Blood Bank Management System Argumentative

Blood Bank is an inventory where different groups of Blood of goods are available. Receiver can collect that they necessary from a Blood center. As a result they cannot to move different shops and they can save their necessary Time. The Staff of the Blood bank helps the collector to find out the necessary Blood components. The main objective of the study was to create electronic blood donor management information system in order to assist in the management of blood donor records, screening of blood, service charge, planning and share information in a more confidential, convenient and secure way using modern technology. This automated system ensures appropriate computerized mechanism with proper security to store data.

This information would be used in identifying/locating existing BDs (Blood Donor), carrying out pre-donation counseling and taking blood results. Unauthorized persons however, easily accessed the paper system and hence making it impossible to keep secrecy and confidentiality expected of medical records. The security of the medical records was also not inadequate as any person could easily access them. I want to develop such a system, which will satisfy some aspects such as reliability, maintainability, cost-effectiveness, security and user-friendliness. 1.2. Overview of the Present System:

To develop a “Blood Bank Automation System” I have to know about different steps of Blood Bank Management System and its rules and regulation. Those are stated below: The system contains Donor information, Patient information, Stock information, billing information etc. Whenever a patient or a collector are request for Blood, the employee searches in the system for the available group of blood that mach with the requirement of the patient or collector. The employee then supplies the Blood and produce bill. It also stores all the information about the collector and the donor in the system.

1.3. Proposed System:
The main stream/theme of my new proposed system is to automate the manual Blood Bank Management System. To develop such a system I have to follow all the steps of a software development life cycle model. This model will be discussed further point. To automate the manual Blood Bank Management System at first I have visit my problem domain place. Gathering requirements from the problem domain, I start my one by one step of my project management.

1.4. Motivation:
The system(BBMS) provides very less or no paper work and also provides help to blood bank manager and blood collector/patient to find and searching their desire blood components. Though everything is stored in this system electronically so information can be retrieved very easily without searching here and there into registers. 1.5. Methodology:

Methodology is needed for software in order to build it with consistency. At first I have to decide the basic theory and then realize its necessity. Analyzing about points, I are completely aware of my purpose, my required and proposed system of Blood Bank Management. To determine by how I will proceed successfully, I will introduce a methodology, which contains the steps for developing my software depending on proposed system. Methods are simply techniques that I apply to accomplish some objectives. Methods include guidelines, techniques and tools for building a software system. In order to develop an automated Blood Bank system, I need a methodology. A Software Development Life Cycle (SDLC) is an abstract description of the structured and methodological development and modification process applied to main stage of producing and developing software. It’s the appropriate framework at this point. Because: It is a complete cyclic process model

SDLC has system request on feasibility study and change request on maintenance SDLC has a straight point and linearity
A software development life cycle is an abstract description of the structured and methodological development and modification process applied to main stage of producing and developing software.

Fig: Software development life cycle

1.5 Structure of the project:
Effective management of a software project depends on thorough planning the progress of the project. The project developer must anticipate the problems that might arise and prepare tentative solutions to those problems. A plan, draw up at the start of the project, should be used as the driver for the project. This initial plan should be the best possible plan given the available information. It involves as the project progresses and better information becomes available. Our project is divided into several segments. They are:

Feasibility study
Requirement engineering
System specification and design
Implementation
Testing and
Maintenance.
Through this feasibility study,
Requirement engineering plays a vital role that is a sub discipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems. The system specification and design techniques are revolted according to requirement analysis, specification and validation. This part outcomes a detailed focus on software development. Most important part of the project is implementation it contains coding, testing, object models of the software. The last part contains application and maintenance of the system that implies effectiveness and reliability of the software.

Chapter 2: Background
Objectives:
The objective of this chapter is to introduce with the idea of feasibility study of a problem domain of a project. When one read this chapter he/she will: Understand the necessity of automation.

Be aware of drawbacks of the manual system.
Know the whole overview of the present and proposed Blood bank management System. Contents:
2.1 History of the situation
2.2 Detail description of the present System
2.3 Basic Principles involved
2.3.1. Overview of sub problems
2.3.2 Feasible solutions
2.3.3 Scopes & Assumptions
2.1 History of the Situation:
The situation is created due to several drawbacks of present system: In the existing system, record keeping is too much analogous. For example, if any record is needed about the current stock available, the rate of the particular Blood group searching and then the current authority cannot response in a quick way. Producing bill is also time consuming. The employees use pen and paper or calculator for producing bill, which takes more time. Sometimes theses manuals would be damaged due to different accidents. Updating records being too long, reference of data and preparation of reports has become quite hard and delayed beyond acceptable time limits.

