Design by Feature
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.
- The Development Planning process has completed.
|Form Feature Team
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.
||Feature Team, Domain
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.
|Study the Referenced
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
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
|Refine the Object
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.
|Write Class and
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.
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.
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.