You are on page 1of 138
BLOOD DONOR INFORMATION SYSTEM M.N. Azeem Mohamed FM 29022 KIT 26-13-01 Supervisor Mr. Munshif 03

BLOOD DONOR INFORMATION SYSTEM

M.N. Azeem Mohamed FM 29022 KIT 26-13-01

Supervisor

Mr. Munshif

03 rd .02.2015

BLOOD DONOR INFORMATION SYSTEM M.N. Azeem Mohamed FM 29022 KIT 26-13-01 Supervisor Mr. Munshif 03 r
PDIE/ MP Declaration I hereby declare that the project work entitled by under the guidance

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,

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

The Ending time of the project,

10 th 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

for the award of any degree or diploma. MOHAMED NAZAR AZEEM MOHAMED BLOOD DONOR INFORMATION SYSTEM

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 1

1

PDIE/ MP Acknowledgment First of all I would like to express our heartful thanks to

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 I’ll 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 2

2

Table of Contents PDIE/ MP 1. Abstract

Table of Contents

PDIE/ MP

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 3

3

PDIE/ MP 3.2.5. Be Open to the Future ……………………………………………. 26 3.2.6. Plan Ahead

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 ……………………………………………………

4.2.1. Similar System 1 ElDorado Donor System …………………

31 - 36 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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 4

4

PDIE/ MP 4.3.4. Schedule Feasibility ………………………………………………. 40 4.3.5. Economic

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 ………………………………………………………………………………….

5.1. Work Breakdown Structure and Task Allocation ……………………….

47 - 62 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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 5

5

PDIE/ MP 5.2.3. User Interface of Blood Donor Information System ……………. 51 - 55 5.2.3.1.

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 ………….……

5.3. Context Diagram & Use Case Diagram ………………………………….

5.4. Data Flow Diagram …………………………………………………………

53 - 55

56

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 6

6

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

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 7

7

PDIE/ MP 8.1.2. Test Cases ………………………………………………………… 82 - 90 8.1.2.1. Test Case

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

