|
At the end of this part of the process, we expect to produce a final
contract that includes product requirements, a course of
development and expected maintenance requirements.
Moving forward, the design phase is used to lock down the
requirements of the project. While not the same level of detail as
a full-blown product specification, the requirements talk of goals
and end results of the product, as well as ways of achieving the
goals. Major interface components and organizational themes are
laid out, as well as restrictions or limitations which are
acceptable and can be used to reduce implementation costs. Sample
screen shots and descriptions of user work flow for specific tasks
may be described, as well as domain size constraints. The purpose
of the design phase is to produce a set of product requirements and
a likely course of development that can be used by many software
development firms to produce the software. Initial estimates of
time of completion, based on timeliness of client input, are also
provided at this phase, although the majority of software projects
end up having an implementation time line that is dictated on the
responsiveness of the client. Also, maintenance requirements and
hosting challenges are identified in the design phase, including
very rough estimates of ongoing costs based on support at
Leepfrog.
During the design phase, the costs for the project are 'locked
down,' and are unlikely to change without collaborative input. This
flexible implementation strategy and ability to rely on the initial
software costs is fairly unique to Leepfrog, and is what permits
our clients to base business decisions about the product on.
After the design phase, the client may choose to shelve the
project or continue onto implementation. The next three phases are
handled as a group – there should be no plans to cancel a
project in mid-implementation, barring a major change from the
planned design. Each phase is designed to establish milestones and
provide a time-based incentive for both parties to continue
efficiently down the implementation path.
Continue reading about the rest of Leepfrog's Methodology here:
| 
