724hyd-026 29110-5-1 tr vse management and …pdtr+29110-5-1.3.pdf · iso/iec pdtr 29110-5-1.3 ©...

© ISO/IEC 2009 – All rights reserved

Document type: Technical Report Document subtype: Document stage: (30) Committee Document language: E 724HYD-026 29110-5-1 TR VSE Management and Engineering Guide for Basic Profile PDTR3 25JB STD Version 2.1c2

ISO/IEC JTC 1/SC 07 N ____

Date: 2009-07-09

ISO/IEC PDTR 29110-5-1.3

ISO/IEC JTC 1/SC 07/WG 24

Secretariat: SCC

Software Engineering — Lifecycle Profiles for Very Small Entities (VSEs) — Part 5-1: Management and Engineering Guide - Basic VSE Profile


ii © ISO/IEC 2009 – All rights reserved

Copyright notice

This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from ISO.

Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or to ISO's member body in the country of the requester:

[Indicate the full address, telephone number, fax number, telex number, and electronic mail address, as appropriate, of the Copyright Manger of the ISO member body responsible for the secretariat of the TC or SC within the framework of which the working document has been prepared.]

Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.


© ISO/IEC 2009 – All rights reserved III

Contents Page

Foreword ..........................................................................................................................................................v

Introduction....................................................................................................................................................vii

1 Scope...................................................................................................................................................1

2 Normative references .........................................................................................................................1

3 Terms and definitions.........................................................................................................................1

4 Basic VSE profile management and engineering guide...................................................................4 4.1 Introduction.........................................................................................................................................4 4.1.1 Overview..............................................................................................................................................4 4.1.2 Basic VSE profile guide general process description .....................................................................4 4.1.3 Process structure description and notation .....................................................................................5 4.2 Project Management (PM) process....................................................................................................7 4.2.1 PM purpose .........................................................................................................................................7 4.2.2 PM objectives ......................................................................................................................................7 4.2.3 PM input products ..............................................................................................................................9 4.2.4 PM output products ..........................................................................................................................10 4.2.5 PM internal products ........................................................................................................................10 4.2.6 PM roles involved .............................................................................................................................10 4.2.7 PM diagram .......................................................................................................................................10 4.2.8 PM Activities......................................................................................................................................12 4.3 Software Implementation (SI) process ............................................................................................19 4.3.1 SI purpose .........................................................................................................................................19 4.3.2 SI objectives......................................................................................................................................19 4.3.3 SI input products ..............................................................................................................................21 4.3.4 SI output products ............................................................................................................................22 4.3.5 SI internal products ..........................................................................................................................22 4.3.6 SI roles involved ...............................................................................................................................22 4.3.7 SI diagram .........................................................................................................................................23 4.3.8 SI activities ........................................................................................................................................24 4.3.9 SI Incorporation to the Project Repository .....................................................................................31 4.4 Roles ..................................................................................................................................................33 4.5 Product description ..........................................................................................................................35 4.6 Software tools requirements............................................................................................................41 4.6.1 Project Management process ..........................................................................................................41 4.6.2 Software Implementation process...................................................................................................41

Annex A ..........................................................................................................................................................43

Bibliography...................................................................................................................................................45

Table of illustrations

Figure I-1 29110 Set of Documents ................................................................................................................ viii

Figure 4.1-1 – Basic profile guide processes (diagram notation is explained in section 4.1.3) .......................... 5

Figure 2 – Project Management process iagram............................................................................................. 11


iv © ISO/IEC 2009 – All rights reserved

Figure 3 – Software Implementation Process Diagram. .................................................................................. 23


© ISO/IEC 2009 – All rights reserved V

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.

In exceptional circumstances, the joint technical committee may propose the publication of a Technical Report of one of the following types:

— type 1, when the required support cannot be obtained for the publication of an International Standard, despite repeated efforts;

— type 2, when the subject is still under technical development or where for any other reason there is the future but not immediate possibility of an agreement on an International Standard;

— type 3, when the joint technical committee has collected data of a different kind from that which is normally published as an International Standard (“state of the art”, for example).

Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether they can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to be reviewed until the data they provide are considered to be no longer valid or useful.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

ISO/IEC TR 29110-5-1, which is a Technical Report of type 3, was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology, Subcommittee SC 07, Systems and Software Engineering.

ISO/IEC TR 29110 consists of the following parts, under the general title Software Engineering — Lifecycle Profiles for Very Small Entities (VSEs):

⎯ Part 1: Overview (TR)

⎯ Part 2: Framework and Taxonomy (ISP)

⎯ Part 3: Assessment Guide (TR)

⎯ Part 4: Profile Specifications

⎯ Part 4-1: Basic Profile Specification (ISP)

⎯ Part 4-n: Profile n Specification (ISP)


vi © ISO/IEC 2009 – All rights reserved

⎯ Part 5: Management and Engineering Guides

⎯ Part 5-1: Management and Engineering Guide for Basic Profile (TR)

⎯ Part 5-n: Management and Engineering Guide for Profile n (TR)


© ISO/IEC 2009 – All rights reserved VII

Introduction

The software industry recognizes the value of Very Small Entities (VSEs) in contributing valuable products and services. For the purpose of this document, a Very Small Entity (VSE) is defined as an entity (enterprise, organization, department or project) having up to 25 people. VSEs also develop and/or maintain software that is used in larger systems, therefore, recognition of VSEs as suppliers of high quality software is often required.

According to the Organization for Economic Co-operation and Development (OECD) SME and Entrepreneurship Outlook report (2005) ‘SMEs constitute the dominant form of business organisation in all countries world-wide, accounting for over 95% and up to 99% of the business population depending on country’. The challenge facing OECD governments is to provide a business environment that supports the competitiveness of this large heterogeneous business population and that promotes a vibrant entrepreneurial culture.

From studies and surveys conducted, it is clear that the majority of ISO/IEC standards do not address the needs of VSEs. Conformance with these standards is difficult, if not impossible. Subsequently VSEs have no, or very limited, ways to be recognized as entities that produce quality software in their domain. Therefore, VSEs are often cut off from some economic activities.

It has been found that VSEs find it difficult to relate ISO/IEC standards to their business needs and to justify the application of the standards to their business practices. Most VSEs can neither afford the resources, in terms of number of employees, budget and time, nor do they see a net benefit in establishing software life cycle processes. To rectify some of these difficulties, a set of guides have been developed according to a set of VSE characteristics. The guides are based on subsets of appropriate standards elements, referred to as VSE Profiles. The purpose of a VSE profile is to define a subset of ISO/IEC standards relevant to the VSE context, for example, processes and outcomes of ISO/IEC 12207 and products of ISO/IEC 15289.

The ISO/IEC 29110 Set of Documents, targeted by audience, has been developed to improve product and/or service quality, and process performance. These are:

⎯ Part 1: Overview;

⎯ Part 2: Framework and Taxonomy;

⎯ Part 3: Assessment Guide;

⎯ Part 4: Profile Specifications and

⎯ Part 5: Management and Engineering Guides.

Parts 1 and 5 are targeted to VSEs, Part 3 is targeted for Assessors and VSEs and Parts 2 and 4 are targeted for standards producers, tool vendors and methodology vendors. If a new profile is needed, Parts 4 and 5 can be developed without impacting existing documents and they become Part 4-x and Part 5-x respectively through the ISO/IEC process.

ISO/IEC 29110-1 defines the business terms common to the VSE Profile Set of Documents. It introduces processes, lifecycle and standardization concepts, and the ISO/IEC 29110 Set of Documents. It also introduces the business aspects, characteristics and requirements of a VSE, and clarifies the rationale for VSE-specific profiles, documents, standards and guides.

ISO/IEC 29110-2 introduces the concepts for Software Engineering International Standardized Profile (ISP) for VSEs, and defines the terms common to the VSE Profile Set of Documents. It establishes the logic behind


viii © ISO/IEC 2009 – All rights reserved

the definition and application of ISP profiles. It specifies the elements common to all ISP profiles (structure, conformance, assessment) and introduces the taxonomy (catalogue) of ISO/IEC 29110 profiles.

ISO/IEC 29110-3 defines the process assessment guidelines and compliance requirements needed to meet the purpose of the defined VSE Profiles. ISO/IEC 29110-3 also contains information that can be useful to developers of assessment methods and assessment tools. ISO/IEC 29110-3 is addressed to people who have direct relation with the assessment process, e.g. the assessor and the sponsor of the assessment, who need guidance on ensuring that the requirements for performing an assessment have been met.

ISO/IEC 29110-4-x provides the specification for Profiles that are based on subsets of appropriate standards elements. VSE Profiles apply and are targeted to authors/providers of guides and authors/providers of tools and other support material.

ISO/IEC 29110-5-x provides an implementation management and engineering guide for the Nnnn VSE Profile described in ISO/IEC ISP 29110 Part 4-x.

Figure 1-1 describes the ISO/IEC 29110 Set of Documents and positions them within the framework of reference. TR means Technical Report.

29110 Guides (TR)

Assessment Guide (TR 29110-3)

Management and Engineering Guide (TR 29110-5)

Management and Engineering Guide – NnnnVSE Profile(TR 29110-5-x)

29110 ISPs

Framework and Taxonomy (ISP 29110-2)

Specificationsof VSE Profiles (ISP 29110-4)

Specification - Nnnn VSE Profile(ISP 29110-4-x)

29110 Overview (TR 29110-1)

Figure I-1 29110 Set of Documents

COMMITTEE DRAFT ISO/IEC PDTR 29110-5-1.3

© ISO/IEC 2009 – All rights reserved 1

Software Engineering — Lifecycle Profiles for Very Small 1

Entities (VSEs) — Part 5-1: Management and Engineering Guide 2

- Basic VSE Profile 3

1 Scope 4

This Technical Report is applicable to Very Small Entities (VSEs). VSEs are enterprises, organizations, 5 departments or projects up to 25 people. The life cycle processes described in the set of ISP and Technical 6 Reports are not intended to preclude or discourage their use by organizations bigger than VSEs. 7 8 This document provides Management and Engineering Guide to the Basic VSE Profile described in ISO/IEC 9 ISP 29110 Part 4-1 through Project Management and Software Implementation processes. 10 11 The Guide applies for software development project. The project may be to fulfil an external or internal 12 contract. The internal contract need not be explicit between the project team and their customer. 13 14 Using the Guide, VSE can obtain benefits in the following aspects: 15 16 ⎯ An agreed set of project requirements and expected products is delivered to the customer; 17

⎯ A disciplined management process, that provides project visibility and corrective actions of project 18 problems and deviations, is performed; 19

⎯ A systematic software implementation process, that satisfies customer needs and ensures quality 20 products, is followed. 21

This Guide is intended to be used with any processes, techniques and methods that enhance the VSEs 22 customer satisfaction and productivity. 23

2 Normative references 24

ISO/IEC ISP 29110-4-1 Software engineering — Lifecycle profiles for very small enterprises - Part 4-1: Basic 25 Profile Specification (ISP). 26

NOTE The purpose of the reference to 29110-4-1 is to document that 29110-5-1 is based on the ISP 29110-4-27 1. 29110-5-1 is a stand alone guide. It is not intended for a VSE to use the ISP to implement the 29110-5-1 guide. 28

3 Terms and definitions 29

For the purposes of this Technical Report, the following terms and definitions apply. 30 31

3.1 32 activity 33 a set of cohesive tasks of a process 34 35 [ISO 12207:2008] 36 37


2 © ISO/IEC 2009 – All rights reserved

3.2 38 baseline 39 a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the 40 basis for further development, and that can be changed only through formal change control procedures 41 42 [ISO 12207:2008] 43 44 3.3 45 correction 46 action to eliminate a detected nonconformity (3.6.2) 47 NOTE A correction can be, for example, rework (3.6.7) or regrade (3.6.8). 48 49 [ISO 9000:2005] 50 51

3.4 52 customer 53 organization or person that receives a product or service 54 55

NOTE 1 A customer can be internal or external to the organization. 56 57 [ISO/IEC 12207: 2008] 58 59 60 3.5 61 guide 62 document published by ISO or IEC giving rules, orientation, advice or recommendations relating to 63 international standardization. 64 65 [ISO/IEC Directives, Part 2] 66 67 3.6 68 international standardized profile (ISP) 69 an internationally agreed-to, harmonized document which describes one or more profiles. 70 71 [ISO/IEC TR 10000-1] 72 73 3.7 74 process 75 set of interrelated or interacting activities which transforms inputs into outputs 76 77 [ISO 9000:2005] 78 79 3.8 80 profile 81 a set of one or more base standards and/or ISPs, and, where applicable, the identification of chosen classes, 82 conforming subsets, options and parameters of those base standards, or ISPs necessary to accomplish a 83 particular function. 84 85 [ISO/IEC TR 10000-1] 86 87 3.9 88 project 89 an endeavour with defined start and finish dates undertaken to create a product or service in accordance with 90 specified resources and requirements 91 92 [ISO 12207:2008] 93



3.10 94 life cycle 95 the evolution of a system, product, service, project or other human-made entity from conception through 96 retirement. 97 98 [ISO/IEC 12207:2008 and ISO/IEC 15288:2008] 99 100 3.11 101 record 102 work product stating results achieved or provides evidence of activities performed in a process 103 an item that is part of a set of identifiable and retrievable data 104 105 [ISO/IEC 15504-5] 106 107 3.12 108 review 109 A process or meeting during which a software product is presented to project personnel, mangers, users, customers, user 110 representatives, or other interested parties for comment or approval. 111 112 [ISO/IEC 1028]" 113 114 3.13 115 report 116 describe the results of activities such as investigations, assessments, and tests 117 118 [ISO/IEC 15289] 119 120 3.14 121 task 122 requirement, recommendation, or permissible action, intended to contribute to the achievement of one or more 123 outcomes of a process 124 125 [ISO/IEC 12207:2008] 126 127 3.15 128 user 129 individual or group that benefits from a system during its utilization 130 131 [ISO/IEC 12207:2008] 132 133 3.16 134 validation 135 confirmation, through the provision of objective evidence, that the requirements for a specific intended use or 136 application have been fulfilled 137 138 [ISO 9000:2005] 139 NOTE Validation in a life cycle context is the set of activities ensuring and gaining confidence that a system is 140 able to accomplish its intended use, goals and objectives. 141

3.17 142 verification 143 confirmation, through the provision of objective evidence, that specified requirements have been fulfilled 144 145 [ISO 9000:2005] 146 NOTE Verification in a life cycle context is a set of activities that compares a product of the life cycle against the required 147 characteristics for that product. This may include, but is not limited to, specified requirements, design description and the 148 system itself 149



4 Basic VSE profile management and engineering guide 150

4.1 Introduction 151

4.1.1 Overview 152

The Basic VSE Profile Management and Engineering Guide applies to a Very Small Entity (VSE), enterprise, 153 organisation, department or project up to 25 people, dedicated to software development. The project may fulfil 154 an external or internal contract. The internal contract between the project team and its customer need not be 155 explicit. 156

The Guide provides Project Management and Software Implementation processes which integrate practices 157 based on the selection of ISO/IEC 12207- Systems and Software Engineering —Software Life Cycle 158 Processes and ISO/IEC 15289 Software Engineering – Software Life Cycle Process – guidelines for the 159 content of software life cycle process information products (documentation) standards elements. Annex A 160 provides an exemplar of Deployment Packages which will facilitate the implementation of these processes. 161

Using the Guide, VSE can obtain benefits in the following aspects: 162 163 ⎯ An agreed set of project requirements and expected products is delivered to the customer; 164

⎯ A disciplined management process, that provides project visibility and corrective actions of project 165 problems and deviations, is performed; 166

⎯ A systematic software implementation process, that satisfies customer needs and ensures quality 167 products, is followed. 168

To use the Guide the VSE needs the following entry conditions: 169

⎯ Project statement of work is documented; 170

⎯ Feasibility of the project was performed before its start; 171

⎯ Project team, including project manager, is assigned and trained; and 172

⎯ Goods, services and infrastructure to start the project are available. 173

4.1.2 Basic VSE profile guide general process description 174

The purpose of the Project Management process is to establish and carry out in a systematic way the tasks of 175 the software implementation project, which allows complying with the project’s objectives in the expected 176 quality, time and cost. 177

The purpose of the Software Implementation process is the systematic performance of the analysis, design, 178 construction, integration and tests activities for new or modified software products according to the specified 179 requirements. 180

Both processes are interrelated (see Figure 4.1-1). 181



182

183

Figure 4.1-1 – Basic profile guide processes (diagram notation is explained in section 4.1.3) 184

PM process uses the customer’s statement of work to elaborate the project plan. The PM project assessment 185 and control tasks compare the project progress against the project plan and actions are taken to eliminate 186 deviations or incorporate changes to the project plan. The PM project closure activity delivers the software 187 configuration, produced by SI, and gets the customer’s acceptance to formalize the end of the project. A 188 project repository is established to save the work products and to control its versions during the project. 189

The execution of the SI process is driven by the project plan. SI process starts with an initiation activity of the 190 project plan review. Project plan will guide the execution of the software requirements analysis, software 191 architectural and detailed design, software construction, software integration and test, and product delivery 192 activities. 193

To remove product´s defects verification, validation and test tasks are included in the activities workflow. 194

The customer provides a statement of work as an input to Project Management process and receives a 195 software configuration as a result of Software Implementation process execution (see figure 4.1-1). 196

4.1.3 Process structure description and notation 197

The following elements are used to describe the processes: 198

Name – process identifier, followed by its abbreviation in brackets “( )”. 199

Purpose - general goals and results expected of the effective implementation of the process. The 200 implementation of the process should provide tangible benefits to the stakeholders. The purpose is identified 201 by the abbreviation of the process name. 202

Objectives - specific goals to ensure the accomplishment of the process purpose. The objectives are 203 identified by the abbreviation of the process name, followed by the letter “O” and a consecutive number, for 204 example PM.O1, SI.O2, etc. Each objective is followed by the square box which includes a list of the chosen 205 processes for the basic profile from ISO/IEC 12207 and its outcomes related to the objective. 206

Input Products – products required to perform the process and its corresponding source, which can be 207 another process or an external entity to the project, such as the Customer. Identified by the abbreviation of the 208 process name and showed as two column table of product names and sources. 209

Output Products – products generated by the process and its corresponding destination, which can be 210 another process or an external entity to the project, such as Customer or Organizational Management. 211 Identified by the abbreviation of the process name and showed as two column table of product names and 212 destinations. 213

Internal Products – products generated and consumed by the process. Identified by the abbreviation of the 214 process name and showed as one column table of the product names. 215



All product´s names are printed in cursive and initiate with capital letters. Some products have one or more 216 statuses attached to the product name surrounded by square brackets “[ ]”and separated by”,”. The product 217 status may change during the process execution. See 5.5 for the alphabetical list of the products, its 218 descriptions, possible statuses and the source of the product. The source can be another process or an 219 external entity to the project, such as the Customer. 220

Roles involved – names and abbreviation of the functions to be performed by project team members. Several 221 roles may be played by a single person and one role may be assumed by several persons. The role list is 222 identified by the abbreviation of the process name and showed as two column table. See 5.4 for the 223 alphabetical list of the roles, its abbreviations and required competencies description. 224

Diagram – graphical representation of the processes. The large round-edged rectangles indicate process or 225 activities and the smaller square-edged rectangles indicate the products. The directional or bidirectional thick 226 arrows indicate the major flow of information between processes or activities and thin arrows indicate the input 227 or output of the products. The notation used in the diagrams does not imply the use of any specific process 228 lifecycle. 229

Activity – a set of cohesive tasks. Task is a requirement, recommendation, or permissible action, intended to 230 contribute to the achievement of one or more objectives of a process. A process activity is the first level of 231 process workflow decomposition and the second one is a task. Activities are identified by process name 232 abbreviation followed by consecutive number and the activity name. 233

Activity Description - each activity description is identified by the activity name and the list of related 234 objectives surrounded by brackets “( )”, for example PM.1 Project Planning (PM.O1, PM.O5, PM.O6, PM.O7). 235 The meaning is that the activity tasks contribute to the achievement of the listed objectives. The activity 236 description begins with tasks summary and is followed by the tasks descriptions table. The task description 237 doesn´t impose any technique or method to perform it. The selection of the techniques or methods is left to 238 the VSE or project team. 239

Tasks description table contain four columns corresponding to: 240

⎯ Role- the abbreviation of roles involved in the task execution. 241

⎯ Task - description of the task to be performed. Each task is identified by activity ID and consecutive 242 number, for example PM1.1, PM1.2, and so on. 243

⎯ Input Products - products needed to execute the task. 244

⎯ Output Products - products created or modified by the execution of the task. 245

246 Incorporation to Project Repository – list of products to be saved in project repository; the Version Control 247 Strategy has to be applied to some of them (see 5.3.8 and 5.3.9). It is useful as a checklist for project 248 manager and technical leader. 249

NOTE Tables used in process description are for presentation purpose only. 250



251

4.2 Project Management (PM) process 252

4.2.1 PM purpose 253

The purpose of the Project Management process is to establish and carry out in a systematic way the tasks of 254 the software implementation project, which allows complying with the project’s objectives in the expected 255 quality, time and costs. 256

4.2.2 PM objectives 257

PM.O1. The Project Plan for the execution of the project is developed according to the Statement of Work and 258 validated with the Customer. The tasks and resources necessary to complete the work are sized and 259 estimated. 260

261

PM.O2. Progress of the project is monitored against the Project Plan and recorded in the Progress Status 262 Record. Corrections to remediate problems and deviations from the plan are taken when project targets are 263 not achieved. . Appropriate treatment is taken to correct or avoid the impact of risk. Closure of the project is 264 performed to get the Customer acceptance documented in the Acceptance Record. 265

6.3.1 Project Planning Process a) the scope of the work for the project is defined; c) the tasks and resources necessary to complete the work are sized and estimated; d) interfaces between elements in the project, and with other project and organizational units, are identified; e) plans for the execution of the project are developed; and f) plans for the execution of the project are activated. 6.3.7 Measurement Process a) the information needs of technical and management processes are identified.

[ISO/IEC 12207, 6.3.1, 6.3.7]



266

PM.O3. The Change Requests are addressed through their reception and analysis. Changes to software 267 requirements are evaluated for cost, schedule and technical impact. 268

269

270

271

272

PM.O4. Review meetings with the Work Team and the Customer are held. Agreements are registered and 273 tracked. 274

275

276

277

278

279

PM.O5. Risks are identified as they develop and during the conduct of the project. 280

6.3.2 Project Assessment and Control Process a) progress of the project is monitored and reported; c) actions to correct deviations from the plan and to prevent recurrence of problems identified in the project, are taken when project targets are not achieved; and d) project objectives are achieved and recorded. 6.3.7 Measurement Process d) the required data are collected, stored, analyzed, and the results interpreted; and e) information products are used to support decisions and provide an objective basis for communication. 6.4.8 Software Acceptance Support Process a) the product is completed and delivered to the acquirer; 7.2.8 Software Problem Resolution Process b) problems are recorded, identified and classified; and e) problems are tracked to closure.

[ISO/IEC 12207, 6.3.2, 6.3.7, 6.4.8, 7.2.8]

7.1.2 Software Requirements Analysis Process g) changes to the software requirements are evaluated for cost, schedule and technical impact.

[ISO/IEC 12207, 7.1.2]

7.2.6 Software Review Process a) management and technical reviews are held based on the needs of the project; c) review results are made known to all affected parties; d) action items resulting from reviews are tracked to closure.

[ISO/IEC 12207, 7.2.6]



281

PM.O6. A software Version Control Strategy is developed. Items of Software Configuration are identified, 282 defined and baselined. Modifications and releases of the items are controlled and made available to the 283 Customer and Work Team including the storage, handling and delivery of the items. 284

285

PM.O7. Software Quality Assurance is performed to provide assurance that work products and processes 286 comply with the Project Plan and Requirements Specification. 287

Note: The implementation of the Software Quality Assurance process is through the performance of the 288 verifications, validations and review tasks performed in Project Management and Software Implementation 289 processes. 290

291

4.2.3 PM input products 292

Name Source

Statement of Work Customer

Resources Organizational Management

6.3.4 Risk Management Process c) risks are identified as they develop and during the conduct of the project; 7.2.6 Software Review Process e) risks and problems are identified and recorded.

[ISO/IEC 12207, 6.3.4, 7.2.6]

7.2.3 Software Quality Assurance Process a) a strategy for conducting quality assurance is developed; b) evidence of Software quality assurance is produced and maintained; c) problems and/or non-conformance with requirements are identified and recorded; and d) adherence of products, processes and activities to the applicable standards, procedures and requirements are verified.

[ISO/IEC 12207,7.2.3 ]

7.2.2 Software Configuration Management Process a) a software configuration management strategy is developed; b) items generated by the process or project are identified, defined and baselined; c) modifications and releases of the items are controlled; d) modifications and releases are made available to affected parties; g) the storage, handling and delivery of the items are controlled.

[ISO/IEC 12207, 7.2.2]



Software Configuration Software Implementation

Change Request Customer

Software Implementation

4.2.4 PM output products 293

Name Destination

Project Plan Software Implementation

Acceptance Record Organizational Management

Project Repository Software Implementation

Meeting Record Customer

Software Configuration Customer

4.2.5 PM internal products 294

Name

Change Request

Correction Register

Meeting Record

Verification Results

Validation Results

Progress Status Record

Project Repository Backup

4.2.6 PM roles involved 295

Role Abbreviation

Customer CUS

Project Manager PM

Technical Leader TL

Work Team WT

4.2.7 PM diagram 296

The following diagram shows the flow of information between the Project Management Process activities 297 including the most relevant work products and their relationship. 298

299



300

Figure 2 – Project Management process iagram. 301



4.2.8 PM Activities 302

The Project Management Process has the following activities: 303 ⎯ PM.1 Project Planning 304

⎯ PM.2 Project Plan Execution 305

⎯ PM.3 Project Assessment and Control 306

⎯ PM.4 Project Closure 307

4.2.8.1 PM.1 Project planning, (PM.O1, PM.O5, PM.O6, PM.O7) 308

The Project Planning activity documents the planning details needed to manage the project. The activity 309 provides: 310

⎯ Reviewed Statement of Work and the tasks needed to provide the contract deliverables and to satisfy 311 customer requirements. 312

⎯ Project life cycle, including task dependencies and duration. 313

⎯ Project quality assurance strategy through verification and validation of work products/deliverables, 314 customer and work team reviews. 315

⎯ Work team and customer roles and responsibilities. 316

⎯ Project resources and training needs. 317

⎯ Estimates of effort, cost and schedule. 318

⎯ Identified project risks. 319

⎯ Project version control and baseline strategy. 320

⎯ Project repository to store, handle and deliver controlled product and document versions and baselines. 321

Role Task List Input Products Output Products

PM

TL

PM.1.1 Review the Statement of Work Statement of Work Statement of Work [reviewed]

PM

CUS

PM.1.2 Define with the Customer the Delivery Instructions of each one of the deliverables specified in the Statement of Work.

Statement of Work[reviewed]

Delivery Instructions

PM

TL

PM.1.3 Identify the specific tasks to be performed in order to produce the deliverables and their software components identified in the Statement of Work. Include verification, validation and reviews with Customer and Work Team tasks to assure the quality of work products. Identify the tasks to perform the Delivery Instructions. Document the Tasks.

Statement of Work[reviewed]

Tasks




PM

TL

PM.1.4 Establish the Estimated Duration to perform each task.

Tasks Estimated Duration

PM

TL

PM.1.5 Identify and document the resources: human, material, equipment and tools, including the required training of the Work Team to perform the project. Include in the schedule the dates when resources and training will be needed.

Statement of Work Resources

PM

TL

PM.1.6 Establish the Composition of Work Team assigning roles and responsibilities according to the Resources.

Resources Composition of Work Team

PM

TL

PM.1.7 Assign estimated start and completion dates to each one of the tasks in order to create the Schedule of the Project Tasks taking into account the assigned resources, sequence and dependency of the tasks.

Tasks

Estimated Duration

Composition of Work Team

Schedule of the Project Tasks

PM PM.1.8 Calculate and document the project Estimated Effort and Cost.

Schedule of the Project Tasks

Resources

Estimated Effort and Cost

PM

TL

PM.1.9 Identify and document the risks which may affect the project.

All elements previously defined

Identification of Project Risks

PM

TL

PM.1.10 Document the Version Control Strategy in the Project Plan.

Version Control Strategy

PM PM.1.11 Generate the Project Plan or update it. Furthermore, the Project Plan can be updated due to the Change Request made by the Customer or arising from the project.

Tasks

Estimated Duration

Resources

Composition of Work Team

Schedule of the Project Task

Estimated Effort and Cost

Identification of Project Risks



Change Request

Project Plan

PM PM.1.12 Include product description, scope, objectives and deliverables in the Project

Statement of Work

(Product Description,

Project Plan




TL Plan. Scope, Objectives and Deliverables)

PM

TL

PM.1.13 Verification of the Project Plan.

Verify that all Project Plan elements are viable and consistent. The results found are documented in a Verification Results and corrections are made until the document is approved by TL.

Project Plan Verification Results

Project Plan [verified]

PM

CUS

PM.1.14 Validation of the Project Plan.

Validate that the Project Plan elements definition match with the Statement of Work. The results found are documented in a Validation Results and corrections are made until the document is approved by CUS.

Project Plan [verified] Validation Results

Project Plan [validated]

PM

TL

PM.1.15 Establish or prepare the project repository using the Version Control Strategy.


Project Repository



4.2.8.2 PM.2 Project plan execution (PM.O2, PM.O3, PM.O4, PM.O5, PM.O7) 322

The Project Plan Execution activity implements the documented plan on the project. The activity provides: 323

⎯ Agreement with the Project Manager (PM) and Technical Leader (TL) on the tasks assignments. 324

⎯ Progress Status Record of the project updated. 325

⎯ Analyzed and evaluated change requests to the plan impacting cost, schedule and technical 326 requirements. 327

⎯ Approved changes to the plan 328

⎯ Reviews and agreements with the Work Team (WT) and Customer (CUS). 329

⎯ Back up of the Project Repository, and its recovery if necessary. 330


PM

TL

WT

PM.2.1 Review the Project Plan and record actual data in Progress Status Record.

Project Plan Progress Status Record

PM

TL

PM.2.2 Analyze and evaluate the Change Request for cost, schedule and technical impact, and include the accepted changes in the Project Plan.

The Change Request can be initiated externally by the Customer or internally by the Work Team.

The evaluation of Change Request initiated by Customer or those which affects the Customer needs. Negotiate with Customer to obtain its acceptance (see PM.2.4).

Change Request[initiated]

Project Plan

Change Request[evaluated]

Project Plan[changed]

PM

TL

WT

PM.2.3 Conduct revision meetings with the Work Team, review risk status, record agreements and track them to closure.

Project Plan


Correction Register

Meeting Record

Meeting Record [updated]

PM

CUS

TL

WT

PM.2.4 Conduct revision meetings with the Customer, record agreements and track them to closure. Change Request initiated by Customer or initiated by Work Team, which affects the Customer, needs to be negotiated to reach acceptance of both parties.

Project Plan


Change Request[evaluated]

Meeting Record

Meeting Record [updated]

Change Request[accepted]

PM PM.2.5 Perform backup according to the Version Control Project Repository




Version Control Strategy. Strategy Backup

PM PM.2.6 Perform Project Repository recovery using the Project Repository Backup, if necessary.

Project Repository Backup

Project Repository [recovered]



4.2.8.3 PM.3 Project assessment and control (PM.O2) 331

The Project Assessment and Control activity monitors and evaluates the performance of the plan against 332 documented commitments. The activity provides: 333

⎯ Reviews of actual plan performance and progress against targets. 334

⎯ Identified and evaluated significant cost, schedule and technical performance deviations and problems. 335

⎯ Review of project risks and identification of new risks. 336

⎯ Documented change requests, appropriate corrective action defined, and changes tracked to closure. 337


PM

TL

WT

PM.3.1 Evaluate project progress with respect to the Project Plan, comparing:

- actual tasks against planned tasks - actual results against established

project objectives - actual resource allocation against

planned resources - actual cost against budget estimates - actual time against planned schedule- actual risk against previously

identified

Project Plan


Progress Status Record [evaluated]

PM

TL

WT

PM.3.2 Establish actions to correct deviations or problems and identified risks concerning the accomplishment of the plan, as needed, document them in Correction Register and track them to closure.

Progress Status Record [evaluated]

Correction Register

PM

TL

WT

PM.3.3 Identify changes to requirements and/or Project Plan to address major deviations, potential risks or problems concerning the accomplishment of the plan, document them in Change Request and track them to closure.


Change Request[initiated]



338

4.2.8.4 PM.4 Project closure (PM.O2) 339

The Project Closure activity provides the project’s documentation and products in accordance with contract 340 requirements. The activity provides: 341

⎯ Delivery of the product as specified in the Delivery Instructions. 342

⎯ Support of Customer product acceptance in accordance to Delivery Instructions. 343

⎯ Completion of the project and sign of the Acceptance Record. 344

Role Task List Input Output

PM

CUS

PM.4.1. Formalize the completion of the project according to the Delivery Instructions established in the Project Plan, providing acceptance support and getting the Acceptance Record signed.

Project Plan

Software Configuration[delivered]

Acceptance Record

Software Configuration [accepted]

PM PM.4.2 Update Project Repository. Software Configuration [accepted]

Project Repository

Project Repository [updated]

4.2.8.5 PM Incorporation to Project Repository 345

The list of products to be saved in Project Repository. After the incorporation, Version Control Strategy has to 346 be applied to: Project Plan. 347

Product

Project Plan

Change Request

Acceptance Record

Meeting Record

Correction Register



Validation Results

348



4.3 Software Implementation (SI) process 349

4.3.1 SI purpose 350

The purpose of the Software Implementation process is the systematic performance of the analysis, design, 351 construction, integration and tests activities for new or modified software products according to the specified 352 requirements. 353

4.3.2 SI objectives 354

SI.O1. Tasks of the activities are performed through the accomplishment of the current Project Plan. 355

SI.O2. Software requirements are defined, analyzed for correctness and testability, approved by the Customer, 356 baselined and communicated. 357

358

SI.O3. Software architectural and detailed design is developed and baselined. It describes the software items 359 and internal and external interfaces of them. Consistency and traceability to software requirements are 360 established. 361

362

7.1.3 Software Architectural Design Process a) a software architectural design is developed and baselined that describes the software items that will implement the software requirements; b) internal and external interfaces of each software item are defined; and c) consistency and traceability are established between software requirements and software design. 7.1.4 Software Detailed Design Process a) a detailed design of each software component, describing the software units to be built, is developed; b) external interfaces of each software unit are defined; and c) consistency and traceability are established between the detailed design and the requirements and architectural design. 7.1.5 Software Construction Process a) verification criteria are defined for all software units against their requirements;

[ISO/IEC 12207, 7.1.3, 7.1.4,7.1.5]

6.4.1 Stakeholder Requirements Definition Process a) the required characteristics and context of use of services are specified. 7.1.2 Software Requirements Analysis 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; f) the software requirements are approved and updated as needed; and h) the software requirements are baselined and communicated to all affected parties.

[ISO/IEC 12207, 6.4.1, 7.1.2]



NOTE Note: Software Architecture and Detailed Design can be performed separately according to the project 363 schedule. 364

SI.O4. Software components defined by the design are produced. Unit test are defined and performed to 365 verify the consistency with requirements and the design. Traceability to the requirements and design are 366 established. 367

368

SI.O5. Software is produced performing integration of software components and verified using Test Cases 369 and Test Procedures. Results are recorded at the Test Report. Defects are corrected and consistency and 370 traceability to Software Design are established. 371

372

SI.O6. A Software Configuration, that meets the Requirements Specification as agreed to with the Customer, 373 which includes user, operation and maintenance documentations is integrated, baselined and stored at the 374 Project Repository. Needs for changes to the Software Configuration are detected and related Change 375 Requests are initiated. 376

7.1.6 Software Integration Process c) software items are verified using the defined criteria; d) software items defined by the integration strategy are produced; e) results of integration testing are recorded; f) consistency and traceability are established between software design and software items; 7.1.7 Software Qualification Testing Process a) criteria for the integrated software is developed that demonstrates compliance with the software requirements; b) integrated software is verified using the defined criteria; and c) test results are recorded.

[ISO/IEC 12207, 7.1.6, 7.1.7]

7.1.5 Software Construction Process b) software units defined by the design are produced; c) consistency and traceability are established between software units and requirements and design; and d) verification of the software units against the requirements and the design is accomplished.

[ISO/IEC 12207, 7.1.5]



377

SI.O7. Verification and Validation tasks of all required work products are performed using the defined criteria 378 to achieve consistency among output and input products in each activity. Defects are identified, and corrected; 379 records are stored in the Verification/Validation Results. 380

381

NOTE: It’s not the intention that all verification activities and work products are made available to the customer. 382

4.3.3 SI input products 383

Name Source

Project Plan Project Management

Project Repository Project Management

384

7.2.4 Software Verification Process a) a verification strategy is developed and implemented; b) criteria for verification of all required software work products is identified; c) required verification activities are performed; d) defects are identified and recorded; and e) results of the verification activities are made available to the customer and other involved parties. 7.2.5 Software Validation Process a) a validation strategy is developed and implemented; b) criteria for validation of all required work products are identified; c) required validation activities are performed; d) problems are identified and recorded; f) results of the validation activities are made available to the customer and other involved parties.

[ISO/IEC 12207, 7.2.4, 7.2.5]

6.1.2 Supply Process d) a product and/or service that meets the agreed requirements are developed by the supplier; e) the product and/or service is delivered to the acquirer in accordance with the agreed requirements; and f) the product is installed in accordance with the agreed requirements. 7.2.1 Software Documentation Management Process a) a strategy identifying the documentation to be produced during the life cycle of the software product or service is developed; c) documentation to be produced by the process or project is identified; and e) documentation is developed and made available in accordance with identified standards.

[ISO/IEC 12207, 6.1.2, 7.2.1]



4.3.4 SI output products 385

Name Destination

Software Configuration

• Requirements Specification • Software Design • Traceability Record • Software Components • Software • Test Cases and Test Procedures • Test Report • Product Operation Guide • Software User Documentation • Maintenance Documentation

Project Management

Change Request Project Management

4.3.5 SI internal products 386

Name

Validation Results


4.3.6 SI roles involved 387

Role Abbreviation

Customer CUS

Analyst AN

Designer DES

Programmer PR

Project Manager PM

Technical Leader TL

Work Team WT



4.3.7 SI diagram 388

The following diagram shows the flow of information between the Software Implementation Process activities 389 including the most relevant work products and their relationship. 390


Initiation

Software Requirements

Analysis

Software Architectural and Detailed

Design

Software Construction

Software Integration and

Tests

Product Delivery

Project Plan

Validation Results


Requirements Specification

Traceability Record

Software Design

Software Components

Test Report

Maintenance Documentation

Product Operation Guide

Software User Documentation

Test Cases and Test Procedures


Project Repository

Software

Change Request

391

Figure 3 – Software Implementation Process Diagram. 392



4.3.8 SI activities 393

The Software Implementation Process has the following activities: 394 ⎯ SI.1 Software Implementation Initiation 395

⎯ SI.2 Software Requirements Analysis 396

⎯ SI.3 Software Architectural and Detailed Design 397

⎯ SI.4 Software Construction 398

⎯ SI.5 Software Integration and Tests 399

⎯ SI.6 Product Delivery 400

4.3.8.1 SI.1 Software Implementation initiation (SI.O1) 401

The Software Implementation Initiation activity ensures that the Project Plan established in Project Planning 402 activity is committed to by the Work Team. The activity provides: 403

⎯ Review of the Project Plan by the Work Team to determine task assignment. 404

