Overview of SQA Components

1
CHAPTER 2

• Overview of SQA Components

2
Learning Objectives

• To discuss
• SQA systems
• Pre-project components
• Project life-cycle components
• Infrastructure components
• Management components
• Standards, certification and assessment
• Organizing for SQA human components

3
SQA Systems

• SQA system always combines a wide range of SQA
  components.
• All components are employed to challenge the
  multitude of sources of software errors and to
  achieve an acceptable level of software quality.

4
SQA Systems

• SQA system components can be classified into 6
  classses
• Pre-project components
• Project life-cycle components
• Infrastructure components
• Management components
• Standards, certification and assessment
• Organizing for SQA human components

5
Pre-project Components

• Objective to ensure that (a) a project
  commitments have been adequately defined
  considering the resources required, the schedule
  and budget and (b) the development and quality
  plan have been correctly determined.
• Contract review
• Development and quality plan

6
Contract review

• Software may be developed within the framework of
  a contract negotiated with a customer.
• Contract review activities must include a
  detailed examination of (a) the project proposal
  draft and (b) the contract drafts.

7
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

8
Development and quality plans

• Once the software development contract has been
  signed, a plan is prepared of the project
  (development plan) and its integrated quality
  assurance activities (quality plan).
• These plans include additional details and needed
  revisions based on prior plans that provided the
  basis for the current proposal and contract.

9
Development and quality plans

• It is common for several months to pass between
  the tender submission and the signing of the
  contract.
• During this period, changes may occur in staff
  availability, in professional capabilities, and
  so forth.
• The plans are then revised to reflect the changes
  that occurred in the interim.

10
Development and quality plans

• The main issues treated in the project
  development plan are
• Schedule
• Required manpower and hardware resources
• Risk evaluations
• Organizational issues team members,
  subcontractors and partnerships
• Project methodology, development tools, etc.
• Software reuse plans.

11
Development and quality plans

• The main issues treated in the projects quality
  plan are
• Quality goal, expressed in the appropriate
  measureable terms
• Criteria for starting and ending each project
  stage
• Lists of reviews, tests, and other scheduled
  verification and validation activities.

12
Software Project Life Cycle Components

• The project life cycle is composed of 2 stages
  the development life cycle stage and the
  operation-maintenance stage.
• The main components
• Reviews
• Expert opinions
• Software testing
• Software maintenance
• Assurance of the quality of the subcontractors
  work and the customer-supplied parts.

13
Reviews

• The design phase of the development process
  produces a variety of documents, software
  installation plans and software manuals.
• Reviews can be categorized as formal reviews
  (DRs) and peer reviews.

14
Formal Design Reviews (DRs)

• A significant portion of these documents requires
  formal professional approval of their quality as
  mentioned in the development contract and
  demanded by the procedures applied by the
  software developer.
• The developer can continue to the next phase of
  the development process only on receipt of formal
  approval of these documents.

15
Formal Design Reviews (DRs)

• Ad hoc committees whose members examine the
  documents presented by the development teams
  usually carry out formal design reviews (widely
  known as DRs).
• The committees senior professionals, project
  leader, department manager, chief software
  engineer, head of other related departments.
• On many occasions, the customers representative
  will participate in a DR.

16
Formal Design Reviews (DRs)

• DR report includes a list of required corrections
  (termed action items).
• Discuss on
• 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.

17
Formal Design Reviews (DRs)

• An additional DR is required and scheduled to
  take place after all the action items have been
  completed and inspected by the committees
  representative.

18
Peer reviews

• Peer reviews (inspections and walkthroughs) are
  directed at reviewing short documents, chapters
  or parts of a report, a coded printout of a
  software module, etc.
• The reviewers all peers (not superiors).
• Objective to detect as many design and
  programming faults as possible.
• Output list of detected faults, defect summary
  and statistics to be used as a database for
  reviewing and improving development methods.

19
Expert opinion

• 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

20
Expert opinion

• Insufficient in-house professional capabilities
  in a given area.
• In small organization 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.

21
Expert opinion

• Temporary inaccessibility of an 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.

22
Software testing

• Software tests are formal SQA components 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 system.

23
Software testing

• Objectives of software testing
• Detection of software faults
• Formal approval of a module or integration setup
  so that either the next programming phase can be
  begun or the completed software system can be
  delivered and installed.

24
Software maintenance components

• Software maintenance services vary in range and
  are provided for extensive periods, often several
  years.
• Software maintenance categories?

• Perfective

• Corrective

• Adaptive

• Preventive

25
Assurance of the quality of the external
participants work

• The motivation for turning to external
  participants lies in any number of factors
• Economic, technical, personnel-related interests.
• Reflects a growing trend in the allocation of the
  work involved with completing complex projects.
• Control applied to external participants are
  defined in contract signed between the relevant
  parties.
• SQA are needed to assure the quality of the
  hardware, software, staff and training supplied
  by the external participants.

26
Infrastructure Component

• The goals prevention of software faults or at
  least, the lowering of software fault rates,
  together with the improvement of productivity.
• SQA components are devised to serve a wide range
  of projects and software maintenance services.

27
Infrastructure Component

• SQA infrastructure components includes
• Procedure and work instruction
• Templates and checklists
• Staff training, retraining, and certification
• Preventive and corrective actions
• Configuration management
• Documentation control.

28
Procedures and work instructions

• QA procedures provide detailed definitions for
  the performance of 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.

29
Procedures and work instructions

• Work instructions provide detailed directions
  for the use of methods that are applied in unique
  instances and employed by specialized teams.

30
Procedures and work instructions

• Procedures and work instructions are based on the
  organizations accumulated experience and
  knowledge such as, they contribute to the
  correct and effective performance of established
  technologies and routines.
