1. 1 Convener: Houman Younessi Convener: Houman Younessi Software Engineering Management Software Engineering Management Course # CISH-6050 Lecture 5: Software Process & Project Management Part 2 05/30/2009

2. 2 CISH-6050 - Software Engineering Management 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 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

3. 3 CISH-6050 - Software Engineering Management 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 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

4. 4 CISH-6050 - Software Engineering Management 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 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

5. 5 CISH-6050 - Software Engineering Management 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 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

6. 6 CISH-6050 - Software Engineering Management 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 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

7. 7 CISH-6050 - Software Engineering Management 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 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

8. 8 CISH-6050 - Software Engineering Management 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. 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.

9. 9 CISH-6050 - Software Engineering Management 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 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

10. 10 CISH-6050 - Software Engineering Management 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? 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?

11. 11 CISH-6050 - Software Engineering Management 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? 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?

12. 12 CISH-6050 - Software Engineering Management 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? 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?

13. 13 CISH-6050 - Software Engineering Management 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 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

14. 14 CISH-6050 - Software Engineering Management 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! 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!

15. 15 CISH-6050 - Software Engineering Management Software Project Scheduling … Schedule vs. Cost vs. Requirements -Software Development Project is a three legged stool: 1.Schedule 2.Cost 3.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 Schedule vs. Cost vs. Requirements -Software Development Project is a three legged stool: 1.Schedule 2.Cost 3.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

16. 16 CISH-6050 - Software Engineering Management 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 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

17. 17 CISH-6050 - Software Engineering Management 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? 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?

18. 18 CISH-6050 - Software Engineering Management 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 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

19. 19 CISH-6050 - Software Engineering Management 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 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

20. 20 CISH-6050 - Software Engineering Management 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 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

21. 21 CISH-6050 - Software Engineering Management 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 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

22. 22 CISH-6050 - Software Engineering Management 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 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

23. 23 CISH-6050 - Software Engineering Management 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 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

24. 24 CISH-6050 - Software Engineering Management 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 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

25. 25 CISH-6050 - Software Engineering Management Software Project Scheduling … Activity List for Software Project ActivityDescription Predecessors Duration AAnalyze Reqmnts-1 BRedesign existing componentsA6 CDesign new componentsA3 DDefine unit interfacesC1 EImplement new codeC6 FDevelop integration planC2 GDevelop communication planF2 Activity List for Software Project ActivityDescription Predecessors Duration AAnalyze Reqmnts-1 BRedesign existing componentsA6 CDesign new componentsA3 DDefine unit interfacesC1 EImplement new codeC6 FDevelop integration planC2 GDevelop communication planF2

26. 26 CISH-6050 - Software Engineering Management Software Project Scheduling … Activity List for Software Project ActivityDescription Predecessors Duration IDevelop integration environmentF2 JTest integration environmentI1 KModify existing codeB, D5 LComplete unit testingE, K1 MVerify unit test resultsL1 NUpdate documentationE, K2 ODevelop integration test casesF1 Activity List for Software Project ActivityDescription Predecessors Duration IDevelop integration environmentF2 JTest integration environmentI1 KModify existing codeB, D5 LComplete unit testingE, K1 MVerify unit test resultsL1 NUpdate documentationE, K2 ODevelop integration test casesF1

27. 27 CISH-6050 - Software Engineering Management Software Project Scheduling … Activity List for Software Project ActivityDescription Predecessors Duration PReview integration test casesN, O, G1 QPerform integration testsP, J1 RPerform User Acceptance TestQ, M2 Activity List for Software Project ActivityDescription Predecessors Duration PReview integration test casesN, O, G1 QPerform integration testsP, J1 RPerform User Acceptance TestQ, M2

28. 28 CISH-6050 - Software Engineering Management 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 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

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

30. 30 CISH-6050 - Software Engineering Management 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: 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: A B C 1 ESTLST

31. 31 CISH-6050 - Software Engineering Management Software Project Scheduling … Establish EST at each milestone: -Set EST at M 1 = 0 -Work left to right computing EST(M i ) for all I -Consider each activity A J ending at M i -EST(M i ) = MAX [EST(A J ) + DUR(A J )]  M i = any Milestone  M 1 is project start; M N is project completion  A J represents any activity  DUR(A J ) is duration for activity A J Establish EST at each milestone: -Set EST at M 1 = 0 -Work left to right computing EST(M i ) for all I -Consider each activity A J ending at M i -EST(M i ) = MAX [EST(A J ) + DUR(A J )]  M i = any Milestone  M 1 is project start; M N is project completion  A J represents any activity  DUR(A J ) is duration for activity A J

32. 32 CISH-6050 - Software Engineering Management

33. 33 CISH-6050 - Software Engineering Management Software Project Scheduling … Establish LST at each milestone: -Set LST(M N ) = EST(M N ) -Work right to left computing LST(M i ) for all I -Consider each activity A J starting at M i -LST(M i ) = MIN [LST(M END ) - DUR(A J )]  M i = any Milestone  M END is milestone at end of any given A J  A J represents any activity  DUR(A J ) is duration for activity A J -Correctness Check: LST(M 1 ) = 0 Establish LST at each milestone: -Set LST(M N ) = EST(M N ) -Work right to left computing LST(M i ) for all I -Consider each activity A J starting at M i -LST(M i ) = MIN [LST(M END ) - DUR(A J )]  M i = any Milestone  M END is milestone at end of any given A J  A J represents any activity  DUR(A J ) is duration for activity A J -Correctness Check: LST(M 1 ) = 0

34. 34 CISH-6050 - Software Engineering Management

35. 35 CISH-6050 - Software Engineering Management 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 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

36. 36 CISH-6050 - Software Engineering Management

37. 37 CISH-6050 - Software Engineering Management 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 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

38. 38 CISH-6050 - Software Engineering Management 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 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

39. 39 CISH-6050 - Software Engineering Management 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 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

40. 40 CISH-6050 - Software Engineering Management 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 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

41. 41 CISH-6050 - Software Engineering Management 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 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

42. 42 CISH-6050 - Software Engineering Management 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 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

43. 43 CISH-6050 - Software Engineering Management 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 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

44. 44 CISH-6050 - Software Engineering Management 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. 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.

45. 45 CISH-6050 - Software Engineering Management 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. … 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. …

46. 46 CISH-6050 - Software Engineering Management 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 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

47. 47 CISH-6050 - Software Engineering Management 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 Key Software Configuration Management (SCM) Tasks: -Configuration Control -Change Management -Revisions -Versions -Deltas -Conditional Code -Configuration status accounting, audit & reviews, and records retention

48. 48 CISH-6050 - Software Engineering Management 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 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

49. 49 CISH-6050 - Software Engineering Management 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 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

50. 50 CISH-6050 - Software Engineering Management References 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 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

51. 51 CISH-6050 - Software Engineering Management References … M. Paulk, C. V. Weber, B. Curtis, M. B. Chrissis, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Boston, MA, 1995