⎯ Commitment to Project Plan by the Work Team and Project Management. 405

⎯ An implementation environment established. 406


PM

TL

WT

SI.1.1 Revision of the current Project Plan with the Work Team members in order to achieve a common understanding and get their engagement with the project.

Project Plan Project Plan[reviewed]

TL

WT

SI.1.2 Set or update the implementation environment.

Project Plan [reviewed]

4.3.8.2 SI.2 Software requirements analysis (SI.O2, SI.O6, SI.O7) 407

The Software Requirements Analysis activity analyzes the agreed customer’s requirements and establishes 408 the validated project requirements. The activity provides: 409

⎯ Elicitation, analysis and specification of customer’s requirements 410

⎯ Agreement on the customer requirements. 411

⎯ Verification and validation of requirements. 412

⎯ Version control of the software requirements products. 413


TL

WT

SI.2.1 Assign tasks to the Work Team members in accordance with their role, based on the current Project Plan.

Project Plan[reviewed]




AN

CUS

SI.2.2 Document or update the Requirements Specification.

Identify and consult information sources (customer, users, previous systems, documents, etc.) in order to get new requirements.

Analyze the identified requirements to determinate the scope and feasibility.

Generate or update the Requirements Specification.

Project Plan (Product Description)


AN SI.2.3 Verification of the Requirements Specification.

Verify the correctness and testability of the Requirements Specification and its consistency with the Product Description. Additionally, review that requirements are complete, unambiguous and not contradictory. The results found are documented in a Verification Results and corrections are made until the document is approved by AN. If significant changes were needed, initiate a Change Request.


Project Plan (Product Description)


Requirements Specification [verified]

Change Request [initiated]

CUS

AN

SI.2.4 Validation of the Requirements Specification

Validate that Requirements Specification satisfies needs and agreed upon expectations, including the user interface usability. The results found are documented in a Validation Results and corrections are made until the document is approved by CUS.

Requirements Specification [verified]

Validation Results

Requirements Specification [validated]

AN SI.2.5 Document the preliminary version of the Software User Documentation or update the present manual.

(optional)


Software User Documentation [preliminary]

AN SI.2.6 Verification of the Software User Documentation

Verify consistency of the Software User Documentation with the Requirement Specification. .The results found are documented in a Verification Results and corrections are made until the document is approved by AN. If significant changes were needed, initiate a Change Request.

(optional)

Software User Documentation [preliminary]

Requirement Specification


Software User Documentation [preliminary, verified]

Change Request [initiated]

TL SI.2.7 Incorporate the Requirements Specification, and *Software User Documentation to the



Requirements




Software Configuration in the baseline.

*(optional)

*Software User Documentation [preliminary, verified]

Specification [validated, baselined],

*Software User Documentation[preliminary, verified, baselined]

4.3.8.3 SI.3 Software architectural and detailed design (SI.O3, SI.O6, SI.O7) 414

The Software Architectural and Detailed Design activity transforms the software requirements to the system 415 software architecture and software detailed design. The activity provides: 416

⎯ Design software architecture, software components and associated interfaces. 417

⎯ Detailed design of the software components and interfaces. 418

⎯ Work Team review of the Requirements Specification 419

⎯ Software design verified and defects corrected. 420

⎯ Verified Test Cases and Test Procedures for integration testing. 421

⎯ Traceability of the software requirements to the software design, test cases, and test procedures. 422

⎯ Design products and documents under version control. 423

NOTE Note: Software Architecture and Detailed Design can be performed separately according to the project 424 schedule. 425


TL

AN

DES

SI.3.1 Assign tasks to the Work Team members related to their role according to the current Project Plan.

Project Plan

AN

DES

SI.3.2 Understand Requirements Specifications. Requirements Specification[validated, baselined]

AN

DES

SI.3.3 Document or update the Software Design:

Analyze the Requirements Specification to generate the architectural design, its arrangement in subsystems and software components defining the internal and external interfaces. Describe in detail, the appearance and the behavior of the interface, based on the Requirements Specification in a way that resources for its implementation can be foreseen.

Provide the detail of software components and their interfaces to allow the construction in an

Requirements Specification [validated, baselined]

Software Design

Traceability Record




evident way.

Generate or update the Traceability Record.

AN

DES

SI.3.4 Verification of the Software Design

Verify correctness of Software Design documentation, its feasibility and consistency with their Requirement Specification. Verify that the Traceability Record contains the adequate relationships between requirements and the Software Design elements. The results found are documented in a Verification Results and corrections are made until the document is approved by AN. If significant changes were needed, initiate a Change Request.

Software Design

Traceability Record

Requirement Specification [validated, baselined]


Software Design[verified]

Traceability Record[verified]

Change Request [initiated].

DES SI.3.5 Establish or update Test Cases and Test Procedures for integration testing based on Requirements Specification and Software Design.

Customer provides testing data, if needed.


Software Design[verified, baselined]


DES

AN

SI.3.6 Verification of the Test Cases and Test Procedures.

Verify consistency among Requirements Specification, Software Design and Test Cases and Test Procedures. The results found are documented in a Verification Results and corrections are made until the document is approved by AN.





Test Cases and Test Procedures[verified]

DES SI.3.7 Update the Traceability Record incorporating the Test Cases and Test Procedures.

Test Cases and Test Procedures [verified]

Traceability Record [updated]

Traceability Record [updated]

TL SI.3.8 Incorporate the Software Design, Test Cases, Test Procedures and Traceability Record to the Software Configuration as part of the baseline.

Software Design[verified]


Traceability Record[verified]




Traceability Record[verified, baselined]

426



4.3.8.4 SI.4 Software construction (SI.O4, SI.O6, SI.O7) 427

The Software Construction activity develops the software code and data from the Software Design. The 428 activity provides: 429

⎯ Work Team review of the Software Design to determine task assignment and software construction 430 sequence. 431

⎯ Coded software Components and applied unit tests. 432

⎯ Traceability between Software Components and Software Design, 433


TL SI.4.1 Assign tasks to the Work Team members related to their role, according to the current Project Plan.

Project Plan

PR SI.4.2 Understand Software Design. Software Design[verified, baselined]

PR SI.4.3 Construct or update Software Components based on the detailed part of the Software Design and define or update unit test cases.

Software Design [verified, baselined],

Traceability Record [verified, baselined]

Software Components

PR SI.4.4 Apply unit test cases to verify that functions work accordingly to the detailed part of the Software Design.

Software Components Software Components[unit tested]

PR SI.4.5 Correct the defects found until successful unit test (reaching exit criteria) is achieved.

Software Components[unit tested]

Software Components[corrected]

PR SI.4.6 Update the Traceability Record incorporating Software Components constructed or modified.

Software Components[corrected]

Traceability Record[verified, baselined].

Traceability Record[updated]

TL SI.4.7 Incorporate Software Components and Traceability Record to the Software Configuration as part of the baseline.

Software Components[corrected]Traceability Record[updated]


Software Components[corrected, baselined]

Traceability Record[updated baselined]

434



4.3.8.5 SI.5 Software integration and tests (SI.O5, SI.O6, SI.O7) 435

The Software Integration and Test activity ensures that the integrated software components satisfy the 436 software requirements. The activity provides: 437

⎯ Work Team review of the Project Plan to determine task assignment. 438

⎯ Understanding of Test Cases and Procedures and the integration environment. 439

⎯ Integrated Software Components, corrected defects and documented results. 440

⎯ Traceability of requirements and design to the integrated software product 441

⎯ Documented and verified operational and software user documentations. 442

⎯ Verified Software baseline. 443


TL SI.5.1 Assign tasks to the work team members related to their role, according to the current Project Plan.

Project Plan

PR SI.5.2 Understand Test Cases and Test Procedures.

Set or update the testing environment.

Test Cases and Test Procedures[verified, baselined]

PR SI.5.3 Integrates the Software using Software Components and defines or updates Test Cases and Test Procedures for integration.

Software Components [corrected, baselined]

Traceability Record [updated, baselined]

Software


PR

CUS

SI.5.4 Perform tests using Test Cases and Test Procedures for integration and document results in Test Report.

Software


Software [tested]

Test Report

