You are on page 1of 56

PROBLEM STATEMENT

The following problem arises when using a typical blood bank’s existing system:

• Personal profile accessibility ( P1 )

The donor’s information can only be updated by the administrators of the blood
Bank. A donor can update their information by calling, faxing, e-mailing, but not by
themselves. This is a waste of time just for updating a piece of information and it
may be troublesome for some donors.

• Lost or damaged card (P2 )

A typical membership card can easily get damaged if it is exposed to the sunlight or
weather and this causes to ruin the card’s barcode which is significantly important
for retrieving records. If the card gets lost or stolen, the donor has to make a
replacement card to keep their membership at the blood bank.

• Donation record accessibility ( P3 )

The donor ID card is the only tangible evidence that contains the donor’s recent
donation records, if the card gets lost, donors may find it difficult to schedule their
next appointment since they are not able to see the last time they had donated blood.

• Blood result notifications ( P4 )

After the process of blood donation, the donor will receive a card that only contains
their name and blood type. They will not be notified of their blood result unless they
request that information from the blood bank.

• Blood stock management ( P5 )

Blood banks are required to maintain account of blood bags in the inventory. This
increases with each blood donation recorded in our system and decreases as they are
checked out upon hospital requests. Our system will need to keep the Information
up-to-date to ensure correctness of the inventory.

• Mailing by postal system ( P6 )

Blood banks will only mail donors when the donated blood is disqualified, however,
this mail is sent through the postal system to the donor’s given address. If the
donor’s address is recorded incorrectly, the mail will be sent to the wrong address
and the donor will never be notified that their blood is rejected and given the reason
for that.
1. Application of software requirement engineering

INTRODUCTION

1.1PURPOSE:

The web based blood donation system is mainly uses for helping the patient who
need blood. So this SRS document consists of a simple explanation about the system
and its features. The document mainly focuses on providing sufficient design
information to the blood bank authorities. And also it will satisfy the functional,
design, performance requirements of the system in briefly.

1.2 Scope:

The main intend of this SRS is to provide a simple description to the blood bank
authorities & system users, about the behaviour of the system. And the entire
package is consisting of below parts.

System software – The system will contains a database in order to store all details
about the donors as well as doctors.
Software documentation – A complete document about the software will be given to
the blood bank administration in order to future maintenance of the system.
Operation Manual – A user manual is provided to the system administrator with
some simple explanations about the system and its features.
User Manual – When the donor submits his/her details through internet a simple
guidance is also given to the donor.

1.3 Definitions, Acronyms & Abbreviations:

WBBDS - Web based blood donation system


Database - Consist of all information related to donors & doctors
HC Certificate – Health Condition Certificate
Login – The process which is related to logging into the system
Password – A set of characters which can be used to correctly identify the exact
person who is log into the system
Id number – Identity card number
MB – Mega byte (Unit of memory storage in computer)
SRD – System requirement definition
SRS – System requirement specification

1.5 Document Overview:

The document has 3 major sections.

1. Introduction – Overview of the whole SRS document


2. General characteristics – A description about the features of the system.
2.1 Introduction
2.2 Product perspective
2.3 Product functions
2.4 User characteristics
2.5 General constraints
2.6 Assumptions & dependencies
3. Specific requirements – A description of specific requirements of the system.
Functional requirements
External interface requirements
Performance requirements
Design constraints
Non-functional requirements
Attributes
2. General characteristics
2.1 Introduction:

Through this section a description is given about the characteristics about the entire
system.

2.2 Product perspective:

WBBDS is mainly towards persons who are willing to donate blood to the patients.
Through this system it will be easier to find a donor for exact blood type and easy to
build the connection between donor & the blood bank authorities.

The main intend of building this software is to formal the procedure of blood
donation & motivate donors in order to donation blood. The system also consists of
some local system hardware devices as well.

A printer & SMS indicator are the main devices among the other devices. The entire
software product includes the all relevant features to create a better connection
between the blood donor & blood bank authorities.

2.1.1. System interfaces.

The data from previous inventory system are available in CSV format. UUIS will
need an API to import data from those files.

2.1.2. User interfaces.


The UI should be easy to manipulate without additional training. The user should be
able to interact with the system in any of the languages available in the language
menu. The pages should use a ZUI graphical environment, should be built with a
good sense of colour and contrast, and should be printable, using keys. All pages of
the system should be accessible from any page.
2.1.3 Communication interfaces.

The system requires HTTP to communicate with server. The system can be
configured to be accessed via any available port. The web based UI is the only
means of communication between the user and the system. The system is accessible
through all popular web browsers that interact with JSP and HTML pages.

