1 / 25

Resource Allocation Tracking System Dec0909

Resource Allocation Tracking System Dec0909. IRP Presentation. Client Zirous Inc. Team Members Tyler Lamb Kirk Olson James Woestman. Faculty Advisor Tien Nguyen. Problem & Solution. Problem

jenski
Download Presentation

Resource Allocation Tracking System Dec0909

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Resource Allocation Tracking SystemDec0909 IRP Presentation Client Zirous Inc. Team Members Tyler Lamb Kirk Olson James Woestman Faculty Advisor Tien Nguyen

  2. Problem & Solution Problem Zirous Inc. is a growing company whose employees are working on numerous different projects. Managers are required to create and maintain reports on the progress and status of their employees, which are presented to upper management. The current solution is to create excel reports but this isn’t very extensible for the future and becomes difficult to manually maintain as the number of employees atZirous Inc. continues to grow. Solution An easy to use web application to track employees and projects is needed to solve this problem. This web application needs to be able to easily track the status and progress of projects as well as employees. Reports must be easy to generate from this data.

  3. System Overview

  4. User Interface & Operating Environment • Pages are built using JAVA Server Pages and JAVA Servlets. • AJAX is used to display dynamic content and reduce the network overhead. This provides a more seamless experience for the user. • IE 7 and Firefox 3 web browsers are supported.

  5. Functional Requirements FR01: Provide a web interface that allows managers to view project and resource information.FR01.1: Resource Utilization Overview.FR01.2: Project Overview.FR01.3: Personnel Overview. FR02: Provide a web interface to allow Managers to modify personnel and project information.FR02.1: Add new personnel to a project. FR02.2: Edit project attributes.FR02.3: Update project progress. FR03: Provide printable reports.FR03.1: Resource Availability Report.FR03.2: Client Program/Project Report. FR04: Interface with T2 database to retrieve personnel information. FR05: Interface with Sugar database to retrieve project information. FR06: RATS must use Zirous’ existing LDAP lookup for secure user authentication.

  6. Non-Functional Requirements NFR01: RATS must be able to be accessed from any location with internet access. NFR02: RATS must be able to scale as Zirous grows in size. NFR03: RATS must be easier to use than the current spreadsheet solution. NFR04: RATS must be able to handle multiple concurrent users using the system. NFR05: The following technologies must be utilized: Java Oracle XE Oracle Application/ OC 4 J Apache Struts2 Hibernate Apache Ant AJAX NFR06: The web interface must be responsive to user input. NFR07: RATS must be developed in a manner that makes it easy to maintain and improve in the future.

  7. Market and Literature Survey • There are resource allocation solutions currently available for use. Some of which are stand alone programs such as Microsoft Project, these typically cost anywhere from $20 for a low end product to a few hundred dollars for a nicer one such as Project. • Besides the cost for decent ones Zirous wants an online system which can be accessed from anywhere with internet access. These do exist however most of them have a monthly subscription fee and a limit to the amount of projects and data you can store. • Along with these inconveniences the products would not allow Zirous to customize them to exactly what they want. So the only viable option for them was a custom made application just for their company.

  8. Deliverables • RATS Application • RATS Source Code • Documentation • Design Document • User Manual • JavaDocs

  9. Resource Requirements • Properly configured OC4J Server • Hibernate • Apache Struts2 • JAVA • Oracle XE Database

  10. Project Schedule Spring 09 Fall 09

  11. Work Breakdown

  12. Risks • Learning Curve of New Technologies • Communication with Client • Integration with T2 and Sugar Databases • Integration with Zirous’ System • Scope Creep • Loss of Team member

  13. System Design • Rats employs a three-tiered architecture. We used the Model-View-Controller (MVC) architectural design pattern. In MVC terminology the “Model” is seen as the actual information in an application. The “View” is the user interface, everything that the user will see when using the application. The “Controller” manages communication between the Model and the View and also manipulates that data according to business rules. • Model: Oracle XEdatabase, accessed using Hibernate. • View: Java Server Pages (jsp) and Java Servlets • Controller: Struts2 • The Struts2 framework encapsulates the View and Controller concepts of the MVC architecture. In order to render a page for the end user the user first requests the page from the server. The Struts2 Controller will then analyze the request and invoke the correct Action class to handle the request. The Action class will check the state of the application (the Model, accessed using Hibernate) and return an appropriate response through the View.

  14. SW Specification

  15. Input & Output Specification • Input • Existing Databases • T2 (project information) • Sugar (employee information) • User created input from HTML Forms • Output • HTML • Excel files

  16. User Interface Specification Pages were built using JAVA Server Pages and JAVA Servlets. AJAX is used to display dynamic content and reduce the network overhead. This provides a more seamless experience for the user.

  17. Test Plan • JUnitunit testing • Tests methods individually • Boundaries of values • djUnit • Code coverage • Integration testing • User Acceptance testing • Ongoing

  18. Prototyping • A series of mockups were created and shown to Zirous for their approval.

  19. Model

  20. View • Consists of JSP pages. • Has no knowledge of where parameters came from. • Only knows how to display information to user.

  21. Controller • Consists of a struts.xml mapping file. • Mapping Sequence: • Server receives URL Request • Request is mapped to a Struts2Action Class. • Action class does unit of work, sets up parameter values, and returns a status string (“success”, “input”, “error”, etc..). • Depending on the status string, parameter values are forward to a JSP view page that knows how to display the parameters.

  22. Test Results • JUnit • All JUnit tests successfully passed before providing copy of application to Zirous. • Integration • Some initial difficulty integrating systems • Issue with different version of JAVA • User Acceptance • Feedback Positive • Making changes in response to feedback

  23. Conclusions & Lessons Learned Conclusion • Overall, we feel that we were successful in completing and overcoming the difficulties presented to us in our project Lessons Learned • Don’t discount losing a member • Spend more time in the first semester doing research of unknown software technologies. Also utilize summer break to accomplish this.

  24. Future Work • Implement bread crumbs feature • Add skill sets to projects and employees • Implement sorting of report tables • Implement “Add Like” functionality on Add Resource Page • Integrate RATS more closely into T2 or Sugar • Implement more sophisticated security functionality

  25. Questions?

More Related