Recruitment Registrar Project Plan

Recruitment RegistrarProject Plan

By

Jason Vipond, Jim Sodam, Joe Klug,

Ajay Dharna

October 24, 2002

Project Overview

• Client – Admissions Marketing Dept.

• What do they do?

• Why do they need us?

Project Overview (cont)

Types of Users:

• Users – Potential Students

• Super-Users – Admissions Marketing Staff

Project Overview (cont.)

We intend to provide a solution that:

• Captures potential students information from the web and stores it in a database

• Reduces data entry

• Allows Admissions Marketing Staff to add, modify, and delete records

Lifecycle Model

Milestones – CS425

• Requirements Analysis Document

• Project Plan

• Design Document

• Final Presentation

Milestones – CS499

• Coding Specification

• Module/Integration Testing Complete

• System Testing Complete

• Acceptance Testing Complete

• Successful Migration

• User Manual

• Final Presentation

Basic Organization

Mr. GrantUpper Management

Dr. EhlmannUpper Management

Jason VipondProject Leader

Karen BollingerMain Client Contact

Ajay DharnaLead Designer

Jim SodamLead Programmer

Joe KlugLead Tester

Roles

• Jason Vipond – Team LeaderJason is responsible for keeping the team on track, assigning units of work, leading meetings, and scheduling team and client meetings.

• Jim Sodam – Lead ProgrammerJim will be in charge of leading the programming process. Since Jim has more experience with ASP, he will be the “go to” guy for ASP page creation and troubleshooting.

Roles (cont.)

• Joe Klug – Lead TesterJoe will oversee the testing process, keenly observing testing criterion and overseeing all module, integration, system tests, acceptance, and site tests.

• Ajay Dharna – Lead DesignerAjay will lead the team in all aspects of design, including: system design, interface design, and web design. Ajay is also responsible for the team website

Additional Responsibilities

• Documentation

• Analysis

• Programming

• Testing

• Design

• Presentations

• Learning required technology

Required Tools

• Hardware– csfs2– PC

• Software– MS Access– Text Editor

Decision Making

• Consensus

• If consensus fails– Majority vote

• In event of a tie– Phase leader makes decision

Change Management

• Baselines– Requirements Analysis Document– Design Document

• Who may make a change proposal?– Team members– Client– Upper Management

Change Management (cont.)

• Types of change– High impact on cost or schedule– Low impact on cost or schedule

• Change Management Board– Consists of team members– Meets within 3 working days of change request– Decision reached

Change Management (cont.)

• Implementing a change– Approvals needed

• If the change changes functionality the client and Change Management Board approval is needed.

• Otherwise only Change Management Board approval is needed

– Documents updated– Change scheduled– Change tested

Change Management (cont.)

• Change Request Form– Name of person requesting change– Date of change request– Change requested– Reasoning behind requested change

Document Plan

• The leader of the current project stage is responsible for documentation for that stage.

• Documentation must be approved by the team before it is considered final.

Document Plan (cont.)

• The author(s) of the document are to proof the document before presenting it to the team for final proofing and editing.

• Printed documents will be made available to the client and management upon request.

• Current documents are always accessible to anyone from the project web page. (http://www.cs.siue.edu/sp/f02g7/)

Test Plan

Module Test• Testing done on a particular module before

combining with the rest of the system.• This includes white and black box testing.• Module tests determine whether or not the

module is ready for integration.• Module tests should be done by someone

other than the programmer of that module.

Test Plan (cont.)

Integration Test• In integration testing, we insert a new module into

the system and perform tests to ensure correctness.• The system can be integrated using a top down or

bottom up approach.• When all modules have been successfully

integrated, integration test is complete.

Test Plan (cont.)

System Test• The integrated system is tested by someone other than the

programmers. The system is tested against the Problem Specification to ensure it does the intended job.

• System tests are done to be certain that the system will handle extreme and normal uses correctly.

• The environment should be as close to the final environment as possible.

• This test is typically called the "Break Test" and shows that the system will hold up against misuse.

Test Plan (cont.)

Acceptance Test• We must show that the system satisfies all the

contract requirements.• If the requirements are not met, the team should

do its best to modify the system to meet the client's concerns.

• If the client is satisfied, he/she will sign an agreement stating that they accept the system.

Test Plan (cont.)

Site Test• The system is put in place for its final set of

tests.

• This test determines the system’s readiness for operation in a production environment.

Migration

• Security concern with live server

• All finished scripts and databases will be passed to Martin Mokoosio for installation on the client’s server.

• The finished scripts and databases will be passed to Martin Mokoosio by April 16, 2003.

Migration (cont.)

Method – Parallel Operation

 If the system is fully functional following migration, the cutover criteria has been met.

 The client will make the decision to cutover from the old system to the new one

Migration (cont.)

Plan ‘B’

• Client uses old system and shops around for a server to house new system.

Migration (cont.)

Introduction of Data• The project team will implement a program

to automate the data conversion process. Any data that does not have a suitable unique identifier (SSN) will be discarded. It is the client’s responsibility to validate the converted data.

Training Plan

There are two types of training that the Team will be responsible for:

• Internal Training

• External Training

• Internal Training• ASP• MS Access• HTML

• External Training• Client trained to use and Administer

the system.• Client will also be provided with a

User Manual.

Training Plan (cont.)

Risks

• Migration of System

• Server crash

• Completion of Project

• Database will become too large

• Hackers

Current Project Status

• Contract Signed

• Documents Updated

• Project Design

• New web site

• Development Server Obtained