Lab Manual Software

Engineering

Dept. of Computer Science

Sir Syed University of Engineering & Technology,
Karachi, Pakistan
LAB INDEX

S.NO Description Remarks

1 Introduction to Software Engineering, Review of
Microsoft Visio and getting familiarized with the Unified
Modeling Language (UML) Environment.
2 To understand and implement Data Flow Diagram 1
3 To understand and implement Data Flow Diagram 2
4 To understand and implement the Class Diagram in UML

5 To understand Use Case Diagram

6 To understand Sequence Diagram
7 To understand Activity Diagram
8 Learning the concepts of Feasibility Study
9 Understanding the concepts of Software Documentations

10 To understand and implement Gantt chart

11 Gain understanding of Project Management
12 Learn how to prepare plans to understand SRS (Software
Requirement Specification) Document.
 Lab Session 01

OBJECT
Getting familiarized with the Unified Modelling Language (UML) Environment.

THEORY
Once the Requirements have been gathered, it is necessary to convert them into an appropriate design. In order to bridge
the requirements gathering and design phases, we use some modeling or specification tool, e.g. the Unified Modeling
Language. A commonly available CASE tool for design through UML is the Rational Rose. Given below is an overview
of the various Aspects in which development could be done using Rational Rose.

The Browser

The Browser contains a list of all the modeling elements in the current model. The Browser contains a tree view of all the
elements in the current Rose model. Elements in the tree structure are either compressed or expanded.
 Figure 4.1: The Browser Window

The Documentation Window

The Documentation Window may be used to create, review, and modify for any selected modeling element. If nothing is
selected, the window displays the string ―No selection‖. The contents of the Documentation Window will change as
different modeling elements are selected.

To create the documentation for a selected element, click to select the element and enter its documentation in the
Documentation Window.

The Documentation Window may be docked or floating just like the Browser. Visibility of the window is controlled via
the View:Documentation window command.
 Figure 4.2: The Documentation Window

Diagram Windows

Diagram windows allow you to create and modify graphical views of the current model. Each icon on a diagram
represents a modeling element. Since diagrams are used to illustrate multiple views of a model, each model element can
appear in none, one, or several of a model's diagrams.
Views in Rational Rose

There are many views of a software project under development. Rational Rose is organized around the views of a
software project:

1. The Use Case View

2. The Logical View
3. The Component View
4. The Deployment View.

Each view presents a different aspect of the visual model. Each view contains a Main diagram by default. Additional
elements and diagrams are added to each view throughout the analysis and design process.

1. The Use Case View

The use case view of the system addresses the understandability and usability of the system. This view looks at actors
and use cases along with their interactions.

Packages in the Use Case View

Packages in the use case view can contain actors, use cases, sequence diagrams, and/or collaboration diagrams. To create
a package:

1. Right-click on the parent modeling element (use case view or another package) to make the shortcut menu
visible.
2. Select the New:Package menu command. This will add a new package called NewPackage to the browser.
 3. While the new package is still selected, enter its name.

Once a package is created, modeling elements may be moved to the package. To move a modeling element to a package:

1. Click to select the modeling element to be relocated.

2. Drag the modeling element to the package.

2. The Logical View

The logical view of the system addresses the functional requirements of the system. This view looks at classes and their
static relationships. It also addresses the dynamic nature of the classes and their interactions. The diagrams in this view
are class diagrams and state transition diagrams.
2.1 Class Diagram

The browser provides a textual view of the classes in a system. Class diagrams are created to graphically view the classes
and packages in the system. Rose automatically creates a class diagram called Main in the Logical View. This diagram
may be opened by double-clicking on it in the browser. The Main class diagram typically contains packages thus, by the
end of development it is a graphical view of the major architectural elements of the system. A package may be added to a
class diagram by selecting it in the browser and dragging it onto the class diagram.
 
Figure 4.5: Logical View Class Diagram

2.2 State Transition Diagram

State transition diagrams show the life history of a given class, the events that cause a transition from a state and the
actions that result from a state change. They are created for classes whose objects exhibit significant dynamic behavior.

3. The Component View

The component view of the system addresses the software organization of the system. This view contains information
about the software, executable and library components for the system. This view contains component diagram.

Component Diagram
A component diagram shows the organizations and dependencies among components. Most models contain many
component diagrams. A component is represented as a rectangle with one small ellipse and two small rectangles
protruding from its side.

Rose automatically creates one component diagram called Main. To create an additional component diagram:
1. Right-click on the owning package (either the component view itself or a user created package) to make the
shortcut menu visible.
2. Select the New:Component Diagram menu command. This will place a new component diagram called
NewDiagram in the browser.
3. While the new diagram is still selected, enter its name.
Rose will automatically add the new diagram to the browser.

To open a component diagram:

1. Double-click on the diagram in the browser.

To create a component:
1. Click to select the package specification icon from the toolbar.
2. Click on the component diagram to place the component.
3. While the component is still selected, enter its name.
Rose will automatically add the new component to the browser.

To create a dependency relationship:

1. Click to select the dependency icon from the toolbar.
2. Click on the package or component representing the client.
3. Drag the dependency arrow to the package or component representing the supplier.

4. The Deployment View

The deployment view addresses the configuration of run-time processing nodes and the components, processes, and
objects that live on them. This view contains only one diagram – the deployment diagram.

Deployment Diagram
The deployment diagram contains nodes and connections. Rose provides two icons that can be used to draw a node – the
processor and the device. A processor is a node that has processing capacity.
 Figure 4.8: Deployment View

To open the deployment diagram:

1. Double-click on the Deployment View in the browser.

To create a node:
1. Click to select the processor icon from the toolbar.
2. Click on the deployment diagram to place the node.
3. While the node is still selected, enter its name.

To create a connection:
1. Click to select the connection icon from the toolbar.
2. Click on the node representing the client.
3. Drag the connection line to the node representing the supplier.

EXERCISES

1. Develop the Component Diagram following the specifications given below:

 Create a package called Registration
 Create the main component diagram for the Registration package
 Create three components on the Main component diagram for the Registration package – Registrar.exe,
Courses.dll and People.dll //Create dummy files for this purpose
 Create a dependency relationship between
o Registrar.exe and Courses.dll o Registrar.exe and
People.dll

Attach printout of the model.

2. Develop the Deployment Diagram following the specifications given below: Open the deployment
diagram.
 Add the following nodes (processors): Registration, Database, Main Building, Dorm, Library
 Add the connections as shown in the table below

Node Connected to Node

 Registration Database
Registration Main Building
Registration Dorm
Registration Library

Attach printout of the model here.

LAB # 02

Objectives

 Introduction to DFD.
 To familiar with DFD models.
 Data Flow Diagrams: discovering and design the cases.

DESCRIPTION:

Data analysis attempts to answer four specific questions:

What Processes make up a system?

What Data are used in each process?
What Data are stored?
What Data enter and leave the system?

Data drive business activities and can trigger events (e.g. new sales order data) or be processed to provide information about the
activity. Data flow analysis, as the name suggests, follows the flow of data through business processes and determines how
organisation objectives are accomplished. In the course of handling transactions and completing tasks, data are input, processed,
stored, retrieved, used, changed and output. Data flow analysis studies the use of data in each activity and documents the findings in
data flow diagrams, graphically showing the relation between processes and data.

Physical and Logical DFDs

There are two types of data flow diagrams, namely physical data flow diagrams and logical data Flow diagrams and it is important
to distinguish clearly between the two:

Physical Data Flow Diagrams

An implementation-dependent view of the current system, showing what tasks are carried out and how they are performed. Physical
characteristics can include:
 Names of people
 Form and document names or numbers
 Names of departments
 Master and transaction files
 Equipment and devices used

Logical Data Flow Diagrams

An implementation-independent view of the system, focusing on the flow of data between processes without regard for the specific
devices, storage locations or people in the system. The physical characteristics listed above for physical data flow diagrams will not
be specified.

A logical DFD focuses on the business and how the business operates. It describes the business events
that take place and the data required and produced by each event.
Data Flow Diagram (DFD)

The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the different processing activities
or functions that the system performs and the data interchange among these functions. Each function is considered as a processing
station (or process) that consumes some input data and produces some output data. The system is represented in terms of the input
data to the system, various processing carried out on these data, and the output data generated by the system. A DFD model uses a
very limited number of primitive symbols to represent the functions performed by a system and the data flow among these
functions.

Importance of DFDs in a good software design

The main reason why the DFD technique is so popular is probably because of the fact that DFD is a very simple formalism – it is
simple to understand and use. Starting with a set of high-level functions that a system performs, a DFD model hierarchically
represents various sub functions. In fact, any hierarchical model is simple to understand. Human mind is such that it can easily
understand any hierarchical model of a system – because in a hierarchical model, starting with a very simple and abstract model of a
system, different details of the system are slowly introduced through different hierarchies. The data flow diagramming technique
also follows a very simple set of intuitive concepts and rules. DFD is an elegant modeling technique that turns out to be useful not
only to represent the results of structured analysis of a software problem, but also for several other applications such as showing the
flow of documents or items in an organization.

Balancing a DFD

The data that flow into or out of a bubble must match the data flow at the next level of DFD. This is known as

balancing a DFD. The concept of balancing a DFD has been illustrated in fig. bellow. In the level 1 of the DFD, data items d1 and
d3 flow out of the bubble 0.1 and the data item d2 flows into the bubble 0.1. In the next level, bubble 0.1 is decomposed. The
decomposition is balanced, as d1 and d3 flow out of the level 2 diagram and d2 flows in.
Decomposition

Each bubble in the DFD represents a function performed by the system. The bubbles are decomposed into sub-functions at the
successive levels of the DFD. Decomposition of a bubble is also known as factoring or exploding a bubble. Each bubble at any level
of DFD is usually decomposed to anything between 3 to 7 bubbles. Too few bubbles at any level make that level superfluous. For
example, if a bubble is decomposed to just one bubble or two bubbles, then this decomposition becomes redundant. Also, too many
bubbles, i.e. more than 7 bubbles at any level of a DFD makes the DFD model hard to understand. Decomposition of a bubble
should be carried on until a level is reached at which the function of the bubble can be described using a simple algorithm.

Numbering of Bubbles

It is necessary to number the different bubbles occurring in the DFD. These numbers help in uniquely identifying any bubble in the
DFD by its bubble number. The bubble at the context level is usually assigned the number 0 to indicate that it is the 0 level DFD.
Bubbles at level 1 are numbered, 0.1, 0.2, 0.3, etc, etc. When a bubble numbered x is decomposed, its children bubble are numbered
x.1, x.2, x.3, etc. In this numbering scheme, by looking at the number of a bubble we can unambiguously determine its level, its
ancestors, and its successors.

Data dictionary
A data dictionary lists all data items appearing in the DFD model of a system. The data items listed include all data flows and the
contents of all data stores appearing on the DFDs in the DFD model of a system. A data dictionary lists the purpose of all data items
and the definition of all composite data items in terms of their component data items. For example, a data dictionary entry may
represent that the data grossPay consists of the components regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data items, the data dictionary lists their name and their type.
Composite data items can be defined in terms of primitive data items using the following
data definition operators:

+: denotes composition of two data items, e.g. a+b represents data a and b.

[,,]: represents selection, i.e. any one of the data items listed in the brackets can occur. For example, [a,b] represents either a
occurs or b occurs.

(): the contents inside the bracket represent optional data which may or may not appear. e.g. a+(b) represents either a occurs or
a+b occurs.

{}: represents iterative data definition, e.g. {name}5 represents five name data.
{name}* represents zero or more instances of name data.

=: represents equivalence, e.g. a=b+c means that a represents b and c.

/* */: Anything appearing within /* and */ is considered as a comment

Well-structured

Well-structured designs improves the maintainability of the system. A structured system is one that is developed from the top down
and modular, that is, broken down into manageable components. The modules should be designed so that they have minimal effect
on other modules in the system. The connections between modules are limited and the interaction of data is minimal. Such design
objectives are intended to improe system quality while easing maintenance task. So, Structure design transform the results of
structured analysis (i.e., a DFD representation) into a structure chart.

Purpose of Structure Chart

A Structure Chart is a design tool that visually displays the relationships between program modeles. It shows which modules with a
system interact and also graphically depicts the data that are communicated between various modules.
Structure charts are developed prior to the writing of program code. They are not intended to express procedural logic a task left to
flowcharts and pseudo code. Nor do they describe the actual physical interface between processing functions. Instead, they identify
the data passes existing between individual modules that interact with one another.

