Sequentielle Vorgehensmodelle

(1)

Sequentielle

Vorgehensmodelle

Oliver Hummel

(2)

Bringing Order to Process Models

■

Sequenzielle Modelle

■ Phasenmodell ■ Wasserfall-Modell ■ V-Modell ■ Formale Entwicklungsmodelle ■ Prototypische Modelle

■

Iterative Modelle

■ Spiralmodell ■ Inkrementelle Modelle ■ Agile Entwicklungsansätze ■ Scrum, XP... ■ Evolutionäre Modelle ■ Wiederverwendungsorientierte Modelle ■ Rekursive Modelle

(3)

Phasen- bzw. Wasserfall-Modell

Analysis

Operation Implementation

and Unit Testing

specification architecture/design code Design requirements Integration and System Testing

system

"Hoffentlich sind die iterativen

Interaktionen zwischen den

Phasen auf aufeinander folgende

Schritte beschränkt." [Royce70]

(4)

Meilensteine

■

Stufenweises Phasenmodell: [Benington56] Herbert D. Benington.

Production of Large Computer Programs. In: Proceedings of the ONR

Symposium on Advanced Programming Methods for Digital

Computers, June 1956.

■

Wasserfallmodell: [Royce70] Winston W. Royce. Managing the

Development of Large Software Systems. Proceedings of the IEEE

WESCON Conference, August 1970, pp.1--9. IEEE, 1970.

(5)

More Accurate Waterfall Model

Analysis

Implementation and Unit Testing

specification Architecture/design code Design requirements Integration and System Testing

Operation and

System Maintenance

Analysis

code

Design

Integration and System Testing

Analysis

code

Design

Analysis

code

Design

(6)

Waterfall Model Characteristics

■

Advantages

■ Concrete activities with complete, well-defined products (inputs and

outputs)

■ Simple process model for managers

■

Disadvantages

■ premature freezing of artefacts

■ inflexible partitioning of the project into distinct stages

■ insensitive to changing customer requirements

■ high-risk due to “big bang” integration

■ unrealistic model of the role of maintenance

■

Applicability

■ only feasible when the requirements are well-understood

■ requires large experience with development techniques and tools

(7)

V-Model

Requirements

Specification Code Tested Modules Tested System Used System Architecture/ Design analysis design implementation

/unit testing integration/testing

integration/testing use

■ waterfall model with elaborated view of validation

validated against

Operation and Maintenance

(8)

Historische Entwicklung des V-Modells

■

Erste Idee kam 1979 von Barry Boehm

■

1986 wurde es in Deutschland als Entwicklungsstandard bei der

Bundeswehr (weiter)entwickelt

■

1993 als IT-Standard des Bundes auch für zivile Projekte

festgeschrieben

■

1997 wurde das V-Modell 97 mit Anpassungen (z.B. an OO)

veröffentlicht

■

2005 erschien dann das V-Modell XT (für Extreme Tailoring)

■ 2009 in Version 1.3 veröffentlicht

(9)

■

Verification:

"Are we building the product right“

[Boehm]

■ The software should conform to its specification

■

Validation:

"Are we building the right product“

[Boehm]

■ The software should do what the user really requires

■

V & V is a whole life-cycle process

■ must be applied at each stage in the software process

■

has two principal objectives

■ the discovery of defects in a system

■ the assessment of whether or not the system is usable in

an operational situation

(10)

Detailliertere Darstellung des V-Modells

User's expectations User requirements Requirements specification System design Component specifications Component design Component implementation Executable components Executable system Usable system Deployed system Component testing System testing Acceptance test System operation Integration testing

(11)

V-Model Characteristics

■

Advantages

■ Improved model of verification and validation activities compared to

the simple waterfall model

■

Disadvantages

■ Same as waterfall model

■

Applicability

(12)

Software Prototyping

■

A prototype is an initial version of a system used to demonstrate

concepts and try out design options

■ typically used in sequential process models

■ its development is typically also carried out sequentially

