This document discusses quality management in software engineering. It covers topics like quality assurance, standards, design, control, and software measurements. The key points are: 1) Quality assurance aims to create standards that lead to high quality software. It involves planning quality standards and processes, and controlling development to ensure standards are followed. 2) Standards include both product standards (documents, code) and process standards (specification, design, validation). They are based on past mistakes and ensure continuity. 3) Quality design defines quality attributes and goals for a project. It considers attributes like security, reliability, and usability. 4) Quality control monitors the development process through reviews and automated testing to check if standards are

1. SEN2 - Qualitymanagement
Group 5
Authors Daniel Vermaasen
Max Zuchowski
Tutor P. van den Hombergh
Date March 31, 2010

2. Contents
Contents 1
1 Introduction 2
2 Process- and Product quality 3
3 Quality assurance/-standards 4
4 Quality Design 6
5 Quality Control 7
5.1 Quality Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 Software Measurements 8
6.1 The Measurementprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 Productmetrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3 Analysis of the Measurments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1

3. Chapter 1
Introduction
Quality of software has improved over the last decades. Reasons for this are new technologies in
object oriented software or better CASE-aid. In general quality means that a product accords to its
specification.
In Software engineering there are attributes that cannot be determined exactly, i.e. maintenance,
security or efficiency.
Quality should be a culture where every team member is obligated to achieve as much quality as
possible. This leads to a chain where every other team member feels to improve his own quality. It is
recommended to manage quality documents to overview the milestones of each project member and to
keep the team communication during lifetime of the project.
In general quality management consists of three parts:
1. Quality assurance: Creation of a framework that leads to standards that on the other hand leads
to high class software.
2. Quality planning: Choosing right standards and methods for a specific software project.
3. Quality control: Definition and rules to make sure that a developer team realizes chosen quality
standards
There should be a separate quality assurance team in a company that communicates with top man-
agers and ensures that project leader do not make any quality compromises when they get in trouble
with time or project budget.
2

4. Chapter 2
Process- and Product quality
It is important to know that the quality of process influences directly the quality of supplied product.
This leads to the fact that if we can standardize the good parts of a production process, we can use these
parts to produce high class products.
It is difficult to generalize this for software engineering processes, because software consists of an
abstract design process. In software engineering there are quality attributes like maintainability or
product prototypes which are difficult to measure. Although it is also difficult to measure how process
modifications influence product quality, experiences have shown that managing development processes
improves software quality.
Process quality management consists of three parts:
1. Standardize process standards (e.g. review dates)
2. Monitor development process to keep sure that standards are used
3. Report development process to management
3

5. Chapter 3
Quality assurance/-standards
Quality assurance processes are responsible for the definition and the selection of standards for a
development process.
There are two types of standards within the quality assurance process:
1. Product standards. I.e. definition of document standards (document structure, documentation
standards), definition of programming standards (how to use a specific programming language)
2. Process standards. I.e. definition of processes that should be kept during software development
process like specification processes, design processes and validation processes.
Software standards are important because:
1. They are based on the knowledge of often-happened mistakes that were made during prior projects.
2. Quality assurance teams profit from them because they can check whether right standards have
been chosen.
3. They lead to continuity because work from one person can be taken-over uncomplicated by another
team member. This leads to lower learn costs.
There are national and international quality standards (i.e. ISO 9000, ISO 9001) which should be a
base for standards of your own company (i.e. programming language conventions, symbol definitions in
diagrams, standards in requirement documents, etc.). A company can gain an ISO-9000 certificate that
shows that its quality follows international standards.
Companies should formulate a manual for their developers with all standards and requirements due
to the product quality. In order to avoid project specific problems quality managers have to follow these
things:
1. Incorporate with software developers while creating standards to make sure they feel more respon-
sibility to use them.
2. Check and revise regularly all standards to make sure they are up-to-date to companies used
technologies.
3. Provide tools to make it easier for the developers to keep the standards.
Standards for documentations are very important due to the fact that documentations are the only
way to show the software and its process to a customer. These standards should cover all types of
documentations in a company.
There are three types of documentation standards:
1. Standards for documentation process
2. Standards for documents
3. Standards for exchange of documents
4

6. Examples for document standards are:
• Description of documents. There may be many documents in a software project. Project manager
should name all documents well chosen.
• Structure of documents. I.e. rules for page numbers, headers, footers, etc.
• Appearance of documents. I.e. applying company specific styles for documents like fonts, logos,
etc.
5