3.3.2 Hardware Interface:

 Min. (64) MB RAM


 Key Board
 Mouse

3.3.3 Software Interface:

 Visual Basic 6.0


 Microsoft Access used as back –end to store the database.

2.1.4 Memory constraints.

UUIS requires a minimum of 512 MB of primary memory and 3GB of secondary


memory for installation and execution.

2.3 Product functions:

Class of use cases Use cases Description


Use cases related to Login of admin Change Log admin into the
system authorization of password of the admin system Change login
system administrator password of the admin of
the system
Use cases related to Register the donor by Store personal, contact,
registration of a donor himself Register the medical details of donors
donor by system admin Store personal, contact,
medical details of donors
Use cases related to Login of donor Log donor into the
system authorization of Change password of the system
the donor donor Change login password
of the donor of the
system

Use cases related to change personal, Change personal &


change the registration contact details by the contact details of donors
details of donors donor himself change Change personal &
personal, contact details contact details of donors
by system admin
Use cases related to Withdraw reg. details by Delete all details of a
withdraw names from the the donor Withdraw reg. exact donors by
donor list details by the admin themselves Delete all
details of a exact donors
by the system admin
Use cases related to Send blood donation Inform the requirement
inform blood donation details to the relevant of the blood group to
details donors donors who has same
blood group
Use cases related to Replace donors’ HC Override the health
replace the older HC certificates condition report details
certificates
Use cases related to Send blood testing details Inform disease details to
inform blood testing to relevant donors Inform
the donor donor details who has
diseases, to relevant
doctors
Use case related to Search relevant details Search & display
access the database from the database relevant details from the
database
Use cases related to print Print the list of newly Print the list of newly
statements registered donors, registered donors,
donation details & list of donation details, list of
removed names as removed names of
statements

2.4 User characteristics:

In here the system admin & the donor are the system users. According to my
assumptions the donor who will register to the system from the website can
understand easy questions which are in English language & he/she has the ability to
realize small instructions & fill the application without any errors & a small
knowledge of computers to upload the health condition certificate to the system.
User is very generous to attend to the donation with such a small announcement. (E-
mails & SMS messages)
2.5 General constraints:

The both kind of donors who has the internet connection & who hasn’t the internet
connection can contribute to the donation through the WBBD system.
The donor who uses internet connection will be guided through small & clear
descriptions.
Every donor may get a user name & a password in order to log into the system.
After the registration of a donor the program will authenticate the accuracy of the
donor’s mobile number through counting the number of characters in the entered
mobile number
System uses the donor registration number & the identity card number to identify
each donor separately.
Inside the system the administrator has more advance functions than the donor.
The hospital doctor is not a user of the system. But the doctor connects to the system
in a different manner. The doctor mainly has the connection with the system admin.
In donor registration, submission of HC certificates & providing donation details to
the system the doctor will connect directly with the system administrator.

2.6 Assumptions & dependencies:

Every donor has a mobile phone.


The system doesn’t keep the details of the gathering stock of blood.
The system database will be accessible in real time.
The donor doesn’t submit any fake reports to the system.
Donors who want to contribute to a donation will definitely reply to the request of
system.
The installation of the system to the website server hasn’t considered as a process
inside the system. That process will do by the authorities who are controlling the
website. Therefore in here the installation process is considered as a process which
is in outside of the scope.
A doctor or a patient can request for a exact blood group. But the request comes
through blood bank authorities to the system admin. Therefore doctor, patient are
not direct users of the system.
3. Specific requirements:

3.1 functional requirements:

Use case diagrams are used to describe functional requirements of the system. The
diagrams are drawn below.
If there is a network failure while a user is working in the system, all login details
regarding on user name & password of the user will be removed from the system.

User case related to system authorization

Use case 1: Login of admin.

Primary actor: System administrator.


Pre Condition: Internet connection should be available.

Main scenario:
1. Log into the official blood bank website.
2. Admin initiates the command to starts the application “WBBDS”
3. System is shown the all features of the system.
4. Click the “Login of administrator” command button.
5. The system asking for the user name & the password.
6. Admin provides the username & the password.
7. System does authentication.
8. Main application relevant to admin is displayed.

Alternative scenario: 7(a). Authorization fails.

1. A message is given to the admin that the provided password is wrong.


2. 2. Allow the admin to re-enter the password. 3 chances will be given.

Use case 2: Change the login password of admin.

Primary actor: System administrator.


Pre Condition: Internet connection should be available. Admin logged in.

Main scenario:
1. Admin selects the command to change the password.
2. The system is asked to type the current password, new password & again the new
password to confirm it.
3. Admin provides the current password, new password & confirm new password.
4. System does authentication.
5. New password is stored in the system.

