s erver c lient m onitoring s ystem p resenting t eam ks3 final presentation

SERVER CLIENT MONITORING SYSTEM

PRESENTING TEAMKS3

Final Presentation

ProblemOrchard Software sells a product, Copia

Organizes Lab Results

Deals With HL7 inconsistencies

Allows physicians to order lab tests and view the results.

Client “Bob's Lab” must maintain systemBilling information must be up to date

Procedure codes

Diagnosis codes

Tests

Order Choices

Personnel

The Bob hires a medtech, “Jimbo” to do this job

Problem Medtechs do lab-related tasks well

They can look at slides.They like to smell bacteria.

They understand the billing and lab side of things

Medtechs don't do some other things wellComputers

Networks

Sometimes the person maintaining the system gets brave

Disables DFT generation

Downloads movies to the server

Doesn't notice something bad has happened

SolutionsConnect to all systems and watch them

HIPAA Issues

VPNs

Firewalls

Have the installed systems call home and give a status report.

Still a HIPAA grey area

Favors real-world network topologies

Values

Earlier detection of problems

Client is down less Costs the client less money Easier for orchard to fix Client is happier Support is happier

Fewer Headaches

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


Functional Requirements

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


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


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 developers using the DCA API in the hosting application should be able to figure out how to use the API via the Javadoc.


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.


D-Requirements

• 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.


Use-Case Diagram (DAS : Data Analysis Server)

Gathering and modeling requirementsUse-Case Diagram : (DCA : Data Collection Agent)


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

Data-Flow

Communication

Architecture

DCA Class Diagram

DAS Class Diagram

Implementation

Java 6

JPA

JAX-WS

Eclipse 3.4

Maven Checkstyle (Checks conformance to coding conventions)

JavaNCSS (Non-Comment Source Size)

Findbugs (Static Analysis)

Cobertura (Code Coverage)

Junit (Unit Testing)

JMock (Component Mocking Library)

Hamcrest(improved assert expressions)

JavaDoc W/ UMLGraph Doclet

Metrics

DCAClasses Methods NCSS Javadocs Javadoc lines

5 28 235 16 936 21 101 7 51

Methods total NCSS total Javadocs Javadoc lines Line Comment49 336 23 144 21

DASClasses Methods NCSS Javadocs Javadoc lines

8 31 255 18 95

Methods total NCSS total Javadocs Javadoc lines Line Comment31 255 18 95 0

NCSS Non-comment Statement Size

CCN Max: 9 Median: 1

Project Documentation and Management

Stakeholders

The developers (team KS3)

Kam

Seema

Shpetim

Stephen

The client (Orchard Software Corporation )


Team Organization Structure

Role Staff Member

Team Leader/Quality Manager

Stephen Gregory

Documentation Leader Seema Patil

Development Manager Kambiz Behbahani

Process and Support Manager

Shpetim Latifi


Team Organization StructureContribution 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 Shpetim Latifi

Project Documentation and ManagementSpiral Model


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.



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.

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 240 person hours for development and documentation

~ 60 hrs of development

~ 80 hrs of debugging and testing

~ 80 hrs+ 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

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

• Single costumer installs the Data Analysis Service

• Single costumer runs the Data Analysis Service

• 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; 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