Project Omniglean. Team: Faculty Advisor: Dr. Mitra. Kenny Trytek Abby Birkett Joe Briggie Derek Woods

Transcription

1 Project Omniglean Team: Kenny Trytek Abby Birkett Joe Briggie Derek Woods Faculty Advisor: Dr. Mitra

2 Revision Date Author(s) Change /02/2010 KT, AB Initial document creation /06/2010 KT, AB, DW Addition of team-created material (incomplete) /10/2010 KT, AB Added Gantt chart /10/2010 JB Updated diagrams, integrated remaining parts /10/2010 KT Checked formatting, minor wording revisions, added table of contents & resource requirements Table 1- Revision History i

3 Table of Contents 1 Introduction Purpose Scope Acknowledgment Term, Acronym, and Abbreviation Definitions Executive Summary Overall Description Problem Statement Concept Sketch System Block Diagram Operating Environment Intended Users and Intended Uses Assumptions and Limitations Market and Literature Survey Expected End Product and Other Deliverables Proposed Approach and Statement of Work Proposed Approach Functional Requirements Non-Functional Requirements Constraint Considerations Technical Approach Considerations Source Code Management Coding Strategies Development Process Testing Requirements Considerations Unit Testing Integration Testing System Testing Safety and Security Considerations Intellectual Property Considerations Commercialization Considerations... 9 ii

4 3.1.9 Possible Risks External Format Change External Availability Proposed Project Milestones and Evaluation Criteria Project Tracking Procedures Statement of Work Task 1: Problem Definition Subtask 1: Problem Definition Completion Subtask 2: Use Cases Identification Subtask 3: Constraint Identification Task 2: Technology Considerations and Selection Subtask 1: Possible Technology Identification Subtask 2: Identification of Selection Criteria Subtask 3: Technology Research Subtask 4: Technology Selection Task 3: End Product Design Subtask 1: Design Document Completion Subtask 2: Design Document Presentation Task 4: End Product Prototype Implementation Subtask 1: Development Environment Setup Subtask 2: Implementation of Prototyped End Product Task 5: End Product Testing Subtask 1: Test Planning Subtask 2: Test Development Subtask 3: Test Execution Subtask 4: Test Evaluation Subtask 5: Test Documentation Task 6: End Product Documentation Subtask 1: Help Documentation Creation Subtask 2: User Guide Documentation Creation Task 7: End Product Documentation Subtask 1: Demonstration Planning iii

5 Subtask 2: Faculty Advisor Demonstration Subtask 3: Client Demonstration Task 8: Project Reporting Subtask 1: Project Plan Development Subtask 2: Project Poster Development Subtask 3: End Product Design Report Development Subtask 4: Project Final Report Development Subtask 5: Weekly Reporting Estimated Resources and Schedules Estimated Resources Personnel Effort Requirements Financial Requirements Schedules Project Schedule Deliverables Schedule Closure Material Project Team Information Client Advisor Team Members Closing Summary iv

6 List of Figures Figure Concept Sketch Figure System Block Diagram List of Tables Table 1.4 Definitions Table Personnel Effort Table Financial Requirements Table Project Schedule Table Deliverables Schedule v

7 1 Introduction 1.1 Purpose Develop an automated data harvesting tool to collect FDIC and FFIEC records from government websites. Develop a database model to store the records. Design a GUI to make records accessible to accountants and analysts for mastering. The end result is to save money & ensure quality data for Kingland Systems clients. 1.2 Scope Project Omniglean comprises the development, testing, and verification of a software system to automatically harvest, store, query, and display data from the government websites of the FDIC and FFIEC. To enable the harvesting functionality, web scraping code will be written, or an affordable third-party web-scraping solution will be found and integrated with the other system components. Code will be written to extract the data from a flat file format produced by the scraping component, and load it into a database. The database model will also be defined as part of the project scope, and it shall support storage of the data types found on the two websites of interest, as well as other data types as yet unknown. These unknown data types, however, may not possess the same level of searchability and speed of access that the data types specifically targeted in the requirements will have. A web services component will also be developed as part of the project, giving users the ability to view the data stored in the database through the internet. The client GUI for viewing the data may be developed by a third party, but it is the aim of this project to develop a reference GUI that will allow viewing the data records and querying the database for desired records. A stretch goal for the project would include the ability to write to the database and perhaps modify existing records, though this is not explicitly provided for. The project will also entail testing the software on real hardware. The software shall fulfill the requirements heretofore set forth by Kingland Systems, and the client will be notified of the make and manufacturer of the hardware being used when the software passed the tests. It is understood that the server's connection to the internet is a prerequisite for the proper functioning of the software and the connection will not be provided by this project. The software developed during this project can only be expected to meet the requirements given that a reliable connection from the server to the internet has been provided by the client, as well as other assumptions having been met (see "Assumptions"). 1

