1. Development Process

2. Four Factors People –10 to 1 variation in programmer productivity with the same experience Process –Methodology Product –Size Technology –Higher-level tools Rapid Development, Steve McConnell

3. Classic Mistakes: People Undermined motivation Weak personnel Uncontrolled problem employees Heroics Adding people to a late project (Mythical Man Month: Fred Brooks) Noisy, crowded offices Friction between developers and customers Unrealistic expectations Lack of effective project sponsorship Lack of stakeholder buy-in Lack of user input Politics over substance Wishful thinking

4. Classic Mistakes: Process Overly optimistic schedules Insufficient risk management Contractor failure Insufficient planning Abandonment of planning under pressure Wasted time during the fuzzy front end Shortchanged upstream activities—tasks done later cost 10-100 times more. Inadequate design Shortchanged quality assurance Insufficient management controls Premature or overly frequent convergence Omitting necessary tasks from estimates Planning to catch up later Code-like-hell programming

5. Classic Mistakes: Product Requirements gold-plating Feature creep Developer gold-plating Management feature blunders Research-oriented development

6. Classic Mistakes: Technology Silver-bullet syndrome Overestimated savings from new tools or methods Switching tools in the middle of a project Lack of automated source-code control

7. Requirements Management Top 3 reasons for project failure (Standish Group 1994, survey of 8000 projects)— project over budget and late –Lack of user input –Incomplete requirements –Changing requirements

8. Design Fundamentals Information hiding Modularity Abstraction Encapsulation Cohesion Coupling Hierarchy Inheritance Polymorphism Basic/standard algorithms Basic data structures

9. Programming Fundamentals Exception handling Internationalization and localization Portability String storage Data types Input/output Memory management Data storage Database design Performance Reuse

10. Runaway Projects Survey of 600 firms revealed 35% had at least one runaway projects (Rothfeder 1988) –Allstate in 1982 started a 5-year $8 million project to automate office operations. Six years and $15 million later they re-estimated it at $100 million. –Westpac Banking corporation in 1988 started a 5-year $85 million IT redesign. Three years and $150 million later, they killed the project.

11. Risk Identification Feature creep Requirements or developer gold-plating Shortchanged quality Overly optimistic schedules Inadequate design Silver-bullet syndrome Research-oriented development Weak personnel Contractor failure Friction between developers and customers Software Risk Management, Boehm 1989; Assessment and Control of Software Risks, Jones 1994

12. Risk Control Feature Creep –Use customer-oriented practices –Use incremental development practices –Control the feature set Requirements or developer gold-plating –Scrub requirements –Timebox development –Control the feature set –Use staged delivery –Use throwaway prototyping –Design to schedule

13. Risk Control Shortchanged quality –Allow time for QA activities and follow fundamentals Overly optimistic schedules –Use multiple estimation practices, multiple estimators, and automated estimation tools –Use principled negotiation –Design to schedule –Use incremental development practices

14. Risk Control Inadequate design –Have an explicit design activity and schedule enough time for design –Have design inspections Silver-bullet syndrome –Be skeptical of productivity claims –Set up a software measurement program –Set up a software tools group

15. Risk Control Research-oriented development –Don’t try to do research and maximize development speed at the same time –Have a separate research team –Use a risk-oriented lifecycle –Manage risks vigilantly Weak personnel –Hire top talent –Training –Teambuilding

16. Risk Control Contractor failure –Check references –Assess the contractor’s ability before hiring –Actively manage the relationship Friction between developers and customers –Use customer-oriented practices

17. Classic Schedule Estimates ActivitySmall Project (2,500 lines) Large Project (500,000 lines) Architecture/design10%30% Detailed design20% Code/debug25%10% Unit test20%5% Integration15%205 System test10%15% Fuzzy front-endUnknown time Requirements specificationVariable, maybe 30%

18. Project Estimates are Fuzzy Because the project is fuzzy Effort and SizeSchedule PhaseOptimisticPessimisticOptimisticPessimistic Initial product concept 0.254.00.601.60 Approved product concept 0.502.00.801.25 Requirements specification 0.671.50.851.15 Product design specification 0.801.250.901.10 Detailed design specification 0.901.100.951.05 Cost Models for Future Software Lice Cycle Processes, Boehm, et. al. 1995