Summer Training Report

On

Med Admin
Submitted in partial fulfillment of the Requirement for the award of the degree of Bachelor of Technology
(Batch 2008 - 2012)

Submitted To : Mr Sudhir Dagar HOD of ECE Deptt.

Submitted By : Payal ECE(7th sem) 8227

Ch. Devil Lal Memorial Govt. Engg. college (Panniwala Mota)

CANDIDATE DECLARATION
I hereby declare that the work which is being presented in this training report entitled Med Admin, in partial fulfillment of the requirement for the award of the degree of BACHELOR OF TECHNOLOGY submitted at Ch. Devi Lal Memorial Govt. Engg. College, Panniwala-Mota (Sirsa),C.D.L.U.(Sirsa) is an authentic work done by me during a period from June, 2010 to August, 2010, under the Guidance of Mr. Sudhir Dagar. The work presented in this project report has not been submitted by me for the award of any other degree of this or any other Institute/University.

PAYAL 8227

ii

ACKNOWLEDGEMENT
Outstanding achievements are not possible in vacuums. It needs a lot of help and assistance beside a healthy environment, luckily we have. My working in this project is not only my effort but this is the result of the guidance, assistance and inspiration of several people who helped me throughout my study and in the preparation of this report. It is my greatest pleasure to express my gratefulness to all those without whose assistance this project could not have been completed. First and foremost I would like to express our sincere thanks to Mr. Sudhir Dagar (HOD, CDLMGEC, Panniwala-Mota(Sirsa)) who provided me with the required assistance and infrastructure to gird up for this highly technical project. I am also grateful to all faculty members of CDLMGEC, who were always there to provide their invaluable suggestions and guidance. Then, I would like to acknowledge the total support and standard of excellence provided by my Project Mentor Mr. Manish Sinha (Manager, R&D). I also express my indebtedness to his for showing keen interest in the project, kind of cooperation, help and above all, his precious time that he gave me without any dithering. I would also like to acknowledge the kind help and guidance that I received from Mrs. Sneha Singla, Mr.Rupinder Singh and Miss Gurpreet Kaur in developing the software.

PAYAL Roll Number: 8227 ECE-7th Sem.

iii

ABSTRACT
This document is submitted for the partial fulfillment of Degree of Bachelors of Technology . This report includes Med Admin. The concept of our service is based on the belief that today parents have the need and right to be more informed about their childs performance. Its based on the realisation of a latent demand for a standard comparative way of assessing childs performance with respect to other students not only in his school but of other schools as well. We also believe that our service certainly prepares the child in a better way to face the competition as he grows up. Our service will be an internet and SMS based service. The service can be divided into three groups
Backend: This involves interacting with the school and regular data collection (after

completion of every set of unit test/examination) from them of the students performance. For this we need to have the schedule/ regular updates of school activities. (Do we intend to go to the school or get the commitment of sending data after each evaluation test. I say this because as we expand we cannot go to each and every school moresover on a regular basis) We can go to the school at the date and collect the data.

Operation: To analyse the data in desired format. We can have a detailed discussion on

the information and its representation format.

Frontend: The service will be primarily web based. Parents will be informed by SMS when the detailed comparison result will be available for them. They will be given

iv

an ID and password using which they can login the website & access the information.

LIST OF FIGURES
Sr. No FIGURE PAGE NO.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 10. 11. 11. 12. 12. 13. 13. 14. 14. 15. 15. 16. 16. 17. 17. 18. 18.

.Net Framework Architecture .Net Framework Class Library ER Model Symbols Process , Dataflow Data Store , External Entity User Master Allergy Drug Med Pass Med Pass Status Order Status Order Type Provider Patients Reason Reason Type Levels of Testing Test Plan

19 21 44 45 46 42 42 43 44 44 45 45 46 47 47 48 68 73

LIST OF TABLES
Sr. No FIGURE PAGE NO.

1.

Allergy
vi

49

2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Drug Med Pass Status Order Status Provider Reason Reason Type Med Pass Order Patients User

49 50 50 51 52 52 53 54 55 56

vii

Table of Contents

CANDIDATE DECLARATION................................................................ii ACKNOWLEDGEMENT.................................................................................................iii .................................................................................................................................. iv ABSTRACT.................................................................................................................. iv ................................................................................................................................... v LIST OF FIGURES........................................................................................................ vi LIST OF TABLES......................................................................vi Table of Contents.....................................................8 1. ORGANISATION PROFILE.........................................................................................2 About CareFusion.......................................................................................................2 2. INTRODUCTION TO REPORT....................................................................................5 2.1. OPTIMIZATION OF SQL QUERY FOR CareFusion Product(Med Admin, Nursing Data Collection, Specimen collection verification, Infant Care, Data View, Tissue and Implant Management, Alerts)...........................................................................5 2.2. AIM ..................................................................................................................6 2.3. PROBLEM DEFINITION.......................................................................................6 3. REQUIREMENT ANALYSIS........................................................................................8 3.1 ITERATIVE ENHANCEMENT DEVELOPMENT PROCESS........................................8 3.2 PROBLEM ANALYSIS........................................................................................11 3.2.1. RECOGNITION OF NEED- WHAT IS THE PROBLEM?................................11 3.2.4 OBJECTIVES ............................................................................................11 3.2.5 DATA SOURCE ........................................................................................12 3.2.6 STRENGTHS...............................................................................................12 3.2.7 WEAKNESS................................................................................................ 12 3.2.8 OPPORTUNITY............................................................................................13

3.2.10 STRATEGIC FORMULATION.....................................................................13 3.3 SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT..................................14 3.3.1. INTRODUCTION TO SRS............................................................................14 3.3.2. TECHNICAL RESEARCH............................................................................15 3.3.3 FEASIBILITY............................................................................................... 33 3.4 OPERATING ENVIRONMENT.........................................................................38 4. SOFTWARE DESIGN..............................................................................................40 4.1. SYSTEM DESIGN............................................................................................40 4.2. STRUCTURED ANALYSIS................................................................................40 4.2.1 STRUCTURED ANALYSIS TOOLS.................................................................41 4.3 COMPONENT LEVEL DETAILED LEVEL DESIGN................................................45 4.3.1 ER DIAGRAMs USED IN PROJECT.............................................................45 4.3.2 DATA TABLEs USED IN PROJECT...............................................................53 4.4 IMPLEMENTATION...........................................................................................62 4.4.1 INTRODUCTION........................................................................................62 4.4.2 IMPLEMENTATION TOOLS..........................................................................63 4.4.3 TYPES OF IMPLEMENTATION.....................................................................63 5. OUTPUT SCREEN.................................................................................................65 5.1. LOGIN SCREEN.............................................................................................. 65 5.2. INCORRECT PASSWORD SCREEN....................................................................66 6. TESTING................................................................................................................73 6.1. OBJECTIVES OF TESTING.................................................................................73 6.2. LEVEL OF TESTING..........................................................................................74 6.2.1. UNIT TESTING...........................................................................................74 6.2.2.INTEGRATION TESTING..............................................................................75 6.2.3.SYSTEM TESTING ......................................................................................75 6.2.4. ACCEPTANCE TESTING.............................................................................78 7. IMPLEMENTATION AND EVALUATION REPORT......................................................83 7.1. SYSTEM IMPLEMENTATION.............................................................................83 7.2. POST IMPLEMENTATION & TESTING................................................................83 7.3. MAINTENANCE................................................................................................84 CONCLUSION AND SCOPE FOR FURTHER ENHANCEMENTS......................................86 BIBLIOGRAPHY.......................................................................................................... 87

