SEN2 – Software ProcessesPresenter: Vadim EmrichLukas Bäcker

Software processes Software process models

Waterfall - Model Evolutionary - Model Component-Based Software

Process iterations Incremental development Spiral development

Process activities Software specification Software-design and –implementation Software-validation and –verification Software maintenance

Software models Conclusion

Topics

2 / 23

Software Processes

A software process is…

the amount of operations that lead tothe production of a software product

complex (intellectual and creative)

CASE utilities…

try to completely automate software processes

do not completely support automating

3 / 23

there are many various software processes

but all have basic activities in common:

specification design & implementation validation evolution

there is no "ideal“ software process

Software processes

4 / 23

Software processes

improving software

processes

making standards

reducing variety

improves communication

reducestime for

education

CASE utilitymakes sense

5 / 23

Software process models

A software process model is…

an abstraction of a software process a specific view on a part of the software process

Three specific software process models

waterfall model evolutionary model component based software engineering (CBSE)

6 / 23

Software process models

Waterfall model

separates basic activities into phases (specification, development, validation, evolution)

each phase leads to the next one

finish current to enter the next phase

7 / 23

Software process models

Evolutionary model

combines specification, development and validation to one phase

at first develop an implementation to make customers criticize

next step is to swap between customize implementation evaluate with customer

till the final product

but process is invisible

often systems are bad structured

8 / 23

Software process models

Component based software engineering

based on existence of reusable software components

reduces amount of software to develop costs risks

possible to have to compromise specifications

requirementspecification

analysis of components

adaption of specifications

system design with reusability

systemvalidation

development and

integration

9 / 23

Process iterations

Repeating processes and activities

Why do we need process iterations? Condition changes Requirement changes Adopt changes

Specification and Implementation are developed simultaneously

Disagreements with nowadays business models

10 / 23

Process iterationsIncremental development

Waterfall-model issue Evolutionary development issue Combines pros

Most exact documentation Open-door design

Define abstract requirements Dedicate requirements to subsystems Design system architecture Develop a subsystem Repeat development process for each

subsystem

11 / 23

Process iterationsIncremental development

(National Physical Laboratory, 2005Via: www.robabdul.com)

12 / 23

Process iterationsIncremental development

(http://www.informatik.uni-bremen.de/gdpa/part3/p3sz1.htm)

13 / 23

Combines Incremental development Prototyping

Basic segments: Determine objectives Identify and resolve risks Development and test Plan the next iteration

Exact consideration of risks

Process iterationsSpiral Model

14 / 23

Process iterationsSpiral Model

15 / 23

Process activities

Four basic activities

Specification

Design and implementation

Validation and verification

Maintenance

16 / 23

Process activitiesSpecification

Requirements analysis Try to understand

Constraints Functions Requirements

Steps Operability research Definition and analysis of requirements Specification of requirements Validation of requirements

17 / 23

Process activitiesDesign and implementation

Design Architecture design Abstract specification for each subsystem Interface design …

Implementation Software models (UML 2.0) CASE-tools

Troubleshooting Find error Plan how to resolve error Resolve error Check again for error

18 / 23

Process activitiesVerification and validation

Are all specifications implemented? Are they implemented proper?

Testing process Subsystem Integrated subsystem Complete system Acceptance

Usually separate test phase Extreme programming = Test-Driven V-Model

19 / 23

Process activitiesVerification and validation

20 / 23

Process activitiesMaintenance

Expensive hardware changes Flexible software systems Dis-/junction between development and

maintenance No complete new systems anymore Evolutionary process

21 / 23

Conclusion

developing software is complex

standardizing the process reduces complexity saves time and money improves communication

a software process model standardizes the developing process

which specific model you choose depends on the software to be created

22 / 23

Thank you…

23 / 23