• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Quality Management handout
 

Quality Management handout

on

  • 1,784 views

 

Statistics

Views

Total Views
1,784
Views on SlideShare
1,784
Embed Views
0

Actions

Likes
0
Downloads
36
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Quality Management handout Quality Management handout Document Transcript

    • SEN2 - Qualitymanagement Group 5 Authors Daniel Vermaasen Max Zuchowski Tutor P. van den Hombergh Date March 31, 2010
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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