Logical Design Phase

Logical Design Phase

In this phase, the focus changes to design. The extended team may be changed to take advantage of specific design expertise, and should include both business representatives (management and staff), and technical expertise (data administration, networking, documentation, etc.).

The team reviews the materials from earlier phases and begins the system design, identifying any additional system objects, determining operations and data structures for all objects, validating relationships and interactions between objects, and prototyping user interface objects.

Warning:

Do not limit design choices based on platform/language decisions made in previous phases. Any constraints resulting from platform/language decisions will be dealt with in the Physical Design phase.

Deliverables

Full Object Model, System Level This diagram shows all the entity objects, interface objects, control/process objects, and messages. This is an update of the entity object model completed in the System Analysis phase, therefore, you should open the existing file in Visio rather than opening a new diagram with the Template button.
Updated Object Life Cycle Models Any changes to the object life cycles resulting from the work in this phase must be entered in the existing models, and new models must be created for any new objects that go through complex life cycles.
Object Interaction Diagrams These diagrams are used to fully define all required messaging between objects based on the transaction sequence diagrams, and each diagram illustrates the flow of control between objects for one transaction sequence. There must be one Object Interaction diagram for each Transaction Sequence diagram. At this time there is neither a sample nor a template for this diagram, although you can find examples in the class materials from the Object Oriented Analysis and Design class.
System-Wide Behavior Model This optional diagram presents a high-level picture of the system and its operation. It is based on the subject areas in the object model. This diagram presents the system as a group of subsystems, that can be scheduled, worked on, and delivered separately. It also helps in determining the relationship of the subsystems based on the services they provide. At this time there is neither a sample nor a template for this diagram, although you can find examples in the class materials from the Object Oriented Analysis and Design class.
External Specification This document describes the external design of the system in terms that make sense to a user of the system. This includes a description of the screens and reports, explanations of the processes the user must follow to accomplish business functions, and a navigational map of the system. This document should be created in Word, but there is no template available at this time.
Initial draft of test plan This document describes the steps to be taken to test the system. These steps should include, at a minimum, expanding or creating use cases for each business function, creating test scripts based on those use cases, creating a test database and other test files, and planning for regression testing. List the business functions that require use cases, indicate where the test data will come from, and estimate when testing milestones will be reached. There is no template or sample for this document at this time.
Use Cases This document describes each use case in detail. There should be a use case for each business function to be handled by the system. There is no template or sample for this document at this time.
Documentation Plan This document describes the user requirements for documentation of the system, and the plan for meeting those requirements. There is no template or sample for this document at this time.
Initial Draft of Test Scripts These scripts are step-by-step procedures used to test functionality. Each business function should have one or more test scripts, depending on the number of alternate paths there are for completing the function. There is no template or sample for this document at this time.
Updated Project Plan The project plan is updated as needed, and a phase section containing the work breakdown structure and schedule for the Physical Design phase is added. At this time, no sample is available.
Methodology Compliance Form This form is initialized by the project team, and completed by a methodology representative who has reviewed the project documentation and found it acceptable. It is completed in Word. At this time, no sample is available.
Recommendation Form This form is completed by the project team, and contains the recommendation to the project sponsor on whether or not the project should continue. The form is completed in Word. At this time, no sample is available.

Steps

The core team recommends a new extended team, if necessary. Be sure that at least one client who is representative of the average user is still on the extended team.

All materials produced in the previous phase are distributed to and reviewed by the team members.

The team meets to review the extended Entity Object Model produced in the previous phase. To complete the Entity Object Model, identify and define interface objects, control/process objects, and messages.

Interface objects
Are used to handle communication and encapsulate environment-specific behavior. Interface objects include user interface screens and windows, online help, and system interfaces.

Use prototyping to design the user interface objects--screens, windows, dialog boxes, reports, etc. User documentation should be planned, designed, and maybe even started at this point, since the user interface is the essence of what user documentation explains. Remember to evaluate the cost of delivery, such as printing costs.
Complete the definition of an Interface Object/Class, using a template (to be provided later).
Create an external specification for the user interface.

Control/Process objects
Are objects that are neither entity objects nor interface objects. See page 5B-12 of the Object Oriented Analysis And Design class materials for an introduction to Control/Process Objects. Complete the definition of a Control Object/Class, using a template (to be provided later).
Messages
Are the communications between objects.

See page 5B-17 of the Object Oriented Analysis And Design class materials for the validation checklist for the full Object Model, and click here to see a sample diagram.

Validate the entity classes for policy and integrity rules.

Complete the operations for each entity class, and document them. Complete the Object/Class Definition, using a template (to be provided later).

Complete the data structure for each entity class, normalize the entity classes, and document each attribute. Complete the Attribute Definition for each attribute, using the ATTRDEF template (to be provided).

Validate the relationships. See page 5C-18 of the Object Oriented Analysis And Design class materials for the validation checklist for validating the entity classes. Complete the Explicit Relationship Definition for each relationship, using the RELATE template (to be provided).

Build an Object Interaction Diagram, as either a fence diagram or a network diagram, or both if desired.

Design a test plan for the system, based on the information learned up to this point.

Create a documentation plan, based on user requirements, priorities, and schedules. Documentation requirements can be discussed in the design meetings, or in separate meetings with user representatives. The plan should indicate what type of user documentation will be provided, who will be responsible for creating it, what tools will be used to create it, and who will be responsible for reviewing it. Estimated delivery dates should be included for both review drafts, review comments, and final documents. Documentation tasks can then be scheduled on the project plan with the other project tasks.

If you need to present a high-level picture of the system and its operation to management (executive level), you can create a System-Wide Behavior Model. This is an optional diagram based on the subject areas in the object model.

Copy and distribute all documentation to all team members.

The team reviews the documentation (models and text documents), and makes any changes that seem necessary.

The documentation packet is forwarded to the methodology unit representative with the compliance form (use the COMPFORM template), and a methodology walkthrough is scheduled with the core team and the methodology representative.At the walkthrough, the methodology representative can ask any questions and raise any issues about compliance with the methodology, or suggestions for improvement.

If any changes are required, the team must complete the required step(s) and schedule a follow-up walkthrough with the methodology representative. When the walkthrough is completed successfully, the project continues with the next step.

The team revises the project plan, if necessary, and the documentation packet, including the project plan, is forwarded to the methodology representative for the final review in this phase.

The methodology representative reviews the documentation packet and completes the compliance form before returning the documentation packet to the project team.

The core team writes a recommendation on whether or not to proceed. Use the RECOMEND template, which includes space for the actual recommendation, and for the pros and cons associated with the recommendation.

The recommendation is forwarded to the project sponsor with the project plan and supporting documentation for review, and the project sponsor decides whether or not to take the project forward.