2.2 Detail description of the present System:
To develop a “Blood Bank Automation System” I have to know about different steps of Blood bank management system and its rules and regulation. Those are stated below: My system contains Donor information, Stock information, patient’s information, billing information etc. Whenever a patient or patient’s relative request for Blood, the employee searches in the system for the available blood component that mach with the requirement of the customer. When a customer receives the Blood and the employee produce bill. It also stores all the information about the customer in the system. 2.3.1. Overview of sub problems

My problem domain is to develop Blood bank management software. During the feasibility study, I faced some issues that made an impact on my software development. These are: Security problem:

In a blood bank storage of blood is a sensitive part. But in the traditional system, total work is paper oriented; there is no such thing like password, user id. So, any one can access the paper, change it or destroy it. Data can be losing due to damage of paper and unscreened blood may be supplied or stored Interface problem:

The user of the “Blood Bank Automation System” demands to create such software that is user-friendly in order to operate the software without any difficulties and the software runs faster. Software related problem:

There must be such people who have maintainability of the software. The software has to meet the changing needs of the Blood Bank manager. Moreover, it should be updated and user friendly. 2.3.2. Feasible solutions:

Solution of the security problem:
To ensure security problem, I have to make passwords for authorized members of Blood bank database. And the developer would modify necessary password at any time to prevent hacking. Otherwise, the whole system will be destroyed. Analysis of the security problems:

Using password is a good solution of the problem. By using password only the authorized person can access the software. Solution of the interface problem:
For the problem I am offering the following solutions: Make a list of user’s requirements; design a structure model, which will clarify misunderstanding points, missing functions, missing requirements at each stage. Design prototype software for this purpose.

Analysis the solution of interface problems:
Considering cost, maintenance, delivery in a reasonable time it is wise to take the first solution as best. If the second solution is taken as feasible solution, then cost and time will be increased. Solutions of the software related problem:

To solve this problem, I must think about customer’s requirements and convenient process. It must be containing the facility of updating and deleting the necessary records and the changing needs of Blood Bank manager. Analysis the solution of software related problems:

The proposed solution is a good solution. Customer can get there require Product and other facility quickly. And the record is always updated. Through this feasibility study, I have determined with strong arguments that automation of Blood bank Management System is better than that of manual system. The feasible solutions of the present problems of the project are best and these will work efficiently to implement automated software. The solutions are considered as feasible depending on some software essential attributes- cost, maintainability, dependability, efficiency, and usability. The solutions are written in such a way that it may evolve to meet the changing needs of customers. Because, maintainability is a critical attribute i.e. software change is an inevitable consequence of a changing business environment.

Chapter3: Domain Based Approach
Objectives:
The objective of this chapter is to describe a number of generic requirements engineering processes for Blood Bank Management System. When you have read this chapter, you will: Understand the principal requirements engineering activities and their relationship; Have been introduced to several techniques of requirements analysis; Understand importance of requirements validation and how requirements validation and how reviews are used in this process; Contents:

Requirement Definition
Domain Based Approach
Requirement Analysis
Event Scenario of Blood bank Management System
Use cases
Requirements validation
Requirements validation in software process
Requirements validation techniques
Requirement Reviews
Requirements Prototyping

Requirement Definition
In the previous chapter I have discussed about the Problem Statement and Domain Scope of a Blood Bank. Now I would like to implement the approaches-Domain Based Approach in my problem domain: Blood bank Management System Domain Based Approach

Domain based approach mainly concentrates about domain and its potential users or stakeholders. It analyzes the problem domain and captures the domain user’s needs and wishes successfully and accurately. Problem Domain Characteristics

Now I will discuss the characteristics of my problem domain to analyze and specify system requirements successfully. If the system requirements do not capture accurately, the proposed system does not run successfully. The domain characteristics include-environmental characteristic, behavioral characteristics, and the system characteristics. Now I discuss about these part of the domain characteristics as follows: Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management: Collector Requirements

Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability. The collectors are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Functional Requirements

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the top-level functions for functional analysis. Performance Requirements

