UNIT-1

2marks 1. Dagal features. Dagal Features provides no warranty, either expressed or implied, with respect to AMGALs 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

5. Factors affecting defect detection in software products vs. other industrial products. Characteristic Complexity Software products Complexity Usually, very complex product allowing for very large number of operational options. Invisible product, impossible to detect defects or omissions by sight (e.g. 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, allowing at most a few thousand operational options. Visible product, 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, Product production planning, Manufacturing

6.

What are the main characteristics of the environment for which SQA methods are developed? Contractual conditions Subjection to customersupplier 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.

7. IEEE definition of Software. Software is: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.

8. Define software errors, faults and failures. The origin of software failures lies in a software error made by a programmer. An error can be a grammatical error in one or more of the code lines, or a logical error in carrying out one or more of the clients requirements Not all software errors become software faults. In other words, in some cases, the software error can cause improper functioning of the software in general or in a specific application. A software fault becomes a software failure only when it is activated when the software user tries to apply the specific, faulty application.

9. Classification of causes of software errors. Faulty definition of requirements Clientdeveloper 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. Difference between correct and incorrect procedure. Refer Page no:23

11. IEEE definition of software quality. 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.

12. Pressmans definition of software quality. 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.

13. 3 requirements given by pressman for quality assurance. Specific functional requirements, which refer mainly to the outputs of the software system. The software quality standards mentioned in the contract. Good Software Engineering Practices (GSEP), reflecting state-of-the-art professional practices, to be met by the developer even though not explicitly mentioned in the contract.

14. IEEE definition of SQA. 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.

15. SQA vs. SQC.

Quality control is defined as a set of activities designed to evaluate the quality of a developed or manufactured product. 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.

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. These activities prevent the causes of errors, and detect and correct them early in the development process.

16. Objectives of SQA activities. Software development (process-oriented) Software maintenance (product-oriented)

17. Need for comprehensive software quality requirements. There is a need for a comprehensive definition of requirements that will cover all attributes of software and aspects of the use of software, including usability aspects, reusability aspects, maintainability aspects, and so forth in order to assure the full satisfaction of the users.

18. McCalls factor model. McCalls factor model classifies all software requirements into 11 software quality factors. The 11 factors are grouped into three categories product operation, product revision and product transition as follows: Product operation factors: Correctness, Reliability, Efficiency, Integrity, Usability. Product revision factors: Maintainability, Flexibility, Testability. Product transition factors: Portability, Reusability, Interoperability.

19. Three quality factors comprise the product revision category.

Maintainability Flexibility Testability

20. Three quality factors included in the product transition category. Portability Reusability Interoperability

21. Alternative models of software quality factors. The Evans and Marciniak factor model (Evans and Marciniak, 1987). The Deutsch and Willis factor model (Deutsch and Willis, 1988).

22. 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. Formal comparison of alternative models. Both alternative models exclude only one of McCalls 11 factors, namely the testability factor. The Evans and Marciniak factor model consists of 12 factors that are classified into three categories.

The Deutsch and Willis factor model consists of 15 factors that are classified into four categories.

24. 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).

25. Who is interested in the definition of quality requirements? Client Software developer Examples: o Reusability requirements o Verifiability requirements

26. Factors which raise very little interest on the part of the client. Portability Reusability Verifiability

27. Two requirements documents expected for project. o The clients requirements document o The developers additional requirements document.

28. Compare factors and sub-factors of software quality.

Factor model

Software quality Factors

Sub-factors

McCalls 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. Six classes of SQA system components. Pre-project components. Components of project life cycle activities assessment. Components of infrastructure error prevention and improvement. Components of software quality management. Components of standardization, certification, and SQA system assessment. Organizing for SQA the human components

30. Two pre-project components. Contract review Development and quality plans.

31. Two stages of project life cycle. The project life cycle is composed of two stages: The development life cycle stage and The operationmaintenance stage.

32. Contract review activities 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.

33. Main issues treated in the project development plan

o Schedules o Required manpower and hardware resources o Risk evaluations o Organizational issues: team members, subcontractors and partnerships Project methodology, development tools, etc. o Software reuse plans.

34. Main issues treated in the projects quality plan 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.

35. Main components in software development project life cycle. The main components are: Reviews Expert opinions Software testing Software maintenance Assurance of the quality of the subcontractors work and the customer supplied parts.

36. Various categories of software maintenance services. These services fall into the following categories: Corrective maintenance code and documentation failures. Adaptive maintenance Functionality improvement maintenance

37. Pre-maintenance components Maintenance contract review Maintenance plan.

38. Software development life cycle components These components are applied for functionality improvement and adaptive maintenance tasks, activities whose characteristics are similar to those of the software development process.

39. Infrastructure SQA components Maintenance procedures and instructions Supporting quality devices Maintenance staff training, retraining, and certification Maintenance preventive and corrective actions Configuration management Control of maintenance documentation and quality records.

40. Class of SQA components in infrastructure components. Procedures and work instructions Templates and checklists Staff training, retraining, and certification Preventive and corrective actions Configuration management Documentation control.

41. Documentation control activities Definition of the types of controlled documents needed

Specification of the formats, document identification methods, etc. Definition of review and approval processes for each controlled document Definition of the archive storage methods.

42. Managerial SQA components Project progress control (including maintenance contract control) Software quality metrics Software quality costs.

43. Software quality metrics Quality of software development and maintenance activities Development teams productivity Help desk and maintenance teams productivity Software faults density Schedule deviations.

44. Main objectives of the SQA 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

45. Managements 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

o Assignment of adequate staff o Follow-up of compliance of quality assurance procedures o Solutions of schedule, budget and customer relations difficulties

46. List the SQA task break down into a number of primary roles. 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, and development of new components

47. 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.

48. The main issues dealt in SQA committees o Solution of software quality problems. o Analysis of problem and failure records as well as other records, followed by initiation of corrective and preventive actions when appropriate. o Initiation and development of new procedures and instructions; updating existing materials. o Initiation and development of new SQA components and improvement of existing components.

49. Two main categories of the decisions regarding organizations SQM Decisions regarding the organizations 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.

50. Various considerations of an organizations SQA system Organizational considerations Project and maintenance service considerations Professional staff considerations