Loading...

The Human Being as Key Element for Software Process Improvement

Scientific Essay 2012 27 Pages

Computer Science - General

Excerpt

Contens

Abstract

1 Introduction

2 Software Development

3 Software Process Improvement (SPI) Methods
3.1 Actions
3.2 Software Process Improvement Models
3.3 SPI Manifesto

4 New approach of Software Process Improvements
4.1 Method
4.2 Model

5 Tools for interlinked SPI

6 Influence Elements of SPI
6.1 Description of the Elements
6.2 Interlinked causal interdependencies
6.3 Network of elements and Cross-Impact Matrix

7 Results

8 Conclusion

References

illustration not visible in this excerpt

Abstract

This paper aims to explain a new approach of software process improvements (SPI). The approach will not replace the existing methods, but will support them for SPI from an additional view. The additional view consists the SPI as a networked system of the activities for SPI. The approach is an extract of a comprehensive PhD paper about SPI and defect prevention from the author. In the PhD paper the author is using over 100 important influence elements. The title of the PhD paper is: „Ganzheitlich vernetzte Fehlerprävention im Software-Entwicklungsprozess.“ (Unmüßig 2012)

Today there are various actions and constructive methods in software process improvements used. As there are a lot of different elements and subjects in the process of improvements involved - it is a complex process. The most involved elements and subjects are e.g. the human being (management, members of staff, customer, work psychology), methods, organisations, culture etc. The author’s own experience and studies confirm that the human being is one of the most important elements in the process. The human being is much more involved in the process than considered in the daily work today. His work performance e.g. software process improvements depends on a lot of interlinked factors.

This paper will use an excerpt of 12 important elements of the above mentioned PhD paper. The elements will be interlinked. A software tool is used to interlink, present and simulate the interrelationship to the other elements. The approach and results can be used in all software process improvements (SPI) / software development processes to support the existing SPI approaches and measures. The support is based on the position (strengths) and relationship of the elements in the result matrix.

Keywords: Software, Software development, Software development process, Software process improvement, SPI, Software quality, holistic, human being, human factors, interlinked elements, Influence factors, defect prevention, processes, methods, organisation, culture, network thinking, SPI Manifesto.

1 Introduction

Today’s software process improvement techniques have made substantial progress over the last years in a contribution to better software quality, but this is not enough.

The new approach consist 12 important elements/activities of SPI elements in a complex System. Today the elements e.g. methods, procedure are mostly technical elements (hard facts). Soft facts are not in the focus and both facts are not interlinked.

The key focus in the new approach in the Software Development Process is on Requirement Analysis and Specification. Based on the results of the research of available sources and in the author’s own experience, 50 to 70 % of all failures come about in these two first development phases (Masing 2007). At present, software is still prevalently compiled by humans. This means the key failure source for SW errors are human factors. The paper will present some interlinked aspects for Software Process Improvement (SPI).

2 Software Development

Process / Procedure Models

For the development of software, methods, process and procedure models are in use (see Fig.1). The activities and results fall under different types of operations such as project management. Process models further also define the relevant roles, tools and methods (Wallmüller 2001). Figure 1 shows the SW Development process and one of the various process / procedure models.

illustration not visible in this excerpt

FIG. 1: Software Development Process; (source: Relating to Hindel 2009)

Process / procedure models outline the applicable organisational framework and the sequence within the software development process. As synonyms to procedure model according to (Masing 2007, p. 824), terms such as software lifecycle, phase model, project model or process model also apply, organisational framework includes the following aspects (Balzert 1998, p. 38):

- The partial actions and sequence thereof within the process sequence (project phases);
- Planned schedules;
- Required employee qualification;
- Applicable standards, references, directives, tools and techniques.

Different procedure models emerged out of the framework conditions. The differences between the procedure models mainly relate to the level of complexity, the number of phases and the sequence of steps within procedures. The complexity of an adequate procedure model depends on circumstances in each particular case.