The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals. Derived Requirements
Requirements that are implied or transformed from higher-level requirement. Allocated Requirements
A requirement that is established by dividing or otherwise allocating a high-level requirement into Stakeholder List:
The stakeholders, the system components, who are the interested parties of the proposed system. Stake-holder
Status
Function(i.e.
Job tasks)
Objective(i.e.
Why?)
Associate with other Users
Problem
Administrator
Primary
-Members information registration

-To preserve previous record
-check donors issue permission
-collect payment
-Manager
-Missing previous record
-always maintaining the standard
Manager
Secondary
-Managing
Blood stock information and quality assurance
-Staff performance evaluation
-Monitor Financial Activities
-Maintaining information
-Check guest information if required
-Maintaining Blood Quality
-To maintain proper cash flow

-Staff
-Accounts
-Receptionist
-Guest

-Validating Donor Information
-Staff dissatisfaction
-Facing pressure from collectors when desired blood isn’t available Donor
Secondary
-Give proper information to the manger during registration

-To get the maximum benefit from the Blood bank
-Manager
-Not getting proper support from the blood bank management
Table-1: A sample recording schedule for information about automated Blood Bank Information System Environmental Factors and Constraints:
The table illustrates the environmental factors and constraints references, their description and impacts on organization to describe the constraints and non-functional requirements of the domain.

Reference
Description
Impacts…
Product law
All products have stock date and expired date.(i.e. Red blood cell has 42 days validity) The products cannot be stored in storage if their expired dates have been over. Product storage
Product have to be stored in separate rooms
The product cannot be contaminated due to mixing

Safety measures

Be careful from fire hazards and mischief.
The product cannot be damaged from calamities

Employee efficiencies
Employee should be skilled and competent
Blood seeker will be satisfied with service

Security
To keep the store secured from theft
Materials of the store will remain safe

Problem / Requirement List:
The Table-2 shows the problem name, problem symptoms, impact on organization, cause of the problems and problem priority.

Name
Symptoms(who or what are effected)
Impact on organization
Cause of Problems
Priority
Missing previous record

When one customer needs to come more then one time.

Redundant information so high maintenance cost

Register book is large or may have many volumes that are difficult and time-consuming matter.

1
Customer fail to payment bill

Request for concession
Loose profit

Administrator not solve the problem
2
Limitation of product
When needed product’s quantity is more than which are stored Bad reputation
Collector collected less quantity/ irregular collection
3
Quality of the product
Sometimes supply less quality product
Customers do not visit store second time
Blood seeker will reduce
3

Behavioral Characteristics: After describing the environmental characteristics, I will discuss the behavioral characteristics of the system. It includes object inventory, process inventory and event list. Object Inventory:

Object name
Description
Dependencies
/Associations
With other objects
Access, availability and Location
Possible states
Processed by
Product
What is offered in Blood Bank
Employee
Customer
Collector
All products have unique ID
Information of Products is stored in information table.
Enquiry
Ok
Not available
Product availability
Sell
Employee
Who are works at Blood bank
Administrator
manager

Donor & receiver information is stored in donor information table. All Donors have unique ID.
Valid
Invalid
Storing product

Validity check
Generate bill
Administrator
Owner of the Blood bank
Employee
Administrator information is stored in employee information table. All
Administrator have unique ID
Valid
Invalid
Validity check
Collector
Who collect blood component
Administrator
Employee
Collector information is stored in delivery information table. Inquiry
Buying product
Product availability
Buy

Table-3: Identified Objects Inventory of Blood Bank

Process:
The table shows the processes that change the states of the objects of Blood Bank Management System and their description, users, related objects and start/stop events. Firstly, this form contains the process name that comes from object Inventory table and this process is the part of the function of a department. Next it shows the process and associated users and objects that determine who starts the process and where. Process name

Part of function
Description
Users
Objects
Start/Stop Event
Product availability
Inquiry
When collector wants to collect a product, inquiry about product is available or not. Employee
Product
Start: request for Product.
End: not available.
Generate bill
Selling product
Fill-Up the all information about product and collector
Employee
Product
Start: entry
Product information.
End: Receiving bill
Sale
Selling product
Fill-Up the all information about product and collector.
Employee
Product
Start: entry
Product id.
End: Receiving bill
Validity check
Inquiry
When an employee wants to login, check the user is valid or not. salesman
product
Start: entry
Employee Id.
End: invalid user.

