MDS
3. Software process
“Software Development Methodologies”
Ricardo Filipe, ISEC ([Link]@[Link])
33
Process - Motivation
34
1
MDS
Process defined
35
Process defined
A software process is needed to guide and coordinate the group of
people.
A software process is a set of related activities that leads to the
production of the software. These activities may involve the
development of the software from the scratch, or, modifying an
existing system.
A software process model is a simplified representation of a
software process. Each model represents a process from a specific
perspective:
Waterfall
Scrum
Lead
…
36
2
MDS
Process defined
Software Process only for a a group of people?
What about one-man projects?
Documentation
Test Cases
User guide
Design Document
Rationale behind decision made
Team growth
Share information with Stakeholders
37
Why we need a Process defined?
Communication
Commitments
Deliverys
Quality
Management
Product/project progress
Team morale
Ownership
Roadmap
38
3
MDS
Process defined – Communication
39
Entry and Exit Criteria
What are the exit criteria for each activity?
What is the entry criteria for the next follow-on activity?
40
4
MDS
Entry Criteria Examples
Required artifacts
Required people
Required tools
Required definition of the activity to be performed
41
Exit Criteria Examples
All the artifacts are reviewed
All or some specified percentage of the errors are corrected
People in the downstream activities have concurred and accepted the
artifacts
Required definition of the activity to be performed.
Other criteria may exists:
E.g. the person that will participate in the next downstream
activity is available.
42
5
MDS
Process Assessment Models
Assessing the maturity of the organization in their
software development and support.
SEI (Software Engineering Institute)
ISO (International Standards Organization)
43
Process Assessment Models
A process is a set of interrelated or interacting activities which
transforms inputs into outputs.
ISO 9000:2005
A process model defines:
A set of tasks that need to be performed, and its sequence
The inputs and outputs from each task
Entry and exit criteria for each task
A lifecycle is the evolution of a system, product, service,
project or other human-made entity from conception through
retirement
ISO/IEC 12207
The process of software development is often modeled as a
series of stages that define the software life cycle
NASA
44
6
MDS
ETVX model
Model introduced by IBM for documenting their
processes
'E' - entry criteria which must be satisfied before a set of tasks
can be performed
'T' - the set of tasks to be performed
'V' - verification & validation process to ensure that the right
tasks are performed
'X' - exit criteria or the outputs of the tasks
Task
Entry definitions Exit
Inputs Outputs
criteria Validation criteria
definitions
45
Case Study - Eating at SELEX
46
7
MDS
Case Study - Eating at SELEX mensa
1. Choose colors for first dish, main dish, and side dish
2. Pick up disk for signaling the main dish
3. Pick up tray with corresponding color for first dish
4. Pick up cup with corresponding color for side dish
5. Choose bread
6. Choose water
7. Choose fruit or desert
8. Put tray on the conveyor
9. Wait to be served
10. Pick up tray from the conveyor
11. Seat
12. Eat
13. Put tray on the other conveyor
14. Separate plastic into bin
15. Exit
47
Eating at SELEX cantina – Process model
Lifecycle (sequence of tasks)
Choose Collect
Eat Exit
menu food
Process task description: Choose menu
Entry criteria:
Exit criteria:
Being hungry
Be a company employee, or Menu has been chosen
having been invited Outputs:
Inputs: Tray
SELEX employee badge or Disk
SELEX lunch voucher
Activities description: Cup, knife, fork, spoon
Consult table with menu and corresponding colors
Pick up disk with the color of the chosen main dish
…
48
8
MDS
Waterfall lifecycle
Requirements
analysis
Design
Coding
Testing
Maintenance
Proposed in 1970 by W.W. Royce
Models a systematic sequential approach – tasks occur
sequentially one after another
But real projects rarely follow the sequential flow
When something goes wrong, go back to a previous step (expensive)
49
Waterfall pros and cons
Requirements must be specified in the first step
Difficult to accommodate the natural uncertainty at the
beginning of the projects
Sometimes clients demand for closed requirements
The result of each phase is usually one or more approved
documents
Document-driven approach – costly iterations
The output from each stage is fed into the next stage in sequence
The software project may be tracked as it moves sequentially
through specific and identifiable stages.
Gave SW engineering a process that development could focus.
50
9
MDS
Waterfall pros and cons
Client sees nothing until the last step
Works better when requirements are well understood,
and technologies known
Still used as context for software processes
51
Classic software life cycle model activities
Walt Scacchi
System Initiation/Planning
Requirement Analysis and Specification
Functional Specification or Prototyping
Partition and Selection
Architectural Design and Configuration Specification
Detailed Component Design Specification
Component Implementation and Debugging
Software Integration and Testing
Documentation Revision and System Delivery
Deployment and Installation
Training and Use
Software Maintenance
52
10
MDS
NASA-Software Engineering Laboratory
recommended software development life cycle
1. Requirements definition
2. Requirements analysis
3. Preliminary design
4. Detailed design
5. Implementation
6. System testing
7. Acceptance testing
8. Maintenance and operation
53
NASA-SEL – Activities by Staff Effort
54 ©2008-2020 João Cunha, DEIS-ISEC
11
MDS
NASA-SEL ex: REQUIREMENTS DEFINITION PHASE
55 ©2008-2020 João Cunha, DEIS-ISEC
NASA-SEL: Tailoring
Certain projects, however, do not fit this mold.[…] the life
cycle and the methodologies they incorporate often need
adjustment.
Tailoring allows variations in the level of detail and degree
of formality of documentation and reviews, which may be
modified, replaced, or combined in the tailoring process.
Such tailoring provides a more exact match to unique
project requirements and development products at a
lower overall cost to the project without sacrificing
quality.
56
12
MDS
ISO/IEC 12207
Information technology- Software life cycle processes
(1995)
Systems and software engineering - Software life cycle
processes (2008)
Systems and software engineering - Software life cycle
processes (2017)
57
ISO/IEC 12207
Establishes a common framework for software life cycle processes,
with well defined terminology, that can be referenced by the software
industry. It contains processes, activities, and tasks that are to be
applied during the acquisition of a software product or service and
during the supply, development, operation, maintenance and
disposal of software products.
Does not detail the life cycle processes in terms of methods or
procedures […] does not detail documentation in terms of name,
format, explicit content and recording media […] does not prescribe a
specific system or software life cycle model, development
methodology, method, model or technique.
Defines stages (phases) and processes. A stage is typically a period of
time and ends with a "primary decision gate". The same process
often recurs within different stages.
58
13
MDS
ISO/IEC 12207:1995
59 ©2008-2020 João Cunha, DEIS-ISEC
ISO/IEC 12207:2008
60 ©2008-2020 João Cunha, DEIS-ISEC
14
MDS
ISO/IEC 12207:2008
Each process of this standard is described in terms of the
following attributes:
The title conveys the scope of the process as a whole
The purpose describes the goals of performing the process
The outcomes express the observable results expected from
the successful performance of the process
The activities are a list of actions that are used to achieve the
outcomes
The tasks are requirements, recommendations, or permissible
actions intended to support the achievement of the outcomes.
61
ISO/IEC 12207:2008
Within this International Standard clauses numbering:
6.a and 7.a denote a process group
6.a.b and 7.a.b denote a process (or lower-level process) within that
group
6.a.b.1 and 7.a.b.1 describe the purpose of the process
6.a.b.2 and 7.a.b.2 describe the outcome of the process
6.a.b.3.c and 7.a.b.3.c list activities of the process and clauses
6.a.b.3.c.d and 7.a.b.3.c.d list tasks of the activity 'c‘
62
15
MDS
ISO/IEC 12207:2008 (example)
7.1 Software Implementation Processes (process group)
7.1.2 Software Requirements Analysis Process (process)
[Link] Purpose (purpose of the process)
The purpose of Software Requirements Analysis Process is to establish
the requirements of the software elements of the system.
[Link] Outcomes (outcome of the process)
a) the requirements allocated to the software elements of the system
and their interfaces are defined;
b) software requirements are analyzed for correctness and
testability;[…]
[Link] Activities and tasks
[Link].1 Software requirements analysis (activity)
[Link].1.1 The implementer shall establish and document software
requirements (including the quality characteristics specifications)
described below (task).
a) Functional and capability specifications, including performance,
physical characteristics, and environmental conditions under which the
software item is to perform.
b) Interfaces external to the software item.
63
64
16
MDS
65 ©2008-2021 João Cunha / Ricardo Filipe, DEIS-ISEC
66 ©2008-2020 João Cunha, DEIS-ISEC
17
MDS
ISO/IEC 12207:2008 (tailoring)
The purpose of the Tailoring Process is to adapt the
processes of this International Standard to satisfy
particular circumstances or factors that:
a) Surround an organization that is employing this International
Standard in an agreement.
b) Influence a project that is required to meet an agreement in
which this International Standard is referenced.
c) Reflect the needs of an organization in order to supply
products or services.
67
ISO/IEC 12207:2017
68 ©2008-2020 João Cunha, DEIS-ISEC
18
MDS
ISO/IEC/IEEE 12207:2017
69 ©2008-2020 João Cunha, DEIS-ISEC
Bibliography
Tsui, Frank and Karam, Orlando. Essentials of Software
Engineering. Sudbury, MA : Jones and Bartlett Publishers, 2007
(Chapter 4)
Walt Scacchi, Process Models in Software Engineering, J.J.
Marciniak (ed.), Encyclopedia of Software Engineering, 2nd
Edition, John Wiley and Sons, Inc, New York, December 2001
[Link]
[Link]
ISO/IEC 12207:2008, Systems and software engineering –
Software Life Cycle Processes
[Link]
ber=4475825
NASA, Recommended Approach to Software Development,
Revision 3, Document SEL-81-305, Greenbelt, Maryland: NASA
Goddard Space Flight Center, 1992
[Link]
70
19