Development Process Four Factors People

Development Process

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 Mc. Connell

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

• • • • 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

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

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

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

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

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

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.

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

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

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

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

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

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

Classic Schedule Estimates Activity Small Project (2, 500 lines) Large Project (500, 000 lines) Architecture/design 10% 30% Detailed design 20% Code/debug 25% 10% Unit test 20% 5% Integration 15% 205 System test 10% 15% Fuzzy front-end Requirements specification Unknown time Variable, maybe 30%

Project Estimates are Fuzzy Because the project is fuzzy Effort and Size Schedule Phase Optimistic Pessimistic Initial product concept 0. 25 4. 0 0. 60 1. 60 Approved product concept 0. 50 2. 0 0. 80 1. 25 Requirements specification 0. 67 1. 5 0. 85 1. 15 Product design specification 0. 80 1. 25 0. 90 1. 10 Detailed design specification 0. 90 1. 10 0. 95 1. 05 Cost Models for Future Software Lice Cycle Processes, Boehm, et. al. 1995