SOFTWARE ENGINEERING SOFTWARE QUALITY - SOFTWARE QUALITY QUALITY - - PDF document

▶
software engineering software quality software quality
SMART_READER_LITE
LIVE PREVIEW

SOFTWARE ENGINEERING SOFTWARE QUALITY - SOFTWARE QUALITY QUALITY - - PDF document

Jul 19, 2023 378 likes •439 views

SOFTWARE ENGINEERING SOFTWARE QUALITY - SOFTWARE QUALITY QUALITY COMPONENTS Today we talk about software process quality and certification Objective quality component: properties that can be Jyrki Nummenmaa University of Tampere, CS

slide-1
SLIDE 1

1

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE ENGINEERING SOFTWARE QUALITY

  • Today we talk about software process quality and certification

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE QUALITY - QUALITY COMPONENTS

  • Objective quality component: properties that can be

measured or approximated objectively

  • Subjective quality component: customer satisfaction (”What

does the product feel like?”)

  • Other: features which can not be (even subjectively)

evaluated at the time. This is related with future events which can not be predicted - unexpected circumstances, changes, etc.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

THE QUALITY SYSTEM

  • Quality control - controlling the way things are done
  • Quality assurance - making sure quality is achieved
  • Quality policy
  • Quality planning
  • Quality improvement
  • These terms come from the standard ISO 8402

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

THE QUALITY SYSTEM (cont’d)

  • The quality system of a company is simply the way the

company works and it covers all areas of activity.

  • Therefore, a quality system always exists. It may be

documented or not.

  • However, in the long run in a big company it makes a major

difference, if the management takes quality seriously and knowingly emphasizes it in all activities.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY CONTROL

  • Controlling the software development process
  • Standards for the development process, e.g.
  • well-defined phases
  • checklists
  • reviews: what and when
  • organisational standards
  • Visibility and bookkeeping of the development process
  • Standards for software code and documentation, e.g.
  • naming and style
  • document skeletons and formats
  • different kinds of review and feedback forms

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY ASSURANCE

  • Improving software quality by monitoring the products

(software) and process

  • Ensuring full compliance with the standards for products and

process

  • Ensuring that any inadequacies in the product and process

(and standards) are brought to management’s attention.

slide-2
SLIDE 2

2

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY ASSURANCE - PREREQUISITES

  • Top management commitment
  • The quality assurance organisation must be independent from

the development organisation.

  • The quality assurance organisation must be properly staffed.
  • The quality assurance organisation must co-operate properly

with the development organisation. Quality must be seen as a common goal.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

PROCESS QUALITY METRICS

  • Actual vs. estimated time and cost
  • Number of faults detected
  • Phase of the project when faults were found
  • Productivity (e.g. lines of code / man-month)
  • Quality expenses (e.g. repairs required after delivery)

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY REVIEW TYPES

  • Design or program inspections/audits. These are commonly

driven by a checklist of possible errors.

  • Management reviews. These are intended to provide

information for the management about the overall progress of the software project.

  • Quality reviews. The work of an individual or a team is

reviewed by a panel made up of project members and technical management.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

A GENERAL SCHEME FOR REVIEWS

  • Select the review team.
  • Arrange the place and time.
  • Distributed the documents.
  • Hold the review.
  • Note the actions and complete the review forms.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

POSSIBLE ACTIONS FOR FINDINGS IN REVIEWS

  • No action. Some kind of an anomaly was found, but it was not

cost-effective to fix it.

  • Refer for repair. The team or individual in charge of the

product has to correct the fault.

  • Reconsider the overall design. It may be more reasonable to

fix other components of the system to solve the problem which was found.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

INSPECTIONS / AUDIT SESSIONS

  • The ”Fagan method” - named after an IBM employee who

pioneered the technique

  • All types of defects are noted - not just logic or function errors.
  • Inspections can be carried out by collagues at all levels

except the very top.

  • Inspections are carried out using a predefined set of steps.
  • Inspection meetings do not last for more than two hours.
  • The inspection is lead by a moderator who has a specific

trainging in the technique.

slide-3
SLIDE 3

3

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

INSPECTIONS / AUDIT SESSIONS (continued)

  • The other participants have defined roles. For example, one

person will act as a recorder and note all defects found and another will act as a reader who takes the other participants through the document under inspection.

  • Checklists are used to assist the fault-finding process.
  • Material should be inspected at an optimal rate of about 100

lines per hour.

  • Statistics are maintained so that the effectiveness of the

inspection process can be monitored.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

A CHECKLIST FOR REVIEW EVALUATIONS

  • Is material complete (and does it meet the standards)?
  • Was material distributed on time?
  • Are applicable standards referenced and available?
  • Were attendees prepared to contributed?
  • Did evaluation start on time?
  • Were number of defects identified?
  • Was review conducted per standard protocols?
  • Were entrance criteria met?
  • Were exit criteria met?

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