PR SI.5.5 Correct the defects found until successful test (reaching exit criteria) is achieved.

Software [tested], Test Report.

Software [corrected]

Test Report [defects eliminated]

PR SI.5.6 Updates the Traceability Record if appropriate.

Software [corrected]

Traceability Record[verified, baselined].


PR SI.5.7 Document the Product Operation Guide or update the current guide, if appropriate.

Software[tested] Product Operation Guide




PR

CUS

SI.5.8 Verification of the Product Operation Guide , if appropriate (see SI.5.7)

Verify consistency of the Product Operation Guide with the Software. The results found are documented in a Verification Results and corrections are made until the document is approved by PR.


Software[tested]


Product Operation Guide[verified]

AN SI.5.9 Document the Software User Documentation or update the current one, if appropriate.

Software[tested]

Software User Documentation [preliminary] (optional)


AN

CUS

SI.5.10 Verification of the Software User Documentation, if appropriate (see SI.5.9)

Verify consistency of the Software User Documentation with the Software. The results found are documented in a Verification Results and corrections are made until the document is approved by AN.


Software[tested]


Software User Documentation[verified]

TL SI.5.11 Incorporate the Software, Traceability Record, Test Report, Product Operation Guide and Software User Documentation to the Software Configuration as part of the baseline.

Software [tested]

Test Report


Product Operation Guide[verified]

Software User Documentation[verified]


Software[tested, baselined] Traceability Record[updated, baselined] Test Report [baselined]

Product Operation Guide [verified, baselined]

Software User Documentation [verified, baselined]

444

4.3.8.6 SI.6 Product delivery (SI.O6, SI.O7) 445

The Product Delivery activity provides the integrated software product to the Customer. The activity provides: 446

⎯ Verified maintenance documentation 447

⎯ Delivery of the software product and applicable documentation in accordance with the Delivery 448 Instructions. 449




TL

WT

SI.6.1 Assign tasks to the work team members related to their role, according to the current Project Plan.

Project Plan

DES SI.6.2 Understand Software Configuration.


DES SI.6.3 Document the Maintenance Documentation or update the current one.



DES SI.6.4 Verification of the Maintenance Documentation.

Verify consistency of Maintenance Documentation with Software Configuration. The results found are documented in a Verification Results and corrections are made until the document is approved by DES.




Maintenance Documentation [verified]

TL SI.6.5 Incorporate the Maintenance Documentation as baseline for the Software Configuration.


Maintenance Documentation [verified]


Maintenance Documentation[verified, baselined]

TL SI.6.6 Perform delivery according to Delivery Instructions.



Software Configuration [delivered]

450

4.3.9 SI Incorporation to the Project Repository 451

The list of products to be saved in Project Repository. After the incorporation, Version Control Strategy has to 452 be applied to: Requirement Specification, Software Design, Traceability Record, Test Cases and Test 453 Procedures, Software Components, Software, Product Operation Guide, Software User Documentation and 454 Maintenance Documentation. 455

Product



Software Design

Traceability Record


Software Components

Software



Product



Test Report

Verification Results(s)

Validation Results(s)



4.4 Roles 456

This is an alphabetical list of the roles, its abbreviations and suggested competencies description. This list is 457 showed as four column table for presentation purpose only. 458

Role Abbreviation Competency

1. Analyst AN Knowledge and experience eliciting, specifying and analyzing the requirements.

Knowledge in designing user interfaces and ergonomic criteria.

Knowledge of the revision techniques and experience on the software development and maintenance.

Knowledge of the editing techniques and experience on the software development and maintenance.

2. Customer CUS Knowledge of the Customer processes and ability to explain the Customer requirements.

The Customer (representative) must have the authority to approve the requirements and their changes.

The Customer includes user representatives in order to ensure that the operational environment is addressed.

Knowledge and experience in the application domain.

3. Designer DES Knowledge and experience in the software components and architecture design.



Knowledge and experience in the planning and performance of integration and system tests.

4. Programmer PR Knowledge and/or experience in programming, integration and unit tests.



5. Project Manager

PM Leadership capability with experience making decisions, planning, personnel management, delegation and supervision, finances and software development.

6. Technical Leader

TL Knowledge and experience in the software development and maintenance.



7. Work Team WT Knowledge and experience according to their roles on the project: AN, DES, and/or PR.



4.5 Product description 459

This is an alphabetical list of the input, output and internal process products, its descriptions, possible states 460 and the source of the product. The source can be another process or an external entity to the project, such as 461 the Customer. This list is showed as four column table for presentation purpose only. 462

Name Description Source

1. Acceptance Record

Document establishing the customer acceptance of the deliverables of the project. It may contain:

- Record of the receipt of the delivery - Identifies the date received - Identifies the delivered elements - Records the verification of any Customer acceptance

criteria defined - Signed by receiving Customer

Project Management

2. Change Request It may has the following characteristics:

- Identifies purpose of change - Identifies request status (new, accepted, rejected) - Identifies requester contact information - Impacted system(s) - Impact to operations of existing system(s) defined - Impact to associated documentation defined - Criticality of the request, date needed by The applicable statuses are: initiated, evaluated, accepted.


Customer

Project Management

3. Correction Register

Activities established to correct a deviation or problem concerning the accomplishment of a plan. It may contain:

- Identifies the initial problem - Identifies the ownership for completion of defined action - Defines a solution - Identifies the open date and target closure date - Contains a status indicator - Indicates follow up actions

Project Management

4. Maintenance Documentation

Electronic or printed document describing the Software Configuration and the environment used for development and testing (compilers, design tools, construction and tests). The Maintenance Documentation includes or refers to products developed during implementation such as the Requirements Specification. It is written in terms that maintenance personnel can understand.

The applicable statuses are: verified and baselined.


5. Meeting Record Record of the agreements established with Customer and/or Work Team. May address the following:

- purpose of meeting - attendees - date, place held - reference to previous minutes - what was accomplished - identifies issues raised - any open issues

Project Management




- agreements - next meeting, if any.

The applicable status is: updated.

6. Product Operation Guide

Electronic or printed document containing the necessary information to install and manage the software. It may provide:

- Criteria for operational use - A description of how to operate the product including:

- operational environment required - supporting tools and material (e.g. user manuals)

required - possible safety warnings - start-up preparations and sequence - frequently asked questions (FAQ) - sources of further information and help to operate the

product - Certification and safety approvals - Warranty and replacement instructions

It should be written in terms that the personnel responsible for the operation can understand.



7. Progress Status Record

Record of the status of the project against the Project Plan. It may contain:

- status of actual tasks against planned tasks - status of actual results against established objectives /

goals - status of actual resource allocation against planned

resources - status of actual cost against budget estimates - status of actual time against planned schedule - status of actual risk against previously identified

Record of any deviations from planned tasks and reason why. The applicable status is: evaluated.

Project Management

8. Project Plan

Includes:

- Product Description - Scope - Objectives - Deliverables - Tasks, including verification, validation and reviews with

Customer and Work Team, to assure the quality of work products. Tasks may be represented as a Work Breakdown Structure (WBS).

- Relationship and Dependence of the Tasks

- Estimated Duration of tasks - Resources (humans, materials, equipment and tools)

Project Management




including the required training, and the schedule when the resources are needed.

- Composition of Work Team - Schedule of the Project Tasks, the expected start and

completion date, for each task. - Estimated Effort and Cost - Identification of Project Risks - Version Control Strategy

- Product repository tools or mechanism identified - Location and access mechanisms for the repository

specified - Version identification and control defined - Backup and recovery mechanisms defined - Storage, handling and delivery (including archival

and retrieval) mechanisms specified - Delivery Instructions

- Elements required for product release identified (i.e., hardware, software, documentation etc.)

- Delivery requirements - Sequential ordering of tasks to be performed - Applicable releases identified - Identifies all delivered software components with

version information - Identifies any necessary backup and recovery

procedures The applicable statuses are: verified, validated, changed and reviewed.

9. Project Repository

A repository may have the following characteristics:

- Repository for work products - Storage and retrieval capabilities - Ability to browse content - Listing of contents with description of attributes - Sharing and transfer of work products between affected

