3.SQA components[Part 1 & Part 2] (1).pdf

OHT 4.1 Software Quality assurance (SQA) SWE 333 SQA Components Dr. Fayez Alqahtani [email protected] Galin, SQA from theory to implementation © Pearson Education...

OHT 4.1 Software Quality assurance (SQA) SWE 333 SQA Components Dr. Fayez Alqahtani [email protected] Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.2 Outline Pre-project components Software project life cycle components Infrastructure components for error prevention and improvements Management SQA components SQA standards, system certification and assessment components Organizing for SQA – the human components Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.3 Components of software quality System assurance system overview Software quality assurance consists of different components Each component is related to a certain part of the software development process ‫حتى في‬ ‫مراحل مبكرة‬ :‫من المشروع‬ If care is taken to perform every ‫مثل توقيع العقد‬ component to the required quality level then a complete system with high quality is achieved ‫يحد من حدوث أخطاء في‬ Galin, SQA from theory to implementation ‫البرمجيات‬ © Pearson Education Limited 2004  OHT 4.4 Components of Software Quality Assurance System: SQA Architecture Software Quality :‫ترجمة حرفية‬ Shrine ‫"مقام" جودة البرمجيات‬ (2) (3) (4) (5) (6) Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.5 Components of software quality assurance system overview Pre-project components Software project life cycle components Infrastructure components for error prevention and improvements Management SQA components SQA standards, system certification and assessment components Organizing for SQA – the human components ‫مكونات ما قبل المشروع‬ ‫مكونات دورة حياة تطوير البرمجيات‬ ‫مكونات البنية التحتية للتحسينات ومنع األخطاء‬ ‫مكونات إدارة ضمان جودة البرمجيات‬ ‫معايير وشهادات ضمان جودة البرمجيات‬ ‫المكون البشري في تنظيم ضمان جودة البرمجيات‬ Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.6 Pre-project SQA components The SQA components belonging here are meant to improve the preparatory steps taken prior to initiating work on the project itself Resources, budget & schedule Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.7 Pre-project SQA components There are two components in pre-project stage: Contract reviews: Reviewing the contract prior to final agreement Development and quality plans: Preparation of plans before the actual work is performed Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.8 Pre project component: Contract Review Software may be developed within the framework of a contract negotiated with a customer or in response to an internal order originating in another department. Contract review activities must include a detailed examination of the project proposal draft and the contract drafts. Contract review is an important software quality component because it ensures that we understand and agree on all project details. It eliminates any disagreement that might happen between the project parties Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.9 Contract review activities include: Clarification of the customer’s requirements Review of the project’s schedule and resource requirement estimates Evaluation of the professional staff’s capacity to carry out the proposed project Evaluation of the customer’s capacity to fulfill his obligations Evaluation of development risks. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.10 Contract review – a story A happy gathering of the CFV project team at a popular restaurant downtown was called to celebrate the successful completion of a 10-month project for Carnegie Fruits and Vegetables, a produce wholesaler. The new information system registers product receipts from growers, processes clients’ orders and produce shipments to clients (greengrocers and supermarkets), bills clients, and calculates payments made to the growers. The team members were proud to emphasize that the project was conducted in full as originally scheduled. The team was especially jubilant as earlier that morning each member had received a nice bonus for finishing on time. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.11 Contract review – a story The third speaker, the software company’s Vice President for Finance, altered the pleasant atmosphere by mentioning that this very successful project had actually lost about $90 000. During his remarks, he praised the planners for their good estimates of the resources needed for the analysis and design phase, and for the plans for broad reuse of software from other systems that were, this time, completely realized. “The only phase where our estimates failed was one of the project’s final phases, the client’s instruction, that where the client’s staff are instructed on how to use the new information system. It now appears that no one had read the relevant RFP (requirement for proposal) section carefully Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.12 Contract review – a story enough. This section stated in a rather innocuous manner that the personnel in all the CFV branches where the software was to be installed would be instructed in its use by the software supplier.” After a short pause he continued thus: “Nobody tried to find out how many branches our client operates. Nobody mentioned that CFV operates 19 branches – six of them overseas – before signing the contract!” Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.13 Contract review – a story He continued: “We tried to renegotiate the installation and instruction budget items with the client, but the client insisted on sticking to the original contract.” Though no names were mentioned, it was clear that he blamed the sales negotiating team for the loss. Contract review is the software quality element that reduces the probability of such undesirable situations. Contract review is a requirement by the ISO 9001 standard and ISO 9000-3 Guidelines Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.14 Pre project component: Development and quality plans Once a software development contract has been signed or a commitment made to undertake an internal project for the benefit of another department of the organization, a plan is prepared of the project (“development plan”) and its integrated quality assurance activities (“quality plan”) Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.15 The main issues treated in the project development plan are: Schedules (What are tasks and how much time is required) Required manpower and hardware resources Risk evaluations Organizational issues: team members, subcontractors and partnerships Project methodology, development tools, etc. Software reuse plans. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.16 Software quality plan A quality plan sets out (within a particular project) the desired product qualities and how these are assessed and define the most significant quality attributes It should define the quality assessment process Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.17 Software quality plan Software quality plan is a document that describes the quality activities of a software project that should be implemented to ensure that the results of the work performed will satisfy the users and achieve the required quality. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.18 Software quality plan Usually a software quality plan includes: Quality goals, expressed in the appropriate measurable terms Criteria for starting and ending each project stage Lists of reviews, tests, and other scheduled verification and validation activities. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.19 Software quality plan More details about how to prepare and implement a software quality plan will be discussed latter. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.20 Software project life cycle components Several SQA components enter the software development project life cycle at different points. Their use should be planned prior to the project’s initiation. The main components are: Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.21 Software project life cycle components Reviews Expert opinions Software testing Assurance of the quality of external participants’ work Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.22 Software Project life cycle components: Reviews Several phases of the development process produce a variety of documents. For example: design reports, software test documents, software installation plans and software manuals. These have to be reviewed to ensure that specified qualities have been met. Reviews types: peer reviews , DRs Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.23 Software Project life cycle components: Expert opinions Expert opinions support quality assessment efforts by introducing additional external capabilities into the organization’s in- house development process. Turning to outside experts may be particularly useful in the following situations: Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.24 Software Project life cycle components: Expert opinions Insufficient in-house professional capabilities in a given area. In small organizations in many cases it is difficult to find enough suitable candidates to participate in the design review teams. In cases of major disagreement among the organization’s senior professionals, an outside expert may support a decision. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.25 Software Project life cycle components: Software testing Software tests are formal SQA components that are targeted toward review of the actual running of the software. The tests are based on a prepared list of test cases that represent a variety of expected scenarios. Software tests examine software modules, software integration, or entire software packages Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.26 Software Project life cycle components: Assurance of the quality of the external participant’s work Subcontractors and customers frequently join the directly contracted developers in carrying out software development projects. The larger and more complex the project, the greater the likelihood that external participants will be required, and the larger the proportion of work transmitted to them (subcontractors, suppliers of COTS software and the customer). Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.27 Software Project life cycle components: Assurance of the quality of the external participant’s work Most of the SQA controls applied to external participants are defined in the contracts signed between the relevant parties. If an external participant’s work is performed using software assurance standards below those of the supplier’s, risks of not meeting schedule or other requirements are introduced into the project. Hence, special software assurance efforts are required to establish effective controls over the external participant’s work. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.28 Infrastructure components for prevention and improvement Procedures and work instruction Templates and checklists Staff training, retraining and certification Preventive and corrective actions Configuration management Documentation control Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.29 Infrastructure components for error prevention and improvement The goals of SQA infrastructure are the prevention of software faults or, at least, the lowering of software fault rates, together with the improvement of productivity. SQA infrastructure components are developed specifically to this end. These components are devised to serve a wide range of projects and software Galin, SQA from theory to implementation © Pearson Education Limited 2004 maintenance services.  OHT 4.30 Infrastructure components for error prevention and improvement This class of SQA components includes: Procedures and work instructions Templates and checklists Staff training, retraining, and certification Preventive and corrective actions Configuration management Documentation control. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.31 Procedures and work instructions Quality assurance procedures usually provide detailed definitions for the performance of What specific types of development activities in a way that assures effective achievement of quality results. – Procedures are planned to be generally applicable and to serve the entire organization. Work instructions, in contrast, provide detailed How directions for the use of methods that are applied in unique instances and employed by ‫عندما تعرف ماذا يجب أن تعمل وكيف ستقوم بذلك فهذا دليل للعمل بشكل صحيح‬ specialized teams. ‫ويقلل حدوث األخطاء وبالتالي هو ضمان للجودة‬ Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.32 ‫قوالب التقارير والعمل وقوائم المراجعة‬ Templates and checklists One way to combine higher quality with higher efficiency is to use Templates and checklists. Saving the time required to define the structure of the various documents Contributing to the completeness of the documents and reviews. Improving communication between development team and review committee members by standardizing documents and agendas. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.33 Staff training, instruction and certification keeping an organization’s human resources knowledgeable and updated at the level required is achieved mainly by: Training new employees and retraining those employees who have changed assignments. Continuously updating staff with respect to professional developments and the in-house, hands-on experience acquired. Certifying employees after their knowledge and ability have been demonstrated. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.34 Preventive and corrective actions Systematic study of previous failures and success stories to implement. Among them we can list: Implementation of changes that prevent similar failures in the future. Correction of similar faults found in other projects and among the activities performed by other teams. Implementing proven successful methodologies to enhance the probability of repeat successes. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.35 Configuration Management The regular software development and maintenance operations involve intensive activities that modify software to create new versions and releases. These activities are conducted throughout the entire software service period in order to cope with the needed corrections, adaptations to specific customer requirements, application improvements, and so forth. Different team members carry out these activities simultaneously. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.36 Configuration Management Changes may take place at different sites. As a result, serious dangers arise, whether of misidentification of the versions ,releases or documentation loss. Configuration management deals with these hazards by – introducing procedures to control the change process. These procedures relate to the approval of changes, the recording of those changes performed, Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.37 Configuration Management – Also the issuing of new software versions and releases, the recording of the version and release specifications of the software installed in each site, and the prevention of any changes in approved versions and releases once they are issued. Most configuration management systems implement computerized tools to accomplish their tasks. These computerized systems provide the updated and proper versions of the installed software and their documentation. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.38 Management SQA components Project progress control in terms of schedule and cost Software quality metrics to measure quality Software quality costs Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.39 Project progress control in terms of schedule and cost The main objective of project progress control components is to detect the appearance of any situation that may lead to deviations from the project’s plans and maintenance service ‫المراقبة المستمرة تساعد على اكتشاف األخطاء بسرعة وفي‬ performance. ‫الوقت المناسب‬ Clearly, the effectiveness and efficiency of the corrective measures implemented is dependent on the timely discovery of undesirable situations. ‫التدخل في الوقت المناسب يساعد على رفع فعالية اإلجراءات‬ ‫التصحيحية‬ Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.40 Project progress control in terms of schedule and cost Project control activities focus on: Resource usage Schedules Risk management activities The budget. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.41Project progress control in terms of schedule and cost It is important that project managers be able to control cost in terms of budget and time in terms of schedule The better cost control means a better software quality from the point view of higher management The same can be said for schedule Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.42 Software quality metrics to measure quality Software quality metrics are used to measure the quality of software These are created by project managers For example How many error did the programmer made in one hundred line of code How many revision has been made to the requirements document (Software engineers quality of work) Software quality metrics will be discussed in details later Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.43 Software quality metrics to measure quality Among the software quality metrics available or still in the process of development, we can list metrics for: Quality of software development and maintenance activities Development teams’ productivity Help desk and maintenance teams’ productivity Software faults density Schedule deviations. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.44 Software quality costs Quality has a cost It is the responsibility of the project manager to control that costs The lower the cost of quality, the better software quality Software quality cost will be discussed later Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.45 SQA standards, system certification and assessment componenets Project process standards Quality management standards Objectives: ▪ Utilization of international professional knowledge ▪ Improvement of coordination with other organizations’ quality systems ▪ Objective professional evaluation and measurement of the organization’s SQA achievement Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.46 Quality Management Standards The organization can clearly benefit from quality standards that guide the management of software development, maintenance, SQA standards, system certification, and assessment components and infrastructure. These standards focus on what is required and leave the decision about how to achieve it to the organization. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.47 Quality management standards The application of a managerial quality system provides a fairly objective assessment of the organization’s achievements. Organizations that comply with quality achievement requirements can then seek SQA certification. The most familiar examples of this type of standard are: SEI CMM assessment standard ISO 9001 and ISO 9000-3 standards. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.48 Project process standard Project process standards are professional standards that provide methodological guidelines (dealing with the question of “how”) for the development team. Well-known examples of this type of standards are: IEEE 1012 standard ISO/IEC 12207 standard. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.49 Components of software quality assurance system SQA Architecture (2) (3) (4) (5) (6) Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.50 Organizing for SQA – the human components SQA components require an organizational base. The main objectives of the SQA organizational base are as follows: To develop and support implementation of SQA components. To detect deviations from SQA procedures and methodology. To suggest improvements to SQA components. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.51 6. Organizing for SQA – the human components Management’s role in SQA The responsibilities of top management The SQA unit This unit and software testers are the only parts of the SQA organizational base that devote themselves full- time to SQA matters. Galin, SQA from theory to implementation © Pearson Education Limited 2004  OHT 4.52 6. Organizing for SQA – the human components SQA trustees, committees and forums SQA trustees are members of development and maintenance teams who have a special interest in software quality and are prepared to devote part of their time to these issues. SQA committee members are members of various software development and maintenance units, and are usually appointed for term or ad hoc service. SQA forums are composed of professionals and practitioners who meet and/or maintain an Internet site on a voluntary basis for discussion of quality issues pertaining to development and maintenance processes. Galin, SQA from theory to implementation © Pearson Education Limited 2004