1 / 95

2 PROJECT MANAGEMENT

2 PROJECT MANAGEMENT. Software Engineering Roadmap: Chapter 2 Focus. Corporate practices. Plan project. Analyze requirements. Maintain. Integrate & test system. Design. Implement. Test units.

carlosfrance
Download Presentation

2 PROJECT MANAGEMENT

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. 2PROJECT MANAGEMENT

  2. Software Engineering Roadmap: Chapter 2 Focus Corporate practices Plan project Analyze requirements Maintain Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  3. Software Engineering Roadmap: Chapter 2 Focus Management structure - hierarchical, peer,... Risk identification & retirement SPMP Schedule Development process - when to do what phase - document: SPMP Corporate practices Cost estimate Plan project Development phases Analyze requirements Maintain Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  4. Learning Goals of This Chapter • Understand the term “project management” • Organize teams • Specify project management plans • Define and retire risks • Estimate costs very early in the life cycle • Create high level projects schedules • Write a Software Project Management Plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  5. 1. Introduction to project management

  6. The Variables of Project Management • Can somewhat vary the following factors. 1. The total cost of the project, • e.g., increase expenditures 2. The capabilities of the product, • e.g., subtract from a list of features . . . . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  7. The Variables of Project Management • Can somewhat vary the following factors. 1. The total cost of the project, • e.g., increase expenditures 2. The capabilities of the product, • e.g., subtract from a list of features 3. The quality of the product, • e.g., increase the mean time between failure 4. The date on which the job is completed. • e.g., reduce the schedule by 20% • e.g., postpone project's completion date one month Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  8. Bullseye Figure for Project Variables cost Target: 100% Target : $70K capability duration Target : 30 wks Target : 4 defects/Kloc defect density Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  9. Bullseye Figure for Project Variables cost Target: 100% Target : $70K Actual: $90K Actual: 100% this project capability duration Target : 30 wks Target : 4 defects/Kloc Actual: 20 wks Actual: 1 defect/Kloc defect density Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  10. RoadMap for Project Management 1. Understand project content, scope, & time frame 2. Identify development process (methods, tools, languages, documentation and support) -- section 4 of chapter 1 3. Determine organizational structure (organizational elements involved)-- see section 3 4. Identify managerial process (responsibilities of the participants)-- see section 3 of case study 1 at end of chapter . . . . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  11. RoadMap for Project Management 1. Understand project content, scope, & time frame 2. Identify development process (methods, tools, languages, documentation and support) -- section 4 of chapter 1 3. Determine organizational structure (organizational elements involved)-- see section 3 4. Identify managerial process (responsibilities of the participants)-- see section 3 of case study 1 at end of chapter 5. Develop schedule (times at which the work portions are to be performed) -- see section 6 6. Develop staffing plan -- see section 3.5 of case study 1 7. Begin risk management -- see section 4 8. Identify documents to be produced -- see SQAP 4.2 9. Begin process itself -- described in chapters 3-10 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  12. 2. Managing people

  13. Plan and Execute Meetings One way to ... 1.* Distribute start time, end time, and agenda with approximate times (see figure tbd) • list important items first 2.* Ensure “strawman” items prepared 3. Start on time 4. Have someone record action items‡ 5. Have someone track time & prompt members 6. Get agreement on the agenda and timing 7. Watch timing throughout, and end on time • allow exceptions for important discussion • stop excessive discussion; take off line 8. Keep discussion on the subject 9.** E-mail action items & decision summary. * in advance of meeting ‡ actions members must perform ** after meeting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  14. Specify Agendas One way to ... 1. Get agreement on agenda & time allocation 2. Get volunteers to … : … record decisions taken and action items … watch time and prompt members (see figure tbd) 3. Report progress on project schedule -- 10 mins 4. Discuss strawman artifact(s) -- x mins 5. Discuss risk retirement -- 10 mins <MORE ITEMS> metrics and process improvement? n. Review action items -- 5 mins Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  15. 3. Options for organizing personnel

  16. Optimal Size for Interaction (Approximate) Effectiveness per developer Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help. 3 Number of people with whom developer must frequently interact Key: = engineer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  17. Optimal Size for Interaction (Approximate) Effectiveness per developer Approximate optimal range Developer communicates regularly with eleven people. Communication time outweighs benefits of interaction Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help. 3 7 Number of people with whom developer must frequently interact Key: = engineer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  18. Hierarchical Project Management Organizations Smaller Projects: Larger Projects: No separate Marketing? No separate QA organization? • Subdivide QA into testing, …? • Subdivide Engineering into • system engineering, …? Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  19. Horizontal Project Management Organizations Ian Corliss Team member Gil Warner Team leader Nel Tremont Team member Team facilitator? Fran Smith Team member Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  20. Organize a Team One way to ... 1. Select team leader: responsibilities: • ensure all project aspects active • fill all gaps 3. Designate leader roles & document responsibilities team leader: proposes and maintains… SPMP configuration management leader: ... SCMP quality assurance leader: ... SQAP, STP requirements management leader: ... SRS design leader: ... SDD implementation leader: ... code base 2. Leaders’ responsibilities: • propose a strawman artifact (e.g. SRS, design) • seek team enhancement & acceptance • ensure designated artifact maintained & observed • maintain corresponding metrics if applicable 4. Designate a backup for each leader as per One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  21. Peer Organizations for Larger Projects Team of leaders Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  22. Project Airline reserv. project Bank accountg. project Molecular analysis project Fluid mechanics project Func- tional Unit Project manage-ment dpt Al Pruitt Full time Quinn Parker Half time Ruth Pella Full time Fred Parsons Full time Marketing dpt Oscar Mart Full time Pete Merrill Full time Sue More Half time Elton Marston Full time Engineer-ing dpt Hal Egberts ...... Ben Ehrlich ...... Mary Ericson ..... Len Engels ..... Table 2.1 Matrixed organization Table 2.1 Matrixed organization

  23. 4. Identifying and retiring risks

  24. The Four Risk Activities (1) Identification Mindset: try to continually identify risks (2) Retirement planning (3) Prioritization (4) Retirement or mitigation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  25. Risk Sources Ordered by Importance (Keil, Cule, Lyytinen, Schmidt) 1. Lack of top management commitment 2. Failure to gain user commitment 3. Misunderstanding of requirements 4. Inadequate user involvement 5. Failure to manage end-user expectations 6. Changing scope and/or objectives 7. ….

  26. The Risk Management Mindset Identification Retirement 2. “Java skills not high enough.” 2. Retirement by avoidance:Use C++ Project finish Project finish Risk 2 Risk 2 Risk 1 Risk 1 1. Retirement by conquest:Demonstrate image super- imposition 1. “May not be possible to superimpose images adequately.” Project start Project start Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

  27. Likelihood 1-10 1 = least likely Impact 1-10 1 = least impact Retire-ment cost 1-10 1 = lowest retirement cost Priority computation Resulting priority Lowest number handled first The highest priority risk 10 (most likely) 10 (most impact) 1 (lowest retirement cost) (11-10) *(11-10) *1 1 The lowest priority risk 1 (least likely) 1 (least impact) 10 (highest retirement cost) (11-1) *(11-1) *10 1000 Table 2.2 A way to compute risk priorities Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  28. #  Risk title (details given above) Like-lihood 1-10 1=least likely Im-pact 1-10 1=least impact Retire-ment cost 1-10 1=lowest retirement cost Pri-ority lowest number handled first Retirement / mitigation plan Respon-sible engineer Target com-pletion date 1 Super-imposing images 3 10 1 8 Experiment with Java images. P. R. 2/1/99  2 Deficient Java skills 9 6 8 80 H.T., K.M., V.I. and L.D. to attend training course beginning 1/5/99 at Ultra Training Corp, obtain Java level 2 certification by 3/1/99 and level 3 certification by 4/15/99 H. L. 4/15/99 3 Alan Gray may be pulled off this project 3 7 9 288 Susan Ferris to inspect all of Alan's work S.F. Contin-ual .. ... ... ... ... ... ... ... ... Table 2.3  Sample Risk Analysis for Encounter Case Study Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  29. Identify and Retire Risks One way to ... 1.* Each team member spends 10 mins. exploring his or her greatest fears for the project’s success 2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader 3.* Team leader integrates and prioritizes results 4.M Group spends 10 mins. seeking additional risks 5.M Team spends 10 mins. finalizing the risk table • Designates responsible risk retirement engineers 6.** Responsible engineers do risk retirement work 7.M Team reviews risks for 10 mins. at weekly meetings • responsible engineers report progress • team discusses newly perceived risks and adds them *:in advance of first meeting M: at meeting **: between meetings

  30. 5. Choosing development toolsand support

  31. To support project management schedule work breakdown To support configuration management For managing requirements For drawing designs functional object-oriented use-case-based Tracing tools requirements to designs designs to code To support testing To support maintenance Potential CASE Tool Components Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

  32. Example of Build vs. Buy Decision-making: Game Graphics engine Build costBuy costComments (in thousands) multi-year costs not accounted for Supplies $ 0 $40 Purchase Ajax engine First-person perspective$ 5 $ 0 Ajax has this feature 3-D $10 $ 1 Customize Ajax application Light reflection $15 $10Customize Ajax application ___ ___ _________________ TOTALS $30$51 Build, do not buy Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  33. Factor Weight  (1-10) Benefit of Language 1 1 to 10=best Benefit of Language 2 1 to 10=best Internet-friendly 3 8 2 Familiarity to development team 8 3 9 Compilation speed 5 2 8 Runtime speed on processor p 1 7 3 Score 3*8 + 8*3 + 5*2 + 1*7 = 65 3*2 + 8*9 + 5*8 + 1*3 = 121 Table 2.4 Example of method for deciding language choice Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  34. 6. Creating schedules: high level planning

  35. High Level Task Chart with Fixed Delivery Date:Order of Completion Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 SCMP complete Begin system testing (2) SQAP complete Milestones (1*) Delivery SPMP rel. 1 complete (3) Freeze requirements (4) Iteration 1 (6) Iteration 2 Risk identification & retirement (5) Prep. for maintenance * Indicated the order in which the parts of this table were built Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  36. One way to ... Create an Initial Schedule 1. Indicate the milestones your must observe • usually includes delivery date 2. Back these up to introduce the milestones you need • e.g., begin system testing well before delivery 3. Designate a time at which all requirements frozen The remaining steps depend on the process used. We will assume an iterative process. 4. Show first iteration: establishes minimal capability • usually: keep it very modest, even trivial, in capability • benefit: exercises the development process itself 5. Show task of identifying & retiring risks • starting from project inception 6. Show unassigned time (e.g., week) near middle? 7. Complete the schedule Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  37. Level Labor Allocation for Fixed Labor Total Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Milestones Freeze requirements Complete testing Karen vacation Release to production 2 2 2 3 2 2 3 Iteration 1 Hal vacation 4 4 4 3 3 4 4 4 4 4 4 4 Iteration 2 2 2 2 1 1 1 4 To be assigned Risk ID & retire Given team size: 4 4 4 4 4 3 3 4 4 4 4 3 3 4 4 4 4 4 4 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  38. 7. Integrating legacy applications

  39. Add new features (typically using same language) or Change features (e.g., port to new environment) Legacy System Integration Build new application that uses legacy system (possibly using different language) Resulting system Repairs Legacy system Legacy system New application New features Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  40. 8. Estimating costs: early calculations

  41. Range of cost estimates after conceptualization phase,based on actual cost of $1 $4 Conceptual- ization phase $1 Range of cost estimates after requirements analysis phase 25c Requirements analysis $1 Design Range of Errors in Estimating Eventual Cost $1 Implementation $1 Integration/Test $1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  42. Typical Cost Estimation Roadmap 1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code. and / or 1B. Use function point method to estimate lines of code 1B.1 Compute un-adjusted function points. 1B.2 Apply adjustment process. 2. Use lines of code estimates to compute labor and duration using COCOMO formulas. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  43. Function Point Computation for a Single Function (IFPUG) External Inquiries (EIN) Internal Logical Files (ILF)* Function Logical group of user data Logical group of user data Logical group of user data External Outputs (EO) External Inputs (EI) External Logical Files (ELF) file file * Internal logical grouping of user data into files file

  44. Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) PARAMETERsimplecomplex Ext. inputsEI… 3 or… 4 or ...6 = ___ Ext. outputs EO … 4 or … 5 or ...7= ___ countTotal

  45. Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) PARAMETERsimplecomplex Ext. inputsEI… 3 or… 4 or ...6 = ___ Ext. outputs EO … 4 or … 5 or ...7= ___ Ext. inquiriesEIN… 3 or … 4 or ...6= ___ Int. logical files ILF ... 7 or …10 or ... 15= ___ Ext. logical files ELF ... 5 or …7 or ... 10= ___ countTotal

  46. Unadjusted Function Point Computation for First Encounter Functions:“Set up Player Character” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  47. Unadjusted Function Point Computation for Second Encounter Functions: “Encounter Foreign Character” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  48. General Characteristics for FP Adjustment 1-7 1. Requires backup/recovery? 0-2 2. Data communications required? 0-1 3. Distributed processing functions? 0 . . . . . incidental average essential 0 1 2 3 4 5 Case study none moderate significant

  49. General Characteristics for FP Adjustment 1-7 incidental average essential 1. Requires backup/recovery? 0-2 2. Data communications required? 0-1 3. Distributed processing functions? 0 4. Performance critical? 3-4 5. Run on existing heavily utilized environmt.? 0-1 6. Requires on-line data entry? 5 7. Multiple screens for input? .... continued 4-5 0 1 2 3 4 5 Case study none moderate significant

  50. General Characteristics for FP Adjustment 8-14 incidental average essential 8. Master fields updated on-line? 3-4 9. Inputs, outputs, inquiries of files complex? 1-2 10. Internal processing complex? 1-4 . . . . 0 1 2 3 4 5 Case study none moderate significant

More Related