This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Quality Software Process
3.3.1 The Software Process
A software process has process-components that provide help and guidance to produce the models of problem, solution, and background space and the corresponding software. The quality process is made up of process-components that follow the actual software process-components like background shadows—providing the role descriptions, activities, tasks, and deliverables that are the end result of the activities carried out within the quality process.
Thus, an overall Quality Software Process includes process-components not only for development but also for quality assurance. A quality process is not necessarily a totally independent process but can be comprised of a set of process-components that are configured depending on the needs of the project to ensure the quality of the actual software development process. Each process-component within the software process is subject to the criteria of necessity and sufficiency—with the third criterion of malleability being applied in the configuration of the process-component itself. A necessary checklist can be applied to the process-components, followed by the sufficiency checks, to ensure that the basic steps or tasks within a process not only have been followed but they have also been followed in the best possible way and with sufficient depth. Finally, the malleability of the process is provided by the process feedback loop and the ability of the process to change itself, not only for the next project but also during the project's execution.
3.3.2 The Quality Process
While the software process described above is a generic term that deals with the process of development (or integration or data warehousing, and so on), the term quality process describes the subprocess that accompanies the software process. This quality process is made up of the quality management, quality assurance, and quality control process-components discussed later in this chapter.
3.3.3 Rigorous Process
The extent to which a process is enforced depends on a number of factors. For example, a large project will have sufficient resources and process management skills to follow the iterative and incremental aspect of the process in great detail. In situations where the budgets are tight, or the skills are lacking, projects can still try to follow the process but the rigorousness with which they follow the process (sufficiency or depth) will be much reduced. Understanding the necessary and sufficient aspect of a process is extremely beneficial in balancing the rigor of the process.
3.3.4 Process Maturity
Judging the quality of process requires measuring its maturity. The Capability Maturity Model is the most popular and most accepted form of measurement of process maturity and subsequent quality. The CMM levels and their applicability in measuring processes, as discussed in the previous chapter, are crucial when measuring the maturity of the QSP. The process discussion in this chapter is aimed at helping organizations climb up the CMM maturity scale.
Furthermore, it is also worth considering CMMi as an integrated measure of the process. For example, in describing the six different project types for UML-based projects, we consider Internet-based development or e-development as a default. For each of the UML project types, the process-components are still described in a common format here, as process-components for development. This is because these process-components are relevant to new development as well as to most other project types. Variations to these process-components are permitted before the project starts, especially if we have a vastly different project type. Some changes to the way the process-components are executed should also be allowed. This is the malleability aspect of a process, as discussed next.
3.3.5 Malleable Process
We can judge the quality or the value of a process by its ability to configure these process-components. This is what I have called malleability of the process (see Section 1.8.3). Consider the differences of various UML-based projects in terms of their process requirements. For example, a straight development project uses certain process-components that directly provide development support. In that project we configure a set of process-components together and create a Software Engineering Process. That SEP is an instantiation of a process for new development. Once that SEP is created, we will still need to change it, particularly during the initial iteration of the process. This is malleability. It is an aspect of process not yet fully discussed within CMM.
3.3.6 Process Timing
Furthermore, note that a quality process or process-components that deal with quality first deal with the goals of an organization, followed by the goals of the project. Therefore, many times quality process-components in both instantiation and their enactment may start before a project starts. There are also some management-related process-components, which are included in most software processes. This management-related work usually starts before the project begins. These can be process-components that deal with the investigation, comparison, and analysis of the problem scenario to make the "Go/No Go" decision. They include numerous aspects related to cost, budget, marketing, and sales. The chance of identifying newer opportunities also comes into the picture given these process steps. Note once again these steps have to be taken before the project begins.