Blood Donor Information and Management S

BLOOD DONOR INFORMATION
SYSTEM
M.N. Azeem Mohamed

FM 29022
KIT 26-13-01
Supervisor
Mr. Munshif
03rd.02.2015
PDIE/ MP
Declaration
I hereby declare that the project work entitled by under the guidance and Supervision of,
Mr. Munshif Cassim Bsc, Member of the Research center of the Bcas Kandy
Campus.
Mr. Mohamed Nuzrath Bsc, Senior Lecture of the Bcas Kandy Campus.
.
The Started time of the project,
20th September 2014, this project is submitted to Bcas Kandy Campus.

The Ending time of the project,
10th January 2015,
And these project are my own creativity and thinking, I have collected information from the
internet and some other books. I think this could be a good project according to my future
career.
This project work is submitted in the partial fulfillment of the requirements for the award of
the Advanced Diploma of Technology in Computer System. The results embodied in this
thesis have not been submitted to any other University or Institute for the award of any
degree or diploma.
MOHAMED NAZAR AZEEM MOHAMED
BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 1

PDIE/ MP
Acknowledgment
First of all I would like to express our heartful thanks to God for this opportunity, which he
rendered to us and gives the physical strength and pleasant mind to complete this project
work as success.
Then of all Ill thanks to Mr. Mohamed Niwas Director of the BCAS Kandy Campus. To give
this great opportunity to complete my HND Programme without any confusion. Then my
sincere gratitude to whole Administrative and IT Department of Bcas Kandy Campus for
their constant encouragements.
I also thanks to Mr. Mohamed Nuzrath, Senior Lecture of the Bcas Kandy Campus. He is
the only person give the idea and the fact about the system. And Sincere thanks to the
individuals that participated in my research Mr. Munshif Cassim. And he was helped to
develop my system as possible.
Who all encourage and satisfy my needs to finish this project work. I am very happy to thank
our Coordinator of the Bcas Kandy Campus, and other lectures giving a well-equipped for
developing this project work. I extent my thanks and gratitude my parents, Friends those
who helped me directly and indirectly for the successful completion of this project work.

PDIE/ MP
Table of Contents
1. Abstract 16
1.1. Content Summery .. 16
1.1.1. Scope .. 16
1.1.2. Schedule .. 16
1.1.3. Costs 16
2. Introduction 17 - 21
2.1. Project Background .. 17
2.1.1. Project Documentation . 17
2.1.2. Software Engineering Principles . 17
2.2. Motivation and Objective of the Project . 18
2.3. Scope of the Project . 19
2.4. Chapter Summery . 20
2.5. Software Tools and Overview . 21

2.5.1. Overview .... 21
2.5.2. Attributes for Comparing Process Model .. 21
2.5.3. Software Engineering Umbrella Activities . 21
2.5.4. Software Tools .. 21
3. Literature Review . 22 - 29
3.1.1. Abstract .. 22
3.1.2. Rationale of the Research .. 22
3.1.3. Systematic Literature Review Process . 23 - 24
3.1.3.1. Formal Definition 23
3.1.3.2. Motivation & Benefits .... 23
3.1.3.3. The Process 23 - 24
3.2. Project Development Principle .. 25 - 27

3.2.1. The Reason it All Exists .. 25
3.2.2. Keep It Simple, Stupid (KISS) 25
3.2.3. Maintain the Vision .. 25
3.2.4. What We Produce, Others Will Consume 26

PDIE/ MP
3.2.5. Be Open to the Future . 26
3.2.6. Plan Ahead for Reuse . 26
3.2.7. Think .. 27
3.3. Principle of Software Engineering . 27 - 29

3.3.1. Separating of Concerns .. 27
3.3.2. Modularity .. 28
3.3.3. Abstraction . 28
3.3.4. Anticipation of Change . 28
3.3.5. Generality 29
3.3.6. Incremental Development 29
3.3.7. Consistency 29
4. Analysis .. 30 - 46
4.1.1. Meaning of Analysis . 30
4.1.2. Importance of Analysis . 30
4.2. Similar System Studies 31 - 36

4.2.1. Similar System 1 ElDorado Donor System ... 31 - 32
4.2.1.1. Functional and Non-Functional Requirements .. 31
4.2.1.2. Help Ensure Donor and Patient Safety ... 31
4.2.1.3. Gain Fast Access to information .. 32
4.2.2. User Interface of the ElDorado ... 32 - 33
4.2.2.1. Description (Figure 4.1.1) .. 32
4.2.2.2. Description (Figure 4.1.2) .. 33
4.2.3. Similar System 2 Integrated Blood Donor System 35
4.2.3.1. Summary .. 35
4.2.3.2. Objective ... 35
4.2.3.3. Project Fact File 35
4.2.4. Similar System 3 Web Based Application . 36
4.2.4.1. Institution .. 36
4.2.4.2. Theme ... 36
4.2.4.3. Summary .. 36
4.2.4.4. Impact 36
4.2.4.5. Source ... 36
4.2.4.6. Project Home URL .. 36
4.3. Feasibility Studies . 37 - 40

4.3.1. Operational Feasibility . 39
4.3.2. Cultural or Political Feasibility . 39
4.3.3. Technical Feasibility . 39

PDIE/ MP
4.3.4. Schedule Feasibility . 40
4.3.5. Economic Feasibility . 40
4.3.6. Legal Feasibility . 40
4.4. Criteria for Project Success and Failure 41 - 42

4.4.1. Project Success Factors .. 41
4.4.1.1. User Involvement 41
4.4.1.2. Executive Management Support .. 41
4.4.1.3. Clear Statement of Requirements 41
4.4.1.4. Proper Planning .. 41
4.4.1.5. Clear Responsibility and Accountability .. 41
Of them members ... 41
4.4.2. Causes of Project Failure 42
4.4.2.1. Planning and Estimate Factor .. 42
4.4.2.2. Implementation Factor 42
4.4.2.3. Human Factor . 42
4.5. Resource Allocation Matrix ..... 43 - 44

4.5.1. Resources Need to Run the System . 43
4.5.1.1. Computer . 43
4.5.1.2. Dongle . 43
4.5.2. Hardware Requirements . 44
4.5.3. Operating System . 44
4.5.4. PC Specifications . 44
4.5.5. Server Specification for Enterprise Vision 44
4.6. Specification .. 45 - 46
4.6.1. Functional Requirements 45
4.6.1.1. Main Function of the System 45
4.6.1.2. Some Other Requirements ... 45
4.6.2. Non Functional Requirements . 46
5. Design . 47 - 62
5.1. Work Breakdown Structure and Task Allocation . 47 - 49
5.1.1. Purpose .. 47
5.1.2. Process ... 47
5.1.3. WBS Task Allocation 49
5.2. User Interface 50 - 55

5.2.1. What is Interface Design? ... 50
5.2.2. Principle of User Interface ... 50

PDIE/ MP
5.2.3. User Interface of Blood Donor Information System . 51 - 55
5.2.3.1. Splash Screen and Login Window 51
5.2.3.2. Main Window of the System .. 52
5.2.3.3. Some Main Windows and Functions .... 53 - 55
5.3. Context Diagram & Use Case Diagram . 56
5.4. Data Flow Diagram 57 - 61
5.5. ER Diagram . 61
5.6. Other Diagram 62
6. Method and Methodology 63 - 76

6.1. Model and Methodology Evaluation 63 - 69
6.2. Software Process Models 63 - 69

6.2.1. Waterfall Model .. 64 - 65
6.2.1.1. System Requirements . 64
6.2.1.2. Software Requirements .. 64
6.2.1.3. Architectural Design 65
6.2.1.4. Detailed Design 65
6.2.1.5. Coding ... 65
6.2.1.6. Testing ... 65
6.2.1.7. Maintenance . 65
6.2.1.8. Advantages of the Waterfall Model ... 65
6.2.1.9. Disadvantages of the Waterfall Model . 65
6.2.2. Iteration Model 66
6.2.3. V Shaped Model . 67

6.2.3.1. Advantages of the V Shaped Model ..... 67
6.2.3.2. Disadvantages of the V Shaped Model . 67
6.2.4. Spiral Model 68

6.2.4.1. Advantages of the Spiral Model 68
6.2.4.2. Disadvantages of the Spiral Model ...... 68
6.2.5. Extreme Model .. 69

6.2.5.1. XP and Agile Principle 69
6.2.5.2. Advantage of the XP .. 69

PDIE/ MP
6.2.5.3. Disadvantages of the XP 69
6.3. Selected Methodology 70

6.3.1. Waterfall Model 70
6.4. Procedures ... 71

6.4.1. Requirements .. 71
6.4.2. Analysis ..... 71
6.4.3. Design ... 71
6.4.4. Coding .. 71
6.4.5. Testing .. 71
6.4.6. Maintenance .... 71
6.5. Implementation .... 72 - 76

6.5.1. Requirements .. 72
6.5.2. Analysis . 72
6.5.3. Design .. 73
6.5.4. Coding ... 73
6.5.4.1. Example 1 Database Connection 74
6.5.4.2. Example 2 Clear the Text Fields . 74
6.5.5. Testing .. 75
6.5.5.1. Program Test 75
6.5.5.2. System Test .. 75
6.5.6. Implementation ... 75
6.5.7. Maintenance ... 76
7. Result and Discussion .. 77 - 78
8. Testing and Evaluation ... 79 - 105

8.1. Testing 79 - 98
8.1.1. Method of Testing . 79 - 81
8.1.1.1. Black Box Testing 79
8.1.1.2. White Box Testing .. 80
8.1.1.3. Gray Box testing . 80 - 81

PDIE/ MP
8.1.2. Test Cases 82 - 90

8.1.2.1. Test Case 1.1 . 82
8.1.2.2. Test Case 1.2 . 83
8.1.2.3. Test Case 1.3 . 84
8.1.2.4. Test Case 1.4 . 85
8.1.2.5. Test Case 1.5. 86
8.1.2.6. Test Case 1.6. 87
8.1.2.7. Test Case 1.7. 88
8.1.2.8. Test Case 1.8 . 89
8.1.2.9. Test Case 1.9 . 90
8.1.3. Evaluation of Actual and Expected Results . 91 - 98

8.1.3.1. Test the Actual Result of the Login
Of the users . 91
8.1.3.2. Test the Actual Result of the Login
Of the Donor Registration . 92
8.1.3.3. Error Correction (Table 8.1.3.2
Test No 3) 92
8.1.3.4. Test the Actual Result of the Donor
Maintaining . 93
Test No 1, 4) ... 93
8.1.3.6. Test the Actual Result of the Sending SMS .. 94
8.1.3.7. Error Correction (Table 8.1.3.4 and
Test No 1, 2) .. 94
8.1.3.8. Test the Actual Result of the Report View .... 95
8.1.3.9. Error Correction . 95
8.1.3.10. Test the Actual Result of Create Admin
And User . 96
Test No 2, 4, 5) .. 96
8.1.3.12. Test the Actual Result of Creating New
Events ..... 97
8.1.3.13. Error Correction (Table 8.1.3.7 and
Test No 1, 5) .. 97
8.1.3.14. Test the Actual Result of Search
Blood Donors . 98

PDIE/ MP
8.2. Project Performance Analysis .. 99 - 100

8.2.1. Budgeted Cost for Work Schedule (BCWS) .. 99
8.2.2. Budgeted Cost for Work Performed (BCWP) 100
8.2.3. Actual Cost for Work Performed (ACWP) .. 100
8.3. Change Control of Project 101 - 102

8.3.1. Change of Schedule .. 101
8.3.2. Change of Resource . 102
8.3.2.1. Skills Sets Need from the Resource improved 102
8.4. Suggestion, Recommendation and areas need to be improved 103 - 105

8.4.1. Software Process Improvement .. 103
8.4.2. Why Need of Software Process Improvement . 103
8.4.3. Principal Product Quality Factors ... 103
8.4.4. The Module Testing Activity 104
8.4.5. Suggestion for Improvement of Blood Donor System . 105
8.4.6. Object Oriented Programming Language . 105
8.4.7. Creating Nice Interface GUI 105
8.4.8. Separate the Classes into Packages 105
8.4.9. Centralization Database . 105
8.4.10. Use of New Tools 105
9. Support and Maintenance 106 - 129
9.1. Reason for Termination of Project 106

9.1.1. Reason for Project Termination 106
9.1.2. Person Responsible for Termination Decision ... 106
9.2. Client Certification ... 107 -108
9.3. Close Out Report .. 109 - 116

9.3.1. General Information 109
9.3.2. Project Deliverables ... 109
9.3.3. Performance Baseline .. 109
9.3.4. Cost (Budget) Baseline . 110
9.3.5. Schedule Baseline .. 111
9.3.6. Scope 112
9.3.7. Operation and Maintenance . 112 - 113
9.3.8. Project Resources .. 114
9.3.9. Project Documentation .. 115
9.3.10. Lesson Learned . 115
9.3.11. Dates for Post Implementation 116
9.3.12. Approvals 116

PDIE/ MP
9.4. User Manual . 117 - 129

9.4.1. How to Run the Application ... 117
9.4.2. How to Logging to the System .. 118
9.4.3. How to Register the Blood Donors ... 119
9.4.4. How to Delete the Blood Donors .. 120
9.4.5. How to Update the Details of a Blood Donor .. 121
9.4.6. How to Create New Event . 122
9.4.7. How to Maintain the Event 123
9.4.8. How to Send SMS to Blood Donors . 124
9.4.9. How to Search Blood Donors ... 125
9.4.10. How to Create Admin and User 126
9.4.11. How to Maintain Admin and User 127
9.4.12. How to View the Reports .. 128
9.4.13. How to Print the Reports .. 129
10. Summary and Conclusion .. 130
11. Reference . 131 - 134
11.1. System Development Principle 131

11.2. Similar System Studies . 132
11.3. Some Project Success Factors and Failure .. 132
11.4. Software Life Cycle 133
11.5. Testing Methods . 133
11.6. Others .. 134
12. Index . 135 - 136

PDIE/ MP
List of Figures
1. Figure 1.1 Systematic Literature Review Process Flowchart 24
2. Figure 4.1.1 ElDorado Management System Registration . 32
3. Figure 4.1.2 ElDorado Management System Blood Ordering 33
4. Figure 4.1.3 ElDorado Management System ER Diagram . 34
5. Figure 4.2.1 Feasibility Studies 1 37
8. Figure 4.4.1 GSM Network .. 43
9. Figure 5.2.1 Splash Screen of System .. 51
10. Figure 5.2.2 Login for Administrator .. 51
11. Figure 5.2.3 Main Window of System 52
12. Figure 5.2.4 Menu Strip Tool of the Main Window .. 52
13. Figure 5.2.5 Button with Icon .. 52
14. Figure 5.2.6 Blood Donor Registration Form 53
15. Figure 5.2.7 Maintaining Blood Donors . 53
16. Figure 5.2.8 Sending SMS to Donors 54
17. Figure 5.2.9 Create New Admin and User 54
18. Figure 5.2.10 Create New Events .. 55
19. Figure 5.2.11 Search Donors .. 55
20. Figure 6.1.1 Waterfall Model ... 64
21. Figure 6.1.2 Iteration Model . 66
22. Figure 6.1.3 V-Shaped Model . 67
23. Figure 6.1.4 Spiral Model . 68
24. Figure 6.1.5 Extreme XP Release Cycle ... 69
25. Figure 6.4.1 Sample User Manual . 76
26. Figure 8.4.1 Principle of Software Project Quality Factors 103
27. Figure 8.4.2 Module Testing Activity . 104
28. Figure 9.4.1 Run the Blood Donor Information System .. 117
29. Figure 9.4.2 Incorrect Username and Password . 118
30. Figure 9.4.3 Correct Username and Password 118
31. Figure 9.4.4 Donor Registration Window .. 119
32. Figure 9.4.5 Message Box of Donor Registration 119
33. Figure 9.4.6 Selecting the Donor ID .. 120
34. Figure 9.4.7 Delete the Current Blood Donor .. 120
35. Figure 9.4.8 Confirmation Message for Deleted . 120
36. Figure 9.4.9 Edit or Update Blood Donor Details 121
37. Figure 9.4.10 Edit the Blood Donor Details . 121
38. Figure 9.4.11 Create New Events . 122

PDIE/ MP
39. Figure 9.4.12 Table View of the Events ... 122
40. Figure 9.4.13 Edit the Event .. 123
41. Figure 9.4.14 Delete the Event . 123
42. Figure 9.4.15 SMS to the Donors .. 124

43. Figure 9.4.16 Confirmation of Sending SMS ... 124
44. Figure 9.4.17 Search Donors by Name 125
45. Figure 9.4.18 Searching Options .. 125
46. Figure 9.4.19 Search by City . 125
47. Figure 9.4.20 Create New Administrator .. 126
48. Figure 9.4.21 Create New User . 126
49. Figure 9.4.22 Delete the Current User . 127
50. Figure 9.4.23 Delete Confirmation of the Users . 127
51. Figure 9.4.24 Window of Reports .. 128
52. Figure 9.4.25 Detailed Report View of the Blood Donors .. 128
53. Figure 9.4.26 Click the Print in the Report 129
54. Figure 9.4.27 Print Properties Window . 129

PDIE/ MP
List of Tables
1. Table 4.3.1 Issues for Project Management Success 42
2. Table 4.4.1 PC Specification .. 44
3. Table 4.4.2 Server Specification 44
4. Table 5.5.1 WBS Task Matrix . 49
5. Table 8.1 SDLC Compliance Matrix . 77
6. Table 8.2 SDLC Compliance Matrix .. 78
7. Table 8.1.1.1 Advantages & Disadvantages of Black Box Testing .. 79
8. Table 8.1.1.2 Advantages & Disadvantages of White Box Testing .. 80
9. Table 8.1.1.3 Advantages & Disadvantages of Grey Box Testing 81
10. Table 8.1.1.4 Deferent Between Testing Methods . 81
11. Table 8.1.2.1 Test Case for Login Validation .. 82
12. Table 8.1.2.2 Test Case for Donor Registration . 83
13. Table 8.1.2.3 Test Case for Update Donor Details . 84
14. Table 8.1.2.4 Test Case for Delete Donor Details .. 85
15. Table 8.1.2.5 Test Case for Sending SMS .. 86
16. Table 8.1.2.6 Test Case for Report View . 87
17. Table 8.1.2.7 Test Case for Create Admin & User . 88
18. Table 8.1.2.8 Test Case for Creating New Event ... 89
19. Table 8.1.2.9 Test Case for Search Blood Donors .... 90
20. Table 8.1.3.1 Test Case for Login . 91
21. Table 8.1.3.2 Test Case for Donor Registration . 92
22. Table 8.1.3.2.1 Test Case for Donor Registration Error Correction . 92
23. Table 8.1.3.3 Test Case for Donor Maintaining . 93
24. Table 8.1.3.3.1 Test Case for Donor Maintaining Error Correction . 93
25. Table 8.1.3.4 Test Case for Sending SMS . 94
26. Table 8.1.3.4.1 Test Case for Sending SMS Error Correction . 94
27. Table 8.1.3.5 Test Case for Report View 95
28. Table 8.1.3.6 Test Case for Create Admin & User 96
29. Table 8.1.3.6.1 Test Case Create Admin & User Error Correction . 96
30. Table 8.1.3.7 Test Case for Creating New Events 97
31. Table 8.1.3.7.1 Test Case for Creating New Events Error Correction 97
32. Table 8.1.3.8 Test Case for Search Blood Donors 98
33. Table 8.2.1.1 Budgeted Cost for Work Schedule .................... 99
34. Table 8.2.2.1 Budgeted Cost for Work Performed................... 100
35. Table 8.3.1.1 Change of Schedule .. 101

PDIE/ MP
List of Acronyms
AC Actual Cost
ACWP Actual Cost of Work Performed
AD Activity Description
ADM Arrow Diagramming Method
ACML AMD Core Math Library
AMD Advanced Micro Devices
API Application Programming Interface
APPML AMD Accelerated Processing Math Libraries
APU Accelerated Processing Unit
BAC Budget at Completion
BCWP Budgeted Cost of Work Performed
BCWS Budgeted Cost of Work Scheduled
CentOS Community Enterprise Operating System
CVS Concurrent Versioning System / Concurrent Versions System
CVSQL Concurrent Versioning System Structured Query Language
COTS Commercial off the Shelf
CPU Central Processing Unit
COQ Cost of Quality
CPF Cost-Plus-Fee
CPFF Cost-Plus-Fixed-Fee
CPI Cost Performance Index
CPIF Cost-Plus-Incentive-Fee
CPM Critical Path Method
CPPC Cost-Plus-Percentage of Cost
CV Cost Variance

PDIE/ MP
CWBS Contract Work Breakdown Structure
DU Duration
DUR Duration
DMA Direct Memory Access
DSP Digital Signal Processing
EAC Estimate at Completion
EF Early Finish Date
EMV Expected Monetary Value
ES Early Start Date
ETC Estimate to Complete
EV Earned Value
FF Free Float
FFP Firm-Fixed-Price
JDBC Java Data Base Connectivity
LF Late Finish date
LOE Level of Effort
LS Late Start date
OS Operating System
PM Project Management
PMO Project Management Office
PMP Project Management Professional
RAM Random Access Memory
RAM Responsibility Assignment Matrix
RBS Resource Breakdown Structure
RBS Risk Breakdown Structure
SQL Structured Query Language (database query language)
SPM Software Process Model
SS Scheduled Start date
TAU Tuning and Analysis Utilities
WCNS Wroclaw Centre for Networking and Supercomputing

PDIE/ MP
WP Work Package
XML eXtensible Markup Language
Abstract
Blood Donor Information System is to create a Computerized Information about the donor
and Hospitals that are related to donating the blood. Through this System any person who is
interested in donating the blood can register himself in the same way, if any hospitals wants
to register itself with this System that can also register. And the purpose of my System is
registering blood donors, and maintain their details. Not only had those things, using my
system easily contact the donors in a critical or emergency situation. Because this system
giving more features to the clients or the hospitals or the blood camp groups.
And I have gathered some information in the internet and some ideas given by the project
supervisors. And this Project Document will cover each Stages of the System Development
Life Cycle (SDLF), and some other important objectives, scope, and motivation of the
project.
Computerized systems as compared to Paper record Systems are time consuming,
laborious, and costly. This paper introduces the review of the main features, merits and
demerits provided by the existing Computer-Based Information System for Blood Banks.
This study shows the comparison of various existing system and providing some more idea
about the computerized system.
1.1 Content Summary

Scope
This system is not only for business purpose. This can take for social services, because if
we are using this system for a hospital, it will be make easy to register the donors and
contact the donors in a emergency situation.
This system is standalone application, this system using local Database to store donors
details using GUI (Graphical user Interface). This system interface will have many function to
control easily
Schedule
The started date of the project was 20th September 2014 and continue for among 4 5
months to complete the project and project report successfully.
Costs
Hardware costs include the Leptop to create interfaces and programming. The USB Modem
used for contact blood donors sending SMS via GSM.
All additional costs have been development, Software and Programming time.

PDIE/ MP
Introduction
Blood is universally recognized as the most precious element that sustains life. It saves
innumerable lives across the world in a variety of conditions. A blood bank is a place
designed especially for the storage of blood and blood products. The term "blood bank"
typically refers to a division of a hospital laboratory where the storage of blood product
occurs and where proper testing is performed to reduce the risk of transfusion related
events. Large coolers hold these products at a constant temperature and they are available
at a moment's notice. The blood donor information system offers functionalities to quick
access to register the donor, and collected donor details from various parts of the Provinces.
It enables monitoring of the results and performance of the blood donation activity such that
relevant and measurable objectives of the organization can be checked. In my system Im
providing the efficient search who needs the blood in their own city, name, and blood groups
as fast as possible.
Blood Bank or the Hospital accept the donated blood, only if donor satisfy all of the following
conditions.
If the donors are between age group of 18-60 years.

If the donors weight is 45 kgs or more.
If the donors hemoglobin is 12.5 gm% minimum.
If the donors last blood donation was 6 or more months earlier. And etc.
2.1 Project Background

The Blood Donor information system is fully computerized system it makes easy to manage
the system by the administrator. And the beginning of this project is research. I mean
researching new things and identify the fact and knowledge about that, focus on the
following areas of study,
Project Documentation
Project Documentation or the Report will give the brief idea about the system which has
been developed by the developers. In the project documentation contain many facts, such
as software development life cycle and each stages, I mean explanation of each stages or
phase and etc.
Software Engineering Principles

Separation of Concerns
Modularity
Abstraction
Anticipation of Change
Generality
Incremental Development

PDIE/ MP
Consistency
Information Metrics
For get more details of software engineering principles, please visit to this site.
http://www.d.umn.edu/~gshute/softeng/principles.html
2.2 Motivation and Objectives of the Project

Goals and objectives are statements that describe what the project will accomplish.
Objectives are lower level statements that describe the specific, tangible products and
deliverables that the project will deliver. Objectives are concrete statements describing what
the project is trying to achieve. The objective should be written at a lower level, so that it can
be evaluated at the conclusion of a project to see whether it was achieved or not. Goal
statements are designed to be vague. Objectives should not be vague. A well-worded
objective will be Specific, Measurable, Attainable/Achievable, Realistic and Time-bound.
The Purpose of this system is if any critical or emergency situation it will be more useful to
save the lives. Because in this system there is a one method called sending SMS to the
registered donors. Using that function the system users or admin can send a SMS just
clicking one button.
And have some other purpose for using this system. Nowadays hackers and intruders are
very disturbance for any kind of system, such as Standalone or Web based Systems. So this
system is very secures rather than other systems. And the earlier days hospitals and blood
camps were used paper base recording system. Even though today also they all using
Paper recording system. What Im trying to say is paper records are not secures, because
any one can see the donors personal details without authorized permission, if any natural
disaster happened I mean flood or something happened then we cant sure papers are safe
in that place. And there are more and more disadvantages using paper records.
If we are using Computerized or Database record will be more secured. Anyone cannot see
or update the records without authorized permission. It will be more useful, and the blood
camp authorized people can handle these problems just simply. Because they all are the
people really going to be use this system. Some main objectives of this project,
To computerize all details regarding blood donor details & events details.
To automate the process of sending SMS selecting via district.
To maintain records effectively.
To manage current blood group of the donors and maintaining new events.
The project has information regarding the fresh blood donors, already registered
blood donor details, events, creating new events details and sending SMS to already
registered blood donors in the system.
Creating New Admin and Users for the System, only from admin privilege.
The valuable data can be keep as secure.
Creating new events to display about when next blood camp? , and where?

PDIE/ MP
2.3 Scope of the Project

Anyone who has ever done a project will have tales of how scope changes caused grief.
Scope is bound to change, and this is to be expected. As the detail becomes clearer, more
complications creep in. These are not foreseeable at the start and hopefully I build in a
contingency for what we cannot see. The scope changes that usually cause problems are
those where the perception of what was in and out of scope was different between various
parties.
The Scope of the project mean normally expecting the result of something. Scope is same
like the motivation and objectives. But there some more special in this case. Scope is really
expecting, as we take our system, we have to think why we are using computerized system
rather other paper base, and we have to think what purpose of that system.
Why we need computerized system, actually todays world we cant maintain or manage the
things without proper system or computer. Now computers are merge with our life. So the
computer based systems are very popular, and thats very secure rather than paper base
system. If we tell one example there were happened a flood disaster, and all the paper
based records can be Drench to the water. Then we cannot recover the important
information. These kind of situation we can recover the information by using computerized
system. Just remove the hard disk and recover the file easily
And security is high, because using computerized system is not allow to use any peoples
without their accounts or authorized permission. So the paper base is not like that, anyone
can see the information and they can do for that information whatever they want.
As my project also a computerized system called Blood Donor Information System. This
system can be used in the hospitals, blood donor camps, or any other important public
places, and etc.
Blood Donor Information System will be more use full for the important medical places,
because if someone need blood immediately, the system will help to identify the blood
donor, and it will be send a SMS to that donor. So it will be make a quick communication
with donors. As I told earlier the purpose of this system is send SMS to the donors in the
critical situation.
My initial thought is that this scope statement completely lacks any of the SMART goal
features. SMART stands for,
Specific
Measurable
Agreed Upon
Realistic
Time Bound

PDIE/ MP
2.4 Chapter Summery

1. Abstract
The abstract is a summary of the entire project or experiment.
2. Table of Contents
The table of contents lists the various sections of the report in logical order.
3. Introduction
The introduction presents the problem at hand. That is the purpose of analysis or
experiment.
Many times the introduction presents what others have done in the area of concern, what
has and has not worked well; references to previous work is appropriate in this section.
4. Theory/Literature Review
This section identifies the methodology upon which the analysis or experiment is based.
5. Discussion of Procedures or Methods Used

This section should briefly describe the approach taken.
6. Results Obtained and Analysis Performed

This section identifies the actual results obtained or analyses performed.
7. Summary /Conclusions /Recommendations

This section may be just the summary or just the conclusions or just the recommendations or
combinations thereof.
8. References
The references should be complete and follow Harvard formats.

PDIE/ MP
9. Appendices
The appendices may contain large sets of tabular data, detailed computer output results,
detailed procedures utilized, etc.
2.5 Software Tools and Overview

Overview
Develop high quality Software project.
A Software process provides a framework for managing activities that can very easily
get out of control.
Different types of function require different software processes.
The best indicators of how well a software process has worked are the quality,
timeliness, and long-term viability of the resulting software project.
Attributes for Comparing Process Model

Overall flow and level of interdependencies among tasks
Degree to which work tasks are defined within each framework activity
Degree to which work products are identified and required
Manner in which quality assurance activities are applied
Manner in which project tracking and control activities are applied.
Software Engineering Umbrella Activities

Software project tracking and control (allows team to assess progress and take
corrective action to maintain schedule)
Risk management (assess risks that may affect project outcomes or quality)
Software quality assurance (activities required to maintain software quality)
Formal technical reviews (assess engineering work products to uncover and remove
errors before they propagate to next activity)
Measurement (define and collect process, project, and product measures to assist
the software in delivering software meeting customer needs)
Software configuration management (manage effects of change)
Software Tools
Visual Studio 2010
- Introduced by Microsoft Corporation.
- Help to Develop Software and Systems according to the requirements.
Microsoft Word 2013
- Help to create reports and documents
Edraw Max 6
- Introduced by Edraw Soft Pvt.Ltd.
- Help to draw the software related diagrams.
Microsoft SQL Server 2008
- Used to manage the data called database management system (DBMS).
Adobe Photoshop

PDIE/ MP
- Introduced by Adobe.
- Help to create nice artistic, and editing works.
Web Browser (Google Chrome, Opera Mini)
- I have used Google Chrome and Opera Mini to browse the facts in the internet.
Literature Review
Abstract
It is observed that in recent years small and medium Software companies have emerged
very rapidly and thousands of such companies are in existence all over the globe. To cater
the needs of such companies, a new field of research was created Software Engineering,
given than Web engineering differs from traditional software engineering in numerous ways,
which include the need of agile process models, extended modelling techniques (WebML),
Navigational development techniques, different architectures and rapid application process
along with different testing techniques.
It has been observed that Software process improvement emerges as one of the biggest
challenges for such companies. A systematic literature review (SLR) has been conducted to
identify and discuss the existing models and techniques used by small and medium
companies. Important phases of our SLR included identification of the research questions to
be investigated, primary and secondary database searches to identify relevant literature,
data extraction from selected studies, data synthesis to formulate answers, and formal
discussion to identify trends and research gaps.
Rationale of the Research

Software processes play an important role in helping project teams in software development
organizations and them use similar and software practices. Ideally, these processes should
combine the need for rigor and discipline with the need for flexibility and creativity, but that
balance is hard to achieve. Formal processes emphasize the explicit command-and-control
side of the organization due to their concrete nature, while informal team practices
emphasize the mutual adjustment and explorations needed to accomplish tasks
successfully.
Many researchers are focusing their attention to define the process and its relation to the
quality of the project. While this remains important, many researchers are exploring the
success factors and people issues that inherently play major roles in the adoption of new
processes by software organizations.
I have also focused some important facts, to finish my project successfully. Projects need a
quality to make success, so I have completed my project in a quality way.
The fact that the engineering of Stand-alone applications differs from the engineering of web
applications motivated this work. As previously illustrated, many development methodologies
and techniques were proposed specifically to tackle issues associated with Stand-alone
applications development and project management. Therefore SPI for small and medium
Stand-alone enterprises also seemed a relevant research topic to be investigated, which is
the objective of this systematic literature review and automatically also the objective of this
research. I focus explicitly on Software companies, which are characterized by companies
that only provide Software solution services such as Software application development.

PDIE/ MP
The above mentioned studies and facts laid the foundation of our investigation. I observed
different approaches for the various artefacts of engineering Software.
Therefore, the purpose of this systematic review (SR) is to gather evidence about process
improvement initiatives observed for Software companies
Systematic Literature Review Process

Formal Definition
A systematic literature review (often referred to as a systematic review) is a means of
identifying, evaluating and interpreting all available research relevant to a particular research
question, or topic area, or phenomenon of interest.
Motivation & Benefits

Systematic reviews are used to gain effective insight into a problem and understand existing
approaches. The main benefits that can be obtained by performing a Systematic reviews are
as follows,
Identification of the particular research questions to be investigated by some Doctors

to make successful application.
Identification of the desired population, intervention, context and outcomes.
Helps in summarizing the existing research evidence.
Lays a foundation for a disciplined search mechanism.
Provides a case to assess the quality of studies.
Helps in producing unbiased empirically validated results.
Provides a mechanism to synthesize the research evidence.
Make easy to register the blood donors.
And easily maintain by the admin.
The Process
SR is a detailed process divided into different tasks and activities that are listed as follows:
Systematic Literature Review Study and Understanding This Phase helps in
developing and understanding of review concepts and to develop an understanding of the
overall methodology.
Formulation of Research Questions This is an iterative phase where the important
research questions to be investigated during the SR are identified.
Development of a Study Protocol This phase is very rigorous and also iterative. It covers
the overall plan for the systematic literature review
Identification of Relevant Literature This phase encompasses the identification of
primary and secondary studies and is a search phase.
Determining Inclusion & Exclusion Criteria During this phase a criteria is applied to
select the studies for to be part of the SR. If a study fulfils the inclusion criteria it is selected
otherwise it is discarded.

PDIE/ MP
Selection of Studies This phase includes both primary and secondary studies. The
studies are selected after the application of the inclusion criteria and are further filtered.
Study Quality Assessment Both qualitative and quantitative studies are assessed for
quality in this phase based on the developed checklists and appropriate scores are assigned
to each study.
Data Extraction Data are extracted from each study and based on the research
questions.
Data Synthesis After extraction the data is aggregated, integrated and summarized for the
further clarity and to answer the research questions.
Report Write Up A very important concluding phase that details and summarizes the
results and findings of the overall systematic literature review process comes at last. All
previous phases contributed to it.

PDIE/ MP
Figure 1.1 is showing the SR phases in depth using flowchart,
Figure 1.1 Systematic Literature Review Process Flowchart
Figure Source - http://effectivehealthcare.ahrq.gov/index.cfm/search-for-guides-reviews-and-

reports/?productid=1669&pageaction=displayproduct
3.1 Project Development Principles

What does it take to ensure a successful software development project? If we follow one or
two basic will that be enough to guarantee a responsive, reliable product developed within
schedule and budget? Or do you need dozens of checklists with dozens of items in each?
We have seven basic principles of Software Development. Such as,
1. The Reason It All Exists

PDIE/ MP
2. Keep It Simple, Stupid (KISS)
3. Maintain the Vision
4. What We Produce, Others Will Consume
5. Be Open to the Future
6. Plan Ahead for Reuse
7. Think
The Reason It All Exists

A software system exists for one reason: to provide value to its users. All decisions should
be made with this in mind. Before specifying a system requirement, before noting a piece of
system functionality, before determining the hardware platforms or development processes,
ask yourself questions such as: "Does this add real VALUE to the system?" If the answer is
"no", don't do it. All other principles support this one.
Keep It Simple, Stupid (KISS)

Software design is not a haphazard process. There are many factors to consider in any
design effort. All design should be as simple as possible, but no simpler. This facilitates
having a more easily understood, and easily maintained system. This is not to say that
features, even internal features, should be discarded in the name of simplicity. Indeed, the
more elegant designs are usually the more simple ones. Simple also does not mean "quick
and dirty." In fact, it often takes a lot of thought and work over multiple iterations to simplify.
The payoff is software that is more maintainable and less error-prone.
Maintain the Vision

A clear vision is essential to the success of a software project. Without one, a project almost
unfailingly ends up being "of two or more minds" about itself. Without conceptual integrity, a
system threatens to become a patchwork of incompatible designs, held together by the
wrong kind of screws. As Brooks states,
Having a clean internal structure is essential to constructing a system that is understandable,
can be extended and reorganized, and is maintainable and testable.
It is only through having a clear sense of a system s architecture that it becomes possible to
discover common abstractions and mechanisms. Exploiting this commonality ultimately
leads to systems that are simpler, and therefore smaller and more reliable.
Compromising the architectural vision of a software system weakens and will eventually
break even the most well designed systems. Having an empowered Architect who can hold
the vision and enforce compliance helps ensure a very successful software project.
What We Produce, Others Will Consume

In some way or other, someone else will use, maintain, document, or otherwise depend on
being able to understand your system. So, always specify, design, and implement knowing
someone else will have to understand what we are doing. The audience for any product of
software development is potentially large. Specify with an eye to the users. Design, keeping
the implementers in mind. Code with concern for those that must maintain and extend the

PDIE/ MP
system. Someone may have to debug the code we write, and that makes them a user of our
code. Making their job easier adds value to the system.
Be Open to the Future

A system with a long lifetime has more value. In today's computing environments, where
specifications change on a moment's notice and hardware platforms are obsolete when just
a few months old, software lifetimes are typically measured in months instead of years.
However, true "industrial-strength" software systems must endure far longer. To do this
successfully, these systems must be ready to adapt to these and other changes. Systems
that do this successfully are those that have been designed this way from the start. Never
design ourselves into a corner. Always ask "what if ", and prepare for all possible answers by
creating systems that solve the general problem, not just the specific one. This could very
possibly lead to the reuse of an entire system.
Abusing this principle is where I see many developers go wrong. One of the benefits of
having both years of experience and many of them on a single project is that we learn As
developers, we often guess wrong on how a system is going to change unless we are also
domain experts. Further, systems do change but often converge so the generalized solution
becomes baggage.
Plan Ahead for Reuse

Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest goal to
accomplish in developing a software system. The reuse of code and designs has been
proclaimed as a major benefit of using object-oriented technologies. However, the return on
this investment is not automatic. To leverage the reuse possibilities that OO programming
provides requires forethought and planning. There are many techniques to realize reuse at
every level of the system development process. Those at the detailed design and code level
are well known and documented. New literature is addressing the reuse of design in the form
of software patterns. However, this is just part of the battle. Communicating opportunities for
reuse to others in the organization is paramount. How can you reuse something that we
don't know exists? Planning ahead for reuse reduces the cost and increases the value of
both the reusable components and the systems into which they are incorporated.
Think
This last Principle is probably the most overlooked. Placing clear, complete thought before
action almost always produces better results. When we think about something, we are more
likely to do it right. We also gain knowledge about how to do it right again. If we do think
about something and still do it wrong, it becomes valuable experience. A side effect of
thinking is learning to recognize when we don t know something, at which point we can

PDIE/ MP
research the answer. When clear thought has gone into a system, value comes out.
Applying the first six Principles requires intense thought, for which the potential rewards are
enormous.
3.2 Principles of Software Engineering

Number of basic principles which provide the keys to a successful software effort. Through
this experience, I have found that one or two such principles are insufficient to guarantee
such a successful outcome. It now appears that at least seven basic principles are involved.
These are,
1. Separation of Concerns
2. Modularity
3. Abstraction
4. Anticipation of Change
5. Generality
6. Incremental Development
7. Consistency
Separation of Concerns
Separation of concerns is a recognition of the need for human beings to work within a limited
context. Although human capacity for forming abstractions appears to be unlimited, it takes
time and repetitive use for an abstraction to become a useful tool. When specifying the
behavior of a data structure component, there are often two concerns that need to be dealt
with basic functionality and support for data integrity. A data structure component is often
easier to use if these two concerns are divided as much as possible into separate sets of
client functions. It is certainly helpful to clients if the client documentation treats the two
concerns separately. Further, implementation documentation and algorithm descriptions can
profit from separate treatment of basic algorithms and modifications for data integrity and
exception handling.
There is another reason for the importance of separation of concerns. Software engineers
must deal with complex values in attempting to optimize the quality of a project. From the
study of algorithmic complexity, we can learn an important lesson. There are often efficient
algorithms for optimizing a single measurable quantity, but problems requiring optimization
of a combination of quantities are almost always complete. Although it is not a proven fact,
most experts in complexity theory believe that complete problems cannot be solved by
algorithms that run in polynomial time.
Modularity
The principle of modularity is a specialization of the principle of separation of concerns.
Following the principle of modularity implies separating software into components according
to functionality and responsibility.

