EEL-5881

An essential aspect of academic research is in reviewing the literature and state of the art of a subject. In today's information age, the literature on a topic is typically found through the Internet as individual files with a common structure that reveals information such as the paper's author, publication source, abstract, data of publication, and references to related research. The body of these documents is the heart of the material, but these structural components can provide a means for searching and organizing documents on a particular topic. While Internet search engines provide the initial mechanism for finding material, they do adequately associate related publications nor provide the ability for a researcher to annotate or review an article. Moreover, search engines do not offer a collaboration system for colleagues to leverage prior literature reviews. In short, the Internet is a general repository for academic publication, and search engines provide access to find such documents, but there are few applications that allow found material to be further organized, cross-referenced, annotated, reviewed, and made available to like-minded researchers. These needs are the impetus behind the Research Expert system.

Applicable Standards

Coding Standard - Microsoft .NET framework design guidelines for class library developers will be used. For more details see the link http://msdn.microsoft.com/en-us/library/czefa0ke.aspx
Document Standard - HTML templates from this link http://www.eecs.ucf.edu/courses/eel5881/ProjectTemplates.html are used for documentation.
- Font size: 10
- Spacing: single
- Table of content: Included at top of each document
Artifact Size Metric Standard - The size of the project will be measured by lines of code. This will further be separated into total lines of code, comments, and blank lines. Also, we will measure the size of the project by number of classes, files, and assemblies on the C#/application side. On the database side we will count the number of tables, views, and stored procedures. Additionally, we will measure the size of our testing system through the number of unit tests.

Project Team Organization

Our team has three members. The project is divided into several task and shared among the team members.

Members of the group:
- Joshua Thompson
- Prabhavathi Kumarasamy
- Paul Varcholik
Role in a project:
- Joshua is responsible for the testing and the test reports.
- Prabhavathi is responsible for the project management plan and testing.
- Paul is responsible for the requirement specification, coding and also for the website.
- Each team member is responsible for the documentation of their respective task.
Communication is through scheduled face-to-face meetings and through mails.

Deliverables

Artifact	Due Dates <some will have multiple deliveries>
Meeting minutes	Weekly
Individual log	Weekly
Group Project Management Reports	At every meeting
ConOps	Oct 1,2008
Project Plan	Oct 1,2008
SRS	Oct 1,2008
High-Level Design	Nov 5,2008
Detailed Design	Nov 5,2008
Test Plan	Oct 1,2008
User's Manual	Dec 5,2008
Final Test Results	Dec 5,2008
Source, Executable, Build Instructions	Dec 5,2008
Project Legacy	Dec 5,2008

Software Life Cycle Process

Tools and Computing Environment

Operating System: Windows XP
Programming languages:

Front-End tools: ASP.Net, C#, HTML, CSS
Back-End tool: SQL 2005
Web Server: IIS 7
Compiler: Visual Studio 2005

Configuration Management

Perforce software will be used for checking the significant modifications (that have been developer tested) and for each test session. The Perforce server will access files from the repository and will show the modifications between the previous and current version of the files. For more details of Perforce software see the link http://www.perforce.com/

Paul Varcholik is responsible for configuration management.

Quality Assurance

In the beginning, the project will be tested at each milestone. When it reaches the final stage, it will be tested continuously and errors will be corrected immediately. Joshua Thompson and Prabhavathi are responsible for testing and test results will be reported to the team members by the test report spreadsheet. For more details about the test plan see the link Test Plan.

Risk Management

To schedule a team meeting in a day/time appropriate to other team members. So the members have to discuss and finalize the day and time comfortable to all.

Project Scope: Finishing the project within time and budget is very important. Team members are informed to finish their work in time without any delay and over budget.

Technical risk arise during implementation will be corrected by appropriate testing that will take place iteratively.

Table of Work Packages, Time Estimates, and Assignments

Project Planning

1 Month (Ending 10/1)

All

Coding & Concurrent Testing

1 Month (Ending 11/5)

Paul Varcholik

Beta (Testing & Bug Fixing)

3 Weeks (11/6-12/1)

Joshua Thompson & Prabhavathi (Testing) Paul (Bug Fixing)

Documentation

Concurrent (Entire Project Length) (Ending 12/5)

All

PERT Chart

Technical Progress Metrics

Requirement phase:

Total number of requirements, the number of requirements by priority divided into high, normal and low, total number of tests created.

Design phase:

Number of design documents produced, total number of tasks generated.

Implementation phase:

The amount of time estimated vs. actual time. Task time will be measured in hours (in 1 hour increment). Running list of tasks: Number of tasks not started, in-progress, completed and cancelled. Also include number of on-time tasks and number of over-estimated tasks.

Testing phase:

Number of tests runs, passed and failed.

Deployment phase:

Number of submissions sent to the customer.

Plan for tracking, control, and reporting of progress

Every Friday, each team member will send a report to the group regarding this week's accomplishments, next week's scheduled tasks, and notes on problems encountered. The group will collectively address outstanding problems identified in these reports, taking corrective action as necessary. The team will meet with the customer at each milestone, to discuss the project's progress, outstanding issues and to demonstrate the application. The customer's involvement will increase dramatically during the beta period, where he will be consulted on scoping, acceptance testing, and final deployment. Meeting minutes will be reported after every customer encounter.