Team Leader Software
Nolan Harley
If any of you have ever worked in a Call Centre then you will know how
many 'Post-It' notes are used! The main problem is that when people try
to pass on problems that they cannot deal with, to Team Leaders, it often
means that either a note is passed along or a reference number is handed to
someone else. An ideal situations is to automate this with the use of
computers:
specify, design, implement and document a program to provide the functions
of a suitable logging piece of software. In outline, this software should be
able to record customers details, reference number, have logging in fuctions,
restricted access, date stamping, updating of records, fault notes and customer
information. It should also be possible to search and link all of this information in
various ways.
Your task is to
What is Required
The first draft and version.
Project plan: The project plan will identify the resources available, the quality assurance procedures to be applied, coding standards, the verification and validation plan, and the scheduling of the project. The object of verification is to establish that the program is working reliably and validation to establish that the system is as desired (according to the requirements definition).
Requirements document: This comprises the requirements definition and specification. It has the following structure: introduction, system model, functional requirements definition, functional requirements specification, hardware requirements, database requirements, non-functional requirements definition and specification, and possibly a glossary and an index. (Note: this organisation merges elements of the requirements definition and the requirements specification into a single document, being more in keeping with the scale of the project.)
Draft user manual: We practice a methodology called user manual first, where there is a draft user manual before writing the system.
Top-level design document: This comprises the software design, using a suitable formal design notation, the user interface design, using a state diagram, and the database specification, using entity-relationship diagrams.
Project overview: This is a short section which ties together all the other sections . This section also includes the Project log and the Project critique. The latter being a review of the system, highlighting how things would be done differently in hindsight, what additional functionality would be include and an outline of how it might be implemented.
User documentation: This comprises a functional description, installation guide, introductory manual and reference manual.
Test plan: This covers the plan for testing of program components, integration and final acceptance. It does not include test results (see next section).
Program listing and program documentation: The program documentation is something separate from the comments in the code itself: it will take the reader through the program, identifying the main data structures used and make clear the overall program structure. It acts as the basis for a maintenance document, inasmuch as the reader should be able to work out where to start making appropriate changes. The test results form part of the program documentation.
The Following Documents are also available that accompanied the Final Project: