CSW QMS 2002 SDP 0909 Software Development

CRITICAL SOFTWARE, S.A.
SOFTWARE DEVELOPMENT
PROCESS
INTEGRATED MANAGEMENT SYSTEM
DATE: 2016-09-29
PROJECT CODE: QMS
DOC. REF.: CSW-QMS-2002-SDP-0909
STATUS: APPROVED
PAGES: 26
ACCESS: CONFIDENTIAL CRITICAL
VERSION: 09
DISCLAIMER - CONTRACT REPORT.

The work described in this report was performed under CRITICAL Software S.A. contract. Responsibility for the
contents resides in the author or organization that prepared it.
© 2016 Copyright CRITICAL Software S.A. All Rights Reserved.

SOFTWARE DEVELOPMENT PROCESS
APPROVAL
VERSION REVISION NAME FUNCTION SIGNATURE DATE
09 -- Délio Almeida Quality Manager 2016-09-29
AUTHORS AND CONTRIBUTORS
NAME DESCRIPTION DATE
André Carvalho Author 2002-11-11
Rui Cordeiro Author 2004-07-30
José Gonçalo Silva Author 2004-07-30
Luís Joaquim Contributor 2005-11-30
Délio Almeida Contributor 2013-01-29
Nelson Vilhena Contributor 2013-01-29
Joel Oliveira Contributor 2013-01-29
Neil Aries Contributor 2015-10-15
Russell Jugg Contributor 2015-10-15
Richard Coley Contributor 2015-10-15
Jorge Rodrigues Contributor 2015-10-15
Paulo Silva Reviewer 2015-10-15
Rodrigo Baptista Contributor 2016-07-11
ACCESS LIST
INTERNAL ACCESS
Public
EXTERNAL ACCESS
Confidential
The contents of this document are under copyright of CRITICAL Software S.A., released on condition that it shall
not be copied in whole, in part or otherwise reproduced (whether by photographic or any other method) and
therefore shall not be divulged to any person other than the addressee (save to other authorized offices of his
organization having need to know such contents, for the purpose for which disclosure is made) without prior
written consent of the CSW Quality Department.
PRINTED: 2016-10-06 | DOC. REF.: CSW-QMS-2002-SDP-0909 2/26

©2016 COPYRIGHT CRITICAL SOFTWARE S.A. ALL RIGHTS RESERVED.
REVISION HISTORY
VERSION REVISION DATE DESCRIPTION AUTHOR
-- 1.10 2002-10-09 Initial version. André Carvalho,

Rui Cordeiro
01 1.17 2002-11-11 Formal review and approval. André Carvalho,

Rui Cordeiro
02, Draft 1.18 2003-07-28 Remove section 2. CRITICAL Software Rui Cordeiro
background and section 7. Standards from
v01 to QM process document. Section 5.2.6
Audit process from v01 was changed to refer
the Quality Management process instead of
Quality Assurance process.
Approved version 02 will include definition of
life cycle models for development and non-
development projects.
02 1.19 2004-07-30 Changes to incorporate the QMS structure Rui Cordeiro,

which considers the top-level document: José Gonçalo
Project Life Cycle Management. Silva
03 1.20 2005-01-14 CRITICAL’s addresses and structural José Gonçalo

updates. Silva
04 1.21 2005-11-30 Changes resulting from process revision. Luis Joaquim
05 1.22 2006-03-15 Improvements in graphical layout. José Gonçalo

Silva
06 1.23 2006-04-24 Remove acronym SRR, Address changes Braselina Sousa

and remove SRR from page 23.
07 -- 2013-10-21 Inclusion of User Interaction Design activities Délio Almeida,

and artefacts in SDP. Nelson Vilhena
08 -- 2015-10-30 LeanQMS: Merge of PT and UK process Paulo Silva, Délio

definitions. Updated to reflect recent Almeida, Jorge
organizational changes in functional areas Rodrigues
and roles. Updated to new template and
branding.
09 -- 2016-08-30 LeanQMS Initiative: inclusion of the new Délio Almeida,

System Engineering Phase prior to project
Rodrigo Baptista
KO in the SDP description.

TABLE OF CONTENTS
1. INTRODUCTION ..................................................................................................................................5
1.1. Objective .......................................................................................................................................5
1.2. Scope ............................................................................................................................................5
1.3. Audience .......................................................................................................................................5
1.4. Definitions and acronyms ..............................................................................................................6
1.5. Document structure .......................................................................................................................8
1.6. Applicable documents ...................................................................................................................9
1.7. Reference documents ...................................................................................................................10
2. DEVELOPING SOFTWARE PROJECTS ............................................................................................11
2.1. Project types for software development ........................................................................................11
2.2. Tailoring the software development life cycle ...............................................................................12
2.3. Tailoring the software development process ................................................................................12
2.4. Roles and responsibilities .............................................................................................................12
3. SOFTWARE DEVELOPMENT LIFE CYCLE PHASES .......................................................................13
3.1. Description of phases....................................................................................................................14
3.1.1. System engineering phase ....................................................................................................15
3.1.2. Requirements engineering phase ..........................................................................................16
3.1.3. Design engineering phase .....................................................................................................18
3.1.4. Validation phase ....................................................................................................................19
3.1.5. Acceptance phase .................................................................................................................20
3.1.6. Operations and maintenance phase ......................................................................................21
3.2. Constraints ....................................................................................................................................22
3.3. Processes invoked in all phases ...................................................................................................23
4. SOFTWARE LIFE CYCLES SPECIFICS .............................................................................................24
5. SOFTWARE DEVELOPMENT PROCESSES .....................................................................................25
TABLE OF TABLES
Table 1 – Definitions ..............................................................................................................................6
Table 2 – Acronyms ...............................................................................................................................8
Table 3 – Applicable documents ............................................................................................................9
Table 4 – Reference documents ............................................................................................................10
Table 5 - Primary life cycle processes vs. life cycle phases ..................................................................25
TABLE OF FIGURES
Figure 1 – Software life cycle phases (full scenario) ..............................................................................13
Figure 2 – System Engineering phase ...................................................................................................15
Figure 3 – Software requirements engineering phase ...........................................................................16
Figure 4 – Design engineering phase ....................................................................................................18
Figure 5 – Validation phase ...................................................................................................................19
Figure 6 – Acceptance phase ................................................................................................................20
Figure 7 – Operation and maintenance phase .......................................................................................21
Figure 8 – Software life cycle constraints ..............................................................................................22

1. INTRODUCTION
1.1. OBJECTIVE
This document details the Software Development Process (SDP) used by CRITICAL Software including the
definition of project types, the processes and their sequence/phasing. It provides the necessary level of guidance
for project members, and confidence to stakeholders, improving the ability to produce results in the scope of
project’s requirements and expectations.
This document also covers systems engineering aspects which are described throughout the document (if
applicable)1.
Nowadays software business demands effectiveness and efficiency, thus managers and developers must
understand from the very beginning which methods and practices they shall apply to solve the problem they face.
Assuming this challenge, the Software Development Process document describes development phases,
processes and the project life cycle organisation, providing all the relevant information to the project team. This
software development process may be applied to (almost) all kind of software projects.
The software development process is a key component of CRITICAL’s Quality Management System. Its effective
application contributes directly to the company’s ability to meet the requirements of the ISO9001 standard for
Quality Management [RD-5].
The software development process described in this document is CRITICAL’s interpretation of the ISO12207
standard for Software Life Cycles [RD-6], ESA ECSS standards [RD-2][RD-3] and ISO13407 standard for Human-
centred design processes for interactive systems [RD-7], plus the experience acquired with past software projects.
1.2. SCOPE
This document covers several software process disciplines and shall be seen as internal standard for software
engineering, supporting and organisational software project activities. The purpose is to provide processes,
procedures and specific requirements for conducting a repeatable software development process within CSW’s
software projects.
The main objective of software development process is to provide adequate guidance to project team, and
confidence to customers that the end product or service satisfies project requirements and expectations. The
ultimate goal is to improve substantially CSW effectiveness and efficiency.
1.3. AUDIENCE
The audience of this document are all CSW members that participate in the CSW projects including: project
managers, technical managers, principal engineers, software product assurance engineers and other technical
project team members (including developers and testers). It also relevant to quality managers, delivery managers,
business development managers, etc.
1
References to phases, processes, procedures and tasks used for software development can most of the times be directly
applied for system (hardware + software) development.

The content of this document is property of CRITICAL Software, SA and distribution to external entities (such as
customers and subcontractors) is not allowed unless there is a written authorisation from the head of the quality
department.
1.4. DEFINITIONS AND ACRONYMS

Table 1 presents the list of definitions used throughout this document. The definitions presented in [AD-1] are also
applicable.
Name Description
A document is considered applicable if it complements this document. All

Applicable Document its content is directly applied as if it was stated as an annex of this
document.
Reference Document A document is considered a reference if it is referred but not applicable to

this document. Reference documents are mainly used to provide further
reading.
Table 1 – Definitions
Table 2 presents the list of acronyms used throughout this document. The acronyms presented in [AD-1] are also
applicable.
Acronym Description
AD Applicable Document
AR Acceptance Review
BOM Bill of Materials
CDR Critical Design Review
CSW CRITICAL Software, SA
CTR Contract
DBS Database Specification
DDS Detailed Design Specification
ECSS European Cooperation for Space Standardization
ESA European Space Agency
ICS Interface Control Specification
IMS Integrated Management System

Acronym Description
ISO International Organization for Standardization
NA Not Applicable
NASA National Aeronautics and Space Administration
NCR Non-Conformance Report
QMS Quality Management system
PAR Product Assurance Report
PDR Preliminary Design Review
PLN Plan (Project Master Plan)
PCM Project Closedown Meeting
PMP Project Management Plan
QR Qualification Review
QMS Quality Management System
RAMS Reliability, Availability, Maintainability and Safety
SAS Software Architectural Specification
SDP Software Development Process
SIM Software Installation Manual
SOW Statement of Work
SRS Software Requirements Specification
STA Statement of Acceptance
SUM Software User Manual
TBC To Be Confirmed
TBD To Be Defined
TCS Test Case Specification
TMR Traceability Matrix Report
TS Technical Specification

