1. CSC 205 - Software Engineering I 1 Overview - Software Lifecycles, Processes, Methods and Tools Software lifecycle basics Software lifecycles – build-and-fix – waterfall – rapid prototype – incremental – spiral Process improvement – CMM & ISO9000 Methods and Tools

2. CSC 205 - Software Engineering I 2 Software Lifecycle A series of steps through which a software product progresses Lifetimes vary from days to months to years Consists of – people! – overall process – intermediate products – stages of the process

3. CSC 205 - Software Engineering I 3 Software Production Personnel Client – individual or organization that wants a product to be developed Developer(s) – (members of) an organization producing the product User(s) – person who authorizes the client to contract the developer – person(s) who will utilize software in operation internal software development: client = developer contract software development: client ≠ developer

4. CSC 205 - Software Engineering I 4 What is a process? Device for producing a product (getting the job done!) Level of indirection – Process description describes wide class of instances Humans create process descriptions to solve classes of problems Thus – software processes are devices for creating and evolving software products

5. CSC 205 - Software Engineering I 5 Intermediate Software Products Objectives – Demarcate end of phases – Enable effective reviews – Specify requirements for next phase Form – Rigorous – Machine processible (highly desirable) Content – Specifications, Tests, Documentation

6. CSC 205 - Software Engineering I 6 Phases of a Software Lifecycle Standard Phases – Requirements Analysis & Specification – Design – Implementation and Integration – Operation and Maintenance – Change in Requirements – Testing throughout! Phases promotes manageability and provides organization

7. CSC 205 - Software Engineering I 7 Requirements Analysis and Specification Problem Definition —> Requirements Specification – determine exactly what client (and user) wants and process constraints – develop a contract with client – what task the product is to do Difficulties – client asks for wrong product – client is computer/software illiterate – specifications may be ambiguous, inconsistent, incomplete Validation – extensive specification reviews to check that requirements satisfies client needs – look for ambiguity, consistency, incompleteness – check for feasibility, testability – develop system/acceptance test plan

8. CSC 205 - Software Engineering I 8 Design Requirements Specification —> Design – develop architectural design (system structure): decompose software into modules with module interfaces – develop detailed design (module specifications): select algorithms and data structures – maintain record of design decisions and traeability – how the product is to do its task Difficulties – miscommunication between module designers – design may be inconsistent, incomplete, ambiguous Verification – extensive design reviews (inspections with checklists) to determine that design conforms to requirements – check module interactions – develop integration test plan

9. CSC 205 - Software Engineering I 9 Implementation and Integration Design —> Implementation – implement modules and verify they meet their specifications – combine modules according to architectural design – how the product does its task Difficulties – module interaction errors – order of integration has a critical influence on product quality and productivity Verification and Testing – extensive code reviews (inspections with checklists) to determine that implementation conforms to requirements and design – develop and test on unit/module test plan: focus on individual module functionality – test on integration test plan: focus on module interfaces – test on system test plan: focus on requirements and determine whether product as a whole functions correctly

10. CSC 205 - Software Engineering I 10 Operation and Maintenance Operation —> Change – maintain software after (and during) user operation – integral part of process – determine whether product as a whole still functions correctly Difficulties – design not extensible – lack of up-to-date documentation – personnel turnover Verification and Testing – extensive review to determine that change is made correctly and all documentation updated – test to determine that change is correctly implemented – test to determine that no inadvertent changes were made to compromise system functionality (check that no affected software has regressed)

11. CSC 205 - Software Engineering I 11 Build-and-Fix Build First Version Retirement Operations Mode Modify until Client is satisfied

12. CSC 205 - Software Engineering I 12 Waterfall (collapsed) - See Schach, pg. 66 Requirements Verify Retirement Operations Test Implementation Verify Design Req. Change

13. CSC 205 - Software Engineering I 13 Rapid Prototyping - See Schach, pg. 71 Rapid Prototype Verify Retirement Operations Test Implementation Verify Design Req. Change

14. CSC 205 - Software Engineering I 14 For each build: Perform detailed design, implement. Test. Deliver. Incremental - See Schach, pg. 73 Requirements Verify Retirement Operations Verify Arch. Design

15. CSC 205 - Software Engineering I 15 The Spiral Model [Boehm,1988]

16. CSC 205 - Software Engineering I 16 (Extremely) Simplified Spiral Model Requirements Verify Retirement Operations Test Implementation Verify Design Req. Change Add a Risk Analysis step to each phase! Risk Assessment

17. CSC 205 - Software Engineering I 17 CMM is not a software lifecycle model... but a strategy for improving the software process regardless of the process model followed – Basic premise: the use of new software methods alone will not improve productivity and quality, because software management is, in part, the cause of problems – CMM assists organizations in providing the infrastructure required for achieving a disciplined and mature process Includes – technical aspects of software production – managerial aspects of software production Capability Maturity Model (CMM) [Watts Humphrey,1989]

18. CSC 205 - Software Engineering I 18 Capability Maturity Model (continued) Five maturity levels – 1. initial – ad hoc process – 2. repeatable process – basic project management – 3. defined process – process modeling and definition – 4. managed process – process measurement – 5. optimizing process – process control and dynamic improvement to move from one stage to the next, the SEI provides a series of questionnaires and conducts process assessments that highlight current shortcomings

19. CSC 205 - Software Engineering I 19 ISO 9000 Further attempt to improve software quality based on International Standards Organization (ISO) ISO 9000 = series of five related standards – within ISO 9000 standard series ISO 9000-3 focuses on software and software development Basic features: – stress on documenting the process in both words and pictures – requires management commitment to quality – requires intensive training of workers – emphasizes measurement Adopted by over 60 countries (USA, Japan, European Union,...) To be ISO 9000 compliant, a company’s process must be certified

20. CSC 205 - Software Engineering I 20 Software Methods and Tools Methods provide a means or procedure for accomplishing a task Tools are devices for performing some task – analytical tools – software tools Methodology guides the proper use of methods and tools Process helps to enact a methodology Environments are a synergistic collection of tools with process support

21. CSC 205 - Software Engineering I 21 Analytical Tools Problem solving techniques that help in software development – cost-benefit analysis ¤ compare expected benefits against estimated costs – stepwise refinement ¤ divide and conquer – abstraction ¤ focus on some important property and ignore (for the time being) irrelevant details Analytical tools underlie many software development methods

22. CSC 205 - Software Engineering I 22 Software Tools Software tools are an automated implement for performing a task Tools facilitate work because they are – fast, immune to boredom and "cheating" Actual Software Tools are... – powerful, effective, convenient, natural, reliable, robust – Most software development tools are not ¤ exceptions: compilers, editors, loaders these have been polished, refined, and debugged through long-term use and hence made reliable and robust these have been made natural and effective through extended exposure and maintenance

23. CSC 205 - Software Engineering I 23 Tool Obstacles Tool use obstacles – developers tend to be like hammer and screwdriver carpenters – tools are not powerful and/or effective – tools are unreliable and/or unrobust ¤ comes with time and money – tools are inconvenient and/or unnatural ¤ comes from successful use Tool building obstacles – Short history of large-scale software development – Limited success in ¤ developing software well ¤ exploiting “tools” successfully – Few software techniques have had time and use required to achieve tool status – No “tools” at all in some key areas (e.g., real-time analysis)

24. CSC 205 - Software Engineering I 24 Requirements Preview Requirements determine the “What” of a software product’s functionality. Requirements analysis and specification transforms – informal product definition into – formal requirements specification A step in between is transforming the product definition into a natural language statement of the system’s functionality