Manchester's premier publisher


24.99 - Spiral Bound
Published Sept 1st 2001
ISBN: 1 901 746 15 1

by David Miller

A guide for IT professionals and students

Table of Contents

Purpose of the Handbook

Order Now at Amazon

The IT Manager's Handbook is designed for ease of use. Each Double Page contains checklists in a simple and informative style, alongside useful tables and charts with which to check your progress. It's spiral binding ensures sheets can be easily photocopied - as a single volume resource The IT Manager's Handbook gathers together all the information required for running a modern business.

The IT Manager's Handbook




This chapter is concerned with in-house development and the production of tailored applications produced by software houses. Many of the issues are pertinent when purchasing packages.


The production of the system specification and estimating costs and timescales are dealt with. The chapter also covers system design, database design, on-line screen design, printed output, financial controls, process specifications, standard programs, coding standards and system implementation. It deals with the production of user guides, the provision of user training, the provision of maintenance and support services, and the management of requests for IT work.


6.1 System Specification


If the system is to be developed as a new system, either in-house or by a software supplier, produce a detailed system specification. Create the system specification from the functional requirements specification by the addition of samples of all screens, analyses, reports, broad processing details, database details and the implementation plan.


Include in the system specification only a manageable amount of detail, sufficient to inform the customer and analyst about the broad input, processing and output of the system, but leaving out the fine detail of the processing. Develop the document to become the long-term technical guide (but not a training document or user guide, which will need to be written separately, probably by the customer).


Use the system specification to derive accurate estimates of effort and cost, together with first guesses of timescales. In addition use the system specification for the basis of system and database design, agreeing and setting standards for on-line and printed layouts, and for financial controls and statistics.


System Specification contents


Develop the system specification from the functional requirements specification by adding:


A breakdown of the system into sub systems if necessary

Transaction names and their identities

Screen examples integrated with the descriptions of on-line functions

Field validation added to on-line functions

Processing and decision tables added to on-line functions

Report examples integrated with the descriptions of print functions

Processing and program identities added to batch functions

Implementations phases and timescales agreed with the user

Database design details

List of database record types and their descriptions

System design standards and conventions to be incorporated into the system

Data capture and cleansing details

System Specification and Production


6.2 Estimating Development Time


It will be necessary to estimate the potential cost of an in-house system at various stages. When a formal functional requirements specification or, better, a system specification has been produced, a fixed estimate can be given.


To be able to estimate the development costs, break down the project into smaller tasks. On-line transactions, batch functions and print schedules form a good basis for the breakdown. Ignore the experience of the development resources for costing purposes at this stage until tasks have been allocated to individual staff.


Allow five days for the development and testing of a simple on-line transaction or print schedule in a Fourth Generation Language, ten days for a more difficult one. Similarly, use five days for a simple batch transaction, ten or more days for a more complex one. It may be possible to produce many reports and analyses in much less time than this using a good report generator and one day per transaction may be more than sufficient. Double the development estimate to give the minimum effort for all elements of the implementation of the function. Vary this according to experience of the particular development environment.


Project time apportionment


Split the project up using the following suggested percentages for elements of the IT organisation's effort required, varying these percentages with experience and according to the particular circumstances: