1 Chapter 3 Project Management. 2 The 4 P’s People — the most important element of a successful project Product — the software to be built Process.
Published byModified over 6 years ago
Presentation on theme: "1 Chapter 3 Project Management. 2 The 4 P’s People — the most important element of a successful project Product — the software to be built Process."— Presentation transcript:
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 size delivery deadline budgets and costs application domain technology to be implemented system constraints user requirements available resources Factors that influence the end result...
5 Why Projects Fail? an unrealistic deadline is established an unrealistic deadline is established changing customer requirements changing customer requirements an honest underestimate of effort an honest underestimate of effort predictable and/or unpredictable risks predictable and/or unpredictable risks technical difficulties technical difficulties miscommunication among project staff miscommunication among project staff failure in project management failure in project management
6 Software Teams 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 The following factors must be considered when selecting a software project team structure...
7 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 Organizational Paradigms
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
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