8 1.3 Acknowledgment The team members of project Omniglean would like to thank Matt Good of Kingland Systems for providing expertise and intimate knowledge of the data mastering process as successfully practiced at Kingland Systems, and for taking time out of his busy schedule to meet each week with the team. Many thanks also extend to Dr. Simanta Mitra, for providing in-depth experience with software design, both in this course and others, as well as his expertise and mentorship in project risk management. Last but not least, thanks go out to Iowa State University for the provision of this program and the chance to work with talented professionals on complex, real-world design problems such as this as part of the undergraduate education experience. 1.4 Term, Acronym, and Abbreviation Definitions Term.NET Copy-left Definition Microsoft's virtualization environment for running programs written in any of its.net languages, including C#, on various hardware. Software that is licensed only under the condition that other software incorporating it be open source and free, or other similar conditions. DAL Data Access Layer: A system component that abstracts the commands used to fetch data from a particular database implementation into a constant and welldefined interface for data access. Data Mastering Process by which many records from various entities are analyzed and potentially conflicting pieces of information are resolved to yield an accurate and comprehensive record. ETL Tool Extract Transform and Load Tool: Software component to extract data entries from a flat file, transform them into a format storable in a database, and load them into the database. FDIC Federal Deposit Insurance Corporation: Government agency that, besides insuring certain bank deposits, also maintains a website of financial institution data that is a harvesting target for this project. FFIEC Federal Financial Institutions Examination Council: Government interagency body whose website is also a target for harvesting of institutional data for this project. GUI Graphical User Interface: Visual interface with software. MDM Server Master Data Management Server: A product offered by IBM, with access provided to Kingland Systems as part of a collaborative agreement between the company and IBM. RSSD ID Replication Server System Database Identification Number: A number used by the Federal Reserve to track any of the hierarchical components of a company. Table 1.4 Definitions 2

9 1.5 Executive Summary This document defines the scope of Project Omniglean, and lays out a plan for completing all of the requirements set forth by Kingland Systems. A concept sketch and system block diagram are included for quickly assessing the scope of the project, as well as detailed lists of deliverables and milestones. An extensive list of customer requirements details each requirement specified by Kingland Systems for the design of the software system. A project schedule is included as a reference plan for completing the project in the time allotted. 2 Overall Description 2.1 Problem Statement Large companies have many layers of corporate hierarchy. Financial and data records sometimes conflict between various layers/entities. Accurate and comprehensive company records are needed. There is a need for Data Mastering, to take multiple conflicting sources of data and determine the reality of the matter in conflict Concept Sketch Harvest & store Analyst User Internet Omniglean Client User Figure 2.1.1: Concept Sketch 3

10 2.1.2 System Block Diagram Figure 2.1.2: System Block Diagram 2.2 Operating Environment Since this project consists only of software systems, it will not be subject to environmental factors such as temperature, humidity, etc. and the design of these systems will not consider such factors. 2.3 Intended Users and Intended Uses Kingland employees and Software Engineers from other companies will be the primary users of our system. Kingland employees will use the Harvester and Importer modules to retrieve data from the [FDIC and FFIEC] websites and put the data into a database for later review. Kingland employees may also use the database that we design to potentially resolve any issues that arise and also to manipulate the data if necessary. The Data Access Layer will not be used directly by any user, but will interact with the Importer module and the Web Services to insert 4

