Send the link below via email or IMCopy
Present to your audienceStart 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.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Smart Medical Monitoring System (SMMS)
Transcript of Smart Medical Monitoring System (SMMS)
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”
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
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
- 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:
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