Acronym Description
TSR Test Report
UX User Experience
UXD User Experience Design(er)
YAS System Architecture Specification
YRS System Requirements Specification
Table 2 – Acronyms
1.5. DOCUMENT STRUCTURE

Section 1. Introduction, provides information about the document content including the overview, purpose,
audience, definitions and acronyms, structure and references list.
Section 2. Developing software projects, introduces the guidelines used to mentor CSW’s software development
process.
Section 3. Software development life cycle phases, presents the software development phases considered in the
CSW software development process, including their processes, states, reviews, milestones and baselines.
Section 4. Software life cycles specifics, presents the specifics in the life cycle of each project type identified within
software development framework.
Section 5. Software development processes, identifies the primary life cycle processes considered in the Quality
Management System and indicates in which life cycle phases their usage is more relevant.

1.6. APPLICABLE DOCUMENTS

Table 3 presents the list of the documents that are applicable to this document. A document is considered
applicable if it complements this document. All its content is directly applied as if it was stated as an annex of this
document.
Applicable document Document Number
[AD-1] CSW Glossary, CSW CSW-QMS-2002-GLS-0353
[AD-2] Project Life Cycles, CSW CSW-QMS-2003-PCS-2296
[AD-3] Quality Management Process, CSW CSW-QMS-2003-PCS-1475
[AD-4] Process Improvement Process, CSW CSW-QMS-2004-PCS-1608
[AD-5] Verification Process, CSW CSW-QMS-2002-PCS-0354
[AD-6] Project Management Process, CSW CSW-QMS-2003-PCS-1778
[AD-7] Requirements Analysis Process, CSW CSW-QMS-2005-PCS-3424
[AD-8] Software Design Process, CSW CSW-QMS-2002-PCS-1328
[AD-9] Software Construction Process, CSW CSW-QMS-2003-PCS-0237
[AD-10] Software Testing Process, CSW CSW-QMS-2004-PCS-2236
[AD-11] Maintenance Process, CSW CSW-QMS-2005-PCS-2595
[AD-12] Integrated Management System website (QMS Portal) [ Quality > QMS ]
[AD-13] Research & Development Projects Tailoring CSW-QMS-2012-GBK-02170

Guidebook, CSW
[AD-14] Maintenance Projects Tailoring Guidebook, CSW CSW-QMS-2012-GBK-01794
Table 3 – Applicable documents

1.7. REFERENCE DOCUMENTS

Table 4 presents the list of reference documents. A document is considered a reference if it is referred but not
applicable to this document. Reference documents are mainly used to provide further reading.
Reference document Document Number

[RD-1] Recommended Approach to Software Development, Rev. SEL-81-305
3, NASA SEL, June 1992
[RD-2] Space Product Assurance: Software Process Assessment
and Improvement - Part 1: Framework2, Version 1A, ECSS, ECSS-Q-HB-80-02 Rev. 1A
October 2010
[RD-3] Space Engineering: Software, Rev. C, ECSS, March 2009 ECSS-E-ST-40C
[RD-4] Software Process Assessment, SPiCE (Software Process

Improvement and Capability Determination) international ISO/IEC TR 15504:1998
ISO/IEC JTC1 standardisation project, 1998
[RD-5] Quality Management Systems – Requirements, ISO, 2008 ISO9001:2008
[RD-6] Information Technology - Software Life Cycle Processes, ISO12207:2001

ISO, 2001
[RD-7] Human-centred design processes for interactive systems, ISO13407:1999
ISO, June 1999
[RD-8] Software Considerations in Airborne Systems and DO-178C
Equipment Certification, RTCA / EUROCAE, January 2012
Table 4 – Reference documents
2
SPiCE for Space (S4S) Assessment Model (ISO/IEC 15504 Conformant Method for the Assessment of Space Software
Processes).

2. DEVELOPING SOFTWARE PROJECTS

The abstract project life cycle model described in [AD-2] for Software Development projects, when instantiated to
a software project should reflect the project characteristics and should help the project team in achieving the
project goals.
The software development brand of projects is vast enough to have a unique life cycle. For instance, the
development of a software component to be used by other programmers is much more demanding in terms of
technical documentation than developing a user application. Also, the development of a project in cooperation
with entities outside the organization demands an extra care in management and communication activities.
In the scope of software development, it is needed to consider different project types in order to find a way to
manage the unique characteristics of the projects. The CSW project types within the software development are
identified in the next section.
2.1. PROJECT TYPES FOR SOFTWARE DEVELOPMENT

These project types try to define a set of classes based in the organisations experience that lead to substantially
different software development scenarios and requirements. We consider that projects should have flexibility to
define its own life cycle but it is important that their definition is based on previous experience and does not intend
to start every definition from the scratch.
The following project types are considered within the software development framework (these are defined as high-
level project types in the Project Life Cycles document [AD-2]):
• Software Development: A project that requires a full or partial life cycle focused on development of a
new or updated software system;
• Agile Software Development: A project using Agile methodologies focused on incremental and iterative
development of a software system or product;
• Platform/Product Development and Support: A project that aims to develop a new software product
that will be commercialised by CSW in a COTS model. The main difference from Software Development
project types is the additional requirements that are needed to handle specific product characteristics
and a multi customer environment. Typically, product development instantiates an Agile SW
Development process or methodology;
• Proof of Concept / Prototyping: A project that is typically a prototyping activity to provide a proof of
concept or to de-risk planned development activities;
• Support & Maintenance: A project that aims to provide a customer service based on maintaining an
existing product. This product may be developed by CSW or by a third-party;
• Research & Development: Project that typically has an internal customer only (although it may resort
to external funding sources or sponsors), and focuses specifically on R&D activities;
• Outsourcing: Project related to management of outsourced CSW collaborators;
• Verification & Validation: A project that focus on V&V activities. V&V is the process of checking that a
software system meets specifications and that it fulfils its intended purpose. This type of project is
intended to validate product outputs from another project, customer or third party organization, and
therefore typically follows the validated project’s life cycle. A V&V project typically applies only specific
phases or processes of the Software Development life cycle;
• QMS Improvements: An internal program or project associated to a Quality Management System
(QMS) Process Improvement, Organizational Change and/or Strategic Process Initiative, which is

typically composed of a multi-disciplinary team, and crossing several Departments or Functions in the
organization (e.g. CMMI, LeanQMS, Agile@CSW Initiatives, etc.);
• Service: If the project does not fit in any other type it is considered as a generic consulting service.
2.2. TAILORING THE SOFTWARE DEVELOPMENT LIFE CYCLE

For the guidelines that should be used to tailor the project life cycle for a concrete project through the adaptation
of life cycle phases and examples provided in this document refer to the Project Life Cycles document [AD-2].
2.3. TAILORING THE SOFTWARE DEVELOPMENT PROCESS

The QMS processes (described in the QMS portal [AD-12]) may be individually selected, tailored and even
modified/extended, as necessary, to achieve the specific goals and requirements for a project. This is described
in the Project Life Cycles document [AD-2] and in the level 2 documentation for each process (e.g. Requirements
Analysis [AD-7], Software Design [AD-8], Software Construction [AD-9], Software Testing [AD-10], Maintenance
[AD-11], etc.).
Each level 2 process document contains a “Process Tailoring” section that presents approved tailoring
considerations relevant to each process.
Additionally, specific Pre-Tailoring Process Guidelines are also defined for the following types of projects:
 Research & Development Projects Tailoring Guidebook [AD-13];
 Maintenance Projects Tailoring Guidebook [AD-14].
2.4. ROLES AND RESPONSIBILITIES

For a complete description of existent roles at CSW and their skills for each job profile, see [AD-12].

3. SOFTWARE DEVELOPMENT LIFE CYCLE PHASES

This section presents the full software development life cycle phases considered in the CSW software
development process (complete life cycle scenario), including their processes, states, reviews and milestones.
The approach to software life cycle phases followed by CSW is inspired in ECSS [RD-3] and it is compliant with
the abstract life cycle definition described in [AD-2]. Figure 1 presents the phases considered in the software
development process.
Phases are an indicator of the focus of a project in a moment in time. For example, in the beginning of a project
it is expected that most of the resources are allocated to requirements definition but it does not mean that no other
activities can be going on. Some design activities or even construction ones (validating prototypes, etc.) can be
carried out before closing the requirements development.
The SDP formally starts with the System Engineering Phase, prior to project execution and the project kick-off
milestone (typically overlapping with the bidding/proposal phase). This recognizes the fact that key software
engineering activities are conducted in this phase, at a high-level, which reflect and have a decisive impact on
following activities and follow-up phases (e.g. technical solution definition or selection, features identification,
make or buy decisions, etc.)
These phases should be organised in a life cycle, the most common life cycle is the waterfall (cascading) but
other life cycles may be used (e.g. incremental or evolutionary).
SYSTEM DESIGN
ENGINEERING ENGINEERING ACCEPTANCE
PHASE PHASE PHASE OPERATIONS AND
REQUIREMENTS
VALIDATION MAINTENANCE
ENGINEERING
PHASE PHASE
PHASE
SRR / KOM PDR CDR QR AR / PCM
SYSTEMREQUIREMENTS PRELIMINARY CRITICAL QUALIFICATION ACCEPTANCE

REVIEW DESIGN REVIEW DESIGN REVIEW REVIEW REVIEW
FUNCTIONAL STATE SPECIFIED STATE DEFINED STATE QUALIFIED STATE ACCEPTED STATE
Figure 1 – Software life cycle phases (full scenario)

3.1. DESCRIPTION OF PHASES

SDP phases are typically organised in a life cycle that make use of processes in order to produce the relevant
work products needed for project execution.
The documentation of the main key processes involved in SDP phases can be found at the QMS portal [AD-12]
where the most up to date versions of process definitions such as the following can be found: ENG.1
Requirements Analysis Process [AD-7], ENG.2 Software Design Process [AD-8], ENG.3 Software
Construction Process [AD-9], ENG.4 Software Testing Process [AD-10] and ENG.5 Maintenance Process [AD-
11].

3.1.1. SYSTEM ENGINEERING PHASE
SYSTEM REQUIREMENTS DESIGN VALIDATION ACCEPTANCE OPERATIONS AND

ENGINEERING ENGINEERING ENGINEERING MAINTENANCE
The System Engineering phase consists on the elaboration of the initial and high-level version of the Technical
Specification (TS), which is the “response” to the customer needs. The initial
version of the Technical Specification contains a high-level definition of the
features/functions, main components, that may include user interfaces The System Engineering phase consists in
(mock-ups), and high-level solution and design of the system to be the initial specification of the system/software
to be developed including the features list,
developed. It represents the initial understanding of the system to be
architectural design (high-level design) and –
developed and serves as input for the next Requirements Engineering if applicable - first user interaction solution
phase. previews (form and behaviour).
A major activity during this phase is the selection (or definition) of the
Architectural Design based on pre-existent organizational Reference Models, Architectures and Frameworks. If
required, formal decision making is utilized to select alternative solutions during this phase.
The work products produced during this phase, including the Features List/High-Level requirements, High Level
Architectural Design and initial Interaction Solution Previews are present or described in the Proposal document,
which is delivered to the customer. The Technical Solution – Decision Analysis Report (TS-DAR) is produced in
relevant situations where the organization has no standard, pre-selected or well-known Technical Solution / SW
Architecture guidelines for the problem being analysed. The SRR milestone typically coincides with the project
kick-off but may occur before or after this milestone.
ENTRY CRITERIA EXIT CRITERIA

 Customer needs  System Requirements Review Report
 Customer SoW, RFP, RFI
KEY PROCESSES MAIN WORK PRODUCTS

 ENG.1 Requirements Analysis  System Requirements Specification (if
(system level) applicable)
 ENG.2 Software Design (system  Features List / High-Level requirements
level)  High-Level Architectural design
 TS-DAR Decision Analysis Report
justifying High-Level Architecture design or
 CUS.1 Purchasing Make or Buy decisions (if applicable)
 MAN.6 Decision Analysis &
Resolution

DELIVERABLES: YRS System Requirements Specification (optional)

FL Features List / High-Level Requirements
TS Technical Solution (High-Level)
UISP User Interaction Solution Previews (Initial Draft)
RESULTING MILESTONE: SRR System Requirements Review

RESULTING STATE: FS Functional State
RESULTING BASELINE: FSB Functional Specification Baseline
Figure 2 – System Engineering phase

3.1.2. REQUIREMENTS ENGINEERING PHASE

The requirements engineering phase consists on the elaboration of the technical specification (TS), which is the
“response” to the customer needs. The technical specification contains a precise and coherent definition of
functions, user interface, performances, cost, schedule and implementation plans for all levels of the software to
be developed. It also ensures that the requirements and specifications are
feasible, complete, and consistent, and that the customer and
development team understand them in the same way. Therefore a major The requirements engineering phase consists
activity during this phase will be the discovery of unknown (or non- in the specification of the software to be
developed including the software
apparent) requirements at this point in time and on the experimentation
requirements, architectural design (high-level
of multiple solutions, by means of low-fidelity and/or high-fidelity design) and user interaction solution previews
prototyping (e.g. from simple sketches to functional prototypes). The (form and behaviour)
preliminary interface control specification (ICS) is generated by this
phase.

 System Requirements Review Report  Preliminary Design Review Report
 ENG.1 Requirements Analysis  Software requirements

 ENG.2 Software Design  Architectural design
 ENG.4 Software Testing process  Interface control specification
 Traceability matrices
 System test plan (strategy and test cases)
 User Interface/Prototype previews
 CUS.1 Purchasing  Design and user's documentation
 List of critical components
 Software standards (e.q. requirement
standards)
DELIVERABLES: SRS Software Requirements Specification

SAS Software Architecture Specification
ICS Interface Control Specification
DBS Database Specification
SVP Software Validation Plan
TCS Test Case Specification
TMR Traceability Matrix Report
UISP User Interaction Solution Previews
SDP Software Development Plan (when tailored in by [RD-8])
PSAC Plan for Software Aspects of Certification (when tailored in by [RD-8])
RESULTING MILESTONE: PDR Preliminary Design Review

RESULTING STATE: SS Specified State
RESULTING BASELINE: TSB Technical Specification Baseline
Figure 3 – Software requirements engineering phase

This phase is mostly run with Software Engineers/Architects and User Interaction Designers working closely to
Subject Matter Experts and representative users, if available. The UX Designer is responsible not only for running
the appropriate “client and user needs” investigation activities but also for materializing (e.g. sketching) the team’s
overall envisioned solution. Is also responsible for running the appropriate usability tests required to confirm
interaction design options and to minimize uncertainty at later project phases.
The Requirements Engineering phase – User Interaction technical component - is framed by the ISO 13407 -
Human-centred design processes for interactive systems [RD-7].
The software requirements engineering phase is completed by the Preliminary Design Review (PDR). The inputs
to the preliminary design review are: the software requirements specification, system architecture, the preliminary
interface control document and Solution Previews (e.g. mock-ups, lo-fi and/or hi-fi prototypes), all part of the
technical specification. The software architectural design and the User Interaction Solution Previews are reviewed
at the preliminary design review (or in a previous meeting). If the preliminary design review is completed
successfully the specified state is announced and the technical specification baseline is set.
During the preliminary design review the technical specification members of the development team (and external
members, if any) carefully study the software requirements, specification documents and Solution Previews. They
itemise and categorise each statement in the documents to uncover omissions, contradictions, TBDs, and
specifications that need clarification or amplification [RD-1].
Given the importance of the full set of technical specifications for the construction of the software
product, the PDR ends with the Client’s commitment and approval for the next project stage, upon review
of the documentation (SRS and User Interaction Solution previews, at bare minimum).
For systems engineering deliverables include the System Requirements Specification (YRS) and the System
Architecture Specification (YAS) (this last only if tailored in at this phase).

3.1.3. DESIGN ENGINEERING PHASE

The design engineering phase produces the software detailed design,

detailed user interface specification (form and behaviour), software code and
the unit tests of each element of the software product, in response to the Producing the detailed design and
requirements contained in the technical specification. It also outputs system source code in parallel allows the
design to be generated from source
usability tests specifications to run at Validation phase. User manuals and
code using reengineering tools.
installation manuals (SUM and SIM) are generally not produced at this phase Producing the unit testing in parallel
(being delivered in the next one) unless tailored in. The results of this phase with the coding allows the errors to be
are the input to the Critical Design Review (CDR), which signals the end of identified and corrected earlier.
the design phase. The state of the software project after critical design review
is called Defined State.
 Technical Specification Baseline (TSB)  Critical Design Review Report
 ENG.2 Software Design  Detailed design

 ENG.3 Software Construction  Detailed User Interface
 Source Code
 Usability Validation Plan
 Test script (unit testing)
 Test reports (unit testing and
coverage)
 Installation manual
 Design and user's documentation
(e.g. user manual)
 Verification reports
DELIVERABLES: DDS Detailed Design Specification

DUI Detailed User Interface
COD Source Code
TSC Test Scripts
TSR Test Report
USTP Usability Test Plan
CRR Code Review Report
SUM Software User Manual (if tailored in)
SIM Software Installation Manual (if tailored in)
RESULTING MILESTONE: CDR Critical Design Review

RESULTING STATE: DS Defined State
RESULTING BASELINE: DSB Design Baseline
Figure 4 – Design engineering phase

3.1.4. VALIDATION PHASE

The validation phase includes a Qualification Review (QR). The state of the software project after qualification
review is called qualified state.
The purpose of the validation phase is to verify the end-to-end functionality of the system in satisfying all
requirements and specifications (mainly system testing), including system usability verifications. During this
phase, the system test team executes the tests specified in the system. Usability tests are run by the project UX
Designers. The results obtained during test execution are documented, and the development team is notified of
any discrepancies. Repairs to software are handled by members of the development team in accordance with
stringent configuration management procedures. Corrected software is retested by the system test team, and
regression tests are executed to ensure that previously tested functions have not been adversely affected [RD-
1].

 Design Baseline (DSB)  Qualification Review Report
 ENG.4 Software Testing  Test script

 Test reports (integration/system testing)
 Acceptance data package (software
delivery on specified data medium)
 CUS.2 Delivery  Software release documentation
 Software non-conformance report
 Manuals (Installation, User, Admin.)
 Training materials
 Software document verification report
 Requirements traceability matrix
 Usability tests and results
DELIVERABLES: COD Source Code

RLR Release Report
BOM Bill of Materials
PCK Data Package
TSR Test Reports
MAN Manuals
RESULTING MILESTONE: QR Qualification Review

RESULTING STATE: QS Qualified State
RESULTING BASELINE: QB Qualification Baseline
Figure 5 – Validation phase

3.1.5. ACCEPTANCE PHASE
REQUIREMENTS DESIGN VALIDATION ACCEPTANCE OPERATIONS AND

