15. Software Life Cycle

wakecabbagepatchΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

146 εμφανίσεις

Using UML, Patterns, and Java

Object
-
Oriented Software Engineering

15. Software Life Cycle

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




2

Outline


Software Life Cycle


Waterfall model and its problems


Pure Waterfall Model


V
-
Model


Iterative process models


Boehm’s Spiral Model

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




3

Inherent Problems with Software Development


Requirements are complex


The client does not know the functional requirements in advance


Requirements may be changing


Technology enablers introduce new possibilities to deal with
nonfunctional requirements


Frequent changes are difficult to manage


Identifying milestones and cost estimation is difficult


There is more than one software system


New system must be backward compatible with existing system
(“legacy system”)


Phased development: Need to distinguish between the system
under development and already released systems


Let’s view these problems as the nonfunctional requirements
for a system that supports software development!


This leads us to software life cycle modeling

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




4

Definitions


Software lifecycle modeling: Attempt to deal with complexity
and change



Software lifecycle:


Set of activities and their relationships to each other to support the
development of a software system



Software development methodology:


A collection of techniques for building models
-

applied across the
software lifecycle

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




5

Software Life Cycle


Software construction goes through a progression of states

Development

Post
-

Development

Pre
-

Development

Conception

Childhood

Adulthood

Retirement

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




6

Typical Software Lifecycle Questions


Which activities should I select for the software
project?


What are the dependencies between activities?


Does system design depend on analysis? Does
analysis depend on design?


How should I schedule the activities?


Should analysis precede design?


Can analysis and design be done in parallel?


Should they be done iteratively?

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






7

Identifying Software Development Activities


For finding activities and dependencies we can use the same
modeling techniques when modeling a system such as creating
scenarios, use case models, object identification, drawing class
diagrams, activity diagrams


Questions to ask:


What is the problem?


What is the solution?


What are the mechanisms that best implement the solution?


How is the solution constructed?



Is the problem solved?


Can the customer use the solution?


How do we deal with changes that occur during the development?
Are enhancements needed?



Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




8

Possible Identification of Software Development Activities

Requirements Analysis

What is the problem?

System Design

What is the solution?

Program Design

What are the mechanisms

that best implement the

solution?

Program Implementation

How is the solution

constructed?

Testing

Is the problem solved?

Delivery

Can the customer use the solution?

Maintenance

Are enhancements needed?

Problem

Domain

Implementation

Domain

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




9

Software Development as Application Domain: A Use
Case Model

<<include>>
<<include>>
<<include>>
Client
End user
Developer
Project manager
Software development
System development
Problem definition
System operation
Administrator
Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




10

IEEE Std 1074: Standard for Software
Lifecycle

IEEE Std 1074

Project

Management

Pre
-

Development

Development

Post
-

Development

Cross
-

Development

(Integral Processes)

> Project Initiation

>Project Monitoring


&Control

> Software Quality


Management

> Concept


Exploration

> System


Allocation

> Requirements


Analysis

> Design

> Implementation

> Installation

> Operation &


Support

> Maintenance

> Retirement

> V & V

> Configuration


Management

> Documentation

> Training

Process

Group

Processes

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




11

Processes, Activities
,

and Tasks


Process Group: Consists of Set of Processes


Process: Consists of Activities


Activity: Consists of sub activities and tasks

Process

Group

Process

Activity

Development

Design

Task

Design

Database

Make a

Purchase

Recommendation

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




12

Example


The Design Process is part of
Development


The
Design Process
consists of the following
Activities


Perform Architectural Design


Design Database (If Applicable)


Design Interfaces


Select or Develop Algorithms (If Applicable)


Perform Detailed Design (= Object Design)


The
Design Database

Activity has the following Tasks


Review Relational Databases


Review Object
-
Oriented Databases


Make a Purchase recommendation


....

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






13


Many models have been proposed to deal with the
problems of defining activities and associating them with
each other


The first model proposed was the
waterfall model

[Royce 1970]

Life Cycle Modeling

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




14


Many models have been proposed to deal with the problems of
defining activities and associating them with each other


The waterfall model


First described by Royce in 1970


There seem to be at least as many versions as there are
authorities
-

perhaps more

Life
-
Cycle Model: Variations on a Theme

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






15



Requirements

Process

System

Allocation

Process

Concept

Exploration

Process

Design

Process

Implementation

Process

Installation

Process

Operation &

Support Process

Verification

& Validation

Process

The Waterfall Model of
the Software Life
Cycle

adapted from [Royce 1970]

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




16

Problems with Waterfall Model


Managers love waterfall models:


Nice milestones


No need to look back (linear system), one activity at a time


Easy to check progress : 90% coded, 20% tested


V
-
Model


Software development is iterative


During design problems with requirements are identified


During coding, design and requirement problems are found


During testing, coding, design& requirement errors are found


=> Spiral Model

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






17



From the Waterfall Model to the V Model


System Design

Requirements

Analysis

Requirements

Engineering


Object Design

Integration
Testing

System

Testing

Unit


Testing

Implementation

System

Testing

Unit


Testing

Integration


Testing

Acceptance

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






18

Activity Diagram of a V Model

System
Requirements
Analysis
Implementation
Preliminary
Design
Detailed
Design
Software
Requirements
Elicitation
Operation
Client
Acceptance
Requirements
Analysis
Unit
Test
System
Integration
& Test
Component
Integration
& Test
precedes

Is validated by

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






19

Properties of Waterfall
-
based Models


Managers love waterfall models:


Nice milestones


No need to look back (linear system)


Always one activity at a time


Easy to check progress during development: 90% coded,
20% tested


However, software development is nonlinear


While a design is being developed, problems with
requirements are identified


While a program is being coded, design and requirement
problems are found


