a) Define software quality and software quality assurance.
b) Distinguish between software errors and software faults. Identify the various causes of software errors. Software quality
IEEE definition: Software quality is: 1. The degree to which a system, component, or process meets specified requirements. 2. The degree to which a system, component, or process meets customer or user needs or expectations.
Pressmans definition: Software quality is defined as: Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. Software quality assurance
IEEE definition: Software quality assurance is: 1. A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. 2. A set of activities designed to evaluate the process by which the products are developed or manufactured. Contrast with quality control.
Expanded definition: Software quality assurance is a systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within the budgetary confines. Distinguish between software errors, software faults and software failures. Software errors are sections of the code that are partially or totally incorrect as a result of a grammatical, logical or other mistake made by a systems analyst, a programmer, or another member of the software development team. Software faults are software errors that cause the incorrect functioning of the software during a specific application. Software faults become software failures only when they are activated, that is, when a user tries to apply the specific software section that is faulty. Thus, the root of any software failure is a software error. The nine causes of software errors 1. Faulty requirements definition 2. Clientdeveloper communication failures 3. Deliberate deviations from software requirements 4. Logical design errors 5. Coding errors 6. Non-compliance with documentation and coding instructions 7. Shortcomings of the testing process 8. Procedure errors 9. Documentation errors
Question 02: a) Explain the relationship between software quality assurance and software engineering. b) What are the three factor categories belonging to McMall's factor model? What factors are included in each of the categories? a) Explain the relationship between software quality assurance and software engineering. Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. The characteristics of software engineering, especially its systematic, disciplined and quantitative approach, make software engineering a good environment for achieving SQA objectives. It is commonly accepted that cooperation between software engineers and the SQA team is the way to achieve efficient and economic development and maintenance activities that, at the same time, assure the quality of the products of these activities. b) McCalls factor model McCalls factor model classifies all software requirements into 11 software quality factors. The 11 factors are grouped into three categories a) Product operation, b) Product revision and c) Product transition
Product operation factors: According to McCalls model, five software quality factors are included in the product operation category, all of which deal with requirements that directly affect the daily operation of the software. These factors are as follows: o Correctness, o Reliability, o Efficiency, o Integrity, o Usability. Product revision factors: According to the McCall model of software quality factors, three quality factors comprise the product revision category. These factors deal with those requirements that affect the complete range of software maintenance activities: corrective maintenance (correction of software faults and failures), adaptive maintenance (adapting the current software to additional circumstances and customers without changing the software) and perfective maintenance (enhancement and improvement of existing software with respect to locally limited issues). These are as follows: o Maintainability, o Flexibility, o Testability. Product transition factors: According to McCall, three quality factors are included in the product transition category, a category that pertains to the adaptation of software to other environments and its interaction with other software systems. These are as follows: o Portability, o Reusability, o Interoperability.
Question 03: a) Mention different components of SQA system architecture. b) What are the main issues treated in the project development plan. a) SQA system architecture component are: Pre-project quality components Project life cycle quality components Infrastructure error preventive and improvement components Software quality management components Standardization, certification and SQA assessment components Organizing for SQA the human components b) The main issues treated in the project development plan are: Schedules Required manpower and hardware resources Risk evaluations Organizational issues: team members, subcontractors and partnerships Project methodology, development tools, etc. Software reuse plans. The main issues treated in the projects quality plan are: 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.
Question 04: a) Briefly describe Formal design reviews (DRs) method. b) What are the functions of Expert opinions component in software development project life cycle. a) Formal design reviews (DRs) A significant portion of these documents requires formal professional approval of their quality as stipulated in the development contract and demanded by the procedures applied by the software developer. It should be emphasized that the developer can continue to the next phase of the development process only on receipt of formal approval of these documents.
Ad hoc committees whose members examine the documents presented by the development teams usually carry out formal design reviews (widely known as DRs).
When a design review committee sits in order to decide upon the continuation of the work completed so far, one of the following options is usually open for consideration: Immediate approval of the DR document and continuation to the next development phase. Approval to proceed to the next development phase after all the action items have been completed and inspected by the committees representative. An additional DR is required and scheduled to take place after all the action items have been completed and inspected by the committees representative. b) Expert opinions Expert opinions support quality assessment efforts by introducing additional external capabilities into the organizations in-house development process. Turning to outside experts may be particularly useful in the following situations: 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 such situations, outside experts may join a DR committee or, alternatively, their expert opinions may replace a DR. In small organizations or in situations characterized by extreme work pressures, an outside experts opinion can replace an inspection. Temporary inaccessibility of in-house professionals (waiting will cause substantial delays in the project completion schedule). In cases of major disagreement among the organizations senior professionals, an outside expert may support a decision.
Question 05: a) List the objectives of contract review. b) Briefly describe software maintenance components. a) Contract review objectives: 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. An internal order may entail a request for developing a firmware software system to be embedded within a hardware product, an order for a software product to be sold as a package, or an order for the development of administrative software to be applied within the company. In all these instances, the development unit is committed to an agreed-upon functional specification, budget and schedule.
Accordingly, contract review activities must include a detailed examination of (a) The project proposal draft and (b) The contract drafts. Specifically, contract review activities include: Clarification of the customers requirements Review of the projects schedule and resource requirement estimates Evaluation of the professional staffs capacity to carry out the proposed project Evaluation of the customers capacity to fulfill his obligations Evaluation of development risks. b) Software maintenance components Software maintenance services vary in range and are provided for extensive periods, often several years. These services fall into the following categories: Corrective maintenance Users support services and correction of software code and documentation failures. Adaptive maintenance Adaptation of current software to new circumstances and customers without changing the basic software product. These adaptations are usually required when the hardware system or its components undergo modification (additions or changes). Functionality improvement maintenance The functional and performance-related improvement of existing software, carried out with respect to limited issues.