1 / 22

Chapter 3 Project Management

Chapter 3 Project Management. The 4 P’s. People — the most important element of a successful project Product — the software to be built Process — the set of framework activities and software engineering tasks to get the job done Project — all work required to make the product a reality.

geona
Download Presentation

Chapter 3 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. Chapter 3Project Management

  2. The 4 P’s • People — the most important element of a successful project • Product — the software to be built • Process — the set of framework activities and software engineering tasks to get the job done • Project — all work required to make the product a reality

  3. Software Projects Factors that influence the end result ... • size • delivery deadline • budgets and costs • application domain • technology to be implemented • system constraints • user requirements • available resources

  4. Project Management Concerns

  5. Why Projects Fail? • an unrealistic deadline is established • changing customer requirements • an honest underestimate of effort • predictable and/or unpredictable risks • technical difficulties • miscommunication among project staff • failure in project management

  6. Software Teams The following factors must be considered when selecting a software project team structure... • the difficulty of the problem to be solved • the size of the resultant program(s) in lines of code or function points • the time that the team will stay together (team lifetime) • the degree to which the problem can be modularized • the required quality and reliability of the system to be built • the rigidity of the delivery date • the degree of sociability (communication) required for the project

  7. Organizational Paradigms • Democratic decentralized (DD) • Better for difficult problems • High morale • Low modularity? • Controlled decentralized (CD). • High modularity • Controlled centralized (CC). • High modularity • Faster for routine work

  8. Chief Programmer Team • IBM – New York Times project • Chief Programmer – backup • “Librarian” • 2-5 programmers

  9. Defining the Problem • establish scope—a narrative that bounds the problem • decomposition—establishes functional partitioning

  10. Melding Problem and Process

  11. To Get to the Essence of a Project • Why is the system being developed? • What will be done? By when? • Who is responsible for a function? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource (e.g., people, software, tools, database) will be needed? Barry Boehm

  12. PERT • Tasks – activities with well defined beginning and end • Use a graph to show dependencies • Circles milestones • Arrows activities • Determine critical path and slack time • Expediter • Statistical estimates and simulations can be used for more realism

  13. Best practices • DOD • Airlie software Council (Virginia) • 1994 initiative

  14. Nine Best practices • Formal risk management • User manual as specification • Inspections and peer reviews • Metric-based scheduling and tracking • Binary gates at the inch-pebble level • Program-wide visibility of project plan and progress versus plan

  15. Nine best practices • Defect tracking against quality targets • Separate specification of hardware and sotware functionality • People-aware management accountabililty

  16. Worst practices • Don’t use schedule compression to justify usage of new technology on any time critical project • Don’t specify implementation technology in the RFP • Don’t advocate use of unproven silver bullet approaches

  17. Worst Practices • Don’t expect to recover form any substantial schedule slip (10% or more) without making more than corresponding reductions in functionality to be delivered • Don’t put items out of project control on the critical path • Don’t expect to achieve large, positive improvements (10% or more over past observed performance

  18. Worst practices • Don’t bury all project complexity in the software (as opposed to the hardware) • Don’t conduct the critical system engineering tasks without software expertise • Don’t believe that formal reviews provide an accurate picture of the project. Usefulness inversely proportional to number beyond five

  19. Microsoft • Level 5 can’t compete against Microsoft? • 17 million copies of Word? • Legal problems • Bozo explosion? • 2000 unsolicited resumes/week

  20. MS peopleware policies • Hire smart people • On project team right away (IBM - 6 months training) • Weekly education sessions • Mentor • Kick back

  21. MS managers • Induce uncertainty, don’t swallow it • The manager is the greatest expert on when you will finish - rely on QA for opinion • Prevent someone from going dark • Don’t micromanage • rely on interdependence among team members • Small milestones • Don’t trade one bad date for another

  22. MS development practices • Case tools, formal analysis and design - not • Formal specification - not • Daily build • Testing • Development not allowed to being until testing signs off on specifications • 1-1 ratio of testers to developers • Quick and dirty tests before build

More Related