ISO/IEC 15504

ISO/IEC 15504 Information technology – Process assessment, also termed Software Process Improvement and Capability Determination (SPICE), is a set of technical standards documents for the computer software development process and related business management functions. It is one of the joint International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standards, which was developed by the ISO and IEC joint subcommittee, ISO/IEC JTC 1/SC 7.[1]

ISO/IEC 15504 was initially derived from process lifecycle standard ISO/IEC 12207 and from maturity models like Bootstrap, Trillium and the Capability Maturity Model (CMM).

ISO/IEC 15504 has been revised by: ISO/IEC 33001:2015 Information technology – Process assessment – Concepts and terminology as of March, 2015 and is no longer available at ISO.

Overview

ISO/IEC 15504 is the reference model for the maturity models (consisting of capability levels which in turn consist of the process attributes and further consist of generic practices) against which the assessors can place the evidence that they collect during their assessment, so that the assessors can give an overall determination of the organization's capabilities for delivering products (software, systems, and IT services).[2]

History

A working group was formed in 1993 to draft the international standard and used the acronym SPICE. SPICE initially stood for Software Process Improvement and Capability Evaluation, but in consideration of French concerns over the meaning of evaluation, SPICE has now been renamed Software Process Improvement and Capability Determination. SPICE is still used for the user group of the standard, and the title for the annual conference. The first SPICE was held in Limerick, Ireland in 2000, SPICE 2003 was hosted by ESA in the Netherlands, SPICE 2004 was hosted in Portugal, SPICE 2005 in Austria, SPICE 2006 in Luxembourg, SPICE 2007 in South Korea, SPICE 2008 in Nuremberg, Germany and SPICE 2009 in Helsinki, Finland.

The first versions of the standard focused exclusively on software development processes. This was expanded to cover all related processes in a software business, for example project management, configuration management, quality assurance, and so on. The list of processes covered grew to cover six business areas: organizational, management, engineering, acquisition supply, support, and operations.

In a major revision to the draft standard in 2004, the process reference model was removed and is now related to the ISO/IEC 12207 (Software Lifecycle Processes). The issued standard now specifies the measurement framework and can use different process reference models. There are five general and industry models in use.

Part 5 specifies software process assessment and part 6 specifies system process assessment.

The latest work in the ISO standards working group includes creation of a maturity model, which is planned to become ISO/IEC 15504 part 7.

The standard

The Technical Report (TR) document for ISO/IEC TR 15504 was divided into 9 parts. The initial International Standard was recreated in 5 parts. This was proposed from Japan when the TRs were published at 1997.

The International Standard (IS) version of ISO/IEC 15504 now comprises 6 parts. The 7th part is currently in an advanced Final Draft Standard form[3] and work has started on part 8.

Part 1 of ISO/IEC TR 15504 explains the concepts and gives an overview of the framework.

Reference model

ISO/IEC 15504 contains a reference model. The reference model defines a process dimension and a capability dimension.

The process dimension in the reference model is not the subject of part 2 of ISO/IEC 15504, but part 2 refers to external process lifecycle standards including ISO/IEC 12207 and ISO/IEC 15288.[4] The standard defines means to verify conformity of reference models.[5]

Processes

The process dimension defines processes divided into the five process categories of:

  • customer-supplier
  • engineering
  • supporting
  • management
  • organization

With new parts being published, the process categories will expand, particularly for IT service process categories and enterprise process categories.

Capability levels and process attributes

For each process, ISO/IEC 15504 defines a capability level on the following scale:[2]

Level Name
5 Optimizing process
4 Predictable process
3 Established process
2 Managed process
1 Performed process
0 Incomplete process

The capability of processes is measured using process attributes. The international standard defines nine process attributes:

  • 1.1 Process performance
  • 2.1 Performance management
  • 2.2 Work product management
  • 3.1 Process definition
  • 3.2 Process deployment
  • 4.1 Process measurement
  • 4.2 Process control
  • 5.1 Process innovation
  • 5.2 Process optimization

Each process attribute consists of one or more generic practices, which are further elaborated into practice indicators to aid assessment performance.

Each process attribute is assessed on a four-point (N-P-L-F) rating scale:

  • Not achieved (0 - 15%)
  • Partially achieved (>15% - 50%)
  • Largely achieved (>50%- 85%)
  • Fully achieved (>85% - 100%).

