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
In Software engineering there are attributes that cannot be determined exactly, i.e. maintenance,
security or eﬃciency.
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 speciﬁc software project.
3. Quality control: Deﬁnition and rules to make sure that a developer team realizes chosen quality
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.
Process- and Product quality
It is important to know that the quality of process inﬂuences 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 diﬃcult 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 diﬃcult to measure. Although it is also diﬃcult to measure how process
modiﬁcations inﬂuence 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
Quality assurance processes are responsible for the deﬁnition and the selection of standards for a
There are two types of standards within the quality assurance process:
1. Product standards. I.e. deﬁnition of document standards (document structure, documentation
standards), deﬁnition of programming standards (how to use a speciﬁc programming language)
2. Process standards. I.e. deﬁnition of processes that should be kept during software development
process like speciﬁcation 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 proﬁt from them because they can check whether right standards have
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 deﬁnitions in
diagrams, standards in requirement documents, etc.). A company can gain an ISO-9000 certiﬁcate 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 speciﬁc problems quality managers have to follow these
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
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
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 speciﬁc styles for documents like fonts, logos,
Quality design describes the deﬁnition of a quality plan for a project. A quality plan deﬁnes 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, eﬃciency and learn ability.
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 ﬁt to the former deﬁned 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 projectspeciﬁcation.
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 diﬀerent kinds of reviews, three of them are explained in the
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.
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 diﬀerent 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-
To ﬁnd 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
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 ﬁnd 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.
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 eﬃcency 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 aﬀect the measured data and the results you are going to choose from
your analysis. Be aware of taking to early conclusions.