Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

On Demand Blood Bank-Applications of Computer Sciences-Project Report, Study Guides, Projects, Research of Applications of Computer Sciences

This report is for final year project to complete degree in Computer Science. It emphasis on Applications of Computer Sciences. It was supervised by Dr. Abhisri Yashwant at Bengal Engineering and Science University. Its main points are: Operations, ODBB, Case, Diagram, User, Request, Updating, Hospital, Monitoring, Volunteer, Registration

Typology: Study Guides, Projects, Research

2011/2012

Uploaded on 07/18/2012

padmini
padmini 🇮🇳

4.3

(202)

175 documents

1 / 17

Toggle sidebar

Related documents


Partial preview of the text

Download On Demand Blood Bank-Applications of Computer Sciences-Project Report and more Study Guides, Projects, Research Applications of Computer Sciences in PDF only on Docsity! iv List of Figures Figure 3-1Operations in ODBB .....................................................................................9 Figure 3-2 Use Case Diagram for Volunteer Registration...........................................10 Figure 3-3 Use Case Diagram for User Request ..........................................................10 Figure 3-4 Use Case Diagram for Updating Hospital s Information ...........................11 Figure 3-5 Use Case Diagram for Monitoring the System ..........................................11 Figure 3-6 Use Case Diagram for Updating Lab's Information...................................12 docsity.com v List of Tables Table 1: List of Abbreviations and their Meanings........................................................3 docsity.com 3 1.4 Glossary Table 1: List of Abbreviations and their Meanings ABBREVIATION MEANINGS HIV Human Immunodeficiency Virus. AIDS Acquired Immunodeficiency Syndrome SMS Short Messaging Service DBMS Database Management System IIS Internet Information Services NIC National Identity Card HTTP Hyper Text Transfer Protocol OS Operating System SQL Structured Query Language TCP Transmission Control Protocol SSL Secure Sockets Layer UI User Interface IP Internet Protocol 1.5 References [1] Ivan Bayross, Web Enabled Commercial Application Development Using HTML, DHTML, JavaScript, Perl, CGI, 2nd Revised Edition, New Delhi: BPB Publications, 2000. [2] Database Systems Principles, Design, and Implementation, Catherine Ricardo, Iona College, New Rochelle, New York: Maxwell Macmillan. [3] Flt Lt. Dr Sathya Prakash (Retd) , X-ray & Specialist Dental Centre , Mysore ,India, URL: http://www.bloodonweb.com/ [4] Blood Bank of Hawaii , URL: http://www.bbh.org/, Last Modified June 20, 2007. [5] Pakistan Blood Bank , URL: http://www.pakistanbloodbank.org/index.htm. docsity.com 4 1.6 Document Overview This SRS document has three sections. The first section explains the introduction to ODBB (On Demand Blood Bank), its scope, and its design goals. The second section analyses ODBB from architectural point of view. The third section explains the operations in ODBB and its functional and non-functional requirements. docsity.com 5 2 ODBB Architecture This section gives an overview of ODBB architecture. 2.1 Other Online Blood Banks in the World There are many other online blood banks in the world including India [3], Hawaii [4], Pakistan [5] and many other countries. 2.1.1 Similarities between O.D.B.B and Other Similar Systems They provide online donors database. ODBB and most of the other systems are free. Some of the systems are not affiliated to a particular hospital. 2.1.2 Differences between O.D.B.B and Other Similar Systems None of them is SMS-based None of them has any labs affiliated to them. They do their testing themselves. Some of them are not affiliated to any hospital. There is always a system admin team that facilitates the communication between the donors and the recipient. 2.2 Three Tiered System ODBB will be a three tiered system. Following are the tiers in ODBB. 2.2.1 Presentation Tier The front end (Presentation Layer) is for user s interaction with the system. This layer will be implemented on client-side. The interaction with the system will be through SMS and the web-site. 2.2.2 Application Tier On the server side, there will be the Application Tier. It would have capabilities to retrieve and store tests and results from the back end database. The application logic lies here docsity.com 8 3 Overall Description This section explains the operations of ODBB (Figure 3-1). 3.1 Main Operations in the System ODBB has following main operations The system would register a volunteer. The system would inform him about his result received from the lab. The system would send a report about every request to the concerned hospital. The hospital attendant would add every transmission specific data in the system. The system would contact a donor to see his availability. It would also inform him about his half yearly appointments. The system would get request from the user. It would reply the user about the response from donors. The labs would send information to the system about their timings and working conditions. The system would send them the volunteer s detail, who intends to go to that lab. They would also send the volunteers reports back to the lab. docsity.com \ Q Updates about Lats conditions and finings / te \ € — Lab GatRequed, Co \ / \ \ Send vclummear s detals | \ a Reply about \ | seagoc from the user % \ ‘ \ | \ Sard volunteers tepcets Check coants avaleility O.D.BB Transmssion spite dat / \ / \ Report about tar \, Creel \ anti provedwe 4 { F N, ———————_ = oN A a ofoen abcul hf yearly appoint ents Tenor ‘ \ \ Inform cbt Register volunteer sepetsfon the ab \ Hospital Figure 3-1Operations in ODBB docsity.com 10 ODBB would locate a donor of a particular blood group donor when requested by the user. The system will be completely Internet and SMS based. A back up would be taken after every two days. The donor can register via the Internet and SMS. A user can also use our system via the Internet and SMS. 3.2 Actors There will be five actors in the system 3.2.1 The Volunteer He would be the person who wants to interact with the system but isn t declared safe to be a donor (Figure 3-2). Figure 3-2 Use Case Diagram for Volunteer Registration 3.2.2The Donor He will be the person who wants to be contacted for donating blood in the future. He has been examined for diseases like AIDS, Hepatitis B, Hepatitis C and HIV. His interaction with the system would be via the Internet and SMS. 3.2.3 The User He will be the person who contacts the donor and needs to get blood. He will access the system via the Internet and SMS (Figure 3-3). Figure 3-3 Use Case Diagram for User Request docsity.com 13 3.3.3 Manipulate the Results Received from the Labs The results about the volunteer are sent by the lab to our system. If the donor has an e- mail address his report is mailed to him. If he doesn t, the report is posted to him. He is told to acknowledge on receiving the report. If he is safe, he is made a donor on the system; else he is informed about his disease and advised to get himself checked. 3.3.4 Get Request from User The user will make the blood request via SMS or Internet. Via the Web-site The user will enter the required blood group. The system will tell him if there are blood donors for that particular group or not. If yes, the user may contact them if he wishes. The system will locate them. Via SMS He will only SMS the particular blood group to the system. The system will tell about the registered number of users of that blood group. The user will tell if he wants to contact them or not. 3.3.5 Locate Donor Then the system will determine the 5 users who have had the longest break in donating blood. It will SMS them and ask if they are available or not. Those who are available are asked if they can reach the hospital. The system selects three donors, from those who can reach the hospital, and they are told to reach the hospital as soon as possible. The system should get an acknowledgement message from them. Else, the system would assume that they are not available. If none of these five donors are available, the system would select the next five donors. This process continues till no donor of that particular blood group is left. Incase, no donor turns up, the system apologizes to the user. When a donor has confirmed that he will reach the hospital, his name is shown to the user. 3.3.6 Send Report to the Hospital A report of all the user/donor interaction with the system is sent to the hospital. docsity.com 14 3.3.7 Maintain Information about the Labs The system will maintain information about the affiliated labs. It will be the duty of the labs to keep us informed of their working condition. If a lab is not working, it is not shown to the user. The labs will also tell the system about the date and time available for appointments. 3.3.8 Arrange Half Yearly Appointments for Registered Donors The system would arrange half yearly appointments for the registered donors with the affiliated labs. The donors will be checked for AIDS, Hepatitis B, and Hepatitis C. 3.3.9 Send Report to the Hospital Every time a user sends a request, the system will send a request to the hospital from where the user claims to be. This is done to prevent naughty users. The hospital will really validate if the user is there or not. 3.4 Non-Functional Requirements Definitions Nonfunctional (supplementary) requirements pertain to other information needed to produce the correct system and are detailed separately. 3.4.1 Reliability The system shall be reliable. If the server crashes, the data will not be lost because a backup will be maintained. The server would take 5 minutes on the average for re- starting. The lost data would be restored within 2 hours. 3.4.2 Availability The system shall be accessed globally over the Internet. It would be available 24 hrs. 3.4.3 Security This is a very sensitive aspect of this project. The system should be secure as malicious users should be prevented from accessing and updating other users accounts and records. ODBB would implement SSL security. The password would not be less than 12 characters. docsity.com 15 3.4.4 Maintainability On Demand Blood Bank shall be designed in a way that is easy to maintain in the future. 3.4.5 Usability The system will be easy to use, so that any one with the basic knowledge of Internet- interaction or any one who can send and receive SMS would be able to use this system. This system will also be friendly for its maintaining and administration staff. 3.4.6 Scalability The system shall be designed in a way that it can be extended in future. In other words, other hospitals can use it without needing to redesign it from scratch. 3.4.7 Life Criticality The system is really life critical. The donors detected by it would have to be of the required blood group. The system should not malfunction in any-case. 3.4.8 Portability The system shall be portable from one computer to another. 3.5 Constraints The donor should be a resident of Islamabad/Rawalpindi. The user can only interact with out system while being in Islamabad/Rawalpinidi. Every volunteer should have a mobile. The user must have a mobile or Internet Access. docsity.com
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved