Ch5 software imprementation1.0


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Ch5 software imprementation1.0

  1. 1. SE423 SPICH-5 ISO29110:Software ImplementationProcessKittitouch Suteeca
  2. 2. 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
  3. 3. ProjectManagementStatement of WorkSoftwareImplementationSoftwareConfigurationISO 29110
  4. 4. ISO29110 Deployment PackagesRequirementsAnalysisVersionControlIntegrationandTestsProjectManagementArchitectureAnd detailed designProductDeliverySelf-AssessmentConstructionAndUnit testingVerificationandValidation
  5. 5. 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.
  6. 6. ISO/IEC29110SOFTWARE IMPLEMENTATION PROCESS SI.1 Software Implementation Initiation SI.2 Software Requirement Analysis SI.3 Software Architectural and DetailedDesign SI.4 Software Construction SI.5 Software Integration and Tests SI.6 Software Delivery
  7. 7. Software Implementation (SI) ProcessSI.O1. Tasks of the activities are performedthrough the accomplishment of the currentProject Plan.
  8. 8. Software Implementation (SI) ProcessSI.O2. Software requirements are defined,analyzed for correctness and testability,approved by the Customer, baselined andcommunicated.
  9. 9. SI.O2 DocumentationRequirements Specification (may includes) Introduction Description Functionality User Interface Reliability Efficiency Maintenance
  10. 10. Software RequirementsSpecification (SRS) No specifics form. Guideline for SRSIEEE 830-1998:IEEE Recommended Practicefor Software RequirementsSpecification13
  11. 11. 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
  12. 12. 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
  13. 13. Characteristics of SRS [SW Tech Center, NASA]1. Complete [ IEEE 830]2. Consistent [ IEEE 830]3. Accurate4. Modifiable [ IEEE 830]5. Ranked [ IEEE 830]6. Testable7. Traceable [ IEEE 830]8. Unambiguous [ IEEE 830]9. Valid10. Verifiable [ IEEE 830]16
  14. 14. 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.
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. • 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
  19. 19. 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).
  20. 20. 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).
  21. 21. 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
  22. 22. 6/24/201326Some key requirementstraceability links. BusinessRequirementSystem Requirement, UseCase, External InterfaceRequirement,Quality attributesChangeRequestSoftware FunctionalRequirementArchitecture, User Interface,Functional DesignCodeSystemTestis verified byis satisfied byis implemented inis origin ofdrives specification ofModifiesProject PlanTaskLeads tocreation ofdepends onanotherWiegers K., Software Requirements, Microsoft Press, 2003ModifiesModifiesModifiesBusinessRulesis origin ofis verified byUnittestIntegrationtestis verified by
  23. 23. Requirements Traceability Matrix** Also called Proof of Compliance Matrix or Verification MatrixLinda Westfall, Bidirectional Requirements Traceability, SQP, Dec 2007
  24. 24. Four types of requirements traceabilityCustomerNeedsRequirementsProductbackward fromrequirementsforward torequirementsforward fromrequirementsbackward torequirementsSource: Wiegers, K., „Software Requirements‟, Second Edition, Microsoft Press, 2003.
  25. 25. 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
  26. 26. 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.
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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.
  31. 31. 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.
  32. 32. Establish Test PlanDesign Test CaseExecute TestWrite Test ReportRemove Software DefectTest CompleteApproveApproveRegression TestMoredefectTest Process : Flow Chart
  33. 33. SI.O5 DocumentationTest Cases and Test Procedures(may includes) Identifies the test case Test items Input specifications Output specifications Environmental needs
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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.
  38. 38. 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.
  39. 39. 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.
  40. 40. Requirement& DesignCodingTestVerificationTR
  41. 41. 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.
  42. 42. 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
  43. 43. 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