Table-4: Processes of that can change the states of objects for Blood Bank Automation

Event List:

Event name
Description
Event caused by
Associated functions/Processes
Login
The point of time at which an employee can be login to the system. Employee
wants to login to the system.
Login to system
Product in and out from system
Adding of new Donor, receive blood and delete of empty product Employee should modify to the system
To the system
Table-5: Event list that trigger the processes of Blood Bank Automation

Solution Characteristics:
Information generation requirements: The aim in considering the information generation requirements of a system is to attempt to define the overall purpose and goal of proposed system. The table shows the name of the outputted report, together with a description, the process with which it is associated and the user for whom the information is intended and the contents of the report. Report Name

Generated by process
For user
Contents
Bill
Generate bill
Collector
This report contains all information about product, which is bought, by a collector and total amount of bill, which has to pay. Donor
detail
Maintaining donor
List
Administrator
Employee

This report contains all information about Donor such as id, name, sex, age, Blood group etc. Product detail
Maintaining Product list
Administrator
salesman

This report contains all information about product such as category, name, id, price, receive-date, exp-date etc. System Function Outline: The table illustrates the sample system function outline. For each proposed system function outline the main objective of the function are listed, together with an outline of processing the developer can start to identify the particular transaction to be supported by the system. Function Reference

Objectives
Outline/Processing
Problem addressed
Users
supplying product
Preserving all information of product to provide service, which are provided Preserving of information requires for sale a product
Maintaining service.
Limitation of product.
Emplo-yee

Maintaining Donor
information
Preserving all information of donor

Preservation of information
Maintaining donor characteristics
Awareness of previous & present record
Administrator
Inquiry
Searching of specific information of product/ employee
to provide service.
Show the result of searching.
Employee inability

Emplo-yee

Chapter 4: System Specification
Objectives:

The objective of this chapter is to describe system specification, in more detail and the descriptions of the overall and detail design processes: Understand the main advantage and disadvantages architectural models Understand System specification attributes

Understand the design techniques of our system.

Contents:
4.1. Introduction
4.2. Entity Relationship Diagram (ERD)
4.3. Data Dictionary

4.1 Introduction:
Specification modeling assumes that a software system will deal with a situation; a specification model represents software elements used in the software solution to problem, and is mainly concerned with the definition, at a high level of abstraction, of the services provided by the software. It is final work product produced by the system and requirement engineer. It describes the function and performance of a computer based system and the constraints that will govern its development. Domain and specification modeling may produce very similar models, but the interpretations of the models are different; the former are about real-world entities, the latter are about software representations of those entities. Modeling the domain will not always be necessary – for instance, when there is an accepted need for a well-defined software system to solve a well-understood situation. In this case, modeling the domain would not bring much advantage. 4.2 Entity-Relationship Diagram (ERD)

An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database. It is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database and its requirements in a top-down fashion.

The ER diagram is principally used to capture the relationships that exist between static data objects in a problem domain or a design model. The basic elements involved in an ER diagram are defined as follows-

Entities are real-world objects with common properties. Entities can be Strong and Weak entity. Entities are abstract concepts, each representing one or more instances of the concept in question.

Here, Rectangles: represent entity sets.
Ellipses: represent attributes.
Diamonds: represent relationship sets.

A relationship is an association among several entities. Relationship lines indicate that each instance of an entity may have a relationship with instances of the connected entity, and vice versa.

Attributes are classes of values that represent atomic properties of either entities or relationships.

Fig 4.2: ER diagram for Blood Bank Management System

In the Blood Bank Management System the attributes with associated entities are listed below: 1. Donor info-> Name, Donor_ID, Age, Collector_name, Mobile_no, Address, Blood_Group. 2. Receive-> Name, Re_ID, Donor_Id , Reference, Date.

3. Stock-> Id, Blood_Group, Quantity, Reffered_by, Reference_Hospital, Patient_Name. 4. Delivery-> Name, ID, Status, Salary.
5. Descriptive Attributes: Received date, Delivery date, Quantity. Relationship types: Takes, Receives, Generate are relationship type

