Database Reference
In-Depth Information
inputs? What are the outputs? What kind of online screens will there
be? What kind of reports would there be? Will paper forms be required?
Will any hookups to external files or companies be required? How shall
this information be processed? As you can see, there's much work to be
done at this point and many questions to be answered. In the end, all of
the answers to these questions will be fully documented in a require-
ments document.
Once all the unknowns are known and are fully documented, the sys-
tems analyst can put flesh on the skeleton by creating both high-level and
then detailed designs. This is usually called a
specification
and can be hun-
dreds of pages long. This document contains flowcharts, file and database
definitions, and detailed instructions for the writing of each program.
All along the way, the accuracy of all of these documents is checked and
verified by having the end users and analysts meet with each other. In fact,
most approaches to system development utilize the creation of a project
team that consists of both end users and IS staff. This team meets regularly
to work on the project and verify its progress.
Once a complete working specification is delivered to the programmers,
implementation can get under way. For the FOCUS system, we turned the
specification over to a team of about 20 programmers. The systems ana-
lyst, project leader, and project manager were all responsible for making
sure that the implementation effort went smoothly. Programmers coded
code and then tested that code. When this first level (unit testing) of test-
ing was done, there were several other phases of testing, including systems
testing, parallel testing, and integration testing. Many companies have QA
(quality assurance) departments that use automated tools to test the verac-
ity of systems being implemented.
Once the system has been fully tested, it is turned over to production
(changeover). Usually, just prior to this, the end-user departments (not
just the team working on the project) are trained and manuals distributed.
The entire team is usually on call during the first few weeks of the sys-
tem after changeover, because errors often crop up and it can take several
weeks for the system to stabilize.
Once the system is stabilized, it is evaluated for correctness. At this
point, a list of things to correct as well as a wish list of things that didn't
wind up in the first phase of the system is created and prioritized. The
team, which consisted of technical and end-user staff, usually stays put
and works on the future versions of the system.
Search WWH ::
Custom Search