Software Processes

SPS611S
Fundamentals

1
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Objectives
• Background
• Basic Concepts
• Software Process Ecosystem
• Historical Overview
• Terminology

2
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
1 Background
 Software engineering aims at developing software systems in an efficient and systematic manner.
As part of software engineering, software processes and life cycle models provide a framework
for the various activities, defining how and when to perform these activities, specifying the roles
involved and the results to be created.

 Since there are many different approaches to developing software, with many
different software engineering methodologies and techniques, there exists a similar
multitude of software processes and life cycle models that has grown over decades,
and today we face a large number of approaches addressing the whole software
product life cycle or selected parts thereof.

 In this lesson, we lay the foundation, providing an overview of the topic, context information and
motivation, and outline the problems and challenges coming along with software processes.
 Furthermore, we provide a short history of software processes, and define the main concepts and
terminology used.

3
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
2 Basic Concepts
• Software processes and software development: Software development is a complex task, consisting of
many individual activities that need to be coordinated. This is where software processes and life cycle
models come into play, providing an infrastructure to coordinate and manage these various activities.
Below are the topics involved:
 Software requirements
 Software design
 Software construction
 Software testing
 Software configuration management
 Software quality

The above mentioned and further tasks are carried out in (almost) all software development efforts,
even though the way, order, and frequency of performing these tasks differs.
4
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software processes, software process models
and life cycle models.
• Software processes: A process is a much wider concept, and above all
consist of the actual performance of the relevant activities, which
may or may not be described by a model.

• Software process models: is a representation of a process, de-

scribing how the process is performed (descriptive model) or how it is
expected to be performed (prescriptive model) at a selected level of
granularity.

5
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software process models <=> Life cycle models:
• Software process models: provide more detail, breaking the main
steps down into sub-steps, and adding information about the results
generated and the roles involved. Only describe only an individual
process rather than the entire life cycle.

• Life cycle models: define the main steps (often called phases or
stages) in the software life cycle and their sequence, in particular in
the software development life cycle.

6
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
The challenge of objectively evaluating
software processes.
One of the basic properties of the software life cycle, in particular of
software development, is that it is always performed in a different
context, with unique properties such as:
Task at hand,
Team available and its qualification and background,
Requirements on speed of delivery and
Reliability of results
As a result, it is usually not possible to evaluate and compare different
processes and life cycle models for the same task
in a genuinely objective way.

7
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
The Purpose of Explicitly Using Software
Processes
• “Facilitate human understanding and communication requires that a group be able
to share a common representational format

• Support process improvement requires a basis for defining and analyzing processes

• Support process management requires a defined process against which actual

project behaviors can be compared
• Automate process guidance requires automated tools for manipulating process
descriptions

• Automate execution support requires a computational basis for controlling behavior

within an automated environment.”
8
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software processes as a means to convince
third parties of the quality of the software.
Software process models are also needed to convince others of the quality of
the software such as:
Customers
Regulatory bodies

Even if the software itself was perfect, this would not be sufficient if there
was not some form of proof or at least strong argument to show this.
Using appropriate software development processes is often considered as
such a strong argument

9
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software processes and IT governance.
• Ensuring that the company as a whole and IT in particular are moving
in the right direction, implementing the company objectives, and to
comply to relevant laws and regulations.
• The main reason for using software processes and software process
models as part of IT governance is that they can help to increase the
predictability of processes and their results, and in particular the
transparency of the work done.
• Benefits from the viewpoint of (senior) management that wants to
know and to control what is happening in an organisation, as well as
from the viewpoint of external regulatory bodies who want to ensure
that distributed products are safe, or want to prevent fraud.

10
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Processes for risk management
• Closely related to IT governance is risk management, another common
reason for defining and managing software processes, and emphasised
in common standards such as ISO 9001:2015, COBIT, SOX, and ISO
31000:2009.
• On the one hand, the systematic definition and management of
software processes can help to reduce the risks involved in these
processes.
• Looking at this relationship the other way round, high risks involved in
a software process are one indicator that this process should be
defined and managed very systematically, while other, low-risk
processes may be performed in a more ad-hoc way.

11
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software processes in small development
efforts
• Small and agile development efforts will need different kinds of software
processes to be successful, but if adequate processes are used, these
development efforts will also benefit considerably, specifically if a fast start
of development is important.

• At the same time, development teams in small development efforts are

more likely to object to a set of processes that they did not select
themselves and that they might not see as genuinely helping them.

• Therefore it is particularly important in small settings to ensure that the

processes really make the team’s life easier and does not just add
bureaucracy.
12
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
 Software Processes and their Evolution
