EuroSPI 2000

Practical and innovation based software process improvement to prepare for the new millenium.

European Software Process Improvement Danish Experience in SPI

Category Index

Rated Newspaper Supported by EU Project

Abstract

Our process improvement experiment provided some key lessons learned especially applicable to small software development organisations. Standard process frameworks (e.g. DSDM) must be tailored and detailed to the specific needs of the organisation. SPI management is a difficult discipline, and internal and external communication is very important. SPI does require resources, but the benefits exceed the costs and payback starts immediately.

We have implemented a DSDM (Dynamic Systems Development Method) inspired, RAD (Rapid Application Development) based process involving close interaction with the customer throughout the development process. We developed the process and the necessary document templates to support the project team through a RAD project. We also improved our requirements analysis process and developed requirements specification documents supported by visual elements such as user interface designs in order to facilitate the discussions with the users before starting the programming.

The resulting development process showed significant improvements with increased customer satisfaction, reduction of the often very large workload peaks at delivery milestones by 50%, and elimination of the need for overtime payments through a general reduction of 30% in the number of hours exceeding normal working hours.
 
 

Introduction

Bruhn NewTech has developed professional software for mission critical operations since 1987. Main products are various NBC (Nuclear, Biological and Chemical) warning and reporting systems marketed and sold internationally to military organisations within NATO.
Currently USA, England and Denmark are using our NBC warning and reporting system within all services nation wide.
 

This Software Process Improvement (SPI) experiment is part of the ESSI programme (ESSI PIE No. 27599). It was carried out in the periods from AUG 1998 to JAN 2000.
 
 

Starting scenario

The plans and the expected outcome

Implementation of RAD, to the software process should ensure close co-operation with the users ensuring immediate feedback and thereby correct functionality of the released products, an essential element in the development of competitive products.

The expected improvements compared to previous reference projects were as follows:

• 30% reduction in change request in a period of 3 months after release.
• 30% reduction of requirements related errors encountered in the final system tests
• 20% reduction in the costs of producing project documentation
• All in all a substantially lower development effort and costs, without compromising productivity.

1.1 Limitations

• Project Management
• Requirements Management
• Design
• Implementation
• Test
• Etc.

1.2 Baseline projects

Baseline Project 1 (BP1)
Content : Adding minor customer specific requirements to an existing COTS Product
Team : 1 Project Manager & 5 Software developers
Duration : 5 Months

Baseline Project 2 (BP2)
Content : Developing a component to be embedded within a larger system
Team : 1 Project Manager & 2 Software developers
Duration : 5 Months

Baseline Project 3 (BP3)
Content : Adding a specialised module to an existing COTS Product
Team : 1 Project Manager & 6 Software developers
Duration : 4 Months

Implementation

1.3 Project organisation: Roles and Responsibilities

1.4 Timebox

In our baseline projects, the length of the time boxes varies from 4 hours to 6 weeks depending of the task. The various requirements was usually time boxed with a duration between a few hours and up to a maximum of 2 weeks, however the project phases covering a prototype cycle was also handled as a timebox, and the duration for these was up to 6 weeks.

In the first baseline project the priorities of the requirements was not documented in writing but agreed upon between the developer and the customer directly whenever needed. In the second and third baseline project the requirements were all prioritised and this was documented as part of the requirement specification.

1.5 Requirement management

Visual elements in the Software Requirement Specification
The Requirement management process was enhanced, due to the drawings of screen layouts in the SRS (Software Requirement Specification). These simple drawings (see: Fig. PGN.2) in the SRS have shown tremendous benefit when discussing new functionality with the customer, especially in cases where it was not possible to meet face to face.

Priorities
Another improvement of the Requirement management process was the implementation of documented prioritisation in the SRS. The following priorities were used:

User involvement & Prototype meetings
The user involvement was done through a continuous dialog between the development team and the user representative. It was not possible to have the user integrated in the development team, however when new functionality was implemented to a certain "prototype" level, the program was demonstrated for the user, and the comments from these prototype meetings where documented and then evaluated and prioritised together with the remaining requirements.

These prototype meetings ensure that problems regarding unclear or inconsistent requirements are resolved up front rather than late in the project.
 

1.6 VDM

The work with VDM to supplement the requirements was not an immediate success. Although VDM is a strong tool, we observed little benefit in this particular experiment. The reason for this was primarily that BP2 turned out not to be well-suited for VDM-specification integration, but also, that we do not possess the critical mass of VDM expertise to implement and sustain VDM use within our organisation at this stage. Based on this we decided not to pursue VDM further in this experiment.
 
 