Alternative scenario: 4(a). Authorization fails.

4(a) 1. A message is shown to the admin that the provided current password is
wrong.
4(a) 2. Allow the admin to re-enter the current password. 3 chances will be given.
4(b). New password doesn’t match with the confirm new password.
4(b) 1. A message is shown to the admin that the provided new password doesn’t
match with the current new password.
4(b) 2. Allow the admin to re-enter the new password & confirm new password.

User case related to registration of a donor

Use case 3: Register the donor by himself.


Primary actor: Donor.
Pre Condition: Internet connection should be available.

Main scenario:
1. Log into the official blood bank website.
2. Admin initiates the command to starts the application “WBBDS”
3. System is shown the all features of the system.
4. Donor initiates the register of a donor command.
5. A small questionnaire is given to the donor, which is related to personal & contact
details.
6. The donor answers the questionnaire & goes to the next page.
7. The system does authentication.

8. The system asks the donor to submit the health condition report & the evidence
report of blood group.
9. The donor submits those reports to the system & finishes the registration.
10. The system does authentication.
11. The registration details are sending to blood bank authorities through an e-mail.
12. Authorities approve details & reports. Send the approval to the system admin.
13. Store registration details in the system database. Alert the donor by sending e-
mails & SMS messages to the donor about the registration. Send the user name &
the password to the donor in order to log into the system.

Alternative scenario:

7(a). Donor doesn’t provide the answers to some main questions completely.
7(a) 1. A message is shown to the donor that he/she hasn’t answered properly. 7(a)
2. Highlight those questions. Allow 3 chances the donor to re-answer those
remaining questions.
7(b). Donor has entered an invalid mobile phone number.
7(b) 1. An error message is shown to the donor that the mobile number contains
invalid number of characters.
10(a). Donor doesn’t submit the required reports.
10(a) 1. A message is shown to the donor that he/she hasn’t submitted the required
reports.
10(a) 2. Allow 3 chances to the donor to submit the required reports again. 12(a).
Authorities don’t approve the registration details of the donor.
12(a) 1. Details will not store in the database.
12(a) 2. Send a message to that person about the rejection of the application. Ask
him to register again.

Use case 4: Register the donor by system admin.

Primary actor: System administrator.


Pre Condition: Internet connection should be available. Administrator logged in.

Main scenario:

1. Admin selects the donor registration command.


2. A small questionnaire is given to the admin which is related to personal & contact
details of the donor.
3. Type all details of a donor which is approved by the hospital authorities & goes to
next page.
4. System does authentication.
5. The system asks the admin to submit the health condition report & the evidence
report of blood group.
6. Admin submits the relevant reports which are approved by the hospital authorities
& finishes the registration.
7. System does authentication.

8. Store registration details in the system database. Alert the donor by sending e-
mails & SMS messages to the donor about the registration. Send the user name &
the password to the donor in order to log into the system.

Alternative scenario:

4(a). Admin doesn’t provide the answers to some main questions completely. 4(a) 1.
A message is shown to the admin that he hasn’t answered properly to questions.
4(a) 2. Highlight those questions. Allow admin to re-answer those questions.
4(b). Admin has entered an invalid mobile phone number.
4(b) 1. An error message is shown to the admin that the mobile number contains
invalid number of characters.
7(a). Admin doesn’t submit the required reports.
7(a) 1. A message is shown to the admin that he hasn’t submitted the required
reports.
7(a) 2. Allow admin to submit the required reports again.

Use case 5: Login of the donor.

Primary actor: Donor.


Pre Condition: Internet connection should be available.

Main scenario:
1. Log into the official blood bank website.
2. Admin initiates the command to starts the application “WBBDS”
3. System is shown the all features of the system.
4. Selects the “Login of a donor” command.
5. The system asking for the user name & the password.
6. Donor provides the username & the password.
7. System does authentication.
8. Relevant application relevant to a donor is displayed.

Alternative scenario: 7(a). Authorization fails.

7(a) 1. A message is given to the user that the provided password is wrong.
7(a) 2. Allow the admin to re-enter the password. 3 chances will be given.

Use case 6: Change the login password of the donor.

Primary actor: Donor.


Pre Condition: Internet connection should be available. Donor logged in.

Main scenario:

1. Donor selects the command to change the password.


2. The system is asked to type the current password, new password & again the new
password to confirm it.
3. Donor provides the current password, new password & confirm new password.
4. System does authentication.
5. New password is stored in the system.

Alternative scenario: 4(a). Authorization fails.

4(a) 1. A message is given to the donor that the provided current password is wrong.
4(a) 2. Allow the donor to re-enter the current password. 5 chances will be given.
4(b). New password doesn’t match with the confirm new password.
4(b) 1. Allow the donor to re-enter the new password & confirm new password.

