Upload
didina
View
56
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Presented by:6 th May 10 Trevor GreeneSEIS- 635 Shilpi Saraswat. ASSET MANAGEMENT APPLICATION. Overview. Project Description Software Development Methodology used Requirements Artifacts Chosen Off the shelf software & libraries used Patterns Demonstration - PowerPoint PPT Presentation
Citation preview
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.