cse 470 : software engineering the software process

34
CSE 470 : Software Engineering The Software Process

Upload: kayleigh-boykin

Post on 15-Jan-2016

232 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: CSE 470 : Software Engineering The Software Process

CSE 470 : Software Engineering

The Software Process

Page 2: CSE 470 : Software Engineering The Software Process

2

What is a Process?

We can think of a series of activities as a process

Any process has the following characteristics It prescribes all of the major activities It uses resources and produces intermediate and final

products It may include sub-processes and has entry and exit

criteria The activities are organized in a sequence Constraints or control may apply to activities

(budget control, availability of resources )

Page 3: CSE 470 : Software Engineering The Software Process

3

Software Processes

Coherent sets of activities for Specifying, Designing, Implementing and Testing software systems

When the process involves the building of some product, we refer to the process as a life cycle

Software development process – software life cycle

Page 4: CSE 470 : Software Engineering The Software Process

4

The Software Process

A structured set of activities required to develop a software system Specification Design Validation Evolution

Fundamental Assumptions: Good processes lead to good software

Good processes reduce risk

Page 5: CSE 470 : Software Engineering The Software Process

5

Generic software process models

The waterfall model Separate and distinct phases of specification and

development

Evolutionary development Specification and development are interleaved

Formal systems development A mathematical system model is formally transformed

to an implementation

Reuse-based development The system is assembled from existing components

Page 6: CSE 470 : Software Engineering The Software Process

6

The SEI Process Models

The SEI CMMIs are the best-known process models for software engineering

SEI: Software Engineering InstituteCMMI: Capability Maturity Models

IntegratedSee:

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

Page 7: CSE 470 : Software Engineering The Software Process

7

The Waterfall Model

RequirementsDefinition

System andSoftware design

Programmingand Unit Testing

Integration andSystem Testing

Operation andMaintenance

Page 8: CSE 470 : Software Engineering The Software Process

8

Requirements Analysis and Definition

The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff.

This phase can be divided into:

Feasibility study (often carried out separately)

Requirements analysis

Requirements definition

Requirements specification

Page 9: CSE 470 : Software Engineering The Software Process

9

System and Software Design

System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture

Software design: Represent the software system functions in a form that can be transformed into one or more executable programs

Unified Modeling Language (UML)

Page 10: CSE 470 : Software Engineering The Software Process

10

Programming and Unit Testing

The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.)

Individual components are tested against specifications.

Page 11: CSE 470 : Software Engineering The Software Process

11

Integration and System Testing

The individual program units are:

integrated and tested as a complete system

tested against the requirements as specified

delivered to the client

Page 12: CSE 470 : Software Engineering The Software Process

12

Operation and Maintenance

Operation: The system is put into practical use.

Maintenance: Errors and problems are identified and fixed.

Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.

Phase out: The system is withdrawn from service.

Page 13: CSE 470 : Software Engineering The Software Process

13

Advantages of the Waterfall Approach

Develop requirements before designDesign before writing codeWrite code before integrating itTest programs after integrating themHave milestone reviews

Page 14: CSE 470 : Software Engineering The Software Process

14

The Waterfall Approach

The Waterfall Model requires that we (attempt to): specify the requirements completely, consistently,

correctly, and unambiguously on the first attempt design the software completely and correctly on the first

attempt write all of the software interfaces and internal details

correctly on the first attempt integrate the components in one large step do system testing and acceptance testing at the end

The linear waterfall model is a one-pass process

Page 15: CSE 470 : Software Engineering The Software Process

15

Some Realities of Software Development

1. Requirements always change because of: changing customer desires and user needs initial requirements analysis inadequate understandings and insights gained through experience changing technology changing competitive situation personnel turnover: engineering, management, marketing,

customer

2. The design is never right the first time design is a creative, problem solving process

3. Frequent demonstrations of progress and early warning of problems are desirable

Page 16: CSE 470 : Software Engineering The Software Process

16

Discussion of the Waterfall Model