PDIE/ MP
Abstraction
The principle of abstraction is another specialization of the principle of separation of
concerns. Following the principle of abstraction implies separating the behavior of software
components from their implementation. It requires learning to look at software and software
components from two points of view, what it does, and how it does it.
Failure to separate behavior from implementation is a common cause of unnecessary
coupling. For example, it is common in recursive algorithms to introduce extra parameters to
make the recursion work. When this is done, the recursion should be called through a non-
recursive shell that provides the proper initial values for the extra parameters. Otherwise, the
caller must deal with a more complex behavior that requires specifying the extra parameters.
If the implementation is later converted to a non-recursive algorithm then the client code will
also need to be changed.
Anticipation of Change
Computer software is an automated solution to a problem. The problem arises in some
context, or domain that is familiar to the users of the software. The domain defines the types
of data that the users need to work with and relationships between the types of data.
Software developers, on the other hand, are familiar with a technology that deals with data in
an abstract way. They deal with structures and algorithms without regard for the meaning or
importance of the data that is involved. A software developer can think in terms of graphs
and graph algorithms without attaching concrete meaning to vertices and edges. Working
out an automated solution to a problem is thus a learning experience for both software
developers and their clients. Software developers are learning the domain that the clients
work in. They are also learning the values of the client. What form of data presentation is
most useful to the client, what kinds of data are crucial and require special protective
measures? The clients are learning to see the range of possible solutions that software
technology can provide. They are also learning to evaluate the possible solutions with regard
to their effectiveness in meeting the clients needs.
If the problem to be solved is complex then it is not reasonable to assume that the best
solution will be worked out in a short period of time. The clients do, however, want a timely
solution. In most cases, they are not willing to wait until the perfect solution is worked out.
They want a reasonable solution soon; perfection can come later. To develop a timely
solution, software developers need to know the requirements: how the software should
behave. The principle of anticipation of change recognizes the complexity of the learning
process for both software developers and their clients. Preliminary requirements need to be
worked out early, but it should be possible to make changes in the requirements as learning
progresses.
Generality
The principle of generality is closely related to the principle of anticipation of change. It is
important in designing software that is free from unnatural restrictions and limitations. One
excellent example of an unnatural restriction or limitation is the use of two digit year
numbers, which has led to the "year 2000" problem, software that will garble record keeping
at the turn of the century. Although the two-digit limitation appeared reasonable at the time,
good software frequently survives beyond its expected lifetime.

PDIE/ MP
For another example where the principle of generality applies, consider a customer who is
converting business practices into automated software. They are often trying to satisfy
general needs, but they understand and present their needs in terms of their current
practices. As they become more familiar with the possibilities of automated solutions, they
begin seeing what they need, rather than what they are currently doing to satisfy those
needs. This distinction is similar to the distinction in the principle of abstraction, but its effects
are felt earlier in the software development process.
Incremental Development
Description of an incremental software development process. In this process, we build the
software in small increments, for example, adding one use case at a time.
An incremental software development process simplifies verification. If we develop software
by adding small increments of functionality then, for verification, we only need to deal with
the added portion. If there are any errors detected then they are already partly isolated so
they are much easier to correct.
A carefully planned incremental development process can also ease the handling of
changes in requirements. To do this, the planning must identify use cases that are most
likely to be changed and put them towards the end of the development process.
Consistency
The principle of consistency is a recognition of the fact that it is easier to do things in a
familiar context. For example, coding style is a consistent manner of laying out code text.
This serves two purposes. First, it makes reading the code easier. Second, it allows
programmers to automate part of the skills required in code entry, freeing the programmer's
mind to deal with more important issues
Consistency serves two purposes in designing graphical user interfaces. First, a consistent
look and feel makes it easier for users to learn to use software. Once the basic elements of
dealing with an interface are learned, they do not have to be relearned for a different
software application. Second, a consistent user interface promotes reuse of the interface
components. Graphical user interface systems have a collection of frames, panes, and other
view components that support the common look. They also have a collection of controllers
for responding to user input, supporting the common feel. Often, both look and feel are
combined, as in pop-up menus and buttons. These components can be used by any
program.
Analysis
One of important phase of Software development life cycle is Analysis. So its really
important for any kind of software project. Even Im also spend many days to analysis for my
project called blood donor information system.
Analysis part is beginning of any software project, so this is summarizing all the feasibly
studies, functional and non-function requirements.

PDIE/ MP
So will see what analysis is and why its important for software project or any other project.
Meaning of Analysis
In a broad sense, a general methodology (not a fixed set of techniques) that applies a
'systems' or 'holistic' perspective by taking all aspects of the situation into account, and by
concentrating on the interactions between its different elements. It provides a framework in
which judgments of the experts in different fields can be combined to determine what must
be done, and what is the best way to accomplish it in light of current and future needs.
Although closely associated with data or information processing, the practice of SA has been
in existence since long before computers were invented.
In a narrow sense, analysis of the current and future roles of proposed computer system in
an organization, the system analyst (usually a software engineer or programmer) examines
the flow of documents, information, and material to design a system that best meets the
cost, performance, and scheduling objectives.
Important of Analysis
Problem identification, definition and capture The requirement analyst should
identify the problem along with the system define it accurately. The requirement
definition should be able to provide information on -
o The problems the solution is aimed to solve
o The benefits expected from the solution
The feasibility of the requirements
High Level Description of solution The solution planned to be developed should be
described at a high level along with the system needs it caters to.
Address the needs of all the clients and the users This is a very important part of
the requirement analysis and a step which needs to be meticulously followed before
freezing the requirements. This would help in the deployment phase of the project
too, by getting the users adaptable to the new process or application.
Feature definition The applications planned features need to be captured at length.
The functional and non-functional requirements need to be captured in detail along
with the details on how the project is going to be executed etc.
4.1 Similar System Studies

Before designing a system, we have to refer some existing similar systems and familiarize
with their plus and minus. We have to arrange some time studying the similar systems and it
is effectively used in this design.
We have to think there manual system in the hospitals or any other blood camps. Some
methods related to marks calculation were also studied and gained knowledge by
interviewing relevant officers in the division and administrative department. These methods

PDIE/ MP
were very useful while designing this system. All the necessary reports generated by the
division and administrative department were also referred and used them in report
generating activities of the project.
To design application client, some similar systems with login facility which were installed in
the internet cafes and communication stores, were studied to get some idea about designing
information system with a login. Some ideas of designing user interface were also gained
from these systems.
Similar System 1 - ElDorado Donor Blood Management System

I have studied the ElDorado Donor Blood Management System based on standalone
application. So I have gathered some more information about that. And this is java based
application, I mean the programming language is java.
ElDorado Donor is them blood management software system designed by blood bankers
to help blood centers manage their blood collection safely, maintain compliance, and
improve efficiency. This system was developed to support the integrated data processing
requirements of both small and large centers and complex organizations. The ElDorado
Donor systems modular configuration provides maximum flexibility to meet them system-
specific requirements.
So this system is mainly use for record the blood donors details, and maintain those details
in a manner. There are some requirements and benefits are there about this blood bank
system.
Functional and Non-Functional Requirements

Three users can access to the system with proper username and password.
Login function to access to the system.
Order the Bloods using the system easily.
Blood Donors Details can be printed by the system in full details.
Registration of the blood donors.
Help Ensure Donor and Patient Safety

Calculate and track blood loss based on site-defined eligibility criteria
Post deferrals for tests, medication, and travel automatically
Perform system safety checks prior to labeling and release
Create customizable warning and error messages to help prevent errors
Gain Fast Access to Information

Improve traceability by tracking component license status from collection to release
Streamline navigation and workflow with an easy-to-use interface
View donor and component data using the *Patient-at-a-Glance Bar
User Interface of the ElDorado Donor Blood Management System

PDIE/ MP
Figure 4.1.1 ElDorado Donor Blood Management System Donor Registration
Figure Source -
http://www.haemonetics.com/Products/Software/Blood%20Center/ElDorado%20Donor.aspx
Description (Figure 4.1.1)

Figure showing the registration form of the ElDorado blood management system. There are
many text fields and more space to fill by the user or the administrator of this system. And
there is advanced function, upload photograph. Mean take picture of the donor while filling
the registration form, and upload in to the database.
Most of the text fields are validated, without completing or without proper reference cant
save or store any data in to the database.

PDIE/ MP
Figure 4.1.2 ElDorado Donor Blood Management System Blood Ordering
Figure Source -
http://www.haemonetics.com/Products/Software/Blood%20Center/ElDorado%20Donor.aspx
Description (Figure 4.1.2)

This figure of window is showing the ordering bloods by selecting the donor id and donor
name. Here the administrator or user can order the bloods for other patient. This make easy
way to connect other hospitals or other blood camps by using local area network connection.
And here the administrator or user can print the order details. Mean how long the system is
running, and what type blood ordered, who are ordering, where, when those details are
easily retrieve from the database.

PDIE/ MP
Database is one of important for any kind of computer base system. So we need to design a
database for a system. Likewise here ElDorado blood management system have database
fields. So first they must need design of it.
Figure 4.1.3 ElDorado Donor Blood Management System ER Diagram
Figure Source - http://lbsitbytes2010.files.wordpress.com/2013/09/finalerd.jpg
Also called an entity-relationship (ER) diagram, a graphical representation of entities and

their relationships to each other, typically used in computing in regard to the organization of
data within databases or information systems. An entity is a piece of data-an object or
concept about which data is stored.
ER Diagram will give a brief and stating idea about the database. Before start to create a
database we must know to design an ER Diagram to make easy. Entity Relation Diagram -
giving you image of how the tables should connect, what fields are going to be on each
table, the tables connection, if many-to-many, one-to-many.

PDIE/ MP
Similar System 2 - Integrated Blood Donor Data Base Management

System
Summary
This project started in July 2008 and will develop and implement a computer based Blood
Donor Tracking System. This system is developed for the staff of the Zambian Blood
Transfusion Services (ZBTS) and will reduce the risks of incorrectly identifying donors and
blood units. Repeat donors can effectively be tracked and a reliable pool of regular repeat
blood donors is established. It ensures blood safety through accurate labelling and
identification of blood units at every stage. The database will be developed with open source
software (software without license costs). More than 17,000 blood donators and patients in
need of a blood transfusion benefit from the Blood Donor Tracking System.
Objectives
To develop and maintain an appropriate integrated blood donor tracing database
system for the efficient and effective recording and management of blood donor data
and blood donor retention
To improve the quality of recording and management of information about blood
donors. This facilitates the effective tracking of repeat blood donors and the
establishment of a reliable pool of regular repeat blood donors
To improve the accuracy, efficiency and effectiveness of tracking information on
blood donations, from Vein to Vein and ensure blood safety through accurate
labelling and identification of blood units at every stage
To ensure sustainability through capacity building, staff skills training and the
integration of the project into the plan and operations of Zambian Blood Transfusion
Services (ZBTS)
Project fact file

Country: Zambia
Sector: Health
Type: on the ground project
Status: implementation
Start date: June 2008
Project owner: Zambia National Blood Transfusion Service (ZNBTS)
Beneficiary: Staff of ZBTS and blood donors
ICT tools: Database, Open Source
Contact: information@iicd.org
More Details of this System please visit: - http://www.iicd.org/projects/zambia-znbts

PDIE/ MP
Similar System 3 - Web-based Blood Bank Management System
Institution
Department of Health and Family Welfare, Government of Delhi
Theme
Knowledge Management in Government, Internet Governance
Implementation Date: Oct 08, 2005
Summary
The Web-based Blood Bank Management System of the Department of Health and
Family Welfare provides the stock of blood for different groups in the various blood
banks as well as online registration to people who are willing to donate blood. The
details of blood donation camps are also available in the system.
The Blood Bank Management System software features, among other things, donor
registration and blood collection; red cell serology; an infectious marker system;
stock maintenance (whole blood/component); transfer of stock of whole blood
(unscreened location to screened location); rejection accounting; discard accounting;
record of the staff; details on blood donation camps; inventory record; and user
access control.
Impact
Through the Web-based Blood Bank Management System, the entire process of
submitting the online registration form is simple and citizens can register online from
home.
The Department of Health and Family Welfare can collect information regarding
various blood groups. Citizens receive information about the next blood donation
camp via post or e-mail after registration as a result of the listings with respect to
various blood groups.
Source
Government of Delhi
Project Home URL

http://www.bloodbanksdelhi.com/

PDIE/ MP
4.2 Feasibility Studies

Normally feasibility study mean, evaluation and analysis of the potential of a proposed
project which is based on extensive investigation and research to support the process of
decision making. First we have to make plane about our project, such we have to allocate a
budget and fix that, who are worker or employees we need to complete our project to make
success. There are many reason to do a feasibility study for a project.
Gives focus to the project and outline alternatives.
Narrows business alternatives
Identifies new opportunities through the investigative process.
Identifies reasons not to proceed.
Enhances the probability of success by addressing and mitigating factors early on
that could affect the project.
Provides quality information for decision making.
Provides documentation that the business venture was thoroughly investigated.
Helps in securing funding from lending institutions and other monetary sources.
Helps to attract equity investment.
So these are some reason to understand how feasibility is important for any kind of projects.
As well as for my project even got some feasibility method, I mean I have plan the budget
and the time period of the project, and schedule the tasks.
A typical feasibility study will take the form of the following diagram,
Figure 4.2.1 Feasibility Studies 1
Figure Source - http://www.prince2primer.com/feasibility-study-and-tailoring-prince2
Because of the range of options and the uncertainty of which would be recommended, then
embedding a feasibility study within the delivery project would give rise to many problems.
For example, each option would require a different project plan for my blood donor
information system, and it would be difficult to create the project initiation documentation
without knowing which option would be chosen.
For this reason, current wisdom suggests that a feasibility study being conducted as a
standalone project, with the project implement as the final report itself. This would then be
used by corporate or programme management to act as a mandate to implement the project
that would implement the feasibility recommendations,

PDIE/ MP
The implementing a project, like any project that would be based on a System. Blood donor
information system as would the feasibility study itself. By definition, every project that uses
the important methodology must be used in some way.
If we take any project can range from short, small, simple and low risk, to long, large,
complex and high risk. As my project event got those issues, however due to the nature of a
feasibility study, it is possible to suggest various approaches when developing the system.
More formal and complex feasibility studies, it may be best to run the project in four
management stages,
Feasibility can be viewed from multiple perspectives. Below present six categories of
feasibility tests.
Operational Feasibility is measure of how well a solution meets the identified the
system requirements to solve the problems and take advantage of the opportunities
envisioned for the system.
Cultural or Political Feasibility is a measure of how people fell about a solution and
how well it will be accepted in a given organizational climate.
Technical Feasibility is a measure of the practicality of a specific technical solution

and the availability of technical resources and expertise to implement and maintain it.
Schedule Feasibility is a measure of how reasonable the project timetable is.
Economic Feasibility is a measure of the cost effectiveness of a project or solution.
Legal Feasibility is a measure of how well a solution can be implemented within

existing legal and contractual obligations.

PDIE/ MP
Operational Feasibility
Operational feasibility is the measure of how well a proposed system solves the problems
and the task of the project advantage of the opportunities identified during the scope
definition and problem analysis phases and how well it satisfies the system requirements
identified in the requirements analysis phase. Operational feasibility also asks if, given what
is now known about the problem and the cost of the solution, the problem is still worth
solving.
Cultural or Political Feasibility

This is related to operational feasibility. But where operational feasibility deals more with how
well the solution will meet system requirements, cultural or political feasibility deals with how
the end users feel about the proposed system. You could say the operational feasibility
evaluates whether a system can work, and cultural or political feasibility asks whether a
system will work in a given organizational climate.
In an information age knowledge is power. It is common for an information system to change
the structure of how information is routed and controlled, changing to some extent the power
structure of the organization.
Technical Feasibility
Today very little is technically impossible. Consequently, technical feasibility looks at what is
practical and reasonable. Technical feasibility addresses three major issues,
1. Is the proposed technology or solution practical?
2. Do we currently possess the necessary technology?
3. Do we possess the necessary technical expertise?
Is the proposed technology or solution practical?

The technology for any defined solution is normally available. The question is whether that
technology is mature enough to be easily applied to our problems. A mature technology has
a larger customer base for obtaining advice concerning problems and improvements.
Do we currently possess the necessary technology?
Assuming the solutions required technology is practical, we must next ask ourselves, is the
technology available in our blood donor information system? If the technology is available,
we must ask if we have the capacity. If we cant afford the technology, then the alternative
that requires the technology is not practical and is technically infeasible.
Do we possess the necessary technical expertise?
This consideration of technical feasibility is often forgotten during feasibility analysis. For
instance, a system should need database management system (DBMS). However, the
analysts and programmers available for the project may not know that DBMS well enough to
properly need to apply.

PDIE/ MP
Schedule Feasibility
Given the available technical expertise, are the project deadlines reasonable that is, what is
the schedule feasibility of the project? Some projects are initiated with specific deadlines. It
is necessary to determine whether the deadlines are mandatory or desirable. For instance, a
project to develop a system to meet the customer requirements.
If the deadlines are desirable rather than mandatory, the analyst can propose alternative
schedules. It is preferable to deliver a properly functioning information system late deliver
unless information system on time.
Economic Feasibility
The bottom line in many projects is economic feasibility. During the early phases of the
project, economic feasibility analysis amount too little more than judging whether the
possible benefits of solving the problem are worthwhile. Costs are practically impossible to
estimate at that stage because the end users requirements and alternative technical
solutions have not been identified. However, as soon as specific requirements and solutions
have been identified, the analyst can weigh the costs and benefits of each alternative. This is
called a cost benefit analysis.
Legal Feasibility
Information system have a legal impact. First of all, there are copyright restrictions. For any
system that includes purchased components, one has to make sure that the license
agreements are not violated. For one things this means installing only licensed copies. But
license agreements and copy protection can also restrict how you integrate the data and
processes with other parts of the system. If you are working with contract programmers, the
ownership of the program source code and nondisclosure agreements have to be worked
out in advance.
Union contracts can add constrains to the information system on how workers are paid and
how their work is monitored. Legal requirements for financial reporting must be met. System
requirements for sharing data with partners could even run up against antitrust laws. Finally,
many information systems today are international in scope. Some countries mandate where
data on local employees and local transactions must be stored and processed. Countries
differ on the number of hours that make up a workweek or how long employees break for
lunch.

PDIE/ MP
4.3 Criteria for Project Success and Failure

Often, software managers have to monitor and manage many projects concurrently.
Unfortunately, some projects were completed successfully but somewhere not completed on
time, over budget or being cancelled. Some of the reasons of this project failure are, lack of
user involvement, lack of planning, incomplete requirements, lack of resources, incorrect
cost estimation, just to name a few. There are many project planning and scheduling
techniques to manage and help to ensure project success. Some of these techniques,
however, may not be suitable for specific types of projects and thus, cause projects to fail.
A project is a complex, no routine, one-time effort limited by time, budget, resources, and
performance specifications design to meet customer needs. Project management is a set of
tools, techniques, and knowledge that, when applied, helps to achieve the three main
constraints of scope, cost and time.
Project Success Factor

User involvement
The absence of user involvement is the major cause of project failure. Even when delivered
on time and on budget, a project can fail if it does not meet users needs.
Executive management support

This influences the process and progress of a project and lack of executive input can put a
project at a severe disadvantage.
Clear statement of requirements

This refers to the base level requirements. By creating a minimal, obtainable base level of
requirements and then developing those features, the effect of change will be reduced. As a
result, an added benefit is that project managers are better prepared to articulate the needs
and priorities of the next phase of the project.
Proper planning
This is one of the keys to a successful project. Creating a project plan is the first thing to do
when undertaking any kind of project. We should need to create a proper plan to develop the
system with the customer requirements.
Clear Responsibility and Accountability of Team Members

This requires that all team members have a clear understanding of their roles and duties in
the project. They must understand how expectations vs. achievements will be measured
and graded. It is left to the project manager to properly implement the communication of
these responsibilities, to provide feedback, and to assure all understand that for which they
will be held accountable.

PDIE/ MP
Issues Description Activities

Focused on achieving these broad
Project Focus Time, budget and quality.
goals.
Engage in planning detailed and
Planning Planning and preplanning.
systematic.
Limited time, money, and other Regular status checks, meetings,
Sense of Urgency
resources. and reminders are essential.
Use a time-tested, proven
Use standard models to build into
project life Identify the best project life cycle.
project plans.
Cycle
Involvement of users in cost and
Evolve gradually to succeed time estimation and risk Maintain a controlled evolution.
management.
Clear approvals and sign-off
by Clear approval points. Examine and approve.
Sponsors
Table 4.3.1 Issues of project management success
Causes of project failure

Projects fail mainly because of unable to plan and estimate correctly, or fail to implement the
tasks according to plan or failure causes by human factor.
Planning and Estimation factor

This factor refers to initial cost and schedule estimates are not revised when more
information becomes available as a project progresses. Also plans are not used correctly or
used to guide the project forward, thus causing the project to fail.
Implementation factor
This is caused by project scope changes, incorrect use of project methodology, major
changes in the requirements and testing, and/or inspections are poorly done.
Human factor
Project managers are not trained to acquire the necessary management skills. Also, some
managers are not able to apply and put the theory of project management into practice. Poor
communications are also one of the human factors that cause a project to fail.
Among these three factors, the major cause of project failure is inappropriate use of project
planning and scheduling methodology.

PDIE/ MP
4.4 Resource Allocation Matrix

Basically blood donor information system is a standalone application. The resource
allocation process is designed to enable executives to make informed decision about the
resources need to run the system, and hardware requirement of the pc.
Resource need to run the system

These two are the important resource to run the blood donor information system without any
hardness.
Computer
A computer is an electronic device that manipulates information, or data. It has the ability to
store, retrieve, and process data. We probably already know that you can use a computer to
type documents, send email, play games, and browse the Web.
As well as computer is the main part to run the system. All the data can store in the
computer database, so its make easy to store the data, and retrieve the data in any time
Dongle
Dongle is help to connect the GSM with the computer. GSM is the legacy network of the
evolution to the third generation (3G) technologies Universal Mobile Telecommunication
System (UMTS), also known as WCDMA, and High Speed Packet Access (HSPA).
Commonly referred to as the GSM family of technologies
Figure 4.4.1 GSM Network

PDIE/ MP
Hardware Requirements
The selection of hardware requirements for Blood camp or hospital is critical because the
Blood donor information system software is expected to become the backbone of the
hospital or blood camp.
Operating System
Blood donor information system runs on Windows XP, Vista or Windows 7& 8 (also Windows
Server 2000, 2003 and 2008). It also has full support for both 32-bit and 64-bit architectures.
If we are thinking of purchasing a new computer, then we thoroughly recommend the
excellent Windows 8. My second choice would be Windows 7.
PC Specifications
This table 4.4.1 shows the recommended and minimum computer specifications for running
the blood donor information system.
Table 4.4.1 PC Specification
Server Specifications for Enterprise version

This table 4.4.2 shows the recommended and minimum server computer specifications for
running the blood donor information system.
Table 4.4.2 Server Specification

PDIE/ MP
4.5 Specification
A standalone application is able to function independently of other hardware. Standalone
application not like web application, only run inside the computer RAM not in the server.
4.5.1 Functional Requirements

Main Function of the System
User and Administrator need login to the system using their own username and
password from each database fields.
Username and password field are need to be validate.
4 seconds progress need after login success message.
After the registration of a donor the program will authenticate the accuracy of the
donors 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 user.
The hospital doctor is not a user of the system.
In donor registration, submission of providing donation details to the system the
doctor will connect directly with the system administrator.
Sending SMS to the registered blood donors in the system.
Type the mobile number and send SMS to anyone.
Administrator can update and delete of any account of blood donor.
Administrator only can create new user and admin for the system, and admin can
delete and update the admin or one user in the system.
The administrator only can create new event and manage events by using system.
The user can only view the events.
Search the donors by donor id, name, address, and the blood group.
Admin and user can view the report of the donors details, and their details of contact.
Logout process need for admin and user accounts.
Some Other Requirements

Every donor has a mobile phone.
The system doesnt keep the details of the gathering stock of blood.
The system database will be accessible in real time.
The donor doesnt submit any fake reports to the system.
Donors who want to contribute to a donation will definitely reply to the request of
system.
The system asking for the user name & the password.
Admin provides the username & the password.
System does authentication.
Main application relevant to admin is displayed.
The donor has contributed to a donation within last 5 months.

PDIE/ MP
4.5.2 Non Functional Requirements

In addition to the obvious features and functions that we will provide in our system, there are
other requirements that don't actually DO anything, but are important characteristics
nevertheless. These are called non-functional requirements.
Non-functional requirements define the overall qualities or attributes of the resulting system.
Non-functional requirements place restrictions on the project being developed, the
development process, and specify external constraints that the project must meet.
Examples of Blood donor information system include safety, security, usability, reliability and
performance requirements. Project management issues (costs, time, and schedule) are
often considered as non-functional requirements as well
These define system properties and constraints.

Process requirements may also be specified mandating a particular CASE system,
programming language or development method.
Non-functional requirements may be more critical than functional requirements. If
these are not met, the system is useless.
Requirements which specify that the delivered project must behave in a particular
way e.g. execution speed, reliability, etc.
Requirements which are a consequence of organizational policies and procedures
e.g. process standards used, implementation requirements, etc.
Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements, etc.
The user interface for Blood donor information system shall be implemented as
simple C# and .NET Framework.
Most systems must operate with other systems and the operating interfaces must be
specified as part of the requirements.
Certain constraints are related to the design solution that is unknown
at the requirements stage
Certain constraints, are highly subjective and can only be determined through
complex empirical evaluations
Non-functional requirements tend to be related to one or more functional
requirements

PDIE/ MP
Design
5.1 Work Breakdown Structure and Task Allocation
The Work Breakdown Structure (WBS) is defined by A Guide to the Project Management
Body of Knowledge.
"A deliverable-oriented hierarchical decomposition of the work to be executed by the project
team to accomplish the project objectives and create the required deliverables."
Purpose
Why do we need to create a WBS for our projects? What purpose does it serve? Why should
I waste my time writing on post-it notes and drawing charts when I could be getting my team
started on the actual work of the project? Now, I know everyone reading this is a great
project manager or team member, so I am sure none of we have ever said comments such
as these, but I am sure we have heard them from those "other" project managers who will
remain nameless.
So to answer these questions, let's take a look at what purpose the WBS serves to our
project. There are three reasons to use a WBS in my project. The first is that is helps more
accurately and specifically define and organize the scope of the total project. The most
common way this is done is by using a hierarchical tree structure. Each level of this structure
breaks the project deliverables or objectives down to more specific and measurable chunks.
The second reason for using a WBS in my project is to help with assigning responsibilities,
resource allocation, monitoring the project, and controlling the project. The WBS makes the
deliverables more precise and concrete so that the project team knows exactly what has to
be accomplished within each deliverable. This also allows for better estimating of cost, risk,
and time because you can work from the smaller tasks back up to the level of the entire
project. Finally, it allows you double check all the deliverables' specifics with the
stakeholders and make sure there is nothing missing or overlapping.
Process
Now that we have agreed that creating a WBS will be help to our project's efficiency and
effectiveness, how do we go about it? First, let's look at what all we need to get started.
There are several inputs,
The Project Scope Statement

The Project Scope Management Plan
Organizational Process Assets
Approved Change Requests

PDIE/ MP

PDIE/ MP
A complex project is made manageable by first breaking it down into individual components
in a hierarchical structure, known as the work breakdown structure, or WBS. Such a
structure defines tasks that can be completed independently of other tasks, facilitating
resource allocation, assignment of responsibilities, and measurement and control of the
project
WBS Task Allocation

The Work breakdown structure can converted to the task matrix.
Task or Project Sub Task Work Package

1. Blood Donor
Information 1.1 Planning 1.1.1 Conceptual Planning
System
1.2 System Analysis 1.2.1 Functional Requirements
1.2.2 Technical Requirements
1.2.3 Requirements Specification Review
1.3 System Design 1.3.1 Internal / External
1.3.2 Design Review
1.3.3 Detailed Project Development
1.4 Coding 1.4.1 Codes Review
1.5 Testing 1.5.1 Programme Test
1.5.2 System Test
1.5.3 Bug Reports
1.5.4 Test Summery
1.6 Implementation 1.6.1 User Documentation
1.6.2 System Documentation

1.7 Maintenance 1.7.1 Review the System
1.7.2 Maintaining the System
1.7.3 Bug Fixing
1.7.4 Upgrade the System
1.8 Final Documentation

Table 5.1.1 WBS Task Matrix

PDIE/ MP
5.2 User Interface

GUI is one of most important for any kind of computer based or software based application,
because this is help to manage or control the system easily by using some icons and some
other buttons.
As well as I have used Microsoft Visual Studio and .NET Framework to create the user
interfaces for my system.
What is Interface Design?

Interface design is the art of making the interaction between the human and the computer
seamless and as effortless as possible. Everything (at some level) on our computer is an
interface, created and designed to allow we access to the data our want.
Principle of User Interface

The structure principle Design should organize the user interface purposefully, in
meaningful and useful ways based on clear, consistent models that are apparent and
recognizable to users, putting related things together and separating unrelated
things, differentiating dissimilar things and making similar things resemble one
another. The structure principle is concerned with overall user interface architecture.
The simplicity principle The design should make simple, common tasks easy,
communicating clearly and simply in the users own language, and providing good
shortcuts that are meaningfully related to longer procedures.
The visibility principle The design should make all needed options and materials
for a given task visible without distracting the user with extraneous or redundant
information. Good designs dont overwhelm users with alternatives or confuse with
unneeded information.
The feedback principle The design should keep users informed of actions or
interpretations, changes of state or condition, and errors or exceptions that are
relevant and of interest to the user through clear, concise, and unambiguous
language familiar to users.
The tolerance principle The design should be flexible and tolerant, reducing the
cost of mistakes and misuse by allowing undoing and redoing, while also preventing
errors wherever possible by tolerating varied inputs and sequences and by
interpreting all reasonable actions.
The reuse principle The design should reuse internal and external components
and behaviors, maintaining consistency with purpose rather than merely arbitrary
consistency, thus reducing the need for users to rethink and remember.

PDIE/ MP
User Interface of Blood Donor Information System
User interface is ever need for any computer based system. As well as I have created nice
graphical user interfaces for my system to meet the client requirements.
Splash Screen and Login Window

There are many great interface designs in my system called Blood Donor Information
System. If we start the system, there is splash screen beginning of my system.
Figure 5.2.1 Splash Screen of System
After five second the system will display a new window called login window, I mean in my
system there two privileges can access to the system. Those are administrator and users.
Administrators are the people manage whole the system, and users are just registering
donors and maintaining the donors.
Figure 5.2.2 Login for Administrator
Figure 5.2.2 is showing administrator login, without proper username, and password anyone
cannot access to the system. Likewise the interface for the user, they also ever need proper
username and password to access to the system.

PDIE/ MP
Main Window of the Blood Donor Information System
The main window is the really important window in the system, this window is secured by
using login privileges, after type correct username, and password, and then only the main
window will be display.
Figure 5.2.3 Main window of System
In here figure 5.2.3 there are some icons I have use some icons to get more clear idea about
those functions. And I have used menu strip tools to rive some more function in the separate
way.
Figure 5.2.4 Menu Strip tool of the Main window in the system
Menu strip help to quick access to the function in the system. And I have used some button
tools and picture tools to make visible to the users.
Figure 5.2.5 Button with Icon
Figure 5.2.5 is showing the button with one icon. I have created this icon used Adobe
Photoshop tool. This button will give more easiness to fine the solution to the users.

PDIE/ MP
Some Main Windows and Function of the System
Here I have used different kind of tools to create this interface for get more visible to the
users.
Figure 5.2.6 Blood Donor Registration Form
Figure 5.2.7 is showing the window of maintain the donors by the administrator.
Administrator only can visible or display this window to make any changes in the system.
Figure 5.2.7 Maintaining Blood Donors

PDIE/ MP
This is interface called sending SMS to the blood donors. So this user interface also got
some more tools and graphical designs.
Figure 5.2.8 Sending SMS to the Donors
As well as there is other interface called create new administrators and users to the system.
This figure 5.2.9 also displaying some kind of .NET framework tools.
Figure 5.2.9 Create new admin, and user

PDIE/ MP
And I have created separate interface for event management, the event management will
give details about the next blood donation camp, and where it is.
Figure 5.2.10 Create new events
And figure 5.2.11 is showing the search window. I mean using this window the admin and
users can easily search the donors and find out easily from the donors list.
Figure 5.2.11 Search donors

PDIE/ MP
5.3 Context Diagram and Use Case Diagram
Diagram 5.3.1 Use Case Diagram

PDIE/ MP
5.4 Data Flow Diagram
Diagram 5.3.2 Data Flow Diagram

PDIE/ MP
Diagram 5.3.3 Data Flow Diagram Level 0

PDIE/ MP

PDIE/ MP

PDIE/ MP
5.5 ER Diagram
Diagram 5.3.10 ER- Diagram

PDIE/ MP
5.6 Other Diagrams

PDIE/ MP
Method and Methodology

6.1 Model and Methodology Evaluation
The development models are the various processes or methodologies that are being
selected for the development of the project depending on the projects aims and goals.
There are many development life cycle models that have been developed in order to achieve
different required objectives. The models specify the various stages of the process and the
order in which they are carried out.
In addition to using computer for work, people use it for fun and entertainment. Noticeably,
the number of companies that produce software programs for the purpose of facilitating
works of offices, administrations, banks, etc., has increased recently which results in the
difficulty of enumerating such companies. During the previous four decades, software has
been developed from a tool used for analyzing information or solving a problem to a product
in itself. However, the early programming stages have created a number of problems turning
software an obstacle to software development particularly those relying on computers.
Software consists of documents and programs that contain a collection that has been
established to be a part of software engineering procedures. Moreover, the aim of software
engineering is to create a suitable work that construct programs of high quality.
Software Process Models

A software process model is an abstract representation of a process. It presents a
description of a process from some particular perspective as:
Specification
Design
Validation
Evolution
The selection of model has very high impact on the testing that is carried out. It will define
the what, where and when of our planned testing, influence regression testing and largely
determines which test techniques to use.
There are various Software development models or methodologies,
Waterfall Model
Iteration Model
V Shaped Model
Spiral Model
Extreme Model

PDIE/ MP
Waterfall Model
The waterfall model is the classical model of software engineering. This model is one of the
oldest models and is widely used in government projects and in many major companies. As
this model emphasizes planning in early stages, it ensures design flaws before they develop.
In addition, its intensive document and planning make it work well for projects in which
quality control is a major concern.
The pure waterfall lifecycle consists of several no overlapping stages, as shown in the
following figure 6.1.1. The model begins with establishing system requirements and software
requirements and continues with architectural design, detailed design, coding, and testing.
The waterfall model serves as a baseline for many other lifecycle models.
Figure 6.1.1 Waterfall Model
Figure Source - http://www.scrum-compact.com/fundamentals-of-project-management/waterfall-

model/
The following list details the steps for using the waterfall model,
System requirements
Establishes the components for building the system, including the hardware requirements,
software tools, and other necessary components. Examples include decisions on hardware,
such as plug-in boards (number of channels, acquisition speed, and so on), and decisions
on external pieces of software, such as databases or libraries.
Software requirements
Establishes the expectations for software functionality and identifies which system
requirements the software affects. Requirements analysis includes determining interaction
needed with other applications and databases, performance requirements, user interface
requirements, and so on.

PDIE/ MP
Architectural design
Determines the software framework of a system to meet the specific requirements. This
design defines the major components and the interaction of those components, but it does
not define the structure of each component. The external interfaces and tools used in the
project can be determined by the designer.
Detailed design
Examines the software components defined in the architectural design stage and produces a
specification for how each component is implemented.
Coding
Implements the detailed design specification.
Testing
Determines whether the software meets the specified requirements and finds any errors
present in the code.
Maintenance
Addresses problems and enhancement requests after the software releases.
Although the waterfall model has its weaknesses, it is instructive because it emphasizes
important stages of project development. Even if one does not apply this model, we must
consider each of these stages and its relationship to our own project.
Advantages of the Waterfall Model

Easy to understand and implement.
Widely used and known.
Reinforces good habits: define-before- design, design-before-code.
Identifies deliverables and milestones.
Document driven, URD, SRD, etc. Published documentation standards, e.g. PSS-05.
Works well on mature products and weak teams.
Disadvantages of the Waterfall Model

Idealized, doesnt match reality well.
Doesnt reflect iterative nature of exploratory development.
Unrealistic to expect accurate requirements so early in project.
Software is delivered late in project, delays discovery of serious errors.
Difficult to integrate risk management.
Difficult and expensive to make changes to documents, swimming upstream.
Significant administrative overhead, costly for small teams and projects.

PDIE/ MP
Iteration Model
The problems with the Waterfall Model created a demand for a new method of developing
systems which could provide faster results, require less up-front information, and offer
greater flexibility. With Iterative Development, the project is divided into small parts. This
allows the development team to demonstrate results earlier on in the process and obtain
valuable feedback from system users.
Often, each iteration is actually a mini-Waterfall process with the feedback from one phase
providing vital information for the design of the next phase. In a variation of this model, the
software products, which are produced at the end of each step (or series of steps), can go
into production immediately as incremental releases.
Figure 6.1.2 Iteration Model
Figure Source - http://www.scrum-compact.com/fundamentals-of-project-management/iteration-

model/

PDIE/ MP
V Shaped Model
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of
processes. Each phase must be completed before the next phase begins. Testing is
emphasized in this model more than the waterfall model. The testing procedures are
developed early in the life cycle before any coding is done, during each of the phases
preceding implementation. Requirements begin the life cycle model just like the waterfall
model. Before development is started, a system test plan is created. The test plan focuses
on meeting the functionality specified in requirements gathering.
Advantages of the V Shaped Model

Simple and easy to use.
Each phase has specific deliverables.
Higher chance of success over the waterfall model due to the early development of
test plans during the life cycle.
Works well for small projects where requirements are easily understood.
Disadvantages of the V Shaped Model

Very rigid like the waterfall model.
Little flexibility and adjusting scope is difficult and expensive.
Software is developed during the implementation phase, so no early prototypes of
the software are produced.
This Model does not provide a clear path for problems found during testing phases.
Figure 6.1.3 V-Shaped Model

Figure Source - http://www.scrum-compact.com/fundamentals-of-project-management/v-
shaped-model/

PDIE/ MP
Spiral Model
The spiral model is similar to the incremental model, with more emphases placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral.
Requirements are gathered during the planning phase. In the risk analysis phase, a process
is undertaken to identify risk and alternate solutions. A prototype is produced at the end of
the risk analysis phase. Software is produced in the engineering phase, along with testing at
the end of the phase. The evaluation phase allows the customer to evaluate the output of the
project to date before the project continues to the next spiral.
In the spiral model, the angular component represents progress, and the radius of the spiral
represents cost.
Advantages of the Spiral Model

High amount of risk analysis.
Good for large and mission-critical projects.
Software is produced early in the software life cycle.
Disadvantages of the Spiral Model

Can be a costly model to use.
Risk analysis requires highly specific expertise.
Projects success is highly dependent on the risk analysis phase.
Doesnt work well for smaller project.
Figure 6.1.4 Spiral Model

Figure Source - http://www.nada.kth.se/~karlm/prutt05/lectures/prutt05_lec6.pdf

PDIE/ MP
Extreme Model
An approach to development, based on the development and delivery of very small
increments of functionality. It relies on constant code improvement, user involvement in the
development team and pair wise programming. It can be difficult to keep the interest of
customers who are involved in process. Team members may be unsuited to the intense
involvement that characterizes agile methods.
Select user Break down Plan release

stories for this stories to tasks
release
Evaluate system Release Develop/

software integrate/ test
software
Figure 6.1.5 Extreme XP Release Cycle
XP and Agile Principles

Incremental development is supported through small, frequent system releases.
Customer involvement means full-time customer engagement with the team.
People not process through pair programming, collective ownership and a process
that avoids long working hours.
Change supported through regular system releases.
Maintaining simplicity through constant refactoring of code.
Advantages of the XP
Lightweight methods suit small-medium size projects.
Produces good team cohesion.
Emphasizes final product.
Iterative.
Test based approach to requirements and quality assurance.
Disadvantages of the XP
Difficult to scale up to large projects where documentation is essential.
Needs experience and skill if not to degenerate into code and fix.
Programming pairs costly.

PDIE/ MP
6.2 Selected Methodology

