4.

SYSTEM DESIGN

4.1 Data Design

4.1.1 Data Structure Description The Life Line project includes eight relational databases. Its for proper functioning of the software. These tables are given in appendix. 4.1.2 Database Description SQL server is a relational database management system (RDBMS) that uses Transact SQL to send request between a client and SQL Server. Server is designed to be a client/server system. Client/Server systems are constructed so that the database can reside on a central computer, known as server, and be shared among several users. When users as server, and shared among several users, When users want to access data on the SQL server, they run an application on their local computer, known as client that connect over a network to the server running SQL Server. Advantages of using SQL Server include Multiuser database, Support RDBMS, fast, ease of use, and security.

4.2 Architectural and Component-Level Design

All of the architectural and component-level design about the project is described in section A of Appendices.

4.3 Software Interface Description

Front end

ASP.NET (C# language)

ASP.NET has many advantages over other platforms when it comes to creating Web applications. Probably the most significant advantage is its integration with the Windows server and programming

tools. Web applications created with ASP.Net are easier to create, debug and deploy because those tasks can all be performed within a single development environment, C#. Back end :SQL Server 2005 SQL Server 2005 (codenamed Yukon), released in October 2005, is the successor to SQL Server 2000. It included native support for managing XML data, in addition to relational data. For this purpose, it defined an xml data type that could be used either as a data type in database columns or as literals in queries. XML columns can be associated with XSD schemas; XML data being stored is verified against the schema. XML is converted to an internal binary data type before being stored in the database. Specialized indexing methods were made available for XML data. XML data is queried using XQuery; SQL Server 2005 added some extensions to the T-SQL language to allow embedding XQuery queries in T-SQL. In addition, it also defines a new extension to XQuery, called XML DML, that allows query-based modifications to XML data. SQL Server 2005 also allows a database server to be exposed over web services using TDS packets encapsulated within SOAP (protocol) requests. When the data is accessed over web services, results are returned as XML.

4.4 User Interface Design

The entire user interfaces and descriptions about it are described in section C of Appendices.

5. TESTING

5.1 Test Plan

The Software Test Plan (STS) describes plans for qualification testing of Software LIFE LINE Configuration Items and software systems. It identifies the software test environment to be used for the testing. Tests to be performed provides schedule for test activities. The primary goal of test plan is to define testing procedures that will ensure that the software is functionally correct from a document perspective and will verify application scalability limits. Its also proves that reliability and fail over aspects of the system can indeed survive instances of system failure. It describes and identifies the tests to be performed, and provides schedules for test activities.

5.1.1 Testing Strategy

The overall strategy for testing LIFE LINE is described as follows. We will use four different methods to test our software.

5.1.1.1 Unit Testing

In unit testing, the analyst tests the programs making up a system. This is also called as program testing. The software units that make up the system are the modules and the routines which are assembled and integrated to perform a large system. This enables the tester to detect errors in coding and logic that are contained within that module alone. Those resulting from the interaction between modules are initially avoided. Unit test comprises the set of testes performed prior to integration of the unit into the entire project. Function Test: The code is exercised with nominal input values for which the expected results are shown, as well as boundary values and special values such as logically related inputs. Performance Test: Performance test is done to determine the amount of execution time spent in various parts of the unit, program throughput and response time and devise utilization by the program unit.

Stress Test: Test has been done to intentionally break the unit. This helps in learning about the strength and limitations about the strength and limitations of the program by examining a manner in which a program unit breaks.

Structure Test: Structure test is done to test the internal logic of the program and traversing particular execution paths. The major activity involved in structure test is to decide which paths to exercise, deriving test data to exercise those paths, determining the test coverage.

5.1.1.2 Integration Testing

Integration testing is used to develop an incremental strategy that will limit the complexity of interactions among components as they are added to the LIFE LINE system, developing an integration system schedule that will make the modules available when needed. In this test, groups of the program modules are tested together to determine they interface properly. Two types of integration testing are: Top down Integration: This method is an incremental approach to the construction of the program structure. Modules are integrated by moving downwards through the control hierarchy, beginning with the main program module. The module subordinates to the main program module are incorporated into the structure incorporated into the structure in either the depth first or breathe first manner. Bottom-up Integration: This method begins the construction and testing the modules at the lowest level in the program structure. Since the modules from the bottom up, processing requires for modules subordinate to a given level is always available and the need for the stubs is eliminated.

5.1.1.3 Validation Testing

Validation testing is a process of obtaining the right amount of processing capability of the software LIFE LINE. Here we make sure that the software is providing the exact result which it is assigned for. Here we will perform black box testing where the software is completed and the test for all software components is done together. We will have several input

data or test data that we will derive results for. Here we will compare the results from the software with the results that are derived. This will check for the validation of the software. In case there are problems with the software we will create a deficiency list and will record all problems there.

5.1.1.4 System Testing

The implementation of a computer based system requires that test data to be prepared and that the system and its elements be tested in a planned structured manner. The computer program component is a major sub-system of the computer-based information system and particular attention should be given to the testing of this system element as it is developed. In a software development project, errors can be injected at any stage during development. Each we have discussed different techniques for detecting and eliminating errors that originate in that phase. In software the use of testing is not limited to the testing phase. System testing includes verification and validation, which can be classified as static and dynamic. In static method the behavior of the system is not observed by executing the system. In dynamic method the behavior of the system is observed by executing the system. We have tested all the modules in our project separately and run successfully.

5.2.Test Procedure
This section describes a detailed test procedure including test tactics and test cases for the system. In this section all software specification is described. We will describe the methods for all the different tests to be performed and will also declare the expected outputs.

5.2.1 Unit Test Cases

In this method of testing we will test the smallest unit of software called modules. We will be testing all the important paths to find any errors within the boundary of module. So here white box test is applied. We will be testing the parts of the software rather than the entire software. The modules are as follows.

5.2.1.1 Test Case for Donor Registration Module

Here the system will check whether proper values are entered in all the textboxes provided for registration. Also check the system module by providing several different names and also use already existing username to register. Purpose of test case for Registration Module To test whether, different donors are able to register to the system successfully. Also helps to check error messages are displayed while providing improper values in the textboxes. Expected results for Registration Module The donor is registered successfully if username and password are provided and also proper values are entered in all the textboxes provided.

5.2.1.2 Test Case for Recipient Registration Module

Here the system will check whether proper values are entered in all the textboxes provided for registration. Also check the system module by providing several different names and also use already existing username to register. Purpose of test case for Registration Module To test whether, different recipients are able to register to the system successfully. Also helps to check error messages are displayed while providing improper values in the textboxes.

 Expected results for Registration Module The recipient is registered successfully if username and password are provided and also proper values are entered in all the textboxes provided.

5.2.1.3 Test Case for Hospital Registration Module

Here the system will check whether proper values are entered in all the textboxes provided for registration. Also check the system module by providing several different names and also use already existing username to register. Purpose of test case for Registration Module To test whether, different hospitals are able to register to the system successfully. Also helps to check error messages are displayed while providing improper values in the textboxes. Expected results for Registration Module The hospital is registered successfully if username and password are provided and also proper values are entered in all the textboxes provided.

5.2.1.4 Test Case for Administration Module

Here the system will check the request sent by the recipient for required blood group, if it is valid he/she will approve it. Purpose of test case for Administrator Module The purpose of test case for administrator module is to check the details of the donor/recipient/hospital. Expected results for Administrator Module The expected result is that the donor details are sent correctly.

5.2.2 Integration Testing

In this method of testing, we will implement the software LIFE LINE at the actual site and will run it. So we will be testing the product on actual site network. Here Top-Down model is used to test. We will start the test with home page, after the home page we will be testing each and every sub component or functions of software.

5.2.2.1 Testing procedure for integration

We will be using stubs to perform the test. Stubs are dummy function that we will use to test the separate modules. Each of the modules to be tested will have its own distinct stub and the stub will be created depending on the functions of each software component. As part of testing, we will be looking for any signs of collision between our software components and those of other components in the actual one. We must make sure that there is no confusion among the application on the network when they are running simultaneously.

5.2.2.2 Test case and their purpose

Each of the software items will be the test case for the integration testing. So each form as a whole will be a test case. We will be testing each and every form for all the errors that logically can occur in it. We will install the software at the actual site and will run it. We will have several different other applications open as well. This applications will be the once that have to interact with our software on normal bases. We will make sure that there all data is saved correctly and no data has been lost from the system.

5.2.2.3 Expected Results

At the end of the test all the results should be positive. All of the e

software components should work properly. In case we come across any errors we will record them in the error document and these errors will be fixed later.

5.2.3 Validation Testing

This test is performed to validate our LIFE LINE SYSTEM. The test is called black box testing where the entire software will be created and will test all the components of the software together. We will be working with the end users who are going to use and to show them the software.

5.2.3.1 Testing procedure for validation

We perform a black box test where we will have software as whole with us. Here we will compare predicted results with those that software gives us and will determine if the software is valid or not. Every button, link or menus will be tested. We will test the correctness of the database and will make sure that there is no error regarding record store database.

5.2.3.2 Expected Results

We should not have any troubles with the software since we have already tested all the parts of the software. Everything here should work fine and we should be able to validate the software. We will be validating only if each and everything work in the software. Any software error will force us to wait for the validation until we have fixed all the errors.

5.2.3.3 Pass/fail criterion for all validation tests

The pass/fail criterion for the entire validation test is that the result from the testing should not contain bugs that could affect the working of the system as a whole. The system passes a test only when the outputs produced by its modules are the expected ones. Failure occurs when the results are far off from the

expected results.

5.2.4 System Testing

System testing of software is testing conducted on a completed, integrated system to evaluate the systems compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. As a rule, system testing takes, as its input, all of the integrated software components that have successfully passed integration testing. The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together.

5.2.4.1 Recovery Testing

In software testing, recovery testing is the activity of testing how well the software is able to recover from crashes, hardware failures and other similar problems, Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed.

5.2.4.2 Security Testing

It is a process to determine that an information system protects data and maintains functionality as intended.

5.2.4.3 Stress testing

Stress testing means testing of software or hardware for its effectiveness in giving consistence or satisfactory performance under extreme and unfavorable conditions such as heavy network traffic, heavy processes load, under or over clocking of underlying hardware,working under maximum requests for resource

utilization of the peripheral or in the system etc.

5.2.4.4 Performance testing

This is to determine how fast some aspect of a system performance under a particular workload. It can also serve to validate and verify other quality attribute of the system, such as scalability, reliability and resource usage.

5.2.4.5 Alpha/Beta testing

Alpha testing is a type of acceptance testing carried out at our site by uses. In this type of testing the users goes on testing the system and the outcome is observed by us simultaneously. Beta testing is a type of testing done at users site. The users provide their feedback to us for the outcome of testing. This type of testing is also known as field testing. Feedback from users is used to improve our system before it is released to our customers.

5.2.4.6 Pass/fail criterion for all system testing

When we test our system, some application will pass and some will fail. When testing is completed for a specific application, we enter the results in our test tracking and reporting system.