Integration Plan:
Software Development Methodology

Software Development Methodology

The software development methodology for the ECOSIM demonstrator development consists of three main elements:

• Procedure A step by step guide to the process for using the method for design and implementation.

• The Framework which refers to the set of available building blocks, the hardware and software environment used for the implementation.

• Evaluation criteria The metrics, measures and design rules that are used to evaluate the design and implementation created using the procedure.

• Notation and terminology providing a common, standard language and symbolism for the design and documentation process.

Project characteristics

Project characteristics of ECOSIM as a software development project can be summarized in four important dimensions, namely

1. project size,
2. application domain,
3. criticality, and
4. innovation.

The position of ECOSIM as a software development project (which covers just one, but certainly a central aspect of the entire project activities and objectives) is summarized in the Table below:

Project size

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,

Project domain

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.

Project criticality

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.

Project innovation

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.

Choice of Approach

The choice of approach for software development is based on the main characteristics of ECOSIM, which include:

• research orientation and a high degree of innovation,
• a heterogeneous and distributed development team,
• approximate initial user specifications from a diverse user group,
• a complex and ill-structured application domain, and
• the pre-competitive nature of the product.

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).

ISO 9000-3 Design and Implementation Guidelines

The requirements of ISO 9000-3 for software design are straight forward and rather general:

• The activities should be carried out in a disciplined manner.
• Input and output should be specified, and design rules and internal interface definitions should be examined.
• A systematic design methodology appropriate to the type of software being developed should be used (application specific methodology).
• Past design lessons learned should be used, and past mistakes avoided.
• Product design should facilitate testing, maintenance, and use.
• The product of the design phase should be subject to review.

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 activities should be carried out in a disciplined manner.
• Rules and standards (e.g., coding standards, language choice) should be specified and observed.
• Methods and tools should be appropriate to satisfy user requirements.
• The product of the coding phase should be subject to review.

ISO 9000-3 Compliance

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.