KS3

Iteration 2

Motivation

• Orchard Software sells product, Copia.– Organizes Lab Results– Deals With HL7 funny business– Allows physicians to order lab tests and view

the results.– And much much more.

Maintaining The System

• Client “Bob's Lab” must maintain system– Billing information must be up to date

• Procedure codes• Diagnosis codes• Tests • Order Choices• Personnel

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

Medtechs

• Jimbo understands Labs!– They can look at slides– They know way too much about bacteria.– They like to smell bacteria.– They (generally) undrestand the billing and lab

side of things.• Jimbo doesn't Understand

– Computers– Networks

Jimbo gets brave

• Jimbo misreads a setting the HL7 interface config and disables generation of billing messages.– A couple of days later Bob (Jimbo's boss)

realizes they haven't been getting paid.– Bob gets angry and calls Orchard for support.– Orchard software VPN's in digs through the

configuration and finds the setting Jimbo incorrectly turned off.

– Costs the client money and makes them unhappy.

Solutions• Connect to all of the systems and watch

them.(Bad)– HIPAA– VPN nightmare

• Have the all of the systems phone-home and give a status report.(Better)– Could possibly be HIPAA compliant– More favorable with real-world network

topologies (NATs, Firewals, etc).

Tools

• Eclipse 3.4• Maven

• Checkstyle• JavaNCSS• Findbugs• Pmd• Cobertura• Junit• JavaDoc W/ UMLGraph Doclet

Metrics

• DCA– NCSS -330

• Classes – 8– BugsFound - 8– Coverage

• Line 36%• Branch 33%

• DAS– NCSS -276

• Classes -11– BugsFound - 3– Coverage

• 0%

DSA

List DCAs

Get Events for DCA

Get past events of type x

Notify Clients

Manage Clients

Support Staff

Manage Events

<<extend>>

<<extend>>

<<extend>>

<<extend>>

DCASend Events to Server

UC-1

UC-2

UC-7UC-3

UC-4

UC-5

UC-6

SDD Modified : Use-Case

Configure

Register Probe

Add Events

Start

Hosting Application

Stop

Probe Respond to a Request

Receive Events

DAS

Data/Event Analysis

UC-8

UC-9

UC-10

UC-11

UC-12

UC-13

UC-14

UC-15

DCA

SDD Modified : Use-Case

Use Case Name Description(UC_1) Manage Clients This use case extends to UC_2 and UC_3

(UC_2) List DCAs Support Staff provide a list of all the clients currently connected to the server.

(UC_3) Notify Clients Support staff call the users if they see something wrong.

(UC_4) Manage Events This use case extends to UC_5 and UC_6

(UC_5) Get Events for DCA Events occurring on the client machine are observed by the support staff.

(UC_6) Get past events of type X Support staff are able to go back and pull data related to the occurrence of a specific event .

(UC_7) Send events to Server Data collection agent send the queued events to the server.

(UC_8) Configure Hosting application can define what to be monitored.

(UC_9) Register Probe Probe registration. For connection to the server.

(UC_10) Add events New events can be added.

(UC_11) Start Start DCA

(UC_12) Stop Stop DCA

(UC_13) Respond to Request Probe is waiting for a registration request to handle.

(UC_14) Receive Events Server receives the event via internet and through a designated web site interface.

(UC_15) Data/Events Analysis Received data are analyzed by the server and result is shown on the server screen for the support staff.

SDD Added : Use-Case

SDD Added : Activity Diagrams

Java

DCA

DAS

Web Services

JAX-WS

Server Container

Website

Client Machine

Hosting Application

Framework/ Application Dependency View

SDD Added : Framework Diagram

Client Application

DCA

Monitoring Services

DAS

Data

Server

StoreData

Data Analysis

Website-Present Data

SDD Added : Architecture view

Need to be Added

1- Class Diagram [SDD]

2- Requirement , Test cases and Implementation Tractability Matrix [SRS]

Software test and documentation

• Started at development phase

• Continues till the end of the project and final integration

• Both approaches used – white box and black box testing

• White box – extended from 1st iteration• Black box – mainly after the 1st iteration

Software test and documentation

Functional requirements tested:

• 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

Software test and documentation

Non-functional requirements tested: •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

Software test and documentation

• All features related to the app tested

• No previous assumptions

• Only limitation - 3 running clients at a time.

• Just as a reminder, our client (Orchard Software Corp.) will be using this application for its needs, and scalability is not a core requirement

• Proper storage of data and ease of access to be fixed and tested

SQAPWe have used the IEEE Standards for all the documents created.This Document is to specify the manner in which quality goals can be achieved for the project.It specifies :•Quality Organization and Responsibilities•Quality Goals and Procedure•Documents required for quality assurance•Techniques used to ensure qualityReviews like Software Requirement Review, Design Review , Post-mortem Reviews(at the end of each phase) have been performed.

Tools Techniques and Methodologies

Checklists are used for formal meetings, for documentsreviews and inspections.Agendas for the meeting were forwarded to each team member and an approval is achieved from all the members.After each meeting the important points discussed will be noted down and each member is through email.Subversion for source control.Eclipse 3.4 (Ganymede) was used for development.

SVVPSoftware Verification and Validation Plan is designed to:• Verify that the products of each software life cycle phase complies with previous life cycle phase requirements and products for correctness, completeness, and accuracy. Satisfies the standards, policies, practices, procedures and conventions of the phase. Establish the proper basis for initiating the next phase• Validate that the completed end product complies with established software and system requirements.