11 and retrieve data respectively. Software Engineers from other companies may utilize the Web Services that we create in order to retrieve data from our database and use it in a way that is specific to their application. 2.4 Assumptions and Limitations Assumptions: The FDIC and FFIEC websites will always be available for harvesting. The FDIC and FFIEC websites will have the same layout every time data is harvested. The way data is organized on the FDIC and FFIEC websites will not change. The format of the file created by the Harvester module will stay the same. Our database will always be available. Our Web Services will always be available. Limitations: The Harvester module will have to traverse the FDIC and FFIEC websites based on their current layouts. The server that hosts our system will have to support ASP.NET. 2.5 Market and Literature Survey No market or literature survey can be done as this is a proof of concept project that will be used internally by Kingland to expand their methods of obtaining data. This project is not for commercial use and will only serve as a reference piece for obtaining data via web scraping. 2.6 Expected End Product and Other Deliverables Harvester Code Importer Code Data Access Layer o Business Logic Layer (Service Layer) o Persistence Layer (Data Access Object Layer) Database Web Services Our project will consist of five main deliverables with four out of the five being pieces of software that will act independently of one another. A database to store data from the FDIC and FFIEC websites will also be created and given to the client. 5

12 The Harvester code will be the module that programmatically access the two websites and retrieves the requested data. The Harvester code will initially put that data into a flat file for later consumption. The flat file that the Harvester code creates will be read by the Importer code and sent to the Data Access Layer to be put into the database. The Business Logic Layer will receive data from the Importer code and perform any necessary operations on it before sending it to the Persistence Layer of the Data Access Layer. The Persistence Layer will interact with a third party data object management library and perform operations on the database. We will also be creating Web Services to allow interaction with our data by Web Applications. 3 Proposed Approach and Statement of Work 3.1 Proposed Approach Functional Requirements System shall autonomously traverse publicly available websites System shall parse information from downloaded file in portable document format (pdf) System shall store parsed information in a flat file System shall allow user the ability to create, modify, and delete records System shall maintain a normalized database System shall expose functionality through web services Non-Functional Requirements System shall support up to 250 concurrent users A single run of system shall complete execution in less than six hours System shall be easily extensible to include more websites than originally specified System shall be completed by May of Constraint Considerations System shall interact with a third party library to facilitate database interaction The database may not be available at all times Technical Approach Considerations 6

13 Source Code Management Source code management will allow team to easily collaborate on coding. We shall be using SVN to maintain our code in this project Coding Strategies Develop use cases that will help determine the architecture of the system. Once the architecture is in place, individual modules of the system can be determined. Each module will be assigned to a single programmer. o Pros: Easy to follow; Each programmer knows what they need to do; o Cons: One module may be more difficult that others; All team members work on the same module until it is complete o Pros: The team would fully understand system and how each module works; Problems could be solved faster as everyone has a different way to solve a problem; o Cons: Slow, others could be working on something else while one person codes; Team members may not learn new skills; Different coding styles between team members may create tension between team members; Not everyone is available at the same time; Result: If one person gets stuck on their module, others can help out. Also, team members need to maintain a positive relationship with other team members in order to complete the project Development Process Iterative approach: Start with planning, build the basic groundwork, test, evaluate, and repeat the process until the system is finished o Pros: If problems are found, they can be fixed early o Cons: Could be slow Spiral approach: Start with basic requirements, basic design, basic prototypes, and plan the next phase o Pros: Prototyping begins early; If problems are found, they can be fixed early o Cons: One step may take longer than expected and project will fall behind 7

14 Waterfall approach o Pros: Easy approach to follow; Bugs found earlier are less costly to fix o Cons: If we fall behind on an earlier stages, all other stages will be behind as well; System requirements might change, we would have to go back and change what is needed in all other stages Result: The spiral approach was decided to best fit the project s needs Testing Requirements Considerations Unit Testing Programmers will be testing while coding. Once a unit is complete, we will put the unit through several tests to check for bugs as well as unexpected behavior Integration Testing We will be piecing the separate units together in a systematic approach, and run the pieced units through a stress test to determine if the system will behave as we expect System Testing Once all units are integrated together, we will perform a final stress test. The final stress test will include running the system through a program that can act as multiple users Safety & Security Considerations The ability of the software to update records and write to the database introduces immense risk that the system could be compromised by inaccurate data entry. If unauthorized users were to gain write access to the records, they could potentially write fraudulent entries into the records, masking the true record status. This could lead to falsified company hierarchies, fraudulent financial records, or worse, depending on the final uses of the software. If other automated software, such as securities trading software, is triggered to trade based on data in the database, then malicious data entries could lead to lost profits from trade executions or even a systemic risk in the securities exchange. Even a well-intentioned user could cause damage by accidentally writing the wrong data due to human error. If users are allowed to write to the database, especially through the internet, then strict controls and checks must be put in place to prevent erroneous data entries. 8

