A initial project-wide activity with domain and development members under the guidance of an experienced object modeller in the role of Chief Architect. is performed.

A high-level walkthrough of the scope of the system and its context is performed. Detailed domain walk-throughs are then held for each area to be modelled which includes studying the Requirements (use cases). After the domain walkthrough, small teams are formed with a mix of domain and development staff who then compose their own models in support of the domain walk-through. The Chief Architect may propose a "strawman" model to facilitate the progress of the teams. The teams each present their models for peer review and discussion. One of the proposed models, or a merge of the models, is selected by consensus. All modelling is done using Coad notation and the Coad methodology.

The object model is then iteratively updated by the Design by Feature process.

Entry Criteria

• The Requirements have been documented and are stable.
• Domain members involved in the Requirements process are available.
• The Chief Architect has been identified.
• The methodology and notation have been identified.

Tasks

The modelling team comprises permanent members from the domain and development areas. Other project staff are then rotated through the modelling sessions so that everyone gets a chance to participate and to see the process in action. It is critical that domain members that were actually involved in the Requirements process are also in the modelling team.

A Domain person gives an overview of the domain area to be modelled. This should also include domain information that is related to the area feature but not necessarily a part of its implementation.

The modelling team studies the referenced use case(s) for the domain area to be modelled. This is an optional task based on the detailed nature of the domain area and/or its interactions.

Using the Coad methodology each small group will compose a model in support of the domain area.

A member from each small group presents that groups proposed model for the domain area. The Chief Architect may also propose further model alternatives. The modelling team selects a proposed model or composes a model by merging ideas from the proposed models. The overall object model is then updated with this new model shape and any changes to the existing overall model that this new model shape requires are made.

Notes on detailed or complex model shapes and on significant model alternatives are made for future reference by the project.

Verification

Internal or self-assessment is achieved by the active participation of domain experts who were actually involved in the requirements process. On an as needed basis, assessment is made by referring back to the business (users) for ratification or clarification of issues that affect the model.

Exit Criteria

The result of the process is the Object Model.

• Object model diagrams in Coad notation focusing on model shape. That is, what classes are in the domain, how are they connected to one another and under what constraints.
• Methods placed in the classes.
• Attributes placed in the classes
• Scenario view(s).
• Model notes to capture why a particular model shape was chosen and/or what alternatives were considered.

An initial project-wide activity performed with the Chief Architect to identify all the features to support the requirements.

Entry Criteria

• The Object Modelling process has been completed.
• Domain members involved in the Requirements process are available.

Tasks

The team comprises permanent members from the domain and development areas. It is critical that domain members that were actually involved in the Requirements process are also be part of the team involved in building the features list.

The team shall identify the set of features by reading the use cases. The features are identified based on -

• the business action the user may take
• Categorizing information in the use case, based on the granularity of business activity described into - subject area, major and minor features. Where the granularity is coarse at the level of subject area, while is very fine at the level of minor features.

Verification

Internal or self-assessment is achieved by the active participation of domain experts who were actually involved in the requirements process. On an as needed basis, assessment is made by referring back to the business (users) for ratification or clarification of issues that affect the features list. Activities, steps and features are only derived from the use cases themselves.

Exit Criteria

The result of the process is the Features List

• A list of business activities
• For each activity, a list of the business steps to complete the activity
• For each activity step, references to the applicable use case(s)
• For each activity step, the feature(s) to satisfy the step

The project manager, development manager and the chief programmers shall plan the order in which the features has to be implemented, based on the feature dependency, load across the development team and also on the complexity of the features to be implemented.

Entry Criteria

• The Features List process has completed.

Tasks

The planning team comprises the development manager plus the chief programmers.

The planning team shall identify the set of features at the level of major and assign a date for completion. The identification of the major feature set and the completion date is based on

• Dependency between features in terms of classes involved
• To balance load across class owners
• Based on the complexity of the features to be implemented.

Verification

Since the planning is a team activity, a self-assessment is achieved by the active participation of chief programmers, development manager and the project manager.

Exit Criteria

The result of the process is the development workplan consisting of

• the set of features categorized as a major feature
• names of the feature and class owners

A set of  features is assigned to a Chief Programmer who then forms a Features Team by identifying the owners of the classes (Developers) likely to be involved in the development of those features. This team then produces the Scenario View(s) for the assigned feature. The Chief Programmer then refines the Object Model based on the content of the scenario view(s). The developers then write class and method prologs. A Design Inspection is held.