The rating is based upon evidence collected against the practice indicators, which demonstrate fulfillment of the process attribute.[6]

Assessments

ISO/IEC 15504 provides a guide for performing an assessment.[7]

This includes:

  • the assessment process
  • the model for the assessment
  • any tools used in the assessment

Assessment process

Performing assessments is the subject of parts 2 and 3 of ISO/IEC 15504.[8] Part 2 is the normative part and part 3 gives a guidance to fulfill the requirements in part 2.

One of the requirements is to use a conformant assessment method for the assessment process. The actual method is not specified in the standard although the standard places requirements on the method, method developers and assessors using the method.[9] The standard provides general guidance to assessors and this must be supplemented by undergoing formal training and detailed guidance during initial assessments.

The assessment process can be generalized as the following steps:

  • initiate an assessment (assessment sponsor)
  • select assessor and assessment team
  • plan the assessment, including processes and organizational unit to be assessed (lead assessor and assessment team)
  • pre-assessment briefing
  • data collection
  • data validation
  • process rating
  • reporting the assessment result

An assessor can collect data on a process by various means, including interviews with persons performing the process, collecting documents and quality records, and collecting statistical process data. The assessor validates this data to ensure it is accurate and completely covers the assessment scope. The assessor assesses this data (using his expert judgment) against a process's base practices and the capability dimension's generic practices in the process rating step. Process rating requires some exercising of expert judgment on the part of the assessor and this is the reason that there are requirements on assessor qualifications and competency. The process rating is then presented as a preliminary finding to the sponsor (and preferably also to the persons assessed) to ensure that they agree that the assessment is accurate. In a few cases, there may be feedback requiring further assessment before a final process rating is made.[10]

Assessment model

The process assessment model (PAM) is the detailed model used for an actual assessment. This is an elaboration of the process reference model (PRM) provided by the process lifecycle standards.[11]

The process assessment model (PAM) in part 5 is based on the process reference model (PRM) for software: ISO/IEC 12207.[12]

The process assessment model in part 6 is based on the process reference model for systems: ISO/IEC 15288.[13]

The standard allows other models to be used instead, if they meet ISO/IEC 15504's criteria, which include a defined community of interest and meeting the requirements for content (i.e. process purpose, process outcomes and assessment indicators).

Tools used in the assessment

There exist several assessment tools. The simplest comprise paper-based tools. In general, they are laid out to incorporate the assessment model indicators, including the base practice indicators and generic practice indicators. Assessors write down the assessment results and notes supporting the assessment judgment.

There are a limited number of computer based tools that present the indicators and allow users to enter the assessment judgment and notes in formatted screens, as well as automate the collated assessment result (i.e. the process attribute ratings) and creating reports.

Assessor qualifications and competency

For a successful assessment, the assessor must have a suitable level of the relevant skills and experience.

These skills include:

  • personal qualities such as communication skills.
  • relevant education and training and experience.
  • specific skills for particular categories, e.g. management skills for the management category.
  • ISO/IEC 15504 related training and experience in process capability assessments.

The competency of assessors is the subject of part 3 of ISO/IEC 15504.

In summary, the ISO/IEC 15504 specific training and experience for assessors comprise:

  • completion of a 5-day lead assessor training course
  • performing at least one assessment successfully under supervision of a competent lead assessor
  • performing at least one assessment successfully as a lead assessor under the supervision of a competent lead assessor. The competent lead assessor defines when the assessment is successfully performed. There exist schemes for certifying assessors and guiding lead assessors in making this judgement.[9]

Uses

