7/28/2019 Galin Sqa 2 Marks Chapter 1-4

1/14

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

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

2/14

5. Factors affecting defect detection in software products vs. other industrial

products.

Characteristic Software products Other industrial products

Complexity Complexity Usually,very complex product

allowing for very large

number of operational

options.

Degree of complexitymuch r lowers, allowing

at most a few thousand

operational options.

Visibility of product Invisible product,

impossible to detect

defects or omissions by

sight (e.g. of a diskette or

CD storing the software)

Visible product, allowing

effective detection of

defects by sight

Nature of development

and production process

Opportunities to detect

defects arise in only one

phase, namely product

development

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/28/2019 Galin Sqa 2 Marks Chapter 1-4

3/14

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

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

4/14

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. 3requirements 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.

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

5/14

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 thecauses 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 fullsatisfaction 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.

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

6/14

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.

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

7/14

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.

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

8/14

Factor model Software quality Sub-factors

Factors

McCalls model: Correctness Accuracy

Product operation Completeness

category 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

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

9/14

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

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

10/14

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

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

11/14

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

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

12/14

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

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

13/14

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.

7/28/2019 Galin Sqa 2 Marks Chapter 1-4

14/14

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