PASS (Pay-roll Accounting and Settlement System)
|This project is carried out with the financial support of the European Union under the European Systems and Software Initiative (ESSI).||EP Number 21223|
Key LessonsThis section summarizes the key lessons we have learnt from undertaking the experiment.
Technological Point-of-viewOne of the fundamental principles of the BOOTSTRAP software process improvement methodology is that before any investments are made in technology, the methodological questions on how to build solutions have to be answered, the methodological solutions to be institutionalized have to gain organizational acceptance and be compatible with the existing or improved processes of the organization.
This principle conforms to the philosophy promulgated by Watts Humphrey in his inseminating work on Managing the Software Process where he writes the following:
"They are thus prone to embrace some magic technological "silver bullet" that will painlessly solve all their problems. While technology is important and is the long-term key to improving the software process, it is rarely of much help in solving problems that are not precisely understood. Since most people object to having someone else's solutions to undefined problems imposed on them, the unplanned introduction of technology generally causes resistance to change."
The above BOOTSTRAP priorities are usually summarized by the following formula:
where O stands for Organization, M stands for Methodology, and T stands for Technology.
Armed with all the above wisdom, we still fell in a double trap. Since there was a budget allocated in the project for buying a tool, we wiped out our wisdom and carefully selected the LBMS tool before institutionalizing the necessary processes. Then, with the tool at hand, we could not wait plunging into learning it, expecting that it would provide us ready-made solutions for all of our problems. Nevertheless, we had to realize the facts of life quickly. Not all of the necessary processes were readily usable in our case in LBMS.
At this point, remembering the wisdom, we returned to defining both the planning and review processes independently from the tool. On the one hand, this approach proved well to be necessary for the review scenario. On the other hand, we also invested a lot of work into the planning scenario until we discovered that in this case, the model coming with LBMS was actually fully applicable. This is the point where we came to appreciate that LBMS was not simply a tool but also an experience library to which the above wisdom does not directly apply.
The lessons from the above experience are the following:
where L stands for Library of experiences or templates. The importance of
the extension lies in the fact that the cornerstone of the model is still O
while the so called tools include L, M, and T.
Strengths and weaknesses of the experimentThe main strength of the experiment is that most of the weaknesses could be corrected. Due to the strong project monitoring, the need for corrective actions was recognized in time (at the closure of the first stage).
Further lessons derived from recognized and corrected weaknesses are summarized below.
The quality system and the scenario development were running in parallel, however at the beginning no links were taken into account. A quality system consists of the Quality Manual, Procedures, and detailed Working Instructions for the procedures. The scenarios should have been aligned with the Procedures and Working Instructions in the Quality Manual, or at least there should have been a mapping.
The introduction of a scenario was done following a predefined series of steps. There was however a misunderstanding of the "use" step. MemoLuX gave the subcontractor the task to try out the scenarios in ways like "use the planning scenario to plan the development of scenarios", or "use the review scenario to review the review scenario"" instead of "use the review scenario to review the customer requirements in the baseline project".
In order to overcoming such misunderstandings derived from missing interaction between the early stages of the PIE and baseline projects, a software circle had to be created, consisting of the experts and the staff that in future would have to work with the results produced by experts. The software circle had a meeting every two weeks for 2 hours. The result of each step was presented to this circle, opinions were discussed, and feedback was recorded. Without this complementary action, it is questionable whether the results (new workflows) would have ever been accepted by the staff.
Back to the PASS main page
I.S.C.N. International Software Consulting Network
Tel: +353 1 286 1583, Fax: +353 1 286 5078