Software Engineering

1. Software Engineering Software Project Planning

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

3. Software Project Planning • The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. • 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. • The 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 • Scope—understand the problem and the work that must be done. • Estimation—how much effort? how much time? • Risk—what can go wrong? how can we avoid it? what can we do about it? • Schedule—how do we allocate resources along the timeline? what are the milestones? • Control strategy—how do we control quality? how do we control change? Project Scope Estimates Risks Schedule Control strategy Software Project Plan

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

6. Estimating Resources • Human Resources: • Select skills required (both position and specialty, e.g. database software engineer). Requires an effort estimate. • Reusable Software Resources: • Off-the-shelf components (existing software acquired from 3rd 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) • Environmental 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 • Project scope must be explicitly defined. If not, the project may be infeasible. • Task and/or functional decomposition is necessary. • Historical measures (metrics) are very helpful. • Triangulation: At least two different techniques should be used. • Remember that uncertainty is inherent in early estimates. • Techniques: • 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.

8. Example: CAD Software • Statement 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. • Functional 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 • Three LOC estimates (optimistic , most likely , pessimistic ) are developed for each function. • Each final function estimate is: • Use historical data for projects of this type (LOC/pm and R/LOC) to obtain effort and cost estimates. • Example: • 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.

10. Example: FP • Similarly, FP estimates can be derived. • Unlike LOC, concentrate on information domain rather than software functions. • Useful as a triangulating measure. • Example: • 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 • 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. • Creating a task matrix: framework activities application functions Effort required to accomplish each framework activity for each application function

12. Example: Process-Based Estimation CC = customer communication, CE = customer evaluation

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

14. Triangulating • 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. • 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. • Planner must determine the cause of deviation and then reconcile the estimates.