Because it is cheaper and quicker to do it right first time
Because quality make our customers happy
Process based Quality Product based Quality Need based kvalitet Value based Quality Four types of quality
Wish Wish Wish Need Need Need Interpretation Requirement specification Commu nication Development process Product time 1 time 2 New requirement Core
Wish Wish Wish Need Need Need Interpretation Requirement specification Commu- nication Development process Product time 1 time 2 New need Core Process based quality Product based quality Need based quality
This is based on the notion that, in many situations, 80% of incidents are accounted for by 20% of the causes. It gets its name from an Italian statistician who studied the phenomenon in detail.
Also known as ‘The 80:20 Rule’, it is not always exactly split 80 to 20, but the general principle is remarkably common. What it does is encourage the circle members to find out which of the causes have the greatest effect.
For example, you could find in your organisation that:
80% of the turnover comes from 20% of the products
80% of the complaints come from 20% of the customers
80% of the absenteeism is accounted for by 20% of the workforce
80% of the errors are produced on 20% of the machines
As you probably found, it is not a clean 80:20 split in each case, but there is frequently a relationship between the majority of the problems and a small minority of the causes.
Defects which gives some wrong results or dangerous. Hang-ups or break downs, no known work around.
Defect which leads to ambiguous results or wrong behavior. Several requirements not fulfilled but required a reprogramming. Something in a program behaving wrongly but where there is a (”work around”) to omit the error.
Defects only concerning a single requirements or a small part of the system. The defect can be ignored and do not have much consequences
Defects which makes it difficult to understand small thing or cosmetics
Quality scenarios are short statements <stimulus> <measurable response>
When the completed sale is sent to the remote tax calculator to add the taxes, the result is returned within 2 seconds “most” of the time, measured in a production environment under “average” load conditions.
“ most” and “average” need further investigation and definition. A quality scenario is not really valid untill it is testable, which implies fully specified.
Will anyone really test them? How and by whom?
Sample factor table Factor Measures and Quality scenarios Variability (current flexibility and future evaluation) Impact of factor (and its variability) on stakeholders, architecture and other factors Priority for success Difficulty or Risk Larman 547
Write those quality scenarios and follow through with a plan for their evaluation.
Service Level Agreement (SLA) / Service Level Management (SLM)
A Service Level Agreement (SLA) is a formal written agreement made between two parties: the service provider and the service recipient. The SLA itself defines the basis of understanding between the two parties for delivery of the service itself. The document can be quite complex, and sometimes underpins a formal contract . The contents will vary according to the nature of the service itself, but usually includes a number of core elements, or clauses.
Generally, an SLA should contain clauses that define a specified level of service, support options, incentive awards for service levels exceeded and/or penalty provisions for services not provided. Before having such agreements with customers the IT services need to have a good quality of these services, Quality management will try to improve the Quality of Service, whereas the SLAs will try to keep the quality and guarantee the quality to the customer.
SLA Management is the key for making sure you get what you paid for .
SLO (service level objectives) and KPI (key performance indicators).
SLO is then valued against the agreed-upon service levels, and the result is reported to the service provider and/or consumer.
Information Technology Infrastructure Library (ITIL)
is a set of best practices used to deliver high quality IT services. The best practices described in ITIL represent the consensus derived from over a decade of work by thousands of IT and data processing professionals’ world-wide, including hundreds of years of collective experience. Because of its depth and breadth, the ITIL has become the defacto world standard for IT best practices.
Example: Review of requirement specification – Sources of errors
Misunderstandings in the communication
Requirement and measurements are not quantified
Missing formal information or documentation
Lack in understanding of where are we going
Misunderstanding of existing data
Missing understanding of relationships in data
Misunderstanding of examples and diagrams
Example - Review of requirement specification - documentation
Review meeting lasting more than 2 hours are less effective
If more than 20 pages are to be reviewed then it is better to split the meeting.
Kilde: Michael Fagan: ”Design og Code Inspections to reduce Errors in program development” IBM Systems Jn., vol. 15, nr. 3, 1976, side 182-211
Review of requirements with customer the 7th October in room 3A18 if review material received before the 4th October Two presentations: one for us as customers and one for us a part of the organization n/a 15:30 – 16:15 Carsten & Eva The Favorites n/a 14:30 – 15:15 Carsten & Eva The LuckyOnes + The Tiny Group Recieved 13:30 – 14:15 Carsten & Eva The Outsiders N/A 12:30 – 13:15 Carsten & Eva The DieHards
See you again the 28th. October Object oriented design and more patterns chapter 22 - 26 Eva Trosborg