Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Smart Medical Monitoring System (SMMS)

32570 Enterprise Software Architecture and Middle ware Application

salah uddin

on 7 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Smart Medical Monitoring System (SMMS)

32570 Enterprise Software Architecture and Middle ware Patient Details SHS Smart Health System (SHS) SHS Agenda INTRODUCTION
CONCLUSION Doctors Type Presented By Aaina Gupta 10592259
Prathyu Samy 11261207
Md.Salah Uddin 11298508
Niharika Gadalli 11172537
Amandeep Singh Saini 11103544 Patient Login SHS SHS Search Doctors SHS List Of Doctors SHS Search Medicine Project Overview Develop an unobtrusive health system

System goal: enhance existing system

Primary benefit: allows medical employees easier
access to acquire information by using
Smartphone technology Problem Understanding Functionality:

Minimum personal intrusion- username and password

Ensure timely information is presented to the medical staff SYSTEM DEVELOPMENT PLAN Boundary Model Constraints Project Organisation Process Model Boehm Spiral Model SYSTEM QUALITY ASSURANCE PLAN System Quality Assurance Plan Purpose:
ensures that the system developed corresponds to the user’s exact requirements.

provides the documentations, standards and procedures in preparation for the development of the Smart Health System (SHS). Documentation IEEE Standard 730-2002 recommends:

Concept of Operations Document (ConOps)-IEEE Standard 1362-1998 (IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document).

System Requirements Description (SRD)-IEEE Standard 830-1998 (IEEE Recommended Practice for Software Requirements Specifications)

System Design Description (SDD)-IEEE Standard 1016-1998 (IEEE Recommended Practice for Software Design Descriptions).

Verification and Validation Plans (VVP)-the IEEE Standard 1012-2004 (IEEE Standard for Software Verification and Validation), as well as the IEEE Standard 829-1998 (IEEE Standard for Software Test Documentation), and IEEE Standard 1008 (IEEE Standard for Software Unit Testing).

Verification Results Report and Validation Results Report-the IEEE Standard 1012-2004 (IEEE Standard for Software Verification and Validation: 6.1 V&V Reporting Requirements) Standards, Practices,
Conventions and Metrics Documentation Standard

Design Standards-IEEE 1016-2009 standard for IT System Design/Software Design

Coding Standards-GNU standard, Richard Stallman, 2011, “ ...a system to create programs that clean, consistent, and easy to install. The GNU standard can also be used as a guide to writing portable, robust and reliable programs”

Commentary Standards

Testing Standards and Practices-IEEE 829-2008 standard for software testing

Selected Software QA Product and Process Metrics-Cyclamate complexity and the fog index Review and Audits Software Specifications Review-“The SSR is held to assure the adequacy of the requirements stated in the SRD,” (IEEE 730-2002)

Architecture Design Review-“The ADR is held to evaluate the technical adequacy of the preliminary design (also known as top-level design) of the software as depicted in the preliminary software design description,” (IEEE 730-2002).

Verification and Validation review-“The verification and validation plan review is held to evaluate the adequacy and completeness of the verification and validation methods defined in the verification and validation plans” (IEEE 730-2002).

Managerial reviews- “Managerial reviews are held periodically to assess the execution of all of the actions and the items identified in the SQAP. Management reviews are carried out by, or on behalf of, the management personnel having direct responsibility for the system. This review may require additional changes in the SQAP itself,” (IEEE 730-2002).

Technical Audits Testing To ensure quality in the testing the project team will follow the IEEE 829-2008 standard for Software and System Test Documentation

Test audit checklist: Problem Reporting & Corrective Action Risk Management How did we
ensure Quality? Peer reviews
Team Meetings
Formal Reviews
Defect management plan Issues and how we
overcame them. Severe time constraints imposed.
Made sure that all teams had milestones.
Sharp learning curve in understanding.
Made subject matter expert’s as Team Leaders.
Adherence to Quality
QA team made regular checks of work being done against a set template. Reference Institute of Electrical and Electronics Engineers, 1988, IEEE Std 1058.1 – 1987, IEEE Standard for Software Project Management Plans, The Institute of Electrical and Electronics Engineers, New York.
Institute of Electrical and Electronics Engineers, IEEE Std 1059-1993 IEEE Guide for Software Verification and Validation Plans, The Institute of Electrical and Electronics Engineers, New York.
Institute of Electrical and Electronics Engineers, 2000, IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, The Institute of Electrical and Electronics Engineers, New York.
Institute of Electrical and Electronics Engineers, 1998, IEEE Std 1061-1998, IEEE Standard for Software Quality Metrics Methodology, The Institute of Electrical and Electronics Engineers, New York.
Institute of Electrical and Electronics Engineers, 1995, IEEE Std 730.1-1995, IEEE Standard for Software Quality Assurance Planning, The Institute of Electrical and Electronics Engineers, New York. Q & A Thank You SHS Nurse Login

Doctors Login SHS Nurse Entry SHS SHS Doctors Entry Entry Medicine SHS Pharmachy Time Table SHS SRS formally specifies the system level requirements of the system.

Desired SRS Characteristics:




Traceable System Requirement Specification Requirements Raw requirements
- user requirements
- exact user requirements

Informal requirements
- functional requirements
- non-functional requirements Architecture Enterprise system using smart phone technology.
support patient information
to eliminate misinterpreted data and data entry which consumes lot of time and money. Stakeholders Primary:
Medical staff
Project team

Network provider staff
Hardware providers Candidate Architecture:
client/server model Key Systems Attributes Reliability and Availability
Usability and Maintainability
Scalability and Extensibility Detailed Design Comprises to two main parts

Smart Health Unit

Communication Module Smart Health Unit This unit is basically used for the storage and processing of the data.

It is also responsible for taking actions according to data processing information.

This unit works on the layered architecture format. Communication Module The design composition of this unit is slightly different from that of Smart Home Unit.
It comprises of sub-systems such as:
Event SubsystemReport Subsystem
•Smartphones - A Smartphone device is not a portable computer: the screen is much smaller, the computing power is significantly less, and the input of data can be time consuming.

•Work required migrating to new system
Full transcript