• Because they reflect the organizations past
  experience, constant care should be taken to
  update and adjust those procedures and work
  instructions to current technological,
  organizational, and other conditions.

31
Supporting quality devices

• Such as templates and checklists.
• Objectives of using these devices
• Saving the time required to define the structure
  of the various documents or prepare lists of
  subjects to be reviewed.
• Contributing to completeness of the documents and
  reviews.
• Improving communication between development team
  and review committee members by standardizing
  documents and agendas.

32
Staff training, instruction and certification

• In SQA, keeping the organizations human
  resources knowledgeable and updated is achieved
  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.

33
Preventive and corrective actions

• Systematic study of the data collected regarding
  instances of failure and success contributes to
  quality assurance process in many ways
• 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 success.

34
Configuration management

• Configuration management deals with the effect of
  modifying the existing system.
• Effects?
• Configuration management introduce procedures to
  control those effects/changes.
• Procedures approval of changes, recording of
  changes, issuing new software versions/release,
  etc.
• Most using computerized tools.

35
Documentation control

• SQA requires the application of measures to
  ensure the efficient long-term availability of
  major documents related to software development
  (controlled documents).
• Purpose of controlled document to provide
  evidence of the SQA systems performance.
• Example test results, design review (DR)
  reports, problem reports, and audit reports.

36
Documentation control

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

37
Management SQA Components

• Managerial SQA components support the managerial
  control of software development projects and
  maintenance services.
• Control components include
• Project progress control
• Software quality metrics
• Software quality costs

38
Project progress control

• Main objective to detect the appearance of any
  situation that may induce deviations from the
  projects plans and maintenance service
  performance.
• Project control activities focus on
• Resource usage
• Schedule
• Risk management activities
• The budget

39
Software quality metrics

• Measurement of the software quality applies to
  the functional quality, productivity, and
  organizational aspects of the project.
• Software quality metrics
• Quality of software development and maintenance
  activities
• Development teams productivity
• Help desk and maintenance teams productivity
• Software faults density
• Schedule deviations.

40
Software quality costs

• The costs of control prevention, appraisal and
  managerial preparation and control costs.
• Costs of failure internal/external failure
  costs, and managerial failure costs.
• Management interested in total sum of the
  quality costs.
• Why?? direct SQA efforts to the improvement of
  activities that cause significant failures.

41
SQA Standards, System Certification and
Assessment Components

• Main objectives
• Utilization of international professional
  knowledge.
• Improvement of coordination with other
  organizations quality systems.
• Objective professional evaluation and measurement
  of the achievements of the organizations quality
  systems.

42
SQA Standards, System Certification and
Assessment Components

• Can be classified into 2 main sub-classes
• Quality management standards
• Project process standards.

43
Quality management standards

• Guide the management of software development,
  maintenance, and infrastructure.
• Focus on what is required and leave the decision
  of how to achieve it.
• SEI CMM assessment standard
• ISO 9001 and ISO 9000-3 standards.

44
Project process standards

• Professional standards that provide
  methodological guidelines (how) for the
  development team.
• Well-known examples
• IEEE 1012 standard
• ISO/IEC 12207 standard.

45
Organizing for SQA the Human Components

• SQA organizational base management team,
  software testing personnel and SQA units in
  addition to professionals and other practitioners
  interested in software quality (SQA trustees, SQA
  committee members and SQA forum members).

46
Organizing for SQA the Human Components

• The objectives of SQA organizational base
• To develop and support implementation of SQA
  components.
• To detect deviations from SQA procedures and
  methodology.
• To suggest improvements to SQA components.

47
Organizing for SQA the Human Components

• Although the entire SQA organizational bas shares
  these objectives, each segment of the
  organizational base concentrates on specific
  tasks.

48
Managements role in SQA

• The responsibilities of top management,
  departmental management and project management
• Definition of the quality policy
• Effective follow-up of quality policy
  implementation
• Allocation of sufficient resources to implement
  quality policy
• Assignment of adequate staff
• Follow-up of compliance of quality assurance
  procedures
• Solutions of schedule, budget and customer
  relations difficulties.

49
The SQA unit

• The responsibilities of SQA unit. including the
  software testers
• 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.

50
SQA trustees, committee 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. Their
  contributions include
• 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.

51
SQA trustees, committee and forums

• SQA committee members are members of various
  software development and maintenance units, and
  are usually appointed for term or ad-hoc service.
• The main issues dealt by the committee are
• Solution of software quality problems.
• Analysis of problem and failure records as well
  as other records, followed by initiation of
  corrective and preventive actions when
  appropriate.

52
SQA trustees, committee and forums

• Initiation and development of new procedures and
  instructions updating existing materials.
• Initiation and development of new SQA components
  and improvement of existing components.

53
SQA trustees, committee and forums

• 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.
• They share their experiences and difficulties as
  well as try to initiate improvements in the
  software process.

54
Considerations guiding construction of an
organizations SQA system

• Decisions regarding the organizations software
  quality management system fall into 2 main
  categories
• The SQA organizational base
• The SQA components to be implemented within the
  organization and the extent of their use.

55
The main consideration affecting the use of the
SQA components

• Organizational considerations
• Project and maintenance service considerations
• Professional staff considerations

56
Organizational considerations

• Type of software development clientele
• Type of software maintenance clientele
• Range of software products
• Size of organization
• Degree and nature of cooperation with other
  organizations carrying out related projects
• Optimization objectives software quality, team
  productivity, process efficiency, financial
  savings.

57
Project and maintenance service considerations

• Level of complexity and difficulty
• Degrees of staff experience with the project
  technology
• Extent of software reuse in the new projects

58
Professional staff considerations

• Professional qualifications
• Level of acquaintance with team members.