Use cases related to change the registration details of donors

Use case 7: Change personal, contact details by the donor himself.


Primary actor: Donor.
Pre Condition: Internet connection should be available. Donor logged in.

Main scenario:

1. Donor initiates the command to edit profile details.


2. The system provides the filled application of the exact donor.
3. Donor changes personal & contact details & finishes.
4. System does authentication.
5. New details will replace the past details & store in the system.

Alternative scenario:

4(a). Donor doesn’t provide the answers to some main questions completely.
4(a) 1. A message is shown to the donor that he hasn’t answered properly to
questions.
4(a) 2. Highlight those questions. Allow the donor to re-answer those
questions.
4(b). Donor has entered an invalid mobile phone number.
4(b) 1. An error message is shown to the donor that the mobile number
contains invalid number of characters.
Use case 8: Change personal, contact details by system admin.

Primary actor: System administrator.


Pre Condition: Internet connection should be available. Admin logged in.

Main scenario:

1. System administrator initiates the command to edit profile details of donors.


2. System asks admin to enter the donor’s registration number & the identity card
number.
3. Admin provides the registration number & the identity card number of the donor.
4. System does authentication.
5. The system provides the filled application of the exact donor.
6. Admin changes personal & contact details & finishes.
7. System does authentication.
8. New details will replace the past details & store in the system.

Alternative scenario:

4(a). Authorization fails.


4(a) 1. A message is given to the admin that the registration number doesn’t
match with the id number.
4(a) 2. Allow the admin to re-enter the registration number & the identity
number. 3 chances will be given.
7(a). Admin doesn’t provide the answers to some main questions completely.
7(a) 1. A message is shown to the admin that he hasn’t answered properly to
questions.
7(a) 2. Highlight those questions. Allow the admin to re-answer those
questions.
7(b). Admin has entered an invalid mobile phone number.
7(b) 1. An error message is shown to the admin that the mobile number
contains invalid number of characters.
User case related to withdraw names from the donor list

Use case 9: Withdraw reg. details by the donor.

Primary actor: Donor.


Pre Condition: Internet connection should be available. Donor logged in.

Main scenario:

1. Donor selects the command to withdraw details from the system.


2. System is shown a message to the donor in order to confirm the decision.
3. Donor confirms the decision.
4. Donor will log out from the system.
5. Donor will get a thank you note from the system to their mobile phones.

Use case 10: Withdraw reg. details by the admin.

Primary actor: System administrator.


Pre Condition: Internet connection should be available.
: Admin logged in.

Main scenario:

1. Admin initiates the command to edit donor details.


2. System is shown the sub commands of the edit donor list command.
3. Admin selects the command to remove donor from the system.
4. System asks the registration number & the identity card number of the donor.
5. Admin submits the registration number & the identity card number of the donor.
6. System does authentication.
7. System is shown all details of the donor & system asks to confirm the decision.
8. Admin confirms the decision.
9. All details of that donor are removed from the database.
10. Donor will get a thank you note from the system to their mobile phones.

Alternative scenario:

6(a). Authorization fails.


6(a) 1. A message is given to the admin that the registration number doesn’t
match with the id number.
6(a) 2. Allow the admin to re-enter the registration number & the identity
number. 3 chances will be given.

User case related to inform blood donation details

Use case 11: Send blood donation details to the relevant donors.

Primary actor: System administrator.


Pre Condition: Internet connection should be available.
: Admin logged in.

Main scenario:

1. Blood bank authorities request for a blood group.


2. Admin selects the command to search donors for exact blood type.
3. System asks to insert the blood group.
4. Admin inserts the needed blood group details.
5. System searches the latest donation details of relevant blood donors. Select donors
for the donation.
6. System is shown the details of donors’ who can donate blood to that blood group.
7. System alerts all donors who can donate blood to that needed blood group, about
the requirement & a complete detail about the donation according to the blood bank
authorities.

8. Donors who are willing to attend to the donation will reply to the system.

Alternative scenario:

5(a). The donor has contributed to a donation within last 5 months.


5(a) 1. Ignore the names of that kind of donors from the chosen list.
5(b). There are no donors in the system who can donate blood to that blood group.
5(b) 1. System is shown a message that no matching donors for the donation.

Use cases related to replace the older HC certificates.

Use case 12: Replace donors HC certificates.

Primary actor: System administrator.


Pre Condition: Internet connection should be available.
: Admin logged in.

Main scenario:

1. Consider the submission date of the health condition report of those replied
donors.
2. The submission date of the HC certificate of those replies donors is older than 5
month.
3. System is shown the names of that kind of donors to the admin.

