Case Study, Stage 5: Outline of Next Steps
I. Project description
A. Process to be improved:
Currently, UR UMUC Healthy Fitness Center uses a manual system in keeping membership records, orders for towels and snack bar items, financial and payroll accounts. This manual system will be replaced by a software system. The proposed technology solution will involve developing a Records Management Software that would be used to organize and manage membership details, orders for towels and snack bar items as well as financial and payroll accounts.
II. Project Management
A. Schedule:
Tsui (2009) stated that typically, project scheduling involves techniques that can be applied to manage project activities that need to be done during the project development. A Gantt Chart will be used as the technique is developing the project schedule. Intended Start and Finish dates will be clearly defined.
B. Resources:
They are imperative in carrying out the project tasks and include personnel/project team members – Web developers and designers. Facilities – workrooms and presentation rooms for the project. Equipment – hardware for the project. Expenses/Funding – such as supplies, travel and room.
C. Deliverables:
| Phase | Deliverables | To Whom |
| User Requirements | Software Project Management Plan (SPMP) | Senior Project Management (SPM) |
| Software Quality Assurance Plan (SQAP) | ||
| Software Verification and Validation (SVVP) | ||
| Software Configuration Management Plan (SCMP) | ||
| User Requirements Document (URD) | Senior Project Management and Client | |
| Acceptance Test Plan | ||
| Software Requirements | Software Requirements Document (SRD) | Senior Project Management and Client |
| System Test Plan (STP) | ||
| Architectural Design | Architectural Design Document (ADD) | Senior Project Management and Client |
| Integration Test Plan (ITP) | ||
| Detailed Software Design and Production | Detailed Design Document (DDD) | Senior Project Management and Client |
| Unit Test Plan (UTP) | ||
| Software User Manual (SUM) | ||
| Software Transfer Document (STD) | ||
| Source Code |
III. Systems Development Life Cycle (SDLC)
A. Feasibility analysis:
This will include an analysis of the project requirements with regard to input data and desired output data, processing needed to transform input into output, the cost-benefit analysis and the project schedule. Moreover, this phase also includes the technical feasibility of the project in terms of available skilled software personnel, software tools and hardware (Tsui, 2009). After this phase, a feasibility report for the whole project is created.
B. Requirement gathering and analysis:
The business requirements are gathered during this phase. Meetings will be held with the major stakeholders such as the end-users and managers in order to clearly determine the requirements. After gathering requirements, they are analyzed for their validity and possibility of incorporating them into the system. The functions that need to be computerized such as membership records, orders for towels and snack bar items, as well as financial and payroll accounts will be examined. Finally, a Software Requirement Specification (SRS) document is created to serve the purpose of guideline for the next phase. It includes the performance, functional, hardware, software as well the network requirements of the project (Tsui, 2009).
C. Systems Design:
The software and system design is prepared from the requirements specifications that were studied in the previous stage. This phase includes translating the requirements specified in the SRS document into a logical structure, which can be implemented in a programming language. System design will help in specifying the software and hardware required, and in defining the overall system architecture. Specifications for system design serve as input for the next stage of the model.
D. Implementation/Coding:
This entails implementing the design specified in the design document in an executable programming language code. With the system design documents at hand, the work is divided into units/modules and the actual coding begins. The output of this phase is the source code for the software system that serves as input to the testing and maintenance phase (Tsui, 2009).
E. Testing:
This will include detecting errors in the software. In this phase, the developed code is tested against the specified requirements to make sure that the software product is essentially solving the needs identified and gathered during the requirements gathering phase. This phase will involve conducting several testing such as unit testing, system testing, integration testing and acceptance testing (Tsui, 2009).
F. Deployment:
Upon successful testing of the product, it is deployed/delivered to the client for their use.
G. Maintenance:
When the client begins using the newly developed software system, problems may start cropping up which have to be solved from time to time. This phase also includes implementing changes that the software system may undergo over time, or implementing new requirements after it has been deployed to the client. Moreover, this phase also incorporates handling any residual errors that might exist in the software even after the testing stage.
IV. Change Management:
Usually, most software development projects are completed with some changes (Tsui, 2009). Change can be done in different areas such specifications, user requirements, system design or even on source code. Changes will be communicated using a Change Request (CR) form. Upon receiving the CR, the first thing will be to record it in a CR Register. All the CRs received will be entered into the CR Register and tracked through closure. It will then be analyzed by the Senior Project Manager (SPM). The analysis would determine; whether the implementation of CR would be possible or feasible, the amount of effort and time it would require to implement the CR, and the impact of the CR on the entire project, particularly in terms of schedule, effort and cost. After the analysis, the Impact Analysis would be presented to the SPM to either approve or reject. Once the CR is approved, it would be implemented according to the CR implementation strategy determined and recorded in the Software Configuration Management Plan (SCMP). In this situation, the strategy that will be used to implement CRs is; as and when received, that is, immediately on receipt. The change would be implemented as soon as the CR is received.
V. Employee Training:
After completing the project and deploying it, a user manual for the system would be provided to the client/customer to help with guidelines in using the new system. Nevertheless, on-site employee training will be carried out to ensure the end-user understands how to use the new software system. This would involve an instructor from the project team giving instructions to the end-users on how to use the newly developed Records Management System. Any questions from them regarding the use of the new system will be answered satisfactorily. The training will take between 2 to 7 days depending on how fast the end-users will learn to use the new system.
VI. Leadership Expectations:
The project leadership will be expected to do the following: define the project scope and deliverables, identify what is required to achieve the deliverables, prepare project timeline, identify the required resources, track the project progress, and report project status. Moreover, the leadership will also be expected to plan and manage project resources, stakeholder communication, project risks and issues, project quality and changes to project scope. Finally, the leadership will also be expected to close the project (Tsui, 2009).
VII. Defining Success:
Success will be defined basing on the following aspects: If the project has met the stated user requirements, it was completed within the budgeted cost and time-frame, and if it was completed on schedule. If it satisfies these aspects then it would have been a success.
Reference
Tsui, F. (2009). Managing Software Project. San Francisco, CA: Jones & Bartlett Learning
