Skip to main content link. Accesskey S

CAM2 Wiki

All users on the internet can see this document



Home > Project Process

Project Process
ShowTable of Contents

Introduction

 
This project will be run using FoCul's "Large Projects" Process. The key features of this process are :
 
  1. Defined prject phases as described below
  2. A Risk Register

  1. A workflow system to manage Reservations and Enhancement Requests
  2. Seperateion of the Developer and Project Manager roles


 

Project Phases

 
The project has the following phases. They follow a senquential logic but we may find that different parts of the project are at different stages.
 

Technical specification

The Technical Specification will be developed using wire frame diagrams of screens and flowcharts of the workflow processes. This will be carried out post sanction.

System development and testing


Having specified the system we go on to develop it. This is generally done by one developer who the test his work before involving a colleague or project manager for internal testing

Development is carried out on our own servers to improve efficiency

 

Internal testing

During Internal Testing the developer and a colleague test the system with the colleague playing “Devils Advocate”. All reservations from this point are recorded in our project management reservations database and managed through that process

 

User acceptance testing 1

The purpose of UAT 1 is to confirm that all of the required functionality is present and to improve the usability of the system. The robustness of the system is of interest but it is of secondary importance at this point.

FoCul will demonstrate the system and then individual users will be asked to perform some of the functions that they need in order for us to assess how well the system will work.

All reservations are recorded in a matrix and then transferred to the project management system

At the end of UAT 1 we would typically expect to have raised 10 - 15 very significant issues and 30+ smaller issues.

UAT sessions on this type of system typically take ½ - 1 day and require the key stakeholders to be present. It is anticipated that a dedicated UAT will be needed for the EI functionality.

User acceptance testing 2


The purpose of UAT 2 is to confirm that the system is robust - it is not the time to request new functionality.

FoCul will demonstrate the system and then individual users will be asked to perform some of the functions that they need in order for us to assess how well the system will work.

All reservations are recorded in a matrix and then transferred to the project management system

At the end of UAT 2 we would typically expect to have raised 1 significant issue and 5+ smaller issues.

UAT sessions on this type of system typically take ½ - 1 day and require the key stakeholders to be present

UAT sessions are where the key users will get most of their training.

It is anticipated that a dedicated UAT will be needed for the EI functionality.

 

Documentation

Documentation comes in 3 types.

Developer Documentation


FoCul will usually embed this within the programming code

User Documentation


Lucite will be responsible for the user documentation

Super User Documentation


Lucite will be responsible for the user documentation

Data migration


Two data migration phases are required as data is needed to test the system. There will be a trial data migration to create test data and hen a formal data migration

End user training


Key users will be trained during the UAT sessions. These key users will then train other MC users in how to operate the system.

Support / Enhancements


FoCul will support the project once it goes live. Issues that arise will be categorised as either bugs or enhancements. Bugs will be fixed and enhancements will be costed up for a decision by Lucite