Next Topic: Software Process To manage complexity of software, we - PowerPoint PPT Presentation

Next Topic: Software Process � To manage complexity of software, we require a process that codifies the activities of software design, development and validation � There are many processes. Which one is correct 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

Examples of Software Processes � Waterfall process � Incremental process • Microsoft � …There are many more! CISC 323, winter 2003, software process 2

Ad Hoc Process � analysis ---> code --> test --> code --> test … � may work for small program, one programmer � for larger systems, doomed to failure CISC 323, winter 2003, software process 3

Waterfall Model System Requirements Software Requirements 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 4

Waterfall Model •Description of complete system. System Requirements •Boundaries between hardware and software components. Software Requirements •Example: brakes in a car • braking system includes Product Design •foot pedal •brake pads Program •software to control brakes. Design Coding Testing Operations CISC 323, winter 2003, software process 5

Waterfall Model Includes: functional requirements System E.g., depressing the brake Requirements slows the car down Software Requirements Product Design Program Design Coding Testing Operations CISC 323, winter 2003, software process 6

Waterfall Model System Includes: non-functional requirements Requirements • E.g. performance: brakes must respond within 100 ms of being Software activated Requirements • E.g., availability: if software fails, brakes must still function manually. Product Design Program Design Coding Testing Operations CISC 323, winter 2003, software process 7

Waterfall Model • Description of functions the System software must fulfill and associated Requirements quality attributes. • Expressed from point of view of a Software user of the system. Requirements • Does not include implementation decisions such as algorithms, data Product Design structures used to address these Program requirements. Design Coding Testing Operations CISC 323, winter 2003, software process 8

Waterfall Model Example: for course marks program, System functions are: Requirements • Student can access system from any CASLab machine Software • Student can specify course in Requirements which he/she is enrolled and request grades for that course Product Design • Grades recorded for that course will be presented to user Program in a readable format Design • …etc. Coding Testing Operations CISC 323, winter 2003, software process 9

Waterfall Model System Requirements Software Requirements External Design Internal Design Coding • Describes software design meeting the requirements specified above. Testing • Design is external, from point of view of a user of the software. Operations • Shows how requirements are mapped to system features. CISC 323, winter 2003, software process 10

Waterfall Model System Requirements Software Requirements External Design Internal Design • May include: Coding • detailed functional design • screen mockups Testing • interaction design. • Does not describe system implementation, Operations e.g., algorithms, data structures, etc. CISC 323, winter 2003, software process 11

Waterfall Model System Requirements Software Requirements External Design Internal Design Coding Describes implementation of software. Includes, e.g., Testing • Deployment architecture • Component architecture Operations • Component interfaces • Data model • Protocols (how components communicate with each other.) CISC 323, winter 2003, software process 12

Waterfall Model System Requirements Software Requirements External Design Actual programming of software. Internal Design Coding Testing Operations CISC 323, winter 2003, software process 13

Waterfall Model System Requirements Software Requirements Ensuring software performs to specification. External Design Addresses both function and quality attributes. Internal Design Coding Testing Operations CISC 323, winter 2003, software process 14

Waterfall Model System Requirements Once software has been Software delivered, revisions will Requirements be required to address • errors External Design • new requirements This is called software Internal maintenance Design Coding Testing Operations CISC 323, winter 2003, software process 15

Bahrami's Simplification What How Do It Test Use CISC 323, winter 2003, software process 16

Premise of Waterfall Model � Each step completed successfully provides strong foundation for next step � Forces developers to cope with data and control flows, errors, problems earlier in development � Each step should be performed by those skilled in those steps � Document everything: software requirements, preliminary design, interface design, final design, test plan/test results, operating instructions • “To procure 5 million dollars of software, I would estimate a 1500 page specification is about right.” (Royce) CISC 323, winter 2003, software process 17

Relative Cost to Fix or Change Software Throughout Lifecycle 160 140 120 100 80 Large Project Small Project 60 40 20 0 Req Code Accept Test CISC 323, winter 2003, software process 18

Waterfall Model � Emphasis on catching problems early through requirements, design stages • Opportunities for validation at every stage • Testing, inspection � Clear documentation created in each phase • Helpful for coordinating team-work • But may create bottlenecks � Works best for well-understood styles of software • In poorly understood domains, requirements and design are heavily influenced by technical feasibility CISC 323, winter 2003, software process 19

Strengths and Weaknesses of Waterfall Model (1) � Primary function • determine order of stages in software development • set transition requirements from one stage to another � Waterfall Model • document (or task) driven • better than ad-hoc process • most widely used process model in standards and industry CISC 323, winter 2003, software process 20

Strengths and Weaknesses of Waterfall Model (2) � weaknesses • emphasis on fully elaborated documents before going onto next stage • only works for well defined, mature, predictable types of software • doesn’t work for highly interactive software, new technology, research • real projects rarely follow sequential flow of model CISC 323, winter 2003, software process 21

Strengths and Weaknesses of Waterfall Model (3) � weaknesses • difficult for customer to state all requirements explicitly at start of project • working version of program not available until very late in project life-span • major blunder may not be discovered until very late • sequential style leads to bottlenecks and doesn’t lend itself to parallel activities CISC 323, winter 2003, software process 22

Software Prototyping traditional understanding of “prototype”: mock-up of a newly engineered product example: prototype aircraft • checking systems, test flights • make refinements before going into production • have to build nearly whole thing (airframe, engines, cockpit controls, hydraulics, landing gear, electronics, etc.) before test CISC 323, winter 2003, software process 23

Software Prototyping for software, prototype used to • try out on customers • firm up requirements (picture worth 1000 words) • no functions, just skeleton, no special cases • at extreme, may appear to work • try out possible trouble areas • performance; time and resources • achievable; new technology • investigating different options CISC 323, winter 2003, software process 24

Key considerations for using Prototypes � objectives for each prototype activity should be clearly established � define the prototype process ahead (prototyping does NOT mean hacking) � results from prototyping effort must be documented and analyzed before decision on how to proceed � complete one prototype and analyze results before starting next iteration � prototype results can be • throw-away • foundation for enhancement • repackaged as product CISC 323, winter 2003, software process 25

Competing Philosophies on Prototyping (1) • throw away prototype • help customer identify requirements • tools used for prototype not suitable for production • quick & dirty prototype • used to quickly bring up system, modify until customer grants approval • resulting software difficult to maintain • heavily patched and no documentation • working version available quickly • misused by some software contractors? CISC 323, winter 2003, software process 26