|Project size||large to very large|
|Project domain||environment, real-time, DSS|
|Project criticality||medium to low|
|Project innovation||high to very high|
This not only measures the size of the resulting product in terms of lines of code or Megabytes of data, but primarily the complexity of the system, the number (and nature) of its main components, interactions, and, importantly, the size and composition (and location) of the development team. With a distributed and international development team with various levels of background (in formal software engineering projects), and the size and complexity of the main project components like the dynamic, 3D simulation models, a label of large to very large is justified,
Here we mean not only the domain of environmental management which is inherently complex and ill-structured, but also the characteristics in more technical terms: real-time (use of on-line information), interactive GUI (a necessary DSS feature), distributed (client/server architecture with both LAN and WAN elements), decision support objective. All these components involve major uncertainties (which are also reflected in the vague initial user specifications) that lead to the conclusion of an ill-structured problem domain.
As a system oriented to forecasting and decision support in an important domain that has demonstrated impacts on human health, ECOSIM project would be of high criticality. However, the time horizon and typical response times of forecasts are in the order of days and hours, not minutes and seconds (compare, for example, the typical time characteristics and response time requirements in a power plant control system or a flight traffic control system).
Also, model-based forecasts like those generated by ECOSIM are inherently uncertain. Their primary objectives is to explore a problem domain and help design and evaluate management alternatives, with the ultimate choice made by the human user, and not by the system automatically. This is equally true for the real-time forecasting of pollution levels, where the appropriate management response is decided and initiated by a human operator.
Finally, ECOSIM as a product should be pre-competitive, a demonstrator of concepts, ideas, and innovative approaches and solutions, but not a market-ready product. In summary, this leads to a criticality ranking of low to medium.
As a research project, that integrates a number of new and partly not yet proven (at least in the proposed integration) elements into a complex system, ECOSIM is of high innovativeness. The distributed nature, based on LAN and WAN communication, on-line integration of HPCN and monitoring, complex 3D dynamic simulation, interactive GUI and GIS and multi media element, and finally multi-criteria DSS concepts all have exploratory element that lead to an innovation ranking of very high.
The choice of approach for software development is based on the main characteristics of ECOSIM, which include:
The basic software development methodology adopted for the ECOSIM demonstrator development and integration is rapid prototyping within an object oriented design and development methodology as described in Rumbaugh OMT (Rumbaugh et al., 1991).
Prototyping is preferably used as a development method in cases where the users find it difficult to explain what is required of the software in a sufficiently technical language to allow precise interpretation. While the User Requirements Analysis (see ECOSIM deliverable D0101) provides general and high-level guidelines, in particular on aspects of required (and also desirable but not essential) functionality, and describes application scenarios in some detail, it lacks the technical details that could be used as the basis for a more structured design approach (for example, object oriented design (OOD) methods such as Rumbaugh OMT, Booch, Shlaer-Mellor, Coad-Yourdon, or Martin-Odell).
While we will primarily use Rumbaugh OMT to guide the development methodology, we will adopt the terminology of Shlaer-Mellor for Objects, Classes, and Instances.
The basic approach foresees a sequence of prototyping cycles, starting from the initial user requirements, where each cycle is used as the basis for a refinement of the specifications and subsequent modification of the functionality and/or implementation. In this approach, prototype development is primarily seen as an information gathering approach to elicit more detailed functional specifications from the user group. The prototype provides the language for these refinements.
The important focus of the design process, which continues as concurrent engineering during the implementation phase in the prototyping cycles, is to ensure that the final system:
meets the functional specifications (support of scenario analysis and forecasting as specified in the initial users requirements document);
fits the runtime time and space constraints (better-than-real-time performance for forecasting);
can be implemented within the resource constraints (time, space, material, existing components, legacy software, people);
is designed with longevity and easy maintainability in mind (requirements of the exploitation plan).
The requirements of ISO 9000-3 for software design are straight forward and rather general:
While these requirements are easy enough to accept, they provide little or no practical guidance for the design process. The same is true for implementation, which in ISO 9000-3 clearly refers to coding (implementing the design) and producing a test-ready product:
The software development method and approach selected in ECOSIM for both the design and implementation phase, including the subsequent validation phase, is therefor in full compliance with the relevant ISO 9000-3 requirements.
As a much more comprehensive and detailed document, ESA PSS-05-0 Issue 2, February 1991, the ESA SOFTWARE ENGINEERING STANDARDS ISSUE 2 (The CEO's chosen Software Engineering Standard Document), Prepared by: ESA Board for Software Standardization and Control (BSSC), are consulted for detailed guidance.