Databases Reference
In-Depth Information
•
Ease of Learning and Use:
Methodologies that are easy to learn and use
are more likely to be used on projects. Some methodologies are pack-
aged with training courses from the vendor or other third parties.
It is not unusual to add to this list of features or to assign more weight
to a handful of them because of their importance to a specific organization.
Experience has shown that complicating the selection process does not
necessarily improve the quality of the final selection. In fact, this can lead
to wasted time and intense team debates or arguments that end in worth-
less stalemates. It is preferrable to build a short list of candidate method-
ologies by disqualifying candidates that are weak on one or two key
features (e.g., not available electronically or purchase price is greater than
$100,000). The short list then can be compared to maybe five or six of the
features that are of key importance to the organization. It is useful to con-
duct a limited number of pilot projects that test the value of a methodology
before making a final selection. It is also not unusual to pilot two different
methodologies in a conference room pilot (CRP) to make a final determina-
tion. This process can take between six weeks and six months.
HIGH-LEVEL DATABASE DEVELOPMENT METHODOLOGY
This section defines a high-level methodology for database develop-
ment. This methodology provides a good start for small- to medium-sized
projects; however, a formal third-party methodology should be considered
for projects that require more than six months of development effort. The
activities discussed in this section are mapped to the standard project
development framework, which consists of the following main phases:
requirements, architecture, design, development, testing, implementation,
and post-implementation. These phases can be conducted in parallel or
sequentially depending on the exact nature of the methodology, and are
restricted to database specific activities.
The subprocesses that are described in this section fit into a larger full
lifecycle methodology that would address such activities as corporate
sponsorship for the project, project plan definition, organization building,
team building, user interface development, application design, technology
selection, acceptance testing, and deployment. It is assumed that these ac-
tivities are completed outside the database development methodology
phases.
•
Define Business Requirements:
Business requirements are captured for
any system development effort. The requirements also should be used
to build the logical data model. They will feed such things as the num-
ber of entities, attribute names, and types of data stored in each at-
tribute. These often are categorized by subject area.
•
Borrow or Create the Data Model:
With a solid understanding of the
business requirements, it is a good idea to search the market for a data
Search WWH ::
Custom Search