VIEWS: 347 PAGES: 4 POSTED ON: 11/7/2012
Feasibility Study: (September 10th, 2009) http://www.cs.cornell.edu/courses/cs501/2007sp/assignments.html Write a short feasibility report that describes the project that you have selected. The exact form of the report is up to you, but it should be well written and suitable to present to an external client. The length is likely to be between two and five pages. The report should include the following: The client for whom the work will be done. A statement of the task to be undertaken. A preliminary requirements analysis. Suggested deliverables. Outline plan, showing principal activities and milestones. Visibility plan. How will you keep in contact with the client and report progress? How will you communicate among your team? Probable technical requirements All members of the project team should share in the production of the report. When you have completed your report, (a) deliver it to the client, (b) Make the report available to everyone on the message board, and (c) submit a hardcopy to the Instructor. Example of a Feasibility Report Format FEASIBILITY STUDY The Group Name all the members and the leader. The Client Name your client and his/her information. The Task To Be Undertaken: What is to be developed? Why? Benefits: List the benefits of creating such software. A Preliminary Requirements Analysis: List the functional requirements of the system: Technical Requirements – Feasibility: List what Server, Database, Web Interface or/and any other requirements to be used. Suggested Deliverables: Management Deliverables: 1. Requirements Analysis – a document and a presentation to go over the formal requirements of the project, both functional and non-functional. This deliverable ensures that the Group is working on a system that closely matches to the wishes of the Client. This deliverable gives the Client a chance to modify and correct items that were wrongly communicated or missed out before allowing the Group to proceed further in the design. 2. Design Document – a document and a presentation to go over the design of the system. This is the Group’s opportunity to go over how the project is to be implemented to the Client. This deliverable is done by the more technical and experienced in the Group, based on the understanding of the requirements established in the previous deliverable. 3. Source Code – a document, presentation along with the source code of the final completed project. This final deliverable wraps up and concludes the project. In this deliverable, the Group delivers the final implementation based on the requirements specified and the design developed in previous stages. The system would have been tested thoroughly with unit tests and with a final acceptance test and would be ready for deployment to the production system. Technical Deliverables: List the Technical deliverables to the client and the instructor. Walk-Through: The client and the developing team are to set together and decide if the system at hand is acceptable by the client. Outline Plan (Milestones) For every deliverable “milestone”, the client must be presented with and agree to it. Visibility Plan External: List all meetings “date and time” made with the clients. Internal: List all meetings made with the group members and show who attended and who did not. Risk Analysis 1. Changing Requirements: Risk: The Client may have different ideas about the system during the course of the project. Depending on the situation, the changes that the Client wishes to have implemented may require little or major changes to the architecture. Solution: To reduce the possibility of this occurring, the Group needs to establish a clear visibility plan with the Client. 2. Incomplete Requirements: Risk: It is possible that requirements may be implied but not discussed or misunderstood. This frequently occurs after meetings. Solution: The Group’s interpretation of the Client’s requirements will be presented back to the Client to get a confirmation on whether the Group has understood the Client. Frequent client updates and a high level of visibility will also help call attention to any misunderstandings. 3. Lack of Resources, Tools: Risk: List all risks and if there are any solutions. Conclusion: Decide whether the project is feasible and that the group is willing to undertake it.
Pages to are hidden for
"Feasibility"Please download to view full document