Whitepaper No. 1

Officeware
RAPID APPLICATION DEVELOPMENT

A Structured Approach to Programming
Modern Business Applications

Methodology Definition, Version 2.0

February, 1998

Table Of Contents

INTRODUCTION

To Top of Page...  

This document defines a Rapid Application Development (RAD) methodology for developing PC-based applications. The standards are oriented to a GUI-based development environment, specifically with Microsoft Access as the example. The aim of the definition is to introduce checkpoints for management control and achieve the desired quality without sacrificing speed of development.

The RAD process aims to eliminate the following difficulties posed by the traditional waterfall model:

• Not suited for object-based, messaging environments such as MS Windows
• Not suited for interface-driven applications
• Introduces a long delay between requirements gathering and final delivery
• Rigid, document-driven process

INTENDED AUDIENCE

This document is intended to be read by anyone affected directly or indirectly by the software applications developed at Officeware, and who can contribute in refining this process definition. A reasonable familiarity with the software development lifecycle and related terms has been assumed.

PHASES

The following illustrates the major differences between traditional design methodology and Rapid Application Development methodology that Officeware embraces:

ACTIVITIES AND DELIVERABLES

To Top of Page...   

Three participants are assumed to be involved in projects:

1. The Client User Representative
2. The Client Technical Representative
3. OFFICEWARE Representative

The responsibilities for the various deliverables have been assigned to these participants.

PROJECT MANAGEMENT ISSUES

To Top of Page...  

Based on the estimated overall effort, projects shall be classified as follows:

• Large Projects:         > 6 person-months

• Medium Projects:      2 - 6 person-months

• Small Projects:          < 2 person-months

The process described above will be followed for Large and Medium projects. For small projects, the emphasis will be on prototyping with user involvement and delivery of documented code (rather than on other documentation). UTPs and STPs will be prepared only if the size of the system warrants it. The decision to prepare UTPs and an STP will be taken by Client Tech Rep.

Data on estimates and actuals will be maintained via time sheets and informal documents to improve estimates.

The need for formal project planning and scheduling of small and medium projects is unnecessary in most cases. This will only be provided at the customer's request, or if project participants and/or scheduling becomes complex enough to warrant it.

STANDARDS

1. Minutes of every meeting with users will be documented and circulated.

2. The Design Spec. will have the following structure:

• Cover Page (Title, Date, Author)
• Introduction (Purpose, Audience, Summary of Document, Summary of System)
• System Overview (Existing System, Proposed System)

The section describing the proposed system shall cover the following topics:

• Business Requirements
• Existing System Overview
• Proposed System Overview
• Hardware Requirements
• Software Requirements
• System Schematic (flow chart, data structures, entity relationship)
• Operational Cycle/Workflow
• System Modules
• Input-Output (Reports, Export/Import, Audit trails)
• User Interface Prototypes
• Report Prototypes
• File Structure  (optional)
• Accuracy  (optional)
• Life span  (optional)
• Backup and Archiving  (optional)
• Security  (optional)
• Manual Procedures  (optional)

The design spec will provide the intermediate and final sign off documents. The development cost and time estimate for any system can be provided after the Functional Specifications are approved. The cost is based on an evaluation of each module as defined in the Specification. To provide flexibility, the costs of development, documentation, online help, training, and other system options are usually provided separately.

3. Review comments and notes prepared during analysis and design shall be structured so as to be readable. Review comments will be in the form of a list of points discussed, with appropriate references to the reviewed document, prototype or other deliverable.

4. Unit Folders shall be maintained for each unit, containing: Description, UTP, Change Log, Dates, Signatures

5. Development standards for Access and Visual Basic shall be followed as per a separate document to be prepared before commencement of development. This document shall address:

• Naming standards for all objects
• Interface standards (header/footer, colour scheme, form layout)
• Code documentation standards
  

6. There shall be an independent round of unit testing for all units. This shall be done as an internal working procedure between OFFICEWARE consultants.

7. Change control and version control procedure, as specified in appendix 3, shall be followed. This document will addresses user involvement in change authorisation, change forms to be used, and version control standards.

8. The STP will have the following structure:

• Introduction
• Test Strategy
• Checkpoints
• Test Conditions and Expected Results
• Test Data
  

9. A Software Change Form (SCF) will be filled and maintained for every change to a baselined configuration item (units after they are frozen, documents after sign-off). The Client Representatives will be involved in impact analysis and approval for every change other than strictly technical ones or obvious bugs.

10. All memos or meeting minutes shall be circulated via Internet Email where possible, or fax.

Copyright © 1996-1998 Officeware Corporation. All rights reserved.


To Top of Page...