ASSET MANAGEMENT APPLICATION

Presented by: 6th May 10Trevor Greene SEIS- 635Shilpi Saraswat

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

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.

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

PHASE ITERATION ARTIFACTS

Inception 1 Project Proposal, Software Development Plan, Configuration Management Plan, Test Plan

Elaboration 5 Software Requirements Specification, Use Case Diagram, Use Cases, system sequence diagrams,

Class Diagrams, Interaction diagrams

Construction 4 Code, Unit Tests, DDLs

Commercialization 2 Presentation, Application Manual, Final Artifacts

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.

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.

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.

Reliability and 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.

Requirements -FURPSSecurity: 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.

Analysis Artifacts Use Case Diagram

Analysis Artifacts Domain Model

System Sequence Diagram -addAsset

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 the size of the project and the use of Spring Source framework the System Sequences diagrams were not as useful as normal.

Design Artifacts -Class Diagram

Design Artifacts -Interaction Diagrams

ViewResolver

HandlerExceptionResolver

1. Request

Security Filter

Dispatch Servlet

HandlerModelAndView

Data bindingValidation

Service

Handler Mapping

View

8. Response

6

7

2

DAO4

Handler Interceptor

3 5

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/

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/

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.

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.

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.

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.

Demonstration

Achiever http://localhost:8080/assetMgmt/index.h

tm

Admin http://localhost:8080/assetMgmt/admin.

htm

Team Dynamics

Project ManagerTrevor Greene

Analyst & Design Shilpi Saraswat

DeveloperTevor Greene

Tester Shilpi Saraswat

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.

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.

SDLC UsedAdvantages: 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

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.