BOOKS & MANUALS:...................................................................................87

Chapter - 1 ORGANISATION PROFILE

1. ORGANISATION PROFILE

About CareFusion

We help our customers measurably improve patient care by focusing on two of the biggest issues affecting healthcare, medication errors and hospital-acquired infections. Our family of products and services are used in over 120 countries and include some of the most widely recognized brand names in their categories: Pyxis for medication and supply management, Alaris for infusion, MaxPlus Clear for needlefree IV access, AVEA and Pulmonetic Systems for ventilation, Jaeger, SensorMedics and Micro Medical for respiratory diagnostic instruments, AVAmax and PleurX for interventional procedures, V. Mueller and Snowden-Pencer for
2

surgical instruments, Nicolet neurodiagnostic instruments, MedMined for infection surveillance and ChloraPrep for preoperative skin preparation. Headquartered in San Diego, we employ more than 15,000 people in more than 20 countries worldwide. Vision Improve the safety and cost of healthcare for generations to come. Mission Deliver clinically proven products and services that improve patient care.

Chapter - 2 INTRODUCTION PROJECT

TO

2. INTRODUCTION TO REPORT
2.1. OPTIMIZATION OF SQL QUERY FOR CareFusion Product(Med Admin, Nursing Data Collection, Specimen collection verification, Infant Care, Data View, Tissue and Implant Management, Alerts) Optimization of SQL Query is a concept aimed towards The query optimizer is the component of a database management system that attempts to determine the most efficient way to execute a query. The optimizer considers the possible query plans for a given input query, and attempts to determine which of those plans will be the most efficient. Cost-based query optimizers assign an estimated "cost" to each possible query plan, and choose the plan with the smallest cost. Costs are used to estimate the runtime cost of evaluating the query, in terms of the number of I/O operations required, the CPU requirements, and other factors determined from the data dictionary. The set of query plans examined is formed by examining the possible access paths (e.g. index scan, sequential scan) and join algorithms (e.g. sort-merge join, hash join, nested loop join). The search space can become quite large depending on the complexity of the SQL query. Generally, the query optimizer cannot be accessed directly by users: once queries are submitted to database server, and parsed by the parser, they are then passed to the query optimizer where optimization occurs. However, some database engines allow guiding the query optimizer with hints.

2.2. AIM We aim for nothing short of the following:

1) To build a self sustaining system by which the application response time will be short.

2) Hospital nurse dont need to stay more time on a single patient.

3) More patients can be handled simultaneously.

4) Hospital cost will be reduced.

2.3. PROBLEM DEFINITION The Problem Definition can be divided into three groups
Backend: Here the constraint can be in terms of data collection like whether the hospital

has computerised system & all the data required is in soft copy or else we will have to input the data ourselves which can be a time consuming process. It also introduces a chance of error during data input.

Frontend: Here the problem can be because of the fact that we limit our client base if we

provide only window base application. In my opinion there can be 3 solutions for this :-

1. 2.

We can perform SQL optimization on Desktop/PDA/Web application We can perform SQL optimization on Web services which will run on the server. We can perform SQL optimization on SQL server 2005 Data base.

3.

Chapter - 3 REQUIREMENT ANALYSIS

3. REQUIREMENT ANALYSIS
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users. Requirements analysis is critical to the success of a project. Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term "requirements analysis" can also be applied specifically to the analysis proper (as opposed to elicitation or documentation of the requirements, for instance). Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. 3.1 ITERATIVE ENHANCEMENT DEVELOPMENT PROCESS. The iterative enhancement development model counters the limitations of commonly used waterfall model and prototyping. The major limitation of waterfall model is that the requirements are to be specified before the decision starts, but this is not feasible practically. Ideally new ideas come in to being during development from the clients as well as the developer which is not possible to merge in already started process of the waterfall model. But is a major advantage of Iterative Enhancement as the name specifies. It is sometimes required to develop a part of the product first and the other product is depended on the behavior or output of this one which means that during decision also the requirement are not clear which is not feasible in the waterfall model.
8

Iterative Enhancement development model is best suited for the development of product in real life where client is usually unaware of what the final product can do. So, Iterative Enhancement development model is chosen for development. The basic idea behind Iterative Enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of the system. Learning comes from both the development and use of the system, where possible. Key step in the process were to start with a simple implementation of a sub set of the software requirement and iteratively enhance the evolving sequence versions until the full system is implemented. Design modification is made along with addition new function capabilities. The procedure itself consists of the initialization step, the iteration step, and the project control list. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspect of the problem and provide and solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new futures to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase. The iteration step involves the redesign and implementation of the task from project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be: Simple, Straight forward, and Modular

That is supporting redesign at that stage or at as a task added to the project control list. The code represents the major source of documentation of the system. The analysis of the
9

iteration is based upon a user feedback and the program analysis facilities available. It involves the analysis of the structure, modularity, usability, reliability, efficiency, and achievement of goal. The project control list is modified in the of the analysis result.

GUIDELINES THAT DERIVE THE IMPLEMENTATION AND ANALYSIS INCLUDE: Any difficulty in design, coding and testing a modification should signal that need for redesign or re-coding. Modification should fit easily in to isolated and easy-to-find-modules. If they do not, some redesign is needed. Modification should become easier to make as the iteration progress. If they are not, there is a basic problem such as a design flaw or a proliferation of patches. Patches should normally be allowed to exist for only one or two iteration. Patches may be necessary to avoid redesigning during an implementation phase. The existing implementation should be analyzed frequently to determine how well it measures up to project goals. Program analysis facilities should be used when ever available to aid in the analysis of the partial implementation-user reaction should be solicited and analyzed for indication of deficiencies of the current implementation.

10

3.2 PROBLEM ANALYSIS 3.2.1. RECOGNITION OF NEED- WHAT IS THE PROBLEM?

With the respective hospitals in consideration, the problem can be further elaborated as:
Till date, there is no mechanism/service available to provide patient, respective hospitals

and their patients family to give the right medication to the right patient at the right time and test the blood collection etc.

3.2.4 OBJECTIVES The main objective of service are

Which segment of hospitals would find this service useful?

How many hospitals will actually use this service?

What will be the main reason for using this service?

How many hospitals would really care whether their nurse can use this service or not?

How many hospitals feel this service could help them improve their nurses performance?

11

3.2.5 DATA SOURCE a) Secondary Data As such there are no secondary data available for anything relevant to this service on net. b) Primary Data Few possible ways to collect this data are: Approach hospitals and get data from the application Ask the nurses to use the PDA/Desktop application

Visit ASHP demo which held in the December in Reston(US) 3.2.6 STRENGTHS The major strengths of service are: Simple Service with low complexity Lower Initial Investment First mover advantage

3.2.7 WEAKNESS Lack of market research Gut based approach

12

 Lack of Infrastructure No perfect expansion plan yet

1st of its kind service hence no idea of the real market situation.

3.2.8 OPPORTUNITY A big growing market

Governments focus on development of hospitals standards at primary level. General change in the trend and people going for new hospitals care choices

3.2.10 STRATEGIC FORMULATION In my opinion we should aim to capture as much market share as possible. This would help us to gain visibility in the market & would help us with our forward & backward vertical integration as per our decided plan. At present we dont have any competitor in this particular service. Particularly at present there cannot be any way of differentiation for our services till we grow and capture a larger market share.

13

3.3 SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT 3.3.1. INTRODUCTION TO SRS A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints). Software requirement specification (SRS) is the starting point of the software development activity. Little importance was given to this phase in the early days of software development. The emphasis was first on coding and then shifted to design. As systems grew more complex, it became evident that the goals of the entire system cannot be easily comprehended. Hence the need for the requirement analysis phase arose. Now, for large software systems, requirements analysis is perhaps the most difficult activity and also the most error prone. The SRS is a means of translating the ideas in the minds of the clients (the input), into formal document (the output of the requirements phase). Thus, the output of the phase is a set
14

of formally specified requirements, which hopefully are complete and consistent, while the input has none of these properties. Responsibilities of the developer Developing the system. Making the client test before the software is actually put into live. Conducting the user training, if necessary, that might be needed for using the system. Maintaining the software for a specific amount of time.

3.3.2. TECHNICAL RESEARCH Technical research is very important before starting the project. We have to specify which tools and libraries will be used in the project. Development environment, libraries, engines and tools must be carefully selected so that no integration problem will be faced up later. We conducted some research trough Internet, and got information from some experienced people to gain enough knowledge about the tools, libraries and development environments that will be used while constructing our game.

15

TECHNOLOGY USED

16

.Net Framework 3.5 C#.Net Web Services SQL Server2005

3.3.2.1 .NET FRAMEWORK 3.5 Microsoft .NET is a set of Microsoft software technologies for connecting information, people, systems, and devices. It enables a high level of software integration through the use of Web servicessmall, discrete, building-block applications that connect to each other as well as to other, larger applications over the Internet. The .NET Framework is an integral Windows component that supports building and running the next generation of applications and XML Web services. The .NET Framework is designed to fulfill the following objectives: To provide a consistent object-oriented programming environment whether

object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely. To provide a code-execution environment that minimizes software deployment

and versioning conflicts. To provide a code-execution environment that promotes safe execution of code,

including code created by an unknown or semi-trusted third party.

17

To provide a code-execution environment that eliminates the performance

problems of scripted or interpreted environments. To make the developers experience consistent across widely varying types of

applications, such as Windows-based applications and Web-based applications. To build all communication on industry standards to ensure that code based on

the .NET Framework can integrate with any other code. The .NET Framework has two main components: the common language runtime the .NET Framework class library.

a) COMMON LANGUAGE RUNTIME(CLR) The common language runtime is the foundation of the .NET Framework. You can think of the runtime as an agent that manages code at execution time, providing core services such as memory management, thread management, and remoting, while also enforcing strict type safety and other forms of code accuracy that promote security and robustness. In fact, the concept of code management is a fundamental principle of the runtime. Code that targets the runtime is known as managed code, while code that does not target the runtime is known as unmanaged code. The class library, the other main component of the .NET Framework, is a comprehensive, object-oriented collection of reusable types that you can use to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by ASP.NET, such as Web Forms and XML Web services.

18

The .NET Framework can be hosted by unmanaged components that load the common language runtime into their processes and initiate the execution of managed code, thereby creating a software environment that can exploit both managed and unmanaged features. The .NET Framework not only provides several runtime hosts, but also supports the development of third-party runtime hosts. For example, ASP.NET hosts the runtime to provide a scalable, server-side environment for managed code. ASP.NET works directly with the runtime to enable ASP.NET applications and XML Web services, both of which are discussed later in this topic. Internet Explorer is an example of an unmanaged application that hosts the runtime (in the form of a MIME type extension). Using Internet Explorer to host the runtime enables you to embed managed components or Windows Forms controls in HTML documents. Hosting the runtime in this way makes managed mobile code (similar to Microsoft ActiveX controls) possible, but with significant improvements that only managed code can offer, such as semitrusted execution and isolated file storage.

Fig:- .NET FRAMEWORK ARCHITECTURE

19

b) .NET FRAMEWORK CLASS LIBRARY The .NET Framework class library is a collection of reusable types that tightly integrate with the common language runtime. The class library is object oriented, providing types from which your own managed code can derive functionality. This not only makes the .NET Framework types easy to use, but also reduces the time associated with learning new features of the .NET Framework. In addition, third-party components can integrate seamlessly with classes in the .NET Framework. For example, the .NET Framework collection classes implement a set of interfaces that you can use to develop your own collection classes. Your collection classes will blend seamlessly with the classes in the .NET Framework. As you would expect from an object-oriented class library, the .NET Framework types enable you to accomplish a range of common programming tasks, including tasks such as
20

string management, data collection, database connectivity, and file access. In addition to these common tasks, the class library includes types that support a variety of specialized development scenarios. For example, you can use the .NET Framework to develop the following types of applications and services: Console applications. Windows GUI applications (Windows Forms). ASP.NET applications. XML Web services. Windows services.

For example, the Windows Forms classes are a comprehensive set of reusable types that vastly simplify Windows GUI development. If you write an ASP.NET Web Form application, you can use the Web Forms classes.

The .NET Framework consists of 3 main parts. i) Programming languages. C# (Pronounced C sharp) Visual Basic (VB .NET) J# (Pronounced J sharp)

ii) Server Technologies and Client Technologies ASP .NET (Active Server Pages) Windows Forms (Windows desktop solutions)
21

Compact Framework (PDA / Mobile solutions)

iii) Development Environments Development environments. Visual Studio .NET (VS .NET). Visual Web Developer

Fig:- NET FRAMEWORK CLASS LIBRARY

22

3.3.2.2 C# a) About C# C# is an object-oriented programming language developed by Microsoft as part of the .NET initiative and later approved as a standard by ECMA and ISO. Anders Hejlsberg leads development of the C# language, which has a procedural, object-oriented syntax based on C++ and includes influences from aspects of several other programming languages (most notably Delphi and Java) with a particular emphasis on simplification. By design, C# is the programming language that most directly reflects the underlying Common Language Infrastructure (CLI). C# language specification does not state the code generation

23

requirements of the compiler: that is, it does not state that a C# compiler must target a Common Language Runtime (CLR), or generate Common Intermediate Language (CIL), or generate any other specific format. b) Features C# differs from C and C++ in many ways, including: There are no global variables or functions. All methods and members must be

declared within classes. C++. c) C# Keywords Keywords are predefined reserved identifiers that have special meanings to the compiler. They cannot be used as identifiers in your program unless they include @ as a prefix. For example, @if is a legal identifier but if is not because it is a keyword. d) C# Operators C# provides a large set of operators, which are symbols that specify which operations to perform in an expression. C# predefines the usual arithmetic and logical operators, as well as a variety of others. In addition, many operators can be overloaded by the user, thus changing their meaning when applied to a user-defined type. e) Future development: Future versions of C# are under development, though their exact specification is not finalized. It will feature enhanced support for Reflection as well as an enhanced Microsoft Office interop library. It will also integrate with the Dynamic Language Runtime and allow C# to call into code written in DLR-based languages using a syntax similar to what C# uses for CLR methods and objects. Local variables cannot shadow variables of the enclosing block, unlike C and

3.3.2.3 WEB SERVICES

24

A 'Web service' (also Web Service) is defined by the W3C as "a software system designed to support interoperable Machine to Machine interaction over a network." Web services are frequently just Web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. This document (WSA) is intended to provide a common definition of a Web service, and define its place within a larger Web services framework to guide the community. The WSA provides a conceptual model and a context for understanding Web services and the relationships between the components of this model. The architecture does not attempt to specify how Web services are implemented, and imposes no restriction on how Web services might be combined. The WSA describes both the minimal characteristics that are common to all Web services, and a number of characteristics that are needed by many, but not all, Web services. The Web services architecture is an interoperability architecture: it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services.

The W3C Web service definition encompasses many different systems, but in common usage the term refers to clients and servers that communicate using XML messages that follow the SOAP standard. In such systems, there is often machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). The latter is not a requirement of a SOAP endpoint, but it is a prerequisite for automated clientside code generation in many Java and .NET SOAP frameworks (frameworks such as Spring, Apache Axis2 and Apache CXF being notable exceptions). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a Web service.

25

More recently, RESTful Web services have been regaining popularity. These also meet the W3C definition, and are often better integrated with HTTP than SOAP-based services. They do not require XML messages or WSDL service-API definitions. a) How Does it Work? The basic Web services platform is XML + HTTP. The HTTP protocol is the most used Internet protocol. XML provides a language which can be used between different platforms and

programming languages and still express complex messages and functions. b) Web services platform elements SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language)

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. c) Agents and Services

A Web service is an abstract notion that must be implemented by a concrete agent. The agent is the concrete piece of software or hardware that sends and receives messages, while the service is the resource characterized by the abstract set of functionality that is provided. To illustrate this distinction, you might implement a particular Web service using one agent one day (perhaps written in one programming language), and a different agent the next day
26

(perhaps written in a different programming language) with the same functionality. Although the agent may have changed, the Web service remains the same. d) Requesters and Providers

The purpose of a Web service is to provide some functionality on behalf of its owner -- a person or organization, such as a business or an individual. The provider entity is the person or organization that provides an appropriate agent to implement a particular service e) Web Services Security

Developed at OASIS, Web Services Security (WSS) defines a SOAP extension providing quality of protection through message integrity, message confidentiality, and message authentication. WSS mechanisms can be used to accommodate a wide variety of security models and encryption technologies. The work provides a general mechanism for associating security tokens with messages. The specification does not require a specific type of security token. It is designed to support multiple security token formats. WSS describes how to encode binary security tokens. The specification describes how to encode X.509 certificates and Kerberos tickets.

27

3.3.2.5 SQL SERVER 2008 a) What is SQL? SQL stands for Structured Query Language SQL allows you to access a database SQL is an ANSI standard computer language SQL can execute queries against a database SQL can retrieve data from a database SQL can insert new records in a database SQL can delete records from a database SQL can update records in a database SQL is easy to learn. SQL is an ANSI (American National Standards Institute) standard computer language for accessing and manipulating database systems. SQL statements are used to retrieve and update data in a database. SQL works with database programs like MS Access, DB2, Informix, MS SQL Server, Oracle, Sybase, etc. Unfortunately, there are many different versions of the SQL language, but to be in compliance with the ANSI standard, they must support the same major keywords in a similar manner (such as SELECT, UPDATE, DELETE, INSERT, WHERE, and others).

b) SQL Database Tables A database most often contains one or more tables. Each table is identified by a name (e.g. "Customers" or "Orders"). Tables contain records (rows) with data.

c) SQL Data Manipulation Language (DML) SQL (Structured Query Language) is a syntax for executing queries. But the SQL language also includes a syntax to update, insert, and delete records.

28

These query and update commands together form the Data Manipulation Language (DML) part of SQL. SELECT - extracts data from a database table. UPDATE - updates data in a database table DELETE - deletes data from a database table. INSERT INTO - inserts new data into a database table.

d) SQL Data Definition Language (DDL) The Data Definition Language (DDL) part of SQL permits database tables to be created or deleted. We can also define indexes (keys), specify links between tables, and impose constraints between database tables. The most important DDL statements in SQL are: CREATE TABLE - creates a new database table. ALTER TABLE - alters (changes) a database table. DROP TABLE - deletes a database table. CREATE INDEX - creates an index (search key). DROP INDEX - deletes an index.

SQL Server 2005 Express Edition is the next version of MSDE and is a free, easy-to-use, lightweight, and embeddable version of SQL Server 2005. Free to download, free to redistribute, free to embed, and easy for new developers to use immediately, SQL Server Express Edition includes powerful features such as SQL Server 2005 Reporting Services, a server-based platform for creating and delivering traditional and interactive reports, and a graphical management tool, SQL Server 2005 Management Studio Express, for easily

29

managing your database. Best of all, as your needs grow, your applications will seamlessly work with the rest of the SQL Server product family. SQL Server 2005, released in November 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 requests. When the data is access over web services, results are returned as XML. For relational data, T-SQL has been augmented with error handling features and support for recursive queries. SQL Server 2005 has also been enhanced with new indexing algorithms and better error recovery systems. Data pages are checksummed for better error resiliency, and optimistic concurrency support has been added for better performance. Permissions and access control have been made more granular and the query processor handles concurrent execution of queries in a more efficient way. Partitions on tables and indexes are supported natively, so scaling out a database onto a cluster is easier. SQL CLR was introduced with SQL Server 2005 to let it integrate with the .NET Framework.

e) Stored Procedure Basics Stored procedures in Microsoft SQL Server are similar to procedures in other programming languages in that they can: Accept input parameters and return multiple values in the form of output

parameters to the calling procedure or batch.

30

Contain programming statements that perform operations in the database,

including calling other procedures. Return a status value to a calling procedure or batch to indicate success or

failure (and the reason for failure). You can use the Transact-SQL EXECUTE statement to run a stored procedure. Stored procedures are different from functions in that they do not return values in place of their names and they cannot be used directly in an expression. The benefits of using stored procedures in SQL Server rather than Transact-SQL programs stored locally on client computers are: They are registered at the server. They can have security attributes (such as permissions) and ownership chaining,

and certificates can be attached to them. Users can be granted permission to execute a stored procedure without having

to have direct permissions on the objects referenced in the procedure. They can enhance the security of your application. Parameterized stored procedures can help protect your application from SQL

Injection attacks. For more information see SQL Injection. They allow modular programming. You can create the procedure once, and call it any number of times in your

program. This can improve the maintainability of your application and allow applications to access the database in a uniform manner. They are named code allowing for delayed binding. This provides a level of indirection for easy code evolution. They can reduce network traffic.

31

An operation requiring hundreds of lines of Transact-SQL code can be

performed through a single statement that executes the code in a procedure, rather than by sending hundreds of lines of code over the network.

f)

Table Basics

Tables are database objects that contain all the data in a database. A table definition is a collection of columns. In tables, data is organized in a row-and-column format similar to a spreadsheet. Each row represents a unique record, and each column represents a field within the record. For example, a table that contains employee data for a company can contain a row for each employee and columns representing employee information such as employee number, name, address, job title, and home telephone number. Tables in SQL Server 2005 have the following main components: Columns

Each column represents some attribute of the object modeled by the table, such as a parts table having columns for ID, color, and weight. Rows

Each row represents an individual occurrence of the object modeled by the table. For example, the parts table would have one row for each part carried by the company.

32

3.3.3 FEASIBILITY The feasibility study is used to determine if the project should get the go-ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development. A feasibility study is a preliminary study undertaken to determine and document a project's viability. The results of this study are used to make a decision whether to proceed with the project, or table it. If it indeed leads to a project being approved, it will - before the real work of the proposed project starts - be used to ascertain the likelihood of the project's success. It is an analysis of possible alternative solutions to a problem and a recommendation on the best alternative. It, for example, can decide whether an order processing be carried out by a new system more efficiently than the previous one. A feasibility study could be used to test a new working system, which could be used because: The current system may no longer suit its purpose Technological advancement may have rendered the current system redundant The business is expanding, allowing it to cope with extra work load Customers are complaining about the speed and quality of work the business

provides Competitors are now winning a big enough market share due to an effective

integration of a computerized system Within a feasibility study, many areas must be reviewed, including those of

Economics, Technical, Schedule, Organizational

33

FEASIBILITY STUDY

34

Technical Feasibility Ecnomical Feasibility Organizational Feasibility Schedule Feasibility

3.3.3.1 TECHNICAL FEASIBILITY STUDY This involves questions such as whether the technology needed for the system exists, how difficult it will be to build, and whether the firm has enough experience using that technology. The assessment is based on an outline design of system requirements. This can be qualified in terms of volumes of data, trends, frequency of updating, etc. In order to give an introduction to the technical system. The organization is equipped with the latest computer workstations and as the software would be developed in the C#.NET and ASP.NET, SQL Server 2005 which is one of the most portable programming languages therefore organization is technically compliant with the software requirements. 3.3.3.2 Organizational Feasibility study This involves questions such as whether the system has enough support to be implemented successfully, whether it brings an excessive amount of change, and whether the organization is changing too rapidly to absorb it. After the system has been implemented it would become very easy for the students to get ebooks from the library using his/her user name and password itself generated by the server when there is no book available in the library and these e-books can be downloaded ,save
35

,email and also open. The whole control is under admin followed by sub admin which upload the files in the system and user with various options to search for the particular book. The current system being followed in the organization is the manual system in which the teachers students themselves access the e- books to their systems for studying purpose, the system is quite erroneous, cumbersome and quite time consuming. The software will serve as a helping hand for the library, and will enable them to keep record of the e-books in a more efficient manner than the current manual system by making the ebooks directly avail to students and marking less time consuming, easy and automated.

3.3.3.3 ECONOMICAL FEASIBILITY STUDY This involves questions such as whether the firm can afford to build the system, whether its benefits should substantially exceed its costs, and whether the project has higher priority and profits than other projects that might use the same resources. This also includes whether the project is in the condition to fulfill all the eligibility criteria and the responsibility of both sides in case there are two parties involved in performing any project. SOFTWARE COST:

Web Services Oracle Server ASP.Net / C#

: : :

20000/15000/12000/-

MAN POWER COST:

36

Team cost System Cost

: :

30000/45,000/-

TOTAL COST:

Total Cost

122000/-

3.3.3.4 Schedule Feasibility study This involves questions such as how much time is available to build the new system, when it can be built (i.e. during holidays), whether it interferes with normal business operation, etc.

Time Duration
For study Designing For development Testing 40 days 20 days 90 days 15 days

Total time

165 days

37

3.4 OPERATING ENVIRONMENT a) Software Requirements Platform: Windows (R) XP Professional with service pack 2 or higher. C#.NET Microsoft SQL Server 2005 Internet Explorer 7 Web Services b) Hardware Requirments Pentimum IV Processors Speed 1.5GHz 256 MB of RAM 5GB of Hard Disk

38

Chapter - 4 SOFTWARE DESIGN

39

4. SOFTWARE DESIGN
4.1. SYSTEM DESIGN This is where the technical blueprint of the system is created by

Designing the technical architecture choosing amongst the architectural

designs of telecommunications, hardware and software that will best suit the organizations system and future needs.

Designing the systems model graphically creating a model from graphical

user interface (GUI), GUI screen design, and databases, to placement of objects on screen. Systems design is the process or art of defining the hardware and software architecture, components, modules, interfaces, and data for a computer system to satisfy specified requirements. 4.2. STRUCTURED ANALYSIS Structured analysis is a set of technique and graphical tools that allow the analysis to develop a new kind of system specifications that are easily understandable to the user. The traditional approach focuses on cost/ benefit and feasibility analysis, project management, hardware and software selection and personnel considerations. In contrast structured analysis considers new goal and structured tools for analysis. The new goals specify the following: Use graphical wherever possible to help communicate better with the user. Differentiate between logical and physical systems. Build a logical system model to familiarize the user with system characteristics

