2. 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
5. 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.
6. 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
7.
8. Software Implementation (SI) Process
SI.O1. Tasks of the activities are performed
through the accomplishment of the current
Project Plan.
9.
10. Software Implementation (SI) Process
SI.O2. Software requirements are defined,
analyzed for correctness and testability, approved
by the Customer, baselined and communicated.
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
14
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
15
More detail in IEEE 830
17. 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.
18.
19. 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
20. 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
21. 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.
22. • 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
23. 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).
24. 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).
25. 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
26. 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
27. Requirements Traceability Matrix*
* Also called Proof of Compliance Matrix or Verification Matrix
Linda Westfall, Bidirectional Requirements Traceability, SQP, Dec 2007
28. 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.
29. 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
30. 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.
31. Benefits of Implementing
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
32. Benefits of Implementing
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
33. Benefits of Implementing
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
34. 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.
35.
36. 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.
37.
38. 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
39. SI.O5 Documentation
Test Cases and Test Procedures
(may includes)
Identifies the test case
Test items
Input specifications
Output specifications
Environmental needs
40. 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
41. 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
42. 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
43. 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.
44.
45. 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.
46.
47. 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.
49. 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.
50. 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
51. 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