Last month, we focused on the Design
Phase, specifically Test Designs. This month, we
will continue our focus on the
Design
Phase,
the second phase of the Iterative Software Lifecycle.
Since the design phase has many deliverables, we will focus
this month on the Object and Data Model deliverables. In
the coming months, we will explain the other deliverables of
the Design Phase as well as the remaining phases of the
Iterative Software Lifecycle and provide you with step-by-step
instructions on implementing it. To see newsletters from
prior months, click here.
This newsletter is
sponsored by Software Planner (http://www.SoftwarePlanner.com).
Design
Phase
The Design Phase is used
to determine the technical solution and to provide preliminary
estimates for delivering the solution. For the project
manager to provide correct estimates, the development team
must spend time architecting a technical solution that meet
the demands of the functional specification.
Additionally, the testing team must develop a Master Test Plan
as to allow them to estimate their effort.
Upon completion of this
phase, a project plan may be developed which details the
costs, effort and timeframes in which the solution may be
delivered. As a final step, the client may decide to
add, omit or delay functionality to fit within their timeframe
and budget.
Deliverables
Below
are the deliverables for the Design Phase:
Since we discussed the
Test Design last month, this month we will discuss the
Object Model and Data Model. In coming months, we
will explain the other deliverables in
detail.
Data Model
Once your development
team has created a detailed design, it is time for them to
begin determining what database tables are needed to
match the design. There are 2 types of data
models:
-
Logical Model - This
is a roadmap of all the data structures in your design, with
relationships among objects clearly defined. It
includes the attributes of each entity and allows you to
normalize the data for your specific purpose.
-
Physical Model -
This is an implementation of a database on a specific
database engine. Based on the Logical Model, the
entities become database tables and the attributes become
fields in each table.
When creating your logical
model, you will draw diagrams that explain the relationships
between the data entities. From here, you create an ERD
(Entity to Relationship Diagram) that shows those
relationships. For example, if you are creating a
billing system, you may have an Invoices entity that has a
relationship with Invoice Line Items. In this
relationship, an Invoice must have one or more Invoice Line
Items. There are many great tools that allow you to draw
these diagrams, such as Erwin ERD. Some databases come
standard with ERD drawing tools, an example is Microsoft SQL
Server. It has an Enterprise Manager that contains an
Diagram modeler.
The Physical model's purpose
is performance. Designing databases for performance
requires an understanding of the underlying DMBS and
normalization techniques. In most instances, the
database should be designed relationally and properly
normalized. In cases of historical reporting, it is
often a good idea to create de-normalized summary tables to
quicken the generation of these reports. Most often, it
is good design practice to keep only the amount of information
necessary to run the business on a day-to-day basis on the
operational system and have a separate data warehouse for
storing historical data. The data warehouse can produce
historical reports or may feed data marts to perform
specialized
reporting.
An important part of the data
modeling process is to establish clear standards. For
example, your data model should have consistent abbreviations,
and should have standard naming conventions. For
example, you may decide to name all your tables as plural
(Invoices instead of Invoice) and you may decide to always
abbreviate number as nbr. If you document your standards
ahead of time, this will ensure that all members of your team
build a cohesive product.
Object
Model
Once your
database model has been defined, you can define your object
model. Below are the steps in object oriented
design:
-
Identify the objects and
their attributes (data).
-
Determine what can be done
to each object.
-
Determine what each object
can do to other objects.
-
Determine the parts of each
object that will be visible to other objects and which parts
will be private.
Similar to database modeling,
it is wise to create diagrams that show the relationship
between objects. There are many tools on the market to
do this (like Microsoft Visual Modeler). Many of these
tools will also generate some of the code behind the
objects.
An important part of the
object modeling process is to establish clear standards.
For example, your object model should have consistent
abbreviations, and should have standard naming
conventions. For example, you may decide to name all
your objects as plural (Invoices instead of Invoice) and you
may decide to always abbreviate number as nbr. Objects
should have also have consistent method names. For
example, you would not want to have an AddNew method in some
objects and an Add method in others. Naming your methods
consistently allows your programmers to quickly develop using
the object model. If you document your standards ahead
of time, this will ensure that all members of your team build
a cohesive product.
Summary
During the Design Phase,
the project manager works with the development team to create
detailed designs. Detailed Designs explain the technical
approach and estimated effort for delivering each functional
specification item. Once this is done, the project manager
works with the testing team to create the Test Plan. The
Test Plan details the testing approach and estimated
effort. Once this is done, the project manager can fully
estimate the entire project and your development team can
create the Data and Object models. The Data and Object
models should have clear standards as to enforce consistency
as multiple team members work on the
project.
Free
Templates
Click the
link below for some free templates to get you started with the
Iterative Software Lifecycle. These templates cover all areas
of the lifecycle, from the planning to production
phases.
Templates for the Iterative Software
Lifecycle
Software
Planner
Software
Planner is a web-based software lifecycle management tool that
fully supports the Iterative Software Lifecycle. To
learn more about Software Planner, click the link
below.
Software
Planner