various modules making up the system

 module dependency (i.e. which module calls which other modules)
 parameters passed among different modules

Basic building blocks of structure chart

1. Rectangular box:
A rectangular box represents a module.
Annotated with the name of the module it represents

2. Arrows
An arrow between two modules implies: during execution control is passed from one module to the other in the direction of the
arrow.

Data flow arrows represent: data passing from one module to another in the direction of the arrow.
3. Diamonds
The diamond symbol represents: one module of several modules connected to the diamond symbol is invoked depending on some
condition

4. Repetition
A loop around control flow arrows denotes:
that the concerned modules are invoked repeatedly.

Guidelines for design

There is only one module at the top:

 the root module.
There is at most one control relationship between any two modules:
 if module A invokes module B, module B cannot invoke module A.
The main reason behind this restriction:
 consider modules in a structure chart to be arranged in layers or levels.

EXECERCISE

Creating Data Flow Diagram

1. Examine the following outline and then draw the diagram you think will model the situation. When a patient
arrives at ABC Surgery with a repeat prescription request, the receptionist checks the prescription file and
writes out a prescription. This has to be authorized by the doctor before being passed to the resident
chemist for dispensing. The chemist then gives the prescription to the patient. If the patient is entitled to
 free prescriptions, the chemist verifies this and fills in the appropriate details on a form, which is filed in the
free prescriptions file. Otherwise the chemist takes the appropriate amount of money from the patient and
gives them a receipt.

2. Suppose you are given the details of a small mail order catalogue system that allows people to shop from
home. When a customer receives the catalogue and wants to buy something, they can telephone, fax or
email their order to the company. The company gets the order and sends the goods and an invoice. When
the customer receives the goods with a delivery note, they send payment and receive a receipt for their
payment.

3. When FlashIT are interviewing and selecting new employees for their company, they ask applicants to
send their application forms and their CVs to personnel. The personnel department then checks these
forms for completeness and, if found to be complete, they are stored in the applications file. Otherwise
these forms are returned to applicants for resubmission. Any candidates not considered suitable for the
post are sent a refusal letter. Suitable candidates are requested to come in for interview. After interviews
have taken place, a decision on the most suitable candidate is taken and they are offered the post. The
interviewees who have been unsuccessful are sent a refusal letter.

4. XYZ High School has a library that lends books to staff and students. Students are allowed to borrow six
books and teachers are allowed to borrow ten. When someone borrows a book the library book file is
updated, as is the borrower file. Everyone issued with a book has it for a period of one month, after which
time they are sent a reminder. If, after six months, they haven't returned the book, they are sent a bill for
the cost of recovery of the book.

5. A system is required which allows a user to input an unordered list of integer numbers into a computer.
The system will store these numbers in the main store of the computer where they are to be sorted by the
system into ascending numeric order and re-stored. Finally the system is to print out the list for the user.

6. Draw the DFD for Education University. The enrolment process works as follows:

Students send in an application form containing their personal details and their desired course
TheUniversity checks that the course is available and that the student has necessary academic
qualifications. If the course is available the student is enrolled in the course, and the university confirms
the enrolment by sending a confirmation letter to the student. If the course is unavailable the student is
sent a rejection letter.

Lab Task Perform:

Examine the following outline and then draw the diagram you think will model the situation. When a patient arrives at
ABC Surgery with a repeat prescription request, the receptionist checks the prescription file and writes out a prescription.
This has to be authorized by the doctor before being passed to the resident chemist for dispensing. The chemist then
gives the prescription to the patient. If the patient is entitled to free prescriptions, the chemist verifies this and fills in the
appropriate details on a form, which is filed in the free prescriptions file. Otherwise the chemist takes the appropriate
amount of money from the patient and gives them a receipt.
Level1:
1. Suppose you are given the details of a small mail order catalogue system that allows people to shop from home.
When a customer receives the catalogue and wants to buy something, they can telephone, fax or email their order
to the company. The company gets the order and sends the goods and an invoice. When the customer receives the
goods with a delivery note, they send payment and receive a receipt for their payment.

Level0:

2.

Level1:
3. When Flash IT are interviewing and selecting new employees for their company, they ask applicants to send their
application forms and their CVs to personnel. The personnel department then checks these forms for
completeness and, if found to be complete, they are stored in the applications file. Otherwise these forms are
returned to applicants for resubmission. Any candidates not considered suitable for the post are sent a refusal
letter. Suitable candidates are requested to come in for interview. After interviews have taken place, a decision on
the most suitable candidate is taken and they are offered the post. The interviewees who have been unsuccessful
are sent a refusal letter.

Level0:

Level1:
4. XYZ High School has a library that lends books to staff and students. Students are allowed to borrow six books
and teachers are allowed to borrow ten. When someone borrows a book the library book file is updated, as is the
borrower file. Everyone issued with a book has it for a period of one month, after which time they are sent a
reminder. If, after six months, they haven't returned the book, they are sent a bill for the cost of recovery of the
book.

Level0:
Level1:

5. A system is required which allows a user to input an unordered list of integer numbers into a computer. The
system will store these numbers in the main store of the computer where they are to be sorted by the system into
ascending numeric order and re-stored. Finally the system is to print out the list for the user.

ssLevel0:

Level1:
6. Draw the DFD for Education University. The enrolment process works as follows:

Students send in an application form containing their personal details and their desired course The University
checks that the course is available and that the student has necessary academic qualifications. If the course is
available the student is enrolled in the course, and the university confirms the enrolment by sending a
confirmation letter to the student. If the course is unavailable the student is sent a rejection letter.

Level0:

Level1:
 LAB # 03 (Practice Lab)

DATA FLOW DIAGRAM FOR HOSPITAL MANAGEMENT SYSTEM

 LAB # 04

OBJECT
Working with the Class Diagrams of UML.
THEORY
Class Diagrams
The browser provides a textual view of the classes in a system. Class diagrams are created to graphically view the classes and
packages in the system. Rose automatically creates a class diagram called Main in the Logical View. This diagram may be opened
by double-clicking on it in the browser. The Main class diagram typically contains packages thus, by the end of development it is a
graphical view of the major architectural elements of the system. A package may be added to a class diagram by selecting it in the
browser and dragging it onto the class diagram.

Figure 6.1: The Class Diagram

Each package typically has its own main diagram which is a picture of its key packages and classes. To create the Main class
diagram for a package, double-click on the package on a class diagram. Once the Main diagram is created for a package, you can
add packages and classes to the diagram by selecting them in the browser and dragging them onto the diagram.
Classes from any package may be added to a class diagram by selecting the class on the browser and dragging it onto the open class
diagram. If the Show Visibility option is set to true either as a default using the Tool:Options menu or individually by using the
shortcut menu for the class, the name of the ―owning‖ package is displayed. The package name will be visible for all classes that
do not belong to the package owning the class diagram.
Packages and classes may also be created using the class diagram toolbar. To create a package or class using the toolbar:
1. Click to select the icon (package or class) on the class diagram toolbar.
2. Click on the class diagram to place the package or class.
3. While the new package or class is still selected, enter its name.
4. Multiple packages or classes may be created by depressing and holding the Shift key.
Packages and classes created on class diagrams are automatically added to the browser.
To create a class diagram:
1. Right-click to select the owning package and make the shortcut menu visible.
2. Select the New:Class Diagram menu command. This will add a class diagram called
 New Diagram to the browser.
3. While the new class diagram is still selected, enter its name.
4. To open the class diagram, double-click on it in the browser.

Class Structure
The structure of a class is represented by its set of attributes. Attributes may be created in the browser, via the Class Specification or
on a class diagram.
To create an attribute in the browser:
1. Right-click to select the class in the browser and make the shortcut menu visible.
2. To create an attribute, select the New:Attribute menu command. This will add
an attribute called name to the browser.
3. While the new attribute is still selected, enter its name.
4. Attribute data types and default values may not be entered via
the browser

To create an attribute using the Class Specification:

1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the Specification menu command.
3. Select the Attributes tab.
4. Right-click to make the shortcut menu visible.
5. Select the Insert menu command. This will insert an attribute called name.
6. While the new attribute is still selected, enter its name. Type and initial value
may be filled in at this time or you may choose to fill in this information later in
the development cycle.

To create an attribute on a class diagram:

1. Right-click to select the class on the class diagram and make the shortcut menu visible.
2. Select the Insert New Attribute menu command. This will insert an attribute
in the form name : type = initval
3. While the attribute is still selected, fill in its name. Type and initial value may be filled in at this time or you may choose
to fill in this information later in the development cycle.
Attributes of a class may be viewed in the browser. The class will be initially collapsed. To expand the class to view its
attributes, click the + next to the class.
Attributes should be documented. To add the documentation for an attribute:
1. Click to select the attribute in the browser.
2. Position the cursor in the Documentation Window. If the Documentation
Window is not visible, select the View:Documentation menu command.
3. Enter the documentation for the attribute.
To delete an attribute:
1. Right-click to select the attribute in the browser or on the Attributes tab of the
Class Specification and make the shortcut menu visible.
2. Select the Delete menu command.
Class Behavior
The behavior of a class is represented by its set of operations. Operations may be created in the browser, via the Class Specification
or on a class diagram. To create an operation in the browser:
1. Right-click to select the class in the browser and make the shortcut menu visible.
2. To create an operation, select the New:Operation menu command. This will add an operation called opname to the
browser.
3. While the new operation is still selected, enter its name.
4. The operation signature may not be entered via the browser

To create an operation using the Class Specification:

 1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the Specification menu command.
3. Select the Operations tab.
4. Right-click to make the shortcut menu visible.
5. Select the Insert menu command. This will insert an attribute called opname.
6. While the new operation is still selected, enter its name. The signature and return value may be filled in at this time or
you may choose to fill in this information later in the development cycle.
To create an operation on a class diagram:

1. Right-click to select the class on the class diagram and make the shortcut menu visible.
2. Select the Insert New Operation menu command. This will insert an attribute in the form
opname ( argname : argtype = default) : return

3. While the operation is still selected, fill in its name. be filled in at this time or you may choose to development cycle.
The signature and return value may fill in this information later in the
Operations of a class may be viewed in the browser. The class will be initially collapsed. To expand the class to view its operations,
click the + next to the class.
To enter the signature of an operation:
1. Right-click to select the operation in the browser and make the shortcut menu visible.
2. Select the Specification menu command.
3. Select the Detail tab.
4. Right-click in the Arguments field to make the shortcut menu visible.
5. Select the Insert menu command. This will insert an argument called argname of type argtype with a default value of
default.
6. Click to select the name, type, or default and enter the desired information.
7. Click the OK button to close the Specification.
To delete an operation:
1. Right-click to select the operation in the browser or on the Operations tab of the Class Specification and make the
shortcut menu visible.
2. Select the Delete menu command.
Operations should be documented.
To add the documentation for an operation:
1. Click to select the operation in the browser.
2. Position the cursor in the Documentation Window. If the Documentation Window is not visible, select the View:
Documentation menu command.3. Enter the documentation for the operation.
Relationships
Relationships provide a conduit for communication. There are four different types of relationships : association, aggregation,
dependency, and inheritance. Relationships may only be created on a class diagram using the toolbar.

Exercise 01:
Exercise 02:
 LAB # 05

Objectives

 Introduction to UML.
 Use case diagrams: discovering actors and use cases.

The Unified Modeling Language (UML)

Is a standard visual modeling language intended (intention) to be used for

 modeling business and similar processes,

 analysis, design, and implementation of software-based systems

UML is a common language for business analysts, software architects and developers used to describe, specify, design, and
document existing or new business processes, structure and behavior of artifacts (models) of software systems.

UML defines nine types of diagrams:

Class (package)
It is used to simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML
elements.

Object

The purpose of a diagram should be understood clearly to implement it practically. It means the object diagram is closer to the
actual system behavior

Use case,

Use case diagrams are typically(commonly) developed in the early stage of development and people often apply use case modeling for the
following purposes:

A use case is a unique functionality of a system which is accomplished by a user. A purpose of use case diagram is to capture core functionalities
of a system and visualize the interactions of various things called as actors with the use case. This is the general use of a use case diagram.

Sequence

A sequence diagram simply depicts(shown) interaction between objects in a sequential order i.e. the order in which these interactions take place

Collaboration,

A collaboration diagram, also known as a communication diagram, is an illustration of the relationships and interactions among software objects
in the Unified Modeling Language (UML). These diagrams can be used to portray(present) the dynamic behavior of a particular use case and
define the role of each object.

State chart,