ISO/IEC 15504 can be used in two contexts:

  • Process improvement, and
  • Capability determination (= evaluation of supplier's process capability).

Process improvement

ISO/IEC 15504 can be used to perform process improvement within a technology organization.[14] Process improvement is always difficult, and initiatives often fail, so it is important to understand the initial baseline level (process capability level), and to assess the situation after an improvement project. ISO 15504 provides a standard for assessing the organization's capacity to deliver at each of these stages.

In particular, the reference framework of ISO/IEC 15504 provides a structure for defining objectives, which facilitates specific programs to achieve these objectives.

Process improvement is the subject of part 4 of ISO/IEC 15504. It specifies requirements for improvement programmes and provides guidance on planning and executing improvements, including a description of an eight step improvement programme. Following this improvement programme is not mandatory and several alternative improvement programmes exist.[10]

Capability determination

An organization considering outsourcing software development needs to have a good understanding of the capability of potential suppliers to deliver.

ISO/IEC 15504 (Part 4) can also be used to inform supplier selection decisions. The ISO/IEC 15504 framework provides a framework for assessing proposed suppliers, as assessed either by the organization itself, or by an independent assessor.[15]

The organization can determine a target capability for suppliers, based on the organization's needs, and then assess suppliers against a set of target process profiles that specify this target capability. Part 4 of the ISO/IEC 15504 specifies the high level requirements and an initiative has been started to create an extended part of the standard covering target process profiles. Target process profiles are particularly important in contexts where the organization (for example, a government department) is required to accept the cheapest qualifying vendor. This also enables suppliers to identify gaps between their current capability and the level required by a potential customer, and to undertake improvement to achieve the contract requirements (i.e. become qualified). Work on extending the value of capability determination includes a method called Practical Process Profiles - which uses risk as the determining factor in setting target process profiles.[10] Combining risk and processes promotes improvement with active risk reduction, hence reducing the likelihood of problems occurring.

Acceptance of ISO/IEC 15504

ISO/IEC 15504 has been successful as:

  • ISO/IEC 15504 is available through National Standards Bodies.
  • It has the support of the international community.
  • Over 4,000 assessments have been performed to date.
  • Major sectors are leading the pace such as automotive, space and medical systems with industry relevant variants.
  • Domain-specific models like Automotive SPICE and SPICE 4 SPACE can be derived from it.
  • There have been many international initiatives to support take-up such as SPiCE for small and very small entities.

On the other hand, ISO/IEC 15504 has not yet been as successful as the CMMI. This has been for several reasons:

  • ISO/IEC 15504 is not available as free download but must be purchased from the ISO (Automotive SPICE on the other hand can be freely downloaded from the link supplied below.) CMM and CMMI are available as free downloads from the SEI website.
  • The CMMI is actively sponsored (by the US Department of Defense).
  • The CMM was created first, and reached critical 'market' share before ISO 15504 became available.
  • The CMM has subsequently been replaced by the CMMI, which incorporates many of the ideas of ISO/IEC 15504, but also retains the benefits of the CMM.

Like the CMM, ISO/IEC 15504 was created in a development context, making it difficult to apply in a service management context. But work has started to develop an ISO/IEC 20000-based process reference model (ISO/IEC 20000-4) that can serve as a basis for a process assessment model. This is planned to become part 8 to the standard (ISO/IEC 15504-8). In addition there are methods available that adapt its use to various contexts.

References

  1. ^ ISO. "Standards Catalogue: ISO/IEC JTC 1/SC 7". Retrieved 2014-01-06.
  2. ^ a b ISO/IEC 15504-2 Clause 5
  3. ^ DTR, meaning Draft Technical Report
  4. ^ ISO/IEC 15504-2 Clause 6
  5. ^ ISO/IEC 15504-2 Clause 7
  6. ^ ISO/IEC 15504 part 3
  7. ^ ISO/IEC 15504 parts 2 and 3
  8. ^ ISO/IEC 15504-2 Clause 4 and ISO/IEC 15504-3
  9. ^ a b van Loon, 2007a
  10. ^ a b c van Loon, 2007b
  11. ^ ISO 15504-2 Clause 6.2
  12. ^ ISO/IEC 15504-2 Clause 6.3 and ISO/IEC 15504-5
  13. ^ ISO/IEC 15504-6
  14. ^ ISO/IEC 15504-4 Clause 6
  15. ^ ISO/IEC 15504-4 Clause 7

Further reading

  • ISO/IEC 15504-1:2004 Information technology — Process assessment — Part 1: Concepts and vocabulary
  • ISO/IEC 15504-2:2003 Information technology — Process assessment — Part 2: Performing an assessment
  • ISO/IEC 15504-2:2003/Cor 1:2004
  • ISO/IEC 15504-3:2004 Information technology — Process assessment — Part 3: Guidance on performing an assessment
  • ISO/IEC 15504-4:2004 Information technology — Process assessment — Part 4: Guidance on use for process improvement and process capability determination
  • ISO/IEC 15504-5:2012 Information technology — Process Assessment — Part 5: An exemplar Process Assessment Model
  • ISO/IEC TR 15504-6:2013 Information technology — Process assessment — Part 6: An exemplar system life cycle process assessment model
  • ISO/IEC TR 15504-7:2008 Information technology — Process assessment — Part 7: Assessment of organizational maturity
  • ISO/IEC PDTR 15504-8 Information technology — Process assessment — Part 8: An exemplar process assessment model for IT service management
  • ISO/IEC TS 15504-9:2011 Information technology — Process assessment — Part 9: Target process profiles
  • ISO/IEC TS 15504-10:2011 Information technology — Process assessment — Part 10: Safety extension
  • van Loon, H. (2007a) Process Assessment and ISO 15504 Springer ISBN 978-0-387-30048-1
  • van Loon, H. (2007b) Process Assessment and Improvement Springer ISBN 978-0-387-30044-3

External links

Agile software development

Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, empirical knowledge, and continual improvement, and it encourages rapid and flexible response to change.The term agile (sometimes written Agile) was popularized, in this context, by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.There is significant anecdotal evidence that adopting agile practices and values improves the agility of software professionals, teams and organizations; however, some empirical studies have found no scientific evidence.

Capability Maturity Model Integration

Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many United States Department of Defense (DoD) and U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization. CMMI defines the following maturity levels for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. Version 2.0 was published in 2018 (Version 1.3 was published in 2010, and is the reference model for the remaining information in this wiki article). CMMI is registered in the U.S. Patent and Trademark Office by CMU.

Continual improvement process

A continual improvement process, also often called a continuous improvement process (abbreviated as CIP or CI), is an ongoing effort to improve products, services, or processes. These efforts can seek "incremental" improvement over time or "breakthrough" improvement all at once. Delivery (customer valued) processes are constantly evaluated and improved in the light of their efficiency, effectiveness and flexibility.

Some see CIPs as a meta-process for most management systems (such as business process management, quality management, project management, and program management). W. Edwards Deming, a pioneer of the field, saw it as part of the 'system' whereby feedback from the process and customer were evaluated against organisational goals. The fact that it can be called a management process does not mean that it needs to be executed by 'management'; but rather merely that it makes decisions about the implementation of the delivery process and the design of the delivery process itself.A broader definition is that of the Institute of Quality Assurance who defined "continuous improvement as a gradual never-ending change which is: '... focused on increasing the effectiveness and/or efficiency of an organisation to fulfil its policy and objectives. It is not limited to quality initiatives. Improvement in business strategy, business results, customer, employee and supplier relationships can be subject to continual improvement. Put simply, it means ‘getting better all the time’.' "

European Software Institute

The European Software Institute (ESI) is a division of Tecnalia with its headquarters in Spain.

One of the early "products" of the institute was a methodology for analyzing and improving processes in software-producing organisations which then became a standard ISO/IEC 15504 with the popular name "SPICE". This standard was the European "answer" to the Capability Maturity Model Integration (CMMI) methodology having been developed at the Software Engineering Institute at Carnegie Mellon University, Pittsburgh, Pennsylvania, US, which today is an institute being in "co-optition" with ESI.

ISO/IEC 12207

ISO/IEC/IEEE 12207 Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.

ISO/IEC 20000

ISO/IEC 20000 is the first international standard for IT service management. It was developed in 2005 by ISO/IEC JTC1/SC7 and revised in 2011 and 2018. It was originally based on the earlier BS 15000 that was developed by BSI Group.ISO/IEC 20000, like its BS 15000 predecessor, was originally developed to reflect best practice guidance contained within the ITIL (Information Technology Infrastructure Library) framework (reference needed), although it equally supports other IT service management frameworks and approaches including Microsoft Operations Framework and components of ISACA's COBIT framework. The differentiation between ISO/IEC 20000 and BS 15000 has been addressed by Jenny Dugmore.The standard was first published in December 2005. In June 2011, the ISO/IEC 20000-1:2005 was updated to ISO/IEC 20000-1:2011. In February 2012, ISO/IEC 20000-2:2005 was updated to ISO/IEC 20000-2:2012.

ISO 20000-1 has now been revised by ISO/IEC JTC 1/SC 40 IT Service Management and IT Governance. The revision has been released in July 2018. From that point certified entities enter a three year transition period to update to the new version of ISO 20000-1.

ISO/IEC 33001

ISO/IEC 33001 Information technology -- Process assessment -- Concepts and terminology is a set of technical standards documents for the computer software development process and related business management functions.

ISO/IEC 33001:2015 is a revision of ISO/IEC 15504. The ISO/IEC 330xx family of standards is intended to supersede the ISO/IEC 155xx family.

ISO/IEC JTC 1/SC 40

ISO/IEC JTC 1/SC 40 IT Service Management and IT Governance is a standardization subcommittee of the Joint Technical Committee ISO/IEC JTC 1 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). ISO/IEC JTC 1/SC 40 develops and facilitates the development of international standards, technical reports, and technical specifications within the fields of IT service management and IT governance, with a focus in IT activity such as audit, digital forensics, governance, risk management, outsourcing, service operations and service maintenance. The international secretariat of ISO/IEC JTC 1/SC 40 is Standards Australia (SA), located in Australia.

