unit-5-1.ppt

unit-5-1.ppt

• 1.
  Quality Management
• 2.
  Quality Management  Managingthe quality of the software process and products
• 3.
  Objectives  To introducethe quality management process and key quality management activities  To explain the role of standards in quality management  To explain the concept of a software metric, predictor metrics and control metrics  To explain how measurement may be used in assessing software quality
• 4.
  Topics covered  Qualityassurance and standards  Quality planning  Quality control  Software measurement and metrics
• 5.
  Software quality management Concerned with ensuring that the required level of quality is achieved in a software product  Involves defining appropriate quality standards and procedures and ensuring that these are followed  Should aim to develop a ‘quality culture’ where quality is seen as everyone’s responsibility
• 6.
  What is quality? Quality, simplistically, means that a product should meet its specification  This is problematical for software systems • Tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.) • Some quality requirements are difficult to specify in an unambiguous way • Software specifications are usually incomplete and often inconsistent
• 7.
  The quality compromise We cannot wait for specifications to improve before paying attention to quality management  Must put procedures into place to improve quality in spite of imperfect specification  Quality management is therefore not just concerned with reducing defects but also with other product qualities
• 8.
  Quality management activities Quality assurance • Establish organisational procedures and standards for quality  Quality planning • Select applicable procedures and standards for a particular project and modify these as required  Quality control • Ensure that procedures and standards are followed by the software development team  Quality management should be separate from project management to ensure independence
• 9.
  Quality management andsoftware development
• 10.
  ISO 9000  Internationalset ofstandards for quality management  Applicable to a range of organisations from manufacturing to service industries  ISO 9001 applicable to organisations which design, develop and maintain products  ISO 9001 is a generic model of the quality process Must be instantiated for each organisation
• 11.
  ISO 9001
• 12.
  ISO 9000 certification Quality standards and procedures should be documented in an organisational quality manual  External body may certify that an organisation’s quality manual conforms to ISO 9000 standards  Customers are, increasingly, demanding that suppliers are ISO 9000 certified
• 13.
  ISO 9000 andquality management
• 14.
   Standards arethe key to effective quality management  They may be international, national, organizational or project standards  Product standards define characteristics that all components should exhibit e.g. a common programming style  Process standards define how the software process should be enacted Quality assurance and standards
• 15.
   Encapsulation ofbest practice- avoids repetition of past mistakes  Framework for quality assurance process - it involves checking standard compliance  Provide continuity - new staff can understand the organisation by understand the standards applied Importance of standards
• 16.
  Product and processstandards
• 17.
  Problems with standards Not seen as relevant and up-to-date by software engineers  Involve too much bureaucratic form filling  Unsupported by software tools so tedious manual work is involved to maintain standards
• 18.
   Involve practitionersin development. Engineers should understand the rationale underlying a standard  Review standards and their usage regularly. Standards can quickly become outdated and this reduces their credibility amongst practitioners  Detailed standards should have associated tool support. Excessive clerical work is the most significant complaint against standards Standards development
• 19.
  Documentation standards  Particularlyimportant - documents are the tangible manifestation of the software  Documentation process standards • How documents should be developed, validated and maintained  Document standards • Concerned with document contents, structure, and appearance  Document interchange standards • How documents are stored and interchanged between different documentation systems
• 20.
  Documentation process
• 21.
  Document standards  Documentidentification standards • How documents are uniquely identified  Document structure standards • Standard structure for project documents  Document presentation standards • Define fonts and styles, use of logos, etc.  Document update standards • Define how changes from previous versions are reflected in a document
• 22.
  Document interchange standards Documents are produced using different systems and on different computers  Interchange standards allow electronic documents to be exchanged, mailed, etc.  Need for archiving. The lifetime of word processing systems may be much less than the lifetime of the software being documented  XML is an emerging standard for document interchange which will be widely supported in future
• 23.
   The qualityof a developed product is influenced by the quality of the production process  Particularly important in software development as some product quality attributes are hard to assess  However, there is a very complex and poorly understood between software processes and product quality Process and product quality
• 24.
  Process-based quality  Straightforwardlink between process and product in manufactured goods  More complex for software because: • The application of individual skills and experience is particularly imporant in software development • External factors such as the novelty of an application or the need for an accelerated development schedule may impair product quality  Care must be taken not to impose inappropriate process standards
• 25.
  Process-based quality
• 26.
   Define processstandards such as how reviews should be conducted, configuration management, etc.  Monitor the development process to ensure that standards are being followed  Report on the process to project management and software procurer Practical process quality
• 27.
  Quality planning  Aquality plan sets out the desired product qualities and how these are assessed ande define the most significant quality attributes  It should define the quality assessment process  It should set out which organisational standards should be applied and, if necessary, define new standards
