ASSET MANAGEMENT APPLICATION

1. Presented by: 6th May 10 Trevor Greene SEIS- 635 Shilpi Saraswat ASSET MANAGEMENT APPLICATION

2. Overview • Project Description • Software Development Methodology used • Requirements • Artifacts Chosen • Off the shelf software & libraries used • Patterns • Demonstration • Team structure and organization • Team Communication • Post Mortem • Summary

3. Project Description • Online Asset Management Application. • Used for tracking a company’s computer related assets like servers, monitors, switches along with hardware that gets added to the servers like, memory and hard drives. • Users of the system are internal and use the system to update the information of asset inventory and check the status of assets. • System can search the inventory for the asset and enable the staff to modify the information about a specific asset.

4. Software Development Methodology We used an iterative approach to our development, using one week time blocks for each phase.

5. Artifacts -Analysis • Project Proposal: First artifact created. High Level Definition. • Use Case Diagram: Useful for defining the scope of the application. • Use Cases: Created fully dressed use cases for all of the cases in our use case diagram. • Domain Model: Created a domain model to get a feel for the primary objects involved . • System Sequence Diagrams: We crated a couple of these to see if they provided any value. We did not find them very useful because the system was not complex. • Software Requirements Specification : Detailed description of FURPS+ goals. Document revisited in the design phase. Not much useful in our case. • Other Documents: • Software Development Plan: Defined goals and schedule. • Test Plan: Definition of testing and goals. • Configuration Management Plan : Definition of build management and goal.

6. Requirements - FURPS+ Functional: Primary focus for this first version of the software. • Archivist can use the system interface to add, update, delete, retire, search and associate an asset in the database. • Staff adds an asset by populating the following attributes: Asset type, Vendor , Model, Location, Value, Purchase Date and Depreciation schedule. • Unique asset tag number is generated after the asset is added to the system. • Admin can use the system to manage sites, models and vendors • Should be equipped with authorization service to grant the access to the system.

7. Requirements - FURPS+ Usability: • We picked a web based application to make it compatible with most platforms. • The human interface of the application includes a user-friendly GUI and provides useful information if their is an issue. Reliabilityand Performance: • Not a major concern with this application due to its small user base and non-vital nature. • Used off the shell software that would allow the system to scale and is known to be reliable making the software less of a variable. • If these become an issue we could add redundancy to improve reliability and scale the servers for performance.

8. Requirements -FURPS Security: • As application was internal and less susceptible to malicious users security is not a major concern. • We did not initial plan to add an ACL mechanism to the application but decided to add it in towards the end of the project. The use of spring made implementation of this very easy and cause zero re-write. Supportability: • Our primary focus of supportability was the maintainability of the application. We decided to apply governance while coding. For example coding conventions, documented code… • Although this is an application that has a specific purpose and not a frame work we built it to be extensible. For example changing the persistence in our application would be easy. • Testing was not a primary concern for this project. We did not build in any features to make testability easier, but we did us JUnit.

9. Analysis Artifacts Use Case Diagram

10. Analysis Artifacts Domain Model

11. System Sequence Diagram -addAsset

12. Artifacts -Design • Class Diagram: Initially useful for defining the layers of the application. Eventually became a burden to update after development was well on it’s way. Would helpful to a new developer on the project. • Interaction Diagrams: Due to thesize of the project and the use ofSpring Source framework the System Sequences diagrams were not as useful as normal.

13. Design Artifacts -Class Diagram

14. Design Artifacts -Interaction Diagrams

15. Off the shelf software used • Runtime • Tomcat • http://tomcat.apache.org/ • MySQL • http://mysql.com/ • Java (JRE 1.6) • http://java.sun.com/ • Development • Eclipse • http://www.eclipse.org/ • Ant • http://ant.apache.org/ • Hudson – Continuous integration engine • http://hudson-ci.org/ • SubVersion – Version control • http://subversion.tigris.org/ • Google Code • http://code.google.com/p/stu635/

16. Libraries Used • Spring Source Framework • http://www.springsource.org/ • Apache Commons • http://commons.apache.org/ • JavaSever Pages Standard Tag Library (JSTL) • http://java.sun.com/products/jsp/jstl/ • Log4J • http://logging.apache.org/log4j/ • DiplayTag • http://displaytag.sourceforge.net/1.2/ • JUnit • http://www.junit.org/ • MySQL Driver • http://www.mysql.com/products/connector/

17. Patterns -MVC • Our application did not require us to use an Model-View-Controller (MVC) pattern and if we wrote this application for a business we may choose to keep the application structure flat. • We decided to use the MVC pattern to gain a better understanding of the Spring MVC framework.

18. Patterns -Persistence • We purposely created a JDBC layer in our application so that persistence implementation could be changed without effecting the other layers. We accomplished this by using an data access object (DAO) interface. • We utilized the Spring Source Framework to handle the complexities of persistence. • One issue that we discovered was there was no good way to handle integrity constraint issues. We experimented with catching the exception on the DAO and then throwing a custom message to the view so that the view would not need to have the business logic only the ability to receive an error message.

19. Patterns -Validation • No coupling between service and view. The Spring framework provides a means to validate beans prior calling any services. This created a good separation between the views and the business logic. The view simply displays checks for an error flag and displays the error if it exists. • Possibly a good spot to add security checks to the application.

20. Patterns -Security • Was not a major concern, but decided to implement some security patterns as we had time towards the end of the project. • URI ACL – We implemented a simple URI based access control to the system using Spring’s security framework. • With more time we would like to have implement service level ACL. Spring makes this simple with security annotations.

21. Demonstration • Achiever • http://localhost:8080/assetMgmt/index.htm • Admin • http://localhost:8080/assetMgmt/admin.htm

22. Team Dynamics

23. Team Organization Team Organization Accomplishments: • Team members gained a lot of knowledge by working collaboratively • Small team size resulted to have an effective communication. Team Organization Challenges: • Minimal work experience of one of the team member. • Small team size with only 2 team members is the major challenge to complete the project on time and within the schedule.

24. Team Communication • Team communication is planned during project planning phase. • The main communication medium used was face to face team meetings during class project time. • Other communication medium used included Emails and Phone calls. • All the communication mediums chosen are used effectively to communicate and to distribute information among team members. • Use of Google code for version control helped reducing clutter in mailboxes.

25. SDLC Used Advantages: • We have working software at very early stage of the project. • Lessons learned at the end of each iteration helped us to improve our team effectiveness and project quality for the subsequent iteration • Provided us much more visibility on the project progress and schedule deadlines. Challenges: • Making sure current iteration is compatible with the previous iterations. • There is no enough time for Testing at the end of each iteration

26. Post Mortem • Things we could have done differently if we get another chance: • Added more functionality which we came up during our Analysis phase and implement all the classes in our analysis model which have been left due to time constraints • Use autowiring or Grails to speed up implementation • Provide more system documentation with user manuals. • Structure the team differently initially.