1 / 23

Software Process Management

Software Process Management. Quality Assurance & Standards. Software Quality Management. “Ensuring software has a low number of defects and reaches the required standards of maintainability, reliability, portability etc.”. Software Quality. Safety Understandability Portability

guang
Télécharger la présentation

Software Process Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Process Management Quality Assurance & Standards

  2. Software Quality Management • “Ensuring software has a low number of defects and reaches the required standards of maintainability, reliability, portability etc.”

  3. Software Quality Safety Understandability Portability Security Testability Usability Reliability Adaptability Reusability Resilience Modularity Efficiencey Robustness Complexity Learnability

  4. ISO 9126 software qualities

  5. External quality changeability Testability portability Internal qualities modularity generality expandibility self-descriptiveness simplicity modularity instrumentation self-descriptiveness modularity self-descriptiveness machine independence software system independence internal versus external qualities

  6. using ISO 9126 quality standards • Judge the importance of each quality for the application • for example, safety critical systems - reliability very important • real-time systems - efficiency important • Work out ways of measuring quality • for example, mean-time between failures for reliability • response-time for efficiency

  7. software measurement • may apply to: • final products • intermediate products (predictive metrics) • may be: • relative or binary (does it/ does it not exist?) • direct or indirect • tightly or loosely coupled

  8. how do we achieve product quality? • the problem: quality attributes tend to retrospectively measurable • need to be able to examine processes by which product is created beforehand • the production process is a network of sub-processes • output from one process forms the input to the next • errors can enter the process at any stage

  9. correction of errors • errors are more expensive to correct at later stages • need to rework more stages • later stages are more detailed and less able to absorb change • Barry Boehm • error typically 10 times more expensive to correct at coding stage than at requirements stage • 100 times more expensive at maintenance stage

  10. for each activity, define: • entry requirements • these have to be in place before an activity can be started • example: ‘a comprehensive set of test data and expected results be prepared and independently reviewed against the system requirement before program testing can commence’

  11. for each activity, define • Implementation requirements • these define how the process is to be conducted • example ‘whenever an error is found and corrected, all test runs must be completed, including those previously successfully passed’

  12. for each activity, define • exit requirements • an activity will not be completed until these requirements have been met • example: ‘the testing phase is finished only when all tests have been run in succession with no outstanding errors’ • software quality plan • these requirements may be laid down in site standards, or a quality plan may be drawn up for a specific project

  13. inspections - general principles • when a piece of work is completed, copies are distributed to co-workers • time is spent individually going through the work noting defects • a meeting is held where the work is then discussed • a list of defects requiring re-work is produced

  14. inspections - advantages of approach • an effective way of removing superficial errors from a piece of software • motivates the software developer to produce better structured and self-descriptive code • spreads good programming practice • enhances team-spirit • the main problem maintaining the commitment of participants

  15. General movement to give software more quality • Increase the visibility of software • put method into processes of development • check intermediate stages

  16. ISO 9000 • A set of standards for developing a system for quality management. • ISO 9001 is a generic model of a quality process for organisations which design, develop and maintain products. • ISO 9000-3 interprets ISO 9000 for software development. • Each country has its own national standards which instantiate ISO 9000 for that country

  17. AS/NZS ISO 9000.3 • Inspection and Testing • Corrective Action • Handling, storage, packaging and delivery • Quality Records • Internal Quality Audits • Training • Software Maintenance • Statistical Techniques • Control of Development Environment • ManagementResponsibility • Quality System • Contract Review, planning and requirements control • Design, Programming and User Documentation Control • Quality System Document Control • Purchasing • Customer Supplied Information and Material • Product Identification

  18. Singapore Standards • SS ISO 9000-3 1997 • Quality management and quality assurance standards – Guidelines for the application of ISO 9001-1994 to the development, supply, installation and maintenance of computer software. • Adopted 1998

  19. Organization ofSoftware Quality Assurance ClientCo SoftCo AuditorCo Client Group Software QA Dept SQA Dept Project Group Project Group

  20. Capability Maturity Model • Carnegie Mellon’s SEI • To allow DoD to assess software contractors • Represents capability of the organisation - NOT a particular project • DoD contractors expected to be at least level 3

  21. CMM-Levels • Initial • no effective management procedures or plans • Repeatable • Formal management, quality and configuration control procedures but no formal process model • Company can successfully repeat projects of the same type • Defined • process defined (basis for process improvement) plus mechanisms to ensure process followed • Managed • metrics formally collected for process improvement • Optimizing • Process improvement an integral part of process

  22. Problems with CMM • Focuses on project management not product development and doesn’t consider • prototyping, formal or structured methods used, tools etc. • regular use of certain tools and methods may produce a better quality product than possible at same or higher level without such tools • Not appropriate for all • commercial and defence software development very different • industry can respond more swiftly to change

  23. AS4006 Software test documentation AS4008 Software design description AS4009 Software reviews and audit AS4043 Software configuration management AS4071 Software management plans AS4216 Software product evaluation AS4258 Software user documentation process AS61508.3 Functional safety of programmable electronic safety-related systems AS/NZS ISO/IEC 12207 Software lifecycle processes &etc. Other Software Standards

More Related