Chapter 5: Data Dictionary
5.1 Definition:
A data dictionary, or metadata repository, as defined in IBM Dictionary of computing, is a centralized repository of information about data such as meaning, relationship to another data,origin,usage,and format”. The term may have one of several closely related meanings pertaining to databases and database management systems(DBMS): A document describing database or collection of database

An Integral component of a DBMS that is required to determine it’s structure A piece of middleware that extends or supplants that native data dictionary of a DBMS 5.2 Data Table
5.2.1 General Information about Donor table

5.2.2 General information about Receive table:

5.2.3 General information about Stock table:

5.2.4 General information about Delivery table:

Chapter 6: Design
6.1.1. Introduction
Design is a meaningful engineering representation of software to be developed. It can be traced to a customer’s requirements and at the same time assessed for quality against a set of predefined criteria for ‘good’ design. In practice and especially when developing layers system, the process of design is to be divided into distinct phases as shown in figure: the phases are requirement specification, architectural design decisions, logical details, detailed design decisions, physical design decisions.

Figure: The major phases of the software design process The goal of software design is to specify how the system is going to be implemented. The programmer to implement the software uses the design. 6.1.2. A General Model of the Design Process

Design is the process of translating between the specifications of what the system must do in to a specification of how the system will accomplish it. It may involve developing several models of the system at different level of abstraction. This diagram suggests that the stages of the design process are sequential.

Here,
Architecture Design specifies the set of components that make up the program. Interface Design specifies the way in which the components interact. The Component Design specifies the responsibilities that are allowed to the components. Data Structure Design specifies the data structure used in the program are designed in detail and specified. Algorithm Design specifies the algorithm that allows the components to fulfill their responsibilities must be identified. Abstract Specification: For each sub system, an abstract specification of its services and the constraints under which it must operate is produced. 6.1.3. Architectural Design process

The design process for identifying the sub systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the software architecture. Common activities of architectural design process:

System Structuring.
Control Structuring
Modular Decomposition.
1. System Structuring:
The first phase of the architectural design activity is usually concerned with decomposing a system into a set of interfacing sub systems. Figure below is a structure model of the architecture for Blood Bank Automation System:

Figure: Architectural System Diagram of the Blood Bank Automation System.

Now I use specific model of the structure may be developed which show how sub systems share data, how they are distributed and how they interface with each other. There are three types of structural model. Here I choose Repository Model for my proposed system. Repository model characteristics:

1. Sub-systems must exchange data. This may be done in two ways: Shared data is held in a central database or repository and may be accessed by all sub-systems; Each sub-system maintains its own database and passes data explicitly to other sub-systems. 2. When large amounts of data are to be shared, the repository model of sharing is most commonly used. Advantages

Efficient way to share large amounts of data;
Sub-systems need not be concerned with how data is produced Centralised management e.g. backup, security, etc. Sharing model is published as the repository schema.
Disadvantages
Sub-systems must agree on a repository data model. Inevitably a Compromise;
Difficult to distribute efficiently.
2. Control Structuring:
The models for structuring a system are concerned with how a system is decomposed into sub-systems. To work as a Blood Bank Automation System, sub-systems must be controlled so that their services are delivered to the right place at the right time. Two general approaches to control can be identified:

i) Centralized Control: One sub-system has overall responsibility for control and starts and stops other sub systems. ii) Event-based Control: Each sub system can respond to externally generated events from other sub-systems or the system’s environment. For Blood Bank Automation System Event Driven is best. It is driven by externally generated events where the timing of the event is out with the control of the sub systems which process the event. Two principal event driven models are: 1) Broadcast models and 2) interrupt-driven models. I select broadcast model for the following reason:

1. Effective in integrating sub-systems on different computers in a network.
2. Sub-systems register an interest in specific events. When these occur, control is transferred to the sub- systems, which can handle the event. 3. Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them. 3. Modular Decomposition:

Here another structure level where sub-systems are decomposed into modules. Two modular decomposition models covered -An object model where the system is decomposed into interacting object. -A dataflow model where the system is decomposed into functional modules, which transform inputs to outputs. 6.1.4. Overall Design

Structure Analysis:
The aim of structured analysis is to transform the textural description of a problem into a graphical model. Structure Analysis methodology is based on Top-down decomposition approach. Here I will represent the SA methodology using Data Flow Diagrams. 6.1.4.1 Data Flow Diagram

