Deployment Package Software Requirements Analysis s1

Deployment Package

Software Design

Basic Profile

Notes:

This document is the intellectual propriety of its author’s organization. However, information contained in this document is free of use. The distribution of all or parts of this document is authorized for non commercial use as long as the following legal notice is mentioned:

Commercial use of this document is strictly forbidden. This document is distributed in order to enhance exchange of technical and scientific information.

This material is furnished on an “as-is” basis. The author(s) make(s) no warranties of any kind, either expressed or implied, as to any matter including, but not limited to, warranty of fitness for purpose or merchantability, exclusivity, or results obtained from use of the material.

The processes described in this Deployment Package are not intended to preclude or discourage the use of additional processes that Very Small Entities may find useful.

Author / F. GUILLEMOT – École de Technologie Supérieure (ETS), (Canada)
Editors / C. Y. LAPORTE – École de Technologie Supérieure (ETS), (Canada)
ANA VAZQUEZ – 5th level, (México)
Creation date / 30th-July-2009
Last update / 7st August-2009
Version / 0.2

Deployment Package - Software Design / Page 18 / 28
Version 0.2

Version History

Date
(yyyy-mm-dd) / Version / Description / Author
2009-07-08 / 0.1 / Document creation / F. GUILLEMOT
2009-08-07 / 0.2 / Overall revision / C.Y Laporte

Abbreviations/Acronyms

Abre./Acro. / Definitions
DP / Deployment Package - a set of artefacts developed to facilitate the implementation of a set of practices, of the selected framework, in a Very Small Entity.
VSE / Very Small Entity – an enterprise, organization, department or project having up to 25 people.
VSEs / Very Small Entities

Table of Contents

1. Technical Description 4

Purpose of this document 4

Why this topic is Important? 4

2. Definitions 6

Generic Terms 6

Specific Terms 6

3. Relationships with ISO/IEC29110 8

4. Description of Processes, Activities, Tasks, Steps, Roles and Products 10

Role Description 13

Product Description 13

Artefact Description 16

5. Template 18

Software Design Template Table of Content Adapted from IEEE 1016 18

6. Example of an Activity Lifecyle 20

Example of Software design Practice Lifecycle 20

7. Checklist 21

8. Tool 22

9. Reference to Other Standards and Models 24

ISO 9001 Reference Matrix 24

ISO/IEC 12207 Reference Matrix 25

CMMI Reference Matrix 25

10. References 27

11. Evaluation Form 28

1. Technical Description

Purpose of this document

This Deployment Package (DP) supports the Basic Profile as defined in ISO/IEC29110 Part 5-1: Management and Engineering Guide. A DP is a set of artefacts developed to facilitate the implementation of a set of practices in a Very Small Entity (VSE). A DP is not a process reference model (i.e. it is not prescriptive). The elements of a typical DP are: description of processes, activities, tasks, roles and products, template, checklist, example, reference and reference to standards and models, and tools

The purpose of this document, entitled “Deployment Package – Design Description” is to provide VSE with a tailorable and easily usable guidelines and materials in order to implement a good software design description.

The content of this document is entirely informative.

This document has been produced by Frédéric Guillemot a software engineering graduate student at ÉTS (École de Technologie Supérieure - www.etsmtl.ca).

Why Software Design is Important?

During IT projects, it is imperative to define the different modules, the interfaces between internal and external modules composing a software product and their interaction between one another. Failure to define the different modules, interfaces will result in interoperability issues between components.

The figure below, presents data from a real company[1]. It shows that about 20% of the defects are produced during the design phase.

The design description phase produces a document known as the Design Description that enables designers and customers to easily understand the interactions in the software enabling the tracing of the requirements. This provides way to verify that each requirement has been addressed. This document is also used when maintaining a software because it describes the modules and interfaces.

Figure 1 Origins of software defects

2. Definitions

In this section, the reader will find two sets of definitions. The first set defines the terms used in all Deployment Packages, i.e. generic terms. The second set of terms used in this Deployment package, i.e. specific terms.

Generic Terms

Process: set of interrelated or interacting activities which transform inputs into outputs [ISO/IEC 12207].

Activity: a set of cohesive tasks of a process [ISO/IEC 12207].

Task: required, recommended, or permissible action, intended to contribute to the achievement of one or more outcomes of a process [ISO/IEC 12207].

Sub-Task: When a task is complex, it is divided into sub-tasks.

Step: In a deployment package, a task is decomposed in a sequence of steps.

Role: a defined function to be performed by a project team member, such as testing, filing, inspecting, coding. [ISO/IEC 24765]

Product: piece of information or deliverable that can be produced (not mandatory) by one or several tasks. (e. g. design document, source code).

Artefact: information, which is not listed in ISO/IEC 29110 Part 5, but can help a VSE during the execution of a project.

Specific Terms

Baseline: a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [ISO/IEC 12207]

Customer: organization or person that pays the VSE to create a software product.

NOTE acquirer or user is customer [ISO 9000]

Software product: The set of computers programs, procedures, and possibly associated documentation and data. [ISO/IEC 12207]

Traceable. 1. having components whose origin can be determined. [ISO/IEC24765]

Traceability matrix. 1. a matrix that records the relationship between two or more products of the development process. [ISO/IEC24765]

