Tailoring the Software Development Process
The QMS processes may be individually selected, tailored and even modified/extended, as necessary, to achieve the specific goals and requirements for a project. This is described in the Project Life Cycles document and in the level 2 documentation for each process (e.g. Requirements Analysis, Software Design, Software Construction, Software Testing, Maintenance, etc.).Each level 2 process document contains a “Process Tailoring” section that presents approved tailoring
considerations relevant to each process. Additionally specific Pre-Tailoring Process Guidelines could already be defined for some specific types of projects.
For Example:
• Research & Development Projects Tailoring Guidebook;
• Maintenance Projects Tailoring Guidebook.
Additional info on tailoring can be found in the SDP (SDP-0909). Tailoring decisions are typically recorded in Quality Assurance Plans for the projects (QAP) and properly stored under version control.
How is it done in the "real world"?
For some software development processes the approach goes through a definition of project types (and the software life cycle under waterfall methodologies) and some well defined project attributes (like team size, project criticality, schedule aggressiveness, etc.) will allow you to REUSE a set of pre-tailored decisions (use this phase, do not use this phase, skip this milestone, deliver these deliverables, produce this documentation, perform these measures of verification and validation or not, etc.). The projects upon start can inherit these pre-tailoring decisions, and if needed (and justified) perform some more. Note: Sometimes the PM will have to approve further changes with the Quality Department. Some additional tailoring decisions are simply not acceptable, for instance: "Let's not do any documentation for this new software development project because we don't have resources for that".Different projects lead to different needs. These project types are high-level taxonomic classes that, in the organization’s experience, lead to substantially different development scenarios and requirements. For instance: Software Development projects, Research and Development Projects, Maintenance Projects, Service Projects, Outsourcing Projects, etc.
Project Types and Project Attributes
The Project Types give us indications of particular project’s vulnerabilities (in the example more based in available knowledge and experience) that a more formal, frequent, granular or extensive process performance may help overcome.
The Project Attributes pinpoint project’s characteristics that advise a more strong or relaxed approach to process performance.
Notice that project attributes consideration may lead to different conclusions: A High Reuse project with a high level of Criticality shall enforce very formal and detailed verification and validation processes.
Tailoring targets
Tailoring targets are software development processes and activities. Its upon the software development process descriptions and requirements that tailoring activity will be exercised.Classified a project, established its attributes and considered its tailoring factors this information shall be cross-related with the goals of each process and activity in the software development process and these processes and activities “tailored” to meet the goals of the project.Tailoring activity may decide that a particular activity (or even a process) has no reason to exist in a project, in most of the cases however, it will be exercised what is known as “Tailoring by Degree”
Tailoring by degree
Tailoring by degree acts upon processes and activities attributes adjusting them to the needs and goals of a project.
Formality - the essential aspects of an activity can be performed with varying degree of detail, or attention to formal rules, procedures, or standards.(…)
Frequency – (…)The frequency of each activity needs to be interpreted in light of the organisation's and project's needs.
Granularity - the level of detail needed in the process definition may vary. (…) A project may want to include more or less detail (…).
Scope - it may not make sense to perform certain activities, due to organizational constraints, business environment, etc.
Source: Process Tailoring and the Software Capability Maturity Model – CMU/SEI-94-TR-024 – Mark P. Ginsberg, Lauren H. Quinn – 1995.
Sources (and further reading)
- Process Tailoring and the Software Capability Maturity Model – CMU/SEI-94-TR-024 – Mark P. Ginsberg, Lauren H. Quinn – 1995
“Tailoring is a key element in the organization’s ability to develop reasonable and efficient software development plans for use in managing and controlling projects within the organization.”
- A Matrix Approach to Software Process Definition – NASA SEL - David Schultz, Judith Bachman, Linda Landis (CSC), Mike Stark, Sally Godfrey (GSFC), Maurizio Morisio (Univ. of Maryland) - 2000 (pdf here)
“Tailoring is a process by which individual requirements or specifications, standards and related documents are evaluated and made applicable to a specific project, by selection and in some exceptional cases, modification of existing or addition of new requirements.”
Details elsewhere here. Quoting: "ISO/IEC 12207:2008 establishes a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry [It aims to be the standard that defines all the tasks required for developing and maintaining software]. It contains processes, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products. Software includes the software portion of firmware."
(...) ISO/IEC 12207:2008 also provides a process that can be employed for defining, controlling, and improving software life cycle processes.
(2016-05-04: Minor rephrases; addit. hyperlinks)