4. The system admin send the donors’ names to the blood bank authorities.
5. Blood bank authorities will get new HC certificates from required donors at the
donation day & send those details to the system admin.
6. Admin initiates the command to edit donors’ profile details.
7. The system is shown the sub directories of that command.
8. Admin initiates the command to replace HC certificates of donors.
9. System is shown the list of relevant replied donors for that latest donation.
10. Admin submits the reports with respect to the each relevant donor’s registration
number & select finish command.
11. System is shown the names of donors with latest submissions of medical reports
& asks for the confirmation.
12. Admin confirms the report details.
13. New reports will replace the past reports & store in the database.

Use cases related to inform blood testing to the donor

Use case 13: Send blood testing details.


Primary actor: System administrator.
Pre Condition: Internet connection should be available.
: Admin logged in.

Main scenario:

1. Blood bank authorities send blood testing details of donors, to the system admin
who is found to be having diseases.
2. Admin stores those details with respect to each donor.
3. The admin alerts the relevant donors about disease & sends them the blood testing
details through e-mails & SMS messages.
4. Relevant doctors’ details are also provided by the system administrator to the
donor through SMS messages.
5. The names of that kind of donors will remove from the donors list.

Use case related to search access the database

Use case 14: Search relevant details from the database.

Primary actor: System administrator.


Pre Condition: Internet connection should be available. Admin logged in.

Main scenario:

1. Admin initiates the command to search details from the database.


2. System asks the admin to initiate the database id of relevant sections that he wants
to access.
3. Admin provides the relevant database ID for the section.
4. System displays the relevant details from the database.

Alternative scenario:

4(a). There are no details for the initialized section.


4(a) 1. System is shown a message indicating that there are no any details in that
section.

Use cases related to print statements

Use case 15: Print the list of newly registered donors, donation details & list of
removed names as statements.
Primary actor: System administrator.
Pre Condition: Internet connection should be available.
: Admin logged in.

Main scenario:
1. Admin selects the command to print statements.
2. The system is shown a window with relevant commands.
3. The admin selects the details that he wants to print.
List of newly registered donors
Blood donation details of donors
Removed names of donors
4. The system asks for the duration
5. The admin provides the duration & finishes.
6. The system prints relevant statements.

Alternative scenario:

5(a). There are no any statements for that exact duration.

5(a) 1. System is shown a message indicating that there are no any statements
for that exact duration.

3.2 External interface requirements:

The system is basically running on the official website of the govt. blood bank.
Mainly there are 2 actors in the system. The system provides some advance features
to the system admin than the donor. If the system admin logs in, the system interface
provides some main command buttons to the admin.

 Change login password.


 Edit donor profile details.
 Search Donors for exact blood group & send messages
 Print statements.
 Update the database
 Send blood testing Details.
 Search details from the database.

If the donor logs in, the system will provide another different interface with different
commands.

 Change login password


 Edit personal, contact details.
 Details related to contributions to donation.
 Future blood donation details.
 Withdraw name from the system.

3.3.1) User Interface:

The Library is the system developed for the students to Providing


the information’s. It is a multi user system these are the owner and other
workers. The user interface to the system is very easy, as it will be implemented
by easy software, which can be used effectively, and efficiently.

3.3.2 Hardware Interface:

Min. (64) MB RAM

Key Board

Mouse

3.3.3 Software Interface:

 Visual Basic 6.0


 Microsoft Access used as back –end to store the database.
3.3.4 Communication Interface:

Verbal communication takes place between the system user


(student) and student of the Library. The communication of user to the
computer system will be very easy and user will get correct information.
Student will not directly communicate with the computer system but
he/she will feel the effect of the compute System over existing paper-
based system, as it will provide fast processing and accurate calculations.

3.3 Specific Requirement

3.3.1 SEQUENCE DIAGRAM


3.3.2 CLASS DAIGRA

3.4performance requirements

 Should run on 500 GHz, 64MB machine.


 Should have a proper internet connection.
 The response time for occurs a change will be no more than 4 seconds.
 The response time for access the database will be no more than 5 seconds.

3.5 design constraints

 Data should not become corrupted in case of network failure, system


crash or power failure.
 Security – The system is consisting of the features to keep the privacy
of every donor. Any donor cannot see any detail of any other donor.

3.6 Software System Attributes:

3.6.1) Usability:

The system is fully usable and does not require any pre-specified constraint to
work properly.

3.6.2) Efficiency:

Hardware should me min. Pentium with 196 MB RAM.

(Fully efficient in the environments having less memory available and a reasonable
speed of execution)

3.6.3) Maintainability:

In case of any change in policies and rule of the institution using the system,
required changes will be made to the module written by developer.

3.6.4) Security:

Only the super user can enter the system to use it.

3.6.5) Reliability:

System gives accurate result without any errors.

3.6.6) Performance:

The system itself is quiet fast.


2. System Design using procedural approach.

2.1 STRUCTURE CHART


2.2 PHYSICAL DFD
2.3 COMPONENT DAIGRAM FOR BLOOD MANAGEMENT SYSTEM
3. System design using object oriented approach.

3.1 USECASE DAIGRAM


3.2 CLASS DAIGRAM
3.3 STATE DAIGRAM
4. System design using UML approach.
4.1 PACKAGE DAIGRAM
4.2 COLLABORATION DAIGRAM
4.3 SEQUENCE DAIGRAM
4.4ACTIVITY DAIGRAM
5. Software testing using testing tools.
CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools.
CASE Tools
CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to
develop software system.
There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management tools,
Database Management tools, Documentation tools are to name a few.
Use of CASE tools accelerates the development of project to produce desired result and helps
to uncover flaws before moving ahead with next stage in software development.
Components of CASE Tools
CASE tools can be broadly divided into the following parts based on their use at a particular
SDLC stage:
 Central Repository - CASE tools require a central repository, which can serve as a
source of common, integrated and consistent information. Central repository is a
central place of storage where product specifications, requirement documents, related
reports and diagrams, other useful information regarding management is stored.
Central repository also serves as data dictionary.

 Upper Case Tools - Upper CASE tools are used in planning, analysis and design
stages of SDLC.
 Lower Case Tools - Lower CASE tools are used in implementation, testing and
maintenance.
 Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and documentation.
CASE tools can be grouped together if they have similar functionality, process activities and
capability of getting integrated with other tools.
Scope of Case Tools
The scope of CASE tools goes throughout the SDLC.
Case Tools Types
Now we briefly go through various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow among various
software components and system structure in a graphical form. For example, Flow Chart
Maker tool for creating state-of-the-art flowcharts.
Process Modeling Tools
Process modeling is method to create software process model, which is used to develop the
software. Process modeling tools help the managers to choose a process model or modify it
as per the requirement of software product. For example, EPF Composer
Project Management Tools
These tools are used for project planning, cost and effort estimation, project scheduling and
resource planning. Managers have to strictly comply project execution with every mentioned
step in software project management. Project management tools help in storing and sharing
project information in real-time throughout the organization. For example, Creative Pro
Office, Trac Project, Basecamp.
Documentation Tools
Documentation in a software project starts prior to the software process, goes throughout all
phases of SDLC and after the completion of the project.
Documentation tools generate documents for technical users and end users. Technical users
are mostly in-house professionals of the development team who refer to system manual,
reference manual, training manual, installation manuals etc. The end user documents describe
the functioning and how-to of the system such as user manual. For example, Doxygen,
DrExplain, Adobe RoboHelp for documentation.
Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example, Accept
360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total analysis.
Design Tools
These tools help software designers to design the block structure of the software, which may
further be broken down in smaller modules using refinement techniques. These tools
provides detailing of each module and interconnections among modules. For example,
Animated Software Design
Configuration Management Tools
An instance of software is released under one version. Configuration Management tools deal
with –

 Version and revision management


 Baseline configuration management
 Change control management
CASE tools help in this by automatic tracking, version management and release management.
For example, Fossil, Git, Accu REV.
Change Control Tools
These tools are considered as a part of configuration management tools. They deal with
changes made to the software after its baseline is fixed or when the software is first released.
CASE tools automate change tracking, file management, code management and more. It also
helps in enforcing change policy of the organization.
Programming Tools
These tools consist of programming environments like IDE (Integrated Development
Environment), in-built modules library and simulation tools. These tools provide
comprehensive aid in building software product and include features for simulation and
testing. For example, Cscope to search code in C, Eclipse.
Prototyping Tools
Software prototype is simulated version of the intended software product. Prototype provides
initial look and feel of the product and simulates few aspect of actual product.
Prototyping CASE tools essentially come with graphical libraries. They can create hardware
independent user interfaces and design. These tools help us to build rapid prototypes based
on existing information. In addition, they provide simulation of software prototype. For
example, Serena prototype composer, Mockup Builder.
Web Development Tools
These tools assist in designing web pages with all allied elements like forms, text, script,
graphic and so on. Web tools also provide live preview of what is being developed and how
will it look after completion. For example, Fontello, Adobe Edge Inspect, Foundation 3,
Brackets.
Quality Assurance Tools
Quality assurance in a software organization is monitoring the engineering process and
methods adopted to develop the software product in order to ensure conformance of quality
as per organization standards. QA tools consist of configuration and change control tools and
software testing tools. For example, SoapTest, AppsWatch, JMeter.
Maintenance Tools
Software maintenance includes modifications in the software product after it is delivered.
Automatic logging and error reporting techniques, automatic error ticket generation and root
cause Analysis are few CASE tools, which help software organization in maintenance phase
of SDLC. For example, Bugzilla for defect tracking, HP Quality Center.
6. Software testing using testing tools.

