0115 966 7955 Today's Opening Times 10:00 - 20:00 (BST)
Place an Order
Instant price

Struggling with your work?

Get it right the first time & learn smarter today

Place an Order
Banner ad for Viper plagiarism checker

Developing of Online Enrolment System

Disclaimer: This work has been submitted by a student. This is not an example of the work written by our professional academic writers. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.

Published: Wed, 28 Feb 2018

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 university’s 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 team’s 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 Dep’t

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 project’s 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 system’s 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 user’s 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 University’s 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 client’s side and on the develop team’s 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 manager’s 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 project’s 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 project’s 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 risk’s 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 risk’s 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.


To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Request Removal

If you are the original writer of this dissertation and no longer wish to have the dissertation published on the UK Essays website then please click on the link below to request removal:


More from UK Essays