When choosing a development life cycle, we don't just trust our feelings. Decide based on
factors that really matter.
Which life cycle will work best for our project? This is an important strategic question
because making the wrong choice could lead to disastrous results of catastrophic
proportions. Think about delayed deliveries, unhappy clients, project overruns, and cancelled
projects.
During the 80s and early 90s, the waterfall model was the de-facto in project delivery. With
the rapid pace in software development and popular use of the Internet, many companies
started shifting to more flexible life cycles such as the iterative, incremental, spiral, and agile.
These new life cycle methods provide more flexibility and support fast-paced development,
giving companies the edge in delivering "the first" in the industry. To date, there are dozens
of life cycle methods available to choose from, each having its own advantages and
disadvantages.
I have selected the Waterfall Method to develop my system called blood donor information
system. Because the water fall method is best to full fill each stages within the time frame.
Waterfall Model
The waterfall model is a sequential design process, often used in software development
processes, in which progress is seen as flowing steadily downwards (like a waterfall) through
the phases of planning, analyzing, designing, coding, testing, implementing, and
maintaining.
The waterfall development model originates in the manufacturing and construction
industries. Highly structured physical environments in which after-the-fact changes are
prohibitively costly, if not impossible. Since no formal software development methodologies
existed at the time, this hardware-oriented model was simply adapted for software
development.
When done well the waterfall method is excellent for large projects and there are no
surprises when the application is finally delivered as all features and even the appearance of
the application has been fully specified and understood by future users of the system.
If the requirements phase is done badly the waterfall method delivers failure as the end
result will only ever be as good as the specifications.
My first step is to create the functional specification. This often begins life as a very
abstract requirements specification provided by the client.
When the application is complete a beta release is published and provided to the
business for testing. Any bugs found are rapidly repaired.

PDIE/ MP
6.3 Procedures
The waterfall model proceeds from one phase to the next in a sequential manner. For
example, one first completes requirements specification, which after sign-off are considered
set in stone. When requirements are completed, one proceeds to design. The software in
question is designed and a blueprint is drawn for implementers (coders) to follow this design
should be a plan for implementing the requirements given. When the design is complete, an
implementation of that design is made by coders. Towards the later stages of this
implementation phase, separate software components produced are combined to introduce
new functionality and reduced risk through the removal of errors.
Thus the waterfall model maintains that one should move to a phase only when its
preceding phase is completed and perfected. However, there are various modified waterfall
models that may include slight or major variations upon this process.
Phases of the waterfall life cycle model.
Requirements - The first phase involves understanding what we need to design and
what is its function, purpose etc. Unless we know what we are going to design, we
cannot approach the problem. Here, the specifications of the input and output or the
final product is studied and marked.
Analysis - As per the requirements, the software and hardware needed for the
proper completion of the project is analyzed in this phase. Right from deciding which
computer language should be used for designing the software, to the database
system that can be used for the smooth functioning of the software, such features are
decided at this stage.
Design - The algorithm (pseudo-code) of the program or the software code to be
written in the next stage, is created now. This algorithm forms the backbone for the
actual coding process. Proper planning relating to the design of user interface,
flowcharts is done here.
Coding - Based on the algorithm or flowchart designed, the actual coding of the
software is carried out at this stage. The flowcharts / algorithms are converted into
instructions written in a programming language.
Testing - The software designed, needs to go through constant software testing and
error correction processes to find out if there are any flaw or errors. Testing is done
so that the client does not face any problem during the installation of the software.
Maintenance - There are some issues which come up in the client environment. To
fix those issues patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the customer
environment.

PDIE/ MP
6.4 Implementation
Normally I have did work of each phases of the software development life cycle. Now here Ill
show the implementation or the works in each phases during the development of the blood
donor information system. These are the stages or phases of software development life
cycle.
Requirements
For the requirements, I have categorized in to two ways, such as functional and non-
function requirements. These are the important thing during the project development period
because we need requirements to collect how system it should be. These are some notes
which I have gathered from the clients and other resources.
Software development team need a plan develop their projects.

There two types of requirements, such as functional and non-functional
requirements.
Functional requirements mean clients preference, the client have plan they must
need some function in the system so those are functional requirements.
Non-functional mean the not the clients preference but the system may be need
some extra function to give quality to use.
Here I have gathered those requirements in two categories.
Requirements is decide the system how it should be.
Analysis
After collected requirements have to analyze the function or we need to study some similar
systems and develop the systems with use of requirements. And I have studied some similar
systems same as blood donor information systems. Some facts,
I have collected factual data similar to system.

I understand the process involved.
Identifying problems and recommending feasible suggestions for improving the
system functioning.
Gathering operational data.
Understand the information flow.
Finding out bottlenecks and evolving solutions for overcoming the weaknesses of the
system so as to achieve the organizational goals.
System Analysis also includes subdividing of complex process involving the entire
system.
Identification of data store and manual processes.

PDIE/ MP
Design
Based on the user requirements and the detailed analysis of a new system, the new system
must be designed. This is the phase of system designing. It is the most crucial phase in the
development of a system. The logical system design arrived at as a result of system analysis
and is converted into physical system design.
The logical design produced during the analysis is turned into a physical design - a detailed
description of what is needed to solve original problem. Input, output, databases, forms,
codification schemes and processing specifications are drawn up in detail. In the design
stage, the programming language and the hardware and software platform in which the new
system will run are also decided. Data structure, control process, equipment source,
workload and limitation of the system, Interface, documentation, training, procedures of
using the system, taking backups and staffing requirement are decided at this stage.
There are several tools and techniques used for describing the system design of the system.
These tools and techniques are: Flowchart, Data flow diagram (DFD), Data dictionary.
Design is make impact to the systems. Because before develop the system, the diagrams
other resources will give brief idea how this system it should be.
Coding
The system design needs to be implemented to make it a workable system. Its demands the
coding of design into computer language, i.e., programming language. This is also called the
programming phase in which the programmer converts the program specifications into
computer instructions, which we refer to as programs. It is an important stage where the
defined procedures are transformed into control specifications by the help of a computer
language. The programs coordinate the data movements and control the entire process in a
system. A well written code reduces the testing and maintenance effort. It is generally felt
that the programs must be modular in nature. This helps in fast development, maintenance
and future changes, if required. Programming tools like compilers, interpreters and language
like c#, c++, and java etc., are used for coding .with respect to the type of application. The
right programming language should be chosen.
And I have choose C# programming language to develop the system by using codes. And
coding is important to make the functions and the programmes. I have used Microsoft Visual
Studio 2010 GUI to develop this system without any affection.

PDIE/ MP
Here is some codes sample of the blood donor information system. This is most need to
connect whole the data in the database.
Example 1 Database Connection