8.1.3.5. Error Correction (Table 8.1.3.3 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

8.1.3.11. Error Correction (Table 8.1.3.6 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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 8

8

PDIE/ MP 8.2. Project Performance Analysis ………………………………………… 99 - 100 8.2.1. Budgeted

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 9

9

PDIE/ MP 9.4. User Manual ……………………………………………………………. 117 - 129 9.4.1. How to

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

10

List of Figures PDIE/ MP 1. Figure 1.1 Systematic Literature Review Process Flowchart ………………… 24

List of Figures

PDIE/ MP

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

6. Figure 4.2.2 Feasibility Studies – 2 ………………………………………………

37

7. Figure 4.2.3 Feasibility Studies – 3 ………………………………………………

38

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

11

PDIE/ MP 39. Figure 9.4.12 Table View of the Events ……………………………………… 122 40. Figure

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

12

List of Tables PDIE/ MP 1. Table 4.3.1 Issues for Project Management Success ………………………… 42

List of Tables

PDIE/ MP

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

13

List of Acronyms PDIE/ MP AC Actual Cost ACWP Actual Cost of Work Performed AD

List of Acronyms

PDIE/ MP

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

14

PDIE/ MP CWBS Contract Work Breakdown Structure DU Duration DUR Duration DMA Direct Memory Access

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

15

WP Work Package XML eXtensible Markup Language PDIE/ MP Abstract Blood Donor Information System is

WP

Work Package

XML

eXtensible Markup Language

PDIE/ MP

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 donor’s details using GUI (Graphical user Interface). This system interface will have many function to control easily

Schedule

The started date of the project was 20 th 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

16

PDIE/ MP Introduction Blood is universally recognized as the most precious element that sustains life.

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 I’m 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 donor’s weight is 45 kg’s or more.

If the donor’s hemoglobin is 12.5 gm% minimum.

If the donor’s 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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

17

 Consistency  Information Metrics PDIE/ MP For get more details of software engineering principles,

Consistency

Information Metrics

PDIE/ MP

For get more details of software engineering principles, please visit to this site.

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 day’s hospitals and blood camps were used paper base recording system. Even though today also they all using Paper recording system. What I’m 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 can’t 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?

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

18

PDIE/ MP 2.3 Scope of the Project Anyone who has ever done a project will

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 today’s world we can’t 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 that’s 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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

19

PDIE/ MP 2.4 Chapter Summery 1. Abstract The abstract is a summary of the entire

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

20

PDIE/ MP 9. Appendices The appendices may contain large sets of tabular data, detailed computer

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

- Introduced by Microsoft Corporation.

- 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

- Introduced by Microsoft Corporation.

- Used to manage the data called database management system (DBMS).

Adobe Photoshop

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

21

- Introduced by Adobe. - Help to create nice artistic, and editing works.  Web

- Introduced by Adobe.

- Help to create nice artistic, and editing works.

Web Browser (Google Chrome, Opera Mini)

PDIE/ MP

- 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

22

PDIE/ MP The above mentioned studies and facts laid the foundation of our investigation. I

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

23

PDIE/ MP Selection of Studies – This phase includes both primary and secondary studies. The

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

24

PDIE/ MP Figure 1.1 is showing the SR phases in depth using flowchart, Figure 1.1

PDIE/ MP

Figure 1.1 is showing the SR phases in depth using flowchart,

1.1 is showing the SR phases in depth using flowchart, Figure 1.1 Systematic Literature Review Process

Figure 1.1 Systematic Literature Review Process Flowchart

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

25

2. Keep It Simple, Stupid (KISS) 3. Maintain the Vision 4. What We Produce, Others

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

PDIE/ MP

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

26

PDIE/ MP system. Someone may have to debug the code we write, and that makes

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

27

PDIE/ MP research the answer. When clear thought has gone into a system, value comes

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

28

PDIE/ MP Abstraction The principle of abstraction is another specialization of the principle of separation

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 client’s 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

29

PDIE/ MP For another example where the principle of generality applies, consider a customer who

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 it’s really important for any kind of software project. Even I’m 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

30

PDIE/ MP So will see what analysis is and why it’s important for software project

PDIE/ MP

So will see what analysis is and why it’s 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 application’s 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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

31

PDIE/ MP were very useful while designing this system. All the necessary reports generated by

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 system’s modular configuration provides maximum flexibility to meet them system- specific requirements.

So this system is mainly use for record the blood donor’s 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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

32

PDIE/ MP Figure 4.1.1 ElDorado Donor Blood Management System – Donor Registration Figure Source -

PDIE/ MP

PDIE/ MP Figure 4.1.1 ElDorado Donor Blood Management System – Donor Registration Figure Source -

Figure 4.1.1 ElDorado Donor Blood Management System Donor Registration

Figure Source -

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 can’t save or store any data in to the database.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

33

PDIE/ MP Figure 4.1.2 ElDorado Donor Blood Management System – Blood Ordering Figure Source -

PDIE/ MP

PDIE/ MP Figure 4.1.2 ElDorado Donor Blood Management System – Blood Ordering Figure Source -

Figure 4.1.2 ElDorado Donor Blood Management System Blood Ordering

Figure Source -

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

34

PDIE/ MP Database is one of important for any kind of computer base system. So

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.

have database fields. So first they must need design of it. Figure 4.1.3 ElDorado Donor Blood

Figure 4.1.3 ElDorado Donor Blood Management System ER Diagram

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

35

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

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

36

PDIE/ MP Similar System 3 - Web-based Blood Bank Management System Institution  Department of

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

37

PDIE/ MP 4.2 Feasibility Studies Normally feasibility study mean, evaluation and analysis of the potential

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,

study will take the form of the following diagram, Figure 4.2.1 Feasibility Studies 1 Figure Source

Figure 4.2.1 Feasibility Studies 1

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,

that would implement the feasibility recommendations, Figure 4.2.2 Feasibility Studies 2 Figure Source -

Figure 4.2.2 Feasibility Studies 2

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

38

PDIE/ MP The implementing a project, like any project that would be based on a

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,

it may be best to run the project in four management stages, Figure 4.2.3 Feasibility Studies

Figure 4.2.3 Feasibility Studies 3

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

39

PDIE/ MP Operational Feasibility Operational feasibility is the measure of how well a proposed system

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 solution’s 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 can’t 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

40

PDIE/ MP Schedule Feasibility Given the available technical expertise, are the project deadlines reasonable that

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 user’s 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

41

PDIE/ MP 4.3 Criteria for Project Success and Failure Often, software managers have to monitor

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

42

PDIE/ MP Issues Description Activities Project Focus Time, budget and quality. Focused on achieving these

PDIE/ MP

Issues

Description

Activities

Project Focus

Time, budget and quality.

Focused on achieving these broad goals.

Planning

Engage in planning detailed and systematic.

Planning and preplanning.

Sense of Urgency

Limited time, money, and other resources.

Regular status checks, meetings, and reminders are essential.

Use a time-tested, proven project life Cycle

Use standard models to build into project plans.

Identify the best project life cycle.

Evolve gradually to succeed

Involvement of users in cost and time estimation and risk management.

Maintain a controlled evolution.

Clear approvals and sign-off by Sponsors

Clear approval points.

Examine and approve.

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

43

PDIE/ MP 4.4 Resource Allocation Matrix Basically blood donor information system is a standalone application.

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 it’s 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

Commonly referred to as the GSM family of technologies Figure 4.4.1 GSM Network BLOOD DONOR INFORMATION

Figure 4.4.1 GSM Network

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

44

PDIE/ MP Hardware Requirements The selection of hardware requirements for Blood camp or hospital is

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.

for running the blood donor information system. Table 4.4.1 PC Specification Server Specifications for

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.

for running the blood donor information system. Table 4.4.2 Server Specification BLOOD DONOR INFORMATION

Table 4.4.2 Server Specification

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

45

PDIE/ MP 4.5 Specification A standalone application is able to function independently of other hardware.

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 donor’s mobile number through counting the number of characters in the entered mobile number

System uses the donor registration number & the identity card number to identify each donor separately.

Inside the system the administrator has more advance functions than the 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 donor’s 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 doesn’t keep the details of the gathering stock of blood.

The system database will be accessible in real time.

The donor doesn’t submit any fake reports to the system.

Donors who want to contribute to a donation will definitely reply to the request of system.

The 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

46

4.5.2 Non – Functional Requirements PDIE/ MP In addition to the obvious features and functions

4.5.2 Non Functional Requirements

PDIE/ MP

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

47

Design PDIE/ MP 5.1 Work Breakdown Structure and Task Allocation The Work Breakdown Structure (WBS)

Design

PDIE/ MP

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

48

PDIE/ MP BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 49
PDIE/ MP BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 49

PDIE/ MP

PDIE/ MP BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION 49

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

49

PDIE/ MP A complex project is made manageable by first breaking it down into individual

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

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

50

PDIE/ MP 5.2 User Interface GUI is one of most important for any kind of

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 user’s 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 don’t 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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

51

PDIE/ MP User Interface of Blood Donor Information System User interface is ever need for

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.

the system, there is splash screen beginning of my system. Figure 5.2.1 Splash Screen of 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.

are just registering donors and maintaining the donors. Figure 5.2.2 Login for Administrator Figure 5.2.2 is

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

52

PDIE/ MP Main Window of the Blood Donor Information System The main window is the

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.

and password, and then only the main window will be display. Figure 5.2.3 Main window of

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.

strip tools to rive some more function in the separate way. Figure 5.2.4 Menu Strip tool

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.

button tools and picture tools to make visible to the users. Figure 5.2.5 Button with Icon

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.

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

53

PDIE/ MP Some Main Windows and Function of the System Here I have used different

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.

to create this interface for get more visible to the users. Figure 5.2.6 Blood Donor Registration

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.

or display this window to make any changes in the system. Figure 5.2.7 Maintaining Blood Donors

Figure 5.2.7 Maintaining Blood Donors

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

54

PDIE/ MP This is interface called sending SMS to the blood donors. So this user

PDIE/ MP

This is interface called sending SMS to the blood donors. So this user interface also got some more tools and graphical designs.

interface also got some more tools and graphical designs. Figure 5.2.8 Sending SMS to the Donors

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.

5.2.9 also displaying some kind of .NET framework tools. Figure 5.2.9 Create new admin, and user

Figure 5.2.9 Create new admin, and user

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

55

PDIE/ MP And I have created separate interface for event management, the event management will

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.

details about the next blood donation camp, and where it is. Figure 5.2.10 Create new events

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.

search the donors and find out easily from the donors list. Figure 5.2.11 Search donors BLOOD

Figure 5.2.11 Search donors

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

56

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

PDIE/ MP

5.3 Context Diagram and Use Case Diagram

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

Diagram 5.3.1 Use Case Diagram

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

57

5.4 Data Flow Diagram PDIE/ MP Diagram 5.3.2 Data Flow Diagram BLOOD DONOR INFORMATION SYSTEM

5.4 Data Flow Diagram

PDIE/ MP

5.4 Data Flow Diagram PDIE/ MP Diagram 5.3.2 Data Flow Diagram BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

Diagram 5.3.2 Data Flow Diagram

BLOOD DONOR INFORMATION SYSTEM DOCUMENTATION

58

PDIE/ MP Diagram 5.3.3 Data Flow Diagram – Level 0 Diagram 5.3.4 Data Flow Diagram

PDIE/ MP