Developing of Online Enrolment System

Developing of Online Enrolment System Preface This software project management plan is intended to act as an outline of the development of a new honours system for Buena Vista College Administration. This plan will provide the structure and basis of the development of the new system. This includes outlining the deliverables, providing a schedule and organisational structure, and producing the associated plans needed for development of this project. This plan is intended to be used by the project team, as a development guide, throughout the life of the project, and by management as a reference to the details of the design as well as the progress of the project. 1.0 Project Overview The overview of the project provides a brief outline of the major details of the project, including identifying the project, stating what is expected form the project, and a summary of both schedule and budget. 1.1 Purpose, Scope Objectives The purpose of this project is to upgrade the existing enrolment system for Buena Vista College. The upgrade will consist of an added function, allowing administration staff to automatically compute students eligibility for entrance into honours programs. This new system will be integrated into the existing enrolment system. The project team will be restricted to adding the honours function only; fixing defects or adding other functionality is out of the scope of this project. The scope of the project does however include the implementation of any additional packaged software. The objective of this project is to meet the universitys business need of improving efficiencies, in order to lower operating costs and remain competitive. These needs are further defined below: v Overall quicker processing of applications to honour programs. Current methods are manual, making them both time consuming and prone to error. v A more effective handling of honors applications v Develop a readily accessible assessment report of current applicants v Develop a readily accessible honors entrance summary report 1.2 Assumption and Constraints There are several assumptions and constraints relating to the project team developing an honours system for Buena Vista College. They can be found in table 1.1 (below). Table 1.1: Assumptions, constraints and impacts Assumptions Impact on plan if false The group size will remain at five members through-out the life of the project The plan will need to be rescheduled to accommodate the change. Tasks will also have to be reallocated. The client has not specified a due date. The project will require heavy rescheduling, and possibly an outsourcing arrangement. The university will approve financing the system. The project will not go ahead. Client will be able to be contacted at all times May delay production, therefore extending the schedule. Constraints Impact on plan if false Project team is constrained by design of current administration system Project would be developed in a manner best suited to the project team. The plan would need to be recompiled, to conform to the new design. 1.3 Project Deliverables The following list specifies the elements of the project to be formally completed as a deliverable. A full list of both deliverable and non-deliverable work products is included in section 7.3. Table 1.2: Project Deliverables Statement of User Requirements and Acceptance Criteria Formally identifies the requirements of the system, specified by the client. This document needs to be reviewed and accepted cby the client. Software Project Management Plan Details the processes, tools and techniques that are to be used in the development of the project. User Documentation A manual for users clearly explaining system. System (Software) Formal hand over of new system to the client. 1.4 Schedule and Budget Summary The schedule and budget for this project is based upon the waterfall Software Design Life Cycle (SDLC) being adopted for this project. Table 1.3: Schedule and Budget Summary Phase Begun Finished Cost Requirements 04/11/2002 08/11/2002 $1,642.67 Analysis 11/11/2002 25/11/2002 $5,923.44 Design 26/11/2002 13/12/2002 $6,608.00 Coding 16/12/2002 03/03/2003 $36,216.00 Testing and Implementation 04/04/2003 25/04/2003 $6,308.31 TOTALS Project life is approx 125 days $56,968.42 The worst-case and best-case scenarios deviate less than 10% from the above summary. The full schedule and budget can be found in section 5.2.2 and 5.2.4 respectively, and in APPENDIX. 1.5 Evolution of the Project Plan This plan will be completed when it passes two criteria: v All elements of the Software Project Management Plan Template (Walden), are included in this document, and v The document passes a quality review, outlined in the Quality Assurance Plan (Section 7.4). At the completion of this document it will be labelled version 1.0 and shall be put under change control, whereby it may only be changed through the processes outlined in the Configuration Management Plan (Section 7.1). This process shall be made available to all members of the project team, as well as any member of management who requests it. Scheduled updates will be conducted at reviews undertaken at each milestone specified in the Project Reviews (Section 7.5). Unscheduled updates may be conducted at any stage during the development of the project, as long as the project manager approves changes. Regardless of whether the updates are scheduled or not, any change to this plan must comply with the change control plan outlined in the Configuration Management Plan (Section 7.1). 2.0 References Buena Vista College (1997) Configuration Management Plan v2.0, Buena Vista College Press, LOCATION Buena Vista College (2001) Quality Management Plan v3.1, Buena Vista College Press, LOCATION Buena Vista College (1999) Verification and Validation Plan v1.2 Buena Vista College Press, LOCATION Buena Vista College (2002) Work Product Plan v4.0 Buena Vista College Press, LOCATION IEEE Computer Society (1999) Volume Two: Process Standards, IEEE Inc.: New York, U.S.A. Walden, J. (1999) Software Project Management Plan Template v3.0, Department of Information Resources. PMBOK Rout Hodgen (2002) lec notes ROUT CASE STUDY SCHWALBE ALAVI M 1999 RUDOPLH EBERHADT LEC NOTES ON ESTIMATING ADD STANDARDS REFERED TO IN THE SUPPORTING PROCESS PLANS ALPHABETISE REFERENCES. 3.0 Acronyms and Definitions The table below shows all acronyms used and their definitions, in alphabetical order. Table 3.1:Acronyms Definitions (Alphabetical) Acronyms Definitions BVC CMP Buena Vista College Configuration Management Plan BVC QMP Buena Vista College Quality Management Plan BVC VVP Buena Vista College Verification and Validation Plan BVC WPP Buena Vista College Work Product Plan Client Buena Vista College Administration COCOMO Constructive Cost Model COSMOS Software Cost Modelling System FPA Function Point Analysis IT Group Buena Vista College Information Technology Group PM Project Manager PPR Post-project Review Project Team Members of the IT Group working on the system QE Quality Engineer SDD Software Design Description SDLC Software Design Life Cycle SPMP Software Project Management Plan SRS Software Requirements Specification SURAC Statement of User Requirements and Acceptance Criteria System Buena Vista College Administration honours system being developed by the project team TD Test Documentation TP Test Plan UD User Documentation 4.0 Project Organisation Project organisation involves identifying the external and internal interfaces as well as the roles and responsibilities of each member of the project team. 4.1 External Interfaces External interfaces summarise the relationship between the project team, the client, and any other entities associated with the project. This project does not have a true external interface existing between two parties, as both the acquirer and developer are part of the same larger organisation. The project shall exist in an environment separated from non-university bodies. The following table highlights the project teams organisational interactions and the interface/ liaison to each organisation. Table 3: External interfaces Organisation Role/s Interfaces with Project Team Develop of system Client IT Department IT Department Oversee project at highest level Client Project Team Buena Vista College Client; Managerial superior of IT dept and project team Project Liaison interfaces with Project Team IT Dept The Project Manager will be responsible for interfacing with anything outside of the project team. This includes the client liaison, the IT Director, and any other external body. It is important to mention that the IT Director has strong personal interest in this project, as he wishes to prove to the university that the IT department is a capable body. We expect that he will impact heavily upon the interface between the client and the project. Buena Vista College are both the client, and organisational superiors to all involved in the project. 4.2 Internal Structure The internal structure of Buena Vista College outlines the managerial hierarchy of the project team, identifying whom each member is reportable to. The structure also distinguishes the other known elements of the organisation, and their relation to each other. 4.5 Roles and Responsibilities The following table identifies the roles of each person in the team, and the subsequent responsibilities related to that role. Table 4: Roles and responsibilities Role Responsibilities Project Manager * conflict resolution * task allocation * project monitoring and improvement * project team leadership * liaise with both client and superiors Quality Engineer * review all deliverables for quality * produce quality plan * system testing System Analyst/ Designer * analysis * design * testing Programmers * coding * source code documentation * testing 5.0 Managerial Process Plans This section contains the managerial plans that shall be employed during this project. These plans are all subject to change and improvement. The plans have been created using both external knowledge, and personal judgement. External knowledge used includes IEEE standards and the PMBOK guide. 5.1 Start-Up Plan The projects cost and schedule shall be determined by how much effort will be required for this project. In order to determine the effort, the system size must be estimated. This shall be done using function-point analysis (FPA), and Constructive Cost Model (COCOMO) analysis. 5.1.1 Measuring System Size The FPA will yield an approximation to the systems size, which includes an estimate to the number of lines of code required. The FPA will be based upon the statement of user requirements; all data requirements, functions, and reports shall be approximated based upon the users specifications. Please be aware that the FPA is executed after the user the requirements have been gathered, and that the project has already begun. 5.1.2 Measuring Effort Required and Determining Schedules Measuring the amount of effort needed for this system can be measured in terms time required. Because the FPA provides an approximation to the size of the system, it can be used as the basis for measuring time required. Accordingly, the FPA results will be fed into a COCOMO analysis. Again, please be aware that this analysis is done once the project has begun, and does not include the effort required to gain, study, and synthesise the user requirements. The COCOMO analysis shall provide an estimate on the amount of time required to complete the project. The time required shall be displayed in a three phase breakdown; design, programming, and integration and testing. These phases shall then be broken down into activities, which shall be further broken down into tasks. Effort/time required for activities will be guided by the estimate provided in the COCOMO analysis. These estimations will be based upon the outlines given in section 7.2 of the PMBOK (Cost Estimating). In turn, the effort/time required for tasks shall be based upon the estimate for the activity that the task is part of. The COCOMO analysis has only been used to determine the effort required from schedule task 2.2 (Process Implementation), to schedule task 5.3 (Configuration Evaluation). To be more specific, the COCOMO product design phase includes section 2.2 to 3.2; the COCOMO programming phase includes all of section 4; and COCOMO integration and testing phase includes all of section 5. The schedule may be found in Appendix. A diagrammatic mapping the breakdown of work, or Work Breakdown Structure (WBS), is included in APPENDIX. The WBS shall then be used to calculate the project schedule, shown in APPENDIX. 5.1.3 Measuring Project Cost Cost is associated with three key indicators, size, quality, and productivity (Rudolph, 2002, p9). Unfortunately quality and productivity are too difficult to measure. Because system size can be measured in terms of effort, which is measured in terms of time, the hours required to complete the effort tasks can be translated to money (As staff pay can be calculated hourly.). By looking at the schedule, a monetary value shall be assigned to each resource used, eg. staff, hardware, training, etc. 5.1.4 Tools Employed in Calculating Size, Effort Cost The tool (application) that shall be used to conduct this analysis is known as COSMOS, created by East Tennessee Universitys Computer Science Department. The output of this application, the FPA, COCOMO, and Rayleigh Information, is shown in APPENDIX. The Rayleigh Information outputted by COSMOS shows how much time needs to be committed to the main building phase. 5.1.5 Staffing Currently, five staff are available for this project; one Project Manager, one Systems Analyst/Designer, one Quality Engineer, and two programmers. Not all staff will be required to work on the project at once. In the initial phase, the Project Manager and System Analyst are expected to do most work. As the project progresses more staffing shall be required. Programmers shall be employed during the intermediate phases, as well as a quality engineer. During this phase the project manager shall continue to manage and control the project, and the Analyst shall provide support, possibly in supporting areas such as process improvement. The Quality Engineer is likely to oversee the programmers, as well any processes that are subject to quality reviews. As the final phase is entered, the programmers shall be laid off, and also other staff, once their roles are no longer required. The project manager shall then hand over the completed product to the client. An approximation of the staff required through each phase is shown below. Detailed staffing schedules can be found in appendix. Table 5.1: Staff number and details by phase Phase Staff required Details Initial phase: Maximum 2 staff Project Manager Analyst Intermediate phase: Minimum 5 staff All staff Final phase: 1 or 2 staff Project Manager (Minimum) 5.1.5.1 Staff Sources The staff for this project will almost certainly come solely from the IT department. We doubt that contract personnel will be required for this project, as the IT group have more staff, which we expect to be free. If no additional internal staff available when the project requires extra staff, then contract personnel shall be considered. As all staff are familiar are with the development environment, we also doubt special expertise will be required. In the unexpected case that contract personnel are required, we shall approach an appropriate agency and seek the right person immediately. Little technical or managerial training will be required, as any contract staff must be experienced in the technical fields needed. Should the position be a managerial position, then managerial experience will be a prerequisite for such a job. 5.1.5.2 Staff Training All staff are currently familiar with the development environment so we do not expect that any technical training will be necessary. We do not know whether managerial training will be of benefit to the staff in this project, as such, no training will be provided. However, managerial process reviews shall be used in this project. These may uncover managerial weaknesses. Should this be the case, action shall be taken during the project, if feasible, otherwise, it shall be provided upon conclusion of the project. 5.1.6 Required Skills The client has specified a fairly basic system that is to operate in a Windows environment. Furthermore, the client stated that the system is a stand-alone system to run on one PC. Therefore, basic technical skills will be required. Our technical staff are certainly competent in such environments. Project management skills will also be required for this project, as well as knowledge in quality, and systems analysis and design. 5.1.7 Other Resources Required We do not expect any resources not already discussed in this document to be used. No additional hardware, facilities, contracts, or software is expected to acquired, both on the clients side and on the develop teams side. 5.2 Work Plan This section explains about work activities, schedule, resources, and budget details for the project. Some parts of the sub-section will refer to appendix or other sections. 5.2.3 Work Activities Waterfall model has been used to satisfy the requirement of BVC. Work activities involved in the work breakdown structure are: v Requirements v Analysis v Design v Coding v Testing v Project Management For a full description of their relationships and details, refer to section 6(technical plan) and appendix WBS. The acceptance criteria for the project lists the necessary task that are to be completed for the client to accept the product. A copy of the Acceptance Criteria is attached in section 6. Risk management processes relevant to these activities, including risk tracking, is included in section section 5.4 The relationship between a task and its predecessors and successors is illustrated in appendix msProject. 5.2.2 Schedule Allocation After establishing WBS, the tasks were entered into Microsoft Projectà ¢ 97, and the estimated schedule was created. This was completed by assigning a time period to each task. The schedule has been provided in the appendix msProject. 5.2.3 Resource Allocation Resource allocation assigns resources, as in staff and tools provided, to control activities within the WBS. These resources for each task are listed in section 6. 5.2.4 Budget Allocation Budget Allocation place a key role in any project. It estimates cost of resources and tools needed to conclude project activities. The budget for this project was calculated using Microsoft Projectà ¢ 97, using resource allocation, and expected pay-rates. A copy of the budget is provided in msProject. 5.3 Control Plan This section describes how the project will be monitored and controlled using the following plans. 5.3.1 Requirements Control Plan Any changes to the product requirements will be managed through the configuration management change control process, summarised in section 7.1. A requirements tracability matrix will be provided in all documents referencing the requirements, this will provide a direct link back to each requirement of the system. Impact analysis and change approval processes are described in Configuration Management, section 7.1. 5.3.2 Schedule Control Schedule control for this project will require inputs to control, control techniques, and outputs such as updates and corrections. The schedule will be monitored using the following inputs. v Project schedule: See Appendix for the project schedule. This will provide the basis for measuring and reporting schedule performance. v Performance reports: These reports provide information on schedule performance, such as whether deadline dates are being met or not. They shall also help the team stick to schedules, and alert us issues that may cause future problems. v Change requests: Schedule changes may be required to extend or shorten the project. Change requests for this project must exist formally as a document, and may originate internally or externally. A schedule control system shall use the above the inputs to manage changes to schedule. When changes to occur, additional planning must be done for compensation. A MS Project file will be updated to accommodate these changes. 5.3.3 Budget Control Budget control will be undertaken by the project manager, and include affecting any changes to the cost schedule, monitoring the cost baseline and determining any changes to the schedule and managing those changes. Changes to the budget schedule shall be influenced as much as possible by the project manager, to create the least effect on the plan. To monitor the budget, the project manager will receive periodic reports on the status budget, detailing what is under, over and on budget. Based on this information, Based on this information, the project manager will be able to assess any difference from the planned budget and determine if the variance is significant enough to require further investigation. If further action is required, then the type and extent is left to the project managers discretion, based on the particular case. Earned Value Management (EVM) will be used to monitor the budget compared to the amount of work completed. Through these techniques, the project manager will be able to determine if there are any changes to the schedule. If the schedule has changed, the project manager will need to reassess the schedule, taking into account these new developments. The project manager will also have to ensure that the changes to the budget will not affect the scope of the project by having to leave out some tasks due to budget constraints. Cost reporting of each task will be determined based on its size and budget. Large and expensive tasks will be reporting more frequently than small and cheap tasks. The period between reports is chosen by the project manager on a case-by-case basis. 5.3.4 Quality Control Plan The details of the Quality Control Plan are outlined in the Quality Assurance Plan, (section 7.4). The Quality Assurance Plan describes the measuring and controlling mechanisms used to assure the quality of the work processes and products. These mechanisms include audits, joint reviews, process assessments, and quality assurance of the processes. 5.3.5 Reporting Plan This plan highlights the reporting mechanisms, formats and frequencies of the reporting structure of the project. These relationships are displayed in table 5.2, below. Table 5.2: Reporting and Communication plan Communication From To Time Period Action plans Audits Minutes of meetings Risk Assessment Schedule checks Progress of assigned tasks All group members Project Manager Weekly 5.3.6 Measurement Plan All project measures, where not predetermined by either Buena Vista College, or any other external requirements, will be agreed upon by the project team based on the projects main issues. These details will be formally recorded in the Measurements Recording Form (Appendix #). The metrics used in the measurement plan will be collected at two processes in the development lifecycle, at the verification and validation processes, and at the end of the project. These measures will be collected mainly through interviews and reports at each of these times. The collected data will then be validated and stored by the project manager. 5.4 Risk Management Plan The risk management plan is designed for the development team to recognize any risk that may have a clashing affect to the projects schedule, budget and quality. The risk management covers the identification of risk factors, the assessment of the possible severity and likelihood of the risks, definition of management strategies for avoiding and containing risk, and the means for ongoing monitoring of the risk factors. 5.4.1 Risk Factors Identified Risk factors that were identified early in the project are listed below. During the life of the project the PM may find more risk factors that may affect the schedule and budget of the project. The PM will record each new risk factor in a Risk Identification Form (Appendix #). The risks presently identified are: v Conflict with team members v Staff skills and competence v Functional Rise v Conflicts with client/Customer v Low quality v Low productivity v Consistent to standards v Business Risks (absence caused by illness of accident of involved stakeholder.) v Loss of client. v New/Old technology conflicts. v Client Acceptance v Availability and use of Resources. 5.4.2 Risk Assessment Each risk factor identified was assessed on the likelihood and severity of it becoming an issue. Each assessment gave a value of 1 to 10, where 1 was low and 10 was high, indicating its importance. The assessment for each risk factor gave the reasons for the risk, impact of the risk, monitoring of the risk, and the resolution of the risk. With this detailed assessment of the risk factors a top ten risks identification and report was created. Also a risk matrix was created of each risks likelihood and severity. The project risks can be founding APPENDIX. 5.4.3 Risk Management Strategy Impacts of the risks on the project will be the cost, schedule and quality of the product. The PM must understand that risks are part of the day-to-day operations of the project. As part of the risk management strategy, the PM must conduct weekly reviews on the status of the current top-ten risks, and continually be aware of the development of any new risks. Any new risks identified must be formally recorded in a Risk Identification Form (Appendix #). Once identified, if in the top-ten, a risk has a contingency plan developed in case it becomes an issue, and is continually monitored. If a risk eventuates and becomes an issue, it will be recorded, its contingency plan will be started, and a group member will be assigned to handle the issue. These procedures are outlined in Issue Management, section 7.6. The PM must also be able to produce a report on the current status of the risks to any stakeholder if required. 5.4.4 Top Ten Risks Identification The top-ten risks identification highlights each risk and its details. It identifies each risks probability of occurring, 1 10(high), its severity and exposure (probability of occurrence * severity), the problem resolution technique, who is responsible for monitoring the risk, and the time period of the risk. Table 5.3: Top Ten Risks ID Item Prob Loss Exp Resolution Who Date 1 Conflicts with team members 6 8 48 Group Meeting PM Cont 2 Resource Availability 4 9 36 Reschedule PM Cont 3 Low Productivity 4 8 32 Inspection PM Cont 4 Consistent standards 5 6 30 Inspection PM Cont 5 Low Quality 4 7 28 Inspection PM Cont 6 Client Acceptance 4 7 28 Client meeting PM Hand -Over Phase 7 Conflict with Client 4 7 28 Client meeting PM Cont 8 Staff skill and competence 3 9 27 Training PM Cont 9 Functional Rise 2 9 18 Reschedule PM Cont 10 Absence of a stakeholder 2 9 18 Reschedule PM N/A Cont = Continuous (on -going) Below is example report kept by the PM to monitor risks in the project. The PM must have a current copy of the report. He must be able to show the report when requested by a stakeholder. Table 5.4: Risk Report Item Rank Now Last Time Time List Resolution Conflicts with team members 1 New 0 Have a group meeting. Resolve differences among the team members Resource Availability 2 New 0 Get more resources Low Productivity 3 New 0 Use Software process improvement methods. Consistent standards 4 New 0 Check QA plan. Low Quality 5 New 0 Design a Quality Model to achieve software quality standards Client Acceptance 6 New 0 Rework project until the client is satisfied. Conflict with Client 7 New 0 Talk with client and resolve issue Staff skill and competence 8 New 0 Train Staff Functional Rise 9 New 0 Redo Schedule for project. Absence of stakeholder 10 New 0 Redo Schedule for project. 5.4.5 Risk Matrix The risk matrix identifies the top-ten risks in terms of their likelihood of occurrence and severity. Items towards the top-left of the matrix are both probable and severe, and should be monitored carefully. Items towards the bottom-right are improbable and have a negligible impact on the project. Table 5.