groups - Effective controls over access - Maintain work products descriptions - Recovery of archive versions of work products - Ability to report work products status - Changes to work products are tracked to Change

Requests The applicable status is: recovered and updated.

Project Management

10. Project Repository Backup

Repository used to backup the Project Repository and if necessary to recover information.

Project Management

11. Requirements Specification

Includes an introduction and a description of the requirements. It may contain:

- Introduction –general description of software and its use within the scope of the customer business;





- Requirements description: - functionality – established needs to be satisfied by

the software when it is used in specific conditions. Functionality must be adequate, accurate and safe.

- user interface – definition of those user interface characteristics that allow to understand and learn the software easily so the user be able to perform his/her tasks efficiently including the interface exemplar description; external interfaces – definition of interfaces with other software or hardware;

- reliability – specification of the software execution level concerning the maturity, fault tolerance and recovery;

- efficiency – specification of the software execution level concerning the time and use of the resources;

- maintenance – description of the elements facilitating the understanding and execution of the future software modifications;

- portability – description of the software characteristics that allow its transfer from one place to other;

- design and construction limitations – needs imposed by the customer;

- inter-operability – capability for two or more systems or software components be able to change information each other and use it.

- reusability – feature of any product/sub-product, or a part of it, so that it can be used by several users as an end product, in the own software development, or in the execution of other software products.

- legal and regulative – needs imposed by laws, regulations, etc.

Each requirement is identified, unique and it is verifiable or can be assessed.

The applicable statuses are: verified, validated and baselined.

12. Resources Description of human resources, infrastructure and budget assigned to the project

Organizational Management

13. Software Software item for a Customer, constituted by a collection of Software Components.

The applicable statuses are: tested and baselined.


14. Software A set of related code units. Software




Component The applicable statuses are: unit tested, corrected and baselined. Implementation

15. Software Configuration

A consistent set of software products including:

- Requirements Specification - Software Design - Traceability Record - Software Components - Software - Test Cases and Test Procedures - Test Report - Product Operation Guide - Software User Documentation - Maintenance Documentation

The applicable statuses are: delivered and accepted.


16. Software Design This document includes textual and graphical information on the software structure. This structure may includes the following parts:

Architectural High Level Software Design – Describes the overall Software structure:

- Identifies the required software Components - Identifies the relationship between software Components - Consideration is given to any required:

- software performance characteristics - software interfaces - security characteristics - database design requirements - error handling and recovery attributes

Detailed Low Level Software Design – includes details of the software components to facilitate its construction and test within the programming environment;

- Provides detailed design (could be represented as a prototype, flow chart, entity relationship diagram, pseudo code, etc.)

- Provides format of input / output data - Provides specification of data storage needs - Establishes required data naming conventions - Defines the format of required data structures - Defines the data fields and purpose of each required

data element - Provides the specifications of the program structure



17. Software User Documentation

Electronic or printed document describing the way of using the software based on the user interface.

It provides user procedures for performing specified tasks using the Software. It may include installation and de-installation procedures. It includes a brief description of the intended use of the Software (the concept of operations), the supplied and required resources, needed operational environment, and availability of problem reporting and assistance. It provides procedures to access and exit the Software. It should list and





explain Software commands and system-provided messages to the user. As appropriate for the identified risk, it includes warnings, cautions, and notes, with corrections. It includes troubleshooting and error correction procedures.

It is written in terms understandable by users.

The applicable statuses are: preliminary, verified and baselined.

18. Statement of Work

It may Include: - Product Description - Scope - Objectives - Deliverables

The applicable status is: reviewed

Customer

19. Test Cases and Test Procedures

Test Case may include: - Identifies the test case - Test items - Input specifications - Output specifications - Environmental needs - Special procedural requirements - Interface dependencies

Test Procedures may include:

- Identifies: test name, test description and test completion date

- Identifies potential implementation issues - Identifies the person who completed the test procedure - Identifies prerequisites - Identifies procedure steps including the step number, the

required action by the tester and the expected results The applicable statuses are: verified and baselined.


20. Test Report Documents the tests, it may include:

- A summary of each defect - Identifies the related test case - Identifies the tester who found each defect - Identifies the severity for each defect - Identifies the affected function(s) for each defect - Identifies the date when each defect originated - Identifies the date when each defect was resolved - Identifies the person who resolved each defect

The applicable status is: baselined.


21. Traceability Record

Relationship among the requirements included in the Requirements Specification, Software Design elements, Software Components, Test Cases and Test Procedures.

- Identifies requirements of Requirements Specification to be traced





- Provides forward and backwards mapping of requirements to Software Design elements, Software Components, Test Cases and Test Procedures.

The applicable statuses are: verified, baselined and updated.

22. Verification Results

May include the record of:

- Participants - Date - Place - Duration - Verification check-list - Passed items of verification - Failed items of verification - Pending items of verification - Defects identified during verification

Project Management


23. Validation Results

May include the record of:

- Participants - Date - Place - Duration - Validation check-list - Passed items of validation - Failed items of validation - Pending items of validation - Defects identified during validation

Project Management


463

4.6 Software tools requirements 464

Software tools that could be used to perform process activities. 465

4.6.1 Project Management process 466

Activity Resource List

Project Planning

Project Plan Execution

Project Assessment and Control

Project Closure

Tools allowing document, manage and control the Project Plan and the use and management of the Project Repository

4.6.2 Software Implementation process 467

Activity Resource List

Software Implementation Documentation tools



Initiation

Software Requirements Analysis

Software Architectural and Detailed Design

Software Construction

Software Integration and Tests

Product Delivery

Software Requirements Analysis

Requirements Specification tools

Software Architectural and Detailed Design

Software Design tools

Software Construction Construction Tools

Software Integration and Tests

Tests tools, Bug tracking tools

468



Annex A 469

(Informative) 470

Deployment Packages 471

In order to facilitate the implementation, by VSEs, of a Profile, a set of Deployment Packages are available. A 472 deployment package is a set of artifacts developed to facilitate the implementation of a set of practices, of the 473 selected framework, in a VSE. But, a deployment package is not a complete process reference model. 474 Deployment packages are not intended to preclude or discourage the use of additional guidelines that VSEs 475 find useful. 476

The elements of a typical deployment package are: detailed description of processes, activities, tasks, roles 477 and products, template, checklist, example, reference and mapping to standards and models, and a list of 478 tools. The mapping is only given as information to show that a Deployment Package has explicit links to Part 5, 479 ISO standards, such as ISO/IEC 12207, or models such as the CMMI. Hence by deploying and implementing 480 a package, a VSE can see its concrete step to achieve or demonstrate coverage to Part 5. Deployment 481 Packages are designed such that a VSE can implement its content, without having to implement the complete 482 framework at the same time. The table of content of a deployment package is illustrated in table A-1. 483

1. Technical Description Purpose of this document Why this Topic is important? 2. Relationships with ISO/IEC 29110 3. Key Definitions 4. Overview of Processes, Activities, Tasks, Roles and Products 5. Description of Processes, Activities, Tasks, Steps, Roles and Products Role Description Product Description Artefact Description 6. Template(s) 7. Example(s) 8. Checklist(s) 9. Tools 10. References to Other Standards and Models (e.g. ISO 9001, ISO/IEC 12207, CMMI) References Evaluation Form

484

Table A.1. Table of Content of a Deployment Package. 485

For the Basic VSE Profile, a set of Deployment Packages are available, at no cost, on the Internet: 486

a) Requirements Analysis 487

b) Architecture and Detailed Design 488

c) Construction and Unit Testing 489

d) Integration and Test 490



e) Verification and Validation 491

f) Version Control 492

g) Project Management 493

h) Product Delivery 494

i) Self-Assessment 495



Bibliography 496

ISO/IEC 12207 - Systems and Software Engineering—Software Life Cycle Processes. 497

ISO/IEC 15289 Software Engineering – Software Life Cycle Process – guidelines for the content of software 498 life cycle process information products (documentation). 499

ISO/IEC TR 29110-1 Software engineering — Lifecycle profiles for very small enterprises – Part 1: Overview 500

OECD. 2005. Organization for Economic Co-Operation and Development, SME and Entrepreneurship Outlook, 501 2005 Edition 502