Next Topic: Software Process Examples of Software Processes � To manage complexity of software, we require a � Waterfall process process that codifies the activities of software � Incremental process design, development and validation • Microsoft � There are many processes. Which one is correct � …There are many more! depends on the desired quality attributes of the system under construction. � Process model: describes process � Reading: • Bahrami Chapter 3 • Custom Courseware: Microsoft paper (Cusumano & Selby) CISC 323, winter 2003, software process 1 CISC 323, winter 2003, software process 2 Ad Hoc Process Waterfall Model System � analysis ---> code --> test --> code --> test … Requirements � may work for small program, one programmer Software Requirements � for larger systems, doomed to failure Product Design Program Design Coding Testing Operations Winston Royce, Managing the Development of Large Software Systems: Concepts and Techniques, 1970 CISC 323, winter 2003, software process 3 CISC 323, winter 2003, software process 4 1
Waterfall Model Waterfall Model •Description of complete system. Includes: functional requirements System System E.g., depressing the brake Requirements Requirements •Boundaries between hardware slows the car down and software components. Software Software Requirements Requirements •Example: brakes in a car • braking system includes Product Design Product Design •foot pedal •brake pads Program Program •software to control brakes. Design Design Coding Coding Testing Testing Operations Operations CISC 323, winter 2003, software process 5 CISC 323, winter 2003, software process 6 Waterfall Model Waterfall Model • Description of functions the System Includes: non-functional requirements System software must fulfill and associated Requirements • E.g. performance: brakes must Requirements quality attributes. respond within 100 ms of being • Expressed from point of view of a Software activated Software user of the system. Requirements • E.g., availability: if software Requirements fails, brakes must still function • Does not include implementation manually. Product Design Product Design decisions such as algorithms, data structures used to address these Program Program requirements. Design Design Coding Coding Testing Testing Operations Operations CISC 323, winter 2003, software process 7 CISC 323, winter 2003, software process 8 2
Waterfall Model Waterfall Model Example: for course marks program, System System functions are: Requirements Requirements • Student can access system from any CASLab machine Software Software • Student can specify course in Requirements Requirements which he/she is enrolled and request grades for that course Product Design External Design • Grades recorded for that course will be presented to user Program Internal in a readable format Design Design • …etc. Coding Coding • Describes software design meeting the requirements specified above. Testing Testing • Design is external, from point of view of a user of the software. Operations Operations • Shows how requirements are mapped to system features. CISC 323, winter 2003, software process 9 CISC 323, winter 2003, software process 10 Waterfall Model Waterfall Model System System Requirements Requirements Software Software Requirements Requirements External Design External Design Internal Internal Design Design • May include: Coding Coding • detailed functional design Describes implementation of software. • screen mockups Includes, e.g., Testing Testing • interaction design. • Deployment architecture • Component architecture • Does not describe system implementation, Operations Operations • Component interfaces e.g., algorithms, data structures, etc. • Data model • Protocols (how components communicate with each other.) CISC 323, winter 2003, software process 11 CISC 323, winter 2003, software process 12 3
Waterfall Model Waterfall Model System System Requirements Requirements Software Software Requirements Requirements Ensuring software performs to specification. External Design External Design Addresses both function Actual programming and quality attributes. of software. Internal Internal Design Design Coding Coding Testing Testing Operations Operations CISC 323, winter 2003, software process 13 CISC 323, winter 2003, software process 14 Waterfall Model Bahrami's Simplification System Requirements What Once software has been Software delivered, revisions will Requirements be required to address How • errors External Design • new requirements This is called software Do It Internal maintenance Design Test Coding Testing Use Operations CISC 323, winter 2003, software process 15 CISC 323, winter 2003, software process 16 4
Premise of Waterfall Model Relative Cost to Fix or Change Software Throughout Lifecycle � Each step completed successfully provides strong foundation for next step 160 � Forces developers to cope with data and control flows, 140 errors, problems earlier in development 120 � Each step should be performed by those skilled in those 100 steps 80 Large Project � Document everything: software requirements, preliminary Small Project 60 design, interface design, final design, test plan/test results, operating instructions 40 • “To procure 5 million dollars of software, I would 20 estimate a 1500 page specification is about right.” 0 (Royce) Req Code Accept Test CISC 323, winter 2003, software process 17 CISC 323, winter 2003, software process 18 Waterfall Model Strengths and Weaknesses of Waterfall � Emphasis on catching problems early through Model (1) requirements, design stages • Opportunities for validation at every stage � Primary function • Testing, inspection • determine order of stages in software development � Clear documentation created in each phase • set transition requirements from one stage to another • Helpful for coordinating team-work • But may create bottlenecks � Waterfall Model � Works best for well-understood styles of software • document (or task) driven • In poorly understood domains, requirements and design • better than ad-hoc process are heavily influenced by technical feasibility • most widely used process model in standards and industry CISC 323, winter 2003, software process 19 CISC 323, winter 2003, software process 20 5
Strengths and Weaknesses of Waterfall Strengths and Weaknesses of Waterfall Model (2) Model (3) � weaknesses � weaknesses • emphasis on fully elaborated documents before going onto • difficult for customer to state all requirements explicitly at next stage start of project • only works for well defined, mature, predictable types of • working version of program not available until very late in software project life-span • doesn’t work for highly interactive software, new • major blunder may not be discovered until very late technology, research • sequential style leads to bottlenecks and doesn’t lend itself • real projects rarely follow sequential flow of model to parallel activities CISC 323, winter 2003, software process 21 CISC 323, winter 2003, software process 22 Software Prototyping Software Prototyping traditional understanding of “prototype”: mock-up of for software, prototype used to a newly engineered product • try out on customers • firm up requirements (picture worth 1000 example: prototype aircraft words) • checking systems, test flights • no functions, just skeleton, no special cases • make refinements before going into production • at extreme, may appear to work • try out possible trouble areas • have to build nearly whole thing (airframe, • performance; time and resources engines, cockpit controls, hydraulics, landing • achievable; new technology gear, electronics, etc.) before test • investigating different options CISC 323, winter 2003, software process 23 CISC 323, winter 2003, software process 24 6
Recommend
More recommend