Software Engineering

1. Software Engineering Project Scheduling and Tracking

2. Objectives • To summarize the purpose of project planning. • To examine the scheduling and tracking stage of project planning. • To focus on the scheduling techniques available to a project planner.

3. 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

4. Scheduling • Definition: Once the scope, process model, work estimates and deadline are in place the schedule is used to connect them into a network of SE tasks. • Many SE tasks can be undertaken simultaneously (parallelism) and some may have a profound effect on subsequent tasks (dependency). Difficult to manage without a schedule. • “Excessive or irrational schedules are probably the single most destructive influence in all of software.” – Capers Jones • “I love deadlines. I love the whooshing sound they make as they fly by.” – Douglas Adams • 90-90 Rule. The first 90% of a project is complete in 90% of the scheduled time. The other 10% is also completed in 90% of the time.

5. Why Are Projects Late? • An unrealistic deadline established by someone outside the software development group. • Changing customer requirements that are not reflected in schedule changes. • An honest underestimate of the amount of effort and/or the number of resources that will be required to do the job. • Predictable and/or unpredictable risks that were not considered when the project commenced. • Technical difficulties that could not have been foreseen in advance. • Human difficulties that could not have been foreseen in advance. • Miscommunication among project staff that result in delays. • A failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem

6. Dealing with Unrealistic Deadlines • “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 • Strategy for dealing with unrealistic externally imposed deadlines: • Perform detailed estimates using historical data. • Using an incremental process model create a documented plan to deliver critical functionality within the deadline but delay other functionality till later. • 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.

7. Scheduling Principles • Compartmentalization—Define manageable and distinct subtasks. Both the product and the process are decomposed. • Interdependency—Indicate task interrelationships. Some occur in sequence, others in parallel. • Time Allocation — Each task is allocated some number of work units. • Effort validation—Be sure resources are available. No more than the total allocated hardware and people are scheduled at any given time. • Defined responsibilities—Each task must be assigned to specific people. • Defined outcomes—Each task must have an output (work products which combine to become deliverables) • Defined milestones—Work products become milestones once reviewed for quality and approved.

8. People vs. Productivity • Mongolian Horde: Adding people to a late project makes it later. • Often productivity is related to the number of communication paths amongst team members. • If people must be added to a late project, they should be assigned to work that is highly compartmentalized. • An empirical relationship (from the software equation): • where L is lines of code, E is development effort (in person months), P is a productivity parameter between 2000 and 12000 (reflects a variety of quality factors) and t is development time in years. • Example: A complex real-time software project estimated at 33000 LOC. Completion in 1.3 years requires 8 people but 1.75 years requires only 3.8 people. • Relationship between number of people and productivity is non-linear.

9. Defining Task Sets • Given a particular process, the set of tasks that populate that process, and are appropriate to the project, must be established. • STEP 1: Determine the type of project • Concept Development. Initiated to explore a new business concept, application or technology. • New Application Development. Undertaken as a consequence of a specific customer request. • Application Enhancement. Existing software undergoes major modification observable by the end-user. • Application Maintenance. Correct, adapt or extend existing software in ways not immediately obvious to the end-user. • Reengineering. Rebuilding an existing (legacy) system in whole or in part.

10. Degree of Rigour • The task set will depend in size and complexity on the degree of rigour required: • Casual. All basic principles of SE are applicable. Umbrella activities, documentation and the task set are reduced. Low ceremony. • Structured. Framework activities, related tasks and umbrella activities appropriate to the project are conducted in a streamlined manner. • Strict. Full process applied with absolute discipline. High ceremony. • Quick Reaction. In an emergency situation only those tasks essential to maintaining quality are applied. “Back-filling” (developing documentation, conducting additional reviews) done after delivery. Must not apply to more than 10% of all work and is not the same as a project with strict deadlines.

11. Assessing Rigour • STEP 2: Grade adaptation criteria on a scale of 1 (small subset of process tasks and overall methodology at a minimum) to 5 (complete set of process tasks and methodology is substantial): • Size of the project • Number of potential users • Mission criticality • Application longevity • Stability of requirements • Ease of customer / developer communication • Maturity of applicable technology • Performance constraints • Embedded and non-embedded characteristics • Project staffing • Reengineering factors

12. Task Selection • STEP 3: Compute task set selector (TSS) value. • Multiply the grade by a weight and entry point multiplier (particular to a project type). • Calculate the average of all weighted adaptation criteria. This is the Task Set Selector value. • Examples: • STEP 4: interpret TSS to determine overall degree of rigor

13. I . 2 P r e l i m i n a r y c o n c e p t p l a n n i n g I . 3 T e c h n o l o g y r i s k a s s e s s m e n t P l a n n i n g E n g i n e e r i n g / P r o j e c t D e f i n i t i o n C o n s t r u c t i o n I . 1 C o n c e p s c p i n I . 4 P r o o f o f c o n c e p t C o n c e p t D e v e l o p m e n t N e w A p p l i c a t i o n D e v e l o p m e n t A p p l i c a t i o n E n h a n c e m e n t A p p l i c a t i o n M a i n t e n a n c e R e e n g i n e e r i n g I . 6 C u s t o m e r r e a c t i o n I . 5 C o n c e p t i m p l e m e n t a t i o n C u s t o m e r R e l e a s e E v a l u a t i o n Selecting SE Tasks • STEP 5: Select appropriate software engineering tasks • Example: Concept development tasks using an evolutionary model Concept Planning Risk Assessment Concept Scoping Proof of Concept Customer Reaction Concept implementation

14. Scheduling • SE scheduling not very different from any multi-task engineering effort. • Program Evaluation and Review Technique (PERT) and Critical Path Methods (CPM) are project scheduling methods that determine: • Critical Path (chain of tasks that determine the duration of the project) • Earliest time that a task can begin. 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 project • Total float. The maximum slippage without overall delay. • Implementation: • Automated tools. • Often use a task network as input.

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

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

17. Gantt Chart

18. Tracking • The project schedule provides a roadmap for tasks and milestones that must be tracked and controlled as the project proceeds. • Techniques: • 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. • In 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.

19. Earned Value Analysis • Enables quantitative assessment of the “percentage of completeness” of a project. • Earned Value Metrics: • Budgeted Cost of Work Scheduled (BCWS): During estimation the work cost of each task is calculated. • Budget at Completion (BAC): • Budgeted Cost of Work Performed (BCWP): Sum of BCWS values for all work tasks actually completed. • Actual Cost of Work Performed (ACWP): Sum of effort actually expended on work tasks performed to date. • Schedule Performance Index (SPI) = BCWP / BCWS; Schedule Variance (SV) = BCWP – BCWS • Cost Performance Index (CPI) = BCWP / ACWP; Cost Variance (CV) = BCWP – ACWP (measures cost savings/overruns)