and interrelationship before implementations.

40

4.2.1 STRUCTURED ANALYSIS TOOLS DFD (Data flow diagram) Structured English Data dictionary Decision table Decision tree The design is a solution a "how to" approach, compared to analysis ,a "what is" orientation. It translates the system requirements in to ways of operational zing them. The design phase focuses on the detailed implementation of the recommended in the feasibility study Emphasis is on translation performance specifications. The design phase is a transaction from a user-oriented document to a document oriented to the programmers or database personnel. System design goes through two phases of development: logical and physical Design. DFD shows the logical flow of a system and defines the boundaries of the system .For a candidate system, it describes the input (source) ,output(destination) ,database(data store) ,&procedure(dataflow)-all in a format that meets the user requirements. Physical design is the preparation of design that showed what the systems physically look like. This is the drafting process. System design through logical & physical design. a) ENTITY -RELATIONSHIP MODEL

As a database designer one should use an entity relationship(ER) diagram as a tool to build the logical database design of the system. An ER diagram represents the following three elements.
i)

ENTITIES: An entity is an object with a district set of properties that is easily

identified. Entities are the building blocks of a database. You represent an entity using a rectangular box that contains the name of the entity.
41

ii)

ATTRIBUTES: An attribute is a property of an entity that differentiates it from

other entities and provides information about the entity. An attribute type is a property of an entity type.
iii)

RELATIONSHIP: A relationship is a crucial part of the design of a database.

It is used to establish a connection between a pair of logically related entities. Separate entities can have relationship with each other. Relationship is represented between two entities using a diamond labeled with the name of the relationship.
Fig:- ER Models Symbols

b)

DATA FLOW DIAGRAM

Data Flow Diagramming is a means of representing a system at any level of detail with a graphic network of symbols showing data flows, data stores, data processes, and data sources/destination. The data flow diagram is analogous to a road map. It is a network model of all possibilities with different detail shown on different hierarchical levels. This processes of representing different details level is called leveling or partitioning by some data flow diagram advocates. Like a road map, there is no starting point or stop point, no time or timing, or steps to get somewhere. We just know that the data path must exist because at some point it will be needed. A road map shows all existing or planned roads because the road is needed.
42

Details that is not shown on the different levels of the data flow diagram such as volumes, timing, frequency, etc. is shown on supplementary diagrams or in the data dictionary. For example, data store contents may be shown in the data dictionary. Data Flow Diagram (DFD) uses a number of symbols to represent the systems. Data Flow Diagram also known as Bubble Chart is used to clarify system requirements and identifying the major transformations that will become programs in system design. So it is the starting point of the design phase that functionally decomposes the requirements specifications down to the level of details. Terms used in DFD i) Process

A process transforms data values. The lowest level processes are pure functions without side effects. An entire data flow graphics high level process.
Fig: Process

ii)

Data flows

A data flow connects the output of an object or process to input of another object or process. It represents the intermediate data value within a computation. It is represented by an arrow and labeled with a description of data, usually its name or type.
Fig: Dataflow

43

iii)

Data store

A data store is a passive object with in a data flow diagram that stores data for later access.
Fig: Data Store

iv)

External Entity

A rectangle represents an external entity such as a librarian ,a library member.

Fig: External Entity Notations

44

4.3 COMPONENT LEVEL DETAILED LEVEL DESIGN 4.3.1 ER DIAGRAMs USED IN PROJECT
i)

User Master :Passward First Name

Last Name

User Id

User
Initials Title Location

ii)

Allergy :-

45

All Id Patient Id

ALLERGY

Type

Created By

Discri ption

iii)

Drug :-

Created By Drug Id

DRUG
Last Updated

Strength

Nam e

46

iv) Med Pass :-

47

MED PASS

iv)

Med Pass Status :-

LMPS CD

Name

Last Updated By

MED PASS STATUS

Last Updated DT Creat ed DT Create d By

v)

Order Status :48

Last Updated DT

LOS CD

ORDER STATUS
Last updated Name Create d By

vi)

Order Type :-

Name LOT CD

ORDER TYPE
Last Updated BY Create d By

vii)

Provider :-

49

Last Updated DT Last Updated BY

Name

PROVIDER
Intials Title Create d By

viii)

Patients :-

50

PATIENT

ix)

Reason :-

Name Created By

ID

REASON
Reaso n

Last Updated BY

Row Order

x)

Reason Type :-

51

Created BY

Name

Last Updated BY

REASON TYPE
LRT CD Create d DT

Last Updated DT

52

4.3.2 DATA TABLEs USED IN PROJECT

i) CFAP_ALLERGY

PRIMARY KEY - ALL_ID ii) CFAP_DRUG

53

PRIMARY KEY - DRUG_ID FOREIGN KEY DRUG_NDC_NUMBER

iii) CFAP_LKP_MED_PASS_STATUS

54

PRIMARY KEY - LMPS_CD FOREIGN KEY a) LMPS_NAME b) LMPS_CREATED_DT

iv) CFAP_LKP_ORDER_STATUS

PRIMARY KEY LOS_CD FOREIGN KEY LOS_NAME

v) CFAP_LKP_ORDER_TYPE

55

PRIMARY KEY LOT_CD

vi) CFAP_LKP_PROVIDER

PRIMARY KEY - LP_CD FOREIGN KEY LP_NAME

56

vii) CFAP_LKP_REASON

PRIMARY KEY - LR_ID FOREIGN KEY a) LR_TYPE_CD b) LR_REASON

viii)
CFAP_LKP_REASON_TYPE

PRIMARY KEY - LRT_CD FOREIGN KEY a) LRT_NAME

57

b) LRT_CREATED_DT c) LRT_CREATED _BY

ix) CFAP_MED_PASS

PRIMARY KEY - MP_ID

58

x) CFAP_ORDER

PRIMARY KEY - ORD_ID FOREIGN KEY ORD_PATIENT_ID

59

xi) CFAP_PATIENT

PRIMARY KEY - PAT_ID FOREIGN KEY a) PAT_SSN b) PAT_FIRST_NAME

60

xii ) CFAP_USER

PRIMARY KEY - USER_ID FOREIGN KEY a) USER_PASSWARD b) USER_FIRST_NAME

61

4.4 IMPLEMENTATION 4.4.1 INTRODUCTION In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters, Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.
It is the process of having system personnel checkout and put new equipment into use,

train users , install the new application and construct any files of data needed to use it. This phase is less creative than system design.
Implementation the systems are placed and used in the actual workforce and the user

