20-01-2016, 05:00 PM
INTRODUCTION
1.1. Project Overview
The Blood Donation Agent is to create an e-Information about the donor and organization that are related to donating the blood. Through this application any person who is interested in donating the blood can register himself in the same way if any organization wants to register itself with this site that can also register. Moreover if any general consumer wants to make request blood online he can also take the help of this site. Admin is the main authority who can do addition, deletion, and modification if required.
1.2. Project Description
This project is aimed to developing an online Blood Donation Information. The entire project has been developed keeping in view of the distributed client server computing technology, in mind.
The Blood Donation Agent is to create an e-Information about the donor and organization that are related to donating the blood. Through this application any person who is interested in donating the blood can register himself in the same way if any organization wants to register itself with this site that can also register. Moreover if any general consumer wants to make request blood online he can also take the help of this site.
Admin is the main authority who can do addition, deletion, and modification if required.
The project has been planned to be having the view of distributed architecture, with centralized storage of the database. The application for the storage of the data has been planned. Using the constructs of MS-SQL Server and all the user interfaces have been designed using the ASP.Net technologies.
The database connectivity is planned using the “SQL Connection” methodology. The standards of security and data protective mechanism have been given a big choice for proper usage.
The application takes care of different modules and their associated reports, which are produced as per the applicable strategies and standards that are put forwarded by the administrative staff.
The entire project has been developed keeping in view of the distributed client server computing technology, in mind. The specification has been normalized up to 3NF to eliminate all the anomalies that may arise due to the database transaction that are executed by the general users and the organizational administration. The user interfaces are browser specific to give distributed accessibility for the overall system. The internal database has been selected as MS-SQL server 2000.
The basic constructs of table spaces, clusters and indexes have been exploited to provide higher consistency and reliability for the data storage. The MS-SQL server 2000 was a choice as it provides the constructs of high-level reliability and security. The total front end was dominated using the ASP.Net technologies. At all proper levels high care was taken to check that the system manages the data consistency with proper business rules or validations.
The database connectivity was planned using the latest “SQL Connection” technology provided by Microsoft Corporation. The authentication and authorization was crosschecked at all the relevant stages. The user level accessibility has been restricted into two zones namely.
Problem Definition
2.1 Existing System
• Cannot Upload and Download the latest updates.
• No use of Web Services and Remoting.
• Risk of mismanagement and of data when the project is under development.
• Less Security.
• No proper coordination between different Applications and Users.
• Fewer Users – Friendly
Disadvantages
1. User friendliness is provided in the application with various controls.
2. The system makes the overall project management much easier and flexible.
3. Readily upload the latest updates, allows user to download the alerts by clicking the URL.
4. There is no risk of data mismanagement at any level while the project development is under process.
5. It provides high level of security with different level of authentication.
2.2. Proposed System
To debug the existing system, remove procedures those cause data redundancy, make navigational sequence proper. To provide information about audits on different level and also to reflect the current work status depending on organization/auditor or date. To build strong password mechanism.
Advantages:
• User friendliness I provided in the application with various controls.
• The system makes the overall project management much easier and flexible.
• Readily upload the latest updates ,allows user to download the alerts by clicking the url.
• It provides high level of security with different level of authentication.
Feasibility Study
Preliminary investigation examine project feasibility, the likelihood the system will be useful to the organization. The main objective of the feasibility study is to test the Technical, Operational and Economical feasibility for adding new modules and debugging old running system. All system is feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary investigation:
• Technical Feasibility
• Operation Feasibility
• Economical Feasibility
3.1. Technical Feasibility
The technical issue usually raised during the feasibility stage of the investigation includes the following:
• Does the necessary technology exist to do what is suggested?
• Do the proposed equipments have the technical capacity to hold the data required to use the new system?
• Will the proposed system provide adequate response to inquiries, regardless of the number or location of users?
• Can the system be upgraded if developed?
• Are there technical guarantees of accuracy, reliability, ease of access and data security?
Earlier no system existed to cater to the needs of ‘Secure Infrastructure Implementation System’. The current system developed is technically feasible. It is a web based user interface for audit workflow at NIC-CSD. Thus it provides an easy access to the users.
The database’s purpose is to create, establish and maintain a workflow among various entities in order to facilitate all concerned users in their various capacities or roles. Permission to the users would be granted based on the roles specified. Therefore, it provides the technical guarantee of accuracy, reliability and security.
The software and hard requirements for the development of this project are not many and are already available in-house at NIC or are available as free as open source. The work for the project is done with the current equipment and existing software technology. Necessary bandwidth exists for providing a fast feedback to the users irrespective of the number of users using the system.
3.2. Operational Feasibility
Proposed projects are beneficial only if they can be turned out into information system. That will meet the organization’s operating requirements. Operational feasibility aspects of the project are to be taken as an important part of the project implementation. Some of the important issues raised are to test the operational feasibility of a project includes the following: -
• Is there sufficient support for the management from the users?
• Will the system be used and work properly if it is being developed and implemented?
• Will there be any resistance from the user that will undermine the possible application benefits?
This system is targeted to be in accordance with the above-mentioned issues. Beforehand, the management issues and user requirements have been taken into consideration. So there is no question of resistance from the users that can undermine the possible application benefits.
The well-planned design would ensure the optimal utilization of the computer resources and would help in the improvement of performance status.
3.3. Economic Feasibility
A system can be developed technically and that will be used if installed must still be a good investment for the organization. In the economical feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs.
The system is economically feasible. It does not require any addition hardware or software. Since the interface for this system is developed using the existing resources and technologies available at NIC, There is nominal expenditure and economical feasibility for certain.
System Analysis
4.1. Software Requirement Specification (SRS)
The software, Site Explorer is designed for management of web sites from a remote location.
INTRODUCTION
Purpose: The main purpose for preparing this document is to give a general insight into the analysis and requirements of the existing system or situation and for determining the operating characteristics of the system.
Scope: This Document plays a vital role in the development life cycle (SDLC) and it describes the complete requirement of the system. It is meant for use by the developers and will be the basic during testing phase. Any changes made to the requirements in the future will have to go through formal change approval process.
DEVELOPERS RESPONSIBILITIES OVERVIEW:
The developer is responsible for:
• Developing the system, which meets the SRS and solving all the requirements of the system?
• Demonstrating the system and installing the system at client's location after the acceptance testing is successful.
• Submitting the required user manual describing the system interfaces to work on it and also the documents of the system.
• Conducting any user training that might be needed for using the system.
• Maintaining the system for a period of one year after installation.
The modules involved are:
1. Administration:
In this module the Administrator has the privileges to add all the Blood Groups, Blood Type, Organization, Type, Country, State, City, and Location. He can search all the info about the Organization, Donor.
User Account:
• AccountID
• Username
• Password
• UserDesc
• HintQuestion
• Answer
• RoleID
• Active
Functionality
Association User Account with UserRole.
Association User Account with Organisation.
Association User Account with personal Details.
Association User Account with Employee deatails.
Association User Account with BloodDonation Details.
Alerts:
• All fields are mandatory
• Select user role
• Select role id
• Select role name
UserRole:
RoleID
RoleName
RoleDesc
Active
Functionality:
• Association user role with user Account Alerts:
• Select Role Id
• Select role name
BDA State:
• StateID
• StateName
• StateCode
• StateDesc
• CountryID
• Active
Functionality:
• Association state with city
• Assocition state with Address
Alerts:
• Select State id
• Select state name
Country:
• CountryID
• CountryName
• CountryDesc
• CountryCode
• Active
Functionality:
• Association state with country
• Assocition state with Address
Alerts:
• Select countryId
• Select countryname
• Select country code
BDA City:
• CityID
• CityName
• CityDesc
• CityCode
• StateID
• Active
Functionality:
• Association Location with city
• Assocition Address with city.
Alerts:
• Select cityId
• Select cityNane
• Select state code
BDALocation:
• LocationID
• LocationName
• LocationDesc
• LocationCode
• CityID
• Pin code
• Active
Functionality:
• Association Location with Address.
Alerts:
• Select LocationId
• Select Location Name
• Select Pincode.
BloodGroup:
• BloodGroupID
• BloodGroup
• Description
• Active
Functionality:
• Association Blood group with Personal details.
Alerts:
• Select BloodGroupID
• Select BloodGroupID
Blood Type:
• BloodTypeID
• TypeName
• TypeDesc
• Active
Functionality:
• Association Blood type with Personal details.
Alerts:
• Select BloodGroupID
• Select Type Name
Personal Details:
• UserAccountID
• FirstName
• MiddleName
• LastName
• DOB
• Weight
• Gender
• ImageURL
• BloodGroupID
• BloodType
• BloodType
• AddressID
• ContactNo_Office
• ContactNo_Residence
• MobileNo
• Active
Functionality:
• Association personal detaials with preferd location Day Time Details.
Alerts:
• Select user account id
• Select Email id
• Select date of birth
Call Center:
In this module all the employee who has been appointed by Admin will come. Admin will add all the information of employee and assign user name and password to them. By using that user name and password they will enter to their login and can search for all the donor, and about all the blood request which have been made by either consumer, donor or any organization. Call center people will assign donor to related request.
Employee Detail:
• EmpId
• Name
• Address
• Phone
• Active
Functionality:
• Association Employee Details type with user Accounts.
Alerts:
• Select Emp Id
• Select email id
Donor:
Donor is that person who is interested in donating their blood so they can register themselves through this website. If any requirement comes then they will be contacted and they can donate their blood. Along with it they can search for the various organization locations wise and can also make request for blood if needed
Donation Frequencies:
• Frequency ID
• Frequency
• Description
Functionality:
• Association Donor Frequencies with Blood donation preferences.
Alerts:
• Select Frequency Id
Donor Preferred Organization:
• User Account D
• Organization ID
• Active
Functionality:
• Association Donor preferred organization with personal details.
Alerts:
• Select user account id
• Select organization id.
Organization:
In this module if any organization wants to register itself then it can do it. It can also search for donor location wise and if needed then it can also make request for blood
Organization:
• OrgID
• OrgName
• OrgType
• OrgAddrID
• OrgImageURL
• OrgDescription
• ContactNo
• MobileNo
• Active
• Comment
Functionality:
• Association organization type with Organization type.
Alerts:
• Select OrgId
• Select Email
Organization Type:
• TypeID
• TypeName
• Type Description
Functionality:
• Association organization type with Organization.
Alerts:
• Select Type Id
• Select Type Name
HARDWARE REQUIREMENTS:
• PIV 2.8 GHz Processor and Above
• RAM 512MB and Above
• HDD 20 GB Hard Disk Space and Above
SOFTWARE REQUIREMENTS:
• WINDOWS OS (XP / 2000 / 200 Server / 2003 Server)
• Visual Studio .Net 2005 Enterprise Edition
• Internet Information Server 5.0 (IIS)
• Visual Studio .Net Framework (Minimal for Deployment)
• SQL Server 2000 Enterprise Edition
System Design
5.1. Data Flow Diagrams (DFD)
A data flow diagram is graphical tool used to describe and analyze movement of data through a system. These are the central tool and the basis from which the other components are developed. The transformation of data from input to output, through processed, may be described logically and independently of physical components associated with the system. These are known as the logical data flow diagrams.
The physical data flow diagrams show the actual implements and movement of data between people, departments and workstations. A full description of a system actually consists of a set of data flow diagrams. Using two familiar notations Yourdon, Gane and Sarson notation develops the data flow diagrams. Each component in a DFD is labeled with a descriptive name. Process is further identified with a number that will be used for identification purpose.
The development of DFD’S is done in several levels. Each process in lower level diagrams can be broken down into a more detailed DFD in the next level. The lop-level diagram is often called context diagram. It consists a single process bit, which plays vital role in studying the current system. The process in the context level diagram is exploded into other process at the first level DFD.
The idea behind the explosion of a process into more process is that understanding at one level of detail is exploded into greater detail at the next level. This is done until further explosion is necessary and an adequate amount of detail is described for analyst to understand the process.
Larry Constantine first developed the DFD as a way of expressing system requirements in a graphical from, this lead to the modular design. DFD is also known as a “bubble Chart” has the purpose of clarifying system requirements and identifying major transformations that will become programs in system design. So it is the starting point of the design to the lowest level of detail. A DFD consists of a series of bubbles joined by data flows in the system.
DFD SYMBOLS:
In the DFD, there are four symbols
1. A square defines a source(originator) or destination of system data
2. An arrow identifies data flow. It is the pipeline through which the information flows
3. A circle or a bubble represents a process that transforms incoming data flow into outgoing data flows.
4. An open rectangle is a data store, data at rest or a temporary repository of data Process that transforms data flow.
Source or Destination of data
CONSTRUCTING A DFD:
Several rules of thumb are used in drawing DFD’S:
1. Process should be named and numbered for an easy reference. Each name should be representative of the process.
2. The direction of flow is from top to bottom and from left to right. Data traditionally flow from source to the destination although they may flow back to the source. One way to indicate this is to draw long flow line back to a source. An alternative way is to repeat the source symbol as a destination. Since it is used more than once in the DFD it is marked with a short diagonal.
3. When a process is exploded into lower level details, they are numbered.
4. The names of data stores and destinations are written in capital letters. Process and dataflow names have the first letter of each work capitalized
A DFD typically shows the minimum contents of data store. Each data store should contain all the data elements that flow in and out.Questionnaires should contain all the data elements that flow in and out. Missing interfaces redundancies and like is then accounted for often through interviews.
SAILENT FEATURES OF DFD’S
1. The DFD shows flow of data, not of control loops and decision are controlled considerations do not appear on a DFD.
2. The DFD does not indicate the time factor involved in any process whether the dataflow take place daily, weekly, monthly or yearly.
3. The sequence of events is not brought out on the DFD.
TYPES OF DATA FLOW DIAGRAMS
1. Current Physical
2. Current Logical
3. New Logical
4. New Physical
CURRENT PHYSICAL:
In Current Physical DFD proecess label include the name of people or their positions or the names of computer systems that might provide some of the overall system-processing label includes an identification of the technology used to process the data. Similarly data flows and data stores are often labels with the names of the actual physical media on which data are stored such as file folders, computer files, business forms or computer tapes.
CURRENT LOGICAL:
The physical aspects at the system are removed as mush as possible so that the current system is reduced to its essence to the data and the processors that transform them regardless of actual physical form.
NEW LOGICAL:
This is exactly like a current logical model if the user were completely happy with he user were completely happy with the functionality of the current system but had problems with how it was implemented typically through the new logical model will differ from current logical model while having additional functions, absolute function removal and inefficient flows recognized.
NEW PHYSICAL:
The new physical represents only the physical implementation of the new system.
RULES GOVERNING THE DFD’S PROCESS
1) No process can have only outputs.
2) No process can have only inputs. If an object has only inputs than it must be a sink.
3) A process has a verb phrase label.
DATA STORE
1) Data cannot move directly from one data store to another data store, a process must move data.
2) Data cannot move directly from an outside source to a data store, a process, which receives, must move data from the source and place the data into data store
3) A data store has a noun phrase label.
SOURCE OR SINK
The origin and /or destination of data.
1) Data cannot move direly from a source to sink it must be moved by a process
2) A source and /or sink has a noun phrase land
DATA FLOW
1) A Data Flow has only one direction of flow between symbols. It may flow in both directions between a process and a data store to show a read before an update. The later is usually indicated however by two separate arrows since these happen at different type.
2) A join in DFD means that exactly the same data comes from any of two or more different processes data store or sink to a common location.
3) A data flow cannot go directly back to the same process it leads. There must be atleast one other process that handles the data flow produce some other data flow returns the original data into the beginning process.
4) A Data flow to a data store means update (delete or change).
5) A data Flow from a data store means retrieve or use.