Ch5 software imprementation1.0

SE423 SPICH-5 ISO29110: Software Implementation Process

Kittitouch Suteeca

Plan-Do-Check-Act (PDCA)Plan: Design or revise business process components

to improve results Do: Implement the plan and measure its performance Check: Assess the measurements and report the results

to decision makers

Act: Decide on changes needed to improve the process

ProjectManagement

Statement of Work

SoftwareImplementation

Software Configuration

ISO 29110

ISO29110 Deployment Packages

RequirementsAnalysis

Version Control

Integration and Tests

Project Management

ArchitectureAnd detailed design

Product Delivery

Self-Assessment

ConstructionAnd

Unit testing

Verificationand

Validation

Software Implementation (SI) Process

ISO/IEC29110 SOFTWARE

IMPLEMENTATION

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.

ISO/IEC29110 SOFTWARE IMPLEMENTATION PROCESS

SI.1 Software Implementation Initiation SI.2 Software Requirement Analysis SI.3 Software Architectural and Detailed

Design SI.4 Software Construction SI.5 Software Integration and Tests SI.6 Software Delivery

Software Implementation (SI) Process

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

Software Implementation (SI) Process

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

SI.O2 DocumentationRequirements Specification (may includes)

Introduction Description

Functionality User Interface Reliability Efficiency Maintenance

13

Software Requirements Specification (SRS)

No specifics form. Guideline for SRSIEEE 830-1998:

IEEE Recommended Practicefor Software RequirementsSpecification

14

Objective of SRS [IEEE] Establish the basis for agreement between the

customers and the suppliers on what the software product is to do

Reduce the development effort Provide a basis for estimating costs and

schedules Provide a baseline for validation and verification Facilitate transfer Serve as a basis for enhancement

15

Example of Specific Requirement.[IEEE]

Specific Requirements External Interfaces Functions Performance Requirements Logical Database Requirements Design Constraints Software System Attributes Organizing the Specifics Requirements Additional Comments

More detail in IEEE 830

16

10 Characteristics of SRS [SW Tech Center, NASA]

1. Complete [ IEEE 830]2. Consistent [ IEEE 830]3. Accurate 4. Modifiable [ IEEE 830]5. Ranked [ IEEE 830]6. Testable 7. Traceable [ IEEE 830]8. Unambiguous [ IEEE 830]9. Valid 10. Verifiable [ IEEE 830]

Software Implementation (SI) Process

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

SI.O3 DocumentationSoftware Design (may includes)

High Level Design Required Software Components Relationship between Software Components Software Performance Characteristics Software Interface Database Design

Low Level Design Input/output format data Data storage needs

Requirements Problems? The requirements phase is the least

understood phase of software development.

The source of lower level (derived) requirements is not maintain.

Skipping the requirements phase and moving into the design phase is a natural tendency

Why Requirements Traceability? Fine Tuning Requirements

Requirements sometimes get “missed” as project moves through the process of creating the System Requirement Specification (SRS) to the System Design Specification (SDS) and Test Plan.

The Requirements Traceability Matrix will point out where more work is needed to ensure requirements are included in the SDS and Test Plan.

• requires unique identifiers for each requirement and product • the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many

Requirements Traceability

Traceability - DefinitionsTraceability

A discernable association among two or more logical entities such as requirements, system elements, verifications, or tasks. (See also “bidirectional traceability” and “requirements traceability.”)

Requirements traceabilityA discernable association between requirements and

related requirements, implementations, and verifications.

Bidirectional traceabilityAn association among two or more logical entities that

is discernable in either direction (i.e., to and from an entity).

04/10/202324

Traceability-Attributes1. The requirement identification number

2. The source of the requirement1. Such as the customer's document paragraph number

or the engineering report documenting the analysis that derived the requirement.

3. The full text of the requirement

4. For allocated or derived requirements, a pointer to the requirement from which it was derived, or "parent" requirement.

5. A pointer to the next lower-level area that this requirement was allocated to during the allocation process

Source: SYSTEMS ENGINEERING HANDBOOK, A “HOW TO” GUIDE For All Engineers, Version 2.0, July 2000. International Council on Systems Engineering (INCOSE).

6. Verification method (e.g. test, demonstration, analysis, inspection/examination).

7. The Test Plan name & number controlling the verification

8. The Test Procedure name & number performing the verification

9. The date and results of the final verification

10. The name of the responsible engineer.

