Download Feasibility Study - Lecture Notes | CS 5150 and more Study notes Software Engineering in PDF only on Docsity!
FEASIBILITY S TUDY
The Group
Douglas Tak-Lai Wong, [email protected] Gregor Charles Carrigan, [email protected] James Ioannidis, [email protected] Jeffery Zhang, [email protected] Talitha Lynn Forcier, [email protected]
The Client
Bob Kibbee, Map & GIS Librarian, Olin Library, [email protected]
The Task to be Undertaken
The project is to develop an interactive web-based mapping application to search the complete range of geo-referenced materials in the Cornell University Library. The interactive map would allow a user to find maps through maps, providing a more intuitive interface to cartographic catalog browsing.
The project consists of three main parts: determining a database solution to hold the metadata for the library’s map resources, developing an administrative interface that would allow for adding and changing metadata for map holdings, and developing a UI to expose this metadata to the end user (library patrons).
Benefits:
Currently library patrons have a difficult time locating maps due to the fact that the patron is in a “geographic” mindset and the library catalog requires that they translate their query into an often obscure textual query.
- The proposed mapping application would allow additional metadata to be appended to current catalog information to aid indexing and searchability.
- The proposed mapping application would provide a framework for library patrons to visually and intuitively locate paper maps and atlases, digital maps scanned from the collection, and GIS resources; thus overcoming the challenges of the current catalog system and promoting the accessibility of these valuable resources.
A Preliminary Requirements Analysis :
The system needs to meet the following functional requirements:
- Web Interface a) Administrator Side i. Allow admin to modify, delete, or add the cartographic information for a particular map ii. Search by region name iii. Display necessary metadata information for a particular map b) Public Side i. Display interactive map 1. Must be able to zoom to at least three levels: world, continent, and country 2. Must provide a minimum level of geographic detail including country boundaries, country names, and a distinction between land and water 3. Must provide both catalog information and possibly some additional metadata on holdings for the current region based on click location and zoom-level 4. Must be able to make several key distinctions between maps, the only mandatory requirement here being the ability to distinguish topographic map series and their resolutions
- Database to store cartographic information a) Must be pre-populated from the library catalog b) Must allow additional information to be added for each map
- Be easily extensible from both the administrator’s perspective and from future developers’ perspectives
The system may have the following functional requirements: Undecided
- An interface to updating the map database with a more current catalog version, while maintaining additional metadata may be necessary.
- The scope of and the amount of metadata we display for each cataloged map. It is possible that for basic purposes we may only present a user with a link to the library catalog entry for a particular map.
- The administrative interface may not need to be web-based.
map collection through an intuitive UI supported by an administrative interface. Development to the extent called out in the above requirements section is all that is planned. The end product will run on an Olin library web-server and will be viewable through all standard web-browsers.
We DO NOT plan to make other library resources available through this interface. We DO NOT plan to expose the additional metadata to the library catalog nor any interface other than a map-based UI. We understand that it is NOT necessary to dynamically link with the library’s central database, so maintaining a separate database is a viable option.
Suggested Deliverables:
Management Deliverables:
- 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 mis-communicated or missed out before allowing the Group to proceed further in the design.
- 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.
- 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:
- A database with the required tables to support the inventory system—a database needs to be set up on the library servers with the tables needed in the system to store the inventory information, geo-referenced materials, and other cartographic data.
- An administrative interface to add, modify, delete and search for inventory—a
webpage designed to allow the administrator (ie., the Client) of the system to add information to the inventory system for every map that is found in the library and to build up an electronic record of the resources that are found in the library.
- An interactive map with labeled countries and clear national boundaries—a map of the world with zooming capabilities and re-centering functions, labeled with names corresponding to the current view of the map, that has clear boundary lines (ie., country border) on a web page.
- A side menu that is populated with cartographic information based on the inventory—a portion of the web page that shows available cartographic resources for the selected region, based on information in the inventory database. The information that will be displayed has yet to be decided.
Walk-Through:
In order to ensure that the Client and the Group are on the same page, the following walk-through has been prepared to illustrate the Group’s understanding of the product desired by the Client. The walk-through is not necessarily a reflection of the exact interactions for the final product; rather it should serve as a rough overview of the functionality required by the final product as the Group currently understands it.
Library Patron walk-through The Patron is first presented with a map of the world labeled so that all countries are named and clickable. When a client selects the country of interest an info-page with a list of the types of maps (topological, street, etc.) or other resources (web links, etc.) relevant to that country along with a list of larger geographical regions which that the country is part of, each of which would link to their own info-page. Also close-up of the country is presented which could be used to add another level of detail to the interface (counties, cities, etc.). A click on the info page will use the library catalogue and the database the Group will be implementing to generate a page listing all the relevant maps. A click to any particular map will present a page containing all the information necessary to physically get the client to the map and anything appropriate that we can glean from the catalogue or database.
Administrative walk-through The administrator needs a way to add, modify and delete entries in the database. To add entries the administrator will enter data on a simple text-box, pull-down menu populated page with all the necessary fields. To modify or delete entries the
Milestone 4. A presentation should be prepared for the Client.
V. Milestone 5 (April 14, 2006) – Database. The database is the most important part of the system, as it is the center of all information. All subsequent system components depends on this deliverable. A database schema needs to be fixed for Milestone 5 to provide a basis for the other components to be based on.
VI. Milestone 6 (April 21, 2006) – Inventory Control. As the menu of cartographic information needs to be published using information in the database, the next bottleneck is the inventory control, which is a graphical interface to allow the administrator to enter, modify, and delete data.
VII. Milestone 7 (April 28, 2006) – Map and Menu. The map and the menu are the front-end graphical web interface that the public user sees and interacts with. Milestone 7 is to reach feature-completion on the requirements.
VIII. Milestone 8 (May 5, 2006) – Testing, Debugging and Integration. The system needs to be well-tested, debugged at this milestone. Also, once the system has passed the acceptance test, it needs to be integrated to the actual production system for this milestone.
IX. Milestone 9 (May 11, 2006) – Project Deadline. The project source code should be handed over to the Client for the final milestone. A presentation is presented to the Client.
Visibility Plan
External – The Group will conduct regular biweekly meetings with the Client at the Olin library. If situations arise or if a problem needs to be addressed between the meetings, the Group will conduct any further necessary communication via email. Because a modified waterfall model will be used, a report will be issued to the Client at the end of every step to ensure that both parties are in-sync and to minimize any miscommunication in the requirements.
Internal – The Group will meet weekly on Wednesday evenings from 7:30 pm to 9: pm to discuss progress and problems. Meeting minutes will be kept track of and sent to all members of the Group for reference. Any additional communication will be done via email or through other collaboration tools such as document sharing. In
addition, the source code will be stored at gforge, a repository for the project. All source code will be documented carefully before being submitted to the repository. The progress of the principal activities and major milestones will be closely monitored and compared with the schedule. During the regular meetings, progress will be compared to a Gantt chart, which will be drafted after the completion of the requirements study when the tasks are identified and assigned.
Business Considerations
As Cornell students, the Group owns the copyright in the software that we create in this project. The Group agrees to transfer the copyright to the Client and to provide the Client with unrestricted license to use the system.
It is just possible that a project may develop concepts that could be patented. If such a situation arises, the Group collectively owns the rights to all patents associated with the System.
We understand that the use of open-source solutions IS a viable option and that there are not any serious licensing issues to this extent.
Risk Analysis
- 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.
- 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.
- Lack of Resources, Tools: Risk: For the project to meet one of the functional requirements (clicking an area of a map within the boundaries of a country should select that country), a
this project IS FEASIBLE and the group IS WILLING to take on the afore mentioned project. The benefits are significant enough to justify the development effort required. Currently, the costs of the project are believed to only involve the labor costs of the group. The preliminary deadline for the project will be set for April 7. On this date a functional system should be live on an Olin library server. The next stage of development will be the completion of a requirements study, which will be conducted and written up by March 3, 2006.
