1 / 16

CSE 436—Personal Software Processes, Software Development Models

CSE 436—Personal Software Processes, Software Development Models. Ron K. Cytron http://www.cs.wustl.edu/~cytron/cse436/. 3 October 2005. Today. Personal Software Processes Break Groups present requirements How did you elicit the requirements? How are the requirements structured?

Gabriel
Download Presentation

CSE 436—Personal Software Processes, Software Development Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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. 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

More Related