Validation: Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled. [ISO/IEC 12207]

Verification: Confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. [ISO/IEC 12207]

3. Relationships with ISO/IEC29110

This deployment package covers the activities related to Architecture and Detailed Design of the ISO Technical Report ISO/IEC 29110 Part 5-1 for Very Small Entities (VSEs) – Basic Profile [ISO/IEC29110].

In this section, the reader will find a list of Project Management (PM) and Software Implementation (SI) process, activities, tasks and roles from Part 5 that are directly related to this topic. This topic is described in details in the next section.

· Process: 3.1[2] Software Implementation (SI)

· Activity: SI.3 Software Architectural and Detailed Design

· Tasks and Roles:

Tasks / Roles[3]
SI.3.1 Assign tasks to the Work Team members related to their role according to the current Project Plan. / TL, AN
DES
SI.3.2 Understand Requirements Specifications. / 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 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 Components and their interfaces to allow the construction in an 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. / AN
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. / DES
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. / DES
AN
SI.3.7 Update the Traceability Record incorporating the Test Cases and Test Procedures. / DES
SI.3.8 Incorporate the Software Design, Test Cases, Test Procedures and Traceability Record to the Software Configuration as part of the baseline. / TL

4. Description of Processes, Activities, Tasks, Steps, Roles and Products

Process: 4.3[4] Software Implementation (SI)

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

Activity: SI.3 Software Architectural and Detailed Design

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

Tasks

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

· SI.3.2 Understand Requirements Specification.

· SI.3.3 Document or update the Software Design

· SI 3.4 Verification of the Software Design

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

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

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

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

Objectives: / To create a software design that will answer the requirements asked by the customer, that will be given the ability to be tested before being released and to verify that every requirements is fulfilled.
Rationale: / A software design is the key stone of a software project. Failure to describe a design architecture that will incorporate all the requirements is a recipe for disaster. The customer will not finalize the payment if the design doesn’t answer all his requirements.
Roles: / AN – Analyst
DES – Designer
TL – Technical Leader
Products: / Software Design
Requirement specifications
Traceability Record
Test Cases and Test Procedures
Software Configuration
Validation Results
Artefacts: / UML Diagrams
Steps: / 1. Assign tasks to the work team members related to their role, according to the current Project Plan.
2. Understand Requirements Specification
3. Document or update the Software Design
4. Verification of the Software Design
5. Establish or update Test Cases and Test Procedures for integration testing based on Requirements Specification and Software Design.
6. Verification of the Test Cases and Test Procedures.
7. Update the Traceability Record incorporating the Test Cases and Test Procedures.
8. Incorporate the Software Design, Test Cases, Test Procedures and Traceability Record to the Software Configuration as part of the baseline.
Step Description: / Step 1. Assign tasks to the work team members related to their role, according to the current Project Plan.
o Obtain requirement specifications from repository
o Obtain Test Cases and Test Procedures from repository
o Obtain Traceability Record from repository
o Use Requirement Specifications, Test Cases and Traceability Record to assign tasks.
Step 2. Understand Requirements Specification
o Examine each requirements and be sure they are understood
· DES groups functional requirements in logical groups.
· DES groups non-functional requirements in groups.
· AN verify DES groups and checks if all requirements are understood.
o If needed, update the Requirements Specifications to add necessary clarification.
· Store updated document in repository
Step 3. Document or update the Software Design
o Analyze the Requirements Specification to generate the architectural design, its arrangement in subsystems and components defining the internal and external interfaces.
o Describe in detail, the appearance and the behaviour of the interface, based on the Requirements Specification in a way that resources for its implementation can be foreseen.
o Provide the detail of Components and their interfaces to allow the construction in an evident way.
o Generate or update the Traceability Record.
o The traceability record should have been produced during the requirement analysis activities.
o Verify that every design element can be traced to a requirement
o Verify that every requirement is represented in design
Step 4. Verification of the Software Design
o Verify correctness of Software Design documentation, its feasibility and consistency with their Requirement Specification.
o Verify that the Traceability Record contains the relationships between requirements and the Software Design elements.
o Document the results in a Verification Results document.
o Correct errors until the document is approved by AN. If significant changes were needed, initiate a Change Request.
Step 5. Establish or update Test Cases and Test Procedures for integration testing based on Requirements Specification and Software Design.
o Create Test Cases and Procedures document
o If customer provides testing data, incorporate them in the document.
Step 6. Verification of the Test Cases and Test Procedures.
o Verify consistency among Requirements Specification, Software Design and Test Cases and Test Procedures.
o Document the results found in a Verification Results
o Correct errors until the document is approved by AN.
Step 7. Update the Traceability Record incorporating the Test Cases and Test Procedures.
o Update the Traceability Record with the new test procedures.
o Verify that every design and test element can be traced to a requirement
o Verify that every requirement is represented in design
o Verify that every requirement is represented in testing
Step 8. Incorporate the Software Design, Test Cases, Test Procedures and Traceability Record to the Software Configuration as part of the baseline.
o Store Software Design, Test Cases, Test Procedures and Traceability Record in the configuration management tool as described in the project software configuration policy.

Role Description

This is an alphabetical list of the roles, abbreviations and list of competencies as defined in Part 5.