Black box testing and white box testing:

What is Black Box Testing?

Crudely put, when the tester has no idea of the internal working of the system which he is
testing, that approach is called black box testing.

In this case, the system under test is viewed as a “black box”.

Requirements Document or Functional Specification Document forms the basis of this testing,
which requires the user to understand the processes within the software

How to write Test Cases for Black Box Testing?

 The tester examines requirements and specifications of the system.


 The tester explores the system’s UI and functionality to understand how the processes on the
system are expected to work.
 Tester designs test cases with valid inputs and the corresponding expected outputs.
 Tester also includes some negative test cases with invalid inputs and expected outputs (error
messages/program termination) as applicable
Techniques of Black Box Testing

In case of black box testing, inputs to the test cases are the driving factor. Any one of the three
techniques discussed below can be used to choose the inputs during the black box testing
process

 Boundary Value Analysis: This approach is focused on testing the boundary values
associated with the system. This approach aims at testing the boundaries of the input domain
that have the highest probability of giving erroneous outputs.
 Equivalence Class Partitioning: In this approach, a limited set of functions is identified
along with its corresponding valid and invalid inputs and expected outputs. This approach
aims at identifying classes of errors and therefore reducing the number of test cases required.
 Error Guessing: An experienced tester most often uses this approach to first identify the
defects and then develop corresponding test cases.

What is White Box Testing?

In white box testing methodology, the tester has the knowledge of the internals of a system
and knows how the system is implemented. The tester uses this knowledge to develop test
cases that will examine the control flow, information flow, data flow, exception and error
handling as well as coding practices of the system.

How to write Test Cases for White Box Testing?


 The tester analyzes and understands the structure of the system by examining its code.
 The tester understands the weak spots within the code that is most prone to defects.
 The tester develops test cases to cover individual data/information/ control flows and branches
within the code.
 The tester also develops test cases to test proper working of all the functionalities and error
handing of the system

Techniques of White Box Testing

When it comes to white box testing, the knowledge that the tester possesses about the system
is the driving factor, which helps the tester to devise test cases aimed at discovering defects
with the internal working of the system.

 Statement Tests: All the statements within the code must have a test case associated with it
such that each statement must be executed at least once during the testing cycle.
 Decision Tests: All the decision directions must be executed at least once during the testing
life cycle.
 Branch Condition Tests: All the conditions in a specific decision must be tested for proper
working at least once.
 Decision/Condition Tests: All the combination of the possible conditions within a specific
decision for all the decisions is to be tested.
 Data Flow Tests: This will ensure that all the variables and data that are used within the
system are tested by passing the specific variables through each possible calculation.
 Multiple Condition Tests: This will ensure that each point of entry within the code is tested
at least once during the testing life cycle.
7. CASE STUDY: study of software quality assurance (SQA) standards.

Software Quality Assurance (SQA) is the process of making sure that the software is
free from defects or mistakes and performs all the functionalities without complaints
just before the delivery.The SQA process talks about the evaluation of the software on
the basis of certain activities.
The Software Quality Assurance is measured based on the internal and external quality
features of the software. The external quality is measured based on the real-time
activities in operational mode and how the software is useful for the end users.
The internal quality is measured based on the style and quality of the code
written. Mostly the client will bother about the external quality only. But, in effect for a
perfect performance of the software, the internal quality is an important aspect to be
considered and maintained.

How to Determine the Software Quality Assurance?


The 2 approaches to determine the Software Quality Assurance are:

The Defect Management Approach


The defects are categorized on the basis of the severity. The counts of the defects are
taken and the actions are decided by analyzing the occurrence of defects. The defects
come from very minute issues and extend to the coding defects, the non-completion of
the requirements and of course if the application does not look good for the
customers. Defect management process is based on some principles:

 Preventing defect is the primary goal of defect management approach. But


preventing defects completely is not possible and so the purpose is to find out the
defects as early as possible and to minimize the impact of the defects.

 To prevent the defects some process should be altered.

 The defect measurement processes should be integrated into the software


development process, and thereby the process can be improved.

 Defect information always helps to improve the processes and hence the defect
information is very useful for perfect completion of the software developed.