■ but, e.g. the spiral model allows for prototypes, too

■

Boehm’s second law

Prototyping (significantly) reduces requirement and design errors,

■

A prototype can e.g. be used in:

■ the requirements engineering

process to help with requirements elicitation and validation

■ design processes to explore

options and develop a UI design

■ the testing process to run

(13)

The Prototyping Process

Establish prototype obje ctive s De fine prototype functionality De ve lop

prototype prototypeEvalua te

Prototyping plan Outline de finition Exe cuta b le prototype Evalua tion re por t

■

Potential benefits of applying prototyping

■

Improved system usability

■

A closer match to users’ real needs

■

Improved design quality

■

Improved maintainability

(14)

Prototypen

■

Prototypen können unterschiedlich realisiert werden, z.B. als

■ UI-Skizze auf Papier oder in PPT (“Slideware”)

■ Ausführbare Prototypen

■ Anpassung eines Altsystem ■ Neuentwicklung

■ Mock-up

■ ausführbare Anforderungsnotation (z.B. SDL)

■

Auswahl erfordert meist eine Abwägung zwischen Aufwand und

Nutzen

(15)

Throw-away Prototypes

■

Prototyping can sometimes conflict with incremental development

■ since prototypes may be “abused” as system increments

■ The objective of incremental development is to deliver a working

system to end-users

■ The development starts with those requirements which are best understood

■ The objective of prototyping is to validate or derive the system

requirements

■ The prototyping process starts with those requirements which are poorly understood

■

Prototypes should be discarded after development as they are not a

good basis for a production system:

■ The prototype’s structure is usually degraded through rapid change

■ The prototype probably will not meet normal organisational quality

standards and are normally unddocumented

■ It may be impossible to tune the system to meet non-functional

(16)

Formal Specification and Formal Methods

■

Formal specification is part of a more general collection of techniques

that are known as ‘formal methods’

■

These are all based on mathematical representation and analysis of

software and include

■ Formal specification

■ Specification analysis and proof

■ Transformational development

■ Program verification

■

Formal methods have limited practical applicability

■ Their principal benefits are in reducing the number of errors in systems

so their main area of applicability is critical (embedded) systems

■ In this area, the use of formal methods is most likely to be cost-effective

■

Bauer-Zemanek hypothesis

Formal methods significantly reduce design errors, or eliminate them

early.

(17)

Cost of Formal Specification

■

Formal specification involves investing more effort in the early phases of

software development

■

This reduces requirements errors as it forces a detailed analysis of the

requirements

■ Incompleteness and inconsistencies can be discovered and resolved

S p e c i f i c a t i o n D e s i g n a n d I m p l e m e n t a t i o n V a l i d a t i o n S p e c i f i c a t i o n D e s i g n a n d I m p l e m e n t a t i o n V a l i d a t i o n C o s t

■

Hence, savings are

made as the amount

of rework due to

requirements

(18)

Acceptance of Formal Methods

■

Formal methods have not become mainstream software development

techniques as was once predicted

■ Other software engineering techniques have been successful at

increasing system quality

■ Hence the need for formal methods has been reduced

■ Market changes have made time-to-market rather than software with a

low error count the key factor

■ Formal methods do not reduce time to market

■ The scope of formal methods is limited

■ They are not well-suited to specifying and analysing user interfaces and user interaction

■ Formal methods are hard to scale up to large systems

■ They require specially trained personnel

(19)

Formal Systems Development

■

Similar to the waterfall method

■ based on the transformation of a formal specification through different

representations to an executable program

■

The software requirements specification is refined into a detailed formal

specification expressed in mathematically profound notations

■

The development steps of design, implementation and unit testing are

replaced by transformation steps

■ Transformations are ‘correctness-preserving’ so it is straightforward to

show that the program conforms to its specification

R 2 F o r m a l s p e c i f i c a t i o n R 3 E x e c u t a b l e p ro g ra m P 2 P 3 _{P 4} T 1 T 2 T 3 T 4 F o r m a l t r a n s f o r m a t i o n s R 1 P 1