Advantages:-Identifies systems requirements long before programming begins.- Only appropriate when the requirements are well-understood

Disadvantages:

-Takes long time to deliver since developing requirements.

- Difficult to adapt to changing requirements

- Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised.

Page 17: CSE 470 : Software Engineering The Software Process

17

Relative Cost to Fix a Software Defect

Page 18: CSE 470 : Software Engineering The Software Process

18

Feedback in the Waterfall Model

RequirementsDefinition

System andSoftware design

Programmingand Unit Testing

Integration andSystem Testing

Operation andMaintenance

Page 19: CSE 470 : Software Engineering The Software Process

19

Evolutionary development

Exploratory development

- Objective is to work with customers and to evolve a final system from an initial outline specification.

- The system evolves by adding new features as they are proposed by customer.

Page 20: CSE 470 : Software Engineering The Software Process

20

Evolutionary development

Rapid prototyping Objective is to understand the system requirements.

Develop “quick and dirty” system in short time; Expose to user comment & feedback; Refine; Repeat until adequate system developed.

Particularly suitable where:- detailed requirements not possible;- powerful development tools (CASE) available

Page 21: CSE 470 : Software Engineering The Software Process

21

Evolutionary development

OutlineDescription

ConcurrentActivities

Requirements

Design

Implementation

InitialVersion

IntermediateVersions

FinalVersion

Page 22: CSE 470 : Software Engineering The Software Process

22

Evolutionary development

Requirements

DesignImplementation

(prototype)

Evaluation

Page 23: CSE 470 : Software Engineering The Software Process

23

Evolutionary development

Problems Lack of process visibility Systems are often poorly structured Special skills (e.g. in languages for rapid

prototyping) may be requiredApplicability

For small or medium-size interactive systems For parts of large systems (e.g. the user

interface)

Page 24: CSE 470 : Software Engineering The Software Process

24

Process iteration

• Modern development processes take iteration as a fundamental concept.

•System requirements ALWAYS evolve during the course of a project; so process iteration where earlier stages are reworked is always part of the process for large systems.

•Iteration can be applied to any of the generic process models.

•Two (related) approaches:• Incremental development• Spiral development

Page 25: CSE 470 : Software Engineering The Software Process

25

Incremental development

System is not a single delivery; the development and delivery broken down into increments delivering 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,the requirements are frozen though requirementsfor later increments can continue to evolve.

Page 26: CSE 470 : Software Engineering The Software Process

26

Incremental development

Valida teincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Valida tesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

Page 27: CSE 470 : Software Engineering The Software Process

27

The Incremental Model

Page 28: CSE 470 : Software Engineering The Software Process

28

Incremental development advantages

Customer value can be delivered with each increment so system functionality is available earlier.

Early increments act as a prototype to help elicit requirements for later increments

Lower risk of overall project failure

The highest priority system services tend to receive the most testing

Page 29: CSE 470 : Software Engineering The Software Process

29

Incremental development problems

The process is not visible. o Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.

System structure tends to degrade as new increments are added.

o Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.

Page 30: CSE 470 : Software Engineering The Software Process

30

Spiral Model

The spiral model is a risk-driven process model generator for software projects. Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping.

This model was first described by Barry Boehm in his 1986 paper "A Spiral Model of Software Development and Enhancement".

Page 31: CSE 470 : Software Engineering The Software Process

31

Spiral development

Process is represented as a spiral rather than as a sequence of activities with backtracking.

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.

Risks are explicitly assessed and resolved throughout the process.

Page 32: CSE 470 : Software Engineering The Software Process

32

Spiral model of the software process

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit 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

Page 33: CSE 470 : Software Engineering The Software Process

33

Spiral model sectors

Objective setting • Specific objectives for the phase are identified

Risk assessment and reduction • Risks are assessed and activities put in place to reduce 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 next phase of the spiral is planned

Page 34: CSE 470 : Software Engineering The Software Process

34

Spiral model usage

Spiral 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 development.