1 / 55

CHAPTER 5

CHAPTER 5. Infrastructure Components PART II. Typical infrastructure components. Procedures and work instruction. Quality support devices like templates and checklists. Staff SQA training and certification activities. Preventive and corrective actions. Software configuration management.

cheng
Download Presentation

CHAPTER 5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CHAPTER 5 Infrastructure Components PART II

  2. Typical infrastructure components • Procedures and work instruction. • Quality support devices like templates and checklists. • Staff SQA training and certification activities. • Preventive and corrective actions. • Software configuration management. • Documentation and quality records control. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  3. Corrective and Preventive Actions (CAPA) - Definition • Corrective actions: • A regularly applied feedback process that includes collection of information on quality non-conformities, identification and analysis of sources or irregularities as well as development and assimilation of improved practices and procedures, together with control of their implementation and measurement of their outcome. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  4. Corrective and Preventive Actions (CAPA) - Definition • Preventive actions: • A regularly applied feedback process that includes collection of information on potential quality problems, identification and analysis of departures from quality standards, development and assimilation of improved practices and procedures, together with control of their implementation and measurement of their outcome. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  5. Corrective and Preventive Actions (CAPA) - Definition • Sources of CAPA information: • Quality records, service reports, internal quality audits, project risk reviews, software risk management reports, etc. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  6. Corrective and Preventive Actions (CAPA) - Process • Successful operation of a CAPA process includes the following process: • Information collection (CAPA sources) • Analysis of information • Development of solutions and improved methods • Implementation of improved methods • Follow-up. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  7. The corrective and preventive action process ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  8. Sources of CAPA information SQA infrastructure class of sources • Internal quality audit reports • External quality audit reports • Performance follow-up of trained and certified staff • Proposals suggested by staff members. Software quality management procedures class of sources • Project progress reports • Software quality metrics reports • Software quality cost reports • Proposals of staff members. External information sources • Customer complaints • Customer service statistics • Customer-suggested proposals. Internal information sources Software development process • Software risk management reports • Design review reports • Inspection reports • Walkthrough reports • Experts’ opinion reports • Test reviews • Special reports on development failures and successes • Proposal suggested by staff members. Software maintenance • Customer applications statistics • Software change requests initiated by customer applications • Software change requests initiated by maintenance staff • Special reports on maintenance failures and successes • Proposals suggested by staff members. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  9. Analysis of collected information • Analysis involves: • Screening the information and identifying potential improvements. • Analysis of potential improvements, to determine: • Expected types and levels of damage • Causes of faults • Estimate total damage expected and determine the priority of each fault case. • Generating feedback on the content and regularity of information received from the designated information sources. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  10. Development of solutions • Solutions to identified causes of recurrent software systems faults are required to: • Eliminate recurrence of the types of faults detected • Contribute to improved efficiency by enabling higher productivity and shorter schedules. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  11. Development of solutions • Several directions for solutions are commonly taken: • Updating relevant procedures. Ex: changes of the maximum and minimum number of participants in a DR session, etc. • Changes in practices, including updating of relevant work instructions. • Shifting to a development tool that is more effective and less prone to the detected faults. • Improvement of reporting methods, including changes in report content, frequency of reporting and reporting tasks. • Initiatives for training, retraining or updating staff. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  12. Implementation of the solutions • Relies on proper instructions and often training but most of all on the cooperation of the relevant units and individuals. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  13. Follow-up of activities • Follow-up of the flow of development and maintenance CAPA records from various sources of information. • enables feedback that reveals cases of no reporting, low quality reporting – important details are incorrect/missing. • Follow-up of implementation. • Indicate whether the designated actions have been performed in practice. • Follow-up of outcomes. • Assessment of how much CAPA actions have achieved the expected results. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  14. Organizing for CAPA • Collecting CAPA records from the various sources. • Screening the collected information. • Nominating ad hoc CAPA teams to tend to given subjects or head the teams. • Promoting implementation of CAPA • Following up information collection, data analysis, progress made by ad hoc teams, implementation as well as outcomes of improved CAPA methods. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  15. Ad hoc CAPA teams They regularly focus on: • Analysis of the information related to the team’s topic. • Initiation of additional observations and inquiries. • Identification of the causes for the faults. • Development of solutions and the relevant CAPA. • Preparation of proposed implementation revisions. • Analysis of the CAPA implementation outcomes and CAPA revision if necessary. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  16. Configuration Management • Questions: • What is the correct version of the software module that I have to continue its coding? • Who can provide me with an accurate copy of last year’s version 4.1 of the TMY software system? • What version of the software system is installed at ABC Industries? • Etc.. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  17. Software configuration – Items and management • Software configuration item (SCI) or configuration item (CI): • An approved unit of software code, a document or piece of hardware that is designed for configuration management and treated as a distinct entity in the software configuration management process. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  18. Software configuration – Items and management • SCI version: • The approved state of an SCI at any given point of time during the development or maintenance process. • Software configuration version: • An approved selected set of documented SCI versions that constitute a software system or document at a given point of time, where the activities to be performed are controlled by software configuration management procedures. The software configuration versions are released according to the cited procedures. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  19. Common types of SCI • Design documents • SDP, SRD, PDD, CDD, STP, STPR, STR, etc. • Software code • Source code, object code, prototype software. • Data file • Test cases and test scripts, parameters, codes, etc. • Software development tools (the versions applied in the development and maintenance stages) • Compilers and debuggers, application generators, CASE tools. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  20. Example: 2 software configuration versions of PMT software Release and release date ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  21. Software configuration management (SCM) - Definition • SCM: • An SQA component responsible for applying (computerized and non-computerized) technical tools and administrative procedures that enable completion of the tasks required to maintain SCIs and software configuration versions. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  22. Tasks of the SCM • Control software change • Release of SCI and software configuration versions • Provision of SCM information services • Verification of compliance to SCM procedures. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  23. The software configuration authority • SCM procedures specify who is responsible for SCM issues. • This responsible usually assigned to a senior professional or a committee that been set-up to handle the SCM issues – software change control authority (SCCA) or software change control board (SCCB). • During the development phase, the project manager may be charged with the authority to carry out SCM responsibilities. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  24. Software control change • Software change management controls the process of introducing changes mainly by doing the following: • Examining change requests and approving implementation of appropriate requests. • Assuring the quality of each new version of software configuration before it becomes operational. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  25. Factors affecting approval of proposed changes • Expected contribution of the proposed change • Urgency of the change • Effect of the proposed change on project timetables, level of service, etc. • Efforts required in making the change operational • Required software quality assurance efforts • Estimated required professional resources and cost of performing the change. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  26. Software change request (SCR) document - a template • Change principles • The initiator • The date the SCR was presented • The character of the change • The goals • The expected contribution to the project/system • The urgency of performance • Change details • Description of the proposed change • A list of the SCIs to be changed • Expected effects on other SCIs • Expected effect on interfaces with other software systems and hardware firmware • Expected delays in development completion schedules and expected disturbances to services to customers • Change timetable and resources estimates • Timetable for implementation • Estimated required professional resources • Other resources required • Estimated total cost of the requested change. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  27. Quality assurance of software changes • Quality assurance efforts are required at two levels: • Quality assurance of each of the changed SCIs • Quality assurance of the entire new software system version (that includes changed SCIs). ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  28. Quality assurance of the changes SCIs • Require preparation of a reviews and testing plan at a magnitude appropriate to the character of the change. • It is important that reviews and testing be carried out by professional testers and not by the SCI’s developer. • The process of reviews and testing, corrections and re-testing (regression testing) the change SCIs is expected to conclude with their approval. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  29. Quality assurance of the entire new software system version • A new version of the software is considered to have been completed once the changed SCIs replace the former SCIs. • Many new versions, especially of complex software systems, actually fail. • The failures generally occur as a result of damage done to interfaces between the changed SCIs and other SCIs left unchanged and not retested because they were not expected to be affected by the changes performed. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  30. Release of software configuration versions • The need to release a new software configuration control: • Defective SCIs • Special features demanded by new customers • The team’s initiatives to introduce SCI improvements. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  31. Types of software configuration releases • Baseline versions • Planned early, during a system’s development or operating stage. • As part of the process, they are reviewed, tested and approved, as their SCIs. • They serve as milestones in the SDLC, and represent the foundations for further system development. • Intermediate versions • When problem arise that require immediate attention – an intermediate version of the software is often prepared. • Usually, serve only a portion of a firm’s customers, limited period, until replaced by a new baseline versions. • Can serve as a “pilot” to the next baseline version. • Revisions • Introduce minor changes and corrections to a given SC version. • In some cases, revisions are released before a new baseline version is released. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  32. Numeration conventions for identification of SCI and software versions • Decimal numeration • Indicates the successive version and revision numbers. • Example: DD7 Ver.1.0, DD7 Ver.1.1, etc. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  33. Software configuration management plans (SCMPs) • Objective: • to plan ahead the schedule of baseline version releases and the required resources to carry out all the activities required for the software configuration releases. • To enable one to follow up the progress of activities involved in software version release. • SCMPs are required during the development stage as well as the operation (maintenance) stage. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  34. SCMP – the content • An overview of the software development project or existing software system. • A list of scheduled baseline version releases. • A list of SCIs (documents, code, etc.) to be included in each version. • A table identifying the relationship of software development project plans and maintenance plans to scheduled releases of new SCIs or SCI versions. • A list of assumptions about the resources required to perform the SCMP. • Estimates of the human resources and budget needed to perform the SCMP. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  35. SCMP for the development stage • SCMP sets the release dates of baseline versions, which usually coincide with the conclusion of one or more of the following three events: the design stage, the coding stage and the system test stage – represent a segment of the entire system’s development plans, prepared at a project’s initiation. • Development process must be comply with the SCMP. • All instructions and procedures necessary for performing the SCM tasks are documented in the SCMP. • Responsibility – the project manager. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  36. SCMP for the operation (maintenance) stage • Further releases of software baseline versions are required. • SCMP usually schedules new baseline releases periodically – annual/semiannual, which include corrected/new versions of SCIs. • Only SCIs for which changes have been completed and approved by the targeted release date can be included in new SC versions. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  37. Software configuration evolution models • The linear evolution model • Only one unique SC version serves all customer at any given time. • For system that is developed to serve a single organization. • Applied to popular software packages • Uniform in structure. • The tree evolution model • Several parallel versions are developed to serve the needs of different customers. • Applied in firmware configuration versions, where each branch serves a different product or product line. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  38. Ver 4.1 IN Ver 4.0 BL Ver 3.0 BL Ver 2.2 IN Ver 2.1 IN Ver 2.0 BL Ver 1.0 BL Linear evolution model Software configuration evolution models Ver d1.1 IN Ver e1.1 BL Ver c2.0 BL Ver b1.1 IN Ver d1.0 BL Ver e1.0 BL Ver c1.1 BL Color printer Black printer Ver c1.0 BL Ver b1.0 BL Printer Printer- fax Ver a1.0 BL General Tree evolution model

  39. Software configuration release documentation – VDD template Identification and installations • Release version and revision number, including date • List of installations where the release was installed Configuration of the released version • List of SCIs (including SCI’s version) in the released software version • List of hardware configuration items required for operating the specified version • List of interfacing software and hardware systems • Installation instructions for the new release ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  40. Software configuration release documentation – VDD template (cont..) Changes in the new version • Previous software configuration version • List of SCIs that have been changed, new SCIs, and deleted SCIs • Short description of introduced changes. • Operational and other implications of changes in the release. Further development issues • List of software system problems that have not been solved in the new version. • List of delayed SCRs and proposals for development of the software system. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  41. Provision of SCM information services • The SCM is required to provide information to professionals, mainly developers, maintenance teams and customer representatives, who have requested that changes be introduced in a software system. • The information provided may be classified into information related to software change control and information dealing with SCI and software configuration versions: • Information related to software change control • Information about SCIs and software configuration versions. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  42. Information related to software control change • Change request status information – based on records for every submission of an SCR and the decisions made. • Change order progress information – based on records for every approved SCO, its schedule, implementation progress and test results, including the information about delays in performance. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  43. Information about SCIs and software configuration versions • Accurate copies of SCI versions (code SCIs, document SCIs, etc.) and entire software configuration versions. • Full reports of changes between successive releases (versions and/or revisions) of code SCIs and between successive releases of other types of SCIs. • Copies of SCI version documentation and software configuration version documentation (VDDs). • Detailed version and revision history for SCIs and software configurations. • Progress information about planned versions and releases • Information correlated about versions installed at a given site and about the site itself. • List where a given software configuration version is installed. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  44. Software configuration management audits – report on: • Percentage of unapproved changes introduced in the system during development or operation. • Percentage of SCOs not carried out according to instructions and not fully complying with procedures. • Percentage of design reviews and software tests of changed SCIs that have not been performed according to the relevant procedures. • Percentage of SCOs that have been completed on schedule. • Percentages of cases where SCIs affected by changes have not been checked, with some necessary changes not implemented. • Percentages of properly documented new SCIs and software configuration versions. • Percentage of properly documented installations of new software configuration versions. • Percentage of cases of failure to transmit all versions-related information to the customer. • Number of cases recorded annually where the SCI work coordination mechanism failed (i.e., did not prevent different teams from simultaneously introducing changes in the same SCI). ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  45. Computerized tools for managing software configuration • Application of tools in SC differs in their level of comprehensiveness, flexibility of application and ease of use. • Benefit of using computerized tools: • Able to comply with the required level of accuracy and completeness of information, and with the required level of availability. • Operate the mechanisms coordinating the work on an SCI’s changes and prevent different teams from simultaneously introducing changes in the same SCI. • Secures the code version and documentation files versions by protecting them from any changes, deletions and other damages. • Activates back-up procedures required for safe SCM file storage. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  46. Documentation Control • Controlled document: • A document that is currently vital or may become vital for the development and maintenance of software systems as well as for the management of current and future relationships with the customer. • Its preparation, storage, retrieval and disposal are controlled documentation procedures. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  47. Documentation Control • Quality record: • A special type of controlled document. • Customer-targeted document that may be required to demonstrate full compliance with customer requirements and effective operation of the software quality assurance system throughout the development and maintenance processes. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  48. Documentation control - objectives • To assure the quality of the document. • To assure its technical completeness and compliance with document structure procedures and instructions (use of template, proper signing, etc). • To assure the future availability of documents that may be required for software system maintenance, further development, or responses to the customer’s (tentative) future complaints. • To support investigation of software failure causes and to assign responsibility as part of corrective and other actions. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  49. Typical controlled documents (including quality records) • Pre-project documents • Contract review report, negotiation meeting minutes, development contract, subcontracting contract, software development plan, etc. • Project life cycle documents • SRD, preliminary design document, critical design document, database description, DR report, STP, etc. • SQA infrastructure documents • SQA procedures, template library, SQA form library, etc. • Software quality management documents • Progress report, software metrics reports, etc. • SQA audit documents • Management review report, internal quality audit report, etc. • Customer documents • Software project tender documents, customer’s software change requests, etc. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

  50. Typical component of documentation control procedures • Definition of the list of the document typesand updates to be controlled (some classified as quality records). • Document preparation requirements. • Document approval requirements. • Document storage and retrieval requirements,including controlled storage of document versions, revisions and disposal, document security. ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser

More Related