Entry Criteria

• The Development Planning process has completed.

Tasks

The Chief Programmer identifies the classes likely to be involved in the design of this set of features and updates the feature database accordingly. Each class has an owning developer. From the ownership list, the Chief Programmer identifies the developers needed to form the Feature team. The Chief Programmer informs the class owners that their participation in the team is required. As part of this step, the Chief Programmer uses the KMS to create a new Design Package for the feature set.

The domain person gives an overview of the domain area for the feature to be designed. This should also include domain information that is related to the feature but not necessarily a part of its implementation. This is an optional task based on the complexity of the feature and/or its interactions.

The feature team studies the referenced use case(s) for the feature to be designed, all confirmation memos, screen designs, external system interface specifications and any other supporting documentation for the referenced use case(s). This is an optional task based on the complexity of the feature and/or its interactions.

Develop the Scenario View(s) required for the feature to be designed. Scenario Views are developed in Playground until support is available in Together/Java. The diagram files should be checked into PVCS in an appropriate place in the package hierarchy. The diagrams should also be converted to a form suitable for publishing on the KMS e.g. a GIF image. Any alternative designs, design decisions, requirements clarifications and notes are also recorded and written up in the Design Alternatives section of the Design Package

The Chief Programmer creates a shared access area for the feature set. This area is either a directory on the UNIX server or a directory on their PC that is backed up to the Unix server by the Chief Programmer as required. The Chief Programmer takes a copy of the existing classes in PVCS. Using Together/Java, the Chief Programmer refines the model to add additional classes, methods, attributes and/or to make changes to existing classes, methods or attributes based on the scenario view(s) defined for this feature. This results in the Java source files being updated in the Feature Team's shared area. The Chief Programmer creates model diagrams in a format publishable on the KMS using the print specifications feature of Together/Java. These files should be checked into PVCS in an appropriate place in the package hierarchy and submitted for publishing on the KMS.

Using the updated Java source files from the "Refine the Object Model" task in the shared FeatureTeam Area, the development owner of each class writes the class and method prologs for each item defined by the feature and scenario view(s). This includes parameter types, return types, exceptions and messages. Once each developer has completed this task, the Chief Programmer generates the API documentation using the Javadoc tool and submits it for publication on the KMS.

Verification

A design inspection with the feature team members or with other project members is held. The decision to inspect within the feature team or with other project team members is that of the Chief Programmer. On acceptance a to-do list is generated per affected class, and each team member adds their tasks to their calendar task list. The Chief Programmer must also merge changes from the shared FeatureTeam Area into the change control system.

Exit Criteria

The result of the process is a successfully inspected Design Package. The design package comprises

• The referenced Requirements in the form of use case(s) and all related confirmation memos and supporting documentation.
• The object model with new/updated classes, methods and attributes.
• The features newly identified during the design (if any).
• The scenario view diagram(s).
• The Javadoc generated output for the class and method prologs created or modified by this design.
• Design alternatives
• A covering memo, or paper, that integrates and describes the design package such that it stands on its own for reviewers.
• Calendar task-list entries for action items on affected classes for each team member.

Starting with the design package, the development class owners implement the items necessary for their class to support the design for this feature. The code developed is then unit tested and code inspected - the order of which is determined by the Chief Programmer. After a successful code inspection, the code is promoted to the Build.

Entry Criteria

• The Design by Feature process has completed. That is the design package has successfully been inspected.

Tasks

The development class owners implement the items necessary to satisfy the requirements of their class for this feature.

A code inspection with the feature team members or with other project members is held either before or after the unit test task. The decision to inspect within the feature team or with other project team members is that of the Chief Programmer. The decision to inspect before or after unit test is that of the Chief Programmer.

The development class owner tests their code to ensure all requirements of their class are satisfied. The Chief Programmer determines what feature team-level unit testing is required (if any). That is, if any testing across the classes developed for this feature is required.

Classes can only be promoted to the build after a successful code inspection. The Chief Programmer tracks the individual classes being promoted, through feedback from the developers, and is the integration point for the entire feature. The Chief Programmer identifies the overall status of the feature in the feature list.

Verification

A successful code inspection plus the successful completion of unit test is the verification of the output of this process. The code inspection and unit test tasks are described above.

Exit Criteria

The result of the process is

• Classe(es) and/or method(s) that have been successfully code inspected.
• Class(es) that have been promoted to the build.
• Status of the feature updated by the Chief Programmer.