• Plan-driven development: better known as the “classical” software process.
Plan work as far as possible in advance. This implies that the requirements
need to be identified in advance, which is why this way of working is also
called “requirements-driven”. Do allow iteration, but with the limitation that
these iterations and their contents are largely planned in advance. Shows
limitations, such as lacking flexibility toward changes, over-documentation,
and poor performance, and they also introduced some bureaucracy.

• Agile and plan-driven development: refers to a software development

approach based on iterative development. Break tasks into smaller
iterations, or parts do not directly involve long term planning. Each iteration
is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks.

13
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software Processes and their Evolution
• Standardisation of processes: Related to but not identical with the
relationship between agile and plan-driven development.

• Industry and technology trends: New trends provide new

opportunities but also new challenges for the software processes
used to implement these trends.

• Software process variety: Still, practitioners and researchers search

for approaches and new models appear on a regular basis. Current
trend toward the development and use of hybrid approaches.

14
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Managing Software Processes
• Defined vs. performed process: The main target, of course, is to ensure that there is no
major difference between the performed and the defined process, i.e. that the
performed process conforms to the defined process.
• Process selection and tailoring: Project managers often select a development approach
on a per-project basis, usually grounded in their personal experience and preferences
which limits project comparability and knowledge transfer. Organisations therefore tend
to define the approach and the processes to be used.
• Process and product quality: One of the central concepts of most current approaches to
quality management is the hypothesis that good processes will lead to
good resulting products.
• Software Process Improvement (SPI): n order to address the resulting issues and to
provide companies with better development models, software processes should be
subject to (continuous) software process improvement
• Software processes and knowledge management: A common feature of most software
processes is that they require a fairly large amount of knowledge to perform.
• Software processes and people: Software processes are largely performed by people,
with only small parts automated or at least strongly prescribed. Therefore, the role of
these people, their motivation and qualification, have a strong influence on success and
need to be taken into account in the design of software processes. 15
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software Process Models and Meta-models
When we want to support processes using tools, or to analyse them in any
systematic way, we need some form of formal description of the processes. This is
where meta-models come into play, i.e. models that define the notation to be used
for (software process) models.

As a result, different levels of process description are needed:

- The process execution level refers to the execution of the process, the individual
documents created, the activities performed etc.

- The process description level goes up one level of abstraction, defining the process
models and the document types, the activity types and so on, thus fixing the objects
to be used on the process execution level.

- The process meta-model level goes up another level, containing the description of
the concepts used to define the document types, activity types etc., i.e. the objects
on the process description level.
16
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
3 The Software Process Ecosystem
Apart from the management of processes and models, and the meta-
models needed (which were all described above), there is a number of additional
components that together form such a software process ecosystem.

Some of its main building blocks are:

Tools to define, manage and perform software processes and life cycle models.
Training is an important task in order to get a process model deployed and used.
Certification infrastructure when certification regarding a model is to be possible,
which is mainly relevant for public process standard. Such a certification may refer
to individuals and their competencies regarding the process model, or to an
organisation and its correct implementation of the process model.

17
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
4 Historical Overview
Early Days: Waterfall models, The V-Model, Iterative and incremental
development.
1980s: The Rise of Software Processes.
1990s and Early 2000s: Lightweight and Agile Processes.
Recent Trends: (IT Governance, Agile in-the-large, Agile, plan-driven
and hybrid life cycles, Global and distributed software processes,
Open source development, Configuration of software rather than
development, Processes for new technologies and application areas).

18
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
5 Terminology
• System: Combination of interacting elements organised to achieve
one or more stated purposes.
• Software: All or part of the programs, procedures, rules, and
associated documentation of an information processing system.
• Software engineering: Application of a systematic, disciplined,
quantifiable approach to the development, operation, and
maintenance of software; that is, the application of engineering to
software.

Software processes form only a small part of software engineering, but

this is a very central part, providing a framework of when and how to
apply the various methods defined by software engineering.
19
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Process Terminology

Figure 1: Relationship between

processes and related terms

• Process: Set of interrelated or interacting activities which use in-

