S ERVER C LIENT M ONITORING S YSTEM P RESENTING T EAM KS3 Final Presentation

G ATHERING AND MODELING REQUIREMENTS Functional Requirements Client: must communicate w/ server via Web services must be able to periodically poll for certain values (eg. CPU usage, memory usage, message queue length) ‏ must be able to receive one-time events (e.g. failures, messages.) must be able to queue up information in case of temporary network failure. Server: data must be received via Web services must be able to verify the identity of the client must be able to accept new values on the fly must store data in a query-able fashion must have at least a rudimentary view for the following statistics for a specific server "alerts" (to be found later) across all servers

G ATHERING AND MODELING REQUIREMENTS Non-Functional Requirements Client: client API must be written in Java (or any other jvm language) ‏ client and APIs related to it must be extendable and configurable from Java

G ATHERING AND MODELING REQUIREMENTS C-Requirements The DAS will have a user interface that allows users to analyze the data collected. The only hardware requirement is a network connection The main mechanism for communication between the DAS and DCA will be SOAP The DAS will need to use less than 512 MB of RAM. The DCA must be designed with the goal of keeping the memory footprint small. The developers using the DCA API in the hosting application should be able to figure out how to use the API via the Javadoc.

G ATHERING AND MODELING REQUIREMENTS D-Requirements DCA Configuration : The developer must be able to create and configure a DCA. The configuration includes endpoint address of the DAS, the available probes, polling interval, and transmission interval. Once the DCA is configured, the developer should be able to tell the DCA to connect to the DAS. Events will be transmitted from the DCA to the DAS via SOAP. The DAS must be able to store all events The system should be designed with Java best practices in mind. The DCA API should not be dependant upon other APIs as it might add an undo burden to use. Reliability: The DAS should not fail more than once every 48 hours. The DCA failure rate is harder to limit as it is dependent on the hosting application. Availability : Availability should be as high as possible. The DCA should be able to compensate for availability issues of the DAS by storing events until the DAS is available.

G ATHERING AND MODELING REQUIREMENTS Use-Case Diagram (DAS : Data Analysis Server)

G ATHERING AND MODELING REQUIREMENTS Use-Case Diagram : (DCA : Data Collection Agent)

G ATHERING AND MODELING REQUIREMENTS Specific Requirement Number Class/FunctionTest Case DCA Configuration. DCASource 4.2 Single costumer runs the Data Collection Agent (DCA) Event Transmission DataEvent Single DCA connect with the DAS Event Storage EventType 5. Multiple DCAs connect with the DAS at the same time; 6.DAS stores the information received from one or more 3.2 Performance Requirements EntityManagerFactoryLocator 4.8 DAS maintains connection with DCA on LAN for 24 hours Reliability ManagerService.EventInfo DataAnalysisServiceImpl ManagerService.EventInfo 4.8 DAS maintains connection with DCA on LAN for 24 hours Availability 4.8 DAS maintains connection with DCA on LAN for 24 hours

P ROJECT D OCUMENTATION AND M ANAGEMENT Stakeholders  The developers (team KS3) ‏ Kam Seema Shpetim Stephen  The client (Orchard Software Corporation ) ‏

P ROJECT D OCUMENTATION AND M ANAGEMENT Team Organization Structure RoleStaff Member Team LeaderStephen Gregory Documentation LeaderSeema Patil Development ManagerKambiz Behbahani Process & Support Manager Sphetim Latifi

P ROJECT D OCUMENTATION AND M ANAGEMENT Team Organization Structure ContributionDocuments Worked Staff Member Team Leader, Implementation and Testing. SPMP,SCMPStephen Gregory Documentation Management and Version control. SQAP,SVVPSeema Patil Design and Architecture SDD, SRSKambiz Behbahani Quality Assurance, Testing STD, User Manual Sphetim Latifi

P ROJECT D OCUMENTATION AND M ANAGEMENT Spiral Model

P ROJECT D OCUMENTATION AND M ANAGEMENT Configuration Management Subversion We have used Subversion to control the versions of all the created documents and for code control. Requesting Changes All requests for change should be done through the issue tracking system. Any issue related to a documentation change should be tagged with “doc.” Any changes related to a non-documentation CI should not. We report issues using Issues option in Google Code.

P ROJECT D OCUMENTATION AND M ANAGEMENT Configuration Management Approving or Disapproving Changes Approval or Disapproval will be left up to the person responsible for the Document,unless the project leader decides otherwise. Implementing Changes The person responsible for the CI for which the change is requested is responsible for making any approved changes. The responsible party may delegate the activity to another party if both parties agree. The party making the change should make a note of the new version of the document being changed. Configuration Audits and Reviews We will conduct periodic reviews of the documents we have in version control. The goal of these reviews is to makes sure the documents are correct, up to date, and follow the according standards.

B RIEF P ROCESS DESCRIPTION AND RISKS Team roles preserved during the process Slow start due to new technology for ¾ members Intensive tutorial for learning Java with Eclipse WSR and Subversion played an important role in project mgmt

R ISKS Not very familiar with Java Team members not familiar with each other No documentation experience Members involved in other ‘projects’ (classes + work)

E FFORT AND D URATION Approximately over 240 person hours for development and documentation ~ 80 hrs of development ~ 80 hrs of debugging and testing ~ 70hrs+ of documentation ~ 10 hrs of team communication + ppt

M ETRICS DCA – NCSS -330 Classes – 8 – BugsFound – 8 – Coverage Line 36% Branch 33% DAS – NCSS -276 Classes -11 – BugsFound – 3 – Coverage 0%

T ESTING AND DEBUGGING Started at development phase, completed last week Requirement matrix to test against requirements and design Both approaches used – white box and black box testing White box – extended from 1 st iteration Black box – mainly after the 1 st iteration

T ESTING LEVELS AND T YPES A huge deal of time devoted to testing and debugging Levels: Unit testing, System testing No user acceptance testing Types: Specification-based, function-based

T EST C ASES Single costumer runs the Data Collection Agent (DCA) Single costumer installs the Data Analysis Service (DAS) Single costumer runs the Data Analysis Service (DAS) Single DCA connects with DAS; DAS receives information from the DCA and outputs data in browser Multiple DCAs connect with the DAS at the same time; DAS receives information from each of the DCAs and outputs data in browser DAS stores the information received from one or more DCAs respectively into database

T EST C ASES LAN as well as 4Mbps/1Mbps High-Speed cable Internet connection Windows XP and Vista platforms, as well as Mac OS X 10.5 Two different web browsers such as IE7 & FF3 Reliability test by running the DCA on one client and the DAS for 24 hours Machines with at least Pentium 4 and 512MB of RAM

> Web site Interface SCMC GUI Client machine Connect button To server Monitoring Services Customer/UserServer Architecture- System Services

Architecture- Structure

Client Application DCA Monitoring Services DAS Data Server Store Data Data Analysis Website-Present Data Architecture- System Communication

Detailed Design - Class Relation

Detailed Design – Framework Diagram