Ch5 software imprementation1.0

SE423 SPI
CH-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

Project
Management
Statement of Work
Software
Implementation
Software
Configuration
ISO 29110

ISO29110 Deployment Packages
Requirements
Analysis
Version
Control
Integration
and
Tests
Project
Management
Architecture
And detailed design
Product
Delivery
Self-Assessment
Construction
And
Unit testing
Verification
and
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

Ch5 software imprementation1.0

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

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

SI.O2 Documentation
Requirements Specification (may includes)
 Introduction
 Description
 Functionality
 User Interface
 Reliability
 Efficiency
 Maintenance

Software Requirements Specification
(SRS)
 No specifics form.
 Guideline for SRS
IEEE 830-1998:
IEEE Recommended Practice
for Software Requirements
Specification
13

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
14

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
15
More detail in IEEE 830

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]
16

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 Documentation
Software 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 - Definitions
 Traceability
 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 traceability
 A discernable association between requirements and related
requirements, implementations, and verifications.
 Bidirectional traceability
 An association among two or more logical entities that is
discernable in either direction (i.e., to and from an entity).

3/18/2022
24
Traceability-Attributes
1. The requirement identification number
2. The source of the requirement
1. 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

3/18/2022
26
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 of
Modifies
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 Documentation
Traceability 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.

Traceability
3. 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

Traceability
5. 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

Traceability
7. 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

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.

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
More
defect
Test Process : Flow Chart

SI.O5 Documentation
Test Cases and Test Procedures
(may includes)
 Identifies the test case
 Test items
 Input specifications
 Output specifications
 Environmental needs

SI.O5 Documentation
Test 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 Documentation
Product 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 Documentation
Software 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

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.

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
Verification
TR

Validation
 Validation
 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 Documentation
Validation 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

Ch5 software imprementation1.0

More Related Content

What's hot (18)

Viewers also liked (10)

Similar to Ch5 software imprementation1.0 (20)

More from Kittitouch Suteeca (17)

Recently uploaded (20)

Ch5 software imprementation1.0