15 Also, if the database becomes unavailable, due to server downtime or other reasons, it could lead to lost profits for the companies that rely on the services of the software. Because the software is only proof-of-concept software, this issue of data redundancy and server downtime will not be tackled by this project, but is important to consider for future developments Intellectual Property Considerations If the software incorporates other third party software, then the overall software package must comply with the license restrictions of the third party software. If the software is to be sold as a product (as opposed to Kingland System's current service-based model), then this could limit the projects ability to access third party, copy-left open-source software Commercialization Considerations Kingland Systems is currently working on a new project that would be more oriented towards software as a product as opposed to their current service-based model. In the event that Kingland Systems would like to market the software from this project under this model, they would like to have an installer available that would take care of initial set-up of the software. If this software-as-a-product model is pursued by Kingland Systems, then the software developed by this project cannot include as a constituent any copy-left software, such as software licensed only under the GNU GPL. This may limit the choices for third-party webscraping tools should the decision be made to purchase the web-scraping functionality separately. It would also be very helpful for the marketability of the software to have a feature that allowed for easy extensibility. Currently, Kingland Systems is targeting two websites (the FDIC and FFIEC) specifically, but ideally they would like to have a user interface to include additional websites and data. This might require much time to develop, and it is not explicitly in the scope of the project, but can be included as a stretch goal if the core functionality is delivered ahead of schedule Possible Risks External Format Change The sites the information is being parsed from is under no constraints to maintain the same format that has been used prior to the current execution. However, it is unlikely the format will change radically due to precedence and number of users using the information. 9

16 External Availability The sites the information is being parsed from may not always be available, so the project would in effect be broken in such a state New Technology Experience The team is not familiar with C#, MySQL, or any of the third party libraries being considered to act as a database go-between, or the screen scraping utilities available. Risk of inefficient implementation is high due to the team s inexperience Proposed Project Milestones and Evaluation Criteria Milestone 1: Web Scraping Software & Flat File Creation Capability Software can scrape data into a flat file from the web, for at least one of the two sites. Milestone 1.5: Web Scraping & Flat File Creation Full Capability o Software operates on both of the target websites to create a flat file. Milestone 2: Database Model Complete Database model is finished that stores basic data from either of the two target websites. Milestone 3: ETL Tool loads flat file into database Extract Transform & Load tool is shown to transform a sample flat file into databasereadable records. Milestone 4: Database Normalized Database model has been fully normalized. Milestone 5: Database readable through DAL Database records can be read out through the interface of the DAL, though no GUI may be present. Milestone 6: Web Services enables read access to database Web services calls allow access to database records, though no GUI may be present. Milestone 7: Reference GUI Complete A reference GUI is complete that allows a user to read the database through web services. No write access is available through the GUI. Milestone 8: Integration Testing Complete Software components have been tested together and bugs have been worked out between the modules. Milestone 9: Software successfully completes test run on FDIC Website 10

17 A test run of the software yields accurate records of FDIC data that can then be read through the reference GUI. Milestone 10: Software successfully completes test run on FFIEC Website A test run of the software yields accurate records of FFIEC data that can then be read through the reference GUI. Milestone 11 (stretch goal): Write Access is enabled to the Database from Web Services Write access is implemented for the Database through web services calls. There may be security flaws at this point that allow users to overwrite data maliciously or delete needed data, but the core function of writing works accurately. Milestone 12 (stretch goal): Security implemented and initial security testing begins Checks are put in place on the privileges of users, and measures are taken to prevent users from maliciously altering data. Kingland employees are invited to test out the system specifically to break it and find weaknesses. Milestone 13 (stretch goal): Security holes are found and patched Security issues that were raised from security testing have been addressed through stricter controls and new security measures Project Tracking Procedures Project components will be discussed among the group and implementation details assigned by the project lead. Each delegated component will be developed and documented by the designer(s) assigned to that individual piece. This will include, without limitation, writing code, documenting API's, and producing readable commenting. If end-user documentation is required, development of that documentation may be assigned as a separate component. Each functional requirement will be given a title and ID number, and will be contained entirely within its own document. The document will be a Microsoft Word document in a standard format currently used by Kingland Systems. Each requirement will also have a version number, and the version number will be updated to reflect changes along the way through development. A list of outside interdependencies will be maintained for each requirement to facilitate possible changes in requirements. Screenshots may be added in to the document as progress is made to illustrate approaches to fulfilling the requirement. The date of modification to the requirement will also be updated to reflect each change. As project components are completed, their status will be reported back to the project lead. These status updates could come in various formats, including , sms messages, and phone calls. Weekly meetings will be held within the group, and their minutes will be posted on the project webpage. Meetings with the client and the faculty advisor will also take place, approximately weekly depending on their schedules and current developments. Meeting 11

18 minutes will also be posted for these meetings as they become available, although certain diagrams and non-text notes may take longer to upload to the site. The project schedule will periodically be examined by the project lead to make sure sufficient progress is being made. The schedule may be adjusted as more information on each deliverable becomes available, and more features of the overall software system are implemented. 3.2 Statement of Work Task 1: Problem Definition Objective: Define the problem of the project. Approach: Determine functional requirements, non-functional requirements, use cases and constraints. Expected Results: A definition that will clearly state the problem Subtask 1: Problem Definition Completion Objective: Complete the problem definition. Approach: Use functional and non-functional requirements along with tasks to define the problem. Expected Results: A definition that will help determine a solution Subtask 2: Use Cases Identification Objective: Determine who will be using this system and how they will use the system. Approach: Request information from the client in regard to use cases and think critically to ascertain further use cases. Expected Results: All possible use cases are clearly defined Subtask 3: Constraint Identification Objective: Find any constraints the system will have. Approach: Request information from the client in regard to what the system needs to work around. Identify constraints defined by our own team. Expected Results: All possible constraints are clearly defined. 12

19 3.2.2 Task 2: Technology Considerations and Selection Objective: Choose a system that will allow full functionality of all functional and non-functional requirements. Approach: Specify functional and non-functional requirements, consider risks and constraints of possible systems, and choose the technology best suited to the requirements. Expected Results: The system chosen will have the ability to satisfy all functional and nonfunctional requirements, as well as meet or exceed all constraint criteria Subtask 1: Possible Technology Identification Objective: Obtain a list of what technologies are available that may have some impact on the project and/or contribute to the success of the project. Approach: Each team member will pursue a different line of inquiry to determine possible technologies for different parts of the project. Expected Results: A list from each team member of technologies that can be used in the project Subtask 2: Identification of Selection Criteria Objective: Choose criteria that will allow the team to distinguish certain technologies as better than others for the purposes of the project. Approach: The team will discuss the requirements of the project and determine what is most important so each criterion will have specific goals and each technology will have a framework under which it can be justifiably considered. Expected Results: A team member will have the ability to differentiate technologies and rank them in order of usefulness to the project in accordance with established criteria Subtask 3: Technology Research Objective: Rank the technologies identified in terms of usefulness to the project. Approach: Each team member will look further into how some of the identified useful technologies can be utilized specifically in the project and rank them according to their overall functionality, taking into consideration all applicable constraints. Expected Results: Each team member will have a list of the related technologies he researched ranked in order of usefulness to the project. 13

20 Subtask 4: Technology Selection Objective: Use the most appropriate technologies for all areas of the project. Approach: Allow each team member to make a case for the best technologies he researched, and decide as a team which technology seems most appropriate given the collective knowledge. Expected Results: The best technologies available for the project will be used for all areas of the project Task 3: End Product Design Objective: Obtain a design such that the system meets client expectations, all requirements, and all constraints defined in tasks 1 and 2. Approach: With chosen technologies and requirements defined in tasks 1 and 2, the team will develop a design such that all criteria are met. Expected Results: A fully functioning design that has met all criteria set by client and project team Subtask 1: Design Document Completion Objective: Complete the design document. Approach: Team will design the system using all requirements set by client as well as the project team. Expected Results: A complete document describing in detail how the project team will implement the system Subtask 2: Design Document Presentation Objective: Present the design document to a review board. Approach: Prepare the design document and a presentation of the proposed design. Expected Results: The design will be presented so that the audience will understand the design and how the system will be implemented Task 4: End Product Prototype Implementation Objective: Complete a working prototype of the proposed product to prove the concept of the final product. 14

21 Approach: Use the previously selected technologies to produce a system that fits within the constraints identified in Task 1 and adheres to the end product design. Expected Results: A working prototype will exist that can be used in all use cases and meets all functional requirements Subtask 1: Development Environment Setup Objective: Ensure code created on one team member s machine is executable, debuggable, and available on all other team members machines. Approach: Each team member will have a personal copy of Microsoft Visual Studio as well as the.net framework. Version control software will be utilized by all team members for accountability and concurrency resolution. Expected Results: Each team member will be able to produce code in their development environment that can be run and tested from all other team members machines Subtask 2: Implementation of Prototyped End Product Objective: Complete a working system that performs all actions required by the functional requirements. Approach: The team will work together in parallel to put together the system as defined in the requirements, with communication between the client and the team in order to refine what is expected and gain a better understanding of how the system will interact with itself and the external actors. Expected Results: A system will exist that functions as defined in the requirements and works with at least part of the available dataset Task 5: End Product Testing Objective: Find all detectable errors and unexpected behaviors in the system. Approach: Plan, develop, and execute tests to guarantee the functionality of the system. Expected Results: All detectable errors and unexpected behavior will be fixed Subtask 1: Test Planning Objective: Plan how the system will be tested. Approach: Team will discuss and determine best approach to test the system. 15

22 Expected Results: The team will have decided the best approach to test the system Subtask 2: Test Development Objective: Develop test cases that will determine if the system meets requirements. Approach: Team will discuss what test cases should be implemented. Expected Results: Team will have decided what test cases will be used Subtask 3: Test Execution Objective: Test the system using the test cases developed by the team. Approach: Using the test cases developed by the team, test the system for errors and unexpected behavior. Expected Results: The testing will show the team errors that need to be fixed Subtask 4: Test Evaluation Objective: Show that tests done on the system have been enough to prove functionality of the system. Approach: Team will discuss and implement test requirements that satisfy functionality, and confirm their correctness with advisor and client. Expected Results: Tests done on system have proven the system functions as expected Subtask 5: Documentation of Testing Objective: Develop a document to show that testing has been done and results of the testing. Approach: Keep track of what errors tests find and unexpected behavior found. Expected Results: A complete document of test cases and results of test cases Task 6: End Product Documentation Objective: Sufficiently document the final product to an extent that another team could read the documentation and become familiar enough to continue the project. Approach: Keep track of changes to the system as well as design considerations and choices so future developers can understand what thought went into the system s operation. Create any additional material as necessary. 16

23 Expected Results: A document containing the full operation and interaction of each system component Subtask 1: Help Documentation Creation Objective: Enable users to troubleshoot common problems by referring to a document instead of a person knowledgeable about the software operation. Approach: Each team member will produce documentation in the area in which they had the most experience creating, due to their knowledge about common problems and how operations can fail during use. Expected Results: A fundamental set of documents that describe procedure during a common fault a user may encounter Subtask 2: User Guide Documentation Creation Objective: Provide users with enough information to use the system and perform common operations without prior experience with the system. Approach: Each team member will produce documentation in the area in which they had the most experience creating, due to their knowledge about common use cases. Expected Results: A fundamental set of documents that describe how to perform common operations using the system Task 7: End Product Demonstration Objective: Show functionalities achieved during the project. Approach: During two separate meetings, the team will present the functional prototype to both the project advisor and the client. Expected Results: The project advisor will issue a grade for the quality of work completed, and the client will sign off on the project as complete Subtask 1: Demonstration Planning Objective: Determine how the demonstration will proceed and what will be demonstrated. Approach: The project manager will create a script that will dictate what will be shown in what order. The team will review and modify it according to their expertise, and an accompanying slideshow will be added by the team for more detail if necessary. 17

24 Expected Results: A script describing what will be presented and in what order, with the potential of an accompanying slideshow if necessary Subtask 2: Faculty Advisor Demonstration Objective: Demonstrate the system and its functionality to the faculty advisor. Approach: The team will present the system live on a computer so the advisor may see the system s functionality and examine its components. Expected Results: The advisor will give each team member a grade representative of the quality of work the team member contributed to the project Subtask 3: Client Demonstration Objective: Demonstrate the system and its functionality to the client. Approach: The team will present the system live on a computer and projector so the client may see the system s capabilities. Expected Results: The client will sign off on the project after demonstration of its completeness and review of satisfaction of its requirements Task 8: Project Reporting Objective: Report finished product to a review board. Approach: Develop a presentation that encompasses the most important aspects of developing the system including project life cycle, documentation, and the finished product. Expected Results: Presentation is well received and review board understands team's decisions Subtask 1: Project Plan Development Objective: Develop a project plan. Approach: As a team, discuss how we will go about designing and implementing the project. Expected Results: A document encompassing all aspects of how we will develop this project Subtask 2: Project Poster Development Objective: Create a project poster briefly describing the project. 18

25 Approach: The team will discuss the most important aspects of this project and decide what to display on the poster. The team will also discuss the format and style of the poster. Expected Results: A professional poster describing the project and its most important aspects Subtask 3: End Product Design Report Development Objective: Describe the design of the system on a technical level. Approach: Each team member will describe the part of the system with which they have the most expertise, and the team will put the document together. The advisor will review the document and suggest possible changes. Expected Results: A comprehensive design document that will fully describe the architecture of the system Subtask 4: Project Final Report Development Objective: Construct a report describing all aspects of the project. Approach: Each team member will describe part of the project as a whole, and the team will put the final presentation together. The advisor will review the document and suggest possible changes, and the report will be presented to the industry review board. Expected Results: A presentation and report will be created that describe the project in its entirety Subtask 5: Weekly Reporting Objective: Inform the class instructor and the faculty advisor of the team s activities and project progress. Approach: A weekly will be sent by a designated individual, decided by the project manager. Expected Results: The class instructor and faculty advisor will receive a weekly , as will the project team members. 4 Estimated Resources and Schedules 4.1 Estimated Resources 19

26 4.1.1 Personnel Effort Requirements Table describes the estimated time requirements per team member per task during the project. The numbers vary slightly due to project roles. Team Member Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Total Kenny Trytek Abby Birkett Joe Briggie Derek Woods Totals Table Personnel Effort Financial Requirements Table describes the estimated costs associated with the project. Materials costs are minimal due to the software-oriented nature of the project. Item Cost Reporting: 1. Poster Materials $ Report Materials $50.00 Labor at $20/hr: 1. Kenny Trytek $6, Abby Birkett $5, Joe Briggie $5, Derek Woods $5,680 Total $23,680 Table Financial Requirements 4.2 Schedules Project Schedule 20

27 Sept Sept Sept 27-Oct 3 Oct 4-10 Oct Oct Oct Nov 1-7 Nov 8-14 Nov Nov Nov 29-Dec 5 Dec 6-12 Dec Dec Dec 27-Jan 2 Jan 3-9 Jan Jan Jan Jan 31- Feb 6 Feb 7-13 Feb Feb Feb 28 Mar 6 Mar 7-13 Mar Mar Mar 28 Apr 3 Apr 4-10 Apr Apr Apr 25 May 1 Activity Start Date End Date Project Plan Presentaion 09/21/10 09/27/10 Project Plan Rough Draft 09/21/10 10/05/10 Project Plan Final Draft 10/05/10 10/12/10 Prototyping 10/05/10 12/10/10 Design Document Rough Draft 10/05/10 11/15/10 Design Document Final Draft 11/15/10 12/03/10 Testing Phase 01/31/11 04/04/11 System Completion 12/10/10 04/04/11 End Product Documentation 03/21/11 04/04/11 Project Poster 03/14/11 03/28/11 Project Presentation 04/25/11 04/25/11 Buffer 04/11/11 4/24/11 Fig Project Schedule Deliverables Schedule Project Plan (Final) October 12, 2010 Initial Prototypes of Each Module November 16, 2010 Design Document (Draft) November 16, 2010 Design Document (Final) December 3, 2010 Table Deliverables Schedule 5 Closure Material 5.1 Project Team Information Client Kingland Systems Matt Good th Avenue South Clear Lake, IA (641) matt.good@kingland.com 21

28 5.1.2 Advisor Simanta Mitra B21 Atanasoff Ames, IA (515) (Office) Team Members Kenneth Trytek Computer Engineering (515) Derek Woods Software Engineering (712) Abby Birkett Computer Engineering (515) Joe Briggie Computer Engineering (515) Closing Summary This project plan shows how our team plans on completing the data extraction project for Kingland Systems. The project has been broken into several deliverables/tasks that can be worked on in parallel to ensure that the project gets done by May The system has been split into five separate subsystems: Harvester, Importer, Data Access Layer, Database, and Web Services which all act independently of one another and can be worked on separately to speed up completion of the overall system. This project does not 22

29 require a lot of financial support as all of the software licenses that are required can be obtained through the school and/or funding from the Senior Design program. 23