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

2. CSE 436 Software Engineering Workshop Today Personal Software Processes Break Groups present requirements –How did you elicit the requirements? –How are the requirements structured? –What interactions do you require with the customer to firm up the requirements Break Software development processes Break Groups discuss architecture –Break down project into pieces –Articulate integration and demonstration points –Plan schedule

3. CSE 436 Software Engineering Workshop 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. CSE 436 Software Engineering Workshop 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. CSE 436 Software Engineering Workshop PSP0 Plan Summary

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

7. CSE 436 Software Engineering Workshop 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. CSE 436 Software Engineering Workshop 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. CSE 436 Software Engineering Workshop Waterfall Model Communication –Initiation, requirements gathering Planning –Estimating, scheduling, tracking mechanisms Modeling –Analysis and design Construction –Code and test Deployment –Delivery, support, feedback

10. CSE 436 Software Engineering Workshop 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. CSE 436 Software Engineering Workshop Incremental Models All perform some kind of iteration over waterfall model Waterfall becomes a pipeline, with next iteration starting when requirements change or become more clear 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 time functionality 1.Communication 2.Planning 3.Design/Modeling 4.Construction 5.Deployment

12. CSE 436 Software Engineering Workshop RAD–Rapid Application Deployment Breaks problem into pieces Utilizes concurrent design and construction Huge integration exercise at the end Alleged 60-90 day time span Communication Planning DesignConstruction DesignConstruction DesignConstruction Deployment

13. CSE 436 Software Engineering Workshop 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. CSE 436 Software Engineering Workshop 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. CSE 436 Software Engineering Workshop Prototyping Model Communication Quick plan Quick design Construction of prototype Deployment, delivery, feedback

16. CSE 436 Software Engineering Workshop 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