Century support part 2: How not to start

This guest article by Carsten Pitz is the second part on the subject of long-term support. In the first part Carsten describes the development of a documentation system. Although it was not initially conceived as such, it became clear over time that the system would have to be available for decades.

Enjoy reading the second part.

Lots of paper, no long-term support

Our original development approach was rather conservative: we documented the application architecture in detail, came up with conventions for design, development and quality assurance and, to top it all off, designed a roadmap. All this without any consideration of the project's lifespan. I'll come back to what this means for long-term support at the end.

The application architecture was documented in accordance with the NATO Architecture Framework version 3 (NAF v3). NAV v3 defines the views, the majority of which were implemented. Tayloring alone took five people almost half a year. In the process, we blacked out several hundred pages of paper.

For the conventions, we relied on established de facto standards recognized as best practices. The convention for the design was NAF v3, which we adapted, and the requirements management was to be carried out in accordance with IREB. The SUN Microsystems guidelines for Java coding and JavaDoc documentation were prescribed for development. Quality assurance was to be carried out in accordance with ISTQB. Since all these conventions were considered best practices, there were no complications in the coordination with our client. We presented, the customer nodded, no discussion.

As the conventions were seen as best practice, the client nodded to them without discussion. [tweetthis]As the conventions were seen as best practice, the client nodded to them without discussion[/tweetthis].

The roadmap was also a lot of work. Our client provided us with numerous studies from well-known consulting firms. We analyzed these and created a spreadsheet to carry out a statistical evaluation. We used this to sort out predictions that were only made by individuals or were controversial. We then drew up the roadmap based on the consensus that emerged.

The result

After the first version of the software was created on the basis of this work, there was a review in which everything was rated as acceptable except for the roadmap. It is understandable that the roadmap was not rated well, as many of the selected technologies had gone out of fashion in the fast-moving times. The waterfall-based process meant that we could no longer intervene to clarify things. And so the group dynamic took its course and the roadmap was overridden. Fortunately, the architecture remained intact.

Based on the conventions for requirements management (IREB) and quality assurance (ISTQB), our customer organized training measures including certifications. This has paid off. The standardized nomenclature in particular was a clear benefit.

Review from the present

100 years of life cycle: What do 4 generations mean? This question has not been considered. Accordingly, no answers have been given. We have tried to predict technical developments. And, like almost everyone before and since, we have failed.

We did not consider many issues. Nevertheless, the customer was satisfied. [tweetthis]We did not look at many issues. Nevertheless: The customer was satisfied[/tweetthis]

We also did not consider changes of a social nature. Nevertheless, the customer was satisfied. Yes, the client was extremely satisfied and later commissioned us again for similar tasks. But - at least from my current perspective - we did not fulfill the brief.

How is it better?

Once again, I will give you some time to answer this question. So thank you until next time!

Image: Bigstock