- Software developers and IT providers can benefit by defining a Process Model as a framework for their currently implemented practices and processes. By basing it on the “good practice” of the ISO12207 Software Life Cycle standard, it helps to implement quality management practice consistent with ISO9001, assess the capability of their processes against a maturity model such as ISO15504 (SPICE) or CMM, show the extent to which current practice meets industry-recognised standards and identify future improvements. This approach provides a “Capability Route Map” which helps a developer's capability to be continually improved towards industry best practice (such as CMM Level 5). Critical Software's recent experience in starting along this route is described.
There is considerable interest from software developers and IT providers in adopting good practice which improves their ability to deliver reliably (on time and on budget) and competitively (achieving customer satisfaction at an attractive cost). “Good practice” comprises processes, methods and techniques which are recognised by the industry as effective and appropriate and are usually defined externally, for example by international standards or industry initiatives. They strengthen the ability of the developer to demonstrate to customers that he is capable of meeting their requirements and competent to bid for work.
To obtain maximum value from “good practice”, the developer needs to understand the capability (“strengths and weaknesses”) of current practices against them and therefore what changes or improvements can be made. These good practices enable the developer to establish a Process Model which assists the consistent application of current practices and provides a “Capability Road Map” for steadily improving them.
Currently, there is a range of external “good practice” definitions available for software and IT, most obviously in the form of international standards and similar. Specific examples relevant to quality management and process improvement are: • • •
ISO9001 Quality Management Systems ISO12207 Software Life Cycle Processes CMM Capability Maturity Model 2
Over the last 3 years, Critical Software has adopted a number of these “good practice” definitions as part of its initiatives to achieve effective development processes and improve them further. In particular it has assessed the capability of its development processes using the ISO15504 standard [1] and achieved formal certification against the ISO9001 standard [2]. Both of these standards recognise the significance of the ISO12207 Software Life Cycle standard [3] as a basis for structuring and defining the key processes needed to develop and deliver software and IT systems.
Improve QPI has advised and supported Critical in updating its practices and processes for ISO9001 certification and ISO15504 assessment. Improve QPI’s wide experience in the software industry and Critical’s specific experience as a software developer in several market sectors has contributed to the concept of the “Capability Road Map” - a framework within which a software developer can initially identify “good practice”, relate it to recognised industry practice and then evaluate its capability by means of external standards such as ISO9001, CMM and ISO15504.
The key first step is identifying what activities and practices take place in your organizational units (e.g. development group, support team etc.) and defining them. Typically, activities and practices will have been established in a mostly “ad-hoc” way in response to previous project and product needs, and maybe without any systematic attempt to provide a sensible or consistent process structure. Some activities and practices may be defined more clearly than others or, while having the same purpose, may be implemented differently in separate teams and groups. The extent to which these activities and practices can be considered to be part of a process will vary (i.e. having defined purpose, inputs, outputs and intermediate steps).
The various activities and practices can then be “abstracted” to create a Process Model – a single “end-to-end” set of processes required to develop and support the organization’s products or services. Some process steps will be sequential, some may take place in parallel. The goal is to have one common definition of each process and their practices (e.g. requirements definition, project planning, document review) rather than equivalent but different definitions for each organizational unit or project team. Also there needs to be a clear and consistent definition of the purpose, inputs and outcomes for each process.
Figure 1 below indicates the relationship of the Process Model to existing sets of practices. Existing activities and practices (e.g. from separate projects) are identified, analysed and abstracted to define the Process Model which can then be instantiated (applied) on projects.
The Process Model includes non-development processes which support the organisation’s ability to develop, deliver and support the product - in particular management processes and product-related ones such as problem handling, change management and documentation.
Once established, the Process Model provides the common starting point for new projects and activities – i.e. it is “instantiated” each time it is used. Where there is a genuine project need, individual processes and practices can be tailored– part of the quality management of the project. A standard feature of project start-up is review of the processes and practices within the Process Model to confirm that where it can be applied “as usual” or where variations are needed. Any variations are defined, reviewed and approved them before project work starts.
While there are good internal reasons for establishing a Process Model, a much clearer relationship with external standards is also now possible. For instance, the ISO12207 standard defines a software life cycle and process structure (CustomerSupplier, Engineering, Management etc.) which is compatible with the ISO9001 Quality Management and ISO15504 Software Process Improvement standards. By mapping the internal Process Model onto the ISO12207 standard, (or using this standard as a basis for the Process Model) you will have established “good practice” that maps onto the ISO9001 and ISO15504 standards. This provides a clear starting point for applying these standards and assessing compliance with them.
Figure 2 below provides a fuller illustration of how current activities and tasks can be structured, mapped (partitioned) onto an ISO12207-style process model and how “state-of the art” detailed practice can be included within specific process sets.
This standard defines several groups of processes that need to be in place for effective quality management
Quality Management System Management Responsibility Resource Management Product Realization Measurement, Analysis and Improvement
To comply with the ISO9001 standard, each project team, organizational unit or group could implement their practices and processes in quite different ways, as long as they are sufficiently equivalent to meet the standard’s requirements. Some processes could be significantly more effective and efficient (“capable”) than others – as long as they are adequate for the standard, they are acceptable.
This also means that ISO9001 provides limited support for process improvement – while there has to be evidence that corrective and preventive actions are taken and opportunities for improvement are being progressed, there is little recognition by the standard of the benefits of process improvement (e.g. faster delivery, better products) and no strong “drivers” to make it happen.
It is not necessary set up a Process Model to obtain ISO9001
certification – as long as you can show that you have the
required practices in place and they are being implemented, you
have complied with the standard. This can make it difficult to
move on to effective process improvement
The TickIT Guide [4]
ISO12207 therefore provides a generic Process Model which provides a starting point for an ISO9001 Quality Management System and subsequently the capability maturity approach of ISO15504 (SPICE) or the similar Capability Maturity Model CMM [5].
Table 1 below lists the groups of Processes (“Process areas”) identified by ISO12207 CRITICAL’S SOFTWARE DEVELOPMENT PROCESS
(PROCESS MODEL)
CUS.1 Acquisition CUS.2 Delivery CUS.3 Reqts Elicitation CUS.4.1 Operational use CUS.4.2 Customer Support Primary (Engineering) ENG.1.1 Sys Reqts Analysis and Design ENG.1.2 Software Reqts Analysis ENG.1.3. Software Design ENG.1.4 Software Construction ENG.1.5 Software Integration ENG.1.5 Software Testing ENG.1.6 System Integration and Testing ENG.1.7 System and Software Maintenance Supporting SUP.1 Documentation SUP.2 Configuration Management SUP.3 Quality Assurance SUP.4 Verification SUP.5 Validation SUP.7 Audit SUP.8 Problem Resolution SUP.9 Safety and Dependability Organisational MAN.2 Project Management MAN.3 Quality Management MAN.4 Risk Management ORG. 6 Reuse
Management Improvement Infrastructure
Training
Critical also used this process model for ISO15504 process capability assessment.
For an individual project, the development cycle comprises a series of stages through which the product moves, changing in status until it is ready to be delivered (see Fig 3 below). This is common to every development project, although often tailored at the more detailed level to provide the “best fit” with the project’s specific needs. This is how the standard Process Model appears from the project viewpoint.
(In practice, the Primary processes actually required will depend on the organisation’s activities: for example if mainly support, there may be few if any development processes needed.)
In preparing for ISO9001 certification, Critical based its Software Development Process (“Process Model”) on the ISO12207 standard, but adapted it to take account of its existing practices and the specific needs of its software products and development projects. Table 2 below summarises its Software Development Process Model and shows clearly its relationship with the ISO12207 standard. Note that the process identifiers (e.g. ENG1.4) help to map these processes to the ISO12207 and ISO15504 process models.
For a software provider, the key feature of this standard is
that it provides a framework for assessing the capability of
existing processes and practices and then improving them
further, particularly in the medium and long term. A
recognisable Process Model
In general, ISO9001 compliance indicates that processes are defined and achieve their purpose (Level 1 Capability) and that they are managed sufficiently well to normally deliver the required work products (Level 2 Capability). However, “standard processes” (Level 3) are not necessarily in place for the performance to be acceptable for ISO9001. Capability Levels from 3 onwards represent higher performance for the processes defined within a Process Model – achievement is far more clearly recognised by ISO15504-based process capability assessment than by ISO9001 assessment.
Defining a Process Model with knowledge of the capability levels of its processes and practices – and so that their capability can be assessed – is another step along the Capability Road Map. 4
To take full advantage of the ISO15504 approach, a more detailed set of process models can be constructed, which introduce relevant best practices from standards and external sources (e.g. for an industry sector such as space) as well as the more detailed practices needed to demonstrate higher levels of process maturity (e.g. CMM Level 4). This set of models provides a “Capability Road Map” for moving from an initial set of defined practices to a
This series of models comprises: • Implementation Processes Model (IPM); captures current engineering and management practice • •
Process Reference Model (PRM); abstracted set of processes, in particular defining “purposes and outcomes” of each process Process Assessment Model (PAM); defines the process performance and process capability indicators needed to assess process performance against ISO15504 or CMM-type maturity models
The Process Assessment Model (PAM) defines the best practices available to project teams and development groups as well as the outputs and indicators needed to demonstrate process capability against either the ISO15504 or CMM maturity levels. This provides a long-term reference framework and the basis for regular assessment of compliance to ISO9001, ISO12207, ISO15504, CMM or other requirements (e.g. industry specific).
A project, team or group can tailor the best practices from the Process Reference Model for its specific needs, subject to approval from a quality specialist to ensure the adapted practices continue to support internal requirements, required external or industry standards and will continue to support assessment of process capability - i.e. that project practice complies with the Process Assessment Model.
Once this set of process models is in place, development work is performed against known levels of “good practice” (or maybe “best practice”) and continuing process improvements to higher levels of capability (i.e. steps along the Capability Road Map) can be targeted and achieved.
Critical Software practice includes tailoring of its Software Development Process (SDP) as a normal part of project start-up; effectively the SDP acts as the Process Reference Model for its engineering and development activities. The ISO15504 (SPICE) assessment which has already been performed will provide a foundation for establishing a Process Assessment Model (PAM) to support regular process capability assessment of its practices and processes.
Individual project teams or groups (Business Units) utilise practices and processes which are drawn from the process areas in the Process Model. These correspond closely to the ISO12207 structure • Customer – Supplier • Engineering / Development • Management • Organisational • Support
The processes are defined to meet targets for capability
level and for compliance with external standards, product
or industry requirements. Upgrades or improvements can
be made to the processes in the Process Model
By adopting a Process Reference Model based on the ISO12207 standard, Critical has achieved a number of advantages • A clear structure for its processes which meet ISO9001 requirements for Quality Management System (and its formal certification) • The ability to assess the current capability of its processes using the ISO15504 standard (or alternatively the CMM) • Consistent processes and practices for its project work, with all practices and activities traceable to a common process model (structure and definitions) • Future ability to enhance the capability of its key processes, demonstrated by ISO15504 assessment while retaining ISO9001 certification • A clear “Capability Road Map” for defining, assessing, managing and improving the capability of its processes in response to business, industry and customer needs.
Critical encourages other developers to define and structure its processes using the ISO12207 standard as a starting point, with tailoring allowed for specific project work. This provides a structured set of processes for application to engineering and development projects, then acts as a “framework” or “route map” for evolving from ISO9001 Quality Management compliance to assessment against ISO15504 or CMM Capability Models and longer term improvement.
This approach also supports the future ability to adapt to additional or revised external standards or adopt practices needed to work for customers in new industrial sectors. Individual project teams need only be concerned about implementing the current Process Model; they can have confidence that it represents the currently expected level of “good practice”. It is the role of the quality and process specialists to maintain and develop the Process Models in response to external requirements, business objectives and obtain feedback from process audits and assessments.
The authors would like to thank Rui Cordeiro, Quality Manager of Critical Software SA for his support for the writing of this paper. Also Jean Martin Simon of Qualium sarl, 38460 Chozeau, France for his input on the use of Process reference Models and permission to use Figures 1,2 and 4 in this paper.