1 / 51

Convener: Houman Younessi

Software Engineering Management. Course # CISH-6050. Lecture 5:. Software Process & Project Management Part 2. Convener: Houman Younessi. 06/11/2012. AGENDA. SW-CMM Level 2: Software Process & Project Management Requirements Management Project Tracking & Oversight

otis
Download Presentation

Convener: Houman Younessi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related