Traceability-Attributes

04/10/202326

Some key requirements traceability links. Business

Requirement

System Requirement, Use Case, External Interface

Requirement,Quality attributes

Change Request

Software Functional Requirement

Architecture, User Interface, Functional Design

Code

System Test

is verified by

is satisfied by

is implemented in

is origin of

drives specification ofModifies

Project Plan Task

Leads to creation of

depends on another

Wiegers K., Software Requirements, Microsoft Press, 2003

Modifies

Modifies

Modifies

Business Rules

is origin of

is verified by

Unit test

Integration test

is verified by

Requirements Traceability Matrix*

* Also called Proof of Compliance Matrix or Verification Matrix

Linda Westfall, Bidirectional Requirements Traceability, SQP, Dec 2007

Four types of requirements traceability

Customer Needs

Requirements

Product

backward from requirements

forward to requirements

forward from requirements

backward to requirements

Source: Wiegers, K., ‘Software Requirements’, Second Edition, Microsoft Press, 2003.

SI.O3 DocumentationTraceability Record (may includes)

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

Benefits of Implementing Traceability

1. Certification -Verification• The traceability information can be used for

certification in safety-critical applications To verify and demonstrate that all requirements

were implemented.

2. Change Impact Analysis• Traceability links help find all of the system elements

that might have to be modified if you change a particular requirement. Without traceability information, chances are high

you’ll overlook some of the side effects of adding, deleting, or modifying a requirement.

Benefits of Implementing Traceability3. Project Tracking

• If you complete the requirements traceability matrix as development takes place, you will have accurate insight into the implementation status of planned functionality. Empty space in the matrix indicates project

deliverables that have not yet been created.

4. Testing• Links between tests, requirements, and code

point toward likely parts of the code to examine for a bug when a test fails to yield the intended result

Benefits of Implementing Traceability5. Reuse

• Traceability information can facilitate the reuse of product components• By identifying packages of related

requirements, designs, code, tests, and other artefacts.

6. Risk Management and Reduction• Documenting the information about system

component interconnections reduces the risk associated with a key team member leaving the company with essential information residing only in that person’s brain

Benefits of Implementing Traceability7. Reengineering

• If you don’t have complete requirements for the existing system. • You can list the functions in a legacy system you’re replacing and record

where they were addressed in the requirements and software components for the new system.

• Provide a way to capture some of what you learn through reverse engineering.

8. Identification of process improvements• e.g. Information about Requirements instability may be used to improve the

development process/change management process

9. Allows developer, customer or supplier to follow closely the development of components

10. Help to reduce cost and delay and improve quality

Software Implementation (SI) Process

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

Software Implementation (SI) Process

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

Establish Test Plan

Design Test Case

Execute Test

Write Test Report

Remove Software Defect

Test Complete

Approve

Approve

Regression Test

Mor

e de

fect

Test Process : Flow Chart

SI.O5 DocumentationTest Cases and Test Procedures

(may includes)

Identifies the test case Test items Input specifications Output specifications Environmental needs

SI.O5 DocumentationTest Report (may includes)

Summary of each defect Related test case Tester who found each defect Severity for each defect Affected function(s) for each defect Date when each defect originated Date when each defect was resolved Person who resolved each defect

SI.O5 DocumentationProduct Operation Guide (may includes)

Criteria for operational use Description of how to operate the product including:

Operational environment required Supporting tools and material required Possible safety warnings Start-up preparations and sequence Frequently asked questions (FAQ)

Certification and safety approvals Warranty and replacement instructions

SI.O5 DocumentationSoftware User Documentation (may

includes)

Installation and De-Installation Brief description of intended use of software Supplied and required resources Needed operational environment Warnings, Caution, and notes with corrections

Software Implementation (SI) Process

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

Software Implementation (SI) Process

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

Verification

Confirmation by examination and provisions of objective evidence that specified requirements have been fulfilled.

In design and development, verification concerns the process of examining the result of a given activity to determine conformity with the stated requirement for that activity.

Requirement& Design Coding

Test

VerificationTR

ValidationValidation

Confirmation by examination and provisions of objective evidence that the particular requirements for a specific intended use are fulfilled.

Validation is normally performed on the final product under defined operating conditions.

“Validated” is used to designate the corresponding status.

SI.O7 DocumentationValidation Result (may includes)

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

SI.O7 Documentation

Verification Result (may includes)

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