Date post: | 07-Dec-2014 |
Category: |
Technology |
Upload: | kittitouch-suteeca |
View: | 573 times |
Download: | 0 times |
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