1. Software Engineering Project Planning James Gain (jgain@cs.uct.ac.za)jgain@cs.uct.ac.za http://people.cs.uct.ac.za/~jgain/courses/SoftEng/

2. Objectives 1.Introduce project planning 2.Examine the stages of project planning:  Scoping  Estimation  Risk Analysis  Scheduling 3.Focus on some of the tools and techniques available to a project planner

3. Software Project Planning lGoal 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 lSufficient to determine project feasibility and create an initial plan lScoping Techniques:  FAST (Facilitated Application Specification Technique), QFD (Quality Function Deployment), Use-Cases lScope is affected by:  Customers’ needs  Business context  Project boundaries  Customers’ motivation  Likely paths for change

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 them

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. Can be reconciled if they are within 20% lRemember that uncertainty is inherent in early estimates lViable Techniques: 1.Delay estimation until later in the project (XP approach) 2.Base estimates on similar projects that have already been completed 3.Use relatively simple decomposition techniques (LOC or FP)

8. Risk Analysis and Management lDefinition of Software Risk:  Concerns future happenings. What risks might cause the project to go astray?  Involves change. How will changes in customer requirements, development technologies, target computers, and other entities affect timeliness and success?  Requires choice. What methods and tools should be used, how many people should be involved to reduce risk? lQuestions:  What can go wrong?  What is the likelihood?  What will the damage be?  What can we do about it?

9. Styles of Risk Management lReactive: “Indiana Jones School of Risk Management” — project team reacts to risks when they occur 1.Mitigation—plan for additional resources in anticipation of fire fighting 2.Fix on failure—resources are found and applied when the risk strikes 3.Crisis management—if failure does not respond to applied resources then the project is in jeopardy lProactive: Formal risk analysis is performed 1.Potential risks are identified 2.Their probability and impact are assessed 3.They are ranked by importance 4.Project team establishes a plan for managing these risks

10. RISK Risk Management Paradigm control identify analyze plan track

11. Risk Analysis lDeveloping a Risk Table (implemented as a spreadsheet): 1.Identify risks 2.Estimate the probability of occurrence. Each member of the project team assigns a probability. Continue in round- robin fashion until agreement is reached 3.Estimate the impact on the project on a scale of 1 to 5: 1 = catastrophic (project failure, costs > R500k) 2 = critical (questionable success, costs = R100-500k) 3 = marginal (degradation of secondary objectives, costs = R1-100k) 4 = negligible (inconvenient, costs < R1k) 4.Sort the table by probability and impact 5.Calculate risk exposure:

12. (3xM) Mitigation, Monitoring, and Management (3xM) Mitigation, Monitoring, and Management lMitigation — how can we avoid the risk? lMonitoring — what factors can we track that will enable us to determine if the risk is becoming more or less likely? lManagement — what contingency plans do we have if the risk occurs? lExample:  Assume high staff turnover has probability = 0.7 and impact = 2  To mitigate meet with staff about grievances, develop techniques to ensure continuity, conduct peer review so all are up to speed, use pair programming  To monitor measure the degree of team “jell”, potential problems with compensation and benefits, general attitude of team members  To manage ensure that procedures are in place for rapid recruitment

13. Scheduling l“I love deadlines. I love the whooshing sound they make as they fly by.” – Douglas Adams lThe Schedule connects the scope, work estimates and deadline into a network of SE tasks lMust Manage:  Parallelism (tasks can be undertaken simultaneously)  Dependency (task has an effect on subsequent tasks) lBad Scheduling is a very destructive influence l90-90 Rule: F irst 90% of a project is complete in 90% of the scheduled time. The other 10% is also completed in 90% of the time

14. Why Are Projects Late? lAn unrealistic deadline established by outsiders lChanging customer requirements that are not reflected in the schedule lAn honest underestimate of effort and/or resources required lRisks that were not considered when the project started lTechnical difficulties that could not have been foreseen lHuman difficulties that could not have been foreseen lMiscommunication among project staff lProject management failing to recognize schedule slippage and not taking corrective action

15. Dealing with Unrealistic Deadlines l“Any commander in chief who undertakes to carry out a plan which he considers defective is at fault; he must put forth his reasons, insist on the plan being changed, and finally tender his resignation rather than be the instrument of his army’s downfall.” – Napoleon lStrategy for dealing with unrealistic externally imposed deadlines: 1.Perform detailed estimates using historical data 2.Using an incremental process model create a documented plan to deliver critical functionality within the deadline but delay other functionality till later 3.Meet with the customers and managers. Indicate the percentage improvement over previous projects required to meet the deadline. Offer the incremental plan as an alternative

16. Scheduling lProgram Evaluation and Review Technique (PERT) AKA Critical Path Method (CPM) is a project scheduling method that determines:  Critical Path (the chain of tasks that determine the duration of the project)  Earliest Time that a task can begin if all preceding tasks are completed in the shortest possible time  Latest Time for task initiation that will not delay the project  Latest and Earliest Finish for the overall project  Total Float (the maximum slippage without overall delay) lImplementation:  Automated tools  Often use a task network as input

17. Define a Task Network lTask (Activity) Network: a graphical representation of the task flow and interdependencies for a project 1.1 Concept Scoping 1.2 Concept Planning 1.3a Risk Assess. 1.3b Risk Assess. 1.3c Risk Assess. 1.4 Concept Proof 1.5a Concept Implement. Integrate a, b, c 1.6 Customer Reaction 1.5b Concept Implement. 1.5c Concept Implement.

18. Effort Allocation 40-50% 30-40% l“front end” activities  customer communication  analysis  design  review and modification lconstruction activities  coding or code generation ltesting and installation  unit, integration  white-box, black box  regression 15-20%

19. Gantt Chart

20. Tracking lThe project schedule provides a roadmap for tasks and milestones that must be tracked and controlled as the project proceeds lTechniques:  Hold Periodic project status meetings for all team members  Evaluate the results of all reviews  Determine whether formal project milestones have been accomplished by the scheduled date  Comparing actual start date to planned start date for each task  Meeting informally with practitioners to obtain their subjective assessment  Using earned value analysis to assess progress quantitatively lIn dire straits managers will use time-boxing. When a task hits the boundary of its time box (+- 10%) work stops and the next task begins