Chapter 2 · 2016-09-01 · Chapter 2 Software Processes Slide 9 Generic software process models The Waterfall Model –plan-driven model; separate and distinct phases of specification

Chapter 2 Software Processes Slide 1

Chapter 2

Software Processes


Topics covered

Software processes and process models

Generic models:

• Waterfall

• Incremental development

• Integration and configuration (reuse-oriented SE)

Basic process activities:

• Specification

• Development

• Validation (and Verification)

• Evolution

(cont'd)


Topics covered (cont’d)

Coping with change

Software prototyping: (with additional material)

• Uses of prototypes

• Classifying prototypes

• User Interface prototyping

(Mills’) Incremental Delivery (cf. incremental

development)

Boehm’s spiral model (bonus 1)

The Rational Unified Process (bonus 2)

Process improvement


Software processes and

process models


The software process

A process is a structured set of activities required to develop a software system.

Many different software processes, but all involve:• Specification – defining what the system should do;

• Design & implementation;

• Validation – checking that it does what the customer wants (and

Verification – checking that it does what is specified);

• Evolution – changing the system in response to changing customer needs.

A process MODEL is an abstract representation of a process. It presents a description of a process from some particular perspective

Models should be as simple as possible, but no simpler.– A. Einstein

[struhk-cherd] –adjective; having a

clearly defined structure or organization.


The software process

A process is a structured set of activities required to develop a software system.

Many different software processes, but all involve:• Specification – defining what the system should do;

• Design & implementation;

• Validation – checking that it does what the customer wants (and

Verification – checking that it does what is specified);

• Evolution – changing the system in response to changing customer needs.

A process MODEL is an abstract representation of a process. It presents a description of a process from some particular perspective

Models should be as simple as possible, but no simpler.– A. Einstein

[struhk-cherd] –adjective; having a

clearly defined structure or organization.


Plan-driven and agile processes

Plan-driven processes: all of the process activities

are planned in advance and progress is measured

against this plan.

Agile processes: planning is incremental and it is

easier to change the process to reflect changing

customer requirements.

In practice, most practical processes include

elements of both plan-driven and agile approaches.

There are no right or wrong software processes!


Generic models


Generic software process models

The Waterfall Model – plan-driven model; separate and

distinct phases of specification and development.

Incremental development – specification, development,

& validation are interleaved; may be plan-driven or agile.

Integration and Configuragion – e.g., “component-

based SE”: the system is assembled from existing reusable

components or systems; may be plan-driven or agile.

-----------------------------

In practice, most large systems are developed using a pro-

cess that incorporates elements from all of these models.

(And, at no additional cost: Boehm’s Spiral Model.)

not, in principle,

iterative


Waterfall model (W. Royce)

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

Note distinct and

separate phases


Waterfall model (cont’d)

Model is mostly used for:

• embedded systems, in which the software must interface with

relatively inflexible hardware, and its functionality is therefore

“frozen” prior to implementation,

• critical systems, for which complete specification and design

documents are needed for extensive safety and security

analysis, and

• large systems that may be part of broader hardware/software

engineering systems developed, perhaps independently, by

several companies or at different sites.

An important variant is formal system development (e.g.,

“Cleanroom” SE), which utilizes mathematical specification

and possibly formal correctness proofs.


Waterfall model problems

Inflexible partitioning of the project into distinct stages

makes it relatively difficult to respond to changing

customer requirements after the process is underway.

“The waterfall model is not the right process model in

situations where informal team communication is

possible and software requirements change quickly.

Iterative development and agile methods are better for

these systems.”


incremental development

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outline

description

Concurrent

activities

“…now the most common approach for the development of application systems and

software products”


incremental development advantages

1. Reduces cost of accommodating changing customer

requirements - amount of analysis and documentation that

has to be re-done is much less than is required with the waterfall

model.

2. Easier to get customer feedback - customers can

comment on demonstrations of the software and see how much

has been implemented. (This does not require deployment in

customer’s environment!)

3. Early delivery & deployment of useful software to the

customer is possible - customers may be able to use and

gain value from the software earlier than is possible with a

waterfall process. (Use in real, operational processes results in

more realistic feedback!)


incremental development problems

1. Lack of process visibility - lack of document deliverables to

measure progress. If systems are developed quickly, it is not cost-

effective to produce documents that reflect every version of the

system.

2. System structure tends to degrade as new increments are

added - unless time and money is spent on refactoring to improve

the software, regular change tends to corrupt its structure.

“Problems become particularly acute for large, complex, long-lifetime systems.

Large systems need a stable framework or architecture…(which) has to be

planned in advance rather than developed incrementally.”


Integration and configuration

Based on systematic (as opposed to informal, serendipi-

tous) reuse – approaches rely on existing components and an

integrating framework for their composition.

Types of software components reused:

• Stand-alone application systems that are configured/

adapted for use in a particular environment.

• Collections of objects that are developed as a component or

a package to be integrated within a component framework

such as the Java Spring framework.

• Web services that are developed according to service

standards and which are available for remote invocation.

(cont'd)


Reuse-oriented software engineering

(What’s available?

Can we live

without

some things?)

(initial/revised

proposal)

(if a suitable OTS

application system is

available)

(if NO suitable

OTS system is

available)Advantages and disadvantages of this

approach?


Basic process activities


Process activities

Real software processes are interleaved sequences

of technical, collaborative and managerial activities

with the overall goal of specifying, designing, imple-

menting and testing a software system, and are now

generally tool-supported.

The four basic process activities of specification,

development, validation (V&V), and evolution are

organized differently in different development

processes. In the waterfall model, they are organized

in sequence; in incremental development they are

interleaved.


Software specification / RE

The process of establishing what services are required

and the constraints on the system’s operation and

development.

Requirements Engineering (RE) process:

• Requirements elicitation and analysis

• Requirements specification (documentation)

• Requirements validation

New requirements come to light throughout the process,

so these activities are interleaved.

(cont'd)


The RE process


Software specification / RE (cont’d)

In agile methods, RE is not seen as a separate activity,

but as part of system development.

• Requirements are informally specified for each increment just

before that increment is developed.

• Requirements are elicited from users who are part of or work

closely with the development team, and are specified

according to user priorities.


Software design and implementation

The process of producing an executable system for

delivery to the customer.

Sometimes involves separate activities of design

and programming.

If an agile approach is used, the activities are

interleaved, with no formal design document

produced. Instead the design is recorded informally

on whiteboards and programmer’s notebooks…


Activities that may be used for

information systems

1. Architectural design: identify overall structure of system,

principal components (sometimes called sub-systems or

modules), their relationships, and how they are distributed.

2. Database (data structure) design: design system data

structures and how these are to be represented in a database.

3. Interface design: define the interfaces between system

components.

4. Component selection and design: search for reusable

components or, if necessary, design new ones.

How might this differ from a list of activities for real-time systems?


Activities that may be used for

information systems (cont’d)


Software design and implementation

(cont’d)

For critical systems, “Design outputs” are detailed

documents setting out precise and accurate descriptions

of the system.

• What form might these outputs take where agile methods are used?

Programming is usually an individual activity, and there is no

general process that is usually followed.

Programmers normally carry out some (“defect”) testing of the

code they produce, and use debugging techniques to locate

and correct the defects found.


Software validation (V&V)

Verification and Validation (V&V) determines whether or

not a system (1) conforms to its specification and (2)

meets the expectations of the customer.

Involves (human-based) checking processes (e.g.,

inspections/reviews, formal verification) and (machine-

based) program testing.

Program testing is the most commonly used V&V

activity and involves executing program elements with

test cases that are derived from analyzing specifications

and/or program logic.


A three-stage testing process

Component testing

• Individual components are tested independently;

• “Components” may be functions or objects or coherent

groupings of these entities.

System testing

• Testing of the system as a whole. Testing of emergent

properties is particularly important.

Customer (aka “alpha” or “beta”) testing

• Testing with customer data to check that the system

meets the customer’s needs/desires.


Testing phases in a plan-driven software

process (“V-model of development”)

Illustrates how test plans are the link between testing and development activities


Software evolution (“maintenance”)

Software is inherently flexible and subject to change.

As requirements change through changing

business/environmental circumstances, the software

must also evolve and change.

The distinction between development and evolution has

become increasingly irrelevant as fewer and fewer

systems are completely new.

Rather than two separate processes, it is more realistic to

think of software engineering as an evolutionary process

where software is continuously changed over its lifetime.

(cont'd)


Software evolution (“maintenance”)

Assess existing

systems

Define systemrequirements

Propose systemchanges

Modify

systems

Newsystem

Existing

systems

e.g., change

requests


Coping with change


Inevitability of change

Change is inevitable in all large software projects.

• Business/environmental changes lead to new and

changed system requirements.

• New technologies open up new possibilities for improving

implementations.

• Changing platforms require application changes.

Change costs include both re-work (redoing already

completed work -- e.g., re-analyzing requirements)

and the cost of implementing new functionality.


Reducing the costs of re-work

CHANGE ANTICIPATION (and therefore, avoidance): stimulate user/ stakeholder anticipation of their needs/

requirements before development begins.

• E.g., a prototype may allow users/stakeholders to better envi-

sion how the system would actually be used.

Change TOLERANCE: the development process and/or

product may be designed to reduce change effort/costs.

• If the system is developed incrementally, accommodating

changing customer requirements during development may be

less costly.

• Information hiding techniques (isolating potentially changeable

design decisions) may be employed in product design to reduce

costs after development.


Software prototyping

Coping with change (cont’d)


What is prototyping?

An iterative process emphasizing:

• Rapid development

• Concreteness and evaluative use (a “real system” is developed and presented to real users for hands-on evaluation)

• Consideration of alternatives

• Feedback

• Modification


General Prototyping process

Establishprototypeobjectives

Defineprototype

functionality

Developprototype

Evaluateprototype

Prototypingplan

Outlinedefinition

Executableprototype

Evaluationreport

What to include & what

NOT to include.


Uses of prototypes

Principal use is to help customers and

developers better understand system

requirements. ( change AVOIDANCE)

• Experimentation stimulates anticipation of how a

system could/may actually be used.

• Attempting to use functions together to

accomplish some (higher-level) task often

reveals subtle requirements problems.

(cont’d)


Uses of prototypes (cont’d)

Other potential uses:

1. Evaluating proposed solutions for feasibility

(=“Experimental Prototyping”)

2. Develop and evaluate User Interface designs

3. “Back-to-back testing”

4. Training users before system delivery

Prototyping is most often undertaken as a

risk reduction activity.


Classifying prototypes

By purpose:

• Throw-away prototyping – to elicit and validate

requirements

• Experimental prototyping – to evaluate proposed

solutions for feasibility, performance, etc.

horizontal vs. vertical (breadth vs. depth)

mockups vs. breadboards (form vs. function)

“Wizard of Oz” prototyping (Turing test reversed)


Throw-away prototyping

Outline

requirements

Develop

prototype

Evaluate

prototype

Specify

system

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusablecomponents

Elicit/validate REQMTS



By purpose:


requirements








By purpose:


requirements






F

i

d

e

l

i

t

y

Number of featuresfew many

low

highVertical prototype

Horizontal prototypepoints of

comparable effort



By purpose:


requirements







Quin Tech “Self-service check-in and

baggage drop-off design”

“The design was tested through a full-scale mock-up.”


Electronic circuit on a bread-

board (REUK.co.uk)

“There is no need to solder anything, and the components can be moved

around and the circuit modified thousands of times without damaging parts.”



By purpose:


requirements





“Wizard of Oz” prototyping (Turing test reversed?)


The Turing Test (Alan Turing, 1950)


The Wizard of Oz exposed…

“The truth is the Wizard was an illusion created by a man hidden behind a curtain.”


Prototyping versus simulation

What’s the difference between prototyping and

simulation?


Throw-away prototype delivery

Developers may be “pressurized” to deliver a throw-

away prototype as the final system.

This is problematic...

• It may be impossible to meet non-functional

requirements with the prototype.

• The prototype is almost certainly undocumented.

• The system (prototype) may be poorly structured

and therefore difficult to maintain.

• Normal organizational quality standards may not

have been applied.

?

Air Tank

Developer

User Mgmt

No, no, no! I won’t

deliver the prototype to

you!

“Pressurizing” the

Developer


Throw-away prototype delivery

Developers may be “pressurized” to deliver a throw-

away prototype as the final system.

This is problematic...

• It may be impossible to meet non-functional

requirements with the prototype.

• The prototype is almost certainly undocumented.

• The system (prototype) may be poorly structured

and therefore difficult to maintain.

• Normal organizational quality standards may not

have been applied.

?


Implementation techniques

Various techniques may be used to implement

prototypes:

• Dynamic, high-level languages (typeless, interpretive)

• Database programming (RAD / 4GLs)

• Component and application assembly

These are NOT mutually exclusive – they are

often used together.

Visual programming is also an inherent part of

most prototype development systems.


User interface prototyping

User interface development consumes an

increasing part of overall system develop-

ment costs.

It is usually impossible to pre-specify the look

and feel of a complex user interface in an

effective way. Thus, prototyping is essential.

(cont’d)


User interface prototyping (cont’d)

Aim is to allow users to gain direct experi-

ence with the interface.

Without this, it is almost impossible to judge

usability.

Often a two-stage process:

• paper prototypes are developed initially,

• followed by a series of increasingly sophis-

ticated automated prototypes.


Paper prototyping

Step through scenarios using sketches of the

interface.

Use storyboards to present a series of interactions

with the system.

Paper prototyping is a cost-effective way of obtaining

user reactions to an interface design proposal.


(Mills’) Incremental Delivery

(not to be confused with the

“incremental development”

generic model)

Coping with change (cont’d)


Incremental Delivery

Rather than deliver the system as a single unit, the

development and delivery is broken down into

increments, each of which incorporates part of the

required functionality.

User requirements are prioritized and the highest

priority requirements are included in early

increments.

Once the development of an increment is started, its

requirements are “frozen” while requirements for

later increments can continue to evolve.(Compromise between Waterfall & incremental development)

(cont’d)


Incremental Delivery (cont’d)


incremental development versus

Incremental Delivery

incremental development

• Incrementally develop the system in versions that are made

available for customer evaluation & feedback (but not

necessarily for actual work in the customer’s own environment)

before proceeding to the development of the next version;

• Normal approach used in agile methods (but may also be used

in plan-driven development);

• Evaluation undertaken by user/customer (or a proxy).

(Mills’) Incremental Delivery

• Deploy increments for actual work-place use by end-users;

• Permits more realistic evaluation of practical usefulness.


Advantages of Incremental Delivery

1. Early increments serve as (limited) prototypes and can

therefore assist in eliciting requirements for later

increments. Unlike real prototypes, they are part of the

real system, so there is no “relearning” when the complete

system is available.

2. Initial increments satisfy customers’ most critical require-

ments, so value is derived early.

3. Maintains the benefits of incremental development, so it

should be relatively easy to incorporate changes.

4. The highest priority system services tend to receive the

most testing. (They're subject to more “validation” steps.)


Potential problems with Incremental

Delivery

1. Problematic when the new system is intended to replace

an existing system. (Why?)

2. Many systems require a set of basic facilities that are used by

different parts of the system. But since requirements are not

defined in detail until an increment is to be implemented, it can

be hard to identify common facilities that are needed by all

increments to be useful.

3. The essence of an iterative process is that the specification is

developed in conjunction with the software. But this conflicts

with the procurement model of many organizations, where

the complete specification is part of the system development

contract (also a problem with incremental development).

(cont'd)


Potential problems with Incremental

Delivery (cont’d)

Also, requirements may NOT be partitionable into

usable, stand-alone increments.

(Can you think of any such systems?)


Spiral development model


Boehm’s spiral development model

Process is represented as a spiral rather than a

sequence of activities.

Each loop in the spiral represents a phase in the

process.

No fixed phases such as specification or design

– loops in the spiral are chosen depending on

what is required.

Explicitly incorporates risk assessment and

resolution throughout the process.

(cont'd)





Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


Spiral model quadrants

Objective Setting – specific objectives for the phase are

identified. Project risks and alternative strategies are identified.

Risk Assessment and Reduction – risks are assessed

and activities put in place to reduce the key risks.

Development and Validation – a development model

for the system is chosen which can be any of the generic

models.

Planning – the project is reviewed and the next phase of the

spiral is planned.


Spiral model usage

The model has been very influential in

helping people think about iteration in

software processes and introducing the risk-

driven approach to development.

In practice, however, the model is rarely used

as published for practical software develop-

ment.


RUP


The Rational Unified Process

A modern process model derived from the work on

the UML and its associated process.

A hybrid process model that brings together aspects

of the generic process models discussed previ-

ously…it represents a new generation of generic

processes.

Normally described from 3 perspectives

• A dynamic perspective that shows phases over time;

• A static perspective that shows process activities;

• A practice perspective that suggests good practices.


RUP phase model

Phase iteration

Inception Elaboration Construction Trans ition

cf. Waterfall Model: RUP phases are more closely

related to business rather than technical concerns.

“in-phase iteration” “cross-phase iteration”


RUP phases

Inception

• Establish the business case for the system.

Elaboration

• Develop an understanding of the problem domain and the

system architecture.

Construction

• System design, programming and testing.

Transition

• Deploy the system in its operating environment.


Static workflows (process activities) in RUP

Workflow Description

Business modelling The business processes are modelled using business

use cases.

Requirements Actors who interact with the system are identified and

use cases are developed to model the system

requirements.

Analysis and design A design model is created and documented using

architectural models, component models, object

models and sequence models.

Implementation The components in the system are implemented and

structured into implementation sub-systems.

Automatic code generation from design models helps

accelerate this process.


RUP “good practices”

Develop software iteratively: plan increments

based on customer priorities and deliver highest

priority increments first.

Manage requirements: explicitly document and

keep track of changes.

Use component-based architectures: organize

system architecture as a set of reusable

components.

(cont'd)


RUP “good practices” (cont’d)

Visually model software: using graphical UML

models to present static and dynamic views.

Verify software quality: ensure software meets

organizational quality standards.

Control changes to software: using change

management system and configuration management

tools.


Many software companies have turned to software

process improvement as a way of enhancing the

quality of their software, reducing costs, or

accelerating their development processes.

Process improvement means understanding existing

processes and introducing changes in an effort to

achieve these goals.

Process improvement


Two approaches to improvement

1. The process maturity approach, which focuses on

improving process and project management and

introducing good software engineering practice.

• Rooted in plan-driven development… The level of process

maturity reflects the extent to which good technical and

management practice has been adopted in organizational

software development processes.

• Usually requires increased “overhead” in the sense that

activities are introduced that are not directly relevant to

program development.

(cont’d)


Two approaches to improvement

(cont’d)

2. The agile approach, which focuses on iterative

development and the reduction of overhead in the

software process.

• The primary characteristics of agile methods are rapid

delivery of functionality and responsiveness to changing

customer requirements.

• Improvement philosophy is that the best processes are

those with the lowest overhead.

• Agile approaches focus on the code being developed and

deliberately minimize formality and documentation.


Process maturity approach: the

process improvement cycle


Process measurement

• Attributes of the current process are measured. (Provides a baseline for assessing improve-ments.)

Process analysis

• Bottlenecks and weaknesses are identified.

• Changes aimed at improving measures are identified.

Process change

• Changes are introduced.

Process maturity approach: the

process improvement cycle (cont’d)


The CMMI process improvement

framework

Reflects the current stage of work on process

assessment and improvement that started at the

DoD-funded Software Engineering Institute (SEI) in

the 1980s.

It has had a profound influence on process improve-

ment.

• Capability Maturity Model (CMM) introduced in early ‘90s

• Revised maturity framework (CMMI) introduced in 2001.

The SEI’s broader mission is to promote software

technology transfer, particularly to US defense

contractors.


Recent SEI announcement re CMMI

“As part of its mission to transition mature technology to the

software community, the SEI has transferred CMMI-related

products and activities to the CMMI Institute, a 100%-controlled

subsidiary of Carnegie Innovations, Carnegie Mellon University’s

technology commercialization enterprise. The CMMI Institute will

conduct CMMI training and certification, sponsor conferences

and classes, and provide information about CMMI process

improvement models and appraisals.

The SEI will continue to pioneer and advance new research in

the field of software process management. More information

about our current work is available at

http://www.sei.cmu.edu/process.”

http://www.sei.cmu.edu/process


Process capability assessment

Intended as a means to assess the extent to which

an organization’s processes follow best practice.

This makes it possible to identify areas of weakness

in support of process improvement.

There have been various process assessment and

improvement models (e.g., SPICE, BOOT-STRAP)

but the SEI’s work has been the most influential.


The current (CMMI) model

An integrated capability model that includes

software and systems engineering capability

assessment.

The model has two instantiations:

• Staged: the model is expressed in terms of five

capability levels

• Continuous: a range of capability ratings are computed


CMMI model components

22 process areas relevant to process capability

and improvement are identified. These are

organized into 4 groups (“categories”):

• Process management

• Project management

• Engineering

• Support

(cont’d)


Process areas in the CMMI

Category Process area

Process management Organizational process definition (OPD)

Organizational process focus (OPF)

Organizational training (OT)

Organizational process performance

(OPP)

Organizational innovation and

deployment (OID)

Project management Project planning (PP)

Project monitoring and control (PMC)

Supplier agreement management (SAM)

Integrated project management (IPM)

Risk management (RSKM)

Quantitative project management (QPM)


Process areas in the CMMI (cont’d)

Category Process area

Engineering Requirements management (REQM)

Requirements development (RD)

Technical solution (TS)

Product integration (PI)

Verification (VER)

Validation (VAL)

Support Configuration management (CM)

Process and product quality management (PPQA)

Measurement and analysis (MA)

Decision analysis and resolution (DAR)

Causal analysis and resolution (CAR)


CMMI model components (cont’d)

Each process area has associated goals (desirable

organizational states) and (advisory) practices

(recommended ways to achieve a goal).


Examples of goals and associated

practices

GoalAssociated practices

The requirements are analyzed

and validated, and a definition of

the required functionality is

developed.

Analyze derived requirements systematically to ensure

that they are necessary and sufficient.

Validate requirements to ensure that the resulting

product will perform as intended in the user’s

environment, using multiple techniques as appropriate.

Root causes of defects and other

problems are systematically

determined.

Select the critical defects and other problems for

analysis.

Perform causal analysis of selected defects and other

problems and propose actions to address them.

The process is institutionalized as

a defined process.

Establish and maintain an organizational policy for

planning and performing the requirements development

process.

for REQM process area


CMMI Assessment scale

Examines the processes used in an organization and

assesses the level of maturity in each area.

Based on a 6-point scale:

0. Not performed

1. Performed

2. Managed

3. Defined

4. Quantitatively managed

5. Optimizing


Level 3

Defined

Level 2

Managed

Level 1

Initial

Level 4

Quantitativelymanaged

Level 5

Optimizing

The staged CMMI model

Comparable to the 5-level Software CMM.

"Repeatable" in CMM

"Managed" in CMM

(cont’d)



(cont’d)



(cont’d)

Each maturity level has process areas and goals.

For example, the process areas associated with Level 2 (“Managed”) include:

• Requirements management (REQM)

• Project planning (PP)

• Project monitoring and control (PMC)

• Supplier agreement management (SAM)

• Measurement and analysis (MA)

• Process and product quality management (PPQA)

(cont’d)



(cont’d)

In addition, organizations operating at the “Managed Level” should have institutionalized practices that are geared to standardization.

• Establish and maintain a policy for performing the project planning process;

• Provide adequate resources for performing the project management process;

• Monitor and control the project planning process;

• Review the activities, status, and results of the project planning process.


The continuous CMMI model

A finer-grain model that considers individual or groups

of practices and assesses their use.

The maturity assessment is NOT a single value but a

set of “capability values” (based on the 6-point

“capability level” scale described earlier) in each area.

The advantage of a continuous approach is that

organizations can pick and choose process areas

to improve according to their local needs.


A process capability profile

0

Project monitoring

and control

Supplier agreement

management

Risk management

Configuration

management

Requirements

management

Verification

Validation

1 2 3 4 5


Key points

Software processes are the activities involved

in producing and evolving a software system.

They are represented abstractly by software

process models.

Generic models are very general and represent

different approaches to development.

Examples are the waterfall model, incremental

development, and integration and configuration

(reuse-oriented SE)

(cont'd)


Key points (cont’d)

Requirements engineering is the process of establishing what services are required and the constraints on the system’s operation and development.

Design and implementation processes produce an executable system based on the specification.

V&V involves checking that the system meets its specification and satisfies user needs.

Evolution is concerned with modifying the system after it is placed in use. Software must evolve to remain useful.

(cont'd)



Processes should include activities to cope with

change. This may involve a prototyping phase

that helps avoid poor decisions on requirements

and design.

Throw-away prototyping is used to explore

requirements and design options.

Rapid development of prototypes is essential.

This usually requires leaving out functionality or

relaxing non-functional constraints.

(cont'd)



Prototyping may be essential for parts of the

system such as the user interface which cannot

be effectively pre-specified.

Users must be involved in prototype evaluation.

The Rational Unified Process is a modern

generic process model that is organized into

phases (inception, elaboration, construction and

transition) but separates activities (requirements,

analysis and design, etc.) from these phases.


Chapter 2

Software Processes

Documents

Chapter 2 · 2016-09-01 · Chapter 2 Software Processes Slide 9 Generic software process models The Waterfall Model –plan-driven model; separate and distinct phases of specification