namespace Blood_Donor_Information_system
{
class db_connection
{
public SqlConnection conn;
public void Connect_Database()

{
conn = new SqlConnection("Data Source=Azeem-PC;Initial

Catalog=Blood_Donor_System;Integrated Security=True");
conn.Open();
}
}
These set of codes are help to connect with database. So this one method or function,
because we can use this method in anywhere, thats why we are called as object oriented
programming language.
Example 2 Clear the text fields

private void button1_Click(object sender, EventArgs e)
{
Action<Control.ControlCollection> func = null;
func = (controls) =>

{
foreach (Control control in controls)
if (control is TextBox)
(control as TextBox).Clear();
else
func(control.Controls);
};
func(Controls);
}
These set of codes are used to clear the text fields which they have called this function.
Example 1 and 2 is showing the sample codes which I have used in my system.

PDIE/ MP
Testing
Before actually implementing the new system into operations, a test run of the system is
done removing all the bugs, if any. It is an important phase of a successful system. After
codifying the whole programs of the system, a test plan should be developed and run on a
given set of test data. The output of the test run should match the expected results.
Sometimes, system testing is considered as a part of implementation process.
Program Test: When the programs have been coded and compiled and brought to working
conditions, they must be individually tested with the prepared test data. All verification and
validation be checked and any undesirable happening must be noted and debugged (error
corrected).
System Test: After carrying out the program test for each of the programs of the system and
errors removed, then system test is done. At this stage the test is done on actual data. The
complete system is executed on the actual data. At each stage of the execution, the results
or output of the system is analyzed. During the result analysis, it may be found that the
outputs are not matching the expected output of the system. In such case, the errors in the
particular programs are identified and are fixed and further tested for the expected output. All
independent modules be brought together and all the interfaces to be tested between
multiple modules, the whole set of software is tested to establish that all modules work
together correctly as an application or system or package.
Below pages there are some testing case and actual test result which I have developed for
the blood donor information system.
Implementation
After having the user acceptance of the new system developed, the implementation phase
begins. Implementation is the stage of a project during which theory is turned into practice.
The major steps involved in this phase are,
Installation of Software and Hardware.

Documentation
The hardware and the relevant software required for running the system must be made fully
operational before implementation. The conversion is also one of the most critical and
expensive activities in the system development life cycle. The data from the old system
needs to be converted to operate in the new format of the new system. The database needs
to be setup with security and recovery procedures fully defined.
I have already recommended computer configuration to install and run this system in the
computer and server.

PDIE/ MP
Maintenance
Maintenance is necessary to eliminate errors in the system during its working life and to tune
the system to any variations in its working environments. It must meet the scope of any
future enhancement, future functionality and any other added functional features to cope up
with the latest future needs. It has been seen that there are always some errors found in the
systems that must be noted and corrected. It also means the review of the system from time
to time. The review of the system is done for,
Knowing the full capabilities of the system

Knowing the required changes or the additional requirements
Studying the performance.
If a major change to a system is needed, a new project may have to be set up to carry out
the change. The new project will then proceed through all the above life cycle phases.
And the main documentation for the maintenance is user manual, it all give the operating
and control the system for the users.
Figure 6.4.1 Sample User Manual
Figure Resource - http://sis.agr.gc.ca/cansis/references/1984mk_a.jpg
Systems Development Life Cycle (SDLC) puts emphasis on decision making processes that
affect system cost and usefulness. These decisions must be based on full consideration of
functional requirements, and economic and technical feasibility. The primary objectives of
any SDLC is to deliver quality system which meets or exceed customer expectations and
within cost estimates, work effectively and efficiently within the current and planned
infrastructure, and is an inexpensive to maintain. SDLC establishes a logical order of events
for conducting system development that is controlled, measured, documented, and
ultimately improved. Any software is not all complete and there are enough rooms to add
new features to existing software.

PDIE/ MP
Results and Discussion

Here I would like to tell the blood donor information system which I have developed. It was a
good experience on the developing area. I have used Microsoft Visual Studio 2010 to create
my application, and I have used Microsoft Word 2013 to create final documentation. Before
start to develop the system I was created Work break down structure to make sure how
many weeks or days I need to compete the system. And below table 8.1 is showing the
result of the stages of work break down structure.
Task No WBS Stages Completed Completed Date

1.1 Planning Yes 23rd September 2014
1.1.1 Conceptual Planning Yes 26th September 2014
1.2 System Analysis Yes 07th October 2014
1.2.1 Functional Requirements Yes 30th September 2014
1.2.2 Technical Requirements Yes 02nd October 2014
1.2.3 Requirements Specification Review Yes 06th October 2014
1.3 System Design Yes 21st October 2014
1.3.1 Internal / External Yes 08th October 2014
1.3.2 Design Review Yes 10th October 2014
1.3.3 Detailed Project Development Yes 21st October 2014
1.4 Coding Yes 01st November 2014
1.4.1 Codes Review Yes 01st November 2014
1.5 Testing Yes 24th November 2014
1.5.1 Programme Test Yes 31st October 2014
1.5.2 System Test Yes 07th November 2014
1.5.3 Bug Reports Yes 13th November 2014
1.5.4 Test Summery Yes 18th November 2014
1.6 Implementation Yes 09th December 2014
1.6.1 User Documentation Yes 20th November 2014
1.6.2 System Documentation Yes 25th November 2014
1.7 Maintenance Yes 22nd December 2014
1.7.1 Review the System Yes 27th November 2014
1.7.2 Maintaining the System Yes 01st December 2014
1.7.3 Bug Fixing Yes 04th December 2014
1.7.4 Upgrade the System Yes 08th December 2014
1.8 Final Documentation Yes 10th January 2015
Table 8.1 SDLC Compliance Matrix

PDIE/ MP
Table 8.1 is showing the completed date of each phases of the software development life
cycle. And after complete each phases and test those phases according to the requirements.
Total number of Phases and Sub Phases 26
Number of Phases implemented 26
Phases partially fulfilled 0
Phases not fulfilled 0
Phases dropped 0
Table 8.2 SDLC Compliance Summary
And summary show how many phases implemented for this project work, and about phases
of the software development life cycle table 8.2.
I was created test cases to identify the each step of the system, and test for to identify the
working condition of the whole system. Below I have created the test cases for each and
each methods of the system, which is clearly testing the each methods and function witch
are run inside the system.
Most of actual testing is giving good comment, and I have got some errors and warning
messages during testing period, I have corrected those errors and warning with the system,
and I have fixed those problems.
This system could be more useful for any kind of patients in the hospitals. Whoever
immediately need blood, using this this they contact the already registered donors by using
this system.
The scope and objective of this system is giving a more secure to data and the information
of the donors, in the critical or emergency situation the admin or user can easily contact the
blood donors, and administrator can create new events to get know when next blood
donation camp will start and the time of it.
So I make one decision the computerized system is better than other paper base or other
systems. So its more secured purpose. I really experienced on developing computer based
and standalone application.

PDIE/ MP
Testing and Evaluation

8.1 Testing
8.1.1 Method of Testing
There are different methods which can be used for Software testing. This chapter briefly
describes those methods. Test cases are developed using various test techniques to
achieve more effective testing. By this, software completeness is provided and conditions of
testing which get the greatest probability of finding errors are chosen. So, testers do not
guess which test cases to choose, and test techniques enable them to design testing
conditions in a systematic way. Also, if one combines all sorts of existing test techniques,
one will obtain better results rather if one uses just one test technique.
Black Box Testing

Black Box Testing is a software testing method in which the internal structure/ design/
implementation of the item being tested is not known to the tester. These tests can be
functional or non-functional, though usually functional. Test design techniques include,
Equivalence partitioning
Boundary Value Analysis
Cause Effect Graphing
The technique of testing without having any knowledge of the interior workings of the
application is Black Box testing. The tester is oblivious to the system architecture and does
not have access to the source code. Typically, when performing a black box test, a tester will
interact with the system's user interface by providing inputs and examining outputs without
knowing how and where the inputs are worked upon.
Advantages Disadvantages
Well suited and efficient for large

Limited Coverage since only a
code segments.
selected number of test scenarios
are actually performed.
Code Access not required.
Inefficient testing, due to the fact
Clearly separates user's perspective
that the tester only has limited
from the developer's perspective
knowledge about an application.
through visibly defined roles.
Blind Coverage, since the tester
Large numbers of moderately skilled
cannot target specific code
testers can test the application with
segments or error prone areas.
no knowledge of implementation,
programming language or operating
The test cases are difficult to design.
systems.
Table 8.1.1.1 Advantages and Disadvantages of Black box testing

PDIE/ MP
White Box Testing
White Box Testing is a software testing method in which the internal structure/ design/
implementation of the item being tested is known to the tester. Test design techniques
include,
Control flow testing
Data flow testing
Branch testing
Path testing
White box testing is the detailed investigation of internal logic and structure of the code.
White box testing is also called glass testing or open box testing. In order to perform white
box testing on an application, the tester needs to possess knowledge of the internal working
of the code.
The tester needs to have a look inside the source code and find out which unit/ chunk of the
code is behaving inappropriately.
As the tester has knowledge of the Due to the fact that a skilled tester is
source code, it becomes very easy needed to perform white box testing,
to find out which type of data can the costs are increased.
help in testing the application
effectively. Sometimes it is impossible to look
into every nook and corner to find
It helps in optimizing the code. out hidden errors that may create
problems as many paths will go
Extra lines of code can be removed untested.
which can bring in hidden defects.
It is difficult to maintain white box
Due to the tester's knowledge about testing as the use of specialized
the code, maximum coverage is tools like code analyzers and
attained during test scenario writing. debugging tools are required.
Table 8.1.1.2 Advantages and Disadvantages of White box testing
Grey Box Testing

Grey Box testing is a technique to test the application with limited knowledge of the internal
workings of an application. In software testing, the term the more you know the better carries
a lot of weight when testing an application.
Mastering the domain of a system always gives the tester an edge over someone with
limited domain knowledge. Unlike black box testing, where the tester only tests the
application's user interface, in grey box testing, the tester has access to design documents
and the database. Having this knowledge, the tester is able to better prepare test data and
test scenarios when making the test plan.

PDIE/ MP
Offers combined benefits of black
box and white box testing wherever
possible. Since the access to source code is
not available, the ability to go over
Grey box testers don't rely on the the code and test coverage is
source code; instead they rely on limited.
interface definition and functional
specifications. The tests can be redundant if the
software designer has already run a
Based on the limited information test case.
available, a grey box tester can
design excellent test scenarios Testing every possible input stream
especially around communication is unrealistic because it would take
protocols and data type handling. an unreasonable amount of time;
therefore, many program paths will
The test is done from the point of go untested.
view of the user and not the
designer.
Table 8.1.1.3 Advantages and Disadvantages of Grey box testing
Table 8.1.1.4 display the different and compere of those testing methods.
S.N. Black Box Testing Grey Box Testing White Box Testing
1 The Internal Workings of Somewhat knowledge of the Tester has full knowledge of
an application are not internal workings are known the Internal workings of the
required to be known application
2 Also known as closed box Another term for grey box Also known as clear box
testing, data driven testing testing is translucent testing as testing, structural testing or
and functional testing the tester has limited code based testing
knowledge of the insides of the
application
3 Performed by end users Performed by end users and Normally done by testers and
and also by testers and also by testers and developers developers
developers
4 Testing is based on Testing is done on the basis of Internal workings are fully
external expectations - high level database diagrams known and the tester can
Internal behavior of the and data flow diagrams design test data accordingly
application is unknown
5 This is the least time Partly time consuming and The most exhaustive and time
consuming and exhaustive exhaustive consuming type of testing
6 Not suited to algorithm Not suited to algorithm testing Suited for algorithm testing
testing
7 This can only be done by Data domains and Internal Data domains and Internal
trial and error method boundaries can be tested, if boundaries can be better
known tested
Table 8.1.1.4 Different between testing methods

PDIE/ MP
8.1.2 Test Cases
Test Case: 1.1 Test Case Name: Login Validation

System: Blood Donor Information System Design Date: 20th December 2014
Short Description: Test the Login Validation
Pre- Conditions
System have 2 kind privileges to access, those are admin and the user. They must access to
the system with proper username and password. If the admin or user type their correct
username and password, then the programme will be check the valid username and
password to access to the system.
Pass/
Step Action Expected System Response Comment
Fail
Change the user type to admin or
1 Click the user type button Pass Good
user in the system
Without Filling the text box Display error message with
2 Pass Good
and click login button information to login
Type incorrect username and

Display error message with Too Slow to popup
3 password and click login Pass
information to login the message
button
Type correct username and

Access to main menu after
4 password and click login Pass Good Visible
completed the progress
button
5 Click the cancel button To exit the system Pass Fast

Table 8.1.2.1 Test Case for Login Validation
Post- Conditions
There are two User type, Administrator and User.
If the Username and Password is correct, access to the main function in the system.
If the Username and Password is incorrect, then error massage will be display.
Check the valid username and password from the database.
Make Sure the username and password of those two users in the system.

PDIE/ MP
Test Case: 1.2 Test Case Name: Donor Registration

Short Description: Test the Donor Registration Fields
Pre- Conditions
After given correct username and password, then the user can view this page by using main
window of the system. All the text fields can be fill by administrator or user.
Pass/
Step Action Expected System Response
Fail
Comment
Click the donor id text field Filling with using any kind numbers
1 Pass Too Slow to select
and fill or text
Without filling the donor id Display error message with
2 Pass Good
field and click save button information
Selecting Blood Group and Any kind of blood group can be

3 Pass Good
click save button added to database
Complete all the text fields

4 All the details save in the database Pass Very Fast
and click save button
Without completing some text Display current error with

5 Fail Not satisfied
fields and click save button information
Click donor maintaining Access to donor maintaining
6 Pass Very Fast
button window
Sometime can save in the
Without completing any fields
7 database, or can be display an Pass Not Fix
click save button
error message
All the text filed can be clean using
8 Click clear button Pass Fix
just a click
9 Click close button To exit the window Pass Fix

Table 8.1.2.2 Test Case for Donor Registration
Post- Conditions
All the Donor details can be store in the database.
Donor id is the primary key, cant duplicate the value.
Admin and users can view this window to register new donors to the system.

PDIE/ MP
Test Case: 1.3 Test Case Name: Update Donor Details

Short Description: Test Update the Donor Details
Pre- Conditions
After completing the registration of donor, then if they have any wrong details the admin can
only update or edit their details with correct details. Using donor id and they can select to
update their details.
Pass/
Step Action Expected System Response Comment
Fail
Using donor id and select the
1 Changing with details Pass Very Quick
donor
Type the donor id in the
2 Changing with details Fail Not Fix
combo box field
Without Changing any details
Not display any error message and
3 of the donors and click Pass Good
save in the database
update button
Edit the details and click to Display updated successfully

4 Pass Fix
save message
Changing donor id and click

5 Display error message Pass Fix
save button
Table 8.1.2.3 Test Case for Update Donor Details
Post- Conditions
Only Administrator can update or edit the donor details.
Using Donor id and select the donors to make changes.
Donor Details can be make complete changes.
After change all the details and clicking save button will change all the details of the
current donor.

PDIE/ MP
Test Case: 1.4 Test Case Name: Delete Donor Details

Short Description: Test Delete the Donor Details
Pre- Conditions
If the blood camp, no need one donor they can just delete the donor by clicking one button.
In the donor maintaining window there is combo box to change the donor list, I mean using
that combo box and select the donor current donor and delete.
Pass/
Fail
Comment
Changing the donor id using All the details must change with the
1 Pass Fix
combo box donor id
2 Click delete button Delete the donor details Pass Quick
After delete the donor then Delete the donors and get refresh
3 Pass Fix
get refresh to make the list of the donor id
To get current details about the

4 Click the refresh button Pass Fix
donor
Without Selecting Donor id Give error message with

5 Pass Fix
and delete information
Table 8.1.2.4 Test Case for Delete Donor Details
Post- Conditions
Only Administrator can delete the donor details.
Selecting donor id and delete the donors.
Easily can delete the donors from the list.

PDIE/ MP
Test Case: 1.5 Test Case Name: Sending SMS

Short Description: Test Sending SMS to Registered Donors
Pre- Conditions
Sending SMS to donors is the most important function of the Blood donor information
system. There is two function sending SMS by the phone number and sending SMS by
selecting blood group, and area of the donor.
Pass/
Fail
Comment
Select correct port to send the SMS

1 Check whats the port Pass Fix
to donor
Type the mobile no in the text Display the numbers in the text
2 Pass Visible
field field
Click the Send button after Send the message to the current
3 Pass Quick
filling the text boxes mobile no
4 Select the blood group Changing blood groups Pass Quick
Click send button without fix Sending the SMS to all registered
5 Pass Quick
the district and blood group donors
6 After click the send button The message box will display Pass Quick
7 Click the close button To exit the system Pass Fix
Table 8.1.2.5 Test Case for Sending SMS
Post- Conditions
Admin and User can send the SMS to Donors, or others using mobile number.
The already registered donors will receive a SMS from the system.
Quick contact with the blood donors.
Easily send the SMS to anyone.

PDIE/ MP
Test Case: 1.6 Test Case Name: Reports View

Short Description: Test All the Reports in the System
Pre- Conditions
Report view is one of important for any kind of system. So report will give the brief idea
about all the blood donors details at one time. Not only that admin or user can print the
donors list with details.
Pass/
Fail
Comment
Click the donor registered list Preview the donor registered list
1 Pass Too Slow
report report with details
Click the donor contact Preview the donor contact details
2 Pass Tool Slow
details report report with the details
3 Click the event details report Preview the event details report Pass Too Slow
Print those reports selecting

4 Printing with the details Pass Good
the donors list
View with suitable

5 All the details are in order Pass Good
arrangement
6 Click the close button To exit the reports Pass Fast
Table 8.1.2.6 Test Case for Report view
Post- Conditions
Reports can view by administrator and users.
Using report they can easily print those details.
Report is given brief idea and clear for the users.

PDIE/ MP
Test Case: 1.7 Test Case Name: Create Admin and User
System: Blood Donor Information System Design Date: 22nd December 2014
Short Description: Test Creating Administrator to the System
Pre- Conditions
Administrator only can create the new administrator and user for the system. To create new
admin or user they must log into one of admin account. Admin can create new account,
update the account, and delete the account.
Pass/
Fail
Comment
Changing user name and password

1 Change the admin id Pass Good
of the current administrator
Changing user and password of the
2 Change the user id Pass Good
current user
Fill the username and
Display successful message in the
3 password with proper name Pass Very Quick
message box
and click save
Without filling username and Display error message with
4 Pass Very Quick
password and click save information
Change the username and
Display updated successfully
5 password of current user and Pass Good
message with detailed
click update
Select the current user and Display deleted successfully

6 Pass Good
click delete button message with detailed
Table 8.1.2.7 Test Case for Create Admin and User
Post- Conditions
Admin only can use this system.
Easily create new administrator and users to the system.
Update the username and password of current users, or administrators.
Delete unwanted users from the database.
Clear the text field just clicking a button.

PDIE/ MP
Test Case: 1.8 Test Case Name: Creating New Event

System: Blood Donor Information System Design Date: 22nd December 2014
Short Description: Test Create New Event
Pre- Conditions
Event management will give a brief idea about the next blood camp event. Here the
administrator only create new events. Administrator only can update the events, and delete
unwanted events.
Pass/
Fail
Comment
Change the event id from Changing all the details about the
1 Pass Quick
combo box events
Display error message with
2 Re-type the event id Pass Good
information
Click save button without Display error message with
3 Pass Good
filling any text field information
Click save button after filling

4 Display save successful message Pass Quick
the text field
Selecting event by id and
Display updated successfully
5 change the text field and click Pass Quick
message
update button
Selecting event by id and

6 Display deleted successfully Pass Quick
click delete button
Without selecting event id

7 Show and error message Pass Quick
and click delete button
Table 8.1.2.8 Test Case for Creating New Event
Post- Conditions
Administrator only can access to the event management window.
New events can create by using this function.
Update the current events.
If there is any unwanted event they can delete.

PDIE/ MP
Test Case: 1.9 Test Case Name: Search Blood Donors

System: Blood Donor Information System Design Date: 23rd December 2014
Short Description: Test Search Blood Donors
Pre- Conditions
Search event is most important for any kind of system, because it will be make easy to
identify the details by using id. Here search donors is needed to identify donors immediately.
Pass/
Fail
Comment
Changing the search by

1 Display search window Pass Good
combo box and click to next
Display the some search by option
2 Select the Search by Pass Quick
in the combo box
Click to Search by id and
3 Display search by id window Pass Quick
click next
Click to Search by name and

4 Display search by name window Pass Too Slow
click next
Click to Search by address

5 Display search by address window Pass Quick
and click next
Click to Search by blood Display search by blood group

6 Pass Quick
group and click next window
Enter value in the search text Display search result in the grid
7 Pass Quick
field view
Table 8.1.2.9 Test Case for Search Blood Donors
Post- Conditions
Administrator and user can search the blood donors.
There 4 type to search the donors
o Search by Donor ID
o Search by Donor Name
o Search by Donor Address
o Search by Donor Blood Group
Quickly view the search result to grid view.

PDIE/ MP
8.1.3 Evaluation of Actual and Expected Results

Expected is how the System has to behave after testing the functionality of an application.
Actual is what the System behaved after testing the functionality of an application.
Functionality/result that is expected for the correct functioning of the application. It is usually
mentioned in the requirement specification documents.
Test the Actual Result of the Login of the Users

Expected
Test No Test Data Purpose Actual Result
Result
Username and password
Check whether the Login will be
for Admin
log in the form will granted to Login will be granted
01
allow the program Admin Main Admin Main Form
User name = admin
to run or not Form
Password=admin
There will be an
Check whether the error message There will be an error
for Admin
log in the form will called message called
02
allow the program username and username and
User name = admin
to run or not password password incorrect
Password=ADMIN
incorrect
Check whether the
for User Login will be
log in the form will Login will be granted
03 granted to User
allow the program User Main Form
User name = user Main Form
to run or not
Password=user
There will be an
Check whether the error message There will be an error
for User
log in the form will called message called
04
allow the program username and username and
User name = user12333
to run or not password password incorrect
Password=sdkfnd
incorrect
Username and password There will be an
There will be an error
for Admin Check whether the error message
message called fill the
05 log in the form will called fill the
username and
User name = allow to run or not username and
password
Password = password
Username and password There will be an
There will be an error
for User Check whether the error message
message called fill the
06 log in the form will called fill the
username and
User name = allow to run or not username and
password
Password = password
Table 8.1.3.1 Test Case for Login

PDIE/ MP
Test the Actual Result of the Donor Registration

I have already created the test case for the donor registration table 8.1.2.2 is showing the
test case with detailed. Here I have evaluate the actual test result of blood donor information
system.
Expected
Result
Click the Save button to
Not Saved in the
Record the details in the Store the details in Popup an error
01 database, there is an
database without filling any the database message
error message
fields
Need to be
Click the Save button to
Store the details in store all the Successfully Saved in
02 Record the details in the
the database details in the the database
database with filling fields
database fields
Successfully save the
Type already registered id Avoid the Show an error
03 donor details to the
of the donor registration message
registered donor details
Changing with
Check the Valid blood Easily can select
04 using mouse Successfully changing
groups in the combo box the blood group
scroll
Table 8.1.3.2 Test Case for Donor Registration
Error Correction (Table 8.1.3.2 and Test No 3)

The reason for this error is the primary key, I mean during my database design I forget to fix
the primary key for the donor registration table. After the correction and test result of the
donor registration in the table 8.1.3.2.1
Type already registered id Avoid the Show an error Not Saved, Popup an
03
of the donor registration message error message
Table 8.1.3.2.1 Test Case for Donor Registration Error Correction

PDIE/ MP
Test the Actual Result of the Donor Maintaining

I have already created the test case for the donor maintaining table 8.1.2.3, and table 8.1.2.4
are showing the test case with detailed. Here I have evaluate the actual test result of blood
donor information system.
Expected
Result
Give a warning
message called
Click update button without Update the details
01 Please select Update successfully
selecting the donor id of current donor
an id of the
donor
Give message
Click the update button with Update the details
02 called Updated Updated successfully
selecting the current donor of current donor
successfully
Delete the donor by Delete from the
03 Delete the donors Deleted successfully
selecting the donor id database
Hide the main
Without hiding the main
window and
04 Logout process Logout the system window and display login
display the login
window
window
Table 8.1.3.3 Test Case for Donor Maintaining
Error Correction (Table 8.1.3.3 and Test No 1, 4)

These errors are called run time errors, because during the run time only display these kind
of errors. Reasons for these errors while developing the system there are some misuse
codes were written by me. So now I have correct the codes and test the system and the
result of that testing is showing in the table 8.1.3.3.1
Give a warning
message called
Click update button without Update the details
01 Please select Update successfully
selecting the donor id of current donor
an id of the
donor
Hide the main
Hide the main window
window and
04 Logout process Logout the system and display login
display the login
window
window
Table 8.1.3.3.1 Test Case for Donor Maintaining Error Correction

PDIE/ MP
Test the Actual Result of Sending SMS

I have already created the test case for the sending SMS to registered donors table 8.1.2.5
is showing the test case with detailed. Here I have evaluate the actual test result of blood
donor information system.
Expected
Result
Successfully
01 Change the COM Port Connect with GSM connected with Show an error message
the GSM
Without selecting any field Popup an error Display error Display send message
02
and click send button message message successfully
Display Popup the message
Selecting the field and click
03 Sending the SMS Successfully called Successfully
send button
Send message send the message
Send to current city
Selecting donor by using Send the SMS
04 or blood group Successfully sent
city, and blood group to donor
donor
Table 8.1.3.4 Test Case for Sending SMS

These errors also called runtime errors, because during running the system then only these
kind of errors can be seen in the display. After plugged the dongle we have check the which
port is connected to dongle. Then only we can make select one port number from the system
and send the SMS to registered blood donors.
Successfully Successfully
01 Change the COM Port Connect with GSM connected with connected with GSM
the GSM network
Without selecting any field Popup an error Display error

02 Display error message
and click send button message message
Table 8.1.3.4.1 Test Case for Sending SMS Error Correction

PDIE/ MP
Test the Actual Result of Reports View

I have already created the test case for the report view table 8.1.2.6 is showing the test case
with detailed. Here I have evaluate the actual test result of blood donor information system.
Expected
Result
Display the
Access to the report of the View the all the donor details in Display the result in the
01
donors details donor details the crystal crystal report
report
Display the
View the all the
Access to the report of the donor contact Display the result in the
02 donor contact
donors contact details details in the crystal report
details
crystal report
Display the
Access to the report of the View the all the event details in Display the result in the
03
event details event details the crystal crystal report
report
Print the reports via using Can printed any
04 Printing the reports Printed the reports
printer kind of reports
Display the
View the current donor View the current donor
05 View the donor current donor
details details
details
Display the
06 Search donor by id Searching Display the search result
search result
Table 8.1.3.5 Test Case for Reports view
Error Correction
Here I havent got any errors, reports are very important to check the current donors details
and the all the donors details at one time, and of course, we can find the donors contact
details without any other details. Not only the donors details, events details also can be see
using these kind of function.
Again I prefer to tell I havent got any error during testing the reports view function.

PDIE/ MP
Test the Actual Result of Create Admin & User

I have already created the test case for create new admin & user, table 8.1.2.7 is showing
the test case with detailed. Here I have evaluate the actual test result of blood donor
information system.
Expected
Result
Update the
Change the user id and Update Display updated
01 username and
click update button successfully successfully
password
Clean the text

02 Click clear button Clean the text fields Nothing happened
fields
Click the text box and type

Creating new user Created
03 new username and Created successfully
or admin account successfully
password and click create
Delete the
Click delete button to delete Delete current user current user or Nothing happened any
04
current user or admin or admin admin from the changes
database
Change user or admin id View the username
View each user Not changing any
05 and view the user name and password of
and admin username and password
and password of each each user & admin
Table 8.1.3.6 Test Case for Create Admin & User
Error Correction (Table 8.1.3.6 and Test No 2, 4, 5)

Here test no 2 error is function is missing to called to clear button, test no 4 is runtime error,
during test period only I have analyze that error and fix, and test no 05 these one also make
error during the runtime.
Clean the text Cleared the text in the

02 Click clear button Clean the text fields
fields text field
Delete the
Click delete button to delete Delete current user current user or
04 Deleted successfully
current user or admin or admin admin from the
database
Change user or admin id View the username
View each user Changing with user or
05 and view the user name and password of
and admin admin id
and password of each each user & admin
Table 8.1.3.6.1 Test Case for Create Admin and User Error Correction

PDIE/ MP
Test the Actual Result of Creating New Events

I have already created the test case of creating new events table 8.1.2.8 is showing the test
case with detailed. Here I have evaluate the actual test result of blood donor information
system.
Expected
Result
Click the create button Popup error Display an error Save successfully in the
01
without filling any details message message database
Display
Click the create button after Save the event Save in the database
02 message save
filling details details with successful message
successfully
Display
Update the event details Update event message Update event details in
03
buy using event id details updated the database
successfully
Display
Click delete button to delete Delete event by message Delete the event detail
04
current event using event id deleted from the database
successfully
View the event
View the event
details by Not change according to
05 Changing the event id details by changing
changing the the event id
event id
event id
Table 8.1.3.7 Test Case for Creating New Events

These errors also called runtime errors, because during running the system then only these
kind of errors can be seen in the display. Reasons for these errors are the SQL commands.
Click the create button Popup error Display an error Show an error
01
without filling any details message message message
View the event

View the event
details by Can view the event
05 Changing the event id details by changing
changing the details successfully
event id
event id
Table 8.1.3.7.1 Test Case for Create New Events Error Correction

PDIE/ MP
Test the Actual Result of Search Blood Donors

I have already created the test case of search blood donors table 8.1.2.9 is showing the test
case with detailed. Here I have evaluate the actual test result of blood donor information
system.
Expected
Result
Select a one Select a

01 Select the Search by list Selected a method
searching method method
Display the
Select search by donor id Select donor id and Display the donor id
02 donor id
and click next search window
window
Display the
Select search by donor Select donor Display the donor
03 donor address
address and click next address and search address window
window
Display the
Select search by donor Select donor blood Display the donor blood
04 donor blood
blood group and click next group and search group window
group window
Display the
Select search by donor Select donor name Display the donor name
05 donor name
name and click next and search window
window
Type id of the current blood Searching current Display the Displayed the search
06
donor and search blood donor search result result
Close the
07 Click close button Close the window Closed the window
window
Table 8.1.3.8 Test Case for Search Blood Donors

PDIE/ MP
8.2 Project Performance Analysis

8.2.1 Budgeted Cost for Work Schedule (BCWS)
Make deliver the project successfully we have to work with allocated time budget, and the
cost for working on that project. As well as I have developed a standalone application which
is run inside the computer, or any other windows platform. And I have already created a
budget cost for this project.
The budgeted cost of individual tasks as Im scheduled in the project plan, based on the
costs of the resources that are assigned to those tasks, plus any fixed costs that are
associated with the tasks. This is the budgeted cost of work scheduled (BCWS).
Reason for Cost Description of Cost Cost of Description Total Cost

Cost for the travelling to known about
Travel Cost Rs. 2, 000 Rs. 2, 000
the project and the documentation
Searching the Details of the System,
Internet Data Cost 1 GB = Rs. 200 , 4 GB Rs. 800
and Documentation
Papers for Making the Function of the
Paper Costs 1 A4 = Rs. 2 , 100 A4 Rs. 200
System, and for other works
Documentation To create the Project Book 1 Book = Rs. 2, 000 , 3 Book Rs. 6, 000
Dongle for Connect with GSM

Dongle Network to Send the SMS to Blood 1 Dongle = Rs. 3, 000 Rs. 3, 000
Donors
SIM Card To Send the SMS to the Donors SIM Card = Rs. 200 Rs. 200
Activate the SMS Package to Send

Activate SMS 1 Month = Rs. 150 Rs. 150
the SMS to the Donors
Total Cost for the Project Rs. 12, 350

Table 8.2.1.1 Budgeted Cost for Work Schedule
Project duration: 5 months

Project Cost (Rs.): Rs. 12, 350
Percent complete: 100% (as per the schedule)
Table 8.2.1.1 is showing the cost for work schedule of the blood donor information system.
The total cost is 12, 200 rupees to develop this system successfully. The more cost to print
the documentation, I mean to bind the Project report. And low cost for to buy a SIM Card and
A4 Papers. This my estimation of the cost schedule.

PDIE/ MP
8.2.2 Budgeted Cost for Work Performed (BCWP)

This is cost for so far, I mean I have to complete the project within 5 months. So far 4
months has finished. Now table 8.2.1.2 is showing the cost in the 4 months.
Reason for Total Cost with

Description of Cost Cost of Description BCWS
Cost 4 Months
Cost for the travelling to known
Travel Cost about the project and the Rs. 2, 000 Rs. 2, 000 Rs. 1, 500
documentation
Internet Data Searching the Details of the
1 GB = Rs. 200 , 4 GB Rs. 800 Rs. 600
Cost System, and Documentation
Papers for Making the Function
Paper Costs of the System, and for other 1 A4 = Rs. 2 , 100 A4 Rs. 200 Rs. 120
works
1 Book = Rs. 2, 000 ,
Documentation To create the Project Book Rs. 6, 000 Rs. 00.00
3 Book
Dongle for Connect with GSM
Dongle Network to Send the SMS to 1 Dongle = Rs. 3, 000 Rs. 3, 000 Rs. 3, 000
Blood Donors
SIM Card To Send the SMS to the Donors SIM Card = Rs. 200 Rs. 200 Rs. 200
Activate the SMS Package to

Activate SMS 1 Month = Rs. 150 Rs. 150 Rs. 120
Send the SMS to the Donors
Total Cost for the Project Rs. 12, 350 Rs. 5, 540
Table 8.2.2.1 Budgeted Cost of Work Performed
8.2.3 Actual Cost of Work Performed (ACWP)

The Actual Cost is the total cost incurred for the actual work completed to date; or simply
put, it is the amount of money you have spent to date. And for this project actual cost of
details,
Actual Project duration: 5 months

Actual Cost (Rs.): Rs. 12, 350
Time elapsed: 4 months
Actual Cost: Rs. 5, 540
Time elapsed: 4 months



PDIE/ MP
8.3 Change Control of Project

To manage a schedule, the project manager must know how the work is progressing
compared to the master schedule and, if necessary, make changes to keep the project on
time. As well as my project also got some changes during the working period.
8.3.1 Change of Schedule

Milestones provide the opportunity for project management to focus on completing activities
that will have the greatest impact on the schedule. On complex projects, focusing on the
milestones is useful for communicating important dates to the entire project team. Project
team members can then adjust their efforts to complete the activities connected to the
milestone events.
Many project leaders believe that time lost on early activities can be made up toward the end
of the project. Hard decisions about paying overtime and working weekends are often
delayed until the end of the project when the pressure to complete the project on time
becomes much stronger. Project managers who focus on milestone events create a sense of
urgency to meet the milestone deadlines and spread the urgency to complete the project
over the life of the project. Projects that meet milestone dates are more likely to meet project
completion dates.
Here I have change and add some extra days to complete my project.
Task Name Duration Changed Duration

1. Planning 6 Days 7 Days
1.1. Conceptual Planning 4 Days 5 Days
2. System Design 13 Days 16 Days
2.1. Design Review 2 Days 5 Days
3. Coding 11 Days 15 Days
4. Testing 17 Days 19 Days
4.1. Programme Test 6 Days 7 Days
4.2. System Test 5 Days 6 Days
5. Maintenance 9 Days 11 Days
5.1. Bug Fixing 3 Days 5 Days
6. Final Documentation 16 Days 18 days
Table 8.3.1.1 Change of Schedule
As I told, I have changed some schedule of the project and add some more extra days. Then
within these days I have finalized my project as much possible.

PDIE/ MP
8.3.2 Change of Resource

The schedule of activities is constrained by the availability of resources. If we apply those
thing to our software project development, then it will be given a better process.
Skill Sets Needed From the Resources

Use different skill sets for human resources required for software development projects,
such as,
Programmers to develop the software programs needed for the project experts in
the chosen programming language.
Graphic Designers to design the graphics and the web pages / front-end required
for the project.
Database Administrator to design the database and assist the programmers in
optimizing data retrieval queries so that the response time is shorter.
System Architects to develop the software architecture for the project.
System Integrators to integrate various components of the project and ensure that
the end product is built conforming to the specifications.
Functional Experts who are experts in the application domain of the project?
These are some important resources in the software development,

Time
Human Resources the most crucial of all the resources
Computer Resources
Money
If we take the time period of the software development is not enough to complete
successfully, because of that I have adjusted the date in the work break down structure. Now
I feel very exiting with this project.
And the computer resources even change according to the situation as well as early I
havent plan to fix a function called sending SMS, after few days I got to know that function
and change the time period of this software project and some resources.
As we know to send SMS mean, definitely we need to connect with the GSM Network then
only we can connect with others. To connect that I bought a one dongle with spent 3,000
rupees, so know my budget even change in that category. So really know any kind project
can be make any kind changes.

PDIE/ MP
8.4 Suggestion, Recommendation and Areas need to be improved

In future we need advanced technology systems, so we must need some changes in the
system development life cycle and other process.
A process can be as big and broad as the entire software development process, or as small
and as focused as a process for design inspections. Regardless of its size, every process is
an opportunity for improvement. Software process improvement can be any action taken to
make a software process better than that which exists.
Software Process Improvement

Understanding existing processes.
Introducing process changes to achieve organizational objectives which are usually
focused on quality improvement, cost reduction and schedule acceleration.
Most process improvement work so far has focused on defect reduction. This reflects
the increasing attention paid by industry to quality.
However, other process attributes can be the focus of improvement.
Why Need of Software Process Improvements

We want to build better software projects (cheaper, more dependable, quicker, )
We really dont know how to measure the software projects characteristics.
There, measure the process under the assumption a better process will produce a
better software projects.
Principal Product Quality Factors
Figure 8.4.1 Principal of Software Projects Quality Factors
Figure Source - http://nas.uhcl.edu/helm/swen5231/Process/sld008.htm

PDIE/ MP
For large software projects with average capabilities, the development process
determines project quality.
For small software projects, the capabilities of the developers is the main
determinant.
The development technology is particularly significant for small software projects.
In all cases, if an unrealistic schedule is imposed then software quality will suffer.
The Module Testing Activity
Figure 8.4.2 Module Testing Activity
Figure Source - http://www.slideshare.net/waruimaina/9process-improvement-chapter-9
Module testing is the testing of complete code objects as produced by the compiler when
built from source.
A library may be composed of a single compiled object or several compiled objects. There is
only a slight difference between unit testing and module testing. Modules are fully formed
chunks of coherent source code that can typically be tested by driving a few function
signatures with various stimuli. On the other hand, unit testing (which is considered as part
of the implementation phase for this software development process) may involve testing one
small part of a function that will never formally implement any function interface.

PDIE/ MP
Suggestion for Improvement of Blood Donor Information System

Object Oriented Programming Language
Need to reuse more than just code, need to reuse all kinds of experience. Because all the
time we cannot crate functions for the list of classes. So its very easy to call that method in
the suitable place. I have used few object oriented methods in the blood donor information
system.
In future I have plan to separate those methods into one and make it simple and object
oriented way.
Creating Nice Interface GUI

Here already I have created nice interface, even in future I can give more attraction interface
to the blood donor information. Because interface is give the easy way to manage or control
the system for the users. If its attractive interface the user can get more benefits.
Any we need to maintain the professional standard on the interface, because some interface
look like a kinder garden. So we to make it the interface in the professional way.
Separate the Classes in to Packages

Separate the classes in to packages mean normally that is the object oriented, because it is
give more use for set of codes, I mean easily use the methods and easily find the classes in
the packages.
In future I can create the classes in the different packages of it.
Centralization Database
Make the database into centralization by using a database server. Because if all the data of
the donors are in a one database mean thats very useful to contact or communicate the
donors easily and quickly.
So we can make the database of blood donor information system into the centralization
database server. So its safe because in a one place of all the data. Easily can make security
purpose for the database server.
Use of New Tools

Use of .NET framework easily use much tools in the GUI. Then system will look more useful
getting the tools. Using menu strip option for access to the windows in the system. As well
as their many tools we use as well.

PDIE/ MP
Support and Maintenance

9.1 Reason for Termination of Project
It is a fact that most project management professionals are not aware that project
termination procedures are critically important for successful as well as failed or prematurely
abandoned projects.
But my project not got termination, but here some fact why the projects are getting
termination before closing date.
Every project has to officially end sometime. Project termination need not necessarily mean
project failure or premature abandonment. A project may be terminated for a variety of
reasons, including successful completion of the endeavor. We'll take a closer look at what
some of these reasons are and how to know when to terminate a project.
Reasons for Project Termination

Here are a few reasons why a project gets terminated before the natural closing date.
Project is completed ahead of schedule and handed over to the sponsors/users.

Premature abandonment due to technical grounds that impede achievement of core
goals.
It is suddenly found that another group publishes results in same core area of
interest.
The principal investigator or an equitant person suddenly quits and the project cannot
continue as planned and the project has to terminated, as putting on hold will be
counter-productive.
Unanticipated loss of human, funding and other valuable resources.
A variety of insurmountable problems may force termination of the project.
An interim review suggests the project will not help achieve the desired objectives.
Person Responsible for Termination Decision

It is the principal investigator (PI) who is entrusted with the task of conducting periodic
reviews of the project and is responsible for closely monitoring the project progress
throughout the project life cycle. Thus, the exact closing date for a project has to be decided
by the principal investigator after consulting the co-principal investigators and subprogram
leader.
The principal investigator will be aware that for all projects, final technical and financial
reports will have to be prepared and presented. It is therefore only to be expected that the
principal investigator will work closely with the subprogram leader to handle necessary
project termination work. It is believed that under certain extraordinary circumstances, the
subprogram leader may seek a time extension for completing the project, provided no
additional funds are demanded.

PDIE/ MP
9.2 Client Certification
Research and Development Centre

BCAS Kandy Campus
CLIENT ACCEPTANCE CERTIFICATE

Purpose: This form is completed at the end of the Project where the client is handing
over a deliverable to the Company. The form verifies what deliverables are being turned
over to the Company and that the client has accepted / approved those deliverables.
Project Name Blood Donor Information System
Project Number << >>
Project Sponsor Individual
Leaner Details M.N. Azeem Mohamed azeemmohamed40@gmail.com

+96 75 200 4415
(name) (email)
(phone number)
Project Description
This project is about Blood Donor Information System. Purpose
of this system registering the blood donors, and critical situation
easily can communicate with registered blood donors via SMS.
SDLC Stage Chapter 1: Introduction

Chapter 2: Literature review
Chapter 3: Analysis
Chapter 4: Design
Chapter 5: Method and methodology
Chapter 6: Results and Discussion
Chapter 7: Testing and evaluation
Chapter 8: Support and maintenance
Chapter 9: Summary and conclusion
Important Notes for Completing this Document
Each section of the Client Acceptance Certificate must be completed in full. If a particular
section is not applicable to this project, then you must write Not Applicable and provide a
reason.
Important Note: No sections are to be deleted from this document. Text contained within
<< >> provides information on how to complete that section and can be deleted once the
section has been completed.
This template is owned and maintained by the BCAS Kandy campus.

PDIE/ MP
LIST OF CLIENT DELIVERABLES COMPLETED

Deliverables A working and completed system is for the hospitals or the
blood camps.
Acceptance Response Accepted

Not Accepted until below issues are addressed
Accepted provided below issues are addressed
Issues Normally I havent got any issues. But I have spent lots time to
develop this system.
Additional Comments I have completed as my knowledge. In future this system is very

useful for the hospitals to contact the blood donors immediately.
PREPARED BY
Project Manager(Client)
(name) (signature) (date)
APPROVALS
Sponsor
Project
Supervisor(Academic)

PDIE/ MP
9.3 Close-Out Report

A. General Information
Blood Donor
Project Title: Information System Project category : Softwares &
Databases
Leaner: M.N. Azeem Supervisor: Mr. Munshif

Mohamed Cassim
Prepared by: M.N. Azeem Date/ Project Number:

Mohamed
B. Project Deliverables
List all Project Deliverables and the date each was accepted by the user. Identify any contingencies
or conditions related to the acceptance.
Deliverable Date Accepted Contingencies or Conditions
A Useful System Called Blood

Donor Information System (Donor Null
Registration and Maintaining)
Project documentation and user

manual Null
C. Performance Baseline
PROJECT BUSINESS Performance Goal Results

OBJECTIVE
Contact the Donors Contact the Donor via SMS Objective achieved
Programs runs at expected

Fast execution time Objective achieved
Saving Lives by using

Pubic Servicers Objective achieved
System
A worthy product with best

Cost effective Objectives achieved
use
The above stated project business objectives and servicers alongside the performance goal and their
respective results were all achieved. A look on the below cost base line would allow to see how the
project had been successful and hence cost effective as well.

PDIE/ MP
D. Cost (Budget) Baseline
State the Planned Cost and Funding for the project, as approved in the Initial Cost Baseline and the
Project Charter. State the Actual Cost and Funding at completion. Document and explain all cost
and funding variances, including approved changes to the cost baseline.
Expenditures (Rs.000)
Planned Actual Variance Explanation
Internal Staff Labor - - - No internal staff
Services Rs. 3000 Rs. 3250 +250 Electricity + transportation
Software Tools - - - Not Specify
Hardware Rs. 3000 Rs. 3000 0 Dongle
Materials and
Supplies - - - No special materials
Facilities Rs. 6500 Rs. 7000 +500 Internet and printing
Telecommunications Rs. 150 Rs. 250 +100 Phone calls
Training - - - No special training observed
Contingency (Risk) - - - No special risks incurred
Total Rs. 12, 650/- Rs. 13, 500/- Rs. 850/-
Funding Source (Rs.000)
General Fund Rs. 5000 Rs. 4000 -1000 Cash at bank
Non-General Fund - - - -
Federal - - - -
Other Rs. 5000 Rs. 5000 Rs. 000 Cash from parents
Total Rs. 10, 000 Rs. 9, 000 0 -

PDIE/ MP
E. Schedule Baseline
Compare the initial approved schedule baseline against the actual completion dates. Enter the
planned start and finish dates from the initial schedule baseline. Document all actual start, finish
dates, and explain any schedule variances, including approved changes to the schedule baseline
Planned Start Actual Start Planned Finish Actual Finish

WBS Elements
Date Date Date Date
Activity or Task
1.1 Planning 20 / 09 / 2014 22 / 09 / 2014 23 / 09 / 2014 24 / 09 / 2014
1.1.1 Conceptual Planning 23 / 09 / 2014 23 / 09 / 2014 26 / 09 / 2014 27 / 09 / 2014
1.2 System Analysis 27 / 09 / 2014 27 / 09 / 2014 07 / 10 / 2014 07 / 10 / 2014
1.2.1 Functional Requirements 29 / 09 / 2014 29 / 09 / 2014 30 / 09 / 2014 30 / 09 / 2014
1.2.2 Technical Requirements 01 / 10 / 2014 02 / 10 / 2014 02 / 10 / 2014 05 / 10 / 2014
1.2.3 Requirements Specification Review 03 / 10 / 2014 03 / 10 / 2014 06 / 10 / 2014 06 / 10 / 2014
1.3 System Design 04 / 10 / 2014 05 / 10 / 2014 21 / 10 /2014 22 / 10 /2014
1.3.1 Internal / External 07 / 10 / 2014 07 / 10 / 2014 08 / 10 2014 09 / 10 2014
1.3.2 Design Review 09 / 10 / 2014 09 / 10 / 2014 10 / 10 / 2014 10 / 10 / 2014
1.3.3 Detailed Project Development 13 / 10 / 2014 14 / 10 / 2014 21 / 10 / 2014 23 / 10 / 2014
1.4 Coding 20 / 10 / 2014 20 / 10 / 2014 01 / 11 / 2014 06 / 11 / 2014
1.4.1 Codes Review 22 / 10 / 2014 22 / 10 / 2014 01 / 11 / 2014 05 / 11 / 2014
1.5 Testing 02 / 11 / 2014 03 / 11 / 2014 24 / 11 / 2014 24 / 11 / 2014
1.5.1 Programme Test 24 / 10 / 2014 24 / 10 / 2014 31 / 10 / 2014 31 / 10 / 2014
1.5.2 System Test 03 / 11 / 2014 03 / 11 / 2014 07 / 11 / 2014 08 / 11 / 2014
1.5.3 Bug Reports 10 / 11 / 2014 12 / 11 / 2014 13 / 11 / 2014 14 / 11 / 2014
1.5.4 Test Summery 14 / 11 / 2014 14 / 11 / 2014 18 / 11 / 2014 18 / 11 / 2014
1.6 Implementation 25 / 11 / 2014 27 / 11 / 2014 09 / 12 / 2014 09 / 12 / 2014
1.6.1 User Documentation 19 / 11 / 2014 19 / 11 / 2014 20 / 11 / 2014 20 / 11 / 2014
1.6.2 System Documentation 21 / 11 / 2014 22 / 11 / 2014 25 / 11 / 2014 26 / 11 / 2014
1.7 Maintenance 10 / 12 / 2014 10 / 12 / 2014 22 / 12 / 2014 22 / 12 / 2014
1.7.1 Review the System 26 / 11 / 2014 27 / 11 / 2014 27 / 11 / 2014 27 / 11 / 2014
1.7.2 Maintaining the System 28 / 11 / 2014 28 / 11 / 2014 01 / 12 / 2014 02 / 12 / 2014
1.7.3 Bug Fixing 02 / 12 / 2014 02 / 12 / 2014 04 / 12 / 2014 04 / 12 / 2014
1.7.4 Upgrade the System 05 / 12 / 2014 06 / 12 / 2014 08 / 12 / 2014 09 / 12 / 2014
1.8 Final Documentation 09 / 12 / 2014 02 / 01 / 2015 10 / 01 / 2015 05/ 02 / 2015

PDIE/ MP
F. Scope
Document any changes to the Project Scope and their impact on Performance, Cost, or Schedule
Baselines.
Scope Change Impact of Scope Change
G. Operations and Maintenance
Describe the plan for operation and maintenance of the product, well, or service delivered by the
project. State the projected annual cost to operate and maintain the product, good, or service.
Identify where and why this projection of cost differs (if it differs) from the Project Proposal. If the
operation and maintenance plan is not in place, what is the target date for the plan and what is the
impact of not having operations and maintenance for the product, well, or services in place.
1. Operations and Maintenance Plan
This project has to be handled with proper care. The system codes very longer than others,
and the user have computer based knowledge to operate the system.
Failing to that, the following problem is likely to occur:
**The entire program may not execute successfully
**And hence the expected output may not be seen
Therefore its very important that this program is maintained by a learned person. If for e.g. the
client wills to increase the capturing frame number or even wishes to change the saving directory a
backup of the original program must be taken first before any changes shall be considered to take
effect.
Need to back up the data twice a month.

However a review on the entire program must be made in every two weeks basis.

PDIE/ MP
2. Operations and Maintenance Cost
Expenditures ($000)
Internal Staff Labor - - - -
Services - - - -
No much software
Software Tools - - - tools used
Hardware - - - -
Materials and Supplies - - - No special M&S
Decrease in electricity
Facilities Rs.1, 000 Rs. 800 -200 charges
Telecommunications Rs. 600 Rs. 900 +300 Heavy usage
Training Rs. 300 Rs. 200 -100 No much training
Contingency (Risk) - - - -
Total Rs. 1, 900 Rs. 1, 900 Rs. 00
Funding Source ($000)
General Fund Rs. 5000 Rs. 4000 -1000 Cash at bank
Non-General Fund - - - -
Federal - - - -
Rs. 5000 Rs. 5000 Rs. 000 Cash from parents

Other
Total Rs. 10, 000 Rs. 9, 000 0 -

PDIE/ MP
H. Project Resources
List the Resources specified in the Resource Plan and used by the project. Identify to whom each
resource was transferred and when it was transferred. Account for all project resources utilized by the
project.
Person or
Resource
Organization Who Turnover Date
(Describe or name the resource used)
Received Resource
Project Team
Mr. Munshif Help to develop 11th November 2014
Mr. Nuzrath Giving a plan 15th August 2014
Customer Support
Facilities
Equipment
Dongle (Modem) Parents 12th June 2014
Software Tools
Visual Studio 2010 BCAS Kandy Campus 14th July 2014
Crystal Report BCAS Kandy Campus 14th July 2014
SQL Server 2008 BCAS Kandy Campus 14th July 2014
Other

PDIE/ MP
I. Project Documentation
Identify all project documentation materials stored in the project library or other repository. Identify the
type of media used and the disposition of the project documentation (see Communications Plan).
Storage
Report(s) and Document(s) Media Used Location Disposition
Feasibility Studies Report Doc, PDF DVD Feasibility Study of System
Specification Report Doc, PDF DVD Functional and Non-Functional
User Interfaces Report Doc, PDF, MP4 DVD Images of Interfaces
System Diagram Report Doc, PDF DVD Sample Diagrams
SDLC Report Doc, PDF DVD Introduction to SDLC
System Testing Report Doc, PDF DVD Testing Methods, Actual Test
User Manual Documentation Doc, PDF DVD User Manual
J. Lessons Learned
Identify Lessons Learned for feedback to the Commonwealth Project Management process. Lessons
Learned should be stated in terms of Problems (or issues) and Corrective Actions taken. Provide a
brief discussion of the problem that identifies its nature, source, and impact. Site any references that
provide additional detail. References may include project reports, plans, issue logs, change
management documents, and general literature or guidance used that comes from another source.
Statement of Problem Discussion References Corrective Actions

PDIE/ MP
K. Dates for Post Implementation Review and Report
Identify the date for completing the post implementation report and the person responsible for this
action.
Action Date Responsible Person
Post - Implementation Review

Post - Implementation Report
L. Approvals
Position/Title Signature/Printed Name/Title Date

Project Supervisor
Project Sponsor
Project coordinator

PDIE/ MP
9.4 User Manual

Blood Donor Information system is a standalone application which is allowed to register the
blood donors, maintain the donors, and contact the donors quickly via sending SMS. Here I
will describe how we can use those function with screen capture of the system.
How to run the application

Make sure first of all we have to install this application on the computer or the Leptop. Then
figure 9.4.1 is showing how to run the application, just double click the icon in the desktop
and run the application.
Double click and open the

Blood Donor Information
System after the installation.
Figure 9.4.1 Run the Blood Donor Information System
After double click the icon, then there is one splash screen will pop up in the display, and
after 3 to 6 second the progress will be load, then the logging window will display in the
computer or leptop monitor.

PDIE/ MP
How to logging to the system
After the progress the login window will be display in the monitor. Login function is give
security for any kind system. As well as blood donor information system also have these kind
function. If the user name and password is wrong error message will pop up on the display
figure 9.4.2 is showing.
Figure 9.4.2 Incorrect Username or Password
If the password is not matching with the username, then this kind of error message will be
display. If the administrator given correct username and password in the correct text fields in
the login window figure 9.4.3 is showing,
Figure 9.4.3 Correct Username or Password
After fill all the text fields with the correct username and password, then the user need to
click the login button to access or display the main admin window.

PDIE/ MP
How to register the blood donors

Blood donor registration is the main function of the blood donor information system because
without registering any of person, we cannot continue the system to make changes. To
make the register of each donors, we must know how fill the text fields as below shown
figure 9.4.4.
Figure 9.4.4 Donor Registration Window
If we miss some important text fields then it wont save in the database. So we should know
what thing need to be complete are.
Donor ID Donor id must be type in that field, it is a unique, cant be repeated same
numbers.
Name Name also need to be fill then only system allow to record the data.
Blood Group We cannot leave this stage, because this is one of important for the
system.
After complete those fields then the data or blood donor details recorded in the database.
And display a message box figure 9.4.5 is shown.
Figure 9.4.5 Message Box of Donor Registration

PDIE/ MP
How to delete a blood donor
Delete function is come under the maintaining donor details in the blood donor information
system. To delete a one donor make sure we have to select that particular donor by using
donor id figure 9.4.6 showing,
Figure 9.4.6 Selecting the Donor ID
Select a current donor by using donor id, and if that donor is not important or no need for the
future works then just click the delete button to delete that donor with details completely.
Figure 9.4.7 Delete the Current Blood Donor
After delete the current donor form the list then there is one confirmation message will be
display in the screen figure 9.4.8 is showing.
Figure 9.4.8 Confirmation Message for Deleted

PDIE/ MP
How to update the details of a blood donor
Update or edit is normally making some changes to the details. As well blood donor
information system have these kind function to edit the blood donor details. Just click the edit
button figure 9.4.9 is showing without selecting any donor by using donor id.
Figure 9.4.9 Edit or Update Blood Donor Details
After clicking the edit button there is window called edit the donors will be display figure
9.4.10 showing.
Figure 9.4.10 Edit the Blood Donor Details
Just select the donors via using donor id. So then we can make any kind of changes about
the selected donors in the list box. Sometimes the donor might be change their mobile
numbers and other email addresses according to their situation. So we should need
connection with the donors to contact them in a critical or emergency situation.
The Administrator can select one donor and make the changes according to that donors
prefer.

PDIE/ MP
How to create new event
Event management is giving an idea about the blood camps, I mean when the next blood
donation will be, and where it is. So those we can add to the system, this function is only
allow to the administrator to create new events.
Figure 9.4.11 Create New Events
First of all we should fill those empty text boxes like figure 9.4.11. Then press the save to
create new events. After few second new event has been created in the database figure
9.4.12 is showing that function in clearly.
Figure 9.4.12 Table view of the events
Here its showing the events details in clearly. Even we can search the events by using
events id. So you can just type the wanted event by using event id in the search field.

PDIE/ MP
How to maintain the event
Maintain mean normally managed by the system administrator. Blood donor information
system even got the save privileges. The administrator can edit or delete the events
according to their preference. Here figure 9.4.13 showing how to edit an event. I.e. already
the place got BMICH after selecting that particular event and change that place into
Sugarathasa Stadium.
Figure 9.4.13 Edit the Event
To delete the old or unwanted event just click the delete button with selected events id. Then
there is one message will display in the window about to confirm the delete via using two
button Yes, and No. If we want delete that event press Yes, to keep that even as well it
is press No.
Figure 9.4.14 Delete the Event
There is one button called clear, this is for to clean the text fields, and make it empty. In the
figure 9.4.13 showing that button clearly.

PDIE/ MP
How to send SMS to blood donors
SMS is main function of this system, because this is the fastest way to communicate with
blood donors in the critical situation. To run this function, make sure we need a GSM Modem
or Dongle to connect with the GSM Network. Then only we can use that system.
Figure 9.4.15 is showing that interface of the Sending SMS to the Donors. Here there three
different details can be manually fix and we can send a SMS to the Donors. Such as we
select the donors via district, blood group, and the duration of period.
Example,
- Only selected a district and send the SMS, it wont look any blood group, and
duration. All registered donors can receive a SMS who are in the particular
district.
- Selecting the one of district, blood group, and duration. Then the system check all
the details in the database. And process that particular command and send the
SMS to the registered donors.
Figure 9.4.15 SMS to the Donors
There is a one default message in that particular message field, so if we want right
something new just click the clear button to clean that message box and whatever we want
we can type the message and clicking the send to send to the donors. Make sure the
confirmation message.
Figure 9.4.16 Confirmation of Sending SMS

PDIE/ MP
How to search blood donor
The administrator and user can search the particular registered donors from the list. Its easy
way to search that particular donor with their details. There are five different search option
have with this system such as using,
- Donor ID
- Donor Name
- Donor Address
- Donor City Selecting the Search Option
- Donor Blood Group
Figure 9.4.17 Search Donors by Name
Using the selecting search option and easily do a search with different search option and
figure 9.4.18 is showing that window.
Figure 9.4.18 Searching Options
Selecting the Search Option
Select one search option and click next button then particular search window will be display
in the monitor as figure 9.4.19 showing.
Figure 9.4.19 Search by City

PDIE/ MP
How to create new administrator and user

Admin and users are the people manage and handling this system. So if we want to create
new admin or the users for manage this system. But here any of users cannot create any
kind of account such for admin or user. This is only administrator.
Figure 9.4.20 Create New Administrator
Same like we can create new users showing figure 9.4.21.
Figure 9.4.21 Create New User

PDIE/ MP
How to maintain the administrator and user

Maintaining the admin and user mean making some changes in their particular account I
mean remove that account from the system storage. Now we will see how delete the details
of current account.
Figure 9.4.22 Delete the Current User
Make sure first of all we should select the particular user by using the ID. Then just click the
delete button to delete that particular account from the list figure 9.4.22. Confirmation of the
deleted will be display figure 9.4.23.
Figure 9.4.23 Delete Confirmation of the Users
Likewise we can delete the administrator account and user account clicking just one button,
but this function is only allow for administrator to make changes. Any other account cannot
access to this maintain function without authorized permission.

PDIE/ MP
How to view the reports
Report is normally view the details of the particular details. The blood donor information
system have got some important reports, such figure 9.4.24 showing.
Figure 9.4.24 Window of Reports
There are three types of reports can view with details. If we Donor registered list. After few
second it will be display figure 9.4.25 is showing that particular report.
Figure 9.4.25 Detailed Report View of Blood Donors
And easily view the report and make good understanding of the details of each and each
donors.

PDIE/ MP
How to print the reports
Printing can done by using printer. The admin or the user can view the report and print each
details of donor in hard paper.
Figure 9.4.26 Click the Print in the Report
Print
After click the print button the print properties window will be display figure 9.4.27 is showing
that properties of printing.
Figure 9.4.27 Print Properties Window
Here just select the printer and setup the pages then click the print button to print the details
of the current details of donors.

PDIE/ MP
Summary and Conclusion

In this project I have learned how to manage the software projects and developing software
projects. Normally any management system have a value for that. So in my project even
there is a value to save the lives. Because using this system any authorized person can
easily contact the blood donors those who were already registered.
Here there some more advanced functions with this blood donor information system.
1. Blood donor registration is normally happening in the system. But here cannot
duplicate the id of blood donor.
2. Administrators only can maintain the blood donors details.
3. Search the donors easily.
4. Sending SMS to the registered donors in the critical or emergency situation.
5. Creating new events and maintain the events.
And this project documentation cover,
1. User Manual Documentation
2. System Testing Report
3. Software Development Life Cycle Stages
4. System Design
All together this report delivering the quality of software projects and how we can main the
software projects. Use of user manual guidance any one easily can understand how this
system is working and how can use this system to get the benefit.
And this system can expect more demand and the commercial selling prizes for any
hospitals or any other blood donation camps. It give more benefits for hospitals and blood
donor camps.
And this report delivering some important titles of the system development life cycle. Such
as stages of software development life cycle.

PDIE/ MP
References
System Development Principle
James, 1996. tifr. [Online]
Available at: http://www.smartdraw.com/resources/tutorials/jackson-system-
development-diagrams/#/resources/tutorials/Introduction-to-Yourdon-and-Coad
[Accessed 09 11 2014]
South Carolina Department of Education. Program for Assisting, Developing and Evaluating
Principal Performance (PADEPP). n.d. Retrieved December 1, 2010,from
http://www.scteachers.org/leadership/principalperformance.cfm
W. W. Royce, Managing the Development of Large Software Systems: Concepts and

Techniques, Proceedings of WESCON, August 1970; also in TRW Software Series, SS-70-01,
and August 1970.
E. R. Mangold, Software Visibility and Management: Technology, Proceedings of the TRW
Symposium on Reliable, Cost-Effective, Secure Software, TRW-SS- 74-14, March 1974.
J. A. Ward, Twenty Commandments for Managing the Development of Tactical Computer
Programs, Proceedings, I974 National Computer Conference, pp. 803 806.
P. W. Metzger, Managing a Programming Project, Prentice-Hall, Englewood Cliffs, NJ, 1973
(2nd ed. 1981).
B. N. Abramson, and R. D. Kennedy, Managing Small Projects, TRW-SS-69-02, 1969.
R. W. Wolverton, the Cost of Developing Large-Scale Software, IEEE Transactions on
Computers, 1974.
G. F. Hice, W. S. Turner, and L. F. Cashwell, System Development Methodology, North-
Holland, New York, 1974

PDIE/ MP
Similar System Studies
Berry, M. W., Dumais, S. T., and OBrian, G. W.1995. Using Linear Algebra for Intelligent
Information Retrieval. SIAM Review, 37(4), pp. 573-595.
Billsus, D., and Pazzani, M. J. 1998. Learning Collaborative Information Filters. In
Proceedings of Recommender Systems Workshop. Tech. Report WS-98-08, AAAI Press.
Bhattacharyya, S. 1998. Direct Marketing Response Models using Genetic Algorithms. In
Proceedings of the Fourth International Conference on Knowledge Discovery and Data
Mining, pp. 144-148.
Some Project Success Factors and Failure

Available at: http://www.martinbauer.com/Articles/How-to-Plan-a-CMS-Project/Project-
Success-Factors [Accessed 15 11 2014]
Pinto, 2000. tifr. [Online]
Available at: http://www.projecttimes.com/articles/10-key-success-factors-for-
application-implementation-projects.html
[Accessed 15 11 2014]
Kerly, 2003. tifr. [Online]
Available at: http://hrishikeshkarekar.com/2012/05/top-10-critical-success-factors-for-
project-success [Accessed 15 11 2014]
Maakr, 2007. tifr. [Online]
Available at: http://www.cio.com/article/2417296/project-management/it-project-
management--10-less-considered-keys-to-success.html
[Accessed 16 11 2014]
Kerzner, H. (2001), Project Management: A Systems Approach to Planning, Scheduling and

Controlling. 7th Ed. New York: J. Wiley & Sons.
Lim, C.S., and Mohamed, M.Z. (1999), Criteria of project success, International Journal of
Project Management, v.17 (4), pp.243-8.
Pinto, J. K., and Slevin, D. P. (1988), Critical success factors across the project life cycle,
Project Management Journal, v.19 (3), pp.67-75.
Prabhakar, G. P. (2008), What is project success: A literature review, International
Journal of Business and Management, v.39, pp.3-10.
Schultz, R. L., Slevin, D. P., and Pinto, J. K., (1987), Strategy and tactics in a process model
of project implementation, Interfaces, v.17, May-June, pp.34-46.

PDIE/ MP
Software Life Cycle
Mohana, 2000. tifr. [Online]
Available at: http://www.tutorialspoint.com/sdlc/sdlc_overview.htm [Accessed 01 12
2014]
Kitty, 2001. tifr. [Online]
Available at: https://airbrake.io/blog/insight/what-is-the-software-development-life-cycle
[Accessed 01 12 2014]
Mekka, 2010. tifr. [Online]
Available at: http://www.techopedia.com/definition/22193/software-development-life-
cycle-sdlc [Accessed 02 12 2014]
Uido, 1999. tifr. [Online]
Available at: http://www.veracode.com/security/software-development-lifecycle
[Accessed 03 12 2014]
[Becker et al.(1988)Becker, Chambers, and Wilks] R. A. Becker, J. M. Chambers, and A. R.

Wilks. The New S Language. Chapman & Hall, London, 1988. ISBN 0-534-09193-8.
[Chambers(1998)] J. M. Chambers. Programming with Data. Springer, New York, 1998. URL
http://cm.bell-labs.com/cm/ms/departments/sia/Sbook/. ISBN 0-387-98503-4.
[Chambers and Hastie(1992)] J. M. Chambers and T. J. Hastie. Statistical Models in S.
Chapman & Hall, London, 1992. ISBN 0-534-16764-0.
Testing Methods
Guide to the Software Engineering Body of Knowledge, Swebok A project of the IEEE
Computer Society Professional Practices Committee, 2004.
Software Engineering: A Practitioners Approach, 6/e; Chapter 14: Software Testing
Techniques, R.S. Pressman & Associates, Inc., 2005.
Myers, Glenford J., IBM Systems Research Institute, Lecturer in Computer Science,
Polytechnic Institute of New York, The Art of Software Guide to the Software Engineering
Body of Knowledge, Swebok A project of the IEEE Computer Society Professional Practices
Committee, 2004.
Software Engineering: A Practitioners Approach, 6/e; Chapter 14: Software Testing
Techniques, R.S. Pressman & Associates, Inc., 2005.
Myers, Glenford J., IBM Systems Research Institute, Lecturer in Computer Science,
Polytechnic Institute of New York, The Art of Software 2004.

PDIE/ MP
Others
Available at: http://www.cs.vu.nl/~hans/SEbook.html
[Accessed 09 11 2014].
Vilkomir, A, Kapoor, K & Bowen, JP, Tolerance ofControl-flow testing Criteria, Proceedings
27th Annual International Computer Software and applications Conference, 3-6 November
2003, 182-187, or http://ro.uow.edu.au/infopapers/88
http://www2.hawaii.edu/~roever/wbt.htm , February 08,2009.
http://www.businessdictionary.com/definition/real-timetesting.html, February, 2009.
Mikucionis, Marius, Larsen, Kim, Nielsen, Brian, Online On-the-Fly Testing of Real-time
systems, http://www.brics.dk/RS/03/49/BRICS-RS-03-49.pdf, February, 2009.
Tretmans, Jan, An Overview of OSI Conformance Testing,
http://www.cs.aau.dk/~kgl/TOV03/iso9646.pdf
http://www.ifp.uiuc.edu/~hning2/protocol.htm , February2009.
F. S. Ingrassia, Combating the 90% Syndrome, Datamation 17176 (1978).

P. F. Drucker, The Practice of Management, Harper and Row, New York, 1954.
H. Koontz, C. F. ODonnell, Principles of Management: An Analysis of Managerial Functions,
McGraw-Hill, New York, 1972.
G. M. Weinberg, The Psychology of Computer Programming, Van Nostrand Reinhold, New
York, 1971.
H. Sackman, Man-Computer Problem Solving, Auerbath, 1970.
J. R. Brown, et al., Quantitative Software Safety Study, TRW report SDP-1776, 1973.
F. P. Brooks, Jr., The Mythical Man-Month, Addison- Wesley, New York, 1975.
J. D. Aron, The Program Development Process: The Individual Programmer, Addison-
Wesley, New York, 1974.
D. J. Riefer, and S. Trattner, A Glossary of Software Tools and Techniques, Computer 5260
(1977).
R. C. Houghton, Jr., Software Development Tools, NBS Special Publication 500- 88, NBS,
Washington, DC, 1982.

PDIE/ MP
Index
Acronyms 14
Abstract 16, 20, 22, and 27
Admin 18, 40, 51, 62, 70, 71, and 72
Application 22, and 117
Analysis 30, and 104
Business 16, and 23
Blood Donor 16, 17, 33, 36, 51, 52, 53, 54, 66, 77, 99, and 107 120
Computerized 16, 43
Coding 17, 20, 25, and 73
Documentation 17, 18, 20, 40, 70, 92, and 108
Developers 17, 68, and 69
Diagram 56- 62
Database 33, 66, 34, 74, and 105
Data 23, 24, and 48
Development 25, and 29
Design 25, and 73
Engineering 21, 27, and 46
Functional 31, 45, 46, 49, and 64
Feasibility 37, 38, 39, and 40
Factor 42, 50, and 77
Gathered 16, 41, and 42
Generality 29, 42, and 50
Goal 17, and 26
Graphical 34, and 75
Hospital 16, 17, and 33
Information 32, 45, 78, 112, and 115
Implement 25, and 35
Interface 50, and 70
Modularity 17, 27, and 28

PDIE/ MP
Motivation 23, and 118
Maintain 25, 49, 73, and115
Matrix 43, and 44
Model 63
Overview 21, and 45
Project 16, 14, 17, 19, 22, 40, 41, and 106
Process 23, 47, 63, and 103
Principle 27, 50, 103, and 104
Planning 41, 50, and 77
Purpose 18, 40, and 47
Produces 69, 70, 78, and 80
Quality 23, and 47
Register 16, 25, and 26
Report 15, and 35
Result 20
Research 22, and 37
Requirement 18, 22, 29, 35, 49, 57, 69, 71, 78, 79, 84, 86, 89, and 115
Stages 17, 21, 40, and 92
Scope 19, and 112
Software Tools 21, and 46
Separation 27, 32, and 51
Similar 31, 32, and 33
Server 44, and 105
System 16, 17, 18, 19, 23, 25, and 50 59
Software 16, 17, 22, 25, 27, 41, 63, 67, and 105
Testing 75, 77, 79 98, and 104
Universally 17, 20, 40, 45, 70, and 110
User 50, 60, 77, 78, 82, 84, 86
Waterfall 63
Work Breakdown 47, and 49

Blood Donor Information and Management S

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Blood Donor Information and Management S

Uploaded by

Copyright:

Available Formats

BLOOD DONOR INFORMATION

M.N. Azeem Mohamed

20th September 2014, this project is submitted to Bcas Kandy Campus.

10th January 2015,

MOHAMED NAZAR AZEEM MOHAMED

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 1

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 2

2.2. Motivation and Objective of the Project . 18

2.3. Scope of the Project . 19

2.4. Chapter Summery . 20

2.5. Software Tools and Overview . 21

3.2. Project Development Principle .. 25 - 27

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 3

3.3. Principle of Software Engineering . 27 - 29

4.2. Similar System Studies 31 - 36

4.3. Feasibility Studies . 37 - 40

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 4

4.4. Criteria for Project Success and Failure 41 - 42

4.5. Resource Allocation Matrix ..... 43 - 44

5.2. User Interface 50 - 55

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 5

5.3. Context Diagram & Use Case Diagram . 56

5.4. Data Flow Diagram 57 - 61

5.6. Other Diagram 62

6. Method and Methodology 63 - 76

6.2. Software Process Models 63 - 69

6.2.2. Iteration Model 66

6.2.3. V Shaped Model . 67

6.2.4. Spiral Model 68

6.2.5. Extreme Model .. 69

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 6

6.3. Selected Methodology 70

6.4. Procedures ... 71

6.5. Implementation .... 72 - 76

7. Result and Discussion .. 77 - 78

8. Testing and Evaluation ... 79 - 105

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 7

8.1.2. Test Cases 82 - 90

8.1.3. Evaluation of Actual and Expected Results . 91 - 98

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 8

8.2. Project Performance Analysis .. 99 - 100

8.3. Change Control of Project 101 - 102

8.4. Suggestion, Recommendation and areas need to be improved 103 - 105

9. Support and Maintenance 106 - 129

9.1. Reason for Termination of Project 106

9.2. Client Certification ... 107 -108

9.3. Close Out Report .. 109 - 116

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 9

9.4. User Manual . 117 - 129

10. Summary and Conclusion .. 130

11. Reference . 131 - 134

11.1. System Development Principle 131

12. Index . 135 - 136

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 10

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 11

42. Figure 9.4.15 SMS to the Donors .. 124

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 12

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 13

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 14

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 15

1.1 Content Summary

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 16

If the donors are between age group of 18-60 years.

2.1 Project Background