Result

1.7 Quantitative measurements

Objective: 20% reduction in the costs of producing project documentation
We can see now that the initial objective of reducing the documentation effort with 20% can not be achieved. We are developing more documents in order to support both the project management and the requirements management processes for our software development projects. We have developed new document types and significantly changed others in order to support the RAD principles employed in the resulting process. It is however the general feeling that the documentation produced now is necessary and adds value to the process, whereas it used to be regarded as a necessary evil with no particular purpose.

Objective: All in all a substantially lower development effort and costs is expected
Over the course of the development projects using the RAD principles implemented through RAMSES, we developed the feeling that we were more in control of the projects and of the development process, but when we examined the time registration data (see: Fig. PGN.3 below), we were quite surprised by the results.

We have reduced the workload peaks exceeding normal working hours at delivery milestones from 31% to 16 %, and the yearly average workload exceeding normal working hours from 18% to 12%.
As a very tangible benefit of the changes in overall workload, we have eliminated the need for overtime payments formerly used to manage the excessive peak workloads. We have previously needed overtime payment as compensation for peak working hours in conjunction with project deadlines. In 1998 we had an overtime payment comparable to the salary of 1½ software engineer, in 1999 we had no overtime payments at all.
We believe that the increased focus on user involvement, prioritised requirements and the timebox concept leads to better management of the customer expectations, and a better control over the entire project.
 

1.8 VDM

1.9 Qualitative measurements

Lessons learned

• One size does not fit all
• We have to modify the DSDM/RAD principles to suit our purpose. It requires a learning phase and small-scale experiments to derive suitable processes.
• The improvement effects arise from the tailoring of the processes rather than from adopting a general process model.
• Overall process models such as DSDM provide good inspiration, but they do not go to the level of detail required, to achieve real benefits. It is probably less significant which framework (DSDM, MSF (Microsoft Solution Framework) [4] or RUP (Rational Unified Process) [3], etc.) is chosen, if the process work captures the necessary details for the real processes.
• The customer representative
• Participation from the customer in a development project secures focus on the customer requirements, reduces "gold-plating", and gives a sense of ownership within the customer organisation, which increases the overall customer satisfaction.
• The customer representative can become a bottleneck for resolving requirement issues if the requirements are not thoroughly analysed and described to a reasonable level of detail before development starts. It is important that the customer organisation is aware of the need for rapid feedback and intensive interaction regarding the requirements.
• Software process improvement pays of.
• There is an immediate benefit from the analysis of the current status of the development process and the involvement of the development staff in process related activities.
• Participation adds to the motivation and creates a company culture that supports continuous improvement.
• By encouraging process improvement at all levels, it is possible to gain further operational efficiency from the knowledge and ideas of the employees regarding optimising the daily work routines, identifying bottlenecks and reducing time waste.
• Process improvement time must be scheduled explicitly in the resource plan
• Customer project activities will always have a higher priority than process improvement, but this conflict can be avoided by explicitly scheduling the process improvement activities, e.g. using a fixed weekday for these tasks.
• The external funding for process improvement secures top management acceptance and support for resource allocation.
• Reporting and dissemination activities are demanding and time consuming. They require dedicated resources and scheduled time.
• Organisational impact
• The process improvement experiment has served as a catalyst for starting an improvement culture. Through the work with the process improvement experiment it has become clear to everybody within the development department that it is possible to improve the processes, whereas earlier there was a lot of scepticism regarding the effectiveness of process improvement.
• The entire development group has been involved in RAMSES activities. This has increased the awareness of the process improvement activities and facilitated the implementation of the processes in the baseline projects although the processes were not fully described.

Problems encountered during the experiment

As other projects, SPI projects are vulnerable to the loss of key personnel. We suffered the loss of two key persons early in the project, and thereby lost a lot of project continuity and SPI experience. One was the intended project manager, and the other an experienced consultant at our main subcontractor. As replacement for the intended project manager, we decided to break down the overall project responsibility and divide it between three persons. One with technical responsibility, one with administrative and EU responsibility, and one with dissemination responsibility. All three were at the same time responsible for other projects or areas and at times heavily overloaded. The result was lack of focus on the tracking of the experiment, so it was not a good solution to the resource problem.

With the lack of experienced SPI management within the organisation, we found it difficult to take the conceptual ideas of our original project proposal and converting them into a proper SPI experiment plan with the proper means of tracking, documenting and reporting of the results of the experiment.

