1 / 33

Recruitment Registrar Project Plan

Recruitment Registrar Project 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

cady
Download Presentation

Recruitment Registrar Project Plan

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RecruitmentRegistrarProject Plan By Jason Vipond, Jim Sodam, Joe Klug, Ajay Dharna October 24, 2002

  2. Project Overview • Client – Admissions Marketing Dept. • What do they do? • Why do they need us?

  3. Project Overview (cont) Types of Users: • Users – Potential Students • Super-Users – Admissions Marketing Staff

  4. 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

  5. Lifecycle Model

  6. Milestones – CS425 • Requirements Analysis Document • Project Plan • Design Document • Final Presentation

  7. Milestones – CS499 • Coding Specification • Module/Integration Testing Complete • System Testing Complete • Acceptance Testing Complete • Successful Migration • User Manual • Final Presentation

  8. Mr. Grant Upper Management Dr. Ehlmann Upper Management Jason Vipond Project Leader Karen Bollinger Main Client Contact Ajay Dharna Lead Designer Jim Sodam Lead Programmer Joe Klug Lead Tester Basic Organization

  9. Roles • Jason Vipond – Team Leader Jason is responsible for keeping the team on track, assigning units of work, leading meetings, and scheduling team and client meetings. • Jim Sodam – Lead Programmer Jim 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.

  10. Roles (cont.) • Joe Klug – Lead Tester Joe will oversee the testing process, keenly observing testing criterion and overseeing all module, integration, system tests, acceptance, and site tests. • Ajay Dharna – Lead Designer Ajay 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

  11. Additional Responsibilities • Documentation • Analysis • Programming • Testing • Design • Presentations • Learning required technology

  12. Required Tools • Hardware • csfs2 • PC • Software • MS Access • Text Editor

  13. Decision Making • Consensus • If consensus fails • Majority vote • In event of a tie • Phase leader makes decision

  14. Change Management • Baselines • Requirements Analysis Document • Design Document • Who may make a change proposal? • Team members • Client • Upper Management

  15. 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

  16. 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

  17. Change Management (cont.) • Change Request Form • Name of person requesting change • Date of change request • Change requested • Reasoning behind requested change

  18. 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.

  19. 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/)

  20. 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.

  21. 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.

  22. 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.

  23. 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.

  24. 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.

  25. 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.

  26. 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

  27. Migration (cont.) Plan ‘B’ • Client uses old system and shops around for a server to house new system.

  28. 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.

  29. Training Plan There are two types of training that the Team will be responsible for: Internal Training External Training

  30. Training Plan (cont.) • 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.

  31. Risks • Migration of System • Server crash • Completion of Project • Database will become too large • Hackers

  32. Current Project Status • Contract Signed • Documents Updated • Project Design • New web site • Development Server Obtained

  33. Questions ?

More Related