650 likes | 916 Views
Lecture 2. Software Project Management. Topics. Project Organization Process and Project Metrics Planning and Estimation Risk Management. Additional References. Abdel-Hamid, Tarek & Madnick, Stuart (1991) Software Project Dynamics . Prentice Hall.
E N D
Lecture 2 • Software Project Management
Topics • Project Organization • Process and Project Metrics • Planning and Estimation • Risk Management
Additional References • Abdel-Hamid, Tarek & Madnick, Stuart (1991) Software Project Dynamics. Prentice Hall. • Jones, Capers (1991). Applied Software Measurement. McGraw Hill. • DeMarco, Tom (1982). Controlling Software Projects. Yourdon Press. • Donaldson, S. & Siegel, S. (1997). Cultivating Successful Software Development. Prentice Hall. • Humphrey, Watts (1995). A Discipline for Software Engineering. Addison Wesley.
Additional References • Fairley, Richard & Rook, Paul, “Risk Management for Software Development,” in Software Engineering, Dorfman, M & Thayer, R. (eds) (1997). IEEE Computer Society Presss. • Shumskas, Anthony, “Software Risk Mitigation,” in Total Quality Management for Software. Schulmeyer, G. & McManus, J. (eds) (1996). International Thomson Computer Press. • Sommerville, Ian (2001). Software Engineering (6th ed.). Addison-Wesley.
Additional References • Sample text for a Software Development Plan http://www.airtime.co.uk/users/wysywig/sdp_1.htm • Boehm, B. (1995), Anchoring the Software Process. http://sunset.usc.edu/TechRpts/Papers/usccse95-507/ASP.html • University of Southern California - Center for Software Engineering http://sunset.usc.edu • Software Program Managers Network http://www.spmn.com • NASA Web Integrated Software Environment http://research.ivv.nasa.gov/projects/WISE/
Additional References • Practical Software Measurement (PSM), Version 3.1, April 17, 1998. Office of the Undersecretary of Defense for Acquisition and Technology
Topics • Project Organization • Process and Project Metrics • Planning and Estimation • Risk Management
Net U.S. Productivity for New Projects Jones (1991), p. 165 J
Process Factors Jones (1991), p. 169
Workforce Level at IBM’sDP Services Organization Abdel-Hamid, p. 162
Resource Consumption Schach, pp. 278, 279
Ideal vs. Actual Staff Loading Strategies DeMarco (1982), p. 176
Alternate Staffing Strategies DeMarco (1982), p. 181
Chief Programmer Team Sommerville, p. 502
Modern Programming Team Structure Schach, p. 98
Organizational Structure for Larger Projects Schach, p. 99
Decentralized Decision Making Schach, p. 100
People Differences (1) • Ability to perform the work • Interest in the work • Experience with similar applications • Experience with similar tools or languages • Experience with similar techniques • Experience with similar development environment Pfleeger, p. 90
People Differences (2) • Training • Ability to communicate with others • Ability to share responsibility with others • Management skills Pfleeger, p. 90
Work Styles Pfleeger, p. 93
Topics • Project Organization • Process and Project Metrics • Planning and Estimation • Risk Management
What Are Metrics? Metric - quantitative measurement (used for tracking purposes) Process Metrics - feedback to improve the process, productivity Project Metrics - used to track project progress Product Metrics - track quality of product
Schedule and Progress Milestone Performance Work Unit Progress Incremental Capability Growth and Stability Product Size and Stability Functional Size and Stability Technical Adequacy Technology Impacts Target Computer Resource Utilization Technical Performance Resources and Cost Personnel Financial Performance Environment Availability Development Performance Process Maturity Productivity Product Quality Defects Complexity Rework Common Issues - Measurement Categories
Core Program Metrics - As Recommended by the SEI Issues Have we ‘Planned’ for sufficient resources? Are we ‘progressing’ as planned? On budget? On schedule? How good is the product? Metrics Size Effort Cost and Schedule Quality Measure (Actual vs. Planned) Function points, SLOC, CSCIs, SU’s, etc. Labor Costs, Labor Hours, etc. Actual vs. planned cost to date, Gantt Charts, Milestones, Reviews, Deliverables, etc. Defects, Changes, Fixes, etc. How large is the job? Does my process provide valid estimates? Source: Carleton, et al., Software Management for DoD Systems: Recommendations for Initial Implementation, SEI Technical Report, Sept 1992
Cost and Schedule Metrics(Earned Value Example) Projected actual end cost CONTRACT BUDGET BASE $ NOW } Actual cost of work performed Planned cost of work scheduled COST VARIANCE } SCHEDULE VARIANCE Planned cost of work performed 15 16 17 19 20 21 22 23 24 25 26 27 28 29 30 ..... end of project 18 TRR CDR CONTRACT MONTH
Guidance on Metrics (1) • Set clearly defined goals (Goal-Question-Metric (GQM) paradigm) • Focus on project issues (risk management) • Begin by only collecting a few key measurements • Develop a “Project Measurement Plan” • Must have management commitment and “buy-in” from project personnel • training, briefs • allocate adequate resources; metrics analyst • set up a metrics working group
Guidance on Metrics (2) • Provide timely feedback to project personnel on metrics analysis • Automate measurement collection as much as possible • minimize impact on project personnel • Measurement results should remain anonymous • do not measure individuals • all projects are different, do not compare • focus on the process and the product
Guidance on Metrics (3) • Understand that metrics are not an end to themselves • metrics cannot identify, explain, or predict everything • most issues/problems require more than one measurement to characterize and understand • metrics should augment, not replace, good management and engineering judgment • Encourage feedback from measurement program participants • Plan for changes to measurement program and the types of measurements collected
Topics • Project Organization • Process and Project Metrics • Planning and Estimation • Risk Management
Planning in the Spiral Model Schach, p. 81
Software Development Subsystems Abdel-Hamid, p. 22
Project Planning - Lessons Learned (1) • Planning requires a software systems development life cycle to provide a framework for considering the specific tasks to be performed. • Planning needs to account for the interaction among management, development, and product assurance disciplines throughout the project life cycle. • Planning is an ongoing negotiation between the customer and seller. Donaldson & Sigel, pp. 32-34
Project Planning - Lessons Learned (2) • Planning maps out the envisioned technical approach, resources, schedule, and milestones for the transition from the current state to a desired state. • Planning should incorporate the need for change. • Planning needs to assess risk to determine the appropriate mix of management, development, and product assurance resources. Donaldson & Sigel, pp. 32-34
Project Planning - Lessons Learned (3) • Planning is required for any software systems development, and it is captured in a project plan ranging from a one-page memo to a sizable document. Donaldson & Sigel, pp. 32-34
Project Planning Framework Customer Need Define the requirements Items Tasks Produce the conceptual design Historical size database Estimate the product size Customer Historical productivity database Estimate the resources Resources available Produce the schedule Management Size, resource, schedule data Delivered Product Analyze the process Develop the product Tracking reports Humphrey, p. 146
Other Planning Considerations • Training • Facilities • Tools and other support hardware and software • Documentation and other deliverables • Special testing requirements
Size Estimation - Lines of Code - Definitions • SLOC - Source (Single) Line of Code • KLOC - Thousand Lines of Code • PLOC - Physical Line of Code • LLOC - Logical Line of Code • CLOC - Commented Line of Code • NCLOC - Non-Commented Line of Code • DSI - Delivered Source Instruction
Software Size Attributes • Length • Functionality • Complexity • Reuse
Size Estimation - Wideband-Delphi • Group of experts is given program’s specification and estimation form. • Group meets to discuss project goals, assumptions, and estimation issues. • Individuals each anonymously list project tasks and a size estimate. • A moderator tabulates results. • Experts meet to discuss results by reviewing tasks that have been defined but not the estimates. • Cycle continues until estimates converge.
FFP (File-Flow-Process) Metric (van der Poel & Schach) S = Size C = Cost Fi = Files Fl = Flows Pr = Processes b = Measure of efficiency Schach, p. 267
Function Point Calculation Unadjusted UFP = a1(Inp) + a2(Out) + a3(Inq) + a4(Maf) + a5(Inf) Adjusted TCF = 0.65 + 0.01 x DI FP = UFP x TCF FP = Function Points TCF = Technical Complexity Factor UFP = Unadjusted Function Points DI = Degree of Influence
a1 (Inp) a2 (Out) a3 (Inq) a4 (Maf) a5 (Inf) Table of Function Point Values (ai)
Technical Factors for Function Point Computation (DI) Step 1: - Assign value between 0 and 5 to each of the 14 factors where 0 implies “not present or no influence” and 5 implies “strong influence throughout.” Step 2: DI is the sum of the 14 values. Schach, p. 268
Object Points • Object points are an alternative function-related measure to function points when 4GLs or similar languages are used for development • Object points are NOT the same as object classes • The number of object points in a program is a weighted estimate of • The number of separate screens that are displayed • The number of reports that are produced by the system • The number of 3GL modules that must be developed to supplement the 4GL code
Object Point Estimation • Object points are easier to estimate from a specification than function points as they are simply concerned with screens, reports and 3GL modules • They can therefore be estimated at an early point in the development process. At this stage, it is very difficult to estimate the number of lines of code in a system
Cost Estimation Techniques • Expert Judgment by Analogy • Bottom-Up Approach • Algorithmic Cost Estimation Schach, pp. 270 - 272
Structuring of Software Cost Estimation (SCE) Models Heemstra, in Dorfmann & Thayer, p. 378
General Cost Estimation Structure Heemstra, in Dorfmann & Thayer, p. 379