You are on page 1of 14


2marks 1. Dagal features. • • • Dagal Features provides no warranty, either expressed or implied, with respect to AMGAL’s performance, reliability or fitness for any specified purpose. Dagal Features does not warrant that the software or its documentation will fulfill your requirements. Dagal Features does not provide any warranty that the software and its documentation are free of errors.

2. Difference between software and industrial products. o Product complexity o Product visibility. o Product development and production process

3. Phases of detecting defects in industrial products. • • • Product development. Product production planning Manufacturing

4. List the uniqueness of software development process The uniqueness of the software development process o High complexity, as compared to other industrial products o Invisibility of the product o Opportunities to detect defects (“bugs”) are limited to the product development phase

allowing effective detection of defects by sight Visibility of product Nature of development and production process Opportunities to detect defects arise in all phases of development and production: Product development.g. Manufacturing 6. Invisible product.5. Characteristic Complexity Software products Complexity Usually. Visible product. very complex product allowing for very large number of operational options. What are the main characteristics of the environment for which SQA methods are developed?  Contractual conditions  Subjection to customer–supplier relationship  Required teamwork  Cooperation and coordination with other software teams  Interfaces with other software systems  The need to continue carrying out a project despite team member changes  The need to continue carrying out software maintenance for an extended period. other industrial products. allowing at most a few thousand operational options. Product production planning. of a diskette or CD storing the software) Opportunities to detect defects arise in only one phase. namely product development Other industrial products Degree of complexity much r lowers. . Factors affecting defect detection in software products vs. impossible to detect defects or omissions by sight (e.

procedures. Classification of causes of software errors. Difference between correct and incorrect procedure. • • 9. or a logical error in carrying out one or more of the client’s requirements Not all software errors become software faults. faulty application. An error can be a grammatical error in one or more of the code lines. • The origin of software failures lies in a software error made by a programmer.          Faulty definition of requirements Client–developer communication failures Deliberate deviations from software requirements Logical design errors Coding errors Non-compliance with documentation and coding instructions Shortcomings of the testing process Procedure errors Documentation errors 10. faults and failures. the software error can cause improper functioning of the software in general or in a specific application. 8. in some cases. Software is: Computer programs. Refer Page no:23 . Define software errors. In other words.7. IEEE definition of Software. A software fault becomes a software failure only when it is “activated” – when the software user tries to apply the specific. and possibly associated documentation and data pertaining to the operation of a computer system.

A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.  Specific functional requirements. or process meets customer or user needs or expectations. The degree to which a system. Software quality is: 1. 15. Pressman’s definition of software quality. or process meets specified requirements. Contrast with quality control. A set of activities designed to evaluate the process by which the products are developed or manufactured.  Good Software Engineering Practices (GSEP). SQA vs. 2. The degree to which a system. component. which refer mainly to the outputs of the software system. 2. 12. reflecting state-of-the-art professional practices. and implicit characteristics that are expected of all professionally developed software. IEEE definition of SQA. component.  The software quality standards mentioned in the contract. SQC. . explicitly documented development standards. IEEE definition of software quality. Software quality is defined as: Conformance to explicitly stated functional and performance requirements. Software quality assurance is: 1. to be met by the developer even though not explicitly mentioned in the contract. 14. 3 requirements given by pressman for quality assurance. 13.11.

Objectives of SQA activities. including usability aspects. 16. The 11 factors are grouped into three categories – product operation. There is a need for a comprehensive definition of requirements that will cover all attributes of software and aspects of the use of software. quality control inspection and other activities take place as the development or manufacturing of the product is completed yet before the product is shipped to the client. These activities prevent the causes of errors. McCall’s factor model. Interoperability. Reliability. Three quality factors comprise the product revision category.  The main objective of quality assurance is to minimize the cost of guaranteeing quality by a variety of activities performed throughout the development and manufacturing processes/stages. and so forth in order to assure the full satisfaction of the users. McCall’s factor model classifies all software requirements into 11 software quality factors. . 19. Quality control is defined as “a set of activities designed to evaluate the quality of a developed or manufactured product. Flexibility. 18. Usability. Integrity. Need for comprehensive software quality requirements. and detect and correct them early in the development process. ■ Product transition factors: Portability. Testability. Efficiency. reusability aspects.  Software development (process-oriented)  Software maintenance (product-oriented) 17. Reusability. maintainability aspects. product revision and product transition – as follows: ■ Product operation factors: Correctness. ■ Product revision factors: Maintainability.

Formal comparison of alternative models.  The Deutsch and Willis factor model (Deutsch and Willis. The Evans and Marciniak factor model consists of 12 factors that are classified into three categories. Five new factors suggested by the two alternative factor models • • • • • • Verifiability (by both models) Expandability (by both models) Software quality factors Safety (by Deutsch and Willis Manageability (by Deutsch and Willis) Survivability (by Deutsch and Willis). 23. namely the testability factor. .• • • Maintainability Flexibility Testability 20. • • • Portability Reusability Interoperability 21. 1987).  The Evans and Marciniak factor model (Evans and Marciniak. 22. 1988). Alternative models of software quality factors. • • Both alternative models exclude only one of McCall’s 11 factors. Three quality factors included in the product transition category.

24. Two requirements documents expected for project. Who is interested in the definition of quality requirements?  Client  Software developer Examples: o Reusability requirements o Verifiability requirements 26. 28. Compare factors and sub-factors of software quality.    Portability Reusability Verifiability 27. Five new factors suggested by the two alternative factor models.      Verifiability (by both models) Expandability (by both models) Safety (by Deutsch and Willis) Manageability (by Deutsch and Willis) Survivability (by Deutsch and Willis). o The client’s requirements document o The developer’s additional requirements document.• The Deutsch and Willis factor model consists of 15 factors that are classified into four categories. 25. . Factors which raise very little interest on the part of the client.

Factor model Software quality Factors Sub-factors McCall’s model: Product operation category Correctness Accuracy Completeness Up-to-dateness Availability (response time) Coding and documentation guidelines compliance (consistency) Reliability System reliability Application reliability Computational failure recovery Hardware failure recovery Efficiency Efficiency of processing Efficiency of storage Efficiency of communication Efficiency of power usage (for portable units) Integrity Access control Access audit Usability Operability Training .

29. The project life cycle is composed of two stages:  The development life cycle stage and  The operation–maintenance stage. Organizing for SQA – the human components 30. certification. Two pre-project components. Components of infrastructure error prevention and improvement.       Pre-project components. • • Contract review Development and quality plans. Components of project life cycle activities assessment. Components of software quality management. and SQA system assessment. Contract review activities ■ 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. Two stages of project life cycle. Six classes of SQA system components. 31. Main issues treated in the project development plan . Components of standardization. 32. 33.

o Software reuse plans. The main components are: ■ Reviews ■ Expert opinions ■ Software testing ■ Software maintenance ■ Assurance of the quality of the subcontractors’ work and the customer supplied parts. subcontractors and partnerships Project methodology. development tools. 34. Various categories of software maintenance services. expressed in the appropriate measurable terms. Main components in software development project life cycle.o Schedules o Required manpower and hardware resources o Risk evaluations o Organizational issues: team members. tests. etc. ■ Adaptive maintenance ■ Functionality improvement maintenance . Main issues treated in the project’s quality plan  Quality goals. 35. and other scheduled verification and validation activities. 36.  Criteria for starting and ending each project stage  Lists of reviews. These services fall into the following categories: ■ Corrective maintenance code and documentation failures.

37. Pre-maintenance components • • Maintenance contract review Maintenance plan. Software development life cycle components These components are applied for functionality improvement and adaptive maintenance tasks. Documentation control activities  Definition of the types of controlled documents needed . 38. • • • • • • Procedures and work instructions Templates and checklists Staff training. Infrastructure SQA components  Maintenance procedures and instructions  Supporting quality devices  Maintenance staff training. 40. 41. retraining. and certification  Maintenance preventive and corrective actions  Configuration management  Control of maintenance documentation and quality records. retraining. and certification Preventive and corrective actions Configuration management Documentation control. 39. Class of SQA components in infrastructure components. activities whose characteristics are similar to those of the software development process.

   Specification of the formats. The main objectives of the SQA organizational base are as follows:  To develop and support implementation of SQA components. 42.  To detect deviations from SQA procedures and methodology. 44. 43. Management’s role in SQA o Definition of the quality policy o Effective follow-up of quality policy implementation o Allocation of sufficient resources to implement quality policy . Managerial SQA components  Project progress control (including maintenance contract control)  Software quality metrics  Software quality costs. etc. Main objectives of the SQA organizational base. Software quality metrics  Quality of software development and maintenance activities  Development teams’ productivity  Help desk and maintenance teams’ productivity  Software faults density  Schedule deviations. Definition of review and approval processes for each controlled document Definition of the archive storage methods. document identification methods.  To suggest improvements to SQA components 45.

The main issues dealt in SQA committees o Solution of software quality problems. followed by initiation of corrective and preventive actions when appropriate. Contributions of SQA trustees • • • • Solving team or unit local quality problems Detecting deviations from quality procedures and instructions Initiating improvements in SQA components Reporting to the SQA unit about quality issues in their team or unit. o Initiation and development of new procedures and instructions. . o Initiation and development of new SQA components and improvement of existing components. updating existing materials. • • • • • Preparation of annual quality programs Consultation with in-house staff and outside experts on software quality issues Conduct of internal quality assurance audits Leadership of quality assurance various committees Support of existing quality assurance infrastructure components and their updates. o Analysis of problem and failure records as well as other records. budget and customer relations difficulties 46. List the SQA task break down into a number of primary roles.o Assignment of adequate staff o Follow-up of compliance of quality assurance procedures o Solutions of schedule. 48. and development of new components 47.

50. Various considerations of an organization’s SQA system  Organizational considerations  Project and maintenance service considerations  Professional staff considerations . Two main categories of the decisions regarding organization’s SQM Decisions regarding the organization’s software quality management system fall into two main categories: (a) The SQA organizational base (b) The SQA components to be implemented within the organization and the extent of their use.49.