Enrolment System

Published: 2021-06-19 00:10:05
essay essay

Category: Information Systems

Type of paper: Essay

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Hey! We can write a custom essay for you.

All possible types of assignments. Written by academics


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) 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. 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.5: Risk Matrix
Likelihood of Occurrence Severity Probable (10 -8) Occasional (7 – 5) Remote (5 -3) Improbable (2-1) Catastrophe (10 -8) · Conflict with team members · Staff skills & competence · Resource Availability · Functional Rise Critical (7-5) · Conflicts with client · Low quality · Low productivity · Client Acceptance Marginal (5-3) · Consistent to standards Negligible (2-1) · Technology conflicts · Unexpected absence · Life cycle model · Lost of client · Aggressive client
5.5 Closeout Plan
Upon finalization of this project the following closeout tasks will be required. Project staff will be re-assigned to their old jobs, or allocated to new projects. All project documentation will need to be stored in the IT Group’s projects archive. Finally an analysis of the project’s performance and success shall be performed, so that lessons may be learned.
5.5.1 Staff Reassignment
The staff involved within this project will either be re-allocated to their previous roles, or assigned to a new project. It must be pointed out that the future cannot be read, and that the case study (Rout, 2002) does not indicate the organisational structure of the IT Group. Staff members may have been working on other projects or fulfilling other roles, of which they would return upon completion of this project. Considering these facts, we can only speculate that the Project Manager will almost certainly be assigned a new project, and other staff member’s future is not known (Project staff will remain employed, but in what roles or projects, we cannot know based our information.).
5.5.2 Archiving Completed Project
All materials and documents created during this project will be stored in electronic format in the IT Group’s project system. With the correct authorization, the materials and documents can be retrieved from this system at any time over the university network. Copies of the entire project will be burnt to CD-ROM and delivered to the client, and also to the IT department manager as a backup.
5.1.3 Reflection: Success, Performance & Lessons Learned
Measuring the group’s performance will allow the group to determine whether they feel they were successful or not. Most important it will provide lessons for the group. It is important to transfer this knowledge somehow, so that the organisation may remember it. Knowledge Transfer Plan
As described by Rout & Hodgen (2002), a project is on temporary endeavour to produce a unique product or service. Projects are always unique, however there are many similarities between them (Which is the reason for existence of the PMBOK and project management standards.). Knowledge gained relating to project management techniques used within this project may be applied to future projects in order to save time and or money, and to avoid known problems. The main goal of this knowledge transfer plan is to reduce the learning curves of future projects: this will provide scale advantages against competitors (eg. Another university.). We believe the best way to facilitate the transfer of project management knowledge is in the explicit form (Recorded in a prescriptive form.), as opposed to the tacit form (A reference to the person/thing holding the knowledge). This could be in the form of a knowledge database for project management. Knowledge could also be transferred outside the project management domain, specifically, in the IT Group’s key knowledge domain, software. The IT Group’s majority of projects will involve the creation of software systems. A software principle or technique learnt in project could almost certainly be transferred to another project. To facilitate this process, we suggest a similar idea to the above: the creation of a software engineering knowledge database. Creating the above two systems is outside the scope of this project, however, with their existence, project members have an invaluable tool to use during projects. Project members would use it to record improvements upon project management or software engineering methods, and most importantly, they could use to see how previous projects dealt with whatever they are dealing with. Essentially, such systems teach, or remind project members how to do things, and also allow the knowledge within them to be refined.
5.1.4 Maintenance and Future Developments
Upon the completion of this project, it is expected that maintenance system will be required. There are two possible types of maintenance that will be required, ongoing, or one-off. Should the need for ongoing maintenance be identified, this project team shall be reformed, so long as the members are still employed by Buena Vista. Because a straight through SDLC has been adopted for this project, it may be difficult to make changes, in the least, we expect it to be more expensive.
6.0 Technical Process Plans
This section justifies the process plan of the system, which focuses on the life cycle model, which is being used as a model to implement the system. Methodologies and tools will also be addressed to define technical part of the project plan. Product delivery and operation are mentioned in the last section.
6.1 Process Model
The waterfall model is chosen for the system implementation for the reason that it is plainly ideal to the problem situation, as the functional requirements are well known. The model involves 5 stages of processes, which are requirements, design, testing, and installation. Each project member is assigned some tasks for the duration of the project to engage and apply the model’s process (Refer to …). Here are some justifications of the using of waterfall model: v Requirements derived from SUR are clear. v There will not be major changes in the requirements. v The size of the system is considerably small. v System implementation will be done in an internal area. v There is no time constraint.
Table 6.1: The following table shows exit and entry criteria of each phase in waterfall model.
Phase Description Entry Exit 1 Requirements · Project initiation · System User of Requirements. · Validation of SUR. 2 Analysis · Specification of User Requirements. · Specification of life cycle model. · Documented analysis of SUR. 3 Design · Analysis of SUR. · Knowledge of system modelling · Implementation of system’s life cycle model. 4 Coding · Documented functional requirements · Knowledge of system encoding · Potential system. 5 Testing · System coding · Final product. 6 Installation · Installation guide · System operational 7 Maintenance · User manual · Organised product 8 Managerial · Continuous activity from project initiation · Termination of project. From the preceding table, key milestones are found after exit criteria are met. By the date of : v 8 November 2002, SUR document is established. v 26 November 2002, document of SUR analysis will be designed. v 13 December 2002, a life cycle model is chosen and the system design is done. v 3 April 2002, a software is developed. v 25 April 2002, a potential software is ready to be delivered after testing is done.
6.2 Methods, Tools, & Techniques
The table below lists methods, tools, and techniques used.
Table 6.2: Methods, tolls and techniques used.
Project Development Plan Given to develop project plan for the new system. Quality Assurance Refer to … Risk management Managing risks that may occur during the making of the system. System Analysis and Design Carry out the analysis and design development of the system. System User Requirements Enclose functional requirements as a guide all along the development plan. Scheduling Used as a guide in order that process plan can be done in accordance to Waterfall model This software life cycle will be used as a representation of system development. Some standards and policies will be used in applying the methods and techniques above. v ISO/IEC 12207 Information Technology Software Life Cycle Processes, Work Breakdown Structure. v ISO 9001 Quality Systems Model for Quality Assurance in Design/Development, Production, Installation and Servicing. v IEEE 830 Software Requirements Specifications.
6.2.2. Tools
The following tools are to be used during this project Microsoft Word Document the system process. Microsoft Project Record activities of work breakdown structure and also apply function point analysis in the file. It also simplifies the creation of project chart and diagrams. Microsoft Excel Document activities and tasks of WBS. Microsoft Access Testing of new system can be made in Microsoft access. COSMOS Estimate project time schedule. SQL (database) Use as a tool to build the system. PMBOK A guide to manage a project.
6.3 Infrastructure Plans
The new system will run in an equal version of operating system within Buena Vista College. v Windows® 1998, Windows® NT, or Windows® 2000. v Microsoft Access® 97. Please see section 4.2 for the project team infrastructure.
6.4 Acceptance Plan
Following the completion of each phase, reviews will be carried out by the person involved in the process. A project member who isn’t involved in the phase development, but has a good knowledge of it may be able to review the process to provide a different point of view which can give the person involved, who’s responsible with the phase development, a fresh idea. The completion of a phase will be reviewed against acceptance criteria (SUR). Before the acceptance of the final product, each project member has the following tasks: v Project Manager: Apart from having the responsibilities on planning the project, Project Manager will be involved in review all phases being done by project members. v System Analyst: Review system requirements and acceptance criteria provided in the System User Requirements. v Quality Manager: Review the standards of the whole project. v Programmer: Review System Analyst’s documentation and the coding of software. For user acceptance criteria, refer to Appendix…
6.5 Deployment Plan
The system operation will be installed in the existing operating system. According to SUR, the new system will operate on a single IBM compatible computer running Windows® 98/NT/00. The college system must have Microsoft Access to run the software. An installation guide will be given to users lest they had trouble shooting with the system execution. Also a user manual will be essentially handful to guide users in operating the system. Prior to the use of the system, it is strongly suggested for users to be given some training in advance. Although the system is not complex, users who are not familiar to computer system environment will see it as a good idea. Project delivery will be conducted by Project Manager, while the training can be performed by Programmer.
7.0 Supporting Process Plans
The supporting plans aid in the development of the product and are used extensively throughout the lifecycle of this project.
7.1 Configuration Management Plan
All project deliverables shall adhere to the standard Buena Vista College Configuration Management Plan based on IEEE Std 828-1998, Standard for Software Configuration Management Plans. This plan details the processes to be completed for the submission/ change of any of the deliverables. This plan outlines both software and document configuration processes. After the formal quality review outlined in section 7.4, of each work product, and the product is finalised, it will then be labeled version 1.0 and put under change control. Any change thereafter will need to go through the change control process. Any problems identified will be brought to the attention of the IT group through a problem identification form (Appendix …). Any requests for change must be formally made through the change request form (Appendix …) which allows for the change/s to be reviewed by both the quality manager and the project manager. If approved, the item/s to be changed are released to the person in charge of the changes, then returned once completed. The details of who made the changes and the corresponding dates is kept in the configuration log (Appendix …). After each document is finalised or changed, the baseline is updated and recorded on the baseline control form (Appendix …). This ensures anyone wishing to read or change a work product is able to find the current version.
7.2 Product Testing and Reviews Plan
All processes, techniques and tools used in the verification and validation of the work products and activities are outlined in the Buena Vista College Verification and Validation Plan. Several methods of review will be used in the verification and validation of the work products. Each work product, its type of review and the participants of that review are listed in the table below.
Table 7.1: Work products’ reviews
Work Product Review Participants SURAC CL, PM SPMP PM, QE TP PM, QE SRS PM, QE, SAD SDD PM, QE, SAD TD PG, PM, QE, SAD Product CL, PM, QE CL – Client; PG – Programmers; PM – Project Manager; QE – Quality Engineer; SAD – Systems Analyst/ Designer Identify which work products will receive what types of peer reviews (such as inspection, walkthroughs, and technical reviews) and what roles will participate in such reviews. Testing will also be undertaken throughout the duration of the lifecycle. Based on the testing activity, various methods of will be undertaken and different people will be involved in the plan, review, development and implementation of the test. These details are displayed in the table below.
Table 7.2: Work products’ testing details
Responsibilities Testing Type Plan Plan Review Development Testing Test Review Unit Testing SAD, QE PM, QE PG PG QE, SAD Module Testing SAD, QE PM, QE PG PG QE, SAD Integration Testing SAD, QE, PM PM, SAD, QE QE, SAD QE, SAD QE, SAD, PM Acceptance Testing CL, PM, QE CL, PM, QE CL, PM CL, PM CL, PM CL – Client; PG – Programmers; PM – Project Manager; QE – Quality Engineer; SAD – Systems Analyst/ Designer
7.3 Documentation and Work Product Plan
The processes, tools and techniques used to generate both deliverable and non-deliverable products is identified in the Buena Vista College Work Product Plan. The development of this product will include the following products. v Statement of User Requirements and Acceptance Criteria (SURAC) -formally identifies the requirements of the system, specified by the client. This document needs to be reviewed and accepted by the client. v Software Project Management Plan (SPMP) – details the processes, tools and techniques that are to be used in the development of the project. v Test Plan (TP) – specifies the methods, tools and techniques used in the testing processes of the product development. v Software Requirements Specification (SRS) – clearly details the technical aspects of the requirements expressed in the SURAC. These details specify the functionality, quality and interface characteristics of each function. v Software Detailed Design (SDD) – formally specifies a detailed design of the system to be developed. This document aids in the coding of the system. v Test Documentation (TD) – records all testing data created through the testing phase of the lifecycle model, as well as all the test cases used. v User Documentation (UD) – provides a manual to the users clearly explaining the new system. v Post Project Review (PPR) – reviews the development of the project, critically analysing the methods, tools and techniques used, as well as comparing actually resources spent to predicted resources needed. Each of these products shall adhere to a standard and be prepared and reviewed by, and distributed to various people. Table 7.3 identifies these details.
Table 7.3: Work products’ personnel details
Work Product Relevant Template or Standard Prepared By Reviewed By Distributed To Configuration Management Plan BVC – CMP PM PM, QE ITG Documentation and Work Product Plan BVC – WPP PM PM, QE ITG Issue Management Section 7.6 PM PM, QE ITG Process Improvement Plan PM PM ITG Product N/A ITG ITG CL Product Testing and Reviews Plan BVC – VVP QE PM ITG Project Reviews PM, QE PM, QE ITG Quality Assurance Plan BVC – QMP QE QE, PM ITG SDD IEEE Std 12207 SAD PM, SAD, QE PG SPMP IEEE Std 1058 PM, QE PM, QE ITG SRS IEEE Std 830-1984 SAD PM, SAD, QE SAD Subcontract Management Plan PM PM, QE ITG SURAC IEEE Std 1233 PM CL CL, ITG TD IEEE Std 1012 ITG ITG ITG TP IEEE Std 1012 SAD PM, QE ITG UD N/A SAD, PG PM, SAD, QE CL CL – Client; ITG – IT Group; PG – Programmers; PM – Project Manager; QE – Quality Engineer; SAD – Systems Analyst/ Designer These work products will adhere to all procedures specified in the Work Product Plan.
7.4 Quality Assurance Plan
To maintain a high standard of quality, all work products shall abide by the Buena Vista College Quality Management Plan based on IEEE Std 1490-1998, IEEE Guide – Adoption of PMI Standard – A Guide to the Project Management Body of Knowledge and IEEE Std 730-1998, IEEE Standard for Quality Assurance Plans. This plan outlines the process for quality reviews, which will be conducted on all work products. These products will undergo a quality review at least a week before the due date. These quality reviews shall ensure that the deliverable is following the standard for that product, and that it addresses all necessary components expected. The quality review shall also ensure that the project is meeting the client’s needs, and not becoming sidetracked. To assist in these reviews, the quality engineer shall produce customised checklists for each work product. If a work product does not pass all the criteria of the checklist, then those problems must be fixed before it is considered completed. There shall also be joint reviews, audits, and process assessments, as described in the Buena Vista College Quality Management Plan, at each milestone of the project. These shall ensure the project is running smoothly and is on track to meet the client’s requirements.
7.5 Project Reviews
At a minimum, reviews will be conducted at the end of phases. Two types of phases exist in this project, the waterfall model phases, and the project management phases. These two phases will exist in parallel during the project. Each waterfall phase will have one or more deliverables required. A deliverable will be a physical object, such as a document, prototype, final system, design, etc. At the end of each phase, the deliverable/s and the project performance to date will be reviewed. Currently we do not know how regularly waterfall reviews will be needed, we expect this occur to weekly, or fortnightly. Reviews on project management processes are harder to define. Considering that the project will take 4 months, it would be good to review the processes at least once per month. In the initial month, additional reviews will be conducted to prevent a drawn out start to the project. The schedule does not accommodate such reviews, however, there are times when staff are free, and could do such tasks. The reason for review at the end of each phase is twofold. Firstly, the project needs evaluation as to whether we should enter the next phase. It might be that the project is no longer feasible, for whatever reason. Secondly, project performance should be reviewed mainly to keep stakeholders informed on how resources are being used to meet project objectives. Performance reporting can also be a useful self-check tool. The performance review process includes is described in sections 7.5.1 – 7.5.3. Techniques that shall be employed include earned value analysis, variance analysis, and trend analysis.
7.5.1 Status Reporting
Status reports shall be conducted weekly/fortnightly and also at the end of each phase. The project manager will create these reports, as s/he has the clearest view of the overall picture. The status report will show how the project stands at a specific point in time. It will address things such as the triple constraint of scope, time, and cost, and whether these are being controlled well enough. Questions such as “How much has been spent? How much time has been required?” and “Is the work being completed as planned?”. These reports shall be tailored to the stakeholders needs, and size of the project. Earned Value Management, as described in Schwalbe (2002, p175), will be used as it integrates scope, time, and cost data. This will be compared against this project’s baseline, once it is completed. Another technique that shall be used is variance analysis, which will show actual project results against predicted project results. This will help keep the project under control.
7.5.2 Progress Reporting
Instead of being conducted at the end of phase, progress reports will be conducted weekly, or fortnightly. This time interval for these reports will be known once the project has begun. Team members will be required to submit their reports at the end of each period. The project manager then will create a consolidated progress report.
7.5.3 Project Forecasting
Project forecasting, at minimum, will take place at the end of each phase. Past information on how the project has performed and trends shall be used to predict future project status. Earned Value Analysis shall be used here also. Questions such as “how much more money is needed to complete the task” shall be asked. Trend and variance analysis will be used here. Trends can be used to predict the future state of the project, based on the past states. Variance analysis will provide an indication, but will not be as useful as trend analysis in forecasting. The project manager will be responsible for this.
7.5.4 Status Review Meetings
Status meetings shall be held periodically to collate and share project information. Currently, three types of status meetings have been decided upon. The project team itself is to meet regularly, at the same frequency required for the progress reviews. In fact, the progress review could be formulated during this meeting. All project members will be expected to participate. The second review meeting is to be between upper management, Tom Walters, and the project team. It shall be compulsory for the project manager to attend these meetings; other project staff may be at such meeting, should there be a need. This meeting is expected to occur less frequently than the project meetings, but how regularly, we do not know. We expect that upper management will be responsible for scheduling these meetings. During these meetings the project manager shall present the status, progress, and forecast reports to Tom Walters. The reports may require modification from Mr Walters before being presented to the client. Feedback from Mr Walters shall be given to the project manager. The third meeting type is between the customer, College Administration, and the project team. These meetings may involve the presence of Tom Walters (Upper Management). Progress, status, and forecast reports shall be presented to the customer during these meetings, as well as any deliverables such as prototypes, user requirement documentation, etc. These meetings will be important to ensure that client is getting what they have specified. An iterative approach shall be undertaken, which will allow much confirmation of the client’s needs. Any problems with the project shall be presented, and resolved.
7.6 Issue Management Plan
Issue management is necessary to the completion of a successful project by providing a way to handle all risks, identified or otherwise, when they become issues. When any risk becomes an issue, an Issue Report Form (APPENDIX #) must be completed by the person/s who first noticed the issue. This form is then to be sighted and signed by the project manager, acknowledging the issue. The project manager is then to assign the responsibility of monitoring and implementing an issue minimization strategy to a member of the group. If no existing issue minimization strategy exists, a new strategy will be created and executed. The monitoring and controlling of the issue will be recorded in the Issue Monitoring Form (APPENDIX #), recording the status and impact of the issue, as well as the minimization strategy. The Issue Monitoring Form is to be completed by the person responsible for monitoring and controlling the risk, on a weekly basis. This is to be done until the issue is handled and no longer relevant to the project.
7.7 Subcontract Management Plan
Two facts indicate that subcontracting will be an unlikely need in this project. Firstly, all staff are familiar the development environment required for this project. Secondly, the project is not a large project. Nevertheless, should subcontracting be required, a plan based upon the guidelines within the PMBOK shall be used. A brief description of processes of this plan is discussed below. It is worthy to mention that the following processes will overlap, both with each other, and other project management areas (communications, risk, etc.). The complete description of the following processes can be found in section 12 of the PMBOK.
7.7.1 Procurement Planning
During the progression of this project, situations may arise where the project team may needs goods or services from external sources. The first step that shall be taken is to carefully consider the advantages and disadvantages of outsourcing. After this we shall determine how to procure, what to procure, how much to procure, and when to procure. During this processes we may need to seek expert knowledge from bodies such as consultants. Two key outputs from the step shall be a procurement management plan, which describes how the following processes will be managed. The second output we shall make is a statement of work, which describes the goods or services that must be provided by the vendor.
7.7.2 Solicitation Planning
This processes creates the documents required to support the solicitation execution. These are defined in section 12.2 of the PMBOK.
7.7.3 Solicitation Execution
The process will involve obtaining and advertising quotes, bids, offers, etc. This is further defined in section 12.3 the PMBOK.
7.7.4 Source Selection
After receiving all offers, a vendor shall be selected. The decision on which vendor to choose will rest upon a complex set of criteria, including price, expertise offered (quality), the organization culture of the vendor (which may clash with Buena Vista), vendor stability, etc. Frameworks for selecting vendors can be found in many IS textbooks, which is what shall be done. A key output in this process is the contract with the vendor, which is legally binding.
7.7.5 Contract Administration
Once a vendor begins working on the project, things such as performance reporting, change control, payments, legal issues, etc will be dealt with. See section 12.5 of the PMBOK. In this processes, we shall ensure the vendor employs a quality assurance plan, a configuration management plan, verification and validation plan, review plan, problem resolution plans, and audit plans: we shall monitor the vendor’s use of these plans.
7.7.5 Contract Closeout
Signing off with the vendor will include verification of what they provided, and formal administrative closure. This is further defined in section 12.6 of the PMBOK.
7.8 Process Improvement Plan
Competitive pressures continuously force organizations to improve upon their processes. Unfortunately, we feel that competitive forces at Buena Vista are not strong because universities don’t compete as fiercely as private institutions. We expect that this weak competitive environment may cause the IT department to be lazier than its private equivalents, and lack the drive to improve itself. This may result in less efficient and or less effective development processes. To counteract this threat, a process improvement plan has been developed, which will be implemented fairly aggressively. The plan must be implemented aggressively because if it is implemented casually, the easygoing culture of the IT department may render the purpose of process improvement effective. The improvement plan will be based upon two management paradigms, total quality management, and knowledge management. Total quality management seeks continually remove the cause of problems from the bottom-up (In organizational terms.). Knowledge management, fundamentally, is concerned with sharing best practices, increasing efficiency, and supporting innovation within an organization.
7.8.1 Process Improvement Plan
At the start of the project, a seminar on process improvement and its importance to the IT Department shall be conducted. It is important that all project staff have the importance of process improvement drilled into them early in the project. As the project progresses and improvements or problems are found, the staff member who made the discovery will complete a “Suggested improvement or problematic process” form, which is delivered to the Project Manager. The project manager then enters the improvement in to the knowledge database system mention in section The initiatives above will not be useful unless an innovative culture is fostered within the IT Department. Cultural change is a difficult goal to achieve. All project staff will need to be periodically reminded of process improvement. To further assist this mindset change, creativity needs to be fostered. This could be achieved in many ways, from brainstorming sessions, to a change in layout of office furnishings. The process improvement plan is more of an ongoing process than a plan. It is detached from the project itself, and exists within the IT Department itself. It shall be adopted throughout all stages of the project, initiating, panning, executing, closing, and control; and in future projects also. In terms of knowledge management, the project manager shall motivate staff to learn more about their fields, and the fields of other project staff. Methods that may be employed are the system mentioned in, as well systems external to the organization, such as discussion boards or open-source web sites. Staff will be persuaded to attend industry conferences and seminars (Such events may be exist outside the project’s time scope, but as mentioned, this plan is partially detached from this project.).
Document Control Appendices
Risk Conflict with team members Impact The schedule of the project will be delayed; morale of team will be low. Monitoring To over come this problem PM talks to members in the team. Check the team progress and how things are going. Proactive Action Choose members that have worked in teams and have a good working history. Contingent Action Have regular group meeting to resolve the group differences. Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 6 8 48 1 Risk Staff skills and competency Impact Cost surpass projection, time constrains won’t be met and quality compromised Monitoring PM monitors the amount of work being done Proactive Action Train all staff to have competent qualification /skill or hire staff that are qualified for specific project needs. Contingent Action Get resources and train all staff members to the level needed to complete the project successfully. Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 3 9 27 8 Risk Functional Rise Impact The project will be delayed. Increased cost of the project. Low quality as things are rushed. Monitoring Development Team must be able to incorporate additional requirements that may be needed or added to satisfy the customer. Proactive Action PM helps accurate estimation of what is neededand ensures the user is happy with requirements by joint reviews, and verification of requirement Contingent Action A schedule should scope adequately rework must be done to accommodate new requirements (should not be overly optimistic) Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 2 9 18 9 Risk Conflicts with client/Customers Impact Team member may quit new members are to be hired as a result Project schedule will be delayed. The staff members may poorly construct the product. Monitoring Team must advise the PM on any conflict they may have with the client. Proactive Action To clarify with client and provide him an idea of the product and software development process. Contingent Action PM should talk to teams members and client and resolve the problems. Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 4 7 28 7 Risk Low quality Impact Client will not accept the product if it doesn’t meet their requirements. Additional time and cost to fix needed attributes to satisfy the client. Monitoring PM monitors the work done by staff is up to the mark. Proactive Action Have member briefed on what is needed for the user and developer point of view by using a Software Quality Model. Contingent Action Design a Quality Model. Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 4 7 28 5 Risk Low productivity Impact That the project‘s schedule will be delayed. Monitoring PM monitors the current progress to the estimated progress of the plan Proactive Action To have members that are highly productive, needed resources provided. Contingent Action Have a meeting. Use software process improvement. Rework schedule for the project Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 4 9 32 3 Risk Consistent to standards Impact That the software will not satisfy the client, as standards have not been accomplished. Rework and increased cost and delay to fix problem. Monitoring PM to make sure that all work of team members conforms to all standards, including software standards and client requirements for the product. Proactive Action Team members briefed on the quality standards for the project. Contingent Action Rework to accommodate the quality standards Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 5 6 30 4 Risk Business Risk (absence caused by illness or accident of involved stakeholder) Impact The project will have a schedule delayed Monitoring PM must make if sure staff members are sick that the project is not badly delayed. Proactive Action Keep staff members updated with other parts of the project. critical part have buddy system. Contingent Action Rework the schedule. Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 2 9 18 10 Risk Loss of client Impact The project is cancelled. Monitoring PM should make sure that there is a line of communication with the client. Proactive Action Frequent feedback from client Contingent Action PM must either get a new client or cancel the project Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 1 10 10 13 Risk New/Old technology conflicts. Impact New technology may effect the existing technology used in the project. May effect work environment. Monitoring PM monitors the effect when new technology is used in the project team. Proactive Action Do not introduce new technology unless team is confident about using it or necessary to complete the user’s requirements. Contingent Action Use exciting technology, staff is related to or provide training. Reschedule Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 3 4 12 12 Risk Availability and use of resources. Impact Resources maybe unavailable during the schedule of the project. This will lead to schedule delays and over budget. Monitoring PM must monitor when resources become unavailable to the project. Proactive Action The PM should adecquately and accurately analyses all resources needed to complete the project successfully. Contingent Action A reschedule the project to accommodate lost time. Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 4 9 36 2 Risk Client Acceptance Impact The client does not accept the delivered product. ( not satisfied) Monitoring PM must get client feedback during the project development. Proactive Action To have a good client relationship and understanding of their needs Contingent Action
Examine the cause of rejection of deliver product. Fix what needs to be done get client satisfied. Reschedule
Likelihood 1 – 10 Severity 1 -10 Risk Exposure Rank 4 7 28 6 Risk Identification Report Reported by: Date: Risk identified: Risk impact: Risk probability: Project Manager signed: Date: Measurement Recording Form Measurement ID Description Collection Technique Acceptance Criteria This appendix characterize the mandatory criteria based on SUR. To successfully complete the project, these criteria must be implemented to be accepted by client afterward.
Data Requirements
DR01 The system will store a student record for each student applied for Honours year. DR02 The system will store Student Details contain personal information. DR03 The system will store Student Record contain Student Details and some information relate to Honours studies. DR04 The system will store Proposed Study Program contain program code and title. DR05 The system will store Course details such as course code, title, etc. DR06 The system will store Proposed Course List contain one or more courses. DR07 The system will support a report from each examiner and the student’s supervisor. DR08 The system will store grade for Thesis/Dissertation. DR09 The system will store names and addresses of student supervisors and assessors. DR10 The system will store personal information of student’s supervisors and assessors.
Functional Requirements
FR01 The system will allow user to create a new student record by entering student name. FR02 The system will allow user to modify an existing student record. FR03 The system will be able to generate an Honours Assessment Report. The report will be produced in the format required for the relevant school. FR07 The system will automatically calculate Student’s Honours Entry Score then store it in the Student Record. FR08 The system will calculate Honours Entry FR09 The system will be able to generate an Honours Entry Summary Report. FR17 The system will allow the user to enter new courses and edit existing courses of any student’s details in the system.
Technical Requirements
TR02 The system will operate on a single IBM compatible running Windowsâ 98/NT/00. TR03 The system will be accesses via a graphical interface. TR01 The system will include any additional software required.

Warning! This essay is not original. Get 100% unique essay within 45 seconds!


We can write your paper just for 11.99$

i want to copy...

This essay has been submitted by a student and contain not unique content

People also read