Upload
kiefer
View
31
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Server Client Monitoring System Presenting Team KS3. Final Presentation. Gathering and modeling requirements. Functional Requirements Client: must communicate w/ server via Web services must be able to periodically poll for certain values ( eg . CPU - PowerPoint PPT Presentation
Citation preview
SERVER CLIENT MONITORING SYSTEM
PRESENTING TEAMKS3
Final Presentation
GATHERING AND MODELING REQUIREMENTSFunctional 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
GATHERING AND MODELING REQUIREMENTS
Non-Functional RequirementsClient:• 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
GATHERING 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.
GATHERING 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.
GATHERING AND MODELING REQUIREMENTS
Use-Case Diagram (DAS : Data Analysis Server)
GATHERING AND MODELING REQUIREMENTS
Use-Case Diagram : (DCA : Data Collection Agent)
GATHERING AND MODELING REQUIREMENTS
Specific Requirement Number
Class/Function Test Case
3.1.1 DCA Configuration. DCASource4.2
Single costumer runs the Data Collection Agent (DCA)
3.1.2 Event Transmission DataEventSingle DCA connect with the DAS
3.1.3 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
EntityManagerFactoryLocator4.8 DAS maintains connection with DCA on LAN for 24 hours
3.4.1 Reliability
ManagerService.EventInfo
DataAnalysisServiceImpl
ManagerService.EventInfo
4.8 DAS maintains connection with DCA on LAN for 24 hours
3.4.2 Availability4.8 DAS maintains connection with DCA on LAN for 24 hours
PROJECT DOCUMENTATION AND MANAGEMENT
Stakeholders
The developers (team KS3)KamSeema Shpetim Stephen
The client (Orchard Software Corporation )
PROJECT DOCUMENTATION AND MANAGEMENT
Team Organization Structure
Role Staff Member
Team Leader Stephen Gregory
Documentation Leader Seema Patil
Development Manager Kambiz Behbahani
Process & Support Manager
Sphetim Latifi
PROJECT DOCUMENTATION AND MANAGEMENT
Team Organization Structure
Contribution Documents Worked
Staff Member
Team Leader, Implementation and Testing.
SPMP,SCMP Stephen Gregory
Documentation Management and Version control.
SQAP,SVVP Seema Patil
Design and Architecture
SDD, SRS Kambiz Behbahani
Quality Assurance, Testing
STD, User Manual
Sphetim Latifi
PROJECT DOCUMENTATION AND MANAGEMENT
Spiral Model
PROJECT DOCUMENTATION AND MANAGEMENT
Configuration ManagementSubversionWe have used Subversion to control the versions of all the created documents
and for code control.
Requesting ChangesAll 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.
PROJECT DOCUMENTATION AND MANAGEMENT
Configuration Management
Approving or Disapproving ChangesApproval or Disapproval will be left up to the person responsible for theDocument,unless the project leader decides otherwise.Implementing ChangesThe person responsible for the CI for which the change is requested isresponsible for making any approved changes. The responsible partymay delegate the activity to another party if both parties agree. Theparty making the change should make a note of the new version of thedocument being changed.Configuration Audits and ReviewsWe will conduct periodic reviews of the documents we have in versioncontrol. The goal of these reviews is to makes sure the documents arecorrect, up to date, and follow the according standards.
BRIEF PROCESS 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
RISKS
Not very familiar with Java
Team members not familiar with each other
No documentation experience
Members involved in other ‘projects’ (classes + work)
EFFORT AND DURATION
Approximately 400 person hours for development and documentation
~ 100 hrs of development
~ 130 hrs of debugging and testing
~ 150hrs+ of documentation
~ 20 hrs of team communication + ppt
METRICS
• DCA– NCSS -330• Classes – 8
– BugsFound – 8
– Coverage• Line 36%• Branch 33%
• DAS– NCSS -276• Classes -11
– BugsFound – 3
– Coverage• 0%
TESTING 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 1st iteration• Black box – mainly after the 1st iteration
TESTING LEVELS AND TYPES
A huge deal of time devoted to testing and debugging
Levels: Unit testing, System testing
No user acceptance testing
Types: Specification-based, function-based
TEST CASES• 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
TEST CASES
• 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