guide is created .Training is provided to the users of the system - usually through workshops or online . Software Implementation is the final, and most involved, step in IMECs 4-step approach to Information System Optimization.

62

4.4.2 IMPLEMENTATION TOOLS The various phases of implementing new system are as following:

Conversion: This means the changing from one system to another. The

objective is to put the tested system in to operation. The method adopted for conversion for this system is parallel system. Under this method both the system old and new are operated parallel. This is the safest method. Error can be prime concern during the conversion this will be done on side. The data will be entered to the database from the existing register.

Training: The quality or training received by the personnel involved with the

system in various capacities helps or hinders and may even prevent the successful implementation of an information system. Those who will be associated with or affected by the system need to be trained. Training the personnel will be in house. The user of the system will be trained that what the system can be and what can not.

Post implementation review: After the system is implemented and conversion

is complete a review of the system will be done. It is the formal process to determine how well the system is working, how it has been accepted and whether adjustments are needed.

4.4.3 TYPES OF IMPLEMENTATION There are three types of implementation: Implementation of a computer system to replace a manual system. Implementation of a new computer system to replace an existing one. Implementation of a modified application to replace an existing one using the

same computer.

63

Chapter - 5 OUTPUT SCREENS

64

5. OUTPUT SCREEN
5.1. LOGIN SCREEN a) LOGIN

65

5.2. INCORRECT PASSWORD SCREEN

66

5.3 CHANGE PASSWORD SCREEN

5.4 DATA VIEW MAIN SCREEN

67

5.5 SEARCH PATIENT ID WITH THE HELP OF OPTIMIZE QUERY.

5.6 SEARCH PATIENT PROVIDER WITH THE HELP OF OPTIMIZE QUERY

68

5.7 GET PATIENT ORDER DATA WITH THE HELP OF OPTIMIZE QUERY

5.8 GET PATIENT HELD DATA WITH THE HELP OF OPTIMIZE QUERY

69

5.9 GET PATIENT DEMOGRAPHICS DATA WITH THE HELP OF OPTIMIZE QUERY

5.10 GET PATIENT DISCONTINUED ORDERS WITH THE HELP OF OPTIMIZE QUERY

5.11 GET PATIENT ORDERS IN SCV APPLICATION WITH THE HELP OF OPTIMIZE QUERY
70

71

Chapter - 6 TESTING

72

6. TESTING
Testing of software is one of the most critical and important element of software quality assurance and represent the ultimate review of specification design, coding. Purpose of software testing is to verify and validate various work products viz. unit integrated unit, final product to ensure that they meet the requirements. 6.1. OBJECTIVES OF TESTING Testing is conducted for the following purposes:(1). It is the process of executing program with the intent of finding an error. (2). A good test case is one that has a high probability of finding an as yet undiscovered error.

(3). A successful test case is one that uncovers an as yet undiscovered error. Our main objective is to design test cases that systematically uncover different classes of error and they do so with a minimum amount of time and effort. This process has two parts:(i) Planning:This involves writing and reviewing unit integration testing, functional testing, validation and acceptance test plans. (ii) Execution:This involves executing these test plans, measuring data, collecting data and to check if it meets the requirements based on the quality criteria. Data collected, is used to make appropriate changes in the plans related to development and testing. The quality of a product or an item can be achieved by ensuring that the product meets the requirements by planning and conducting the following testes at various stages.

73

6.2. LEVEL OF TESTING In order to uncover the errors present in different phases we have the concept of levels of testing. The basic levels of testing are as shown below

Fig: Levels of Testing

Acceptance Testing

Client Needs Requirements

System Testing

Integration Testing

Design

Unit Testing

Code

The basic levels are: 1. Unit Testing 2. Integration Testing 3. System Testing 4. Acceptance Testing 6.2.1. UNIT TESTING In this, different modules are tested against the specifications produced during design for the modules.Unit testing is essentially for the verification of the code produced during the coding phase.This is done by both of us by considering that a module can be used by othersonly after it
74

has been unit tested satisfactorily. Due to its close association with coding, the coding phase is frequently called coding and unit testing. 6.2.2.INTEGRATION TESTING In this, many unit tested modules are combined into subsystems, which are then tested. The main goal here is to see if the modules can be integrated properly. Hence, our emphasis is on testing interfaces between modules. Thus, this testing activity can be considered testing the design. 6.2.3.SYSTEM TESTING Here the entire software system is tested. The reference document for this purpose is the requirements document and the goal is to see if the software meets its requirements. This is essentially a validation exercise, and in many situations it is only validation activity. Acceptance testing is sometimes performed with realistic data of the client to demonstrate that software is working satisfactory. Testing here focuses on the external Behaviour of the system: the internal logic of the program is not emphasized. Consequently, mostly functional testing is performed at these levels. The two approaches of testing are : 1. Black box or Functional Testing 2. White box or Structural Testings

I. Functional Testing The function testing is concerned with functionality rather than implementation of the program. Here, test cases are generated based upon the actual code of the program or module to be tested. This structural approach is sometimes called glass box testing .The intent of structural testing is not to exercise all the different input or output conditions but to exercise the different programming structures and data structures used in the program. To test the structure of a program, structural testing aims to achieve test cases that will force the desired coverage of
75

different structures. Various criteria have been proposed for this. Unlike the criteria for functional testing, which are frequently imprecise, the criteria for structural testing are generally quite precise as they are based on program structures, which are formal and precise.
a) Functional Test Cases advantages.

They are independent of how the software is implemented, so if the implementation Changes, Test Cases are still useful TC development can occur in parallel with implementation, thereby reducing overall project development time.

b) Functional Test Cases disadvantages 1. Significant redundancies may exist among Test Cases 2. Possibility of gaps of untested software. Advantages of Black Box Testing 1. The test is unbiased as the designer and the tester are independent of each other. 2. The tester does not need knowledge of any specific programming languages. 3. The test is done from the point of view of the user, not the designer. 4. Test cases can be designed as soon as the specifications are complete. 5. Disadvantages of Black Box Testing 1. The test can be redundant if the software designer has already run a test case. 2. The test cases are difficult to design.

II. Structural testing In functional testing the structure of the program is not considered.Test cases are decided solely on the basis of the requirements or specifications of the program or module,and the
76

internals of the module or the program are not considered for selection of test cases.Due to its nature,functional testing is often called Black Box Testing . The basic for deciding test cases in functional testing is the requirements or specifications of the system or module. For the entire system, the test cases are designed from the requirements specifications document for the system. For modules created during design, test cases for functional testing are decided from the module specifications produced during the design. There are a number of techniques that can be used to select test cases that have been found to be very successful in detecting errors. Here we mention some of these techniques:1. Equivalence Class Partitioning 2. Boundary Value Analysis 3. Error Guessing Also known as Clear Box, Structural or Glass Box Testing. The ability to see inside the Black Box allows the tester to identify Test Cases based on how the function is actually implemented. White box deals with the internal logic, design and structure of the code. Developer is the best person to know the code as he is the one who actually wrote it. White Box testing Guarantee that all independent paths within a module have been exercised at least once. Exercise all logical decisions on their true and false values. Execute all loops at their boundaries and within their operational bounds . Exercise internal data structure to ensure their validity. Advantages of White Box Testing 1. Helps in optimizing the code. 2. Reveals hidden errors in the code. 3. Tester can rigorously describe exactly what is tested.
77

4. Forces tester to reason carefully about implementation. Disadvantages of White Box Testing 1. As knowledge of code and internal structure is a prerequisite, skilled tester needs to carry out this type of testing, which increases cost. 2. The developer will always have the same perspective towards the approach of solving the problem, thus, the special cases that he missed when actually building of program will probably stay un-noticed. And it is nearly impossible to look into every bit of code to find out hidden errors. 3. Expensive. 4. Slow approach. 6.2.4. ACCEPTANCE TESTING This is the final step in the process of software testing life cycle. This testing is performed to demonstrate to the client, on the real life data of the client, the operations of the system. Testing is an extremely critical and time consuming activity. It requires proper planning of the overall testing process. Frequently the testing process starts with a test plan that identifies all the testing related activities that must be performed and specifies the schedule, allocate the resources, and specifies guidelines for testing. The test plan specifies conditions that should be tested, different units to be tested and the manner in which the modules will be integrated together. Then for different test units, a test case specification document is produced, which lists all the different test cases, together with the expected outputs. During the testing of the unit, the specified test cases are executed and the actual result is compared with the expected output. The final output of the testing phase is the test report and the error report or a set of such reports (one for each unit tested). Each test report contains the set of test cases and the result of executing the code with these test cases .The error report describes the error encountered and the action taken to remove errors.
78

a) FEATURES TO BE TESTED In the testing features we test all the functional features specified in the requirements document. In this we check the test cases that whether the outputs achieved are: Equivalent to the corresponding specified results. Testing will be done for the performance, as the throughput and the response time in the project are the strong features. b) TEST PLAN In a software development projects, errors can be injected at any stage during development. For each phase, we have discussed different techniques for detecting and eliminating errors that originate in that phase. However, no technique is perfect, and it is expected that some of the errors of the earlier phases will finally manifest themselves in the code. This is particularly true because in the earlier phases, most of the verification techniques are manual because no executable code exists. Ultimately, these remaining errors will be reflected in the code. Because code is frequently the only product that can be executed and whose actual behaviour can be observed, testing is the phase where the errors remaining from all the previous phases must be detected. Hence, testing performs a very critical role for quality assurance and for ensuring the reliability of software. In general, testing commences with a test plan and terminates with acceptance testing. A test plan is general document for the entire project that defines the scope, approach to be taken, and the schedule of testing as well as identifies the test items for the entire testing process and the personnel responsible for the different activities of testing. The test planning can be done well before the actual testing commences and can be done in parallel with the coding and designing phases. The inputs for forming the test plans are:(1) Project plan. (2) Requirements document. (3) System Design document.
79

A test plan should contain the following:

Fig: Test Plan

Test unit specification. Features to be tested. Approach for testing. Test deliverables. Schedule. Personnel allocation.

c) TEST DELIVERABLES In addition to the test plan, the following documents are required for testing: 1. Unit test report for each unit. 2. Test case specification for system testing.
80

3. Test report for system testing. 4. Error report.

Chapter - 7 IMPLEMENTATION AND EVALUATION REPORT

81

82

7. IMPLEMENTATION AND EVALUATION REPORT

7.1. SYSTEM IMPLEMENTATION

Stage Key Question

: User training : What is the actual operation? : Are user manuals ready? Are there delays in loading the files?

Result

: Training program User friendly documentation

The implementation phase is less creative than system design. During the final testing, user acceptance is testing, user acceptance is tested followed by user training. Depending upon the nature of the system, extensive user training may be required. 7.2. POST IMPLEMENTATION & TESTING

Stage

: Evaluation Maintenance Enhancement

Key

: Is key system running?

83

Question Result

Should the system be modified? : User requirement meet User standards met Satisfied user

After the completion of the installation phase is completed, the user staff is adjusted to the changes created by the candidate system, evaluation and maintenance begin. 7.3. MAINTENANCE Inevitably the system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period. In software engineering, software maintenance is the process of enhancing and optimizing deployed software (software release), as well as remedying defects. Software maintenance is one of the phases in the software development process, and follows deployment of the software into the field. The software maintenance phase involves changes to the software in order to correct defects and deficiencies found during field usage as well as the addition of new functionality to improve the software's usability and applicability. Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work. In comparison, about of all civil engineering, architecture, and construction work is maintenance in a similar way.

84

Maintenance is keeping the system up to date with the changes in the organization and ensuring it meets the goals of the organization. System maintenance can be classified into three types of activities. These are as follows:

Corrective Maintenance: Almost software that is developed has residual

errors, or bugs in them. Many of these surfaces only after the system have been in operation, sometimes for long time. These errors once discovered need to be remove leading to the software getting changed.

Perfective Maintenance: Sometimes changes have to be done according to

users requirement. This type of changes to the software is called perfective maintenance.

Adaptive Maintenance: Software often must be upgraded and enhanced to

include more features and provide more services. This also requires modification of software. The change in environment by deploying the software also leads to changes in the software.

85

CONCLUSION AND SCOPE FOR FURTHER ENHANCEMENTS

We do understand that without the co-operation from the hospital authorities, we cannot acclaim any sort of Hall of fame. The relation that we intend to establish with the hospital is very deep and will go far beyond the limitations of the following points:
Exchange of historical data related to patient treatment by the doctors both in internal and

external ward. (Perfect confidentiality of all data is ensured) Providing related infrastructure to conduct sessions/workshops
Display of notices/ information mentioned by Optimization of SQL Query in the

designated places through designated medium of communication

Providing opportunity to Optimization of SQL Query for advertising the services to the

hospitals and their doctors for proper visibility of the services Disclosure of all relevant information within a stipulated duration of time (Applies to both parties)
Providing resources manpower and infrastructure according to the mutually agreed

stems

86

BIBLIOGRAPHY

BOOKS & MANUALS:

C# .Net programming, Black Book by Steven Holzner.

Beginning ASP.NET, Wrox Edition, By Ullman. Complete reference ASP.NET.

www.Google.com. www.macronimous.com. www.msdn.com.

Microsoft knowledge base (online).

www.4guysfromrolla.com. www.dotnetspider.com.

87

 www.w3schools.com/webservices.aspx(Tutorial).

www.sqlauthority.com

88