✄ ✂ ✂ ☎ ✞ ✞ ✂ ✆ ✁ ✝ ✁ ✂ ✝ ✁ ✁ ✝ ✂ ✂ ✁ ✄ � ☎ ✝ ✝ � Software Process A software (development) process is a method for CISC323: Introduction to Software developing software that organizes the effort into a number of Engineering separate steps such that large software can be developed by many people in an organized, manageable and track-able way There are many processes , each with their own strengths Next Topic: Software Process and weaknesses Which one is most suitable depends on the desired quality Readings : attributes of the system under construction Bahrami: Chapter 3 Warning : Software processes are often also called “models” Custom Courseware: Advice : This topic makes the most sense if you put your “How Microsoft Builds Software” project manager hat on 1 2 CISC 323, Winter 2004, SW Process CISC 323, Winter 2004, SW Process Examples of Software Processes Ad Hoc Process Ad hoc process code test code test Analyze Waterfall process analyze … Prototyping process May work for small programs developed by one Incremental process person Evolutionary process For larger systems, it is doomed to failure Object-oriented software processes Uniform Approach (UA) … Sync & Save process (Microsoft) … 3 4 CISC 323, Winter 2004, SW Process CISC 323, Winter 2004, SW Process
✟ ✟ ✟ ✟ First explicit process (Royce, Waterfall Process Waterfall Process (Cont’d) 1970) For example , for Course Marks program, Requirements Requirements functional requirements are: Cascade of phases, carried Analysis Analysis • Students can specify course he/she is enrolled in and request grades for that out in fixed order with sign-off course of each, before proceeding to • The student’s grades recorded for that System and System and course will be displayed Software Design Software Design • … the next Implementation • Describes what software is Implementation supposed to do and Unit Testing and Unit Testing • Describes functional and non- Note that subprocesses for functional requirements (e.g., performance, usability, Integration and Integration and each phase left unspecified. availability) System Testing System Testing Free to choose. Could have, for • Typically expressed from user’s point of view instance, implementation • Defines what it means for the Operation and Operation and carried out in parallel software to work “properly” maintenance maintenance Original version, others exist 5 6 CISC 323, Winter 2004, SW Process CISC 323, Winter 2004, SW Process Waterfall Process (Cont’d) Waterfall Process (Cont’d) Does not describe aspects Requirements Requirements of the implementation, Analysis Analysis e.g., lower-level data structures, algorithms System and System and Software Design Software Design • Partitions system into Implementation Implementation hardware and software and Unit Testing and Unit Testing subsystems • Establishes overall system and software architecture • Realize design as a set of programs and program Integration and Integration and • Includes, e.g., component units (components). Includes: System Testing System Testing architecture, component • Choose implementation language interfaces, data model, high- • Design and implement data structures, level data structures and algorithms, procedures, etc Operation and Operation and algorithms, protocols (how • Check that individual code units (e.g., classes, maintenance maintenance components communicate with modules, packages) work properly (unit testing) each other) 7 8 CISC 323, Winter 2004, SW Process CISC 323, Winter 2004, SW Process
✡ ☛ ☛ ✠ ☞ ✠ ☛ ✠ ☞ ☛ ☛ ☛ ☛ Waterfall Process (Cont’d) Waterfall Process (Cont’d) Requirements Requirements • Software is delivered, installed and • Check that units work properly in Analysis Analysis possibly integrated into existing system conjunction with other units • Typically revisions are needed to (integration testing) address bugs, changed or new • Check that whole system works System and System and requirements properly (system testing) Software Design Software Design Implementation Implementation and Unit Testing and Unit Testing Integration and Integration and System Testing System Testing Operation and Operation and maintenance maintenance 9 10 CISC 323, Winter 2004, SW Process CISC 323, Winter 2004, SW Process Iterative Waterfall Process Weaknesses of Waterfall Process More realistic Consequences of design decisions may not be known Requirements Analysis After last phase, can until completion of the last phase revisit earlier phase May be costly to change early bad design decisions System and Still one phase at a time Design problems may just be “worked around” rather than fixed Software Design and cascade to next User may get badly designed system when done Changing requirements may render large parts of the Implementation development and the artifacts it yielded useless and Unit Testing Costly to change requirements User may not get what she really wanted Integration and System Testing Don’t use waterfall when Development team inexperienced, or Operation and Requirements likely to change (e.g., software is highly interactive, maintenance for inexperienced, undecided users, or uses new technology) Source: I. Sommerville. Software Engineering. 2001 11 12 CISC 323, Winter 2004, SW Process CISC 323, Winter 2004, SW Process
✏ ✑ ✏ ✎ ✑ ✒ ✑ ✍ ✑ ✍ ✒ ✌ ✒ ✌ ✑ ✌ ✌ ✏ Strengths of Waterfall Process The Importance of Being Right Early Easy to understand, follow, and manage The cost of fixing a problem increases Most widely used software development exponentially the earlier it was introduced process time introduced Reflects standard engineering practice Require Design Implem ments entation Use waterfall when Require 1 - - time detected development team experienced, and ments Design 2 1 - requirements very unlikely to change Impleme 5-15 2-10 1-5 ntation and test Source: Source: S. McConnell. Code Complete. 1993, R. Dunn. Software Defect Removal. 1984 13 14 CISC 323, Winter 2004, SW Process CISC 323, Winter 2004, SW Process The Power of Prototypes Prototyping Process Full development Goal : Get the requirements right as early as possible Initial Requirements Analysis preceded by Problem : and Design sequence of Customers often don’t exactly know what they want prototypes “Maybe that’s what I said, but it’s not what I meant!” Refine Use each prototype Requirements Build Prototype Solution : and/or Design to improve Show customer partial implementation of system that has requirements and/or relevant external interfaces and behaviour but not others Customer Evaluation design ( prototype ) Customers can refine their expectations and change their When customers Full Scale Development expectations without invalidating a complete development effort satisfied, move on to Final prototype forms basis of final product full development 15 16 CISC 323, Winter 2004, SW Process CISC 323, Winter 2004, SW Process
Recommend
More recommend
