| |
IBI develops systems from a proprietary �Results Based, Reverse Design
Methodology�.
Key Benefits
- Results Based
- Fast
- What You See Is What You Get
- Foundation for Enhancements
Results Based, Reverse Design Methodology
- Process
- IBI develops systems from a proprietary �Results Based, Reverse Design
Methodology�. This means that we start with the �end result� based on
requirements, then work backwards through the design, leading up to our
Inputs. We pour over the expected results, then conceptually �brain storm�
through the process, capturing as many details as they turn up, but not
drilling down into finite details until the �Design Phase�. We create a
prototype that potentially becomes the base for the construction. While
there is often re-work, this prototype opens our eyes to the possibilities
and exposes more details that will be necessary for a successful
implementation.
Data Modeling
During this first phase we capture many fundamental data entities
(things/nouns), keys (identifiers) and attributes (details) about the
entities. For example, Vendor and Store
would be Entities, and Store Hours and
Address would be attributes. Plus, we define some of the relationships
(verbs) between entities. A relationship might be defined as: �a Store �does business at�
many locations.� Once we have the �Conceptual Data Model�, we
start to backfill it with additional details that are obvious in the
requirements and in the �end result�. Complex or unknown items are stubbed,
and assumptions are documented for further analysis and approval.
User Interface
Once we have this �First Cut� Data Model, we can start to design the User
Interface (UI), showing the Web site �flow� and navigation. Often, one page
will represent one entity or relationship. However, sometimes it is more
appealing to combine some of these onto one page.
There is a parallel effort going on. The �Graphic Artist� designs the
general �look and feel� of the web site. For example, where does the Company
Logo go; what colors do we use; what do the navigation buttons look like; do
they use �mouse-over� effects, etc.?
Prototype
As the prototype is developed, additional attributes and �physical flow
control� tables are created and implemented into the code. However, standards
are maintained even in the prototype, so conversion to the �real thing� is
easier. SQL will be centralized into an �Include� during the prototype using
parameters as properties and for driving methods. Then, the SQL can easily be
migrated to �Data Access Layer� objects. This improves security and
performance in the real Web site, while allowing for quick changes during the
prototype phase.
The prototype becomes an iterative process until we (client and IBI) are
satisfied with the �look and feel�, and many (but maybe not all) of the
results are realized.
Production Ready and Testing
The prototype is then converted to a real Web site, designed for security,
integrity and high performance in a multi-user environment. The site goes
through a thorough unit test plan; system test and then a load/stress test. Usually, some anomalies are discovered and corrected. The test plans are
repeated until there are no �show-stoppers�. Ideas for enhancements are often
brought to light. We highly recommend postponing these enhancements for
another phase because �scope creep� can kill a project. Momentum is in our
favor, and results follow results. So, roll out the first phase, and then add
enhancements.
Rollout and Monitoring
The site is monitored for performance after it is launched. The celebration
party follows shortly after launch.
|