Overview - Software Lifecycles, Processes, Methods and Tools

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. 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. 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 vs external contract • and all the shades of gray!

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 • work for you?

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. Phases of a Software Lifecycle • Standard Phases • Requirements Analysis & Specification • Design • Implementation and Integration • Operation and Maintenance • Change in Requirements • Testing throughout • Phases promote manageability and provide organization

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 or developer “knows better” (want vs need) • client is computer/software illiterate or developer domain illiterate • specifications may be ambiguous, inconsistent, incomplete • Validation • extensive specification reviews check that requirements satisfy client wants • look for ambiguity, consistency, incompleteness • check for feasibility, testability • develop system/acceptance test plan

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 traceability • 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. 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. 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. Build-and-Fix Build First Version Modify until Client is satisfied Operations Mode Retirement

12. Requirements Verify Design Verify Implementation Test Waterfall Req. Change Operations Retirement

13. Rapid Prototype Verify Design Verify Implementation Test Rapid Prototyping Req. Change Operations Retirement

14. Requirements Verify Arch. Design Verify Incremental For each build: Perform detailed design, implement. Test. Deliver. Operations Retirement

15. The Spiral Model [Boehm,1988]

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

17. Capability Maturity Model (CMM) [Watts Humphrey,1989] • 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

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. 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. 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. 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. 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. 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. Requirements Focus • Requirements determine the “What” of a software product’s functionality. (See Jackson!) • 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

25. What about Reality? • Is a rational process of software development possible? (desirable?) • Parnas: No! We should fake it, though • people don’t know what they want • don’t know everything at outset, backtracking inevitable • human beings not good at big, complex problems • changes occur in the environment (out of our control) • human errors only avoidable if we avoid the use of humans • can we? • preconceive, pet design ideas • reuse and other economic factors • Rank order these along different dimensions

26. What does the sincere developer do? • Fake the rational process - • designers need guidance - helps us proceed • better than ad hoc - we can at least aim high • organizational advantages to standard procedure • reviews, transfer workers, ideas and software • if we agree on an ideal process, we can measure progress along that dimension • external reviews made possible and useful

27. Why have a Requirements Document? • Record desired behavior of system • that user or customer can review • Avoid making customer decisions by programming! • Avoid duplication and inconsistency • many would argue, the requirements doc can answer questions • A complete requirements doc is necessary to make good estimates (not sufficient though!) • Valuable insurance against staff turnover • Test plan development

28. More • Can be used, long after system in use, to define constraints for future changes