ENGINEERING ENGINEERING MAINTENANCE
The acceptance phase includes an Acceptance Review (AR). The state of the software project after acceptance
review is called the accepted state.
The purpose of the acceptance phase is to demonstrate that the system meets its requirements in the operational
environment. The testing conducted during this phase is performed under the supervision of an independent
acceptance test team (on behalf of the customer) and follows the procedures specified in the acceptance test
plan. The development team provides training and support to the test team. They also correct any errors
uncovered during testing and update the system documentation to reflect software corrections [RD-1].
 Qualification Baseline (QB)  Acceptance Review Report

 Test script
 ENG.4 Software Testing
 Test reports (acceptance testing)
 Acceptance data package (release
SECONDARYPROCESSES package)
 CUS.2 Delivery  Software release documentation
 System
 Installation manual, User manual
 Customer satisfaction data
 Installation report
 Customer approval
 Lessons learned
DELIVERABLES: PCK Data Package

TSC Test Scripts
TSR Test Reports
MAN Manuals
STA Statement of Acceptance
RLR Release Report
RESULTING MILESTONE: AR Acceptance Review

RESULTING STATE: AS Accepted State
RESULTING BASELINE: AB Acceptance Baseline
Figure 6 – Acceptance phase

3.1.6. OPERATIONS AND MAINTENANCE PHASE
REQUIREMENTS DESIGN VALIDATION ACCEPTANCE OPERATIONS AND

ENGINEERING ENGINEERING MAINTENANCE
The operations and maintenance phase starts after completion of the acceptance review of the software. This
phase is very important since the success of software products is dependent on the level of operations that it can
provide to the customer organisation.
The maintenance process [AD-11] is activated when the software product undergoes any modification to code or
associated documentation as a result of correcting an error, a problem or implementing an improvement or
adaptation. Triggers to the maintenance process include bug reports and change requests.
The operations and maintenance may be invoked within warranty period or by a maintenance contract and ends
with the retirement of the software product, with the end of maintenance contract or with the end of warranty
period.
 Accepted Baseline (AB)  Retirement or End of

Maintenance Contract
 ENG.5 Maintenance  Maintenance/operation plan

 Problem analysis report
SECONDARYPROCESSES  System
 Non-conformance report
 Customer satisfaction data
 CUS.3 Contract management
 Change request
 Change control record
DELIVERABLES: COD Source Code

PCK Data Package
CSF Customer Satisfaction Form
SCR Software Change Request
OMP Operation and Maintenance Plan
RLR Release Report
RESULTING MILESTONE: NA
RESULTING STATE: NA
RESULTING BASELINE: NA
Figure 7 – Operation and maintenance phase

3.2. CONSTRAINTS
The constraints to be considered when instantiating a life cycle for a project are basically precedence constraints
(e.g., affecting the execution of some phases, processes or activities). Figure 8 presents the constraints
recommended for organising life cycle phases.
The software requirements engineering phase of the software development process consists on the elaboration
of the technical specification, which is the supplier’s response to the requirements baseline. This phase may start
in parallel or after the elaboration of the requirements baseline.
The design engineering phase shall not start before the System Requirements Review. It can start before the
Preliminary Design Review (PDR), but it is after the Preliminary Design Review that the results of the software
requirements engineering phase are reviewed and baseline to be used as inputs to the Design Engineering phase.
Given its importance on system design and project planning, the PDR requires an explicit client’s “Go/No
Go for next stage” approval.
The validation phase can start after the preliminary design review (e.g. unit testing will be executed during the
source code implementation). Only after the Critical Design Review (CDR) the validation of the technical
specification (system testing) should be performed.
The acceptance phase should start only after the validation phase is executed.
The operations and maintenance phase typically starts after acceptance review but it must not start before
qualification review.
Start constraint
REQUIREMENTS
ENGINEERING PHASE
DESIGN
ENGINEERING
PHASE
VALIDATION
PHASE
ACCEPTANCE
PHASE
OPERATIONS AND
MAINTENANCE
PHASE
SRR / KOM PDR CDR QR AR / PCM

SYSTEM REQ. PRELIMINARY CRITICAL DESIGN QUALIFICATION ACCEPTANCE
REVIEW DESIGN REVIEW REVIEW REVIEW REVIEW
FUNCTIONAL STATE SPECIFIED STATE DEFINED QUALIFIED ACCEPTED STATE

STATE STATE
Figure 8 – Software life cycle constraints

To be effective some milestones in the software development process are mandatory. The mandatory milestones
are KOM, PDR, QR and PCM. These milestones may be performed with different levels of formality depending
from the complexity of the project but evidences of their execution shall be provided. Note: PCM and AR are
typically combined, but may also be performed independently.
3.3. PROCESSES INVOKED IN ALL PHASES

There are other QMS processes not listed in the life cycle phases defined above (mainly support and
organisational processes) because these processes may (or may not) be in any phase depending from the project
needs. To have the complete list of life cycle processes see the Quality Management process [AD-3] and/or the
QMS Portal [AD-12].

4. SOFTWARE LIFE CYCLES SPECIFICS

According to the software development project types defined in 2.1 the specific characteristics and life cycle
examples relating each of the project types with the software development phases (presented in section 3) can
be found at the Project Life Cycles document [AD-2].
Nevertheless, these examples may not answer to all projects and other life cycle models may be created if
considered more convenient according to the project objectives and characteristics.

