OOM Procedures Manual

1. Purpose

The objectives of this document are to describe the Object Oriented Methodology (OOM) process structure and to detail the procedures involved in conducting OOM projects.

2. Scope 

The intended readers of this manual are the practitioners of OOM projects. This manual is structured according to the stages of the OOM process. For each task in the OOM stages, the following information is documented :

• Objective
• Description
• Prerequisites
• Deliverables
• Guidelines
• Techniques
• Sub-tasks

For ease of reference, part of the contents are extracted from the full manual and summarized in the following sections.

3. OOM Overview

Object Oriented Methodology (OOM) is a system development approach encouraging and facilitating re-use of software components. With this methodology, a computer system can be developed on a component basis which enables the effective re-use of existing components and facilitates the sharing of its components by other systems. Through the adoption of OOM, higher productivity, lower maintenance cost and better quality can be achieved.

The OOM life cycle consists of six stages :

• Business planning;
• Business architecture definition;
• Technical architecture definition;
• Incremental delivery planning;
• Incremental design and build;
• Deployment.

3.1 Business Planning

The Business Planning stage is usually conducted through a series of meetings and workshops with the business management and business users. These meetings initiate the development process by establishing a mutual understanding of the objectives, scope, user requirements and assess the feasibility of the development project.

The tasks of the Business Planning are :

(a) Examine Current Environment and Define Objectives

By establishing the objectives of the system, project team members and business users can be well aware of the boundaries, scope and the associated costs and benefits of the project. By examining the findings in previous studies, current systems and business missions, the objectives of the business solutions are established in broad terms.

(b) Identify Overall Requirements

Functional requirements are functionality that the system will provide. They are documented in terms of Requirements Catalogue in a high level way as the detailed requirements will be expressed by Use Cases in later tasks.

(c) Model Business Processes

A Business Process Model (BPM) is developed jointly with the users. This model scopes the business area within which the proposed business solutions will be implemented and subsequently operate. User workshops with the business people that perform the business processes are used to discuss, understand and document the events and processes involved. The BPM will show the "to-be" process model. Any process re-design should be completed before the present task.

(d) Analyse Use Cases

In component and object-oriented development, the Use Case is the main driver for computer systems development. The processes described in BPM define the business system; they do not describe what is required of the computer system. There is however a link between the two and thus a process, usually Elementary Business Process (EBP), may be linked to a Use Case. This linking provides a level of traceability and structure to the development of the computer system.

The functional requirements of the business solutions are documented with Use Cases. Each Use Case describes a way in which the system can be used that will provide value to the user. Each functional requirement will be expressed as (or within) at least one Use Case. Use Case diagrams are drawn containing the system actors and Use Cases relevant to the business solutions.

(e) Model Initial Business Classes

This task is best started after the completion of Use Case modelling because in that task the domain knowledge of the analysts will have increased significantly.

Emphasis at this point needs to be on the basic Business Classes, i.e. classes that correspond to objects as these are of relevance in the domain. The assumption is that in general these classes will lead to a related entity in the data model and as such can serve as a basis for sizing. The data model may contain more entities, e.g. to realise many-to-many relationships, etc.

(f) Identify Reusable Components

This task is carried out together with the previous task. In this way it can be avoided that class modelling will be done for services that are already available from existing components. Determining reuse at this point is one of the cornerstones of component based development.

(g) Finalize Feasibility Study

This task is not required if a Combined Feasibility Study / System Analysis and Design Phase approach is taken. This task finalizes the Feasibility Study Report with an estimate of the cost and duration of the implementation effort. For database sizing purpose, a Required System Logical Data Model will be created by following the task "Map Business Classes to Entities" of Business Architecture Definition stage.

3.2 Business Architecture Definition

Business Architecture Definition focuses on gaining an increased understanding of the users' needs and defining a solution that will satisfy the needs.

System requirements as specified in the Use Cases will be analysed. The component services required to fulfil the system functionality will be identified. Component services will be realised by designing the detailed business classes and their collaboration within the components.

In order to gain advantage from component based development, services available from reusable components and the dependencies between them will be identified. Parallel to the above activities, prototypes of screens and reports will be made.

The tasks of the Business Architecture Definition are :

(a) Review Business Planning Deliverables

This task will be conducted if there are changes to the business requirements after the Business Planning stage. The potential change is usually dependent on the elapse time between the end of Business Planning stage and the start of Business Architecture Definition stage. This task is particularly important to those projects which have conducted Feasibility Study (or Business Planning stage) as a separate phase.

(b) Prototype User Interface

Screen prototypes are an excellent technique to validate the presentation and the associated data input/output of the Use Cases. Users are encouraged to involve such that the completed solution is mutually accepted. User workshops are an efficient mechanism to build prototypes.

(c) Identify Candidate Components

This is the task of defining the business architectural elements that the system comprises. The components identified are the logical business components for which component services will be defined.

The identification of components will be mainly dependent on the associations (static view) of the business classes. The candidate components will not be finalized at this stage since they need to be verified by interaction modelling (dynamic view) during later task.

(d) Model Component Interaction

Parallel to prototyping and after identifying candidate components, the interaction of Business Components are modelled. The component services defined are based on functionality of Use Cases.

This task will be carried out together with the task "Model Business Class Interaction". This is needed to provide more insight into the functionality of the components.

(e) Model Business Class Interaction

Objects interact to implement behaviour. Business Class Object Sequence Diagrams are constructed to define the operations of business classes. This interaction will enable the analyst to analyse the dynamic behaviour of the business classes. The modelling at this stage is mainly modelling inside the components.

(f) Map Business Classes to Entities

If an ODBMS (Object Database Management System) is to be used, there is a direct mapping between structures in the class model and the ODBMS structure. This is not true for relational databases. For example, they do not support inheritance structures. Relational tables also require primary and foreign keys, which are not supplied by the class model. If a RDBMS is used, an object to relational translation must be performed to produce the logical data model.

(g) Finalize Interaction Model

The two preceding tasks will have left the team with a wealth of Object Sequence Diagrams (OSDs). These OSDs have to be checked on completeness, consistency and level of detail before the model can be handed over to the Incremental Design and Build stage. Typically, more details may have to be added.

3.3 Technical Architecture Definition

The activities of the Technical Architecture Definition (TAD) will be executed in parallel to the Business Architecture Definition (BAD) stage. While BAD focus on the business requirements, the TAD stage focus on technology and architecture sides.

The tasks of the Technical Architecture Definition are:

(a) Identify Technical Requirements

As new business and technical requirements are identified, their impact on the existing systems infrastructure must be identified. Where no such infrastructure exists, the services that the infrastructure should provide have to be identified, analysed and implemented.

(b) Select Industry Standard Solutions

Applications built by an organisation may be unique from the point of view of business functionality, they typically are not from technical architectural point of view. One of the keys to success in application development is adopting industry standard solutions, frameworks and best practices where possible. Making the right choice involves comparing the technical requirements to the services provided by the architectural frameworks/solutions considered. Organization standards should be taken into consideration in the selection process.

(c) Describe Technical System Architecture

Technical System Architecture (TSA) defines the tools, environments and software solutions that support the application. For the developers to effectively work together tools must be selected to support all the different technologies needed to build the type of application in an integrated and consistent manner. This activity focuses on the matching of appropriate tools and platforms, which fit the technical requirements and organization standards.

(d) Define Technical Application Architecture

Before any design and build activity can take place, the minimum requirement is the setting up of reference model for analysts and developers to base their solution/component designs upon. Technical Application Architecture (TAA) defines how software is constructed by responsibilities and provides a clear separation between the layers in your system. These responsibilities within the architectural layers are termed "stereotypes" representing a name and purpose for the objects, or technologies, which implement the specific architectural responsibilities. It is also important to realise which techniques are to be used for different stereotypes (EJB, Servlets, JSP etc.) before going into implementation.

(e) Design Technical Services and Patterns

As not all of the technical requirements are handled by services provided by standard solutions during Technical System Architecture, it is necessary to design customised technical services to address the outstanding requirements and supporting the business components.

(f) Prototype Technical Architecture

This task encompasses a limited development project, which in structure will be equal to a Business Architecture Definition plus Design and Build cycle but with main difference that the "business" to be supported in this case consists of application software.

(g) Finalize Technical Architecture

The Technical Architecture needs to be finalized after receiving the sizing information and proof-of-concept review from the Business Architecture Team.