(20)

Formal Systems Development

■

Algebraic approach

■

The system is specified in terms of its operations and their

relationships

■

Model-based approach

■

The system is specified in terms of a state model that is constructed

using mathematical constructs such as sets and sequences

(21)

The Structure of an Algebraic Specification

sort < name >

imports < LIST OF SPECIFICATION NAMES >

Informal descr iption of the sor t and its operations

Operation signatures setting out the names and the types of

the parameters to the operations defined over the sort

Axioms defining the operations over the sort

< SPECIFICATION NAME > (Generic parameter)

(22)

Specification Components

■

Introduction

■ Defines the sort (the type name) and declares other specifications

that are used

■

Description

■ Informally describes the operations on the type

■

Signature (syntax)

■ Defines the syntax of the operations in the interface and their

parameters

■

Axioms (semantics)

■ Defines the operation semantics by defining axioms which

(23)

Kinds of Operations

■

Constructor operations

■ Operations which create or change entities of the type being specified

■ they always deliver a result of the type itself

■

Inspection operations

■ Operations which evaluate entities of the type being specified

■ Typically deliver results of a primitive type

■

To specify behaviour, define the inspector operations for each

constructor operation, i.e. n*m axioms

■

At times, complex constructors may defined by using more primitive

ones

(24)

2. Example of an Algebraic Specification

■

Specifying a COORD data structure

COORD

sort Coord

imports INTEGER, BOOLEAN

Defines a sort representing a Cartesian coordinate. The

operations defined on Coord are X and Y which evaluate the

x and y attributes of an entity of this sort and Equals which

compares two entities of sort Coord for equality.

Create (Integer, Integer) -> Coord

X (Coord) -> Integer

Y (Coord) -> Integer

Equals (Coord, Coord) -> Boolean

X

(

Create

(x, y)) = x

(25)

Operations on a List ADT

■

Constructor operations which evaluate to sort List

■ Create, Cons and Tail

■

Inspection operations which take sort list as a parameter and

return some other sort

■ Head and Length.

■

Tail can be defined using the simpler constructors Create and

Cons.

(26)

LIST (Elem: [Undefined -> Elem] sort LIST

imports INTEGER

Defines a list where elements are added at one end and are removed from the other end. Operations of List are Create, which brings an empty list into existence,

Cons, which creates a new list with an additional member added to the end, Length, which evaluates the size of the list, Head, which evaluates the front

element of the list, and Tail, which evaluates to a new list with the head element removed.

Create -> List

Cons (List, Elem) -> List Tail (List) -> List

Head (List) -> Elem Length (List) -> Integer

Head (Create) = Undefined exception (empty list) Head (Cons (L, v)) = if L = Create then v else Head (L) Length (Create) = 0

Length (Cons (L, v)) = Length (L) + 1 Tail (Create) = Create

Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v)

(27)

Formal Systems Development

■

Advantages

■ High quality software

■ High-level of confidence in software correctness

■

Disadvantages

■ Need for specialised skills and training to apply the technique

■ Difficult to formally specify some aspects of the system such as the

user interface

■

Applicability

(28)

Zusammenfassung

■

Sequentielle Vorgehensmodelle durchlaufen die Phasen der

Software-Entwicklung nacheinander

■ und gemäß der Grundidee genau ein Mal

■ in den meisten Modellen finden sich allerdings iterative Elemente

■

Prototyping kann in allen Vorgehensmodellen eingesetzt werden

■ um unklare Anforderungen oder deren Umsetzung zu erproben

■ Prototypen sollten danach entsorgt werden (throw away!)

■

Formale Entwicklungsmethoden nutzen formalisierte Modelle

■ versuchen dadurch ein bessere Systemqualität zu erreichen

■ erfordern spezielle Kenntnisse

■ meist für eingebettete und kritische Systeme eingesetzt

■ bei gleichen Qualitätsanforderungen aller Erfahrung nach kaum/nicht teurer als andere Ansätze