CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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!

CSC x402 Requirements Engineering 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?

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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)

CSC x402 Requirements Engineering 11 Build-and-Fix Build First Version Retirement Operations Mode Modify until Client is satisfied

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

CSC x402 Requirements Engineering 13 Rapid Prototyping Rapid Prototype Verify Retirement Operations Test Implementation Verify Design Req. Change

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

CSC x402 Requirements Engineering 15 The Spiral Model [Boehm,1988]

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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]

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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)

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 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

CSC x402 Requirements Engineering 28 More Can be used, long after system in use, to define constraints for future changes