1. Project Management All projects need to be “managed” –Cost (people-effort, tools, education, etc.) –schedule –deliverables and “associated” characteristics Project management needs to be consciously studied and understood by : –current project managers –current project leaders –current technical leaders –aspiring software engineers

2. 4-Phases of Project Management Planning (P) –gather and analyze information (e.g. requirements) –develop a project plan Organize (O) –recruit, train, and organize the personnel –acquire and set up the resources, procedures, metrics, etc. Monitor (M) –track the activities and risks according to the metrics Adjust (A) –fix those risk items that turned into real problems –improve upon current activities

3. Planning: Project Plan(s) Quick Estimates: –Brief Product/Project Description –Schedule with deliverables and external delivery dates –Cost of a single rolled up number More Comprehensive Plan: –Product/Project Description: function list, scope of project (all the deliverables), systems, training, consulting services & support –Product/Project Attributes: performance, quality, scalability, any special needs (i.e. translation, standards, etc.) –Schedule: multiple delivery dates, multiple milestones and acceptance dates –Cost: by major functions, by systems, by support, by consulting services, by training, etc. –Resources : people, hardware, software, space, travel, special skills, communication facilities, special tools, process and procedures, etc. –Risks: “prioritized” list of risks and a risk mitigation outline

4. Planning: Estimation The more clear the requirements, the better is the estimate(s) In reality, it is very difficult to modify the numbers once the early estimates are given ; make sure to buffer your estimates 2 most common estimates : 1.schedule 2.cost or effort (most of this is tied to people resource as opposed to hardware or software or facilities)

5. Work-Breakdown Structure (WBS) (an estimation technique) Assuming that the requirements and the types of deliverables are fairly well understood: (e.g.) –code : source, executables, messages, screens, etc. –documents: design spec., test plan, test cases, user manuals, etc. –training: end user training, support personnel training, etc. 1.For each of the deliverables, consider the set of activities that will be employed to develop the deliverable (based on the process/procedure chosen) 2.Map the deliverable against the chosen activities, and consider the sequencing of the activities, including any inter-deliverable relationships.

6. A Simple Work-Breakdown Structure : Example Project is to provide a component that computes the power function (given x and y, provide x**y or x y ). After some discussion with the user/customer, it was determined that the deliverables are: a) user reference sheet and b) actual source code and object code on MS-Windows. The Work-Breakdown Structure of activities: –“Power - code”: analysis, low level (code) design, code, code test on MS Windows environment –Reference sheet: analysis, design, write-up, test the write-up

7. WBS: Simple POWER example (cont.) Initial sequencing of the activities for the deliverables: Analysis of Requirements Ref. Sheet Testing Ref. Sheet Writing Ref. Sheet Design Code Design Code Implementation Code Testing End Note: the reference sheet activities are shifted a bit; also the code design may provide input to reference sheet design.

8. From Work Breakdown to Volume of Work For POWER function code, the “volume” of work may be in: –Pages of Analysis and Design –Lines of Code –Number of Test Cases For POWER reference sheet, the volume may be in: –Number of Pages of design/analysis –Number of Text Sentences and Number of Diagrams –Number of Test Cases

9. How do we Estimate Volume of Effort ? Do we have comparable historic data ? Can we use our personal experience ? Can we ask others who have more experience ? Can we buy data from professional organizations ? Give the estimation work to the workers: –code delivery estimation to the programmers –reference sheet delivery estimation to the writers

10. Volume Estimate with Personal Experience (for this example) POWER Code: –1 page of analysis and design –100 loc of C++ code (input check, error message, power algorithm, return the result) –14 test cases for both variables x and y: 7 test cases for each of the variables x and y –2 outside the boundary, 2 at the boundary, 2 within the boundary and 1 at zero Reference Sheet: –1 page of design –3 pages of user reference sheet (1 for functional description, 1 usage directions, 1 error conditions and messages –3 test cases (1 for normal usage, 2for error condition)

11. Convert Volume Estimates to Effort Estimates Power Code: –1 page of Analysis and Design -.5 person day –100 loc of C++ code - 1 person day –14 test cases and bug fix - 1 person day Reference Sheet : –1 page of Design -.5 person –3 pages of reference sheet -.5 person day –3 test cases, review, and changes -.5 person day

12. Total Cost and Schedule Estimates for POWER ? Total cost in person-days: – 2.5(code) + 1.5 (ref.sheet) = 4 person days Schedule : –if all sequential (with one person), it is 4 days –if done in parallel (with 2 people), it is 2.5 days With Buffer (of approximately 20%) –Cost = 5 person-days (multiply this by $/person-day) –Schedule = 3 days (done in parallel)

13. A Few Things to Remember 1.Is our requirements well understood and double checked with user? 2.Is the buffering enough and applicable to others who may be less familiar/productive with C++ (or any chosen tool) ? –Some claim as much as a factor of 4 between actual and estimate information 3.Is this approach scalable when the project is large and complex (containing hundreds of these POWER functions ) ? 4.Work Breakdown Structure can be more complex if the inter-deliverables are related (code design may affect reference sheet design). 5.How many people can be applied to each activity/task ?

14. Critical Path (CP) Scheduling Critical Path (CP) := Longest Path 1.We need to “break down” the activities into detailed, discrete work units or tasks (with needed time-units). 2.Sequence the work units or tasks, showing what may be performed independently and where are the dependencies. 3.Estimate time required for each task. AB D F C G E EndStart 2 3 4 5 6 32 Note : END is gated by activity E which gated by D & G

15. Critical Path & Expected Project time The “expected” project time is the total time units needed to complete all the tasks on the critical path. In the previous slide: tasks A,B,F,G & E are on the critical path and the total time needed is 2+3+5+6+2 = 18 time units = expected project time Any delay on the critical path elongates the expected project time.

16. CP Scheduling (forward/backward paths) The CP Graph may be looked at in a tabular form: Tasks Est. Time Effort Early Start Late Start Potential Slack A B C D E F G 2 3 4 3 2 5 6 End 0 2 5 9 16 5 10 18 0 0 2 9 13 16 5 10 0 4 4 0 0 0 Note: the slack time may be taken at C or D, but not both taking 4 units. Slack time := (Late start – Early start) Early End 2 16 10 12 9 5 Late End 18 16 10 13 5 2

17. Scheduling with CP Critical Path analysis of a project schedule tells us: 1.sequential ordering of tasks 2.potential parallelism of tasks 3.which activities are critical and must be completed on time to avoid delay. It does not tell us : 1.how accurate the estimated task effort is Some people convert the estimate into a probability interval. (e.g. Program Evaluation and Review Technique - PERT) 2.whether we can apply multiple resources to any of the activity and reduce the time. (CPM, however, will allow us to look at applying resources to reduce time.)