CSC 205 - Software Engineering I 1 Overview - Software Lifecycles, Processes, Methods and Tools Software lifecycle basics Software lifecycles – build-and-fix

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

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: client = developer• contract software development: client ≠ developer


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

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 promotes manageability and provides 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– 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

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

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 FirstVersion

Retirement

Operations Mode

Modify untilClient is satisfied


12

Waterfall (collapsed) - See Schach, pg. 66

Requirements

Verify

Retirement

Operations

Test

ImplementationVerify

Design

Req. Change


13

Rapid Prototyping - See Schach, pg. 71

Rapid Prototype

Verify

Retirement

Operations

Test


Design

Req. Change


14

For each build:Perform detaileddesign, implement.Test. Deliver.

Incremental - See Schach, pg. 73

Requirements

Verify

Retirement

Operations

Verify

Arch. Design


15

The Spiral Model [Boehm,1988]

Concept of Operation

Requirements Plan

Requirements OAC

Risk Assessment

Risk It

em Set

Risk M

anag

emen

t Plan

Requirements

Risk Control

Requirements Validation

Abstract Specification Plan

Abstract Specifcation OAC

Risk Assessment

Risk Control

Abstract Specification

Abstract Specification Validation

Concrete Specification Plan

Concrete Specification OAC

Concrete Specification

Concrete Specification Validation and Verification

Software Development Plan

Risk Assessment

Risk Control

Progress through steps

Cumulative cost

Evaluate alternatives, identify, resolve risks

Develop, verify next-level product

Plan next phases

CommitReview

partition

Determine objectives, alternatives, constraints (OAC)


16

(Extremely) Simplified Spiral Model

Requirements

Verify

Retirement

Operations

Test


Design

Req. Change

Add a Risk Analysisstep to each phase!

Risk Assessment

Risk Assessment

Risk Assessment


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

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 Preview

• Requirements determine the “What” of a software product’s functionality.

• Requirements analysis and specification transforms– informal product definitioninto– formal requirements specification

• A step in between is transforming the product definition into a natural language statement of the system’s functionality

Documents

CSC 205 - Software Engineering I 1 Overview - Software Lifecycles, Processes, Methods and Tools Software lifecycle basics Software lifecycles – build-and-fix