A CHECKLIST FOR REVIEW EVALUATIONS (cont’d)

  • Are all issues scheduled for resolution?
  • Are interface issues coordinated?
  • Is disposition of all defects complete?
  • Were HCI, testing, maintenance, and tools considered?
  • Were quality attributes reported?
  • Has trace of defects been initiated?

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE QUALITY CIRCLES

  • A Japanese practice.
  • A quality circle is a group of four to ten volunteers working in

the same area who meet for, say, an hour a week to identify, analyse and solve their work-related problems.

  • One of the group is a group leader and one (maybe from
  • utside) is a facilitator giving advice.
  • Training is required, and so is full support from the

management.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

PROBLEM SOLVING BY SOFTWARE QUALITY CIRCLES

  • Identify a list or problems and choose one.
  • Clarify the problem.
  • Identify and evaluate the causes.
  • Identify and evaluate the solutions.
  • Decide on the solution.
  • Develop an implementation plan.
  • Present the plan to the management.
  • Implement the plan.
  • Monitor the plan.
  • Consider wider apllicability of solution.
  • Restart from choosing another problem.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

ISO 9000

  • Series of standards for general use in different fields of

industry.

  • ISO 9001 is for companies with product development and

production.

  • Separate certification organisations give certification for

companies which fulfill the requirements of the standards.

slide-4
SLIDE 4

4

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

INGREDIENTS OF ISO 9001

  • Management responsibility
  • Quality system
  • Contract review
  • Design control
  • Document control
  • Purchasing
  • Purchaser supplied control
  • Product identification adn traceability
  • Process control
  • Inspection and testing

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

INGREDIENTS OF ISO 9001 (continued)

  • Inspection, measuring and test equipment
  • Inspection and test status
  • Control of nonconforming product
  • Corrective action
  • Handling, storage, packaging and delivery
  • Quality records
  • Internal quality audits
  • Training
  • Servicing
  • Statistical techniques

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

AN OVERVIEW OF ISO 9001 REQUIREMENTS

  • The management must define and document the policy

concerning quality and must ensure that this policy is communicated to all levels of the organisation.

  • All quality control procedures must be documented.
  • All contracts to supply goods or services should contain

mutually agreed requirements that the developer is capable of delivering.

  • There should be procedures to approve design and other

documentation.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

AN OVERVIEW OF ISO 9001 REQUIREMENTS (continued)

  • Where components of the system to be supplied to the client

are obtained from third parties there must be procedures to ensure, check, and maintain the quality of these components.

  • Individual products should be identifiable as should their

components.

  • The process by which the final product is created should be

planned and monitored.

  • Inspection and testing should take place during the

development phase, at its completion and before delivery. Tests and inspections should also be carried out on components obtained from third parties.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

AN OVERVIEW OF ISO 9001 REQUIREMENTS (continued)

  • The equipment used in the production process itself should

be properly controlled with respect to quality.

  • The testing status of all components and systems should be

clearly recorded all times.

  • Care must be taken to ensure that items which are known to

be defective are not inadvertently used.

  • When a defect is detected, measures must be undertaken to

remove the defective part and to ensure that the defect does not occur again.

  • Satisfactory procedures must be in place to deal with correct

handling, storage, packaging, and delivery of the product.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

AN OVERVIEW OF ISO 9001 REQUIREMENTS (continued)

  • Sufficient records must be maintaned to demonstrate that the

quality system is working satisfactorily.

  • The software quality management system should be audited
  • n a regular basis.
  • Servicing and supprt activiies must be subject to the quality

management system.

  • The developer must establish appropriate statistical

techniques to verify the acceptability of the final product.

slide-5
SLIDE 5

5

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

CERTIFICATION (for standards like ISO 9001)

  • The company familiarises itself with the standards.
  • The company applies for the certification.
  • The certification organization inspects the company (based on

documents which it requires from the company).

  • An evaluation meeting is held with representatives from both

the company and the certification organisation.

  • If necessary, some corrective actions are performed.
  • A certification is given to an accepted company.
  • Re-evaluations will be performed.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

GENERAL CONCLUSIONS

  • The development of a quality system requires changes and

changes create resistance.

  • Be realistic.
  • Quality depends a lot on attitudes.
  • Internal and management motivation is essential.
  • Small steps can be the best way forward.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

CMMI MATURITY LEVELS

  • 1. Initial
  • Unpredictable, poorly controlled, reactive (reacts to problems)
  • 2. Managed
  • Characterized for projects, often reactive
  • 3. Defined
  • Defined for the organization, proactive
  • 4. Quantitatively managed (measuring)
  • Measured and controlled
  • 5. Optimizing
  • Continous improvement

CMMI = Capability Maturity Model Integration

  • 0. Incomplete
  • Jobs are not completed.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Maturity Level Development

  • A theory says that one should not skip the levels when

improving the maturity.

  • The idea behind this is that the organisations are generally

not ready to move up two levels in one step.

  • Thereby, higher level processes may not succeed because

there is not enough experience to support them.

  • Notice that not all processes are necessarily on the same

level.

  • Notice further, that the CMMI levels apply to other processes

also, not only software development.