Data flow diagram: Data flow diagram (DFD) is one of the major graphical structure analysis modeling tools that allows us to depict a system as a network of functional processes, connected to one another. DFDs can’t only be used modeling information processing system, but also as a way of modeling whole organization. The components of DFD are the Process, the Flow, the Store and the External Entity.. Process: The process portrays a part of system that transforms inputs into outputs. It represents how one or more inputs are changed into outputs. Here, I have represented the following symbol as process:

Fig-5.1: The Process symbol Flow: The flow illustrates the movements of packets of information from one part of the system to another part. Here I have shown the flow by the following symbol:

Fig-5.2: The Flow symbol
Store: To model a collection of data, the store is used. Data are carried by
flows into and out of the store. The symbol I have shown below as the store.

Fig-5.3: The Store symbol

External Entity: External entities are the generators and receivers of external events. The following symbol is portrayed for External Entity.

Fig-5.4: The External Entity Model

DFD Diagram: Level-0

Invalid
Donor Details

DFD Diagram: Level-1

Stock_Id Invalid Id Stock Update

Check

DFD Level-2:

Details

Invalid

Id, Blood
Group update

Summary:
At the end of this chapter any one can get the idea what is the relation between system design and requirement engineering and how it is affected design techniques. All sections of design techniques are described here

Chapter 7: Project Implementation
Objective:
The objective of this chapter is to discuss about implementation of software which applied during software development. When I study this chapter I will: 1. Select programming language for implementation

2. Apply object modeling due to my project.
3. Discuss about a number of testing technique.
4. Discuss about user interface.
Contents:
7.1 Implementation
7.1.1 Introduction
7.1.2 Select programming languages
7.2 Coding
7.3 User interface
7.4 Testing
7.1 Implementation:
7.1.1 Introduction
Implementation is the important part of the software development. This can be done by implement my concept that include in the analysis and design state. All of this established as a program or a set of programs. 7.1.2 Select programming languages

To develop the software I select APEX as programming module and Html, CSS as scripting language. for some several reason that are:
1. Platform independent
2. Effective and efficient
3. Robust
4. Easily handle exception.
I use Oracle11g (MySql) for the database.

7.2 Coding:
The task of coding consider following task they are:
1. Understand the problem that is trying to solve.
2. Understand basic design principles and concepts.
3. Select a programming language/Module that used to be built the software. 4. Select a programming environment that provides tools that will make my work easier. 5. Create a set of unit tests that will be applied once the component I code is completed. Coding principles: when writing code, be sure

1. Write code based on documentation.
2. Create nested loops in a way that makes them easily testable. 3. Use meaningful variable names and follow other local coding standards. 4. Keep conditional logic as simple as possible.
7.3. Necessity of analysing the user interface:
1. User interfaces should be designed to match the skills, experience and expectations of its anticipated users. 2. System users often judge a system by its interface rather than its functionality. 3. A poorly designed interface can cause a user to make catastrophic errors. Human factors in interface design

1 .Limited short-term memory
People can instantaneously remember about 10 items of information. If I present more than this, they are more liable to make mistakes. 2. People make mistakes
When people make mistakes and systems go wrong, inappropriate alarms and messages can increase stress and hence the likelihood of more mistakes 3. People are different
People have a wide range of physical capabilities. Designers should not just design for their own capabilities.

4. People have different interaction preferences
Some like pictures, some like text.
UI design principles:
UI design must take account of the needs, experience and capabilities of the system users. Designers should be aware of people’s physical and mental limitations (e.g. limited short-term memory) and should recognise that people make mistakes. UI design principles underlie interface designs although not all principles are applicable to all designs. User Interface Design principles

The following “User Interface Design principles” are considered during developing the software: 1. User familiarity
The interface should be based on user-oriented terms and concepts rather than computer concepts. For example, an office system should use concepts such as letters, documents, folders etc. rather than directories, file identifiers, etc .Like this my software use such terms in interfaces which are manual Blood Bank oriented. 2. Consistency

The system should display an appropriate level of consistency. Commands and menus should have the same format; command punctuation should be similar, etc. 3. Minimal surprise If a command operates in a known way, the user should be able to predict the operation of comparable commands. For my software I make forms such that which not makes users puzzled. Recoverability The system should provide some resilience to user errors and allow the user to recover from errors. This might include an undo facility, confirmation of destructive actions, ‘soft’ deletes, etc. 5. User guidance

