Software Engineering

Lecture 04 – Software Processes

© 2015-20 Dr. Florian Echtler
Bauhaus-Universität Weimar
<[email protected]>

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Software Processes
●
SPs are “activities involved in producing a software system”
●
SP models are “abstract representations of these processes”
(Definitions from [Sommerville2011])

●
There is no ideal process.
●
One size does not fit all.

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 2

Fundamental Activities
●
4 fundamental activities – software …
– Specification
– Design & Implementation
– Validation
– Evolution
●
Major components:
– Products (= outcomes of an activity)
– Roles (= responsibilities of people involved)
– Pre- and post-conditions

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 3

Software Specification
●
Defines functionality of/constrains on the software product
●
Also known as requirements engineering
●
Nearly always the initial step
●
Sub-activities:
– Feasibility study
– Requirements elicitation/analysis
– Requirements specification
– Requirements validation

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 4

Software Specification
Image source (FU): Sommerville, Software Engineering, Chapter 2, https://xkcd.com/1425/

Requirements
Feasibility
elicitation and
study
analysis
Requirements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 5

Requirements Specification
●
User requirements: (“Lastenheft”)
– Statements in natural language (+ diagrams)
– What services is the system expected to provide?
– What constraints is it expected to observe?
– Often part of the call for bids (“Ausschreibung”)
●
System requirements: (“Pflichtenheft”)
– Detailed description of functions/services
– Defines exactly what is to be implemented
– Often part of the contract

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 6

User requirements
●
“Lastenheft” → customer's view
●
Clear, rigid structure, e.g. from [Balzert2009]
●
Goals
●
Application area
●
Functions
●
Data
●
(additional) Services
●
Quality requirements
●
Appendix

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 7

System requirements
●
“Pflichtenheft” → developer's view
●
Extension of UR with additional sections
●
Goals
●
Application area
●
Product environment
●
Functions
●
Data
●
(additional) Services
●
Quality Goals
●
Test scenarios
●
Development environment
28/05/24
●
Appendix
Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 8
Requirements Specification (2)
Source (FU): Sommerville, Software Engineering, Chapter 4

●
User requirements example (“feature wishes”)
– The patient management system shall generate monthly management reports showing the cost of
drugs prescribed by each clinic during that month.
●
System requirements example (“testable”)
– On the last working day of each month, a summary of the drugs prescribed, their cost, and the
prescribing clinics shall be generated. The system shall automatically generate the report for printing
after 17:30 on the last working day of the month.
– A report shall be created for each clinic and shall list the individual drug names, the total number of
prescriptions, the number of doses prescribed, and the total cost of the prescribed drugs. If drugs are
available in different dose units (e.g., 10 mg, 20 mg) separate reports shall be created for each dose
unit.
– Access to all cost reports shall be restricted to authorized users listed on a management access
control list.

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 9

Requirements Specification (3)
●
Functional requirements
– What should the system (not) do?
– E.g. “A user shall be able to search the appointment lists for all clinics.”
●
Non-functional requirements
– Reliability, response time, security, ease of use …
– E.g. “The system shall be available during normal working hours (Mo-Fr,
8:30 – 17:30). Downtime during NWH shall not exceed 5 sec. per day.”
– “The system shall conform to ISO Standard XYZ.”

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 10

Software Design & Implementation
●
Conversion from system specification to executable system
●
Sub-activities:
– Design
●
e.g. architecture, interface, component, database, …
●
Often involves graphical models, UML
– Implementation
●
Often interleaved with design (depending on SPM)
●
Also involves testing & debugging

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 11

Software Design & Implementation
Image source (FU): Sommerville, Software Engineering, Chapter 2

Requirements
specification
Design activities

Architectural Abstract Interface Component Data structure Algorithm

design specification design design design design

System Software Interface Component Data structure Algorithm

architecture specification specification specification specification specification

Design products

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 12

Software Validation
●
Verification and validation (V&V)
●
Validation → “Are we building the right product?” [Boehm79]
– User testing
– Acceptance testing (with user-supplied data)
●
Verification → “Are we building the product right?” [Boehm79]
– Unit testing (with developer-supplied data)
– System testing

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 13

Software Validation
Image source (FU): Sommerville, Software Engineering, Chapter 2

Requirements System System Detailed

specification specification design design

System Sub-system
Acceptance Module and
integration integration
test plan unit tests
test plan test plan

Acceptance System Sub-system

Service
test integration test integration test

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 14

Software Evolution
●
Also known as software maintenance
●
Often higher costs than initial development
●
Integral part of the entire software process

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 15

Software Evolution
Image source (FU): Sommerville, Software Engineering, Chapter 2

●
Beware of “not-invented-here” (NIH) syndrome

Requirements Evaluate Propose system Modify

specification existing systems changes systems

New
system
Existing
systems

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 16

“Plan-driven” vs. “Agile”
●
Plan-driven processes:
– All steps/activities planned in advance
– Progress measured against this plan
●
Agile processes:
– Incremental planning
– Easier adaptation to change
– More difficult to measure progress
●
Many hybrid methods

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 17

Example Software Processes
●
Waterfall model
●
Other “traditional” models
●
Incremental development
●
Reuse-oriented development

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 18

Waterfall Model
Requirements
specification

System and
software design

Implementation
and unit testing

Integration/
System testing

Operation/
maintenance

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 19

Waterfall Model
●
Derived from general systems engineering
●
Phases …
– have clear lifetimes (plan-driven)
– end with “sign-off” on specific documents →
iterations are expensive
●
Used in formal development (proof-driven, for
safety-critical systems)
●
Very inflexible

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 20

Other “traditional” models
Image source (CC): https://en.wikipedia.org/wiki/Rational_Unified_Process

●
Rational Unified Process (RUP) [Krutchen03]
●
Derived from work on UML
●
Focus on business perspective
●
Focus on iteration

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 21

Other “traditional” models
Image source (PD): https://en.wikipedia.org/wiki/Spiral_model

●
Spiral Model [Boehm88]
●
4 sectors for each cycle
●
Focus on risk assessment

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 22

Other “traditional” models
Image source (CC): https://de.wikipedia.org/wiki/V-Modell

●
V Model [Boehm79], based on Waterfall
●
Often used by German government
●
Current variant: “V-Modell XT”

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 23

Incremental Development
Image source (CC): https://en.wikipedia.org/wiki/Incremental_build_model

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 24

Incremental Development
●
Also known as evolutionary development
●
Basis for many agile processes
●
Quickly develop multiple prototypes
●
Test with end users, refine, repeat
●
Very useful for GUI applications

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 25

Reuse-oriented Development
Image source (FU): Sommerville, Software Engineering, Chapter 2

●
Focus on reuse/adaptation of existing components
●
Needs requirement compromises
●
Often used in Web context (e.g. LAMP stack)

Requirements Component Requirements

specification analysis modification

System Development/ System design

validation Integration with reuse

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 26

Reacting to Change
●
Change will happen during the SP
●
Two strategies for coping with change:
– Change avoidance → Prototyping
– Change tolerance → Incremental Delivery

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 27

Prototyping
●
Quickly create prototypes and expose to users
●
Useful during all phases
●
Initial prototypes may not even contain code (e.g. paper prototypes,
mockups, Wizard-of-Oz)
●
Be prepared to throw entire prototypes away

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 28

Incremental Delivery
Image source (FU): Sommerville, Software Engineering, Chapter 2

●
Order functionality by importance
●
Deliver most important functions to the end user first
●
Either plan-driven (increments defined in advance) or agile (inc.
defined on-the-fly)

Define outline Define Design system

requirements increments architecture

Develop Validate Integrate Validate Final

increment increment increment system System

System incomplete

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 29

Questions/suggestions?
Image source (FU): http://www.paragoninnovations.com/ng4/guide.shtml

28/05/24 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 30