5. SOFTWARE DEVELOPMENT PROCESSES

Table 5, shows the primary life cycle (customer and engineering) processes considered in the Quality
Management System and indicates in which life cycle phases their usage is more relevant.
The support, management and organisational processes (not shown in Table 5) may be invoked at any time in
any phase of the life cycle. The list of all QMS processes is presented in the Quality Management document [AD-
3] and/or in the QMS Portal [AD-12]. Details on specific processes and its activities may be found on level 2
documents [AD-7][AD-8][AD-9][AD-10][AD-11] .
SOFTWARE DEVELOPMENT LIFE CYCLE PHASES
SYSTEM REQUIRE OPERATI

PROCESSES DESIGN
ENGINEE MENTS VALID ACCEPT ONS AND
ENGINEE
RING ENGINEE ATION ANCE MAINTEN
RING
RING ANCE
CUS.1 Purchasing X X X
CUS.2 Delivery X
CUS.3 Contract X X X X X X
Management
ENG.0 System Analysis X
ENG.1 Requirements X
X
Analysis
ENG.2 Software Design X X X
ENG.3 Software X
Construction
ENG.4 Software Testing X X
ENG.5 Maintenance X
Table 5 - Primary life cycle processes vs. life cycle phases



CSW QMS 2002 SDP 0909 Software Development

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSW QMS 2002 SDP 0909 Software Development

Uploaded by

Copyright:

Available Formats

CRITICAL SOFTWARE, S.A.

DISCLAIMER - CONTRACT REPORT.

© 2016 Copyright CRITICAL Software S.A. All Rights Reserved.

VERSION REVISION NAME FUNCTION SIGNATURE DATE

09 -- Délio Almeida Quality Manager 2016-09-29

AUTHORS AND CONTRIBUTORS

NAME DESCRIPTION DATE

André Carvalho Author 2002-11-11

Rui Cordeiro Author 2004-07-30

José Gonçalo Silva Author 2004-07-30

Luís Joaquim Contributor 2005-11-30

Délio Almeida Contributor 2013-01-29

Nelson Vilhena Contributor 2013-01-29

Joel Oliveira Contributor 2013-01-29

Neil Aries Contributor 2015-10-15

Russell Jugg Contributor 2015-10-15

Richard Coley Contributor 2015-10-15

Jorge Rodrigues Contributor 2015-10-15

Paulo Silva Reviewer 2015-10-15

Rodrigo Baptista Contributor 2016-07-11

PRINTED: 2016-10-06 | DOC. REF.: CSW-QMS-2002-SDP-0909 2/26

VERSION REVISION DATE DESCRIPTION AUTHOR

-- 1.10 2002-10-09 Initial version. André Carvalho,

01 1.17 2002-11-11 Formal review and approval. André Carvalho,

02 1.19 2004-07-30 Changes to incorporate the QMS structure Rui Cordeiro,

03 1.20 2005-01-14 CRITICAL’s addresses and structural José Gonçalo

04 1.21 2005-11-30 Changes resulting from process revision. Luis Joaquim

05 1.22 2006-03-15 Improvements in graphical layout. José Gonçalo

06 1.23 2006-04-24 Remove acronym SRR, Address changes Braselina Sousa

07 -- 2013-10-21 Inclusion of User Interaction Design activities Délio Almeida,

08 -- 2015-10-30 LeanQMS: Merge of PT and UK process Paulo Silva, Délio

09 -- 2016-08-30 LeanQMS Initiative: inclusion of the new Délio Almeida,

PRINTED: 2016-10-06 | DOC. REF.: CSW-QMS-2002-SDP-0909 3/26

PRINTED: 2016-10-06 | DOC. REF.: CSW-QMS-2002-SDP-0909 4/26

PRINTED: 2016-10-06 | DOC. REF.: CSW-QMS-2002-SDP-0909 5/26

1.4. DEFINITIONS AND ACRONYMS

A document is considered applicable if it complements this document. All

Reference Document A document is considered a reference if it is referred but not applicable to

BOM Bill of Materials

CDR Critical Design Review

CSW CRITICAL Software, SA

DBS Database Specification

DDS Detailed Design Specification

ECSS European Cooperation for Space Standardization

ESA European Space Agency

ICS Interface Control Specification

IMS Integrated Management System

PRINTED: 2016-10-06 | DOC. REF.: CSW-QMS-2002-SDP-0909 6/26

ISO International Organization for Standardization

NASA National Aeronautics and Space Administration

NCR Non-Conformance Report

QMS Quality Management system

PAR Product Assurance Report

PDR Preliminary Design Review

PLN Plan (Project Master Plan)

PCM Project Closedown Meeting

PMP Project Management Plan

QMS Quality Management System

RAMS Reliability, Availability, Maintainability and Safety

SAS Software Architectural Specification

SDP Software Development Process

SIM Software Installation Manual

SOW Statement of Work

SRS Software Requirements Specification