Personal Software Processes and Software Development Models

1. CSE 436—Personal Software Processes, Software Development Models Ron K. Cytron http://www.cs.wustl.edu/~cytron/cse436/ 9 October 2006

2. Today • Personal Software Processes • Groups present requirements (postponed to next week) • How did you elicit the requirements? • How are the requirements structured? • What interactions do you require with the customer to firm up the requirements • Software development processes • Break • Groups discuss architecture • Break down project into pieces • Articulate integration and demonstration points • Plan schedule • Present architecture ideas to class

3. PSP–Personal Software Process • What is this? • Self-improvement process • Managing time and other spare resources • Becoming more effective, productive, valuable • Increased awareness • Productivity enhancement • Feasibility • Quality issues • Why? • How do you know where you are? • How do you know where to go? • How do you know how to get there?

4. Baseline Personal Process (PSP0) • Planning • Summary and overview • Get or develop requirements • Fill out plan summary • Entry in time recording log • Development • Design the program • Implement the design • Compile, fix and log all defects • Test, fix and log more defects • Entry in time recording log • Post Mortem • Complete project plan summary • Estimated and actual data • Complete time and defect logs • Today: Planning

5. PSP0 Plan Summary

6. PSP0 Planning-Phase Script • Requirements • Elicit • Elaborate • Validate • Resource estimation • Best estimate • Will serve as area of “personal improvement” • Exit criteria • Documentation • Summary and Overview • Requirements tabulated • Estimated time for the project • Entry in time log for this phase

7. Software Process Models • Distinct set of activities, actions, tasks, milestones, work products • Agreed upon by management and engineers • Adds stability, control to an organization • Steps vary by method • Work products are code, documentation, data • This is an area where WU students are deemed deficient by interviewers. • Take note: • Waterfall • Spiral • XP (Extreme Programming)

8. Waterfall Model • Also called classic life cycle, proposed by Winston Royce in 1970 • Original proposal allowed for feedback and loops • In practice, strictly linear • Called a “prescriptive” process model

9. Waterfall Model • Communication • Initiation, requirements gathering • Planning • Estimating, scheduling, tracking mechanisms • Modeling • Analysis and design • Construction • Code and test • Deployment • Delivery, support, feedback

10. Waterfall Model • Real projects find it difficult to be so “linear” • Customers have trouble stating requirements consistently, accurately, minimally. • Model does not account for uncertainty • Working version of program not realized until end of model • Tracking functional and nonfunctional properties is hard • Customer confidence can become weak • Model may work “in the small” but fails “in the large”

11. Incremental Models 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 • All perform some kind of iteration over waterfall model • Waterfall becomes a pipeline, with next iteration starting when requirements change or become more clear functionality Communication Planning Design/Modeling Construction Deployment time

12. RAD–Rapid Application Deployment Design Design Design Construction Construction Construction • Breaks problem into pieces • Utilizes concurrent design and construction • Huge integration exercise at the end • Alleged 60-90 day time span Communication Planning Deployment

13. RAD drawbacks • Requires sufficient human resources • Must commit to rapid development process • Vision of design must remain consistent among teams • Tends to fade or become chaotic over time • Requires a project that can be componentized • Levels of abstraction and insulation between teams can cause performance issues • Use of cutting-edge technology in one team can sink the whole project if it fails

14. Evolutionary Models • Examples • Prototyping • Spiral • Concurrent Development • Iterative approaches • Increasingly more complete versions of the product are generated • Articulated deliveries can help planning • Revising design delivers a more on-target product • Revisiting implementation can remedy a bad initial approach • Must avoid urge to begin over completely

15. Prototyping Model Communication Quick plan Quick design Deployment, delivery, feedback Construction of prototype

16. Prototyping Model • Useful when • Insufficient requirements exist at start • Behavior of some components unknown • New or strange OS • Hardware “in progress” • HCI (Human-Computer Interface) factors not yet firm • Algorithmic uncertainties: speed, space • However • Testing may be minimal • Not intended for ultimate delivery of longevity • Little or no documentation is produced • Customer and team must agree on this approach up-front • Expectations should not be overly high on either side

17. Schedule • No group meetings this (Oct 13) or next Friday (Oct 20,fall break) • In class 16 October, prepare to present requirements and refined architecture decomposition