Software Life Cycle
Notes based on Vliet, Hans. (2007) Software Engineering: Principles and
Practices. Wiley
USTM - Business School. Computer Science: Software
Development Foundamentals
Lecturer: Afrosio Sadie (afrosio@gmail.com)
Traditional models versus Real projects
• Traditional models for the phased development of
software are, to a large extent, ‘document-driven’.
The pile of paper that is produced in the course of
the project guides the development process. The
development process is seen as a series of
transformations. It starts with a clear requirements
document, and ends with running code. In the next
section we discuss the waterfall model, a well-
known variation of the process model introduced
on previous lectures.
Alternative Models
• Water Fall Model
• Agile Methods
• Incremental Developments
• Rapid Application Development
and DSDM
• Extreme Programming
• Scrum
• Rational Unified Process
• V-Formatted
• Dev-Ops
Maintenance or Evolution
• Software maintenance is defined in IEEE Standard 1219 [IEEE93] as:
“The modification of a software product after delivery to correct faults, to
improve performance or other attributes, or to adapt the product to a
modified environment.”
Each maintenance task, whether it concerns repairing an error or adapting a
system to new user requirements, in principle entails all aspects of the initial
development cycle. During maintenance, we also have to analyze the
problem and conceive a design which is subsequently implemented and
tested.
Maintenance
• Made to an existing product
• Analyze the problem and conceive a design which is subsequently
implemented and tested
• We do not start from scratch either
• time pressure has larger impact
Laws of evolution
1. Law of continuing change: A system that is being used undergoes continuous change, until it is judged
more cost-effective to restructure the system or replace it by a completely new version.
2. Law of increasing complexity: A program that is changed becomes less and less structured (the entropy
increases) and thus becomes more complex. One has to invest extra effort in order to avoid increasing
complexity.
3. Law of self regulation: Software evolution processes are self-regulating and promote a smooth growth of
the software.
4. Law of conservation of organisational stability (invariant work rate) The global progress in software
development projects is statistically invariant.
5. Law of conservation of familiarity: A system develops a constant growth increment to sustain the
organization’s familiarity with the system. When this increment is exceeded, problems concerning quality
and usage will result.
6. Law of continuing growth: The functionality of a system needs to continuously increase in order to
maintain user satisfaction.
7. Law of declining quality: The quality of a system declines, unless it is actively maintained and adapted to
its changing environment.
8. Law of system feedback: Software evolution must be seen as a feedback system in order to achieve
improvements.
• Progressive activities: Activities contribute to an increase in the living
standard;(Lehman )
• Anti-progressive activities: serve to maintain the status quo. It is an
investment in the future, which had better be left to others.(Lehman)
• Generating new code and changing existing code are progressive
activities. These are interesting, challenging and rewarding activities.
They provide the user with new or better functionality. Writing
documentation, improving the structure of the code, and maintaining
good communication between the people involved are anti-regressive
activities. Neglecting these activities may not be harmful in the short
term, but it certainly will be in the long term.
Software Product Lines
“A software product line is a set of software-intensive systems
sharing a common, managed set of features that satisfy the specific
needs of a particular market segment or mission and that are
developed from a common set of core assets in a prescribed way.”
Variability and reuse are increasingly important in developing large-
scale and reliable, but also customized software systems. The goal of
software product line engineering is the large-scale strategic reuse of
functionality across multiple software products within a domain, such
that different software configurations tailored for different customers
or use cases are derived from a common code base.
Software Product Line Engineering (SPLE)
Software Product Line
Engineering (SPLE) is a
software engineering
paradigm, which guides
organizations toward the
development of products
from core assets rather
than the development of
products one by one from
scratch.
Product Line Development
• Core Asset Management
• Product Development
• Management
References
• https://www.cs.cmu.edu/~ckaestne/17708/
