Group Project: Order Processing System
Project Plan - Phases & Phase Transition Plan
Problem Definition Report:
Input: We would get input from online order processing systems based websites, books from the Hagerty Library on the nature of problems that analysts encounter while designing a system.
Activity: We will, after examining websites on how they accept, track and provide customer support with the help of order processing systems. In addition, we will also refer to books that have been written on such systems in order to pin down our problem so that we understand the focus of the system. Websites such as buy.com, egghead.com maintain customer order information such as past orders, status of pending orders and even shipment status. Since we are designing such a system for computer monitors, we would also take into account issues that relate to product profile and customer profile.
Output: After examining the above-mentioned sources we will come up with a problem definition report that outlines the nature & complexity of the problem our system is trying to solve.
Requirements Document Draft:
Input: Primarily our input will be from sources such as books and online systems. In addition to these two, we will also conduct interviews.
Activity: The main activity in this phase is to gather the requirements. In this phase, we will try to understand the client’s business, and their immediate/future requirements with respect to the sale of computer monitors and based on that we will try and come up with the set of requirements that match our client’s expectations. To start we will try and examine their existing system and understand the nature, shortcomings, issues with that system in addition to new needs that the client will have. Meeting potential users and their managers would be the basis for understanding our client’s requirements. We will also upon listing the requirements, prioritize them as “critical”, “desirable” etc. so that we can get a better understanding of the needs of our client. But we like to keep this as “draft” phase since we want to take this back to the client and discuss the draft with them in order to further refine it.
Output: At the end of this phase, we will have a rough version of the requirements and also feedback from the client on issues we might have overlooked or examined incorrectly.
Requirements Document Version II:
Input: Mainly we would take input from the draft version and the client feedback.
Activity: This phase would consist of further refining the requirements and additional activities such as interviews will continue as we continue to clarify our understanding of the client’s business and its customers. We want to spend time on the requirements more since improper requirements is one of the major causes for runaway/dissatisfactory projects.
Output: At this phase we would have a better requirements document in order for us to identify what our client thinks as “essential” or “cool” and this will help us in going forward with the system design.
Design Plan Document:
Input: The requirements document would be the foremost source of input
Activity: This phase involves our thinking as to how we want to come with a solution to meet the expectations of our client. This would begin with understanding the data modeling issues (Entity-relationship model, conceptual-relational model) for the business environment, and also issues such as scale, scope and usage of the system
Output: on completion, we will have a design document, which will have a proposed solution for the system and help us in the preparation of a prototype.
Prototype Design & Feedback:
Input: Design document will serve as the primary input
Activity: We will come up with a quick prototype that captures the critical/essential features of the system and get feedback via live demonstration from the client. The prototype could be either refined further or completely discarded but we will benefit from the feedback on issues like user interface design (layout, color, keystrokes, shortcuts etc) and output format (reports - hard & soft copy)
Output: Whether or not we retain the prototype is not important to us since the primary purpose of this phase produces the quick piece of software along with what the client thinks about it. Based on this we go back one phase and continue to refine our design plan document.
Development & Testing Phase:
Input: Prototype design and feedback phase will give us input along with the requirements document, and the design document.
Activity: This phase involves actual coding and designing/implementation of a database system and also testing. We want to test the system in-house on issues like network connectivity, bandwidth requirements, data availability, user sessions etc. (since it’s a web based system the stateless nature of the web brings a range of problems along with it). So actual coding in order to design data entry, display, report generation, database updates etc will be done
Output: We will have a system that’s tested and tried in house so that we are sure we met the client’s list of requirements and also made a system with a good user interface.
Implementation Plan:
Input: This phase will take input not only from the development & testing phase but also representatives from the client’s end who are part of their management, IS departments.
Activity: We will do a test run of the system on site and also plan a conversion plan for transition from their old system to the new system. Installation plan, fees and billing procedures will also be detailed in the form of documents.
Output: The final system that hopefully makes the client happy!
Phase Transition Diagram
Problem Definition Report
Requirements Document
Draft
Requirements Document
Version II
Design Plan Document
Prototype Design
& Feedback
Development
& Testing Phase
Implementation Plan