Introduction II
PA017 SW Engineering II → Aspects of SW Development
Management
Jaroslav Ráček Josef Spurný
Faculty of Informatics, Masaryk University
September 27, 2022
Waterfall Lifecycle
Integration and testing of the system at the same time
Problems at later stages have great impact on price
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 2 / 23
Waterfall Lifecycle
Problems
Real project do not follow predefined order of steps
Users may not fully and clearly describe requirements at early
stages of project
Customer has to be patient
Late discovery of issues may seriously jeopardize the whole
project
Managers prefer this model.
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 3 / 23
Visibility of Waterfall Lifecycle
Activity Output Document
Requirements Analysis Feasibility Study
General Requirements
Requirements Specification Catalogue of Requirements
System Specification Functional Specification
Tests Plan
User Manual Design
Architecture Design Architecture Specification
System Test Plan
Interface Design Interface Specification
Integration Tests Plan
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 4 / 23
Visibility of Waterfall Lifecycle
Activity Output Document
Detailed Design Units Specification
Unit Tests Plan
Implementation Source Code
Unit Testing Unit Testing Protocol
Module Testing Module Testing Protocol
Integration Testing Integration Testing Protocol
Final User Manual
System Testing System Testing Protocol
Acceptance Testing Final System and its Documentation
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 5 / 23
Implementation based on General Requirements
Very talented individuals are required
Average team cannot be used for this type of development.
Successful products were developed by small teams of
highly-talented members
Systems are usually improperly structured
Repeated changes damage system structure. Evolution is
difficult and costly.
Process is invisible
Manager needs regular outcomes to steer the process. For fast
implementation, it is not efficient to produce documentation
reflecting each version.
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 6 / 23
Incremental Lifecycle
Development based on General Requirements
Problems
General Requirements vs. Reality
Program Documentation vs. Specification
Maintenance increases entropy
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 7 / 23
Prototyping Lifecycle
Suitable for smaller projects when general requirements are not
clear
People like to criticize
Therefore, prototypes are used to collect knowledge
Recommended 1-2 prototype iterations
Prototypes are (mostly) discarded after specification – focus on
low cost
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 8 / 23
Researcher Lifecycle
Problems
Challenging to manage
Trial-and-error approach
Non-existent or invalid documentation
Team members cannot be replaced
Experimenting without predictable outcome.
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 9 / 23
Researcher Lifecycle
For each project, a suitable lifecycle has to be chosen.
Is Researcher Lifecycle suitable for critical infrastructure?
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 10 / 23
Spiral Lifecycle (Boehm,1988)
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 11 / 23
Composition of Application
Model Calculations
User Inputs
User Outputs
Management
Hints / Help
Errors Processing
Internal Data Migration
Data Declaration
Comments
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 12 / 23
Typical Programmers’ Activities
Reading knowledge base
Designing app, components,
documentation
Planning approach, tasks,
time
Programming
Documentation
Testing
Overviews
Meetings
Debugging
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 13 / 23
Maintenance
Maintenance is
software product
modification after
handover to the
Customer with the
aim of removing
errors, improving
performance, or
adaptation to the
changing
environment.
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 14 / 23
Relative Cost of Maintenance
If you think-through the structure of the future SW well and design it
properly, the cost of implementation will be slightly higher, but the
cost increased this way will return in the SW operation phase when
maintenance is provided and customer on-demand modifications are
delivered
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 15 / 23
Hypotheses about Errors
The later the phase in which an error is detected, the more
costly is the cost of fixing it
Many errors remain hidden and will be revealed only after the
phase in which the error was made has ended
There are many errors in the requirements
Errors in requirements mostly consists of wrong assumptions,
forgotten facts, conflicting or ambiguous information
Errors in requirements can be detected
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 16 / 23
Errors and HW Wear
At the beginning, the HW performance is sufficient, but there are
errors that can be fixed over time
At the end, the wearing begins to manifest, and the HW is falling
behind its more powerful surroundings. It is time to replace it
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 17 / 23
Errors and SW Wear
It is naive to think that, as time passes by, you will remove all SW
errors and all troubles will disappear :-)
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 18 / 23
Errors and SW Wear
In reality, the Customer asks for new modifications repeatedly during
operation. This makes the SW more complex and introduces new
errors. One day, it will be better to develop the system from scratch
(Lehman’s Law).
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 19 / 23
Lehman Laws (1974)
Law of Continuing Change
System used in real environment is continuously changing, until it
becomes cheaper to re-structure the system, or to completely replace
it by a newer version.
Law of Increasing Complexity
During evolutionary changes, the programs becomes increasingly
less structured and internal complexity becomes higher. Removing
increased complexity requires additional effort.
Law of Self-regulation
The pace of global system attributes change may appear random over
time. From long-term perspective, it is a self-regulated process which
can be statistically described and predicted.
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 20 / 23
Lehman Laws (1978)
Law of Invariant Work Rate
The overall advancement in development is statistically invariant. In
other words, the development pace is approx. constant and does not
correlate with invested resources.
Law of Conservation of Familiarity
Users must update their familiarity with the system to efficiently
handle it. Fast growth hinders the handling mastery. As a
consequence, average increment growth remains invariant as the
system evolves.
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 21 / 23
Programming in Team
LOC = Lines of Code - program size
E = Effort - time in months
PP = Programmer’s Productivity
GPP = Group Programmers’ Productivity
PP = LOC
E (lines of code per month)
N programmers → N(N−1)
2 ≈ N2 interactions
λN2 – effort per communication (each communicates with everyone
else)
GPP = LOC
(E+λN2)
- group productivity
GPP
PP = E
(E+λN2)
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 22 / 23
Brooks’ Law
Adding a team member to delayed project may cause an
increased delay
Costs for inclusion of a new team member are usually higher than
his/her benefit.
Jaroslav Ráček, Josef Spurný ·Introduction II ·September 27, 2022 23 / 23