Plan-Do-Check-Act (PDCA)Plan: Design or revise business process componentsto improve resultsDo: Implement the plan and measure its performanceCheck: Assess the measurements and report the results todecision makersAct: Decide on changes needed to improve the process
ProjectManagementStatement of WorkSoftwareImplementationSoftwareConfigurationISO 29110
Software Implementation (SI) ProcessISO/IEC29110SOFTWAREIMPLEMENTATIONThe purpose of the Software Implementation process is the systematicperformance of the analysis, design, construction, integration and testsactivities for new or modified software products according to thespecified requirements.
Software RequirementsSpecification (SRS) No specifics form. Guideline for SRSIEEE 830-1998:IEEE Recommended Practicefor Software RequirementsSpecification13
Objective of SRS [IEEE] Establish the basis for agreement between thecustomers and the suppliers on what the softwareproduct 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 enhancement14
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 Comments15More detail in IEEE 830
Software Implementation (SI) ProcessSI.O3. Software architectural and detaileddesign is developed and baselined. Itdescribes the software components andinternal and external interfaces of them.Consistency and traceability to softwarerequirements 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 leastunderstood phase of software development The source of lower level (derived)requirements is not maintain. Skipping the requirements phase and movinginto the design phase is a natural tendency
Why Requirements Traceability? Fine Tuning Requirements Requirements sometimes get “missed” asproject moves through the process of creatingthe System Requirement Specification SRS tothe System Design Specification SDS and TestPlan The Requirements Traceability Matrix will pointout where more work is needed to ensurerequirements are included in the SDS and TestPlan
• 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-manyRequirements Traceability
Traceability - Definitions Traceability A discernable association among two or more logicalentities such as requirements, system elements,verifications, or tasks. (See also “bidirectional traceability”and “requirements traceability.”) Requirements traceability A discernable association between requirements andrelated requirements, implementations, and verifications. Bidirectional traceability An association among two or more logical entities that isdiscernable in either direction (i.e., to and from an entity).
6/24/201324Traceability-Attributes1. The requirement identification number2. The source of the requirement1. Such as the customers document paragraph number orthe engineering report documenting the analysis thatderived the requirement.3. The full text of the requirement4. For allocated or derived requirements, a pointer to therequirement from which it was derived, or "parent"requirement.5. A pointer to the next lower-level area that this requirementwas allocated to during the allocation processSource: SYSTEMS ENGINEERING HANDBOOK, A “HOW TO” GUIDE For All Engineers, Version 2.0, July 2000. InternationalCouncil on Systems Engineering (INCOSE).
6. Verification method (e.g. test, demonstration,analysis, inspection/examination).7. The Test Plan name & number controlling theverification8. The Test Procedure name & number performingthe verification9. The date and results of the final verification10. The name of the responsible engineer.Traceability-Attributes
Requirements Traceability Matrix** Also called Proof of Compliance Matrix or Verification MatrixLinda Westfall, Bidirectional Requirements Traceability, SQP, Dec 2007
Four types of requirements traceabilityCustomerNeedsRequirementsProductbackward fromrequirementsforward torequirementsforward fromrequirementsbackward torequirementsSource: Wiegers, K., „Software Requirements‟, Second Edition, Microsoft Press, 2003.
SI.O3 DocumentationTraceability Record (may includes) Identifies requirements of RequirementsSpecification to be traced Provides forward and backwards mapping ofrequirements to Software Design elements,Software Components, Test Cases and TestProcedures
Benefits of ImplementingTraceability1. Certification -Verification• The traceability information can be used forcertification in safety-critical applications To verify and demonstrate that all requirementswere implemented.2. Change Impact Analysis• Traceability links help find all of the system elementsthat might have to be modified if you change aparticular requirement. Without traceability information, chances are highyou‟ll overlook some of the side effects of adding,deleting, or modifying a requirement.
Benefits of ImplementingTraceability3. Project Tracking• If you complete the requirements traceabilitymatrix as development takes place, you willhave accurate insight into the implementationstatus of planned functionality. Empty space in the matrix indicates projectdeliverables that have not yet been created.4. Testing• Links between tests, requirements, and codepoint toward likely parts of the code to examinefor a bug when a test fails to yield the intendedresult
Benefits of ImplementingTraceability5. Reuse• Traceability information can facilitate the reuseof product components• By identifying packages of relatedrequirements, designs, code, tests, andother artefacts.6. Risk Management and Reduction• Documenting the information about systemcomponent interconnections reduces the riskassociated with a key team member leavingthe company with essential information residingonly in that person‟s brain
Benefits of ImplementingTraceability7. Reengineering• If you don‟t have complete requirements for theexisting system.• You can list the functions in a legacy system you‟rereplacing and record where they were addressed in therequirements and software components for the new system.• Provide a way to capture some of what you learnthrough reverse engineering.8. Identification of process improvements• e.g. Information about Requirements instability may be used toimprove the development process/change managementprocess9. Allows developer, customer or supplier to followclosely the development of components10. Help to reduce cost and delay and improvequality
Software Implementation (SI) ProcessSI.O4. Software components defined by the designare produced. Unit test are defined and performedto verify the consistency with requirements and thedesign. Traceability to the requirements and designare established.
Software Implementation (SI) ProcessSI.O5. Software is produced performing integration ofsoftware components and verified using Test Casesand Test Procedures. Results are recorded at the TestReport. Defects are corrected and consistency andtraceability to Software Design are established.
Establish Test PlanDesign Test CaseExecute TestWrite Test ReportRemove Software DefectTest CompleteApproveApproveRegression TestMoredefectTest 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 productincluding: 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) ProcessSI.O6. A Software Configuration, that meets the RequirementsSpecification as agreed to with the Customer, which includesuser, operation and maintenance documentations is integrated,baselined and stored at the Project Repository. Needs forchanges to the Software Configuration are detected andrelated Change Requests are initiated.
Software Implementation (SI) ProcessSI.O7. Verification and Validation tasks of all requiredwork products are performed using the defined criteriato achieve consistency among output and inputproducts in each activity. Defects are identified, andcorrected; records are stored in theVerification/Validation Results.
VerificationConfirmation by examination and provisions ofobjective evidence that specified requirements havebeen fulfilled.In design and development, verification concerns theprocess of examining the result of a given activity todetermine conformity with the stated requirement for thatactivity.
Validation Validation Confirmation by examination and provisions ofobjective evidence that the particularrequirements for a specific intended use arefulfilled. Validation is normally performed on the final productunder defined operating conditions. “Validated” is used to designate the correspondingstatus.
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 DocumentationVerification 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