The diagram below explains the various stages of the defect management approach.
The Software Quality Assurance Attribute Approach
There is a list of attributes which describes the step by step approach to obtain Software
Quality Assurance. The attributes are given as in the diagram below:

Functionality: The attributes considers the set of all the functions used in the software.

 Suitability: Ensures the functions of the software are appropriate.

 Accuracy: Ensures the accurate usage of the functions.


 Interoperability: Ensure the effective interaction of the software with other
components.

 Security: Ensure the software is capable of handling any security issues

Reliability: The purpose of the attribute is to check the capability of the system to
perform without delay during any conditions

 Maturity: Less possibility of failure of the software in any activities.

 Recoverability: The rate of recovery ability once a failure occurs.

Usability: The purpose is to ensure the use of a function

 Understandability: How much effort a user needs to understand the functions.

Efficiency: The attribute depends on the architecture used and the coding practices.
Maintainability: The way to analyze and fix a fault/issue in the software

 Analyzability: Finding out the cause of failure.

 Changeability: How the system response to necessary changes.

 Stability: How stable the system is when the changes made.

 Testability: Testing efforts

Adaptability: Ability of the system to adopt the changes in its environment.

ISO 9000

 In order to bring quality in product & service, many organizations are adopting
Quality Assurance System.
 ISO standards are issued by the international Organization for standardization in
Switzerland.
 Proper Documentation is an important part of an ISO 9001 Quality Management
System.
 ISO 9001 is the quality assurance standard that applies to software engineering.
 It includes, requirements that must be present for an effective quality assurance
system.
 ISO 9001 standard is applicable to all engineering discipline.
 The requirements delineated by ISO 9001:2000 address topic such as
 Management responsibility
 Quality system
 Contract review
 Design control
 Document
 Data control
 Product identification
 Traceability
 Process control
 Inspection
 Testing
 Preventive action
 Control of quality records
 Internal quality
 Audits
 Training
 Servicing
 Statistical techniques.
 In order for a software organization to become registered to ISO 9001:2000, it
must establish policies and procedures to address each of the requirements just
noted and then be able to demonstrate that these policies and procedures are
being followed.

Six sigma:

Six Sigma is a highly disciplined process that helps us focus on developing and delivering
near-perfect products and services.
Features of Six Sigma
 Six Sigma's aim is to eliminate waste and inefficiency, thereby increasing customer
satisfaction by delivering what the customer is expecting.
 Six Sigma follows a structured methodology, and has defined roles for the participants.
 Six Sigma is a data driven methodology, and requires accurate data collection for the
processes being analyzed.
 Six Sigma is about putting results on Financial Statements.
 Six Sigma is a business-driven, multi-dimensional structured approach for −
o Improving Processes
o Lowering Defects
o Reducing process variability
o Reducing costs
o Increasing customer satisfaction
o Increased profits
The word Sigma is a statistical term that measures how far a given process deviates from
perfection.
The central idea behind Six Sigma: If you can measure how many "defects" you have in a
process, you can systematically figure out how to eliminate them and get as close to "zero
defects" as possible and specifically it means a failure rate of 3.4 parts per million or
99.9997% perfect.
Key Concepts of Six Sigma
At its core, Six Sigma revolves around a few key concepts.
 Critical to Quality − Attributes most important to the customer.
 Defect − Failing to deliver what the customer wants.
 Process Capability − What your process can deliver.
 Variation − What the customer sees and feels.
 Stable Operations − Ensuring consistent, predictable processes to improve what the
customer sees and feels.
 Design for Six Sigma − Designing to meet customer needs and process capability.
Our Customers Feel the Variance, Not the Mean. So Six Sigma focuses first on reducing
process variation and then on improving the process capability.
8. Study of Business Process Reengineering

Reengineering:

 Business definition. Business goals are identified within the context of four key
drivers: cost reduction, time reduction, quality improvement, and personnel
development and empowerment.
 Process identification. Processes that are critical to achieving the goals defined in the
business definition are identified.
 Process evaluation. The existing process is thoroughly analyzed and measured.
 Process specification and design. Based on information obtained during the first three
BPR activities, use-cases are prepared for each process that is to be redesigned.
 Prototyping. A redesigned business process must be prototyped before it is fully
integrated into the business.
 Refinement and instantiation. Based on feedback from the prototype, the business
process is refined and then instantiated within a business system.

BPR Principles
 Organize around outcomes, not tasks.
 Have those who use the output of the process perform the process.
 Incorporate information processing work into the real work that produces the raw
information.
 Treat geographically dispersed resources as though they were centralized.
 Link parallel activities instead of integrated their results. When different
 Put the decision point where the work is performed, and build control into the process.
 Capture data once, at its source.

You might also like