ISO/IEC JTC 1/SC 7

ISO/IEC JTC 1/SC 7 Software and systems engineering is a standardization subcommittee of the Joint Technical Committee ISO/IEC JTC 1 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), that develops and facilitates standards within the field of engineering of software products and systems. The international secretariat of ISO/IEC JTC 1/SC 7 is the Bureau of Indian Standards (BIS) located in India.

In-Step BLUE

in-STEP BLUE is a project management software program developed and sold by microTOOL GmbH, based in Berlin, Germany. It is designed to assist project managers in developing plans, assigning resources to tasks, tracking progress, managing budgets, requirements, changes and risks as well as analyzing workloads. The tool automatically stores all project results in a central repository shared by all users. Individual project management methods can be supported as well as the agile method Scrum, official methods like the British PRINCE2, the German V-Model XT (Version 1.4), the Swiss HERMES method and methods for the automotive industry according to ISO/IEC 15504, also known as SPICE.

The software is available in English and German and has more than 34,000 registered users worldwide.

List of International Organization for Standardization standards, 15000-15999

This is a list of published International Organization for Standardization (ISO) standards and other deliverables. For a complete and up-to-date list of all the ISO standards, see the ISO catalogue.The standards are protected by copyright and most of them must be purchased. However, about 300 of the standards produced by ISO and IEC's Joint Technical Committee 1 (JTC1) have been made freely and publicly available.

Project management

Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time.

The primary challenge of project management is to achieve all of the project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, quality and budget. The secondary – and more ambitious – challenge is to optimize the allocation of necessary inputs and apply them to meet pre-defined objectives. The object of project management is to produce a complete project which complies with the client's objectives. In many cases the object of project management is also to shape or reform the client's brief in order to feasibly be able to address the client's objectives. Once the client's objectives are clearly established they should influence all decisions made by other people involved in the project – for example project managers, designers, contractors and sub-contractors. Ill-defined or too tightly prescribed project management objectives are detrimental to decision making.

A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or staffing) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. The temporary nature of projects stands in contrast with business as usual (or operations), which are repetitive, permanent, or semi-permanent functional activities to produce products or services. In practice, the management of such distinct production approaches requires the development of distinct technical skills and management strategies.

Software development process

In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. It is also known as a software development life cycle. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.

Some people consider a life-cycle "model" a more general term for a category of methodologies and a software development "process" a more specific term to refer to a specific process chosen by a specific organization. For example, there are many specific software development processes that fit the spiral life-cycle model. The field is often considered a subset of the systems development life cycle.

Software quality

In the context of software engineering, software quality refers to two related but distinct notions:

Software functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product. It is the degree to which the correct software was produced.

Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It has a lot more to do with the degree to which the software works as needed.Many aspects of structural quality can be evaluated only statically through the analysis of the software inner structure, its source code, at the unit level, the technology level and the system level, which is in effect how its architecture adheres to sound principles of software architecture outlined in a paper on the topic by OMG. But some structural qualities, such as usability, can be assessed only dynamically (users or others acting in their behalf interact with the software or, at least, some prototype or partial implementation; even the interaction with a mock version made in cardboard represents a dynamic test because such version can be considered a prototype). Other aspects, such as reliability, might involve not only the software but also the underlying hardware, therefore, it can be assessed both statically and dynamically (stress test).

Functional quality is typically assessed dynamically but it is also possible to use static tests (such as software reviews).

Historically, the structure, classification and terminology of attributes and metrics applicable to software quality management have been derived or extracted from the ISO 9126-3 and the subsequent ISO 25000:2005 quality model, also known as SQuaRE. Based on these models, the Consortium for IT Software Quality (CISQ) has defined five major desirable structural characteristics needed for a piece of software to provide business value: Reliability, Efficiency, Security, Maintainability and (adequate) Size.

