Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Convener: Houman Younessi PowerPoint Presentation
Download Presentation
Convener: Houman Younessi

Convener: Houman Younessi

122 Views Download Presentation
Download Presentation

Convener: Houman Younessi

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Software Engineering Management Course # CISH-6050 Lecture 5: Software Process & Project Management Part 2 Convener: Houman Younessi 06/11/2012 1

  2. AGENDA • SW-CMM Level 2: Software Process & Project Management • Requirements Management • Project Tracking & Oversight • Project Planning • Project Estimation • Project Scheduling • Software Quality Assurance (SQA) • Software Configuration Management • Sub-contract Management 2

  3. Software Project Scheduling • Software Project Activities • Finalize requirements • Estimate project – size and effort • Identify tasks and resource • Schedule and track the project • Software project scheduled by allocating resource over planned product development phase 3

  4. Software Project Scheduling … • Basic principles guiding project scheduling: • Compartmentalization – tasks & activities • Interdependency – between tasks & activities • Time Allocation – tasks and activities scheduled must be allocated work units • Effort Validation – ensure resources aren’t overbooked for multiple tasks 4

  5. Software Project Scheduling … • Basic principles guiding project scheduling … • Defined Responsibilities – every scheduled task is assigned resource • Defined Outcomes – every scheduled task has a defined outcome • Defined Milestones – every task should be associated with a project milestone 5

  6. Software Project Scheduling … • Mapping Effort to Schedule • Once the effort for a project has been estimated, a schedule can be derived • Example: • 36 Person Month (PM) project • 1 Person could take ~ 3 years • 6 People could take ~ 6 months • 36 People can’t do it in 1 month 6

  7. Software Project Scheduling … • Mapping Effort to Schedule … • Once effort is fixed, some flexibility can be gained by adding resource to the project • A schedule can always be extended by only using fewer resources • Threshold when adding resource: • At some point, adding more resource is no longer productive; more time spent educating new members 7

  8. Software Project Scheduling … • Basic Effort vs. Schedule Concepts, applying productivity: • 1 Person Year (PY) = 2080 Hours (52 weeks * 40 hrs/week) • 1 Person Month (PM) = 174 Hours (52 weeks/12 * 40 hrs) • 100% productivity = 40 hrs/week writing code; no lunch, no meetings, etc. • 90% productivity = 36 hrs/week writing code; 4 hrs for mtgs, lunch, etc. 8

  9. Software Project Scheduling … • For high level discussions on determining project schedule, assume 100% productivity: • Example: 36 PM with 6 resource will take about 6 months to complete • Then, estimates are mapped to actual project plan, where productivity has to be considered: • Ex: 36 PM with 6 resource may actually take 6.7 PM with 90% productivity 9

  10. Software Project Scheduling … • Example: • Project Estimate is 10,000 hours • Effort: PY = 4.81; PM = 57.5 PM • 1 Full Time Equivalent (FTE), working at 100% productivity (40 hrs/week) would take how long to complete the project? 10

  11. Software Project Scheduling … • Example: • Project Estimate is 10,000 hours • Effort: PY = 4.81; PM = 57.5 PM • 1 Full Time Equivalent (FTE), working at 100% productivity (40 hrs/week) would take how long to complete the project? • 57.5 PM or 4.8 Years • 5 FTE working 100% productivity would take how long to complete the project? 11

  12. Software Project Scheduling … • Example: • Project Estimate is 10,000 hours • Effort: PY = 4.81; PM = 57.5 PM • 5 FTE working 100% productivity would take how long to complete the project? • 11.5 PM or almost 1 year • 57.5/5 = 11.5; 4.8/5 = .96 • 5 FTE working 90% productivity would take how long to complete the project? 12

  13. Software Project Scheduling … • Example: • Project Estimate is 10,000 hours • Effort: PY = 4.81; PM = 57.5 PM • 5 FTE working 90% productivity would take how long to complete the project? • 12.7 PM or 1.1 Year • 90% productivity (36 hrs/week), 1 PY = 1872 hours; 1 PM = 157 hours 10,000 / 1872 = 5.34 years / 5 FTE = 1.07 10,000 / 157 = 63.7 months / 5 = 12.7 13

  14. Software Project Scheduling … • What if project schedule doesn’t fit customer’s schedule or dead line? • Ensure schedule based on historical data from development organization • Refine project scope (de-scope) • Suggest phased approach • Consider adding more resource & funding • Avoid unrealistic promises • Meet with customer to discuss options – expectations management! 14

  15. Software Project Scheduling … • Schedule vs. Cost vs. Requirements • Software Development Project is a three legged stool: • Schedule • Cost • Requirements • If try to shorten one leg (i.e. bring in the schedule or reduce the cost), the stool will topple! • If one leg is adjusted, adjust the other two accordingly 15

  16. Software Project Scheduling … • Distributing Effort over software development phases • Actual effort for each phase depends on development model being used • Traditional models – less time in reqmnts & more time in development & test • OO models – more time in design, less time in development • 40-20-40 Guideline: 40% front end analysis; 20% dev; 40% system test 16

  17. Software Project Scheduling … • People Challenges when considering resource, effort, and schedule: • Resource productivity • Educational background & experiences • Teamwork • Manager, project manager relationship with resource & team • Working environment • Organizational turnover – new resource always being rotated into group? 17

  18. Software Project Scheduling … • Common software project scheduling problems: • Assuming best scenario case – everything will go well • Confusing expended effort with actual project progress • Never asking customer to wait longer • Poorly monitored schedule progress • Assuming every bug is the last one • Automatically adding more resource when schedule slips 18

  19. Software Project Scheduling … • Considerations when scheduling project: resource vs. months: • Cost varies as product of staff & months, but progress usually does not • For partitionable tasks – add more resource to bring in schedule • When task can’t be partitioned, adding more resource usually has no effect on schedule • Partitionable tasks with communication between subtasks - diminishing returns 19

  20. Software Project Scheduling … • Brooks’ Law: “Adding manpower to a late software project makes it later.” • How long a project takes depends on sequential constraints • Amount of resource to be effectively used depends on independent subtasks • Training & repartitioning tasks diverts resource from other tasks • Can always derive a longer schedule from reduced resource, but usually not a shorter schedule by adding resource 20

  21. Software Project Scheduling … • Determining Critical Path in the project schedule: • In building the project plan, tasks and subtasks are identified – usually in 2 week or less durations / components • Resource are assigned to the tasks, with estimated start and stop dates (duration) • Some tasks can be done in parallel, while other tasks are dependent and must be done sequentially • A critical path exists through the project 21

  22. Software Project Scheduling … • Critical Path: • Working Definition: Set of activities, any one of which, if not completed within their allocated schedule, will result in a schedule slippage for the entire project • Activities on the critical path of a project have no “slack time” in their duration • Always at least one critical path from the start to the end of project 22

  23. Software Project Scheduling … • Critical Path (CP) … • More than one critical path may exist in a project • Sometimes, there may appear to be more than one critical path, but true critical paths will have the same duration • On rare occasions, every task is on the critical path – i.e. all tasks are sequential • Scheduling tools automatically calculate CP, but there is a method behind the tool 23

  24. Software Project Scheduling … • Critical Path Method: • Make a list of activities, with dependencies • Identify effort and duration for each activity • Organize activity list into Network diagram • Include milestones, placing activities after predecessors • Organize in time sequence, annotating with activity identity and duration • Add milestones if necessary • Refine diagram elements for readability 24

  25. Software Project Scheduling … Activity List for Software Project Activity Description Predecessors Duration A Analyze Reqmnts - 1 B Redesign existing components A 6 C Design new components A 3 D Define unit interfaces C 1 E Implement new code C 6 F Develop integration plan C 2 G Develop communication plan F 2 25

  26. Software Project Scheduling … Activity List for Software Project Activity Description Predecessors Duration I Develop integration environment F 2 J Test integration environment I 1 K Modify existing code B, D 5 L Complete unit testing E, K 1 M Verify unit test results L 1 N Update documentation E, K 2 O Develop integration test cases F 1 26

  27. Software Project Scheduling … Activity List for Software Project Activity Description Predecessors Duration P Review integration test cases N, O, G 1 Q Perform integration tests P, J 1 R Perform User Acceptance Test Q, M 2 27

  28. Software Project Scheduling … • Critical Path Method: • Make a list of activities, with dependencies • Identify effort and duration for each activity • Organize activity list into Network diagram • Include milestones, placing activities after predecessors • Organize in time sequence, annotating with activity identity and duration • Add milestones if necessary • Refine diagram elements for readability 28

  29. Activity Network for Software Project I 5 7 F (2) (2) O 13 (2) G 3 (1) J (1) C H 6 (3) 8 (0) P A R (2) 1 2 (1) (1) D (1) 11 E Q (6) N B (2) (1) (6) M 12 L K 10 9 (1) 4 (1) (5) 29

  30. Software Project Scheduling … • Annotate activity network by assigning each activity: • Earliest Start Time (EST) • Latest Start Time (LST) • EST and LST are shown at the milestones • Represents the earliest start time and latest times for completion for that milestone: EST LST B A 1 C 30

  31. Software Project Scheduling … • Establish EST at each milestone: • Set EST at M1 = 0 • Work left to right computing EST(Mi) for all I • Consider each activity AJ ending at Mi • EST(Mi) = MAX [EST(AJ) + DUR(AJ)] • Mi = any Milestone • M1 is project start; MN is project completion • AJ represents any activity • DUR(AJ) is duration for activity AJ 31

  32. Network with EST 6 8 I 5 18 7 F 4 (2) (2) O 13 (2) G 3 (1) 14 J C H (1) 6 (3) 8 (0) 15 P A 8 1 2 (1) (1) (2) D (1) 11 R E Q 0 (6) N 1 B (2) (1) (6) M 12 L K EST 10 9 (1) 4 (1) 16 (5) 13 12 7 32

  33. Software Project Scheduling … • Establish LST at each milestone: • Set LST(MN) = EST(MN) • Work right to left computing LST(Mi) for all I • Consider each activity AJ starting at Mi • LST(Mi) = MIN [LST(MEND) - DUR(AJ)] • Mi = any Milestone • MEND is milestone at end of any given AJ • AJ represents any activity • DUR(AJ) is duration for activity AJ • Correctness Check: LST(M1) = 0 33

  34. Network with EST/LST 6 12 8 14 I 5 18 18 7 F 4 6 (2) (2) O 13 (2) G 3 (1) 14 14 J C H (1) 6 (3) 8 (0) 15 15 P A 8 14 1 2 (1) (1) (2) D (1) 11 R E Q 0 0 (6) N 1 1 B (2) (1) (6) M 12 L K 10 LST 9 (1) EST 4 (1) 16 16 (5) 13 15 12 12 7 7 34

  35. Software Project Scheduling … • Identifying Critical Path (CP) in Network Diagram: • CP is set of activities where EST = LST and there is no slack time • Usually represent CP as set of activities on the CP: A-B-D-E-K • Always at least one critical path • May be more than one CP with no slack time • Slipping any activity on the CP will mean a slip in the entire project schedule 35

  36. Project Critical Path A-B-K-N-P-Q-R 6 12 8 14 I 5 18 18 7 F 4 6 (2) (2) O 13 (2) G 3 (1) 14 14 J C H (1) 6 (3) 8 (0) 15 15 P A 8 14 1 2 (2) (1) (1) R D (1) 11 E Q 0 0 (6) N 1 1 B (2) (1) (6) M 12 L K 10 LST 9 (1) EST 4 (1) 16 16 (5) 13 15 12 12 7 7 36

  37. Software Project Scheduling … • Critical Path – Additional Thoughts: • Today, most organizations use project tools to identify and manage the critical path • Concept is still the same – tool calculates the CP based on milestones, duration, dependencies, etc. • Generally, tools will produce a Gantt Chart or Bar Chart that identifies activities, durations, and critical path(s) through the project 37

  38. AGENDA • SW-CMM Level 2: Software Process & Project Management • Requirements Management • Project Tracking & Oversight • Project Planning • Project Estimation • Project Scheduling • Software Quality Assurance (SQA) • Software Configuration Management • Sub-contract Management 38

  39. Software Quality Assurance • Software Quality (from Pressman): • Conformance to explicitly stated functional and performance requirements, explicitly documented standards, and implicit characteristics that are expected of all professionally developed software • Software requirements are foundation from which quality is measured • Specified standards define a set of development criteria from which quality is measured 39

  40. Software Quality Assurance … • SQA ensures that: • Appropriate development methodology used • Projects use standards and procedures • Independent reviews & audits conducted • Documentation for maintenance & upgrades • Documentation done during development, not after • Change control processes are in place • Testing emphasizes all high risks areas • Each task successfully completed before starting next task 40

  41. Software Quality Assurance … • SQA ensures that … • Deviations from Standards and Procedures are exposed • Project is auditable by external professionals • Quality control work is performed against standards • The SQA plan and software development plan are compatible 41

  42. Software Quality Assurance … • SQA can be members of existing development team or separate group • SQA plan created during project planning and reviewed by all members • SQA Plan should include: • Evaluations to be performed • Audits & reviews; Standards • Error reporting procedures; SQA documents to be produced 42

  43. Software Quality Assurance … • Some DoD contracts may require Independent Verification & Validation org (IV&V) • If no IV&V org, V&V part of SQA tasks • Verification: • “Are we building the product right?” • Check: program conforms to its specs • Validation: • “Are we building the right product?” • Check: application meets user requirements 43

  44. Software Quality Assurance … • The Testing Process: • Unit Testing • Module Testing • Subsystem Testing • System Testing • Acceptance Testing • Testing plan identifies: • Testing process; requirements traceability; schedule; function to be tested; recording process; constraints; HW & SW; etc. 44

  45. Software Quality Assurance … • Lots of literature, books, and information available on SQA and testing methodologies • Testing Methodologies: • White Box Testing • Basis Path Testing • Control Structure Testing • Black Box Testing • GUI Testing • Etc. … 45

  46. Software Configuration Management • Change management – fundamental activity of Software Engineering • Changes to requirements drives changes to design, to code, to test, etc. • Configuration Management: • Development and application of procedures and standards for managing an evolving systems product 46

  47. Software Configuration Management .. • Key Software Configuration Management (SCM) Tasks: • Configuration Control • Change Management • Revisions • Versions • Deltas • Conditional Code • Configuration status accounting, audit & reviews, and records retention 47

  48. Software Configuration Management .. • Role of SCM: • Establish baselines and control versions • Track change requests & problem reports • Screen, prioritize, & authorize changes • Perform trend analysis: • Requirements changes • Size growth of evolving product • Testing progress • Incremental release content • Errors: new, fixed, continuing 48

  49. Subcontract Management • Purpose of Subcontract Management is to select qualified software subcontractors & manage them effectively: • Selecting a qualified subcontractor • Establishing commitments (contract) • Activities to be performed; dates; basis for managing contract, etc. • Tracking & reviewing subcontractor’s performance and results 49

  50. P. Jalote, Software Project Management in Practice, Addison-Wesley, Boston, MA, 2002 R. L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, Boston, MA, 2003 N. E. Fenton, S. L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, PWS Publishing Company, Boston, MA, 1997 H. Zuse, A Framework of Software Measurement, Walter de Gruyter, New York, NY, 1997 D. Yardley, Successful IT Project Delivery: Learning the Lessons of Project Failure, Addison-Wesley, Boston, MA, 2002 R. S. Pressman, Software Engineering: A Practitioner's Approach, 5th ed., McGraw-Hill, New York, 2001 W. S. Humphrey, Managing the Software Process, Addison-Wesley, Reading, MA, 1989 I. Sommerville, Software Engineering, 5th ed., Addison-Wesley, Reading, MA, 1995 References 50