The impact of a new software development methodology and how to afford the changing resistance: the RESPECT experience
E. Cozzio
Federazione Trentina delle Cooperative Via Segantini, 10 - I-38100 Trento, Italy tel. +39 0461 898320, fax +39 0461 895431 e-mail: enrico.cozzio@ftcoop.itetc.
F. Calzolari
ITC-Irst, I-38050 Povo (Trento), Italy tel. +39 0461 314583, fax +39 0461 314591 e-mail: calzolar@irst.itc.it
Although experience in developing systems has shown that an inadequate understanding of system requirements is the single most important cause of user dissatisfaction and system failure, the software development process is often largely unformalised and it lacks of support for the early phases of requirements collecting and definition, especially in small companies.
Therefore the FTC (FTC stands for the Trentino Federation of Cooperatives) addresses this problem, providing a way to move from an informal and unsupported software development process to a more formal one, adopting new methodologies and applying suitable tools. The main technical objective of the Process Improvement Experiment RESPECT is to improve the requirements' specification and analysis phase by formalising the process of requirement capturing and by adopting a CASE tool to support this phase.
Unfortunately one may expect that moving from an informal development process to a more structured and formal one will add an overhead to the programmers' activities. However, from the business point of view the challenge is to measure the impact of process changes in order to assess that the new practice really improve products' quality, time to market and customer satisfaction at the price of some added burden for development activities.
This article summarises the first year experience with the RESPECT project and addresses the problem of measure the impact of the new development methodology and how FTC afforded the changing resistance in order to make the improvement really effective.
ICT support for the whole of FTC is provided by an internal software development team, the responsibilities of which span from software development to maintenance, from on site assistance to network support.
In recent years the FTC has identified a potential expansion of its overall activities from the captive market of the represented co-operatives to the external market. This poses a set of new challenges for the software development team, in particular regarding the way expectations of external customers are addressed.
This is primarily due to the fact that, as it happens with many small companies, FTC’ software development process is largely informal and deadline driven. In this context, the capture of user requirements is usually done in an ad hoc and often imprecise fashion, with the assumption that the real expectations will be clarified along the way through informal progress meetings. This has proven wrong in several occasions and is one of the long-standing identified weaknesses of FTC’ development process.
In the awe of the business expansion for FTC, the software development team has the opportunity as well as the duty to address the issue in a systematic fashion. FTC’ software development team has therefore initiated an improvement programme for the entire software development process, starting from the requirement specification and analysis phases.
The RESPECT project represents the starting point of this programme. The aim of the experiment is to implement a new requirement specifications process supported by automatic tools, and to show that improvements in the requirements specifications process enable FTC’ software staff to decrease the overall development effort and increase software quality.
If the experiment will be successfully completed, two primary objectives should be reached:
Although the software process has not yet been formalised nor has a standard methodology been defined to describe the nature of each phase and the documents and artefacts to be produced, some efforts toward adopting a more formal development process have already been made:
The PROUD project is a pilot project, performed before transferring main results and the same experience to other market fields. In particular, agricultural co-operatives, social co-operatives, and production co-operatives will be involved in the next step, thus being the natural candidates for adoption of the same solutions, experimented during the PROUD project.
The project is nevertheless a real production project. A complete system to support the commercialisation, direct retailing and consumer loyalty is going to be developed. Two of the components of the entire system will be the "Fidelity card management software" and the "Sales data warehousing".
The completion of the PROUD project is planned to require about 800 person/days. Several companies are involved in the baseline project with different roles: two external companies, will develop some of the software components. Within the scope of the PROUD project, the FTC itself behaves as a client for the PICO project (Progetti d’Innovazione tramite la Cooperazione – Innovation Projects through the co-operation), a project focused on financial auditing.
From an operational standpoint, the RESPECT project is expected to have a twofold impact on the customer-supplier interaction. On the one hand it is expected to rationalise the definition of the needed software product characteristics, for the benefits of the software developers. On the other hand, since customers tend to provide imprecise descriptions of their real requirements, it is expected to facilitate customers in describing their final expectations earlier on in the prototyping phase.
Most importantly, from an organisational standpoint, the RESPECT project is expected to help overcome the resistance encountered during the introduction of the new methodologies, a problem which has been all too frequent in the past. In particular, past experience in adapting solutions to the FTC environment is being used to reduce the resistance to change and to minimise the overhead that the adoption of the new methodology introduces.
Finally, RESPECT is expected to enhance the software-related documentation. Currently the two selected components of the baseline project are the first ones in the several years FTC software development experience provided by requirements related formal documents. Until now, it is the very first time that informal verbose descriptions are substituted by a structured document, compliant with general requirement standards.
The basic approach is that after a training session in the new methodology and tools, an existing development team is employing the new techniques in the baseline project, comparing them against their own past experiences with a traditional methodology (i.e., comparing the situation with the existing development process).
As most EEC-funded projects, the work plan for RESPECT is divided into several work-packages. The most significant ones, from an implementation point of view are WP2 – Tools acquisition and Integration, WP4 – Training, WP5 – Experimentation, and WP6 – Analysis and Consolidation of results.
Fig. E.C. 1: The RESPECT Project Gannt
Although WP2 is not directly related to the organisational and business objectives, it is nevertheless an integral part of the implementation as it makes use of a methodology for tool selection (DESMET) that has been particularly important in leading the project staff towards a structured approach to requirements definition. The influence of adopting such a methodology is pervasive across the project – this is a positive side effect of its use. However, since it primarily relates to technical objectives, the results of WP2 are not presented in this article for brevity reasons.
The measured results and the lessons learned so far
At the time of writing, the analysis and consolidation of results (WP6) has not taken place yet and therefore only informal results can be presented. However, based on the feedback from the activities in WP4 and WP5, it is already clear that several results are being achieved in line with the expectations. The points worth noticing are presented below.
The adoption of a couple of tools (Rational RequisitePro and IBM Visual Age) supporting the requirements definition phase and the analysis and design phase, has proven to provide an effective means for the development early phases. The availability of a company database containing previous projects requirements and designs is facilitating reuse, thus reinforcing the expectation for a shorter time to market for future applications.
The new analysis phase supports a more natural partitioning of a complex system into smaller components, easier to be managed. This results in a better application definition in the design phase according to customer expectations, rather from later arbitrary design choices.
By improving clarity of the communication channel back to the user, the perceived quality of the product is improved by making an impact on customer satisfaction earlier. That is, the user can see from the clear representation of his expectations whether the system will satisfy the needs (rather than vaguely suspecting that they satisfy the need, but awaiting a completed prototype to verify the suspicion). In such cases, where multiple contracts may be under consideration simultaneously, the improved user satisfaction earlier in one contract may be the triggering event to facilitate the choice.
The total business volume for FTC’ software development team is increasing, thanks also to improved customers' confidence in the quality of requirements definition.
More in general, a better defined and more structured development process is leading FTC to define roles and responsibilities more precisely, thus improving the structure of the organisation.
From another point of view, having identified a defined requirements responsibility, FTC is forced to carefully planning and scheduling of the ongoing projects, thus supporting a better defined development process.
Staff also feel that the most part of these benefits will be probably available after that a number of projects will be completed, providing feedback and support for reuse. Until then, the introduction of the new methodologies risks to be perceived to increase the "project bureaucracy".
However FTC people feel that the project is perceived as the necessary first step to define a more formal development process.
People involved in RESPECT are gaining new skills and knowledge about several different fields and methodologies. For example FTC staff learned how to use the DESMET methodology for tool selection. After this experience, they applied the same methodology to screen and select other ones, choosing the best suited for a certain task.
Fig. E.C. 2: How DESMET is used by FTC
The impact is clearly evident at FTC and it is expected that the analysis to be conducted in WP6 will reinforce these findings. To conclude, however, a few considerations can be made regarding resistance to change.
All in all, FTC’ experience is that methodologies need to be explained and adapted to be useful in practice. In particular, FTC developers have been trained about software engineering fundamentals. Only after the training sessions it has been possible to define general guidelines for the requirements definition phase. This is one of the main learned lessons. Training is one of the most important factors to overcome resistance to change.
Equally, the newly introduced tools have been used to define not only requirements and classes structure for a specific project, but for the whole of future FTC developments. A database of requirements has been established, that, although it is based on a few projects, already contains a number of requirements and use-cases defining typical interactions with the system. Another lesson is therefore that thinking ahead for reuse can really make a difference in the way the requirements are captured. In turn, facilitating reuse makes it easier to win developers acceptance of the new methods.
Managing Director of Ufficio della Cooperazione di Consumo Trentina, a department of Federazione Trentina delle Cooperative.
This department deals with accounting and auditing, and also offers financial and administrative help, together with organisation and planning strategies to retail co-operatives (Famiglia Cooperativa scrl) and their consortium (Sait scrl), in the province of Trento (Italy).
Dr. Francesco Calzolari - ITC - Irst, Povo (TN), Italy.
Francesco Calzolari received his Laurea degree cum laude in Computer Science from the University of Pisa, Italy, in 1991, with a thesis in the field of Fault Tolerance, and his Ph. D. in Informatics Engineering from the Politecnico of Milan, Italy, in 1996, with a thesis about Timed Petri Nets and Real Time Systems.
In 1997 he joined the Software Engineering group at the Istituto per la Ricerca Scientifica e Tecnologica (IRST), Trento, Italy. He was involved in the researches about dynamic models for software maintenance and testing.
Actually he is member of the STAR Project team (Maintenance of Software Systems) at IRST, and his current research interests include software engineering, dynamic models and reverse engineering.
The Trentino Region.
The Autonomous Province of Trento is situated in northern Italy, in the Alps, with a population of 464,000 inhabitants over a mostly mountainous area of 6,207 km sq/.
Out of 223 council towns, only 5 have over 10,000 inhabitants, and they assimilate 38.9% of the population.
Trento, the capital of the region has over 100,000 inhabitants and the town of Rovereto 33,000 inhabitants, both of which are situated in the valley of the river Adige.
The Co-operative Movement in Trentino.
The Cooperative Movement in Trentino was born at the end of the last century, based upon the economic theories of Friedrich Wilhelm Raiffeisen.
The Trentino area was a fertile breeding ground for the development of these ideas, whether due to the culture of the population or to the favourable administration, ever since its recognised origins, (in that which was a province of the old Austro-Hungarian Empire), thus so today under the administrative bodies of the Autonomous Province of Trento and the Region Trentino Alto Adige/Süd Tirol.
The Coop. Movement, within Trentino culture, is the economic consequence of the spirit of associationism, of voluntary work, of good will and the capacity to "do things together", in essence, of the culture of self -government and self-management deeply rooted in this Land and tangible in everyday life.
Therefore, Trentino is a land of consolidated co-operation, so much so that out of 464,000 inhabitants more than 160,000 are co-operative associates (100,000 not counting double or triple subscribers) which traditionally operate in the following sectors.
The Trentino Co-operative Movement is assisted, co-ordinated, guided and controlled by the Federazione Trentina delle Cooperative (Trentino Federation of Co-operatives), a consortium amongst all the co-operatives of the province and their consortiums.
It is precisely the guidance and co-ordination of the Federation which confers upon the Movement of Co-operatives the combining power of the system and the claims of the economic model, according to the ideology which inspired Raiffeisen.
The Co-operative Movement in Trentino employs 7,788 permanent staff and 2,752 for seasonal work.
ITC - IRST
ITC-Irst, the RESPECT subcontractor, is a public research institute whose activities include software engineering and maintenance. ITC - Irst holds a solid background in software engineering issues, especially in object-Oriented modelling, effort estimation, static and dynamic code analysis as well as in software metrics. Several tens of articles presented at international conferences or published by scientific journals the impact of such activities on the scientific community.
Within the RESPECT project, ITC - Irst co-operates with the FTC for scientific and methodological aspects, supporting activities regarding tool selection, customisation and training, implementation as well as requirement process and guidelines definition.