7. Chapter 4
Quality Design
Quality design describes the definition of a quality plan for a project. A quality plan defines all
quality attributes of a product and how they should be valued. Summarizing it should indicate whether
a developed product is high-class or whether its not.
A quality plan may consist of following parts:
1. Product description and quality expectations due to it.
2. Product plans which include its responsible people and all services around the product.
3. Process descriptions.
4. Quality goals and plans inclusive reasons for all quality attribute.
5. Risks and risk management.
There are several quality attributes which should be considered by development teams. I.e. secu-
rity, reliability, elasticity, stability, comprehensibility, testability, adaptability, modularity, complexity,
portability, usability, reusability, efficiency and learn ability.
6

8. Chapter 5
Quality Control
The main part of qualitycontrol is the monitoring of the process of the software development. This
brings you in a position where you can ensure that Methods and Standard for high quality are followed.
During the process of development, the produced software is controlled to fit to the former defined project
standarts. To check the quality of the product, two possibiltys complement to each other.
1. Quality-Review The software, the documentation and the used processes during the productiontime
is checked by a small group. All things which are not done as agreed in the productstandards are
forwarded to the projectleader.
2. Automated Software Evaluation The Software gets evaluated by another program. It searches for
cases in which the produced software or documentation is equal to the projectspecification.
5.1 Quality Review
As described, a small Team will work through the software and documents created during the software
development process. There are existing different kinds of reviews, three of them are explained in the
following table.
Kind of Review Main Purpose
Design- or Programinspection Finding detailerror in the application,
in the design or inside the code, preferable with an checklist.
Progress-Review Should give an overview of the overall progress of the development-process.
Also includes the timetables, costs and other presets.
Quality-Review Gives an technical analysis of the products components.
Variations are written down formal and handed in to the project-leader.
A review should be announced as early as possible and all documents which will be reviewed, should
be puplished to the involved people as soon as possible. The review itself should not exceed two hours
and all authors of the reviewed documents should be present. The review should be moderated and also
recorded to publish the results to the involved people.
7

9. Chapter 6
Software Measurements
Softwaremeasuring and -metrics
The problem with reviews is, that they delay the completion of the softwaresystem. To minimize the
delay based of reviews, the use of automated tools is recommend. Those tools can focus on the existing
problems which are discussed in the review itself.
Measuring software is done to derive the feartures of a product into numbers. This opens the possi-
bility of comparing former non-comparable products or processes to each other. Those numbers can also
be use to draw conclusions for other software-projects and particularly for following projects.
Two different use-methods for measuring software are common:
To formulate common predictions for a system
The measured features are brought into a summary, this gives an prediction for the expected system-
failures.
To find abnormal components
the components are measured for their own. The results point to the componentes with high com-
plexity or to faulty components.
But not all features of software can be measured directly. There are external attributes link main-
tainability, usability and comprehensibility depend on who the user and developer see the software. To
include those factors, it is possible to relate them to internal softwarefeatures. The more relations can be
found between internal and external features, the more important they are. For example the maintain-
ability is related to the number of functionparameters, the programmsize and the length of the manual.
This means, the total of all internal factors can estimate the external factors and allows conclusions of
their importance.
6.1 The Measurementprocess
During the measurementprocess the individual components should be measured, the results should
be compared to other the other data of the project but also (if possible) with data from the history.
Unsual data must be analysed to find out, if the data is just complex and this unsual data is correct or
if it needs to be focused and improved in the ongoing process.
8

10. 6.2 Productmetrics
Productmetrics decribes the properties of the software itself. Due to the fact, that it is not possible
to make conclusions from the size or the complexity to qualityfactors like maintainability, we try to
abstract the the qualityproperties from this large set of easy acquirable data. Productmetrics must be
devided into two groups:
Dynamic Metrics Measurements which collect data during the runtime of a program.
It eastimates the efficency and the reliability of the Program
Static Metrics Data gained through the design, the program or documentation.
It estimates the complexity, readability and maintainability.
6.3 Analysis of the Measurments
While analysing the measured data, it is hard to interpret the measured data right. It is often the
case that those data is interpreted in the wrong way. It is extremly important to try to draw conclusions
in all possible directions. It is also very important to see the circumstances under which the program is
in use oder will be in use, this will affect the measured data and the results you are going to choose from
your analysis. Be aware of taking to early conclusions.
9