We did not have the necessary skills and experience required for developing the means of measuring and tracking the effect of the experiment on our quantitative goals of reduction in requirements related errors and change requests. We should have drawn more on external experience from subcontractors, EU, or ESSI peers in resolving some of our problems early on in the project. We should have used early dissemination activities to share our problems and learn from others.

We failed to properly communicate the effort and the plans for the process improvement experiments throughout the organisation in the start of the project, which left parts of the organisation with the feeling that there was no progress.
 
 

Summary

The objective of the proposed experiment was to improve the software development process by adopting a formal RAD (Rapid Application Development) method.

We expected a reduction in requirements related errors and change requests of 30%, we expected a reduction in documentation costs of 20% and anticipated a substantially lower development effort and cost.

We have implemented a DSDM (Dynamic System Development Method) [5] inspired, RAD based process involving close interaction with the customer throughout the development process. We customised and developed the process and the necessary document templates to support the project team through a RAD project. We also improved our requirement analysis process and developed requirements specification documents supported by visual elements such as user interface designs in order to facilitate the discussions with the users before starting the programming.

The resulting overall process improvements have led to a more controlled development process and verifiably to the achievement of one of our original goals. The improvements have reduced the often very large workload peaks at delivery milestones by 50%, and thereby eliminated the need for overtime payments.

The involvement of the customers has resulted in realistic expectations to the final product and consequently more satisfied customers. We have not been able to verify the effect of our improvements with respect to the objectives of reduction in the number of requirements related errors and change requests. We have made an initial analysis of the reference data in order to set up the necessary criteria, but lack of effective metrics and post-experiment data prevents us from drawing any conclusions.

Our process improvement experiment provided some key lessons learned especially applicable to small software development organisations.

• Standard process frameworks (e.g. DSDM) must be tailored and detailed to the specific needs of the organisation.
• SPI management is a difficult discipline, and internal and external communication is very important.
• We did not have the necessary skills and experience required for developing the means of measuring and tracking the effect of the experiment on our main quantitative goals.
• Measurements must be planned as part of the experiment, and it requires specific skills and knowledge.
• We should have drawn more on external experience from subcontractors, EU, or ESSI peers in resolving some of our problems early on in the project, using dissemination activities to share our problems and learn from others.

The improvements archived during the RAMSES project are now included in our development process and used on all development projects when applicable.
 
 

References

[2] FITZGERALD, J and LARSEN, P.G., Designing Software: a model based approach, Cambridge University Press 1997

[3] KRUCHTEN, P., The Ration Unified Process, An introduction, Addison-Wesley Pub Co. 2000

[4] MSF (Microsoft Solution Framework), http://www.microsoft.com/technet/Analpln/process.asp

[5] STAPLETON, J., DSDM the method in practice, DSDM Consortium 1997
 
 

Recommended reading

The following book is recommended for inspiration:

• STAPLETON, J., DSDM the method in practice, DSDM Consortium 1997 [5]

Bruhn NewTech - Company profile

An NBC environment exists if Weapons of Mass Destruction (WMD) have been used or there has been a release, accidental or otherwise, of toxic material. Bruhn NewTech develops and supports NBC information systems that provide military commanders and emergency planners with rapid and accurate information to enhance vital decision-making.

Bruhn NewTech has 15 years of experience in the development and use of information technologies for Nuclear, Biological and Chemical defence purposes and emergency response. This has lead to a range of products, projects and training support activities for military forces, civil defence and emergency response planners.

For more information: http://www.newtech.dk/

Peter Gungaard Nielsen
Project Manager
Bruhn NewTech A/S

Education:
 

Professional Summary:
More than 8 years of experience in software development including requirement specification, design, implementation and test.
Responsibilities include resource management, project management of development projects and co-ordination and implementation of process improvements.

Work Experience:
 

Svend Skafte
Systems Engineering Manager
Bruhn NewTech A/S

Education:
 

Professional Summary:
Mr. Svend Skafte has 10+ years of experience in software development, software integration, communication interfaces, software quality management and project management.
Responsibilities include requirements analysis, system design, programming, and program management (proposals, planning, organization, control and customer interface).

Work Experience:
 

Partners in EuroSPI

Editors

ISCN LTD, ISCN GesmbH, Schieszstattgasse 4/24, 8010 Graz, and Coordination Office, Florence House, 1 Florence Villas, Bray, Ireland, office@iscn.at, office@iscn.com, office@iscn.ie, Editing Done: 19.7.2002