Software quality measurement quantifies to what extent a software program or system rates along each of these five dimensions. An aggregated measure of software quality can be computed through a qualitative or a quantitative scoring scheme or a mix of both and then a weighting system reflecting the priorities. This view of software quality being positioned on a linear continuum is supplemented by the analysis of "critical programming errors" that under specific circumstances can lead to catastrophic outages or performance degradations that make a given system unsuitable for use regardless of rating based on aggregated measurements. Such programming errors found at the system level represent up to 90% of production issues, whilst at the unit-level, even if far more numerous, programming errors account for less than 10% of production issues. As a consequence, code quality without the context of the whole system, as W. Edwards Deming described it, has limited value.

To view, explore, analyze, and communicate software quality measurements, concepts and techniques of information visualization provide visual, interactive means useful, in particular, if several software quality measures have to be related to each other or to components of a software or system. For example, software maps represent a specialized approach that "can express and combine information about software development, software quality, and system dynamics".

Software quality assurance

Software quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000 or a model such as CMMI.SQA encompasses the entire software development process, which includes processes such as requirements definition, software design, coding, source code control, code reviews, software configuration management, testing, release management, and product integration. SQA is organized into goals, commitments, abilities, activities, measurements, and verifications.Software quality assurance, according to ISO/IEC 15504 v.2.5 (SPICE), is a supporting process that has to provide the independent assurance in which all the work products, activities and processes comply with the predefined plans and ISO 15504.

Stuart Arnold

Stuart Arnold (1945–2015) was a UK systems engineering professional, with a degree in electrical engineering from Leeds University.

Stuart Arnold had a background in private and public sector engineering management applied to systems and software products and services. This spanned the leadership of engineering teams, the application of new technology and conducting research into systems engineering.

Stuart’s career started in microwave technology at Roke Manor Research in the UK. His systems engineering knowledge drew heavily on many years of international industrial experience working for Philips in the development, manufacture and product support of domestic, professional and defence systems. He was Software Engineering Manager for Thorn EMI Sensors before moving into government service as Systems Engineering Manager in the UK’s Defence Evaluation and Research Agency, later a QinetiQ Fellow and QinetiQ’s Systems Engineering Head of Profession.

Stuart contributed to establishing a common international understanding of the discipline of systems engineering, and to its presentation as a natural and essential element of business practice. As the Editor of the systems engineering International Standards, ISO/IEC 15288 and its companion assessment model ISO/IEC 15504 Part 6, Stuart was at the heart of ISO actions to establish systems engineering as a cardinal component of international trade and commerce. He was also a recognized contributor to both IEEE 1220 and EIA-632.

Stuart was a Chartered Engineer in the UK, a Fellow of the Institution of Engineering and Technology, and a Fellow of the International Council of Systems Engineering (INCOSE).

TickIT

TickIT is a certification program for companies in the software development and computer industries, supported primarily by the United Kingdom and Swedish industries through UKAS and SWEDAC respectively. Its general objective is to improve software quality.

Tudor IT Process Assessment

Tudor IT Process Assessment (TIPA®) is a methodological framework for process assessment. Its first version was published in 2003 by the Public Research Centre Henri Tudor based in Luxembourg. TIPA is now a registered trademark of the Luxembourg Institute of Science and Technology (LIST). TIPA offers a structured approach to determine process capability compared to recognized best practices. TIPA also supports process improvement by providing a gap analysis and proposing improvement recommendations.

TIPA uses the generic approach for process assessment published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) in ISO/IEC 15504 – Process Assessment (now ISO/IEC 33000). The ISO/IEC 15504-2 requirements on performing assessments are structured and documented in the TIPA Assessment Process. Additional guidance, contextual advice and return of experience complete the TIPA Process Assessment Method and support the usability of the TIPA framework. The TIPA Process Assessment Method can be used to assess processes from any field of activity.

The TIPA framework is supported by an exhaustive toolbox that provides templates and tools for every single step of the assessment process. It can be customized to any application domain .

Fields
Concepts
Orientations
Models
Software
engineers
Related fields
ISO standards by standard number
1–9999
10000–19999
20000+
IEC standards
ISO/IEC standards
Related

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.