3 Software Process Improvement (SPI) Methods

There are various Software Process Improvement-Methods (SPI-M) used today.

3.1 Actions

1. Analytical Quality Actions

Analytical quality actions are implemented e.g. in order to verify current quality levels. The examinations do not establish absolute certainty regarding conformity/non-conformity of a product.

There are e.g. following analytical quality actions used: white box test, black box test and cause-effect analysis.

2. Constructive Quality Actions

Constructive quality actions mainly aim at defect prevention. For e.g. procedure/process models, methods, program language, quality gates, Risk management, Personal & Team Software process (PSP / TSP), FMEA & Reviews.

3. Organizational Quality Actions

Organizational actions include the design, implementation and maintenance of e.g. a corporate Quality Management System, Project Management System, team-building and others.

4. Psychological Prevention Actions/People Actions

Software development should not be considered a purely technical procedure only. As software development is carried by the human input (the development team), communication processes, leadership, quality culture and other variables this entails are key to the output quality.

3.2 Software Process Improvement Models

The combination of the explained actions of SPI are models e.g. Capability Maturity Models. An advantage to using Capability Maturity Models is that they systematically impose successful practices on different models. Examples of capability maturity models include CMM(I) or SPICE (Hörmann, 2006, p. 5).

Application of the models and actions under the models promote process improvements and thus aid the failure prevention/minimisation effort. In order to be able to effect process improvements, first an inventory check is needed of the actual status. The inventory check takes the form of an assessment. Under the assessment, formal and actually practiced processes are examined separately and correlated with ideal values and criteria under the respective capability maturity model. The correlation output is an action matrix that indicates the problem areas and processes found. In this way, process improvements may be initiated and implemented in an ideal manner. Fig. 2 shows the interdependencies between processes, process assessments, capability determination (assessment of capability maturity level) and process improvements on applying a capability maturity model such as SPICE or CMM(I).

illustration not visible in this excerpt

FIG. 2: Software Process Assessment with SPICE according to ISO 15504

(source: Petrasch 1998, p. 119)

Additionally as output, the capability maturity level is determined. Most models differentiate between levels on a range from 1 to 5, 1 to 6 or 1 to 7.

The higher the level within a model, the better the processes concerned are formally defined and practiced.

SPI are important for reducing failure and increasing quality. Late failure detection adds massively to costs. According to various analyses, failure elimination costs, as a variable, multiply by a factor of about five to ten for each phase in the sequence. This means that a failure generated in the initial specification phase that has been identified only as late as in the programming phase becomes n-times more expensive to eliminate by then. The cost growth factor between the initial specification phase and acceptance testing may reach as much as 100 (Balzert 1998, p. 288). The author´s own practical experience and analyses confirm this figure. Consequently, SPI should be pursued as the primary aim.

The goal may be complied with much easier by practicing quality control in each phase of the process rather than at the very end of the development chain only (Balzert 1998, p. 287 ff.). Quality has to be generated within the process as opposed to “imposing it” on the product post process. A about 50% of failure occur in the initial design and specification phases (Balzert 1998, p. 289), it is particularly important to concentrate on SPI specifically in the initial phases.

3.3 SPI Manifesto

The new approach for SPI in this paper will support the existing SPI activities including the following 10 statements from the SPI Manifesto in 2010 (SPI-Manifesto 2010). See Table 1.

illustration not visible in this excerpt

Tab. 1: SPI-Manifesto 2010; (source: SPI-Manifesto 2010)

4 New approach of Software Process Improvements

As SPI involves a lot of different areas/elements e.g. people, culture, organisation, methods, communication etc. it will be considered in this paper as complex network system.

Complexity according to Ulrich und Probst (1988, p. 57) is defined first by the structure, number and variety of and the interrelationships between the different elements in a system and second by variability in time. Grossmann (1992, p. 19) recognises four basic types of systems:

[...]

Author

Share

Previous

Title: The Human Being as Key Element for Software Process Improvement