Some user guidance such as help systems, on-line manuals, etc. should be supplied. In my project I provides help menu for use of the software. 6. User diversity
Interaction facilities for different types of user should be supported. For example, some users have seeing difficulties and so larger text should be available Different Interaction styles of User Interface:

1. Direct manipulation
2. Menu selection
3. Form fill-in
4. Command language
5. Natural language
The chart of interaction styles of Blood Bank Automation System

Interaction Styles
Apply to the software
Main advantages
Application examples
Direct manipulation
Yes
Fast and intuitive interaction.
Easy to learn.
Icons
Menu Selection
No
Avoids user error.
Little typing required
Menu bar
Form fill in
Easy to learn Checkable
Yes
Simple data entry
Entry forms
System Application:
Snapshots for Blood Bank Automation System:
This chapter gives an overview of the “SDH Blood Bank Management System” software through snapshots of user interfaces and form operations descriptions.

Snapshots Different Forms and their Operations:

Login Form:

This form is used to allow user to access the system by entering valid password. If user enter wrong password he/she can not access the software.

Main Form:

This Form is main interface of the software which detects user which purposes are possible through the software. This form contains buttons, Icons and Menu Bar. By Clicking respective button user can access required form.

Donor Information Form:

Stock Information Report:

Delivery Invoice

7.4.1 Testing:
Testing is the process, which is used to uncover errors from software that are made inadvertently as it was designed and constructed. 7.4.2 Classification of Testing:
There are two basic type of testing. These are:
1) Static testing
2) Dynamic testing
7.4.2.1 Static testing:
Static testing is related with inspecting the code. For this software, all the codes are reviewed several times. 7.4.2.2 Dynamic Testing:
There are two types of dynamic testing. These are:
a) White box testing
b) Black box testing
White box testing:
Software is tested from two different perspectives:
1. Internal program logic is exercised using “white box” test case design techniques.
2. Software requirement are exercised using “black box” testing design techniques. In both cases, the intent is to find be maximum number of errors with the minimum amount of effort and time. White box testing of software is predicated on close examination of procedural detail. Logical paths through the software are tested by providing test cases that exercise specific sets of condition and /or loops. The status of the program may be examined at various points to determine if the expected or asserted status corresponds
to the actual status. White Box Testing Techniques:

White box testing sometimes called glass box testing is a test case design method that uses the control structure of the procedural design to derive test cases. Using white box testing methods, software engineer can derive test case that: 1) Guarantee that all independent paths within a module have been exercised at least one. 2) Exercise all logical decisions on their true and false sides 3) Execute all loops at their boundaries and within their operational bounds, and 4) Exercise internal data structures to ensure their validity. My following method:

In my project I follow white box testing
I have knowledge of the source code; it becomes easy to find out which type of data can help in testing the application effectively It helps in optimizing the code Extra line of code can be removed which can bring in hidden defects Due to my knowledge about the code, maximum coverage is attained during test scenario writing

Test Log
a) This is a log that records the tests applied and the results of each test b) For a module this may look like a table

Conditions
Expected results
Actual results
Comment
Stock Id = 21
Blood group = B+
False
False
Pass
Stock Id = 23
Blood group =A B+
True
True
Pass
Stock Id = 21
Blood group = B+
False
True
Problem bad return

Chpter8: Documentation of the system
Blood bank is a palace where investigation take place about the reasons of the collected blood and deliver it to the patient or patients relative when they need according to the doctors supervision Now a days among the service rendered unit business of blood bank center is one of the leading prospects in Bangladesh .Hence to improve efficiency and to manage business in an easy manner to achieve further goal automation is must. That’s why software named “Blood Bank Management System” should be introduced. Details:

From1, It’s an introduction page. To click the logout button, we exit the software. If user name and password are correct then details form is opened. Otherwise an error message is will be displayed. The details form contains following option: 1) Home

2) Donor information
3) Receive information
4) Stock information
5) Delivery information
Using this option we can keep and retrieving information about donors, patient, blood stock, bill etc. Users Manual: As I’m a new developer and I’ve not yet develop any big project such like that, I can’t fulfill user manual completely. But I’m trying to develop this. And I will develop this perfectly in the next version of this software. System Requirements:

Any person who want to run “Blood Bank Management System ” in his/her computer then he/she must have the following minimum software and hardware
requirements. Hardware Requirements:

** Processor: 800 MHz
** RAM: 1 GB
** Hard Disk: 20 GB
Software Requirements: Oracle11g.
Chapter 9: Maintenance
Objectives:
The objectives of this chapter are to introduce software maintenance and ways of modifying software. When one read this chapter, he/she will: Understand the different strategies for changing software systems, namely maintenance. Understand the principles of software maintenance and why software is expensive to maintain. Contents:

9.1 Maintenance
9.2 Classification of Maintenance 9.2.1 Corrective Maintenance 9.2.2 Adaptive Maintenance 9.2.3 Perfective Maintenance 9.3 Iterative Development of Maintenance Summary

9.1 Maintenance
Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment. Today maintenance is the biggest single software engineering activity. Software needs maintenance, because it was delivered bugs, the environment in which the software operates may change, and the customers’ requirements may change. Above this reason, Software needs maintenance. Though software does not ware out, it needs maintenance for the following reasons: 1) It was delivered bugs. The bugs may be coding error, design error or analysis error. 2) The environment in which the software operates may change. For example: the operating system may change or hardware platform may change. 3) The customer requirement may change. For example: the software requires new features. Therefore, software needs maintenance.As software,“Automated Blood Bank Management System” also needs maintenance.

The ISO/IEC 14764 organization describes the 6 software maintenance processes as: 1. The implementation processes contains software preparation and transition activities, such as the conception and creation of the maintenance plan, the preparation for handling problems identified during development, and the follow-up on product configuration management. 2. The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it and check its validity, investigate it and propose a solution, document the request and the solution proposal. 3. The process considering the implementation of the modification itself. 4. The process acceptance of the modification, by checking it with the individual who submitted the request in order to make sure the modification provided a solution. 5. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software. 9.2 Classification of Maintenance:

1) Corrective Maintenance
2) Adaptive Maintenance
3) Perfective Maintenance
9.2.1Corrective Maintenance
When bugs appear in the software, these bugs need to be corrected. The process of removing bugs is corrective maintenance. This may be: [
1) Coding Errors
—- These are relatively cheap to fix.
2) Design Errors
—More expensive as several modules may need to be rewritten. 3) Analysis Errors
— The most expensive, the program may require significant redesign

9.2.2: Adaptive Maintenance
When the environment of the software changes, the software must adapt with its environment. The process of adapting with environment is adapting
maintenance. 9.2.3 Perfective maintenance:
When the customer requirements are changed, the software must fulfill its customer requirement. To fulfill customer requirement is perfective maintenance. For “Blood Bank Management System” we give attention towards these three kinds of maintenance. In this software we may need perfective maintenance because if the blood center takes vat from the patient then the software may need to be changed. 9.3 Iterative Development of Maintenance:

Ideally maintenance can be thought of as iteration through a standard software development.

Figure: Iterative Development of Maintenance

Chapter 10: Future work and Conclusion

Future Work
There is always a scope of betterment and the candidate system is not against this perception. This project is especially designed for Blood Bank Management to take appropriate step to improve working standard and documentation through computerization. Since my system is going to be implemented as the application of “Blood Bank Management System” on APEX as frontend and Oracle 11g (MySql) as backend tool, so it will help better for both user as well as developer .As per as my project cover all important details of Donor information, Stock, and Delivery; therefore there is some future improvement area exist also. The main scope of future may be:

Adding Screening module in my software which help to test the collected blood. Fully automated, need for human intervention
Reducing manual efforts for maintain the system
More user friendly and fixing unconscious bug.
Conclusion:
I have tried at best as possible to give them a best solution with my capability, industry and patience. In this solution, some limitations may have. But I have tried to overcome the limitations as per as possible. Quires are efficiently done and my project shows fast query. More over my software is user friendly. So I can claim that my software project shows better performance. In “Blood Bank Management System”, I tried to hard to include all the components which actually need in a “Blood Bank Management System”. This is my first project and I am inexperience so I may have mistake or have some problem in the software. I think and hope that I will develop more perfectly in the next version when I get the user feedback.