11

  • Background reading: Quality Management

    Please read chapter 24 and do the associated activities.

    24.1 Software quality
    24.2 software standards
    24.3 Software measurement and metrics

  • Topics covered

    Software quality
    Software standards
    Reviews and inspections
    Quality management and agile development
    Software measurement (in brief)

    Why is Quality Management (QM) important?

    In 1960s, problems with software quality were discovered with the development of the first large software systems such as
    1. Software was delivered over time;
    2. Software was unreliable;
    3. Software systems were difficult to maintain and
    4. Software was hard to reuse etc.

    Examples of project failure

    Many software projects have run over time and budget. Some of them have to terminate before the deadline.

    Examples:
    Overrun Budget: The IBM OS/360 operating system was a classic example. It spent over 10 years from 1960s to 1970s. (Pugh and Johnson, 1991)
    data source: https://books.google.co.uk/books?id=MFGj_PT_clIC&printsec=frontcover&dq=IBM's+360&redir_esc=y&hl=en#v=onepage&q=IBM's%20360&f=false Accessed date:31/08/2016

    Examples:
    Cause life: software defects can kill people. E.g. Thrac-25 incident. The embedded systems used in radiotherapy machines failed and cause some of patients die. The main reasons are bad software design and development practices. It even couldn’t do testing in a clean automated way. (Rose, 1994)
    data source: www.ccnr.org/fataldose.html Accessed date:31/08/2016

    Why is Quality Management (QM) important?

    To prevent failure in large software systems which lead to the adoption of formal techniques of software QM.
    The fundamentals of quality management were established by manufacturing industry in a drive to improve the quality of the products that were being made.
    These quality management techniques, in conjunction with new software technologies and better software testing, have led to significant improvements in the general level of software quality.

    Software Quality Management (SQM)

    Concerned with ensuring that the required level of quality is achieved in a software product.
    Three principal concerns:
    At the organisational level: SQM is concerned with establishing a framework of organisational processes and standards that will lead to high-quality software.
    At the project level: establish a quality processes and a quality plan for a project.

    Quality Management (QM) Activities

    QM provides an independent check on the software development process.
    The QM process checks the project deliverables to ensure that they are consistent with organizational standards and goals
    The quality team (QT) should be independent from the development team.
    QT should report to management above the project manager level.
    Project manager might compromise on product quality in order to meet the project’s schedule and budget.

    Quality planning

    A quality plan sets out the desired product qualities and how these are assessed and defines the most significant quality attributes.
    The quality plan should define the quality assessment process.
    It should set out which organisational standards should be applied and, where necessary, define new standards to be used.

    Quality plans

    Humphrey (1989) suggests an outline structure for a quality plan, this includes:
    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.

    Scope of quality management

    Quality management is particularly important for large, complex systems. The quality documentation is a record of progress and supports continuity of development as the development team changes.
    Useful link: documentation standards
    For smaller systems, quality management needs less documentation and should focus on establishing a quality culture.
    Techniques have to evolve when agile development is used.

  • Software quality

  • Software quality attributes

    Safety Understandability Portability
    Security Testability Usability
    Reliability Adaptablity Reusability
    Resilience Modularity Efficiency
    Robustness Complexity Learnability

    Software quality

    Quality, simplistically, means that a product should meet its specification.
    This is problematical for software systems
    There is a 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.
    The focus may be ‘fitness for purpose’ rather than specification conformance.

    Software fitness for purpose

    Has the software been properly tested?
    Is the software sufficiently dependable to be put into use?
    Is the performance of the software acceptable for normal use?
    Is the software usable?
    Is the software well-structured and understandable?
    Have programming and documentation standards been followed in the development process?

    Non-functional characteristics

    The subjective quality of a software system is largely based on its non-functional characteristics.
    This reflects practical user experience – if the software’s functionality is not what is expected, then users will often just work around this and find other ways to do what they want to do.
    However, if the software is unreliable or too slow, then it is practically impossible for them to achieve their goals.

  • Quality conflicts

    It is not possible for any system to be optimized for all of these attributes – for example, improving robustness may lead to loss of performance.
    The quality plan should therefore define the most important quality attributes for the software that is being developed.
    The plan should also include a definition of the quality assessment process, an agreed way of assessing whether some quality, such as maintainability or robustness, is present in the product.

    Process and product quality

    The quality of a developed product is influenced by the quality of the production process.
    This is important in software development as some product quality attributes are hard to assess.
    However, there is a very complex and poorly understood relationship between software processes and product quality.
    The application of individual skills and experience is particularly important in software development;
    External factors such as the novelty of an application or the need for an accelerated development schedule may impair product quality.

    Quality culture

    Quality managers should aim to develop a ‘quality culture’ where everyone responsible for software development is committed to achieving a high level of product quality.
    They should encourage teams to take responsibility for the quality of their work and to develop new approaches to quality improvement.
    They should support people who are interested in the intangible aspects of quality and encourage professional behavior in all team members.

  • Software Standards

  • Problems with standards

    They may not be seen as relevant and up-to-date by software engineers.
    They often involve too much bureaucratic form filling.
    If they are unsupported by software tools, tedious form filling work is often involved to maintain the documentation associated with the standards.

    Standards development

    Involve practitioners in 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 specialised tool support. Excessive clerical work is the most significant complaint against standards.
    Web-based forms are not good enough.

    ISO 9001 standards framework

    An international set of standards that can be used as a basis for developing quality management systems.
    ISO 9001, the most general of these standards, applies to organizations that design, develop and maintain products, including software.
    The ISO 9001 standard is a framework for developing software standards.
    It sets out general quality principles, describes quality processes in general and lays out the organizational standards and procedures that should be defined. These should be documented in an organizational quality manual.

    Software standards

    Standards define the required attributes of a product or process. They play an important role in quality management.
    Standards may be international, national, organizational or project standards.

    Importance of standards

    Encapsulation of best practice- avoids repetition of past mistakes.
    They are a framework for defining what quality means in a particular setting i.e. that organization’s view of quality.
    They provide continuity - new staff can understand the organisation by understanding the standards that are used.

    Product and process standards

    Process standards
    These define the processes that should be followed during software development. Process standards may include definitions of specification, design and validation processes, process support tools and a description of the documents that should be written during these processes.

    Product Standards Process Standards
    Design review form Design review conduct
    Requirements document structure Submission of new code for system building
    Method header format Version release process
    Java programming style Project plan approval process
    Project plan format Change control process
    Change request form Test recording process

  • What is CMM

    CMM (Capability Maturity Model)
    It is a method to evaluate and measure the maturity of the software development process of an organisation.
    The maturity of software development process measurement is on a scale of 1 to 5 level
    The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an increasing series of levels of a software development organisation.
    The higher the level, the better the software development process, hence reaching each level is an expensive and time-consuming process.
    (data source: http://www.tutorialspoint.com/software_testing_dictionary/capability_maturity_model.htm)

    What is Maturity?

    Human Factors Diagram Level of CMM Diagram

    Definitions: well defined; repeatable; measured; analysed; improved and effective

    The level 1 of maturity

    CMM has 5 levels of maturity.
    Level One :Initial
    The software process is characterized as inconsistent, and occasionally even chaotic. Defined processes and standard practices that exist are abandoned during a crisis.
    Success of the organization majorly depends on an individual effort, talent, and heroics.
    The heroes eventually move on to other organizations taking their wealth of knowledge or lessons learnt with them.

    The level 2 of maturity

    Level Two: Repeatable
    This level of Software Development Organization has a basic and consistent project management processes to track cost, schedule, and functionality.
    The process is in place to repeat the earlier successes on projects with similar applications.
    Program management is a key characteristic of a level two organization.

    The level 3 of maturity

    Level Three: Defined
    The software process for both management and engineering activities are documented, standardized, and integrated into a standard software process.
    They are for the entire organization and all projects across the organization use an approved, tailored version of the organization's standard software process for developing, testing and maintaining the application.

    The level 4 of maturity

    Level Four: Managed
    Management can effectively control the software development effort using precise measurements.
    At this level, organization set a quantitative quality goal for both software process and software maintenance.
    At this maturity level, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable.

    The level 5 of maturity

    Level Five: Optimizing
    The Key characteristic of this level is focusing on continually improving process performance through both incremental and innovative technological improvements.
    At this level, changes to the process are to improve the process performance and at the same time maintaining statistical probability to achieve the established quantitative process-improvement objectives.

  • System Engineering (SE)

    System engineering (SE) covers:

    The development of total systems
    It may or may not include software.
    It focuses on transforming
    customer needs,
    Stakeholders’ expectations
    Deal with constraints into product solutions
    Support these product solutions throughout entire lifecycle of the product.

    System Engineering (SW)

    System engineering (SE) covers:

    The development of software systems
    It focuses on as follows:
    the application of systematic,
    disciplined
    quantifiable approaches to the development,
    operation and
    maintenance of software.

    Example of CMM

    Software CMM: enhance a software focused development and maintenance capability
    People CMM: develop, motivate and retain project talent.
    (Data source: www.tutorialspoint.com)

    Immature VS mature organisation

    here are following characteristics of an immature organization:
    Process improvised during project
    Approved processes being ignored
    Reactive, not proactive
    Unrealistic budget and schedule
    Quality sacrificed for schedule
    No objective measure of quality
    Data source: http://www.tutorialspoint.com/cmmi/cmmi-overview.htm

    There are following characteristics of an mature organization:
    Inter-group communication and coordination
    Work accomplished according to plan
    Practices consistent with processes
    Processes updated as necessary
    Well defined roles/responsibilities
    Management formally commits
    Data source: http://www.tutorialspoint.com/cmmi/cmmi-overview.htm

  • CMMI structure

    The CMMI structured as follows:
    Maturity levels (1-5 levels)
    Maturity capability levels (0-5 Levels)
    Process areas
    Goals: Generic and Specific
    Common features
    Practices: Generic and specific

    CMMI representation

    A representation allows an organisation to pursue different improvement objectives.
    An organisation can go either staged or continuous representation

    CMMI staged representation

    It is the approach used in the Software CMM.
    It uses predefined set of process areas to define an improvement path for an organisation. This improvement path is described by a model component called Maturity level.
    It provides a pre-defined roadmap for organisational improvement based on proven grouping and ordering of processes and associated organisational relationships.

    IPPD

    Integrated Product & Process Development (IPPD) is a systematic approach that achieves a timely collaboration of relevant stakeholders throughout the life of the product to better satisfy customer needs, expectations and requirements.
    The processes to support an IPPD approach are integrated with the other processes in the organisation.
    If a project or organisation chooses IPPD, it has to select another practices, e.g. SE or SW

    What is CMMI ?

    CMM Integration project was formed to sort out the problem of using multiple CMMs.
    CMMI Product Team's mission was to combine three Source Models into a single improvement framework to be used by the organizations pursuing enterprise-wide process improvement.

    CMM Integration (CMMI):
    builds an initial set of integrated models.
    improves best practices from source models based on lessons learned.
    establishes a framework to enable integration of future models.
    Data source: http://www.tutorialspoint.com/cmmi/cmmi-overview.htm

    How to select SE CMMI Disciplines?

    First, you may select Systems Engineering (SE) discipline if it is for improving systems engineering processes e.g. configuration management, measurement and analysis, organisational process focus, project monitoring and control etc.
    Secondly, you may select IPPD discipline if it is for integrated product and process development processes like integrated teaming, organisational environment for integration.
    Thirdly, you may select all disciplines if it is for improving multiple disciplines, then you need to work on all the areas related to those disciplines and pay attention to all of the discipline amplifications for those disciplines.

  • Maturity level details

    Level 1: initial : process unpredictable poorly controlled and reactive.
    Level 2: Managed: process characterise for projects and is often reactive.
    Level 3: defined: process characterised for the organisation and is proactive.
    Level 4: Quantitatively managed: process measured and controlled
    Level 5: Optimising: focus on continuous process improvement

    Maturity level 1

    Level 1: initial : process unpredictable poorly controlled and reactive.
    Processes are usually ad hoc and chaotic.
    Unstable environment.
    Success in these organisations depend on the competence and heroics of the people in the organisation and not on the use of proven processes.
    Frequently exceed the budget and/or schedule of their projects.
    It is characterised by a tendency to over commit; abandon processes in the time of crisis and not be able to repeat their past successes.

    Maturity level 2

    Level 2: Managed: process characterise for projects and is often reactive.
    In level 2, an organisation has achieved all the specific and generic goals of the maturity level 2 process areas. An organisation has ensured that requirements are managed and that processes are planned, performed, measured and controlled.
    The process discipline reflected by maturity level 2 helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.

    Maturity level 3

    Level 3: defined: process characterised for the organisation and is proactive.
    In level 2, an organisation has achieved all the specific and generic goals of the maturity level 2 and 3 process areas. The processes are well characterised and understood and are described in standards, procedures, tools and methods

    The difference between level 2 and 3

    Difference between level 2 and 3 is the scope of standard, process descriptions and procedures.
    In level 3, these are tailored from the organisation’s set of standard processes to suit a particular project or organisation unit.
    As results, in level 3, the processes that are performed across the organisation are consistent except for the differences allowed by the tailoring guidelines.
    Level 3 is more details and accurate than at level 2. In level 3, processes are managed more proactively using an understanding of the interrelations of the process activities and detailed measures of the process, its work products and its services.

    Maturity level 4

    Level 4: Quantitatively managed: process measured and controlled
    In level 4, an organisation has achieved all the specific and generic goals of the maturity level 2, 3, and 4 process areas.
    Quantitative objectives for quality and process performance are established and used as criteria in managing processes. Quantitative objectives are based on the needs of the customer, end users, statistical terms and are managed throughout the life of the processes.
    For these processes, detailed measure of process performance are collected and statistically analysed. Special causes of process variation are identified and whereas appropriate, the sources of special causes are corrected to prevent future occurrences.

    The difference between level 3 and 4

    Difference between level 3 and 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques and is quantitatively predictable. At Level 3, processes are only qualitatively predictable.

    Maturity level 5

    Level 5: Optimising: focus on continuous process improvement
    In level 4, an organisation has achieved all the specific and generic goals of the maturity level 2, 3, 4 and 5 process areas.
    Processes are continually improved based on a quantitative understanding of the common causes of variation inherent in processes.
    It focuses on continually improving process performance through both incremental and innovative technological improvements.
    Optimising processes that are agile and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organisation. The organisation’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning. Improvement of the processes is inherently part of everybody’s role, resulting in a cycles of continual improvement.

    The difference between level 4 and 5

    Difference between level 4 and 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives.
    At level 5, processes are concerned with addressing common causes of process performance while maintaining statistical predictability to achieve the established quant table process-improvement.

    The levels of Maturity should by sequence

    Each maturity level provides a necessary foundation for effective implantation of processes at the next level.
    Higher level processes have less chance of success without the discipline provided by lower levels.
    The effect of innovation can be hided in a noisy process.
    Higher maturity level processes may be performed by organisations at lower maturity levels with the risk of not being consistently applied in a crisis.

  • CMMI Continuous representation

    It is the approach used in the SECM and the IPD-CMM.
    It allows an organisation to select a specific process area and improve relative to it. The continuous representation uses capability levels to characterise improvement relative to an individual process area.
    It provides flexibility for organisations to choose which processes to emphasize for improvement, as well as how much to improve each process.

    How to pick the right representation for your organisation?

    Organisational maturity is the focus of the staged representation,
    Process area capability is the focus of the continuous representation.

    The difference between Organisational maturity & Process area capability

    Organisational maturity pertains to a set of process areas across an organisation
    Process area capability deals with a set of processes relating to a single process area or specific practice.

    Maturity capability levels (0-5 Levels)

    Level 0: incomplete
    Level 1: performed
    Level 2: Managed
    Level 3: Defined
    Level 4: quantitatively managed
    Level 5: Optimising

  • Reviews and inspections

  • Reviews and inspections

    A group examines part or all of a process or system and its documentation to find potential problems.
    Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management.
    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).

    Quality reviews

    A group of 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.

    Phases in the review process

    Pre-review activities
    Pre-review activities are concerned with review planning and review preparation
    The review meeting
    During the review meeting, an author of the document or program being reviewed should ‘walk through’ the document with the review team.
    Post-review activities
    These address the problems and issues that have been raised during the review meeting.

    Distributed reviews

    The processes suggested for reviews assume that the review team has a face-to-face meeting to discuss the software or documents that they are reviewing.
    However, project teams are now often distributed, sometimes across countries or continents, so it is impractical for team members to meet face to face.
    Remote reviewing can be supported using shared documents where each review team member can annotate the document with their comments.

  • Program inspections

    These are peer reviews where engineers examine the source of a system with the aim of discovering anomalies and defects.
    Inspections do not require execution of a system so may be used before implementation.
    They may be applied to any representation of the system (requirements, design, configuration data, test data, etc.).
    They have been shown to be an effective technique for discovering program errors.

    Inspection checklists

    Checklist of common errors should be used to drive the inspection.
    Error checklists are programming language dependent and reflect the characteristic errors that are likely to arise in the language.
    In general, the 'weaker' the type checking, the larger the checklist.
    Examples: Initialisation, Constant naming, loop termination, array bounds, etc.

    An inspection checklist (b)

    Fault class Inspection check
    Interface faults
    Do all function and method calls have the correct number of parameters?
    Do formal and actual parameter types match?
    Are the parameters in the right order?
    If components access shared memory, do they have the same model of the shared memory structure?
    Storage management faults
    If a linked structure is modified, have all links been correctly reassigned?
    If dynamic storage is used, has space been allocated correctly?
    Is space explicitly deallocated after it is no longer required?
    Exception management faults
    Have all possible error conditions been taken into account?

    An inspection checklist (a)

    Fault class Inspection check
    Data faults
    Are all program variables initialized before their values are used?
    Have all constants been named?
    Should the upper bound of arrays be equal to the size of the array or Size -1?
    If character strings are used, is a delimiter explicitly assigned?
    Is there any possibility of buffer overflow?
    Control faults
    For each conditional statement, is the condition correct?
    Is each loop certain to terminate?
    Are compound statements correctly bracketed?
    In case statements, are all possible cases accounted for?
    If a break is required after each case in case statements, has it been included?
    Input/output faults
    Are all input variables used?
    Are all output variables assigned a value before they are output?
    Can unexpected inputs cause corruption?

  • Quality management and agile development

  • Pair programming weaknesses

    Mutual misunderstandings
    Both members of a pair may make the same mistake in understanding the system requirements. Discussions may reinforce these errors.
    Pair reputation
    Pairs may be reluctant to look for errors because they do not want to slow down the progress of the project.
    Working relationships
    The pair’s ability to discover defects is likely to be compromised by their close working relationship that often leads to reluctance to criticize work partners.

    Agile QM and large systems

    When a large system is being developed for an external customer, agile approaches to quality management with minimal documentation may be impractical.
    If the customer is a large company, it may have its own quality management processes and may expect the software development company to report on progress in a way that is compatible with them.
    Where there are several geographically distributed teams involved in development, perhaps from different companies, then informal communications may be impractical.
    For long-lifetime systems, the team involved in development will change. Without documentation, new team members may find it impossible to understand development.

    Quality management and agile development

    Quality management in agile development is informal rather than document-based.
    It relies on establishing a quality culture, where all team members feel responsible for software quality and take actions to ensure that quality is maintained.
    The agile community is fundamentally opposed to what it sees as the bureaucratic overheads of standards-based approaches and quality processes as embodied in ISO 9001.

    Shared good practice

    Check before check-in
    Programmers are responsible for organising their own code reviews with other team members before the code is checked in to the build system.
    Never break the build
    Team members should not check in code that causes the system to fail. Developers have to test their code changes against the whole system and be confident that these work as expected.
    Fix problems when you see them
    If a programmer discovers problems or obscurities in code developed by someone else, they can fix these directly rather than referring them back to the original developer.

    Reviews and agile methods

    The review process in agile software development is usually informal.
    In Scrum,, there is a review meeting after each iteration of the software has been completed (a sprint review), where quality issues and problems may be discussed.
    In Extreme Programming, pair programming ensures that code is constantly being examined and reviewed by another team member.

    Pair programming

    This is an approach where 2 people are responsible for code development and work together to achieve this.
    Code developed by an individual is therefore constantly being examined and reviewed by another team member.
    Pair programming leads to a deep knowledge of a program, as both programmers have to understand the program in detail to continue development.
    This depth of knowledge is difficult to achieve in inspection processes and pair programming can find bugs that would not be discovered in formal inspections.

  • Software measurement

  • Software Measurement

    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 measurement programmes, most organisations still don’t make systematic use of software measurement.
    There are few established standards in this area.

    Software metric

    Any type of 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.
    May be used to predict product attributes or to control the software process.
    Product metrics can be used for general predictions or to identify anomalous components.

    Types of process metric

    The time taken for a particular process to be completed
    This can be the total time devoted to the process, calendar time, the time spent on the process by particular engineers, and so on.
    The resources required for a particular process
    Resources might include total effort in person-days, travel costs or computer resources.
    The number of occurrences of a particular event
    Examples of events that might be monitored include the number of defects discovered during code inspection, the number of requirements changes requested, the number of bug reports in a delivered system and the average number of lines of code modified in response to a requirements change.

  • Key Points

    Software quality management is concerned with ensuring that software has a low number of defects and that it reaches the required standards of maintainability, reliability, portability etc. Software standards are important for quality assurance as they represent an identification of ‘best practice’. When developing software, standards provide a solid foundation for building good quality software.
    Reviews of the software process deliverables involve a team of people who check that quality standards are being followed. Reviews are the most widely used technique for assessing quality.
    In a program inspection or peer review, a small team systematically checks the code. They read the code in detail and look for possible errors and omissions. The problems detected are discussed at a code review meeting.
    Agile quality management relies on establishing a quality culture where the development team works together to improve software quality.
    Software measurement can be used to gather quantitative data about software and the software process.
    You may be able to use the values of the software metrics that are collected to make inferences about product and process quality.
    Product quality metrics are particularly useful for highlighting anomalous components that may have quality problems. These components should then be analyzed in more detail.
    Software analytics is the automated analysis of large volumes of software product and process data to discover relationships that may provide insights for project managers and developers.

  • Glossary

    BCEIMNPQRSTVW

    B

    black-box testing

    An approach to testing where the testers have no access to the source code of a system or its components. The tests are derived from the system specification.

    Data source: Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.734

    brownfield software development

    The development of software for an environment where there are several existing systems that the software being developed must integrate with.

    Data source: Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.735

    Return to Top

    C

    Change management

    A process to record, check, analysis, estimate and implement proposed changes to a software system.

    Sommerville I. 2011"Software Engineering" 9th Edition. Pearson Pp.735

    cleanroom software engineering

    An approach to software development where the aim is to avoid introducing faults into the software (by analogy with a cleanroom used in semiconductor fabrication.) The process involves formal software specification, structured transformation of a specification to a program, the development of correctness arguments, and statistical program testing.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.736

    CMM

    The software Engineering Institue's Capability Maturity Model, which is used to been superseded by CMMI, but is still widely used.

    Sommerville I. 2011"Software Engineering" 9th Edition. Pearson Pp.736

    CMMI

    An integrated approach to process capability maturity modelling based on the adoption of good software engineering practice and integrated quality management. It sorts discrete and continuous maturity modelling and integrates systems and software engineering process maturity models.

    Sommerville I. 2011"Software Engineering" 9th Edition. Pearson Pp.736

    configuration item

    A machine-readable unit, such as a document or a source code file, that is subject to change and where the change has to be controlled by a configuration management system.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.737

    configuration management

    The process of managing the changes to an evolving software product. Configuration management involves configuration planning, version management, system building and change management.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.737

    Return to Top

    E

    event-based systems

    Systems where the control of operation is determined by events that are generated in the system/s environment. Most real-time systems are event-based systems.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.738

    Return to Top

    I

    ISO 9000/9001

    A set of standards for quality management processes that is defined by the international standards organisation (ISO). ISO 9001 is the ISO standard that is most applicable to software development. These may be used to certify the quality management process in an organisation.

    Return to Top

    M

    maintenance

    the process of making changes to a system after it has been put into operation.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.740

    mean-time to failure(MTTF)

    The average time between observed system failures; used in reliability specification.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.740

    Return to Top

    N

    non-functional requirement

    A statement of a constraint or expected behaviour that applies to a system. This constraint may refer to the emergent properties of the software that is being developed or to the development process.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.744

    Return to Top

    P

    pair programming

    A development situation where programmers work in pairs, rather than individually, to develop code; a fundamental part of extreme programming.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.742

    P-CMM

    people capability maturity model (P-CMM) which is a process maturity model that reflects how effective an organisation is at managing the skills, training and experience of the people in that organisation.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.742

    process maturity model

    A model of the extent to which a process models good practice and reflective and measurement capabilities that are geared to process improvement.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.742

    process model

    An abstract representation of a process. Process models may be developed from various perspectives and can show the activities involved in a process, the artefacts used in the process, constraints that apply to the process and the roles of the people enacting the process.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.742

    Return to Top

    Q

    quality control

    it is the application of these quality processes to weed out products that are not of the requrired level of quality

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.652

    quality assurance (QA)

    The overall process of defining how software can be achieved and how the organisation developing the software knows that the software has met the required level of quality.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.743

    quality plan

    A plan that defines the quality processes and procedures that should be used. This involves selecting and instantiating standards for products and processes and defining the system quality attributes that are most important.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.743

    Return to Top

    R

    reengineering

    The modification of a software system to make it easier to understand and change. Reengineering often involves software and data restructuring and organisation, program simplification and documentation.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.743

    reliability

    A version of a software system that is made available to system customers.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.744

    Return to Top

    S

    safety

    The ability of a system to operate without catastrophic failure

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.744

    safety case

    A structured argument that a system is safe and/or secure. Many critical systems must have associated safety cases that are assessed and approved by external regulators before the system is certified for use.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.744

    security

    The ability of a system to protect itself against accidental or deliberate intrusion. Security includes confidentiality, integrity and availability.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.745

    SEI

    software Engineering Institute. A software engineering research and technology transfer centre founded with the aim of improving the standard of software engineering in U.S. companies.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.745

    software metric

    An attribute of a software system or process that can be expressed numerically and measured. Process metrics are attributes of the process such as the time taken to complete a task; product metrics are attributes of the software itself such as size or complexity.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.745

    Return to Top

    T

    test coverage

    The effectiveness of system tests in testing the code of an entire system. Some companies have standards for test coverage (e.g. the system tests shall ensure that all program statements are executed at least once.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.746

    test-driven development

    An approach to software development where executable tests are written before the program codes. The set of tests are run automatically after every change to the program.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.747

    Return to Top

    V

    valiation

    The process of checking that a system meets the needs and expectations of the customer.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.747

    verification

    The process of checking that a system meets the needs and specifications.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.747

    Return to Top

    W

    white -box test

    An approach to program testing where the tests are based on knowledge of the structure of the program and its components. Access to source code is essential for white-box testing.

    Sommerville I. 2011"Software Engineering" 10th Edition. Pearson Pp.748

    Return to Top