1. Software Engineering Software Project Planning

2. Objectives 1.To introduce project planning. 2.To examine the stages of project planning: scoping, estimation, risk analysis and scheduling. 3.To focus on the tools available to a project planner.

3. Software Project Planning lThe overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. lMust deal with:  Project complexity: has a strong effect but is heavily influenced by past practitioner experience.  Project size: as size increases the interdependency of elements also grows. Watch out for scope creep (when customers change requirements mid-cycle).  The degree of structural uncertainty: the degree to which requirements are solidified and the ease of functional decomposition. lThe purpose of project planning is to ensure that the end result is completed on time, within budget, and exhibits quality!

4. Steps in Project Planning lScope—understand the problem and the work that must be done. lEstimation—how much effort? how much time? lRisk—what can go wrong? how can we avoid it? what can we do about it? lSchedule—how do we allocate resources along the timeline? what are the milestones? lControl strategy—how do we control quality? how do we control change? Software Project Plan Project Scope Estimates Risks Schedule Control strategy

5. Scope lA bounded description of the data and control, function, performance, constraints, interfaces and reliability sufficient to determine project feasibility and create an initial plan. lScoping Techniques:  Preliminary meeting or interview  FAST (Facilitated Application Specification Technique) lUnderstanding Scope:  customers needs  business context  project boundaries  customer’s motivation  likely paths for change  “Even when you understand, nothing is guaranteed!”

6. Estimating Resources lHuman Resources:  Select skills required (both position and specialty, e.g. database software engineer). Requires an effort estimate. lReusable Software Resources:  Off-the-shelf components (existing software acquired from 3 rd party with no modification required)  Full-experience components (previous project code is similar and team members have full experience in this application area)  Partial-experience components (existing project code is related but requires substantial modification and team has limited experience in the application area)  New components (must be built from scratch for this project) lEnvironmental Resources:  The hardware and software tools required to develop the project. Planner needs to provide a time window for booking these resources.

7. Estimating Cost and Effort lProject scope must be explicitly defined. If not, the project may be infeasible. lTask and/or functional decomposition is necessary. lHistorical measures (metrics) are very helpful. lTriangulation: At least two different techniques should be used. lRemember that uncertainty is inherent in early estimates. lTechniques: 1.Delay estimation until late in the project (not advisable) 2.Base estimates on similar projects that have already been completed. 3.Use relatively simple decomposition techniques (LOC or FP). 4.Use one or more empirical models for software cost.

8. Example: CAD Software lStatement of Software Scope:  The CAD software will accept 2D and 3D geometric data from an engineer through a user interface that exhibits good HCI. All geometric data will be maintained in a database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will interact with peripheral devices including a mouse, digitizer, laser printer and plotter. lFunctional Decomposition:  User interface and control facilities (UICF)  Two-dimensional geometric analysis (2DGA)  Three-dimensional geometric analysis (3DGA)  Database management (DBM)  Computer graphics display facilities (CGDF)  Peripheral control function (PCF)  Design analysis modules (DAM)

9. Example: LOC 1.Three LOC estimates (optimistic, most likely, pessimistic ) are developed for each function. 2.Each final function estimate is: 3.Use historical data for projects of this type (LOC/pm and R/LOC) to obtain effort and cost estimates. lExample:  avg. productivity = 620 LOC/pm (pm = person month). Based on burdened labour rate of R8000 pm, avg. cost = 13 R/LOC.  Total estimated project cost = R431000. Total estimated effort = 54 person months. FunctionUICF2DGA3DGADBMCGDFPCFDAMTotal KLOC2.35.36.83.354.952.18.433.2

10. Example: FP lSimilarly, FP estimates can be derived. lUnlike LOC, concentrate on information domain rather than software functions. lUseful as a triangulating measure. lExample:   avg. productivity for systems of this type = 6.5 FP/pm. Based on a burdened labour rate of R8000, R/FP = R1230.  Total estimated cost = R461000, total estimated effort = 58 pm.

11. Process-Based Estimation lThe SE Process is decomposed into a small set of tasks and cross referenced against the functions. Planner estimates the effort (in person months) required to accomplish each task for a particular function. lCreating a task matrix: l application functions framework activities Effort required to accomplish each framework activity for each application function

12. Example: Process-Based Estimation ActivityCCPlanRisk Anal. Anal.DesignCodeTestCETotal Function UICF0.52.50.45.0n/a8.4 2DGA0.754.00.62.0n/a7.35 3DGA0.54.01.03.0n/a8.5 CGDF0.53.01.01.5n/a6.0 DBM0.53.00.751.5n/a5.75 PCF0.252.00.51.5n/a4.25 DAM0.52.00.52.0n/a5.0 Total0.25 3.520.54.7516.5n/a46 CC = customer communication, CE = customer evaluation

13. Empirical Estimation Models lUse empirically derived formulae to predict effort as a function of LOC or FP. Do not need your own historical data. lStructure:  where A, B, C are empirical constants, E is effort in person months and ev is the estimation variable (LOC or FP). lSome Examples: lThese models yield different results. Estimation models must be calibrated for specific applications. Best if they have been sourced from many projects.

14. Triangulating lDo not expect that all estimates will agree within a percent or two. If estimates are within a twenty percent band, they can be reconciled into a single figure. lBut, if agreement between estimates is poor:  The scope of the project is not adequately understood or has been misunderstood by the planner.  Productivity data used for problem-based estimation techniques is inappropriate for the application, obsolete or has been misapplied. lPlanner must determine the cause of deviation and then reconcile the estimates.