puts to deliver an intended result.
• Task: Required, recommended, or permissible action, intended to
contribute to the achievement of one or more outcomes of a process.
• Activity: Set of cohesive tasks of a process
• Sub-process: A process that is part of a larger process.
• Procedure: Specified way to carry out an activity or a process.
20
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Process Terminology
• Life cycle: Evolution of a system, product, service, project or other
human-made entity from conception through retirement.
• Life cycle model: Framework of processes and activities concerned
with the life cycle, which can be organised into stages, and which acts
as a common reference for communication and understanding.
• Process instance: Single specific and identifiable execution of a
process.
• Role: A defined function to be performed by a project team member,
such as testing, filing, inspecting, coding.
• Product: An artefact that is produced, is quantifiable, and can be
either an end item in itself or a component item.
21
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software Process Terminology
• Software process: A process that forms part of the life cycle of software.
• Software development process:
-Process by which user needs are translated into a software product.
-A software process that is performed (fully or at least partly) during the development
part of the software life cycle.
Software development life cycle (SDLC): Life cycle that includes the software
development processes used to specify software requirements and transform them
into a deliverable software product.
Software (product) life cycle (SPLC): Life cycle that includes the software development
life cycle plus additional software processes that provide for deployment,
maintenance, support, evolution, retirement, and all other inception-to-retirement
processes for a software product, including the software configuration management
and software quality assurance processes that are applied throughout a software
product life cycle.
A software product life cycle may include multiple software development life cycles for
evolving and enhancing the software.
22
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Software Process Terminology
Life cycle phase: Collection of logically related life cycle activities. During development, a
phase usually culminates in the completion of a major deliverable.
Stage: Period within the life cycle of an entity that relates to the state of its description or
realization.
Stage gate: A review at the end of a stage in which a decision is made to continue to the
next stage, to continue with modification, or to end a project.
Quality gate: A defined set of results and activities to be completed at a certain point
within development such as the end of a stage, in combination with a formal review to
verify that all expected results have been prepared in adequate quality, and all expected
activities have been performed.
Milestone: A significant point or event in the project.
Methodology:
- A system of practices, techniques, procedures and rules used by those who work in a
discipline.
- Specification of the process to follow together with the work products to be used and
generated, plus the consideration of the people and tools involved, during an
information-based domain (IBD) development effort.
23
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Model and Meta-model Terminology
Model:
- Representation of a real world process, device, or concept.
- An abstract representation of an existing entity or an entity to be created, where
entity denotes any part of reality or any other conceivable set of elements or
phenomena, including other models. With respect to a model, the entity is called the
original.
Descriptive and prescriptive models: If a model represents an existing entity, it is called
a descriptive model. If it represents an entity that is to be created, it is called a
prescriptive model.
Meta-model:
- Specification of the concepts, relationships and rules that are used to define a
methodology.
- Model defining the concepts and their relations for some modelling notation.

24
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Process Model Terminology

Figure 2: The process cube

25
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Process Model Terminology
“Performed process” vs. “Process model”. Put differently, the process model
describes the explicit understanding of the process, while the performed process
describes the implicit understanding. As a result, both components of the process
are actually optional, since a process may be modelled but not (yet) performed,
or—more common—it may be performed but not modelled.

“Process ‘as is’ ” vs. “Process ‘to be’ ”. A process model may be descriptive,
describing the process “as is”, or it may be prescriptive, describing the process “to
be”. Similarly, even if a process has not been modelled, there exists an implicit
expectation of how the process should be performed, the process “to be”.

“General process” vs. “Process instance”. Most processes exist on two different
levels: there is the level of the individual instance, where the process is
performed once, and the level of the general process as it is performed
repeatedly, across different instances. 26
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Standard processes and tailoring
• Standard process: Set of definitions of the processes used to
guide processes in an organisation.
• Process tailoring: Making, altering, or adapting a process description
for a particular end.
• Tailored process: Process developed by tailoring a standard process.

27
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
 Standard processes and tailoring
• Includes the step of project
planning which adds further
information to the project
process such as the
resources used, dates, or
the information that certain
steps need to be repeated
multiple times.

Figure 3: Standard processes and tailored processes

28
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Major Phases Within Software Life Cycles
• Requirements analysis: Process of studying user needs to arrive at a definition of system, hardware, or
software requirements.
• Design: Process of defining the software architecture, components, modules, interfaces, and data for a
software system to satisfy specified requirements.
• Implementation: Process of translating a design into hardware components, software components, or
both.
• Test: Activity in which a system or component is executed under specified conditions, the results are
observed or recorded, and an evaluation is made of some aspect of the system or component.
• Deployment: Phase of a project in which a system is put into operation and cutover issues are resolved
• Operations: Ongoing execution of activities that produce the same product or provide a repetitive
service.
• Verification: Confirmation, through the provision of objective evidence, that specified requirements
have been fulfilled
• Validation: In a life cycle context, the set of activities ensuring and gaining confidence that a system is
able to accomplish its intended use, goals and objectives.
• Traceability: Degree to which a relationship can be established between two or more products of the
development process, especially products having a predecessor-successor or master-subordinate
relationship to one another.
29
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.
Other Relevant Terminology
• Quality: Quality is the degree to which a set of inherent
characteristics fulfils requirements.
• Process quality: Ability of a process to satisfy stated and implied
stakeholder needs when used in a specified context.
• Project: A project is a temporary endeavour undertaken to create
a unique product, service, or result.
• Risk: Uncertain event or condition that, if it occurs, has a positive
or negative effect on one or more project objectives.

30
Kneuper, R. (2018). Software processes and life cycle models: An introduction to modeling, using and managing Agile, Plan-Driven, and hybrid processes. Springer.