Software Engineering Software Project Planning Objectives 1

Software Engineering Software Project Planning

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.

Software Project Planning l The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. l Must 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. l The purpose of project planning is to ensure that the end result is completed on time, within budget, and exhibits quality!

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

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

Estimating Resources l Human Resources: - Select skills required (both position and specialty, e. g. database software engineer). Requires an effort estimate. l Reusable 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) l Environmental Resources: - The hardware and software tools required to develop the project. Planner needs to provide a time window for booking these resources.

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

Example: CAD Software l Statement of Software Scope: - The CAD software will accept 2 D and 3 D 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. l Functional Decomposition: - User interface and control facilities (UICF) Two-dimensional geometric analysis (2 DGA) Three-dimensional geometric analysis (3 DGA) Database management (DBM) Computer graphics display facilities (CGDF) Peripheral control function (PCF) Design analysis modules (DAM)

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. l Example: Function UICF 2 DGA 3 DGA KLOC 2. 3 5. 3 6. 8 DBM CGDF 3. 35 4. 95 PCF DAM Total 2. 1 8. 4 33. 2 - avg. productivity = 620 LOC/pm (pm = person month). Based on burdened labour rate of R 8000 pm, avg. cost = 13 R/LOC. - Total estimated project cost = R 431000. Total estimated effort = 54 person months.

Example: FP l Similarly, FP estimates can be derived. l Unlike LOC, concentrate on information domain rather than software functions. l Useful as a triangulating measure. l Example: - avg. productivity for systems of this type = 6. 5 FP/pm. Based on a burdened labour rate of R 8000, R/FP = R 1230. - Total estimated cost = R 461000, total estimated effort = 58 pm.

Process-Based Estimation l The 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. l Creating a task matrix: framework activities application functions l Effort required to accomplish each framework activity for each application function

Example: Process-Based Estimation Activity CC Plan Risk Anal. Design Code Test CE Total Function UICF 0. 5 2. 5 0. 4 5. 0 n/a 8. 4 2 DGA 0. 75 4. 0 0. 6 2. 0 n/a 7. 35 3 DGA 0. 5 4. 0 1. 0 3. 0 n/a 8. 5 CGDF 0. 5 3. 0 1. 5 n/a 6. 0 DBM 0. 5 3. 0 0. 75 1. 5 n/a 5. 75 PCF 0. 25 2. 0 0. 5 1. 5 n/a 4. 25 DAM 0. 5 2. 0 n/a 5. 0 3. 5 20. 5 4. 75 16. 5 n/a 46 Total 0. 25 CC = customer communication, CE = customer evaluation

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

Triangulating l Do 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. l But, 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. l Planner must determine the cause of deviation and then reconcile the estimates.