3.4 Incremental Delivery Planning

An increment delivers a number of complete Use Cases. Since each Use Case describes a way in which the system can be used, they can deliver value from the moment of deployment. Based on the prioritisation of Use Cases developed in the Business Planning stage, the most important Use Cases are delivered first.

The tasks of the Incremental Delivery Planning are :

(a) Define Increments and Implementation Strategy

Incremental delivery is planned by assigning Use Cases and the required components to the proposed increments. Decisions about the assignment of specific Use Cases to increments are made by assigning a delivery priority to each Use Case. The priority is derived primarily from the value to the business represented by the Use Case. Other factors such as complexity of the Use Case and dependencies between components should be taken into consideration.

(b) Finalize Systems Analysis and Design

This task finalizes the Systems Analysis and Design activities with the compilation of System Analysis and Design Report.

3.5 Incremental Design and Build

This stage will take the final deliverables of the Business Architecture Definition as its starting point. The components and their classes will be mapped onto the technical architecture from the Technical Architecture Definition and will subsequently be optimised for reasons of performance, maintainability etc.

The optimised classes will be realised using the class concept, provided as part of the programming language. The programs will be tested, accepted by users and made ready for deployment.

The tasks of the Incremental Design and Build Business are :

(a) Consolidate the Architectures

BAD looks at the problem domain and provides defined business components and component services to support the requirements. TAD looks at stereotypes and applicable technologies and provides a set of patterns and principles of use for components and software solutions for specific technical requirements.

(b) Design and Build Solution Process

There are two sides to the component-based development process and models, the Left Hand Side (Solution Process) and the Right Hand Side (Business Component).

The Left Hand Side is about building Use Cases, which is outside the Business Component. The Solution OSDs show the interactions on the left-hand side of the Process Controller. It involves identifying and adding User Classes (consistent with the User Interface Prototype), then building the User Interface objects and Control Objects such as Process and Interface Controller objects, and the usage of the Business Component interfaces. It also defines the transactional context.

(c) Design and Build Business Components

There are two sides to the component-based development process and models, the Left Hand Side (Solution Process) and the Right Hand Side (Business Component). The Right Hand Side is about building Business Components, which is inside the business component, on the right hand side of the Business Component Interface on an Object Sequence Diagram.

(d) Design and Build Data Services

There are the same benefits to "componentising" database access services as to "componentising" business services. It provides the capability to work to a static interface and therefore allows structural changes behind the interface without impact.

(e) Test Increment

The code created to implement the behaviour of the Use Case is tested to ensure that it executes correctly according to the specification given in the Use Case. The testing approach aligns with the general testing concepts.

3.6 Deployment

Incremental deployment could be adopted depending on the nature of the business, project constraints, and the benefits achievable.

The tasks of the Deployment are :

(a) Prepare User Training

Whether the training needs to be conducted for the system as a whole or per increment depends very much on how the increments are deployed.

If deployment is to be carried out for each increment, the first execution of the training will have to be done before the first increment's User Acceptance Test (UAT). During UAT, end users will have to operate the system and will have to accept the training material before the deployment of the increment.

Basically, training will need to be scheduled before the first deployment.The development of user training material can be regarded as a separate set of activities, carried out in parallel with the normal development (Design and Build).

(b) Conduct User Training

Training sessions are conducted to train future users of the new system on how it operates. The training is completed before each increment is rolled out. The training may include a train-the-trainers program if a large number of users have to be trained or permanent training is required.

(c) Perform Data Conversion

Data necessary for the operation of the new system is converted from existing data sources into a format accessible by the new system. The converted data is then loaded into the data structures associated with the system.

(d) Prepare for Delivery to Production Environment

This task could basically start after completion of the Incremental Delivery Planning stage, so execution will be parallel with the Incremental Design and Build stage.

In order to make the required functionality available to the users, agreements have to be reached with the computer operations department on availability, response times, backup and recovery, etc. In return, the computer operations department will inform the project on the costs of running the software. Manuals will need to be finalized during this task.

(e) Deliver to Production Environment

The solutions with the newly integrated Use Cases are delivered into a working environment. Where possible, delivery should be made into the production environment, but other potential target environments include a formal test office or other user testing area.