While a program is tested, coding errors, design errors and
requirement errors are found


Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




20


The spiral model proposed by Boehm is an iterative model with
the following activities


Determine objectives and constraints


Evaluate Alternatives


Identify risks


Resolve risks by assigning priorities to risks


Develop a series of prototypes for the identified risks starting with
the highest risk.


Use a waterfall model for each prototype development (“cycle”)


If a risk has successfully been resolved, evaluate the results of the
“cycle” and plan the next round


If a certain risk cannot be resolved, terminate the project
immediately


Spiral Model (Boehm) Deals with Iteration

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






21

Spiral Model

Deter
mine object iv
es
,
alt er
nat iv
es
, & constr
aints
Ev
aluat e alt er
nat iv
es
,
ident if y & resolv
e r
isks
De
v
elop & v
er
if y
ne
xt le
v
el product
Plan ne
xt phase
Requirements
Development
Integration
plan
plan
plan
Requirements
Design
validation
validation
Software
System
Product
Risk
analy sis
Risk
analy sis
Prototype1
Prototype2
Prototype3
Risk
analy sis
Concept of
operation
Requirements
Design
Code
Unit T
est
Integration &
T
est
Acceptance
Detailed
Design
P1
P2
T
est
Project P1

Project P2

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






22

Types of Prototypes


Illustrative Prototype

(
Revolutionary Prototyping
)


Develop the user interface with a set of storyboards


Implement them on a napkin or with a user interface builder
(Visual C++, ....)


Good for first dialog with client


Functional Prototype

(
Evolutionary Prototyping
)


Implement and deliver an operational system with minimum
functionality


Then add more functionality


Order identified by risk


Exploratory Prototype ("Hacking")


Implement part of the system to learn more about the
requirements.

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




23

Process Maturity


A software development process is mature



if the development activities are well defined and



if management has some control over the quality, budget and
schedule of the project


Process maturity is described with



a set of maturity levels and



the associated measurements (metrics) to manage the process


Assumption:



With increasing maturity the risk of project failure decreases

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




24

Capability maturity levels

1. Initial Level


also called ad hoc or chaotic

2. Repeatable Level



Process depends on individuals ("champions")

3. Defined Level



Process is institutionalized (sanctioned by management)

4. Managed Level


Activities are measured and provide feedback for resource
allocation (process itself does not change)

5. Optimizing Level


Process allows feedback of information to change process itself

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






25

Maturity Level 1: Chaotic Process


Ad hoc approach to software
development activities


No problem statement or
requirements specification


Output is expected


but nobody knows how to
get there in a deterministic
fashion


Similar projects may vary
widely in productivity


"when we did it last year we
got it done"


Level 1 Metrics:

Rate of
Productivity (Baseline
comparisons, Collection of data
is difficult)


Product size (LOC, number
of functions, etc)


Staff effort (“Man
-
years”,
person
-
months)


Recommendation:

Level 1
managers & developers should
not concentrate on metrics and
their meanings,


They should first attempt to
adopt a process model
(waterfall, spiral model, saw
-
tooth, macro/micro process
lifecycle, unified process)

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






26

Maturity Level 2: Repeatable Process


Inputs and outputs are defined


Input: Problem statement or
requirements specification


Output: Source code


Process itself is a black box (
activities within process are not
known)


No intermediate products are
visible


No intermediate deliverables


Process is repeatable due to
some individuals who know
how to do it


"Champion"


Level 2 Metrics:



Software size: Lines of code,
Function points, classes or
method counts


Personnel efforts: person
-
months


Technical expertise


Experience with
application domain


Design experience


Tools & Method
experience


Employee turnover within
project

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






27

Maturity Level 3: Defined Process


Activities of software
development process are well
defined with clear entry and exit
conditions.


Intermediate products of
development are well defined
and visible


Level 3 Metrics

(in addition to
metrics from lower maturity
levels):


Requirements complexity:
Number of classes, methods,
interfaces


Design complexity: Number
of subsystems, concurrency,
platforms


Implementation complexity:
Number of code modules,
code complexity


Testing complexity: Number
of paths to test, number of
class interfaces to test


Thoroughness of Testing:


Requirements defects
discovered


Design defects
discovered


Code defects discovered


Failure density per unit
(subsystem, code
module, class

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






28

Maturity Level 4: Managed Process


Uses information from early
project activities to set priorities for
later project activities (intra
-
project
feedback)


The feedback determines how
and in what order resources are
deployed


Effects of changes in one activity
can be tracked in the others


Level 4 Metrics
:


Number of iterations per activity


Code reuse: Amount of
producer reuse (time
designated for reuse for future
projects?)


Amount of component reuse
(reuse of components from
other projects and components)


Defect identification:


How and when (which
review) are defects
discovered?


Defect density:


When is testing complete?


Configuration management:


Is it used during the
development process? (Has
impact on tractability of
changes).


Module completion time:



Rate at which modules are
completed (Slow rate
indicates that the process
needs to be improved).

Copyright 2002 Bernd Brügge



Software Engineering II, Lecture 3: Scheduling SS 2002






29

Maturity Level 5: Optimizing Process


Measures from software development activities are used
to change and improve the current process


This change can affect both the organization and the
project:


The organization might change its management scheme


A project may change its process model before completion

Bernd Bruegge & Allen H. Dutoit




Object
-
Oriented Software Engineering: Using UML, Patterns, and Java




30

Summary


Software life cycle


The development process is broken into individual pieces called
software development activities


No good model for modeling the process (black art)


Existing models are an inexact representation of reality


Nothing really convincing is available today


Software development standards


IEEE 1074


Standards help, but must be taken with a grain of salt


The standard allows the lifecycle to be tailored


Capability Maturity Model.