- Email: [email protected]
Stepwise improvement of the software-process in a multidimensional framework
Atut-1 &km’ ofAuto~~& Pro@mnmkg Vol. 16, pp63-70,1992 Printed in Great Britain. All rights resexwd
0066-41381921915.00 0 1992 Pergamoo Press Ltd
STEPWISE IMPROVEMENT OF THE SOFTWARE-PROCESS IN A MULTIDIMENSIONAL FRAMEWORK R. T. Mittermeir and R. A. Schlemmer Imtitutfiir h#hmatik der Univetsitit Kkagtnjiui, Universititsst@e
65-67, A-9022 Ulagenfurt, Germany
Abstract So&ware process models, irrespective of whether they are life cycle oriented or not, focus strictly on the activity domain within a single project. This focus is heavily challenged by COSMOS, a multidimensionalso&wareprocess model. In additionto the activitystructure,it takes into account also the communication-and infrastructurein which sofiware developmenttakes place. This threedimensional framework meets special challenges due to incorporatiug sofiware reuse and object orientedness into large scale software production and it allows for adequate planning of various activities controlling sofiware developmentwhich are not directly attributableto a specificproject, but which might run in parallel to a host of projects. This paper reports on investigations concerning the mapping of this multidimensionalsoftware developmentmodel on a software process maturity scale, analog to the one proposed by Humphrey (1989). Keywords
Software process, ACI (activity-, communicationand infrastructure),control-andexecutionlevels, reuse, long-term aspects, process maturity model.
1 Motivation “Every kid can write a program? Why so much ado about software processes? After all, we know by now, that the classical waterfall like, d~ent driven approach to develop software does not work well anyway! We develop our software by prototyping based on experience!” This, or similar arguments can quite often be heard as excuse, when project managers fail to pay adequate attention to the software development process in their or~a~on, But are they to be blamed? Software process prescriptions do indeed share some serious deficiencies - ranging from the claim of undiscriminated applicability to the lack of actually accomodating the specific difficulties one encounters in almost any real project. Quite a lot has changed, since software process models have been published for the first time. Let us look at some of it: _
Process models show a project view. This project view is fully adedquate, if all the work in an organization is focussed on but one project, or if several projects are carried out rather independently. Today, however, we see quite
R. T. Mittermeir and R. A. Schlemmer
64
often projects which extend over the boundaries of individual companies or development teams, while within software companies, one aims to execute projects in such a way that cross-vertilization and cross-utilization is maximized. Implications of the above perspective are not only that processes should extend projects as far as scope of work (their task structure) is concerned, but also from the perspective of project duration. Such a perspective is not so much driven by the fact, that maintenance becomes dominant over development from scratch (development teams and maintenance teams might differ; in some projects one might not even distinguish between maintenance and development) but from the explicit aim of our industry for software reuse, be it in development or in maintenance. A modern software process model would have to take care of the challenges stemming from the strive for reuse at all levels. _
Furtheron, one should pause for a brief reflection concerning the true nature of software. Classical process models focus on the “products” that are to be made during each step or phase, be they documents, specifications, test sequences, or executable code. However, if we carefully look at the trail of activities (including the backtracking involved with them in almost any project) we realize that software results from a complex communication process. Informal communication is frozen into specifications, specifications are made executable and finally transformed (formally or manually) into executable code, (hopefully) satisfizing what has been inadequately expressed at the very beginning of this communication process between users, managers, developers, and whoever might be involved in a complex project. Finally, we have to realize, that the root of project models has been in a time when compilers have been about the only software development tools. However, tools should influence the process as much as the process to be supported will have to influence the tools. Comparing the work and toolset of a shoemaker with the process and machinery of a modern shoe-factory might amply illustrate this fact.
In the light of these considerations, a software process model incorporating the key-factors of software production: - the activity structure - the communication structure _ the development infrastructure has been proposed (Yeh et al., 1991a). In this paper, we will report on the development of a strategy for growing in a stepwise fashion from whatever the current status of software production in a company might be to an ideal, optimizing level incorporating all three dimensions mentioned above. The paper is organized in the following way. We firstly give a brief introduction on the COSMOS process model which proposes an integrated view of activity-, communication-, and infrastructure. An ideal process will be described within these dimensions. Afterwards, a strategy of how to move towards this ideal will be sketched. Section 4 will present some findings on process readiness out a soft-validation of our concept.
Improvement of the Softwsre-ROC~SS
65
2 A Multidimensional Process Model
To capture the complexity of large software development efforts, additional handles are needed to address such aspects as the collaborativenature of the work involved, the evolution over time and the ~te~lations~~ to other, past, parallel, or future projects. In Yeh et al. (1991a,b) a framework, defined by activities, communication, and infrastructure (AC11 has been proposed. These three concepts serve as distinct but interrelated handles for software process modelling. Activities for developmentof a software system and project control are groupedinto tasks which need to be related to each other. Dependencies and ordering of corresponding elements are to be introduced, resulting in the following modelling artifacts: - Tasks and work products and - Ordering and dependencies among them Communication structure models the flow of itiormation and allocation of responsibilitiesamong all partiesinvolvedin a softwaredevelopmenteffort. Main elements used to capture these aspects are:
- Roles and res~nsibi~ties - Interconnecting communicationchannels - Communicationdependencies With infrastructum we refer to any tangible or intangible resources needed to carry out software projects. It comprises support for the activity aspect as well as support for the communication dimension. Activity related infrastructurecomprisesmethodologies,techniques,and tools for software development and project guidance. On the communicationaldimension, not only tangible aspects are to be considered. Reporting schemes, established procedures for prqject guidance, and standards count also as ~~t~ct~* Further, any investments in such intangibles as knowledge and skills of users and developers, supporting the problem solution or the improvement of the process itself, improve the infrastructure. While the significanceof the activity dimension is obvious, we want to stress that it would be futile to conduct projects in ignorance of the mat~ty of the ~rnrn~~tion structure or of in&u&ucture. On the other hand, neither of these dimensions improves on its own. It needs as focussed effort to improve on them as effort is needed to progress on the activity chain. All three dimensions can be developed to a certain maturity level. We sketch in the sequel what we consider as “ideal” for each of them. An Optimizing Activity Structure. The activity structure, ideally, needs to allow for
flexibility and dynamism.The process needs to bear the flexibilityof adaptingto changing context complexity and evolve along with increasing knowledge about the problem to be solved. Consequently, phases can no longer be viewed as static and separate as within wa~~~l-like approaches. Whenever possible, tasks - and not only those which are adjacent in the waterfall model - need to overlap or be executed in parallel. For coordinatingparallel or overlappingefforts and for balancingthe AC1dimensionsproperly, a process is split into two generic levels (Mittermeir, 1991; Yeh et al., 1991a): Cm&o1 level, Considering the limiting and reinforcing factors of each of the AC1 dimensions and their balance. This level deals with the rather nontechnical tasks of process and project management and coordinating subprojects. By its introduction, resources are explicitly devoted to tasks that are usually done as afterthoughtsand hardly get the needed attention,
R. T. Mittemei
66
and R. A. Schlemmer
Execution 1eveLPerformingpurely technical activitiesof systemsbuilding.
A process is developed recursively, starting with an an overall control level. It covers the following tasks (cf. ~t~~eir, 1991; Yeh et al., 1991a): <>
c> <> <> <> <> C> <>
Pie-project evaluation Conception of an overall solution strategy Risk management initiation Es~blis~ent and maintenance of activity, ammunition, infrastructure for the overall project Definition of subprojects Maintenance of interrelationshipsbetween subprojects Evaluation and integration of results from subprojects Evaluation of the overall result
and
At the execution level, either one of the “trivial” process models indicated by Mittermeir (1991), such as Waterfall, Prototyping, Buy-It, etc. is performed, or, if demanded by the complexityof the subtask, another, smallerscale control-/execution-levelbundle is invoked. However, the con~ptu~ starting point for all the activities of the team needs to be the customers/users problem and not only their stated requirements. To find out what users really need the development-teamsstart-off with the objectives to be achieved and with a first statement of the problem. Continuous refinement of the solution follows till an acceptableproblem solution (by all relevant customer groups accepted)is reached (cf. Yeh et al., 1991a). Hence, these tasks are not defined as distinct phases, but form highly parallel and overlapping building blocks of systems development. Therefore, phases can no longer be used as the major organizing principle at the execution level. There, problem orientation will be used for subproject scheduling and workpackage definition. Defining an optimal granularity of subprojects and workpackages will be an important consideration. An Optimizing Communication Structure. To support a flexible activity structure,
problems have to be split into pieces such that small, relatively autonomous groups can work on a subproblem from the problem statement (initial requirements) to a possible solution (code and test)!
Group size plays an important role with respect to flexibility and communication.In small teams, high levels of communication can easily be reached. Hence, groups of three to five are often considered as optimal (Hackman and Oldham, 1980). Gptimixing intra-team communication,one must not for&# inter-team communicationthough. Here, various role models, such as proposed by Schlemmer (1992) should channel the formation interchange needed in an adequate way. A further argument to be seen in this context stems from the application of modern software development methods. Notably object orientedness and reuse seem to call for flexible, knowledgable owners of modules which have an adequate potential to communicate with the rest of the organization. With large teams, knowledge would be spread too far to achieve this aim. With small teams, the following roles might be enacted to support determination for quality and well defined interfaces to the outside world: Primarily responsible for user interaction, requirements analysis, and design of a solution.
Primary
requirements
analyst
and
designer.
Improvement of the Software-Prccess _
67
Primary implementor. Primarily responsible for coding of the suggested solution, providing feedback and feedforward for design and requirements aspects. P&nary tester. Primarily responsible for testing, providing feedback to design and implementation.
If additidaal specialists‘ knowledge is needed, experts - who should form part of an infrastructure available for all control- and execution level aspects - can be consulted. By using experts as consultants for various projects rather than aligning them to a single project, synergy effects can be harnessed. Problem patterns tend to reoccur in projects and, thus, need not be solved separately in every project. As long as the execution-level team stays within the tolerances of schedule, budget, and solution domain, provided by the control level, there is no need for direct interference from outside. They can organize themselves according to the needs for solving the problem. However, if they move beyond tolerances the control-level has to take over control and define activities to remedy the situation. It is important to recognize that for optimizing communication it does not suffice to consider only the core development group. Shrug roles are customers, users, and other potentially affected groups. A process manager and a reuse manager working across all levels need to provide additional support, but would not be attached to any single project, On the control-level, we see such roles as system architect, integration and interface manager, review and test manager, and (sub-)project manager. Communication between these roles is primarily based on objectives (long and short-term), budget, schedule, risks, and progress in terms of effort yet to be expended, and compliance with plans (Schlemmer, 1992).
An Ideal Infrastructure.As basis of a sound process, an “ideal” infrastructure needs to cover all those elements of high process maturity described by Humphrey (1989)(i.e., a project management and commitment system, quality assurance - standards and enforcing procedures, configuration and change management, a process architecture and support group, comprehensive and effective process metrics, automated tools for gathering and analysis). In addition, need is given for a sound reuse concept with corresponding infrastructure support (procedures, a reuse repository, etc.). Further, mechanisms and support for dynamic process development and risk m~agement at con~l-levels will be needed to encounter for the increasing complexity of systems to be built. A major intangible aspect of the ideal infrastructure is human resource orientation by provision of adequate personnel assessment, career and education plans with ongoing training of staff, Thus, reuse can be more easily enhanced to the whole variety of implicit knowledge and a basis can be built for a reuse strategy beyond reuse of software including the huge amount of experience (cf. Rombach, 1992).
3 Stepping Towards the Ideal Currently, many software developers are far from what is considered to be ideal. Humphrey, focussing on process management aspects, Humphrey (1989) proposed a suite of five maturity levels as path to an ultimately optimizing organization. Here we briefly sketch a similar suite for the ACI-framework. In addition to aspects of process management, to be introduced stepwise within the three dimensions, we found at least two other aspects deserving proper attention: Introduction
of a sound
reuse
concept
along
with process
management,
68
R. T. Mittermeir and R. A. Schlemmer
incorporating reuse of software, knowledge about the process and methods (c,f Bornbach, 1992 - reuse of experience). The second aspect focusses attention on the kind of process to be ~~odu~d‘ Increasing complexity of systems to be built calls for the introduction of process models being able to evolve with increasing knowledge about the problem to be solved. Dynamic process development along with risk management an& increased flexibility as well as customer satisfaction (as described in section 2) will have ta be introduced in parallel with process management. Consequently, a strategy for process improvement needs to account for these concerns as well, presenting the responsible manager the whole effort to be taken and still encountering for the necessary detail by illumination of major improvement variables and uncovering their nexusus. The mapping of this multidimensional software process model along with an enhanced concept of matu~ty resulted in five steps (detailed by Schlemmer, 1992), which have been termed according to Humphrey’s So&ware Process Maturity Model (Humphrey, 1989). The five steps obey the following strategy: The line we conceptually follow, gradually stresses upstream tasks of software development, those to be performed prior to coding including items of process management, along with flexible and dynamic process development, and reuse. Whereas at the initial level developing organizations view software development as consisting primarily of (ad hoc) coding and testing, at a next stage emphasis needs to be put on tasks connected to analysis and design. To move to a repeatable level, infrastructure needs to provide tools and training in adequate methodolo~es and techniques for these tasks. The activity structure has to reflect these efforts with tasks appropriately fit into. Within the communication structure corresponding responsibilities and flow of itiormation for requirements analysis and design methodologies must be defined. Along with these steps, basic project management, quality assurance, configuration control (as postulated by Humphrey, 1989), and technology management need to be set in place. To move on to higher maturity (defined level), further details of tasks and roles connected to analysis, design, and project set-up need to be revealed. Tasks for slicing the problem into pieces need to be considered and built into the activity dimension. Thus, explicit handling of development in increments is possible for better handling of req~ements volat~ity and, thus, quality and cost (Boehm and Papaccio, 1988). Increased effort needs to be spent on the process, its explicit definition and later management calling for the institution of a process manager along with definition of tasks to be performed and objectives to be achieved supported by appropriate resources. The ability to reuse experience is fostered by institutionalizing it via artifacts in all three dimensions of the process as standards and quality assurance are already effective as a basis from the prior level. Starting with reuse of code at this third level is deemed lowest in resistance. Institutionalized reuse will explicitly be demanded with the managed process (fourth level) by introduction of a distinct responsibility for reuse efforts (definition of a sound reuse strategy, maintenance of a reuse repository, etc.). According to Humphrey (1989) also process metrics along with a data repository and analysis procedures for effective process control will be defined. Enhanced flexibility within the activity dimension is gained by following a spiral-like approach (Boehm, 1988). Along with explicit handling of risks it serves to meet the demands of changing context complexity. From a long-term perspective, this flexibility at the activity dimension can be buffered by orientation on an appropriate communication- and infrastructure. The final step to an optimizing process (see section 2) introduces the concept of control and execution levels. Problem orientation becomes the major organizing principle for
Improvement of the Software-Process
69
efforts performed by small interdisciplinary teams. Thus, a highly concurrent approach to problem solving is possible. This step is paired by a shift of paradigm from project orientation to process orientation and a focus on human resources to fully harness reuse of experience. technical
4 Results of a Process Readiness Survey Based on the idea of stepwise improvement of the process in such a multidimensional framework and the sketched ideal, we performed a series of expert interviews with leading Austrian (and two German) software producers’ to validate and improve our proposal and to assess their readiness to adopt these ideas. The findings are based on a sample of 15 interviews performed with experts having widespread experience in software development and its management. The interviewees have been selected in such a way as to cover a broad spectrum of institutions. Their size ranged from one very small company (approx. 20 employees) to a large one employing about 2000 software developers, with the bulk being in the 100 to 600 people break. Further, the primary field of activity was considered. It covered product development, product adaption and maintenance, as well as individual application development, and software R&D. It was finally smoothened by bringing in experts from university and consultants in the area of software development. Asked on the perceived importance of process models all interviewed parties were quite positive. Awareness for institutionalizing a defined process as a basis for improvement was shown. There were, however, subtle differences between given answers and effective usage of models. Some companies were able to present an enacted working process while others had to admit the existence of a gap between definition and usage of process models. While most organizations visited really try hard to apply their defined models, even among this selected group of reputable companies, about a third more or less “rests” on the model. They consider it rather as a marketing asset residing in a drawer than as an important means for higher productivity and quality which needs constant attention and improvement. Besides this slightly negative result, we gained the impression though, that process awareness and process orientation is increasing. Some organizations not only apply some model, but work on climbing up the process maturity scale. Others, especially rather small ones, do yet see a need for process orientation. However, willingness and orientation in terms of spending resources on it is rather low - short-term pressures out of the need to ship a product are deemed too important. As long as transparency of markets is low and customers do not question software engineering capabilities, many of them will hardly pay more than lip services on processes, especially on higher management levels. An amalgam of day-to-day time pressure and aspects of computing education seems to be responsible for these effects. A second issue addressed in these interviews concerned the perceived need to move up to an optimizing process (level 5). The viewpont that the “ideal” level for their company would be below the optimizing process was taken especially among those interviewees, who currently were not working effectively on their process. They are rather more short-term oriented. Only delivery of the product is determining their efforts. It was not seen, that this might lead to paradoxes over time (Schlemmer, 1992). On the other hand, most organizations already working thoroughly on process improvement stated clearly the need to move on to a continually optimizing environment.
70
R. T. h4ittermeir and R. .4. Schlemmer
Further, from some interwiews we got the impression that the level of maturity could vary between projects. We doubt the validity of this view though, since notably the concepti introduced on higher levels extend over project boundaries and should, therefore encompass - at least in the medium term - the whole organization. Different perceptions of the urgency of focussing on the software process between in-house application developers and developers for an anonymous market might be more than statistical noise. But whether the processes to be enacted would just differ, or whether some may even in the long run remain sloppier than the others seems at least doubtful. 5 Conclusion From our small survey, we may conclude that the state of software process maturity, as indicated by the SE1 model or by the AC1 framework is rather low (average between levels 2 and 3), but knowledge is existing and awareness is increasing. Focussing on three dimensions - activity, communication, and infrastructure - when considering software process improvement has been generally acclaimed from the practitioners interviewed. Splitting between these dimensiones would allow companies to enact software processes which would be “tailor made” to their organization. The five levels indicated as prescriptions for setting priorities in process improvement have been considered with interest, however, not all interviewees acknowledged the need to follow them up to the ultimate level. Explixitely addressing software reuse and flexibility characteristics as aspects of process maturity got positive reactions notably from those interviewees which “commanded” already a rather mature software process.
References Boehm B.W. (1988). A spiral model of software development and enhancement. IEEE Computer 21 (5). Boehm B.W., Papa&o P.N. (1988). Understanding and Controlling Software Costs. IEEE Transactions on Software Engineering. October. Hackman R.J., Oldham G.R. (1980). Work Redesign. Addison-Wesley. Humphrey W.S. (1989). Managing the Software Process. Addison-Wesley. New York. Mittermeir R.T. (1991). POWDER - Prototyping of Wicked Development Efforts with Reuse. Working paper, Klagenfurt. Rombach D.H. (1992). Reusablity Metrics. Proceedings of DEC College “Metriken 92”. Munich. January. Schlemmer R.A. (1992). Software Process Improvement. Thesis. University of Klagenfurt/Austria. Yeh R.T., Naumann D., Mittermeir R.T., Schlemmer R.A., Gilmore W., Sumrall G., LeBaron J. (1991a). A Commonsense Management Model for Systems. IEEE November. Softutare, Yeh R.T., Schlemmer R.A., Mittermeir R.T. (1991b). A Systemic Approach to Process Modelling. International Journal of Systems Integration. Vol l/2.
0066-41381921915.00 0 1992 Pergamoo Press Ltd
STEPWISE IMPROVEMENT OF THE SOFTWARE-PROCESS IN A MULTIDIMENSIONAL FRAMEWORK R. T. Mittermeir and R. A. Schlemmer Imtitutfiir h#hmatik der Univetsitit Kkagtnjiui, Universititsst@e
65-67, A-9022 Ulagenfurt, Germany
Abstract So&ware process models, irrespective of whether they are life cycle oriented or not, focus strictly on the activity domain within a single project. This focus is heavily challenged by COSMOS, a multidimensionalso&wareprocess model. In additionto the activitystructure,it takes into account also the communication-and infrastructurein which sofiware developmenttakes place. This threedimensional framework meets special challenges due to incorporatiug sofiware reuse and object orientedness into large scale software production and it allows for adequate planning of various activities controlling sofiware developmentwhich are not directly attributableto a specificproject, but which might run in parallel to a host of projects. This paper reports on investigations concerning the mapping of this multidimensionalsoftware developmentmodel on a software process maturity scale, analog to the one proposed by Humphrey (1989). Keywords
Software process, ACI (activity-, communicationand infrastructure),control-andexecutionlevels, reuse, long-term aspects, process maturity model.
1 Motivation “Every kid can write a program? Why so much ado about software processes? After all, we know by now, that the classical waterfall like, d~ent driven approach to develop software does not work well anyway! We develop our software by prototyping based on experience!” This, or similar arguments can quite often be heard as excuse, when project managers fail to pay adequate attention to the software development process in their or~a~on, But are they to be blamed? Software process prescriptions do indeed share some serious deficiencies - ranging from the claim of undiscriminated applicability to the lack of actually accomodating the specific difficulties one encounters in almost any real project. Quite a lot has changed, since software process models have been published for the first time. Let us look at some of it: _
Process models show a project view. This project view is fully adedquate, if all the work in an organization is focussed on but one project, or if several projects are carried out rather independently. Today, however, we see quite
R. T. Mittermeir and R. A. Schlemmer
64
often projects which extend over the boundaries of individual companies or development teams, while within software companies, one aims to execute projects in such a way that cross-vertilization and cross-utilization is maximized. Implications of the above perspective are not only that processes should extend projects as far as scope of work (their task structure) is concerned, but also from the perspective of project duration. Such a perspective is not so much driven by the fact, that maintenance becomes dominant over development from scratch (development teams and maintenance teams might differ; in some projects one might not even distinguish between maintenance and development) but from the explicit aim of our industry for software reuse, be it in development or in maintenance. A modern software process model would have to take care of the challenges stemming from the strive for reuse at all levels. _
Furtheron, one should pause for a brief reflection concerning the true nature of software. Classical process models focus on the “products” that are to be made during each step or phase, be they documents, specifications, test sequences, or executable code. However, if we carefully look at the trail of activities (including the backtracking involved with them in almost any project) we realize that software results from a complex communication process. Informal communication is frozen into specifications, specifications are made executable and finally transformed (formally or manually) into executable code, (hopefully) satisfizing what has been inadequately expressed at the very beginning of this communication process between users, managers, developers, and whoever might be involved in a complex project. Finally, we have to realize, that the root of project models has been in a time when compilers have been about the only software development tools. However, tools should influence the process as much as the process to be supported will have to influence the tools. Comparing the work and toolset of a shoemaker with the process and machinery of a modern shoe-factory might amply illustrate this fact.
In the light of these considerations, a software process model incorporating the key-factors of software production: - the activity structure - the communication structure _ the development infrastructure has been proposed (Yeh et al., 1991a). In this paper, we will report on the development of a strategy for growing in a stepwise fashion from whatever the current status of software production in a company might be to an ideal, optimizing level incorporating all three dimensions mentioned above. The paper is organized in the following way. We firstly give a brief introduction on the COSMOS process model which proposes an integrated view of activity-, communication-, and infrastructure. An ideal process will be described within these dimensions. Afterwards, a strategy of how to move towards this ideal will be sketched. Section 4 will present some findings on process readiness out a soft-validation of our concept.
Improvement of the Softwsre-ROC~SS
65
2 A Multidimensional Process Model
To capture the complexity of large software development efforts, additional handles are needed to address such aspects as the collaborativenature of the work involved, the evolution over time and the ~te~lations~~ to other, past, parallel, or future projects. In Yeh et al. (1991a,b) a framework, defined by activities, communication, and infrastructure (AC11 has been proposed. These three concepts serve as distinct but interrelated handles for software process modelling. Activities for developmentof a software system and project control are groupedinto tasks which need to be related to each other. Dependencies and ordering of corresponding elements are to be introduced, resulting in the following modelling artifacts: - Tasks and work products and - Ordering and dependencies among them Communication structure models the flow of itiormation and allocation of responsibilitiesamong all partiesinvolvedin a softwaredevelopmenteffort. Main elements used to capture these aspects are:
- Roles and res~nsibi~ties - Interconnecting communicationchannels - Communicationdependencies With infrastructum we refer to any tangible or intangible resources needed to carry out software projects. It comprises support for the activity aspect as well as support for the communication dimension. Activity related infrastructurecomprisesmethodologies,techniques,and tools for software development and project guidance. On the communicationaldimension, not only tangible aspects are to be considered. Reporting schemes, established procedures for prqject guidance, and standards count also as ~~t~ct~* Further, any investments in such intangibles as knowledge and skills of users and developers, supporting the problem solution or the improvement of the process itself, improve the infrastructure. While the significanceof the activity dimension is obvious, we want to stress that it would be futile to conduct projects in ignorance of the mat~ty of the ~rnrn~~tion structure or of in&u&ucture. On the other hand, neither of these dimensions improves on its own. It needs as focussed effort to improve on them as effort is needed to progress on the activity chain. All three dimensions can be developed to a certain maturity level. We sketch in the sequel what we consider as “ideal” for each of them. An Optimizing Activity Structure. The activity structure, ideally, needs to allow for
flexibility and dynamism.The process needs to bear the flexibilityof adaptingto changing context complexity and evolve along with increasing knowledge about the problem to be solved. Consequently, phases can no longer be viewed as static and separate as within wa~~~l-like approaches. Whenever possible, tasks - and not only those which are adjacent in the waterfall model - need to overlap or be executed in parallel. For coordinatingparallel or overlappingefforts and for balancingthe AC1dimensionsproperly, a process is split into two generic levels (Mittermeir, 1991; Yeh et al., 1991a): Cm&o1 level, Considering the limiting and reinforcing factors of each of the AC1 dimensions and their balance. This level deals with the rather nontechnical tasks of process and project management and coordinating subprojects. By its introduction, resources are explicitly devoted to tasks that are usually done as afterthoughtsand hardly get the needed attention,
R. T. Mittemei
66
and R. A. Schlemmer
Execution 1eveLPerformingpurely technical activitiesof systemsbuilding.
A process is developed recursively, starting with an an overall control level. It covers the following tasks (cf. ~t~~eir, 1991; Yeh et al., 1991a): <>
c> <> <> <> <> C> <>
Pie-project evaluation Conception of an overall solution strategy Risk management initiation Es~blis~ent and maintenance of activity, ammunition, infrastructure for the overall project Definition of subprojects Maintenance of interrelationshipsbetween subprojects Evaluation and integration of results from subprojects Evaluation of the overall result
and
At the execution level, either one of the “trivial” process models indicated by Mittermeir (1991), such as Waterfall, Prototyping, Buy-It, etc. is performed, or, if demanded by the complexityof the subtask, another, smallerscale control-/execution-levelbundle is invoked. However, the con~ptu~ starting point for all the activities of the team needs to be the customers/users problem and not only their stated requirements. To find out what users really need the development-teamsstart-off with the objectives to be achieved and with a first statement of the problem. Continuous refinement of the solution follows till an acceptableproblem solution (by all relevant customer groups accepted)is reached (cf. Yeh et al., 1991a). Hence, these tasks are not defined as distinct phases, but form highly parallel and overlapping building blocks of systems development. Therefore, phases can no longer be used as the major organizing principle at the execution level. There, problem orientation will be used for subproject scheduling and workpackage definition. Defining an optimal granularity of subprojects and workpackages will be an important consideration. An Optimizing Communication Structure. To support a flexible activity structure,
problems have to be split into pieces such that small, relatively autonomous groups can work on a subproblem from the problem statement (initial requirements) to a possible solution (code and test)!
Group size plays an important role with respect to flexibility and communication.In small teams, high levels of communication can easily be reached. Hence, groups of three to five are often considered as optimal (Hackman and Oldham, 1980). Gptimixing intra-team communication,one must not for&# inter-team communicationthough. Here, various role models, such as proposed by Schlemmer (1992) should channel the formation interchange needed in an adequate way. A further argument to be seen in this context stems from the application of modern software development methods. Notably object orientedness and reuse seem to call for flexible, knowledgable owners of modules which have an adequate potential to communicate with the rest of the organization. With large teams, knowledge would be spread too far to achieve this aim. With small teams, the following roles might be enacted to support determination for quality and well defined interfaces to the outside world: Primarily responsible for user interaction, requirements analysis, and design of a solution.
Primary
requirements
analyst
and
designer.
Improvement of the Software-Prccess _
67
Primary implementor. Primarily responsible for coding of the suggested solution, providing feedback and feedforward for design and requirements aspects. P&nary tester. Primarily responsible for testing, providing feedback to design and implementation.
If additidaal specialists‘ knowledge is needed, experts - who should form part of an infrastructure available for all control- and execution level aspects - can be consulted. By using experts as consultants for various projects rather than aligning them to a single project, synergy effects can be harnessed. Problem patterns tend to reoccur in projects and, thus, need not be solved separately in every project. As long as the execution-level team stays within the tolerances of schedule, budget, and solution domain, provided by the control level, there is no need for direct interference from outside. They can organize themselves according to the needs for solving the problem. However, if they move beyond tolerances the control-level has to take over control and define activities to remedy the situation. It is important to recognize that for optimizing communication it does not suffice to consider only the core development group. Shrug roles are customers, users, and other potentially affected groups. A process manager and a reuse manager working across all levels need to provide additional support, but would not be attached to any single project, On the control-level, we see such roles as system architect, integration and interface manager, review and test manager, and (sub-)project manager. Communication between these roles is primarily based on objectives (long and short-term), budget, schedule, risks, and progress in terms of effort yet to be expended, and compliance with plans (Schlemmer, 1992).
An Ideal Infrastructure.As basis of a sound process, an “ideal” infrastructure needs to cover all those elements of high process maturity described by Humphrey (1989)(i.e., a project management and commitment system, quality assurance - standards and enforcing procedures, configuration and change management, a process architecture and support group, comprehensive and effective process metrics, automated tools for gathering and analysis). In addition, need is given for a sound reuse concept with corresponding infrastructure support (procedures, a reuse repository, etc.). Further, mechanisms and support for dynamic process development and risk m~agement at con~l-levels will be needed to encounter for the increasing complexity of systems to be built. A major intangible aspect of the ideal infrastructure is human resource orientation by provision of adequate personnel assessment, career and education plans with ongoing training of staff, Thus, reuse can be more easily enhanced to the whole variety of implicit knowledge and a basis can be built for a reuse strategy beyond reuse of software including the huge amount of experience (cf. Rombach, 1992).
3 Stepping Towards the Ideal Currently, many software developers are far from what is considered to be ideal. Humphrey, focussing on process management aspects, Humphrey (1989) proposed a suite of five maturity levels as path to an ultimately optimizing organization. Here we briefly sketch a similar suite for the ACI-framework. In addition to aspects of process management, to be introduced stepwise within the three dimensions, we found at least two other aspects deserving proper attention: Introduction
of a sound
reuse
concept
along
with process
management,
68
R. T. Mittermeir and R. A. Schlemmer
incorporating reuse of software, knowledge about the process and methods (c,f Bornbach, 1992 - reuse of experience). The second aspect focusses attention on the kind of process to be ~~odu~d‘ Increasing complexity of systems to be built calls for the introduction of process models being able to evolve with increasing knowledge about the problem to be solved. Dynamic process development along with risk management an& increased flexibility as well as customer satisfaction (as described in section 2) will have ta be introduced in parallel with process management. Consequently, a strategy for process improvement needs to account for these concerns as well, presenting the responsible manager the whole effort to be taken and still encountering for the necessary detail by illumination of major improvement variables and uncovering their nexusus. The mapping of this multidimensional software process model along with an enhanced concept of matu~ty resulted in five steps (detailed by Schlemmer, 1992), which have been termed according to Humphrey’s So&ware Process Maturity Model (Humphrey, 1989). The five steps obey the following strategy: The line we conceptually follow, gradually stresses upstream tasks of software development, those to be performed prior to coding including items of process management, along with flexible and dynamic process development, and reuse. Whereas at the initial level developing organizations view software development as consisting primarily of (ad hoc) coding and testing, at a next stage emphasis needs to be put on tasks connected to analysis and design. To move to a repeatable level, infrastructure needs to provide tools and training in adequate methodolo~es and techniques for these tasks. The activity structure has to reflect these efforts with tasks appropriately fit into. Within the communication structure corresponding responsibilities and flow of itiormation for requirements analysis and design methodologies must be defined. Along with these steps, basic project management, quality assurance, configuration control (as postulated by Humphrey, 1989), and technology management need to be set in place. To move on to higher maturity (defined level), further details of tasks and roles connected to analysis, design, and project set-up need to be revealed. Tasks for slicing the problem into pieces need to be considered and built into the activity dimension. Thus, explicit handling of development in increments is possible for better handling of req~ements volat~ity and, thus, quality and cost (Boehm and Papaccio, 1988). Increased effort needs to be spent on the process, its explicit definition and later management calling for the institution of a process manager along with definition of tasks to be performed and objectives to be achieved supported by appropriate resources. The ability to reuse experience is fostered by institutionalizing it via artifacts in all three dimensions of the process as standards and quality assurance are already effective as a basis from the prior level. Starting with reuse of code at this third level is deemed lowest in resistance. Institutionalized reuse will explicitly be demanded with the managed process (fourth level) by introduction of a distinct responsibility for reuse efforts (definition of a sound reuse strategy, maintenance of a reuse repository, etc.). According to Humphrey (1989) also process metrics along with a data repository and analysis procedures for effective process control will be defined. Enhanced flexibility within the activity dimension is gained by following a spiral-like approach (Boehm, 1988). Along with explicit handling of risks it serves to meet the demands of changing context complexity. From a long-term perspective, this flexibility at the activity dimension can be buffered by orientation on an appropriate communication- and infrastructure. The final step to an optimizing process (see section 2) introduces the concept of control and execution levels. Problem orientation becomes the major organizing principle for
Improvement of the Software-Process
69
efforts performed by small interdisciplinary teams. Thus, a highly concurrent approach to problem solving is possible. This step is paired by a shift of paradigm from project orientation to process orientation and a focus on human resources to fully harness reuse of experience. technical
4 Results of a Process Readiness Survey Based on the idea of stepwise improvement of the process in such a multidimensional framework and the sketched ideal, we performed a series of expert interviews with leading Austrian (and two German) software producers’ to validate and improve our proposal and to assess their readiness to adopt these ideas. The findings are based on a sample of 15 interviews performed with experts having widespread experience in software development and its management. The interviewees have been selected in such a way as to cover a broad spectrum of institutions. Their size ranged from one very small company (approx. 20 employees) to a large one employing about 2000 software developers, with the bulk being in the 100 to 600 people break. Further, the primary field of activity was considered. It covered product development, product adaption and maintenance, as well as individual application development, and software R&D. It was finally smoothened by bringing in experts from university and consultants in the area of software development. Asked on the perceived importance of process models all interviewed parties were quite positive. Awareness for institutionalizing a defined process as a basis for improvement was shown. There were, however, subtle differences between given answers and effective usage of models. Some companies were able to present an enacted working process while others had to admit the existence of a gap between definition and usage of process models. While most organizations visited really try hard to apply their defined models, even among this selected group of reputable companies, about a third more or less “rests” on the model. They consider it rather as a marketing asset residing in a drawer than as an important means for higher productivity and quality which needs constant attention and improvement. Besides this slightly negative result, we gained the impression though, that process awareness and process orientation is increasing. Some organizations not only apply some model, but work on climbing up the process maturity scale. Others, especially rather small ones, do yet see a need for process orientation. However, willingness and orientation in terms of spending resources on it is rather low - short-term pressures out of the need to ship a product are deemed too important. As long as transparency of markets is low and customers do not question software engineering capabilities, many of them will hardly pay more than lip services on processes, especially on higher management levels. An amalgam of day-to-day time pressure and aspects of computing education seems to be responsible for these effects. A second issue addressed in these interviews concerned the perceived need to move up to an optimizing process (level 5). The viewpont that the “ideal” level for their company would be below the optimizing process was taken especially among those interviewees, who currently were not working effectively on their process. They are rather more short-term oriented. Only delivery of the product is determining their efforts. It was not seen, that this might lead to paradoxes over time (Schlemmer, 1992). On the other hand, most organizations already working thoroughly on process improvement stated clearly the need to move on to a continually optimizing environment.
70
R. T. h4ittermeir and R. .4. Schlemmer
Further, from some interwiews we got the impression that the level of maturity could vary between projects. We doubt the validity of this view though, since notably the concepti introduced on higher levels extend over project boundaries and should, therefore encompass - at least in the medium term - the whole organization. Different perceptions of the urgency of focussing on the software process between in-house application developers and developers for an anonymous market might be more than statistical noise. But whether the processes to be enacted would just differ, or whether some may even in the long run remain sloppier than the others seems at least doubtful. 5 Conclusion From our small survey, we may conclude that the state of software process maturity, as indicated by the SE1 model or by the AC1 framework is rather low (average between levels 2 and 3), but knowledge is existing and awareness is increasing. Focussing on three dimensions - activity, communication, and infrastructure - when considering software process improvement has been generally acclaimed from the practitioners interviewed. Splitting between these dimensiones would allow companies to enact software processes which would be “tailor made” to their organization. The five levels indicated as prescriptions for setting priorities in process improvement have been considered with interest, however, not all interviewees acknowledged the need to follow them up to the ultimate level. Explixitely addressing software reuse and flexibility characteristics as aspects of process maturity got positive reactions notably from those interviewees which “commanded” already a rather mature software process.
References Boehm B.W. (1988). A spiral model of software development and enhancement. IEEE Computer 21 (5). Boehm B.W., Papa&o P.N. (1988). Understanding and Controlling Software Costs. IEEE Transactions on Software Engineering. October. Hackman R.J., Oldham G.R. (1980). Work Redesign. Addison-Wesley. Humphrey W.S. (1989). Managing the Software Process. Addison-Wesley. New York. Mittermeir R.T. (1991). POWDER - Prototyping of Wicked Development Efforts with Reuse. Working paper, Klagenfurt. Rombach D.H. (1992). Reusablity Metrics. Proceedings of DEC College “Metriken 92”. Munich. January. Schlemmer R.A. (1992). Software Process Improvement. Thesis. University of Klagenfurt/Austria. Yeh R.T., Naumann D., Mittermeir R.T., Schlemmer R.A., Gilmore W., Sumrall G., LeBaron J. (1991a). A Commonsense Management Model for Systems. IEEE November. Softutare, Yeh R.T., Schlemmer R.A., Mittermeir R.T. (1991b). A Systemic Approach to Process Modelling. International Journal of Systems Integration. Vol l/2.