In building the IPSI system we had to recognize that the implementation of a portal system is an integration engineering task. This had an important impact onto the software process deployed. Backend integration is based on middleware, frontend integration is based on a commonly used user interface which called for careful design.

Most requirements for IPSI were fulfilled by integrating standard tools. In order to effectively plan the software process for building IPSI, it was crucial to use prototypes (compare above). Only after implementing these prototypes we were able to assess the feasibilty of the architecture and only then we were able to calculate duration of the tasks identified and efforts needed for these tasks. The productive use of IPSI showed that the openness of the architecture is a crucial issue. Many further legacy systems had to be added after the initial release, standard tools were exchanged for individual customers. All these modifications depend on a clear and modular architecture. With hindsight, it would have been useful to develop IPSI as a component-based system on the basis of a standard component model like JavaBeans or COM.

Summing this up, the effort for implementing was lower than initially expected, simply because we were able to benefit from standard tools. The kind of tasks was different from what was initially planned, more tasks than initially planned were integration tasks. In the end only a few thousand lines of code were written, but this software was used as glue between existing systems and therefore required extremely detailed design and careful testing.

< Realization | References >