• 28.
  Quality plan structure Product introduction  Product plans  Process descriptions  Quality goals  Risks and risk management  Quality plans should be short, succinct documents • If they are too long, no-one will read them
• 29.
  Software quality attributes
• 30.
  Quality control  Checkingthe software development process to ensure that procedures and standards are being followed  Two approaches to quality control • Quality reviews • Automated software assessment and software measurement
• 31.
  Quality reviews  Theprincipal method of validating the quality of a process or of a product  Group examined part or all of a process or system and its documentation to find potential problems  There are different types of review with different objectives • Inspections for defect removal (product) • Reviews for progress assessment(product and process) • Quality reviews (product and standards)
• 32.
  Types of review
• 33.
   A groupof people carefully examine part or all of a software system and its associated documentation.  Code, designs, specifications, test plans, standards, etc. can all be reviewed.  Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management. Quality reviews
• 34.
  The review process
• 35.
  Review functions  Qualityfunction - they are part of the general quality management process  Project management function - they provide information for project managers  Training and communication function - product knowledge is passed between development team members
• 36.
  Quality reviews  Objectiveis the discovery of system defects and inconsistencies  Any documents produced in the process may be reviewed  Review teams should be relatively small and reviews should be fairly short  Review should be recorded and records maintained
• 37.
   Comments madeduring the review should be classified. • No action. No change to the software or documentation is required. • Refer for repair. Designer or programmer should correct an identified fault. • Reconsider overall design. The problem identified in the review impacts other parts of the design. Some overall judgement must be made about the most cost-effective way of solving the problem.  Requirements and specification errors may have to be referred to the client. Review results
• 38.
  Software measurement andmetrics  Software measurement is concerned with deriving a numeric value for an attribute of a software product or process  This allows for objective comparisons between techniques and processes  Although some companies have introduced measurment programmes, the systematic use of measurement is still uncommon  There are few standards in this area
• 39.
   Any typeof measurement which relates to a software system, process or related documentation • Lines of code in a program, the Fog index, number of person- days required to develop a component  Allow the software and the software process to be quantified  Measures of the software process or product  May be used to predict product attributes or to control the software process Software metric
• 40.
  Predictor and controlmetrics
• 41.
   A softwareproperty can be measured  The relationship exists between what we can measure and what we want to know  This relationship has been formalized and validated  It may be difficult to relate what can be measured to desirable quality attributes Metrics assumptions
• 42.
  Internal and externalattributes
• 43.
  The measurement process A software measurement process may be part of a quality control process  Data collected during this process should be maintained as an organisational resource  Once a measurement database has been established, comparisons across projects become possible
• 44.
  Product measurement process
• 45.
  Data collection  Ametrics programme should be based on a set of product and process data  Data should be collected immediately (not in retrospect) and, if possible, automatically  Three types of automatic data collection • Static product analysis • Dynamic product analysis • Process data collation
• 46.
  Automated data collection
• 47.
  Data accuracy  Don’tcollect unnecessary data • The questions to be answered should be decided in advance and the required data identified  Tell people why the data is being collected • It should not be part of personnel evaluation  Don’t rely on memory • Collect data when it is generated not after a project has finished
• 48.
   A qualitymetric should be a predictor of product quality  Classes of product metric • Dynamic metrics which are collected by measurements made of a program in execution • Static metrics which are collected by measurements made of the system representations • Dynamic metrics help assess efficiency and reliability; static metrics help assess complexity, understandability and maintainability Product metrics
• 49.
  Dynamic and staticmetrics  Dynamic metrics are closely related to software quality attributes • It is relatively easy to measure the response time of a system (performance attribute) or the number of failures (reliability attribute)  Static metrics have an indirect relationship with quality attributes • You need to try and derive a relationship between these metrics and properties such as complexity, understandability and maintainability
• 50.
  Software product metrics
• 51.
  Object-oriented metrics
• 52.
  Measurement analysis  Itis not always obvious what data means • Analysing collected data is very difficult  Professional statisticians should be consulted if available  Data analysis must take local circumstances into account
• 53.
  Measurement surprises  Reducingthe number of faults in a program leads to an increased number of help desk calls • The program is now thought of as more reliable and so has a wider more diverse market. The percentage of users who call the help desk may have decreased but the total may increase • A more reliable system is used in a different way from a system where users work around the faults. This leads to more help desk calls
• 54.
  Key points  Softwarequality management is concerned with ensuring that software meets its required standards  Quality assurance procedures should be documented in an organisational quality manual  Software standards are an encapsulation of best practice  Reviews are the most widely used approach for assessing software quality
• 55.
  Key points  Softwaremeasurement gathers information about both the software process and the software product  Product quality metrics should be used to identify potentially problematical components  There are no standardised and universally applicable software metrics