State diagram describes the behavior of a single object in response to a series of events in a system.

Activity,

Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The activity can be described as an operation of
the system.

The basic purpose of activity diagrams is to capture the dynamic behavior of the system.. It is also called object-oriented flowchart.

Component,

When modeling large object-oriented systems, it is necessary to break down the system into manageable subsystems. UML component diagrams
are used for modeling large systems into smaller subsystems which can be easily managed.

Deployment.

Deployment diagrams are used to visualize the topology of the physical components of a system, where the software components are deployed.
Deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams consist of nodes and their
relationships.
Use case analysis  is a major technique used to find out the functional requirements of a software system. Use case, an important
concept in use case analysis, represents an objective user wants to achieve with a system. It can be in text form, or be visualized in a
use case diagram.

The beauty of use case is that it aims at describing a system from external usage view point, rather than from developer's
perspective. Therefore, writing use case can be the deciding factor for building a system that meets users' needs.

Basic Use Case Diagram Symbols and Notations

System

Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's boundaries.

Use Case

Draw use cases using ovals. Label with ovals with verbs that represent the system's functions.

Actors

Actors are the users of a system. When one system is the actor of another system, label the actor system with the actor
stereotype.
Relationships

Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled
either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An
"extends" relationship indicates alternative options under a certain use case.

A standard form of use case diagram is defined in the Unified Modeling Language.

Example-1

Bank ATM
An automated teller machine (ATM) or the automatic banking machine (ABM) is a banking subsystem (subject) that provides
bank customers with access to financial transactions in a public space without the need for a cashier, clerk or bank teller.
Customer (actor) uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw cash and/or transfer
funds (use cases).ATM Technician provides maintenance and repairs. All these use cases also involve Bank actor whether it is related
to customer transactions or to the ATM servicing.
An example of use case diagram for Bank ATM subsystem - top level use cases.
Example -2

Point of Sales Terminal

An example of UML use case diagram for Point of Sale (POS) Terminal or Checkout. A retail POS system typically includes a
computer, monitor, keyboard, barcode scanners, weight scale, receipt printer, credit card processing system, etc. and POS terminal
software.

Checkout use case is an example of a large and complex use case split into several use cases each describing some logical unit of
behavior. Note, that including use case becomes incomplete by itself and requires the included use cases to be complete.
Checkout use case includes Scan Item, Calculate Total and Tax, and Payment use cases.

Payment use case is represented using generalization relationship. It means that only one specific type of payment is accepted -
either by cash, or by credit, debit, or with check. An alternative to such representation could be to use  include relationship so that
not just single but several forms of payment could be accepted from the same client during checkout.

Q1 Airport check-in and security screening business model

Q2 Restaurant business model
Q3 Ticket vending machine
Q4 Bank ATM UML use case diagrams examples (not attempt)
Q5 Point of sales (POS) terminal (not attempt)
Q6 e-Library online public access catalog (OPAC)
Q7 Online shopping use case diagrams
Q8 Website administration
Q9 Hospital Management
Q10 Radiology diagnostic reporting UML use case diagram
 Exercise Solutions:

Q1 Airport check-in and security screening business model

Q2 Restaurant business model

Q3 Ticket vending machine

Q4 e-Library online public access catalog (OPAC)

Q5 Online shopping use case diagrams

Q6 Website administration
Q7 Hospital Management

Q8. Radiology diagnostic reporting UML use case diagram

 LAB # 06

Objective
To Understand Interaction diagram In UML.

Theory

Interaction diagrams describe how groups of objects collaborate in some behavior it typically captures the behavior of a
single use case. Interaction diagrams do not capture the complete behavior, only typical scenarios.
Analyzing a System’s Behavior
UML offers two diagrams to model the dynamics of the system: sequence and collaboration diagrams. These diagrams
show the interactions between objects.
Sequence Diagrams
A sequence diagram is a form of interaction diagram which shows objects as lifelines running down the page, with their
interactions over time represented as messages drawn as arrows from the source lifeline to the target lifeline. Sequence
diagrams are good at showing which objects communicate with which other objects; and what messages trigger those
communications. Sequence diagrams are not intended for showing complex procedural logic.

Sequence Diagram Components

Object
This box shape represents a class, or object, in UML. They demonstrate how an object will behave in the context of the
system.

Lifeline
A dashed vertical line that represents the passage of time as it extends downward. Along with time, they represent the
sequential events that occur to an object during the charted process. Lifelines may begin with a labeled rectangle shape or
an actor symbol

Activation boxes 
Symbolized by a rectangle shape, an activation box represents the time needed for an object to complete a task. The
longer the task will take, the longer the activation box becomes.

Messages 
Packet of information that are transmitted between objects. They may reflect the start and execution of an operation, or
the sending and reception of a signal.

 Synchronous messages
Represented by a solid line with a solid arrowhead. This symbol is used when a sender must wait for a response to a
message before it continuesmost method calls in object-oriented programming languages are synchronous. A closed and
filled arrowhead signifies that the message is sent synchronously

If you want to show that the receiver has finished processing the message and returns control to the sender, draw a
dashed arrow from receiver to sender. Optionally, a value that the receiver returns to the sender can be placed near the
return arrow.

 Instantaneous message
Messages are often considered to be instantaneous, i.e. the time it takes to arrive at the receiver is negligible. For
example, an in-process method calls. Such messages are drawn as a horizontal arrow.

Sometimes however, it takes a considerable amount of time to reach the receiver.

For example, a message across a network. Such a non-instantaneous message is drawn as a slanted arrow.
  Found message
A found message is a message of which the caller is not shown. Depending on the context, this could mean that either the
sender is not known, or that it is not important who the sender was. The arrow of a found message originates from a
filled circle.

 Asynchronous messages
With an asynchronous message, the sender does not wait for the receiver to finish processing the message, it continues
immediately. Messages sent to a receiver in another process or calls that start a new thread are examples of asynchronous
messages. An open arrowhead is used to indicate that a message is sent asynchronously.
  Message to self
A message that an object sends itself can be shown as follows
 Guard
A message can include a guard, which signifies that the message is only sent if a certain condition is met. The guard is
simply that condition between brackets.

Collaboration Diagrams
They are the same as sequence diagrams but without a time axis:
 Their message arrows are numbered to show the sequence of message sending.
 They are less complex and less descriptive than sequence diagrams.
  Example-1

 Sequence Diagram of Online Shopping System

Example-2

Sequence diagram of e-mail message

Example-3

 Creating a Sequence Diagram using Collaboration Diagram on Rational Rose

 Getting familiar with sequence diagram symbols and notations
 Steps for creating a Sequence Diagram on Rational Rose

Creating a Sequence Diagram using Collaboration Diagram

1. Make sure the Collaboration diagram is the active diagram. (If you've been doing the examples in order, it should
already be active)
 2. Hit the "F5" key (the single key labeled 'F5').

Rose generates the Sequence diagram based on the Collaboration diagram. The reverse can be done as well. A
Collaboration diagram can be generated from a Sequence diagram by hitting the 'F5' key.

The sequence diagram looks like this:

Getting familiar with sequence diagram symbols and notations

A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction diagram that shows how processes
operate with one another and in what order.
Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams.

Basic Sequence Diagram Symbols and Notations

Class roles

Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but
don't list object attributes.

Activation

Activation boxes represent the time an object needs to complete a task.

Messages
Messages are arrows that represent communication between objects. Use half-arrowed lines to represent asynchronous
messages. Asynchronous messages are sent from an object that will not wait for a response from the receiver before
continuing its tasks.
Various message types for Sequence and Collaboration diagrams

Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.

Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place the
condition for exiting the loop at the bottom left corner in square brackets [].
Destroying Objects
Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X.

Steps for creating a Sequence Diagram on Rational Rose

Exercise

Q1: Object: Model a Sequence Diagram for login operation.

 The new customer will enter his/her user id& password and then click on login button on the login.aspx
Webpage.
 The Session Manager gets the user id and user details from Customer class instance and verifies the user id and
password.
 If user details are invalid customer will not be allowed to login and an appropriate error message will be
displayed, otherwise the customer is logged in.

Q2: Draw Sequence diagram of ATM processing.

Q3: Draw Sequence diagram of Hospital system.
Sequence Diagram

Hospital System
ATM Processing
 LAB # 7

Objective
To Understand Activity diagram In UML.

Theory
An activity diagram is a simple and intuitive illustration of what happens in workflow, what activities can be done in parallel, and
whether there are alternative paths through the workflow.

Activity is a particular operation of the system. Activity diagrams are not only used for visualizing dynamic nature of a
system but they are also used to construct the executable system by using forward and reverse engineering techniques.
The only missing thing in activity diagram is the message part.

It does not show any message flow from one activity to another. Activity diagram is some time considered as the flow
chart. Although the diagrams looks like a flow chart but it is not. It shows different flow like parallel, branched,
concurrent and single.

Activity control nodes overview

Elements of activity diagram are:

Activities
an activity is the specification of a parameterized sequence of behavior. An activity is shown as a round-cornered rectangle
enclosing all the actions, control flows and other elements that make up the activity.

Actions
an action represents a single step within an activity. Actions are denoted by round-cornered rectangles.
Control Flow
a control flow shows the flow of control from one action to the next. Its notation is a line with an arrowhead.

Initial node
The filled in circle is the starting point of the diagram.

Final node

There are two types of final node: activity and flow final nodes.

The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes

The flow final node is depicted as a circle with a cross inside.

Objects and Object Flows

an object flow is a path along which objects or data can pass. An object is shown as a rectangle.
An object flow must have an object on at least one of its ends. A shorthand notation for the above diagram would be to use input
and output pins.

Decision and Merge Nodes

Decision nodes and merge nodes have the same notation: a diamond shape. They can both be named. The control flows coming
away from a decision node will have guard conditions which will allow control to flow if the guard condition is met. The following
diagram shows use of a decision node and a merge node.

Fork and Join Nodes

Forks and joins have the same notation: either a horizontal or vertical bar (the orientation is dependent on whether the control flow
is running left to right or top to bottom). They indicate the start and end of concurrent threads of control. The following diagram
shows an example of their use.

Interruptible Activity Region

An interruptible activity region surrounds a group of actions that can be interrupted. In the very simple example below, the "Process
Order" action will execute until completion, when it will pass control to the "Close Order" action, unless a "Cancel Request"
interrupt is received, which will pass control to the "Cancel Order" action.
Partition
An activity partition is shown as either a horizontal or vertical swimlane. In the following diagram, the partitions are used to
separate actions within an activity into those performed by the accounting department and those performed by the customer.

Example-1
Order processing activity diagram
Example-2
Activity diagram for use case WithdrawMoney

Task:
1. Hospital management system.
2. Bank system

Hospital Management System

1. LOGIN ACTIVITY DIAGRAM:

2. PATIENT REGISTRATION ACTIVITY DIAGRAM:

3. PATIEN WARD , OPERATION , ASSIGN SURGEON AND DISCHARGE ACTIVITY DIAGRAM:

4. PATIENT AMOUNT ACTIVITY DIAGRAM:
 Bank System

1. LOGIN ACTIVITY DIAGRAM:

2. BANK SYSTEM ACTIVITY DIAGRAM:

 LAB #08

OBJECT
Learning the concepts of Feasibility Study.

THEORY
The development of software begins with requirement gathering and their analysis. The Software Requirements are the
descriptions of the system services and constraints that aregenerated during the requirements engineering process. Before
the software requirements are gathered and analysed, it is necessary to do some research to study the impact of the
software, which is to be developed, over the client‘s business. This research is known as Feasibility study.

Software Requirements Engineering Process

It is the process of establishing the services that the customer requires from a system and the constraints under which it
operates and is developed.

The processes used for RE vary widely depending on the application domain, the people involved and the organization
developing the requirements. However, there are a number of generic activities common to all processes

 Feasibility Studies
 Requirements elicitation and analysis
 Requirements validation
 Requirements management

The Feasibility Study

The Feasibility Study is a combination of a market study and an economic analysis that provides an investor with
knowledge of both the environment where a project exists and the expected return on investment to be derived from it.

Feasibility Study may also be defined as:

 A preliminary study undertaken before the real work of a project starts to ascertain the likelihood of the projects
success.
 A small-scale investigation of a problem to ascertain whether a proposed research approach is likely to provide
useful data.
 An analysis of the practicability of a proposal.
 A study that usually recommends selection of a cost-effective alternative.
 A study that decides whether or not the proposed system is worthwhile.

Feasibility Study is a study undertaken:

 To assess in broad terms of technology, cost and time the feasibility of meeting a Staff Target.
 To identify alternative solutions, their relative advantages and disadvantages, and key problem areas for further
study.
  To provide detailed coasted proposals for project definition studies and information in the detail necessary to
draft a Staff Requirement.
 To check:
 If the system contributes to organizational objectives
 If the system can be engineered using current technology and within budget
 If the system can be integrated with other systems that are used

Feasibility Study Report

 The study addresses issues including the project's benefits, costs, effectiveness, alternatives considered, analysis
of alternative selection, environmental effects, public opinions, and other factors.
 A written report includes the study findings, recommendations, and (when the goal is feasible) a campaign plan,
timetable, and budget.

Feasibility Study Implementation

Feasibility Study is carried out through information assessment (i.e. what is required), information collection and report
writing. Certain areas may be targeted by asking the following questions:

 What if the system wasn‘t implemented?

 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?

Case Studies of Feasibility Studies

Consider the following Real-world case studies of Feasibility Studies carried out by various organizations:

Case 1: Bank Soft Feasibility Study - World Bank ATM Pilot Project

This document outlines a feasibility study done by Bank Soft for World Bank. World Bank has proposed a pilot project
where they would like to implement several ATM machines to measure the popularity of such machines. In the future,
they would use the data that they collect on these machines to implement more machines worldwide.

World Bank is renowned for its attention to security. Herein, three alternatives have been suggested for designing these
test machines. Each alternative is quite secure, but has its own advantages and disadvantages over the other. The
alternatives are as follows:
 An embedded system. This would require a lot of time and custom hardware, but would be extremely fast and
BankSoft would provide an excellent warranty for the software.
 Custom software on Microsoft Windows. This system would require minimal time and cost, but would not
require any special hardware. Interoperability with the bank's central computer would be maximized, and
warranty coverage would also be at peak.
 Custom software on a free Unix OS. This system would also not require special hardware, but making the
software interoperable with the bank's central computer would take additional time and effort. Such a system
would be extremely stable and inexpensive.
The recommendation has been made that the second alternative be designed, with custom software designed on top of the
Microsoft Windows platform. It is strongly believed that its advantages outweigh its disadvantages more than any other
alternative.

Case 2: The Mentoring Database System Feasibility Study

In this document, an overview of the Otonabee College Mentoring Program has been given and then a description of the
requirements for a software system to support the various administrative tasks associated with that program. Then an
analysis of the system currently in use is given to emphasize the need for a redesign and the development of a new
software system, the Mentoring Database System (MDBS). Finally, a description of the proposed solution, an analysis of
the project‘s feasibility, and a conclusion is presented.
EXERCISES

1. Mention the sequence of issues that are to be addressed in a Feasibility Study Report.
2. Mention the various Feasibility Areas discussed in the MDBS Feasibility Study.
3. Consider any Real-world Feasibility Study Report. Comment on the quality of the report by highlighting its
strengths and weaknesses.

EXERCISE NO#01

Firstly I design the project which is named as Gaming Zone Arena using the platform of C# windows Forms which
are combining to form a desktop application.
Platforms for Project:

1. .Net Framework (C#, Windows Forms).

2. Microsoft Sql Server 2018 (in which I create tables for records).

Problem Issues:

1. In first step I create login page and sign up page for this project in which multiple tables were created in backend
the problem arising in this step that is data failure because several data were repeated (Data Repetition) at the
time which are illegal in Database.
2. The second problem arising when the interconnections of joing two tables that is signs up and login page.
3. The 3rd and most important problem which is occurs most of the time that is connection established between
database and .net framework.
4. The 4rth problem occurs when the exception errors occur in code developer is too confused to resolve that
problem because the code is in bulk of amount.
5. Restrict to users to enter specific form which are hidden.
6. Calculations which are perform for billing sometime generating errors because of Boolean expressions.
7. Communication failure in between developer and Customer.
8. The interaction of UI Design which are not attract customer for product.
9. Requirements which are given by the Customer for product which are not completely done in project that’s a big
problem.
 EXERCISE NO#02

There are five areas of Feasibility Study which I involved in my project.

1. Technical Feasibility.
2. Economic or financial Feasibility.
3. Legal Feasibility.
4. Operational Feasibility.
5. Scheduling Feasibility.

Technical Feasibility:-
In my project technical feasibility is implemented .it helps Customer assess whether the technical term of capable
to converting the ideas into working system that is the timer include in my project in which the given time is up
the computer are shutdown. This type of technical term customer’s time was not wasted for watching every user.

Economic or Financial Feasibility:-

Economic feasibility of a project helps organizations assess the viability, cost, and benefits associated with
projects;before financial resources are allocated. It helps decision-makers determine the positive economic
benefits to the organization that the proposed system will provide, and helps quantify them too. This assessment
typically involves a cost/ benefits analysis of the project.
Legal Feasibility:-

This area investigates if the proposed system conflicts with legal requirements like data protection acts or social
media laws.

Operational Feasibility:-

In my project helps analyze and determine whether the business of gaming zone needs can be fulfilled using the
proposed solution or not. It helps to study if the business of gaming zone problem is worth solving.
Scheduling Feasibility:-

I have fulfilled the scheduling Feasibility because I deliver and complete all work on time and the customer were
happy for my work.
 EXERCISE NO#03

Arena Feasibility Study- World Arena Organization Gaming Zone Project

This document outlines a feasibility study done by Arena for World Arena Organization. WAO has proposed a gaming
zone where they would like to implement several gaming zones houses to measure the popularity of such gaming zones
houses. In the future, they are familiar to implement many more gaming zone houses because of popularity.
1. An embedded system, this would require a lot of time and custom hardware. But would be extremely fast and
WAO would provide an excellent warranty for the software.
2. Custom software on Microsoft Windows. This system will require minimal time and cost, but would not require
any type of special hardware.
 LAB #09
OBJECT
Understanding the concepts of Software Documentation.

THEORY

All large software development projects, irrespective of application, generate a large amount of associated
documentation. For moderately sized systems, the documentation will probably fill several filing cabinets; for large
systems, it may fill several rooms. A high proportion of software process costs is incurred in producing this
documentation. Furthermore, documentation errors and omissions can lead to errors by end-users and consequent system
failures with their associated costs and disruption. Therefore, managers and software engineers should pay as much
attention to documentation and its associated costs as to the development of the software itself.

The documents associated with a software project and the system being developed, have a number of associated
requirements:

1. They should act as a communication medium between members of the development team.
2. They should be a system information repository to be used by maintenance engineers.
3. They should provide information for management to help them plan, budget and schedule the software
development process.
4. Some of the documents should tell users how to use and administer the system.

Satisfying these requirements requires different types of document from informal working documents through to
professionally produced user manuals. Software engineers are usually responsible for producing most of this
documentation although professional technical writers may assist with the final polishing of externally released
information.

Process and Product Documentation

Generally, the documentation produced falls into two classes:

1. Process documentation: These documents record the process of development andmaintenance. Plans, schedules,
process quality documents and organizational and project standards are process documentation. The major
characteristic of process documentation is that most of it becomes outdated. Plans may be drawn up on a weekly,
fortnightly or monthly basis. Progress will normally be reported weekly. Memos record thoughts, ideas and
intentions, which change. Although of interest to software historians, much of this process information is of little real
use after it has gone out of date and there is not normally a need to preserve it after the system has been delivered.
However, there are some process documents that can be useful as the software evolves in response to new
requirements. For example, test schedules are of value during software evolution as they act as a basis for re-planning
the validation of system changes. Working papers which explain the reasons behind design

decisions (design rationale) are also potentially valuable as they discuss design options and choices made.
In short, Process documentation is produced so that the development of the system can be managed. Product
documentation is used after the system is operational but is also essential for management of the system development.
The creation of a document, such as a system specification, may represent an important milestone in the software
development process.

Document Quality

Component Description

Identification data Data such as a title and identifier that uniquely

identifies the document.
Table of contents Chapter/section names and page numbers.
List of illustrations Figure numbers and titles
Introduction Defines the purpose of the document and a brief
summary of the contents
Information for use of the documentation Suggestions for different readers on how to use
the documentation effectively.
Concept of operations An explanation of the conceptual background to
the use of the software.
Procedures Directions on how to use the software to
complete the tasks that it is designed to support.
Information on software commands A description of each of the commands
supported by the software.
Error messages and problem resolution A description of the errors that can be reported
and how to recover from these errors.
Glossary Definitions of specialized terms used.
Related information sources References or links to other documents that
provide additional information
Navigational features Features that allow readers to find their current
location and move around the document.
Index A list of key terms and the pages where these
terms are referenced.
Search capability In electronic documentation, a way of finding

specific terms in the document.

 Figure 2.2: Suggested components in a software user document

Documentation Standards

Documentation standards act as a basis for document quality assurance. Documents produced according to appropriate
standards have a consistent appearance, structure and quality. The standards that may be used in the documentation
process are:

1. Process standards These standards define the process, which should be followed forhigh-quality document
production.
2. Product standards These are standards, which govern the documents themselves.
3. Interchange standards It is increasingly important to exchange copies of documents viaelectronic mail and to
store documents in databases. Interchange standards ensure that all electronic copies of documents are
compatible.

Writing style

Writing documents well is neither easy nor is it a single stage process. Written work must be written, read, criticized and
then rewritten until a satisfactory document is produced. Technical writing is a craft rather than a science but some broad
guide-lines about how to write well are:
1. Use active rather than passive tenses
2. Use grammatically correct constructs and correct spelling
3. Do not use long sentences which present several different facts
4. Keep paragraphs short
5. Don‘t be verbose
6. Be precise and define the terms which you use
7. If a description is complex, repeat yourself
8. Make use of headings and sub-headings.
9. Itemize facts wherever possible
10. Do not refer to information by reference number alone

Documents should be inspected in the same way as programs. During a document inspection, the text is criticized,
omissions pointed out and suggestions made on how to improve the document. As well as personal criticism, grammar
checkers can also be used, which are incorporated in word processors.

On-line documentation

It is now normal to provide some on-line documentation with delivered software systems. This can range from simple
‗read me‘ files that provide very limited information about the software through interactive hypertext-based help systems
to a complete on-line suite of system documentation. Most commonly, however, hypertext-based help systems are
provided. These may be based on a specialized hypertext system or may be HTML-based and rely on web browsers for
access. The main advantage with on-line documentation is its accessibility.

Document Preparation

Document preparation is the process of creating a document and formatting it for publication. Figure 2.3 shows the
document preparation process as being split into 3 stages namely document creation, polishing and production. Modern
word processing systems are now integrated packages of software tools that support all parts of this process. However, it
is still the case that for the highest-quality documents, it is best to use separate tools for some preparation processes
rather than the built-in word processor functions. The three phases of preparation and associated support facilities are:

1. Document creation The initial input of the information in the document. This issupported by word processors
and text formatters, table and equation processors, drawing and art packages.
2. Document polishing This process involves improving the writing and presentation of thedocument to make it
more understandable and readable. This involves finding and removing spelling, punctuation and grammatical
errors, detecting clumsy phrases and removing redundancy in the text. Tools such as on-line dictionaries, spelling
checkers, grammar and style checkers and style checkers may support the process.

3. Document production This is the process of preparing the document for professionalprinting. It is supported by
desktop-publishing packages, artwork packages and type styling programs.

Figure 2.3: Stages of document preparation

EXERCISE

1. Write the Software Requirement Specifications (SRS) for the project assigned by the lab teacher (Refer to the SRS
template in the Appendix)

Abstract
ONLINE FOOD ORDER SYSTEM is a website designed primarily for use in the food delivery
industry. This system will allow hotels and restaurants to increase scope of business by reducing
the labor cost involved. The system also allows to quickly and easily managing an online menu
which customers can browse and use to place orders with just few clicks. Restaurant employees
then use these orders through an easy to navigate graphical interface for efficient processing.

Introduction
It is known globally that, in today’s market, it is extremely difficult to start a new small-scale
business and live-through the competition from the well-established and settled owners. In fast
paced time of today, when everyone is squeezed for time, the majority of people are finicky when it
comes to placing a food order. The customers of today are not only attracted because placing an
order online is very convenient but also because they have visibility into the items offered, price
and extremely simplified navigation for theorder.

Online ordering system that I am proposing here, greatly simplifies the ordering process for both
the customer and the restaurant. System presents an interactive and up-to-date menu with all
available options in an easy to use manner. Customer can choose one or more items to place an
order which will land in the Cart. Customer can view all the order details in the cart before
checking out. At the end, customer gets order confirmation details. Once the order is placed it is
entered in the database and retrieved in pretty much real time. This allows Restaurant Employees to
quickly go through the orders as they are received and process all orders efficiently and effectively
with minimal delays andconfusion.

Motivation
The motivation for designing this application came because my family is involved in the fast food
business and I personally do not like waiting for long in the store or to have to call store to place an
order especially during the peak lunch or dinner hours. Moreover, I value recent learning about the
Java and JSP Programming languages as well as seeing how powerful and dynamic they are when
it comes to web designing and applications. The languages used to build this application are
JavaScript, JSP, HTML and Java at client facing whereas Oracle database at the back-end because
I found them to be extremely useful while working on the technologies.
Aim of the Software
This software is developed to help computer science students to learn about the Web application
designing using JSP and HTML from their basic capabilities to build a complete working
application fromscratch. Further, it gives insight about how GUI interacts with server-side
language, Java, and finally with the Oracle database.

Background and Related Work

This Case study looks at the problem of setting up a fast food restaurant. In existing system there
are few problems:
1. For placing any orders customers have to visit hotels or restaurants to know about food
items and then place order and pay. In this method time and manual work isrequired.
2. While placing an order over the phone, customer lacks the physical copy of the menu item,
lack of visual confirmation that the order was placedcorrectly.
3. Every restaurant needs certain employees to take the order over phone or in-person, to offer
a rich dining experience and process the payment. In today’s market, labor rates are
increasing day by day making it difficult to find employees whenneeded.

Hence, to solve this issue, what I propose is an “Online Food Order System, originally designed for
small scale business like College Cafeterias, Fast Food restaurant or Take-Out, but this system is
just as applicable in any food delivery industry.
The main advantage of my system is that it greatly simplifies the ordering process for both the
customer and the restaurant and also greatly lightens the load on the restaurant’s end, as the entire
process of taking orders is automated.

Anticipated Benefits are:

1. This will minimize the number of employees at the back of thecounter.
2. The system will help to reduce labor costinvolved.
3. The system will be less probable to make mistake, since it’s amachine.
4. This will avoid long queues at the counter due to the speed of execution and number of
optimum screens to accommodate the maximumthroughput.
Program Requirements
Outline your solution. Describe the "what’s" of your project -- what does it do?

Product Perspective:
The Online Food Order System application is a web-based system. It can be accessed using IE
10.0 and above, Fire Fox 31 and above and Google Chrome.

System Model:

The structure of the system can be divided into 3 main logical components:
1. Web Ordering System- provides the functionality for customers to place their order and supply necessarydetails.
2. Menu Management-allows the restaurant to control what can be ordered by thecustomers
3. Order Retrieval System-This is a final logical component. Allows restaurant to keep track of all orders placed.
This component takes care of order retrieving and displaying orderinformation.

Product Function:
The Online Food Order System application would have the following basic functions:
Web Ordering System Module
This module provides the functionality for customers to place their order and supply necessary
details. Users of the system, namely restaurant customers, must be provided the following
functionality:
1. Create anaccount.
2. Manage theiraccount.
3. Log in to thesystem.
4. Navigate the restaurant’smenu.
 5. Select an item from themenu.
6. Add an item to their currentorder.
7. Review their currentorder.
8. Remove an item/remove all items from their currentorder.
9. Provide paymentdetails.
10. Place anorder.
11. Receive confirmation in the form of an ordernumber.
12. View orderplaced.

Additional Feature:
1. eClub- Allows user to subscribe to eClub to get promotional deals and discountsoffers.

Out of all the functions outlined above, Account Creation and Management only will be used
every time a customer places an order. This will allow to simplify the overall user experience.

Menu Management System Module

This module provides functionality for the power user-Administrator only. It will not be available
to any other users of the system like Restaurant Employees or Customers.
Using a graphical interface, it will allow an Admin to manage the menu that is displayed to users
of the web ordering system:
1. Add/update/delete food category to/from themenu.
2. Add /update/delete food item to/from themenu.
3. Update price for a given fooditem.
4. Update additional information (description, photo, etc.) for a given fooditem.

Before customers can actually use this system, functionality provided by this component will
have to be configured first. Once the initial configuration is done, this will be the least likely used
component as menu updates are mostly seasonal and do not occur frequently.

Order Retrieval System Module

This is the most simplest module out of all 3 modules. It is designed to be used only by restaurant
employees, and provides the following functions:
1. Retrieve new orders from thedatabase.
 2. Display the orders in an easily readable, graphicalway.

Implementation
Hardware/Software Interface:
This section lists the minimum hardware and software requirements needed to run the system efficiently.

Hardware Interface:
1. PentiumProcessor
2. 60 MB of free hard-drivespace
3. 128 MB ofRAM

Software Interface:
1. Operating System: Windows (Vista/7 orabove)
2. Web Browser: IE 10 or above, Mozilla FF 31 and above or GoogleChrome
3. Drivers: Java RuntimeEnvironment
4. Integrated Development Environment: Eclipse J2EE or ApacheTomcat

Functional Requirement Specifications:

Activity Diagram:
This section lists the activity diagram and describes the flow of the activities in the system. A
detailed description is then given after the figure for each activity. Figure # 3 provides the
overview of the activity of the Online Food Order System application.
All users of the system are provided with below menu options:
Home, Menu, My Cart, User Account, eClub, About Us and Contact

Web Ordering System Module

Customers of the Web Ordering system will interact with the application through an easy to
use top navigation menu.
1. “Home” menu option: allows the users to see all food items offered with nice images as well as select an item to
place anorder.

2. “Menu”menu option: a ‘Drop-Down’ menu, allows users to see all food items per category. Item can then be added
to the cart using a single buttonclick.
3. “My Cart (x)”menuoption:
 Allows users to see details of the items placed in cart. Details include Item #, Product Name, Product Image, Product
Description, Quantity, Unit Price, Total per item and final Total of the order. It also allows ‘Update’ and ‘Delete’ an
item using single button click. User can then use a ‘Proceed to checkout’ button to proceedfurther.
 Once, Check Out button is selected, user will be prompted for the Sign In/Sign Up process if not logged in else user
will be presented with a simple “Payment Information” form. User will be asked to provide all required details in
displayed text boxes and make appropriate Drop- down selections. Then, all this information can be saved using a
‘Save’button.
 User will then be presented with a “Review Order” page, which will display Payment Information along with
Order details to review. User can then use a ‘Check Out’ button to place anorder.
 Once order is placed, user will be presented with appropriate Order confirmation
success/failuremessage.
4. “My Account”: a “Drop Down” menu will display the user orders, Sign In and Sign Outoptions.
5. EClub- Allows user to subscribe to eClub to get promotional deals and discountsoffers.

Menu Management System Module

Similar to Web ordering system, this module presents Admin with below additional options under
“My Account” Drop down menu:
 Add Category: Allows to add a food Category name in a simpleform.
 Add Product: Allows to add Product Name, Description, Price and choose Category in a simple form along with
ProductImage.
 Modify Product: Allows updating or deleting productdetails.
Order Retrieval System Module
The application will automatically fetch new orders from the database at regular intervals and
display the order numbers.
 Under “My Account’ menu a customer will be able to see only his/her order whereas a Restaurant Employee or an
Admin can see all usersorders.
 To view the details of an order, the user must click on that order number, which will display all order details this
structure can intuitively be expanded and collapsed to display only the desired information.

Non-functional Requirements
All of the application data is stored in a Oracle database, and therefore a Oracle Database must
also be installed on the host computer. As with Apache2, this software is freely available and can
be installed and run under most operating systems.
The server hardware can be any computer capable of running both the web and database servers
and handling the expected traffic. For a small scale restaurant that is not expecting to see much
web traffic, an average personal computer may be appropriate. Once the site starts generating more
hits, though, it will likely be necessary to upgrade to a dedicated host to ensure proper
performance. The exact cutoffs will need to be determined through a more thorough stress testing
of the system.

Constraints
 Hardware Limitations: The minimum hardware requirement for the system is 128 MB of Ram and a 60MB hard-
discdrive.
 Others: The application should be built using Java and JavaScript inscribed in HTML, and it should, initially, be
accessible through the eclipse IDE and later published on a server

System Evolution
The heart of the entire ordering system is the Database. Currently the system is only available for
small scale restaurants. For Large restaurants, performance considerations should be taken into
account in terms of Hardware/Software capacity/Page load time etc. Also, security vulnerabilities
should be evaluated for large scale systems.
In future this can also be available as a Mobile application and can be integrated with in store
Touch Screen Order devices.
I am also certain that if this system goes into actual use, many requests will arise for additional
features which I had not previously considered, but would be useful to have. For this reason, I feel
as though the application can be constantly evolving, which I consider a very good thing.

Conclusions and Future Work

Conclusion:
The main objective of the application is to help Computer Science students understands the basics
of Java, JavaScript and HTML. The following results have been achieved after completing the
system and relate back to the system’s objective.
Should allow Computer Science students to browse through the code andapplication:
\This can be achieved when students are able to run and install the application. When they run the
application, they can browse through the implementation of different objects.

Should allow users to browse through different product categories:

This is achieved through an easy to use graphical interface menuoptions.

Should allow users to save items to the cart and view detailed information
about the order:
The users can add any number of items to the cart from any of the available food categories by simply clicking the Add to
Cart button for each item. Once item is added to the cart, user is presented with detailed order to review or
continueshopping.

Should allow the user to checkout the item(s):

This is achieved using the “Proceed to checkout button” in the cart initially and then “CheckOut” button at last step after
“review Order” step.. Button is disabled when there are no items in thecart.

Should allow the user to process the payment:

This is achieved when user selects “Processed to Checkout” button and fill up the Payment informationdetails.

Should allow the user to see Success message after placing an order:
This is achieved when user successfully places an order. The user is given the order conformation number along with
success message.
Future Work:
The following section describes the work that will be implemented with future releases of the software.
1. Customize orders: Allow customers to customize foodorders
2. Enhance User Interface by adding more user interactive features. Provide Deals and promotional Offer details to
home page. Provide Recipes of the Week/Day to HomePage
3. Payment Options: Add different payment options such as PayPal, Cash, Gift Cards etc. Allow to save payment
details for futureuse.
4. Allow to process an order as aGuest
5. Delivery Options: Add deliveryoption
6. Order Process Estimate: Provide customer a visual graphical order statusbar
7. Order Status: Show only Active orders to RestaurantEmployees.
8. Order Ready notification: Send an Order Ready notification to thecustomer
9. Restaurant Locator: Allow to find and choose a nearbyrestaurant
10. Integrate with In store touch screen devices likeiPod

Appendices
This section includes figures for ER Diagram and various Web application images.

ER Diagram:
 LAB #10

Creating Gantt Chart & PERT Chart Using MS Project

Objective:
 Introduction about Microsoft Project and discuss some features.
 Introduction about Gantt Chart and Network Diagram.
 Create Gantt chart and Network Diagram with the help of example

Introduction about Microsoft Project:

Microsoft Project is a project management software program, developed and sold by Microsoft, which is designed to assist a
project manager in developing a plan, assigning resources to tasks, tracking progress, managing the budget, and analyzing
workloads. Microsoft Project can be used in a variety of industries including construction, manufacturing,
pharmaceuticals, government, retail, financial services and health care.

Microsoft Project is a software application sold by Microsoft that provides project management tools to manage projects.
The program, which has many different versions, allows users to:

 Understand and control project schedules and finances.

 Communicate and present project information.
 Organize work and people to make sure that projects are completed on schedule.

Features:
Project creates budgets based on assignment work and resource rates. As resources are assigned to tasks and assignment
work estimated, the program calculates the cost, equal to the work times the rate, which rolls up to the task level and then
to any summary tasks and finally to the project level. Resource definitions (people, equipment and materials) can be
shared between projects using a shared resource pool. Each resource can have its own calendar, which defines what days
and shifts a resource is available. Resource rates are used to calculate resource assignment costs which are rolled up and
summarized at the resource level. Each resource can be assigned to multiple tasks in multiple plans and each task can be
assigned multiple resources, and the application schedules task work based on the resource availability as defined in the
resource calendars. All resources can be defined in label without limit. Therefore, it cannot determine how many finished
products can be produced with a given amount of raw materials. This makes Microsoft Project unsuitable for solving
problems of available materials constrained production. Additional software is necessary to manage a complex facility
that produces physical goods.

The application creates critical path schedules, and critical chain and event chain methodology third-party add-ons also
are available. Schedules can be resource leveled, and chains arevisualized in a Gantt chart. Additionally, Microsoft
Project can recognize different classes of users. These different classes of users can have differing access levels to
projects, views, and other data. Custom objects such as calendars, views, tables, filters, and fields are stored in an
enterprise global which is shared by all users.
Introduction about Gantt chart:

A Gantt chart, commonly used in project management, is one of the most popular and useful ways of showing activities
(tasks or events) displayed against time. On the left of the chart is a list of the activities and along the top is a suitable
time scale. Each activity is represented by a bar; the position and length of the bar reflects the start date, duration and end
date of the activity.

A Gantt chart is a type of bar chart, developed by Henry Gantt in the 1910s, that illustrates a project schedule. Gantt charts illustrate
the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements
comprise the work breakdown structure of the project. Modern Gantt charts also show the dependency (i.e., precedence network)
relationships between activities.

This allows you to see at a glance:

 What the various activities are

 When each activity begins and ends
 How long each activity is scheduled to last
 Where activities overlap with other activities, and by how much
 The start and end date of the whole project

To summarize, a Gantt chart shows you what has to be done (the activities) and when (the schedule).

Sample of Gantt chart

Introduction about Network Diagram

The Network Diagram view was called the PERT Chart in earlier versions of Project. This view shows the dependencies
between tasks in a graphical manner. Gantt chart is primarily meant to view the schedule time line, whereas Network
diagram to view the all type of dependencies in the project.

Each task shown in the box called node and a line connecting two boxes represents the dependency between those tasks.

You can also create new tasks in the Network Diagram. It’s always easy to manage the tasks from Gantt chart view, but
if you are concerns on view the dependencies instantly while you creating the tasks, Network Diagram will be the right
one.

Network Diagram also can display a record of progress:

  If the task is completed, the task node shows cross diagonal lines
 If the task is in progress but not completed, a single diagonal line draw through node
 No diagonal line appears in tasks that are not yet started

Sample of Network Diagram

Create Gantt chart and Network Diagram

Gantt Chart:
1. Adding tasks and milestones to a Project File:
 On the View menu, click Gantt Chart.
 In the Task Name field, type a task name, and then press TAB. (Microsoft Project enters an estimated duration of
one day for the task followed by a question mark)
 In the Duration field, type the amount of time each task will take in months, weeks, days, hours, or minutes, not
counting nonworking time. (By default the time period will be days, but that can be changed to hours, months,
etc.)
 Press ENTER. It should look like the figure below:

 To add a milestone the only difference is that the duration of the activity must be zero (below is an example):
Note: By double clicking on a Task or milestone, you can modify its information with a form that prompts

2. Grouping Tasks in Logical Order:

Outlining helps organize your tasks into more manageable chunks. You can indent related tasks under a more general
task, creating a hierarchy. The general tasks are called summary tasks; the indented tasks below the summary task are
subtasks. A summary task's start and finish dates are determined by the start and finish dates of its earliest and latest
subtasks.

 Click once on the first activity of the group of activities you want to group. For the example Activities 4 and 5


 Then click on the option “New Task” in the “Insert” Menu to insert a new task that will represent the name of the
group (“Group 1” for this example)

 Then select the tasks below (4 and 5) and then click in the option “Indent” in the “Project

3. Creating Relationships Between Tasks:

A network of tasks in a project must be connecting activities from the start to the end, to establish these relationships we
need to use the field “Predecessors” of each task, where we can designate which activity will be preceding the one we are
updating, in the example below we will indicate MS project that “Activity 5” can start once “Activity 4” is completed
(Finish to Start relationship).
Notice that by establishing the relationship now the Group 1 takes 2 days to be completed, because before, the activities
were set to be performed in parallel, and now they are in series (Finish to Start relationship)

Note: MS project will calculate dates based on the durations of the tasks, their relationships and the start date set for the
project, however it is possible to change the starting date of a task (if necessary) By double clicking on a Task or
milestone, and using the fields related to the dates (Start or Finish)

4. Assigning Resources to Tasks:

You can use the Resource Sheet in Microsoft Project to create a list of the people, equipment, and material resources that
make up your team and carry out the project tasks. Your resource list will consist of work resources or material
resources. Work resources are people or equipment; material resources are consumable materials or supplies, such as
concrete, wood, or nails.
 On the View menu, click Resource Sheet.
 On the View menu, point to Table, and then click Entry.
 In the Resource Name field, type a resource name.

 You can go through the fields in the sheet, but for the simplicity of the example just focus on the name and
initials of the Resource
 Below is an example of some Human resources added to the Resource Sheet (We could add also other type of
resources such as Equipments, Consumables, etc.)

 Once the resources are created, you can go back to the View menu, and click Gantt Chart to see again the tasks,
and then when you double click a task you can add a resource to this task by using the tab “Resources”

Network Diagram:

 Click Gantt chart view and go to the sub options in Gantt Chart
  Click Network diagram

Now let’s try a small example, step by step to practice each of the options we have seen so far about how to create a
project using MS Project. We are going to use a small set of tasks (Table Below) related to the initial phases of a System
Testing Plan (Definition and Design)

Activity Predecessor Responsibility Effort System Testing

Phase
1.RSD Analysis Requirements  Test Manager 3 days Definition Phase
Specification Document  Project
completed. Manager
(Not part of System  Test Leader
Testing Plan
2. Develop Test Plan Activity 1 •Test Manager 5 days Design Phase
•Test Leader
•Tester E
3. Develop Test Design Activity 2 •Tester A and B 8 days Design Phase
Specification
4. Develop Test Case Activity 3 •Tester A and B 5 days Design Phase
Specification
5. Develop Test Activity 4 •Tester A and B 3 days Design Phase
Procedure Specification
6. Develop Test Item Activity 5 •Tester A and B 1 days Design Phase
7. Prepare Tools and Test Activity 6 •Tester A and B 3 days Design Phase
 Scripts
8. Review Test Plan and Activity 7 •Test Manager 2 days Design Phase
Attachments •Test Leader
•Tester E
Check that System is Activity 8 •Tester E, A and B 1 days Design Phase
Ready to be tested
10. Add Design Activity 9 •Test Leader 1 days Design Phase
Documents to CMS •Tester E, A and B
(Milestone)

Step by Step Create Gantt Chart of System Testing Plan

Adding Task:

 Write the name of each task in the spreadsheet using the column “Task Name”
 Write the duration in days of each task in the spreadsheet using the column “Duration”
 Group the tasks by the Phase according to the table of tasks shown before, and add a group that encloses the
phases named “System Testing Plan MCY-ADTT-ST-2002-01” this will represent the plan as a whole
 Write the predecessors of each task in the spreadsheet using the column “Predecessors” (If you can’t see the
column, try to expand the vertical bar that divides the spreadsheet to the Gantt Chart)
 To convert a Task in a Milestone, just double click the Task and go to the tab “Advanced” then check the box that
says “Mark Task as a Milestone”

Grouping:

 Insert a new task at the beginning that will group everything. Highlight the tasks that are going to be added as
subtasks and use ‘Indent’ option.
1.1 Insert new task 1.2 Highlight task

The final result should look like this, now repeat this steps to create the Subgroups that will represent the phases
(Definition and Design).

1.3 Create Group

 Insert a new task at the beginning of the definition tasks. Highlight the tasks that are going to be added as
subtasks.
 2.1 Insert new task 2.2 Highlight task

The final result should look like this, now repeat this steps to create the Subgroup that will represent the phase “Design

2.3 Create Group

 Insert a new task at the beginning of the Design tasks. Highlight the tasks that are going to be added as subtasks
in the design phase and then Click on the option ‘Indent’
 The final result should look like this

3.3 Create Group

Add Resource:

 Got to the view “Resource Sheet”

 Add the necessary resources to the “Resources Sheet”, we are going to use only the Name, Initials and Standard
Rate in $/hr. The resources are going to be taken from the table showed at the beginning of the example, more
specifically from the column “Responsibilities”
 Now, with the Resources already register in the project file, go back to the View “Gantt Chart”
Assign Resources:

 Double click the task you want to link to resources available in the “Resource Sheet”
 Then got to the Tab “Resources” and look up the resources you want to relate to the activity (For the example
let’s keep the amount of effort of each Resources as 100%, Leveling Resources won’t be covered in this tutorial),
finally Click the “Ok” button to finish the assignment.
 Repeat steps 1 and 2 for the rest of the tasks.

Insert more Column:

 We can show more information, related to the tasks, in the spreadsheet, one column that might be of general
interest is the cost, to do this first perform a Right Click on top of the spread sheet (Specifically In the titles of the
Columns), a pop-up menu should appear showing several options, chose the one that says “Insert Column”
 2. Then lookup the column named “Cost” and then press the “Ok” button
As explained before, you can add and hide columns from the Spread sheet, this lets you show exactly what the people
needs to see, below is a view with selected fields: Name, Cost, Duration, Resource initials and Start Date. The reader is
welcome to experiment with this features and to explore more views that are offered by MS Project, such as resources
usage, cost reports, etc.
Exercise:

Create Gantt Chart and Network Diagram in Microsoft Project with above mention projects.
 Social website like (Facebook, Twitter etc.)
 Hospital Management System
 Faculty Management System

Social Website Gantt chart

Hospital Management System

Faculty Management System
 LAB #11

Objectives

 Gain understanding of project management.

 Learn how to prepare project plans.

Project management is the process of planning and controlling the development of a system within a specified timeframe
at a minimum cost with the right functionality.
Project Work Plan
Prepare a list of all tasks in the work breakdown structure, plus:
 Duration of task.
 Current task status.
 Task dependencies.
 Key milestone dates.

Tracking Progress
 Gantt Chart
o Bar chart format.
o Useful to monitor project status at any point in time.
 PERT Chart
o Flowchart format.
o Illustrate task dependencies and critical path.

A Gantt chartis a graphical representation used in project management that will show the length of time tasks in the
project should take, as measured against real time. This helps the project to run more smoothly because:
 You can easily see the order of tasks.
 You can see project progress in terms of where you are and where you should be, because each task is given a
time allotment.
 Helps you see any dependencies that may exist between tasks.

Steps to Create Gantt chart

1. On the File menu, point to New, point to Schedule, and then click Gantt Chart.
2. On the Date tab, type the number of tasks you want to start with, the time units you want displayed, and the date
range for the project.
3. Replace default task names with the task names relevant to your project and replace task start dates, finish dates,
and durations.

Add more tasks to the Gantt chart.

1. Select the project frame by clicking the solid line that surrounds the Gantt chart.
 2. Drag down the selection handle   at the lower center of the frame. New task rows are created to fill the space.
3. Click the Task Name cell for one of the new tasks, and then type the task name.
Add milestones to the Gantt chart.
1. From Gantt Chart Shapes, drag a Milestone shape onto the drawing page and position it between the tasks you want
the milestone to precede and follow.
2.  NOTE   When you add a Milestone shape to a Gantt chart, you also automatically add a task row with duration of
0 (zero).
3. Type a name and date for the milestone.
Create dependencies between tasks in the Gantt chart.
1. Create dependencies between tasks in the Gantt chart.
2. First, click to select the task bar or milestone you want to link from, and then press SHIFT and click to select the
dependent task or milestone.
3. Right-click one of the shapes, and then click Link Tasks.

PERT chart (Program Evaluation Review Technique)

A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT
stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage
the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for
project management in the private sector at about the same time.
A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either
circles or rectangles) representing events, or milestones in the project linked by labeled vectors (directional lines)
representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks.

Create a PERT chart structure

Each project task or step is represented by a node. Nodes are divided into sections where you can record task data.
First, you'll drag a node for each task onto the drawing page. Then, you'll connect the nodes to indicate the order in
which the tasks must be completed and the dependencies between them.
1. In Visio, on the File menu, point to new, point to Schedule, and then click PERT Chart.
2. From the PERT Chart Shapes stencil, drag a PERT 1 or PERT 2 shapes onto the drawing page to create the
first node.
3. Drag a second PERT 1 or PERT 2 shape onto the drawing page to create the second node.
4. Drag a Dynamic connector shape onto the drawing page.

5. Click away from the connector to see which end has an arrowhead, select the connector, and then drag the end
without the arrowhead to the middle of the first node until a red box appears around the entire shape.

6. Connect the other end of the connector to the second node the same way.

7. The shapes stay connected at the closest available points when you move them.

8. Continue dragging and connecting node shapes until each of your project tasks or steps is represented by a node.
 Task

1. GANTT Chart
Your organization has won a tender to create a new "Software as a Service" product, and you're in charge of the
project.
You decide to use a Gantt chart to organize all of the necessary tasks, and to calculate the likely overall timescale for
delivery.
You start by listing all of the activities that have to take place, and you estimate how long each task should take to
complete. Your list looks as follows

Task Length

A. High level analysis 1 week

B. Selection of server hosting 1 day

C. Configuration of server 2 weeks

D. Detailed analysis of core modules 2 weeks

E. Detailed analysis of supporting modules 2 weeks

F. Development of core modules 3 weeks

G. Development of supporting modules 3 weeks

H. Quality assurance of core modules 1 week

I. Quality assurance of supporting modules 1 week

J. Initial client internal training 1 day

K. Development and QA of accounting reporting 1 week

L. Development and QA of management reporting 1 week

M. Development of management information system 1 week

N. Client internal user training 1 week

2. PERT Problem

1: Which tasks are on the critical path?

2: What is the slack time for tasks C, D and G?
3: Task C is delayed by one day. What impact would this have on the completion date of the project? Why?
4: Task A will be delayed by 2 days because some equipment has arrived late. If the project manager wants to finish the
project on time he will need to shorten the duration of one or more of the tasks. How can he achieve this?
5: The project manager reduces the durations of tasks D and F by one day each. How will this affect the finishing date of
the project?
2. Draw Gantt chart and PERT Chart of assigned Projects

GANTT CHART:
Your organization has won a tender to create a new "Software as a Service" product, and you're in charge of the
project.
You decide to use a Gantt chart to organize all of the necessary tasks, and to calculate the likely overall timescale for
delivery.
You start by listing all of the activities that have to take place, and you estimate how long each task should take to
complete. Your list looks as follows

Task Length

A. High level analysis 1 week

B. Selection of server hosting 1 day

C. Configuration of server 2 weeks

D. Detailed analysis of core modules 2 weeks

E. Detailed analysis of supporting modules 2 weeks

F. Development of core modules 3 weeks

 Task Length

G. Development of supporting modules 3 weeks

H. Quality assurance of core modules 1 week

I. Quality assurance of supporting modules 1 week

J. Initial client internal training 1 day

K. Development and QA of accounting reporting 1 week

L. Development and QA of management reporting 1 week

M. Development of management information system 1 week

N. Client internal user training 1 week

2. PERT Problem

1: Which tasks are on the critical path?

Answer:
Task H is on critical path because of it long time duration.

2: What is the slack time for tasks C, D and G?

Answer:
Slack time of C, D and G is 3 because it connect with B and there start time is same as to B end time.

3: Task C is delayed by one day. What impact would this have on the completion date of the project? Why?
Answer:
If task C is delayed so all the remaining process is stop due to incompletion of Task C because all remaining task is
connect with C so they cant work more if C is not complete and Completion of task would increase the time which he
gives and all project take more time to complete.

4: Task A will be delayed by 2 days because some equipment has arrived late. If the project manager wants to
finish the project on time he will need to shorten the duration of one or more of the tasks. How can he achieve
this?
Answer:
if Task A will be delayed 2 days so it take the shorten path to complete which is A to G then its goal state A, G  Goal
State which I so it is the shortest path.

5: The project manager reduces the durations of tasks D and F by one day each. How will this affect the finishing
date of the project?
Answer:
If project manager reduce duration of task D and F by one day is so it complete their task with to much difficulties
because their schedule is mix-up due to short time duration but the task complete in less time and finish date of project is
decrease.

Draw Gantt chart and PERT Chart of assigned Projects

 LAB #12
Objectives

To Understand Software Requirement Specification (SRS).

Theory
Software Requirement Specification (SRS) document usually contains a software vendor’s
understanding of a customer’s software requirements. This document ensures that the software
vendor and the customer are in agreement as to the features required in the software system
being built. SRS is created after the initial requirement elicitation phase in which Software
vendor interacts with the customer to understand the software needs. Usually SRS
documentation is prepared by a business analyst who has some technical background.
An SRS is written in precise, clear and plain language so that it can be reviewed by a business
analyst or customer representative with minimal technical expertise. However it also contains
analytical models (use case diagrams, entity relationship diagrams, data dictionary etc.) which
can be used for the detailed design and the development of the software system. SRS is one of
the most critical pieces of software development since it acts as the bridge between the software
developers and business analysts.

What is the need for an SRS document?

Software Requirements Specification is usually the first deliverable for any software project. As
they say, first impression is the best impression! And you should ensure that even the first draft
of an SRS is of high quality.
The benefits of a good SRS are,
 A contract between the customer and the software vendor – A good SRS document
specifies all the features required in the final system including technical requirements and
interface requirements. SRS document is used by the customer to determine whether the
software vendor has provided all the features in the delivered software system. To the Software
vendor it provides a solid foundation to fix the scope of the software system.
 Enables costing and pricing of the project – A well defined SRS enables software
developers to accurately estimate the amount of effort required to build the software product.
Function point analysis and SMC are some the techniques adopted for estimating effort.
 Input for detailed design – A good SRS enables experienced developers to convert the
requirements directly to a technical design. For example, a well defined data dictionary can be
easily converted to a database specification.
 Management of customer expectations – Since SRS precisely defines project scope; it
ensures that customer expectations don’t change during software development . If they do, SRS
can be modified and costing/pricing can be done again on the changes required.

What are the contents of an effective SRS document?

There is no single precise template for writing good Software Requirement Specifications. The
contents of an SRS document depend on the software product being developed and also on the
expertise of the people doing the requirement elicitation. Different business/technology domains
in a company usually have their own customized version of SRS template. Still a good Software
Requirement Specification (SRS) usually contains project scope section, functional
requirements, requirement analysis models, external interface requirements and non functional
requirements.

Remember that there is no “Perfect SRS”. However, SRS should be:

 Correct: each requirement represents something required by the target system.
 Unambiguous: every requirement in SRS has only one interpretation
 Complete: everything the target system should do is included in SRS (no sections are
marked TBD-to be determined).
 Verifiable: there exists some finite process with which a person/machine can check that
the actual as-built software product meets the requirements.
 Consistent in behavior and terms.
 Understandable by customers.
 Modifiable: changes can be made easily, completely and consistently.
 Design independent: doesn't imply specific software architecture or algorithm.
 Concise: shorter is better.
 Organized: requirements in SRS are easy to locate; related requirements are together.
 Traceable: each requirement is able to be referenced for later use (by the using paragraph
numbers, one requirement in each paragraph, or by using convention for indication
requirements).

Software Requirements Specification

Table of Contents

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview

2. General Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Characteristics

3. Specific Requirements
3.1 Functional Requirements
3.2 Performance Requirements
 3.3 Non-Functional Requirements
3.4 Design Constraints

Appendix
A. 1 Hospital Management Process Diagram

1. Introduction

1.1 Purpose

Basic Description of Problem

The Administrator and staff of a hospital have been experiencing major headaches in organizing and
managing patients, beds, and nurses. There have been reports of missing patient information, lack of
security and privacy on patient medical history, and confusion in bed allocations. Nurses have
complained about mistakes in nurse allocation to patients, and bed management for waiting patients. The
manual systems cannot handle current demands on hospital staff.
1.2 Scope
The purpose of this specification is to document requirements for a system to manage the hospital. The
specification identifies what such a system is required to do. The specification is written in a format
conforming to the IEEE Standard 830-1984. Subject to approval, the specification will complete the
Requirements phase and will be followed by detailed design, implementation, and testing.
The product will be labeled the Hospital Management System (HMS). The Hospital Management System
will manage a waiting list of patients requiring different treatment. The availability of beds will be
determined and if beds are available the next appropriate patient on the list will be notified. Nurses will be
allocated to wards depending on ward sizes, what type of nursing is needed, operating schedules, etc.
The current manual method of managing patients, nurses, and beds is time consuming and error prone. It
is also difficult to manage the large paper flow involved in this process. The Hospital Management
System will allow hospital administrative staff to access relevant information efficiently and effectively.
The goal of HMS is to manage nurses, patients, beds, and patient medical information in an efficient cost-
effective manner. All of these sub-systems (managing nurses, beds, patient medical information) need to
be designed and implemented so that HMS can run effectively.
1.3 Definitions, Acronyms, and Abbreviations
HMS Hospital Management System
GUI Graphical User Interface
PHID Patient Hospital Identification Number
1.4 References
1. Austin, C.J. (1983). Information Systems for Hospital Administration. Health Administration Press.
2. Dean, R. (1996). The Healthcare Information Systems Directory [online]. http://www.health-infosys-
dir.com/
3. Rowland, H.S. (1984). Hospital Administration Handbook. Aspen Publishing.
4. Rowland, H.S., Rowland, B.L. (1992). Manual of Hospital Administration. Aspen Publishing

1.5 Overview
This specification includes a brief product perspective and a summary of the functions the software will
provide. User characteristics are discussed and any general constraints or assumptions and dependencies
are listed.
Requirement statements are categorized as functional requirements, performance requirements, non-
functional requirements, or design constraints. Functional requirements are further categorized in terms of
patient management, nurse management, or bed management. Non-functional requirements are further
categorized in terms of security, maintainability, and scalability.
An appendix of additional information is provided. A process diagram is included.
2. General Description

2.1 Product Perspective

The HMS is designed to help the hospital administrator to handle patient, nurse and bed information. The
current design goal is to build an internal system to achieve the functionality outlined in this specification.
2.2 Product Functions
The HMS will allow the user to manage information about patients, nurses, and beds. Patient
management will include the checking-in and checking-out of patients to and from the hospital. The HMS
will also support the automatic backup and protection of data
2.3 User Characteristics
There are three different types of users for the HMS system:
Type 1. The Hospital Administrator who is most familiar with the problem domain. He has some
knowledge of basic computer operations and applications such as Microsoft Word, Excel,
and PowerPoint. He has some education in computer science, which allows him to adapt
to new systems quickly. The Hospital Administrator is the only person who will have the
authority to change information stored in the database. In addition, the Hospital
Administrator is the major stakeholder in this project. The Hospital Administrator should
therefore always be consulted for comments on requirements issues.
Type 2. Administrative Clerks, who handle data entry for the HMS system. They have data entry
training from college. Administrative Clerks are familiar with basic computer operations.
Type 3. Nurses, who are in charge of hospital wards. Of the three user types nurses have the least
computer knowledge. There is a requirement for nurses to perform some data entry.
Nurses will need to make regular scheduling changes, and so the interface should be easy
to use.

Based on the above categorizations, in order to meet user's needs the following precautions should be
taken:
 the interface should be designed with the computer novice in mind
 data entry masks should recognize and correct improperly entered data
 for deleting or revising a record the system should ask the users for confirmation
 report generation should occur in a timely fashion
 diverse computer education levels should be considered
 online help is important
 the design should not assume users will perform their jobs as expected
 error messages should be used
 system design should follow the manual process as closely as possible
 the interface should be easy to understand
 users should be consulted throughout design

2.4 General Constraints

The following constraints will limit the developer's options for designing the system:

 Implementation is required by the end of week 11, semester 2, 2002.

3. Specific Requirements

3.1 Functional Requirements

R l. Patient Management Subsystem
The patient management subsystem requirements are concerned with the management of patient
information. They specify how patient information can be managed and manipulated.

R 1.1 The HMS shall allow the user type 1 and 2 to update patient personal information (name,
address, tel, email, closest relative, date of birth, …).
R 1.2 The HMS shall store all patient illness history information (past illnesses, test results,
allergies, …).
R 1.3 The HMS shall allow the user type 1 and 2 to add new patients into the system.
R 1.3.1 The HMS shall assign a unique ID to new patients.
R l .4 The HMS shall allow all user types to retrieve patient personal information by patient ID
or patient last name, first name, or Medicare number.
R l.4.1 The HMS shall allow all user types to retrieve patient personal information.
R l.4.2 The HMS shall allow user type 1 and 3 (only if nurse assigned to the particular
patient) to retrieve patient illness history information.
R 1.5 The HMS shall manage the patient check-in process.
R l.5.1 The HMS shall update the patient status to in-patient.
R l.5.2 The HMS shall record bed, nurse, and doctor information associated with the
patient.
R 1.5.3 The HMS shall allow the user type 1 or 2 to change bed, nurse, and doctor
information associated with the patient.
R l.6 The HMS shall allow the user type 1 and 3 (only if nurse assigned to the particular patient)
to update patient treatment information.
R 1.7 The HMS shall manage the patient check-out process.
R 1.7.1 The HMS shall update the patient status to out-patient.
R l .7.2 The HMS shall calculate the bill due when the patient checks out.

R 1.8 The HMS shall manage patients on a waiting list.

R l.8.1 The HMS shall allow the user type 1 or 2 to add patients to a waiting list.
R l.8.2 The HMS shall allow the user type 1 or 2 to remove patients from a waiting list.
R 1.8.3 The HMS shall allow the user type 1 or 2 to check-in a patient on a waiting list.
R l.8.4 The HMS shall allow the user type 1 or 2 to retrieve waiting patient information
by illness category, illness seriousness, start waiting date, patient last name, first name,
ID, or Medicare number.
R 1.9 The HMS shall allow all user types to generate reports on patients.
R l.9.1 The HMS shall allow all the user types to generate reports on selected patients.
R 1.9.2 The HMS shall allow all user types to generate reports of in-patients by ward,
illness category, or check-in date.
R l.9.3 The HMS shall allow all user types to generate reports of on-waiting patients by
illness seriousness, illness category, or waiting time.
R2. Nurse Management Subsystem
The nurse management subsystem requirements are concerned with the management of nurse
information. They specify how nurse information can be managed and manipulated.
R 2.1 The HMS shall allow the user type 1 or 2 to add new nurses to the system.
R 2.2 The HMS shall allow the user type 1 or 2 to remove nurses from the system.
R 2.3 The HMS shall allow the user type 1 or 2 to update nurse information.
R 2.3.1 The HMS shall allow the user type 1 or 2 to update nurse personal information (name,
address, tel, email, date of birth, …).
R 2.3.2 The HMS shall allow the user type 1 or 2 to update nurse specialty information
(area of expertise, experience).
 R 2.4 The HMS shall allow all user types to retrieve nurse information by nurse number or last
name, first name, or tax file number.
R 2.4.1 The HMS shall allow all user types to retrieve available nurse information.
R2.4.2 The HMS shall allow all user types to retrieve nurse information by specialty.
R2.4.3 The HMS shall allow all user types to retrieve nurse personal information.

R 2.5 The HMS shall update nurse available information when a nurse is assigned to a checked-in
patient.
R 2.6 The HMS shall allow user all users to generate reports on nurses by specialty, available
status, or experience.
R3. Bed Management Subsystem
The bed management subsystem requirements are concerned with the management of bed information in
the hospital. They specify how bed information can be managed and manipulated.
R 3.1 The HMS shall allow all users to add new beds to a ward.
R 3.2 The HMS shall allow all users to remove beds from a ward.
R 3.3 The HMS shall update availability status when a patient checks in or checks out.
R 3.4 The HMS shall allow all users to retrieve available bed information by bed number.
R 3.5 The HMS shall allow all users to generate reports about beds.
R 3.5.1 The HMS shall allow all users to generate reports about beds by ward
oravailability status.
R3.5.2 The HMS shall allow all users to generate bed usage statistic reports showing bed
usage rates in one year by ward.
R4. Other Requirements
The HMS shall backup patient, nurse, and bed data every 24 hours automatically

3.2 Performance Requirements

R5. The HMS shall respond to user's retrieving information quickly. The waiting time for any retrieve
operation must be under 2 seconds.

3.3 Non-functional Requirements

.
R 6. Security.
The security requirements are concerned with security and privacy issues. All patient medical information
is required by law to be kept private. Only after the patient signs a written consent form (on being
admitted to hospital) can anyone (even the patient's doctor, nurse, and the hospital administrator) view the
medical details about any particular patient. In the case of an emergency, the allocated doctor, nurse, and
the hospital administrator are immediately given user 3 status, and written consent is sought from the
patient afterwards.
R 6.1 The HMS shall support different user access privileges.
R 6.1.1 User type 2 shall have security privilege level 1. They can only read patient
current illness information. They can’t access patient illness history information.
R 6.1.2 User type 3 shall have security privilege level 2. They can read and write patient
current illness information. They can only access patient illness history information if
they have been assigned to the particular patient.
R 6.1.3 User type 1 shall have security privilege level 3. They can read and write patient
current illness information. They can also read patient history information.
R 6.2 The HMS shall protect patient illness history information.
R7. Maintainability
The maintainability requirements are concerned with the maintenance issues of the system.
R 7.1 The repair time of HMS shall be under a half hour.
R 7.2 System down time for maintenance should be less than 6 hours per quarter of a year.
R8. Scalability
The scalability requirements are concerned with the scalable issues of the system.
R 8.1 The HMS shall be able to scale up to support more workstations. System performance shall
not degrade if up to twenty percent (20%) more workstations are added.

3.4 Design Constraints

R 9. The HMS shall use a graphical user interface.
R 10. The HMS must run in the 3rd year computing labs.
R 11. The HMS must be written in Java.

Appendix:

A.1 Hospital Management Process Diagram

Exercise

1. Design SRS documentation of assigned project

 Project Report
On
“BLOOD BANK MANAGEMENT SYSTEM”

Submitted for partial fulfillment of requirement for the award of degree

Of
Bachelor OF Computer Science
In

Sir Syed university of Engineering and technology

Batch 2018

DEPARTMENT OF COMPUTER

Sir Syed university of Engineering and technology

Introduction
Today the business and services environment is becoming very complex and
competitive. Besides the availability of modern technology, highly qualified and
well-trained staff, without an efficient management system, organizations cannot
function efficiently. Almost all the blood banks use the manual system because
there is no centralized management system to support their day to day activities.
The objective of this project is to provide solution based on ICT to improve
efficiency of manual based systems and to eliminate the paper work.
Business Background
Blood banks use the manual way to record data of its donors, acceptors, details of
blood etc. without knowing the fact that the data that is collected at the blood
banks can be used for many research purposes, and can be analyzed in different
ways. For example when a person comes to donate blood he has to go through
many tests and the result of the tests can be used to determine different patterns.
The manual system itself is time consuming and prone to human errors therefore it
has less accuracy. It requires lots of man power, lacks data security and retrieval of
data is time consuming.
Strategy
Many strategies can be used for successful implementation of this system. Firstly,
we have to move all the data from papers to the centralized servers so that
information retrieval becomes easier and we don’t lose our previous data and make
high quality system through which we can make our process work in more efficient
way.
Objectives
Our main object is to create a centralized system for blood banks which makes:
 Collecting and storing data easier.
 Upgrade the system as per new technology.
 Digitize the system for easy usage.
 Keep a check on inventory of blood.
 Monitor the achievement. .

Vision
The vision is the mission or goals that an organization wants to achieve. For a
blood bank the mission would be:
 Responding to customer’s queries.
 Improving ourselves in this competitive world..
  Building trust among the customers.
 Every individual must be valued equally in the work environment without
any partiality
 Deliver all the services on time as in this system time is very crucial.

Infrastructure
To implement the system I would use developer’s account of sales force. Through
that I will be able to manage all the communications with the donors, the hospitals
and people in emergency. If this system runs well next step would be analysis of
the data collected.

Implementation
Implementation of this project will take careful analysis of all the attributes and
entities in our system and how they can be linked to each other. How the process
will flow through different entities will be a crucial task too.
Also we have to perform the SWOT analysis for our system to know the strengths,
weaknesses, opportunities and threats and how external and internal forces can
influence our system.
After the SWOT analysis we will make the E-R diagram then the class diagram
which will visually represent our proposed system in a better way.

SWOT Analysis
Relational Schema of BBMS:

In this relational schema we totally define our project structure and also clearly
visible all objects and attributes of project which we use in our project.

Objects/Attributes:

 Login {username (pk), password}.

 Signup {fname, lname, username (FK), password, contact, gender, address}.
  Donor details {D_id (PK),
D_name,D_contact,D_gender,D_bloodgroup,D_address}.
 Acceptor details {A_id (PK), A_name, A_contact, A_gender,
A_bloodgroup, and A_address}.
 Test {T_id(PK), T_name, Patient_name, T_date}.

Use Case Diagram of BBMS:

Here is the use case diagram of BLM which are given bellow.

Sequence Diagram of BBMS:

Here is the Sequence diagram of BLM which are given bellow.
Class Diagram of BBMS:

IMPLEMENTATION:
This is the Part B of the report, in Part A I have discussed about the requirements
of the Blood Bank Management System and also the design of the system. In this
part I will discuss the implementation of that system. The aim was to make the
centralized system of the Blood Bank for the easy maintenance utilization and
analysis of information.

OBJECTS:

In my application I have used all these objects out of which Donor Details,
Acceptor Details, Test, Matching Criteria are custom objects and Reports and
dashboards are standard objects. Forms for the custom objects are as follows:

New Users:
This is the form to register new User into the system. I have also uploaded some data
using the data import wizard.

Donor Details
This object contains the details of the donors that are registered in the Blood Bank.
Acceptor Details
This object contains the details of the Acceptor that are registered in the Blood
Bank.

As we shown in above this is all details and pages of my Blood bank management
system now we discuss about the ER diagram of this project.
Now we discuss about the requirements of BBMS.

REQUIRMENTS:
User Requirements:

1. User can sign up firstly and after login through id and password.
2. User can send the blood to their friends.
3. User can update the status donor or acceptor.
4. User can give the blood to acceptor.
5. User can change the status.
6. User can also select the instructor
7. Donor can also donate blood.
8. Acceptor and donor also update the blood group.

System Requirements:
1. Operating system: Window XP & higher.
2. IDE: visual studio.net 2005 / 2010.
3. Front end: ASP.NET.
4. Language: C#.NET.
5. Database: SQL server 2000/2005.

Hardware Requirement:
1. Intel P4 1.5GHz or above.
2. 512MB ram.
3. 80GB HDD Minimum.

Functional requirements:
1. Login of admin.
2. Blood Donor
3. Change the login password of admin.
4. Register the donor by himself.
5. Register the donor by system admin.
6. Login of the donor
7. Change the login password of the donor.
8. Change personal, contact details by the donor himself.
9. Change personal, contact details by system admin.
10. Withdraw reg. details by the donor.
11. Withdraw reg. details by the admin.
12. Send blood donation details to the relevant donors.
13. Send blood testing details.
Non Functional Requirements:
There are a lot of software requirements specifications included in the non-functional
requirements of the Hospital Management System, which contains various process, namely
Security, Performance, Maintainability, and Reliability.

Security:
● Patient Identification: The system needs the patient to recognize herself or himself using the
phone.
● Logon ID: Any users who make use of the system need to hold a Logon ID and password.
● Modifications: Any modifications like insert, delete, update, etc. for the database can be
synchronized quickly and executed only by the ward administrator.
● Front Desk Staff Rights: The staff in the front desk can view any data in the Hospital
Management system, add new patient’s record to the HMS but they don't have any rights alter
any data in it.
Administrator rights: The administrator can view as well as alter any information in the Hospital
Management System.

Performance: 
● Response Time: The system provides acknowledgment in just one second once the 'patient's
information is checked.
● Capacity: The system needs to support at least 1000 people at once.
● User-Interface: The user interface acknowledges within five seconds.
● Conformity: The system needs to ensure that the guidelines of the Microsoft accessibilities are
followed.

Maintainability: 
● Back-Up: The system offers the efficiency for data backup.
● Errors: The system will track every mistake as well as keep a log of it. 

Reliability: 
● Availability: The system is available all the time. 
Feasibility Report for Blood Bank Management System
The feasibility report of our blood bank management system is a great project is designed for
successful completion of project on blood bank management system.
The Blood bank system project report contain information related to blood like
Blood type.
Date of Donation of Blood.
Validity of Blood.
Availability of Blood Group.

Cost:
The cost of our project is very low because there are much language available at very low cost.
The languages which are available at low cost are as follows:
C#
Windows Forms
SQL SERVER

Time Taken:
The time taken by project is not more than one week because the data of our project is not more
than 50 users that are why it’s less time taken application.

DATABASE Software:
The database which we used is MySQL because the reliability performance and speed of
MySQL is so good.
Scalability.
The MySQL database server provides the ultimate scalability.

High Performance:
Unique storage engine architecture allows database professionals to configure the
MySQL Database server.

High Availability:
Solid availability of MySQL database server with customer reliable guarantees
around the clock uptime.

Now in the end we discuss about ER-Diagram of BBMS.

ER-Diagram:

Conclusion:
In this project I tried to implement the Centralized Blood Bank Management
System. This project is built on sales force and can serve many advantages to the
organization. As everything is centralized we can combine many objects in order to
perform effective analysis. Effective analysis of data can help a lot in medical field
as many other objects and fields can be added to this system for the different blood
groups.