HOSPITAL MANAGEMENT SYSTEM PROJECT REPORT

HOSPITAL MANAGEMENT SYSTEM PROJECT REPORT 

 PROJECT REPORT

HOSPITAL MANAGEMENT SYSTEM PROJECT REPORT

PROJECT SOURCE CODE

HOSPITAL MANAGEMENT SYSTEM SOURCE CODE IN ASP.NET

FREE DOWNLOAD ALL THE PROJECT REPORTS WITH SOURCE CODE FROM HERE

OBJECTIVE :       

Hospitals currently use a manual system for the management and maintenance of critical information. The current system requires numerous paper forms, with data stores spread throughout the hospital management infrastructure. Often information (on forms) is incomplete, or does not follow management standards. Forms are often lost in transit between departments requiring a comprehensive auditing process to ensure that no vital information is lost. Multiple copies of the same information exist in the hospital and may lead to inconsistencies in data in various data stores.

A significant part of the operation of any hospital involves the acquisition, management and timely retrieval of great volumes of information. This information typically involves; patient personal information and medical history, staff information, room and ward scheduling, staff scheduling, operating theater scheduling and various facilities waiting lists. All of this information must be managed in an efficient and cost wise fashion so that an institution's resources may be effectively utilized HMS will automate the management of the hospital making it more efficient and error free. It aims at standardizing data, consolidating data ensuring data integrity and reducing inconsistencies.

PROJECT OVERVIEW : HOSPITAL MANAGEMENT SYSTEM PROJECT

                       

The Hospital Management System (HMS) is designed for Any Hospital to replace their existing manual, paper based system. The new system is to control the following information; patient information, room availability, staff and operating room schedules, and patient invoices. These services are to be provided in an efficient, cost effective manner, with the goal of reducing the time and resources currently required for such tasks.

A significant part of the operation of any hospital involves the acquisition, management and timely retrieval of great volumes of information. This information typically involves; patient personal information and medical history, staff information, room and ward scheduling, staff scheduling, operating theater scheduling and various facilities waiting lists. All of this information must be managed in an efficient and cost wise fashion so that an institution's resources may be effectively utilized HMS will automate the management of the hospital making it more efficient and error free. It aims at standardizing data, consolidating data ensuring data integrity and reducing inconsistencies.

SYSTEM DESIGN: HOSPITAL MANAGEMENT SYSTEM PROJECT

               In this software we have developed some forms. The brief description about them is as follow:-

Reception:

The reception module handles various enquiries about the patient's admission and discharge details, bed census, and the patient's movements within the hospital. The system can also handle fixed-cost package deals for patients as well as Doctor Consultation and Scheduling, Doctor Consultancy Fees and Time Allocation.  

·          Doctor visit schedule

·          Doctor Appointment Scheduling

·          Enquiry of Patient

·         Find History of Patient Enquired.

Administration:  

This module handles all the master entry details for the hospital requirement such as consultation detail, doctor specialization, consultancy fee, and service charges.  

Employee 

·         Employee Detail Recording.

·         Doctor Type .

·         Doctor Master

·         Referral Doctor

Pharmacy:

This module deals with all medical items. This module helps in maintaining Item Master, Receipt of Drugs/consumables, issue, handling of material return, generating retail bills, stock maintenance. It also helps in fulfilling the requirements of both IPD and OPD Pharmacy.

Laboratory:

This module enables the maintenance of investigation requests by the patient and generation of test results for the various available services, such as clinical pathology, X-ray and ultrasound tests. Requests can be made from various points, including wards, billing, sample collection and the laboratory receiving point. The laboratory module is integrated with the in-patient/ outpatient registration, wards and billing modules.

Registration:

This module helps in registering information about patients and handling both IPD and OPD patient’s query. A unique ID is generated for each patient after registration. This helps in implementing customer relationship management and also maintains medical history of the patient.  

SOFTWARE REQUIREMENTS : HOSPITAL MANAGEMENT SYSTEM PROJECT

           

            Web Technologies : ASP.NET 2.0

            Language                 : C#

            Database                  : SQL SERVER 2005

            Web Server              : IIS

            Operating System   : WINDOWS XP

INTRODUCTION: HOSPITAL MANAGEMENT SYSTEM PROJECT

Documenting the assembly, maintenance, use, and troubleshooting of a system as complex as a voting system is a difficult task. A single system might combine proprietary hardware, custom operating systems and software, commodity personal computers, and pen and paper. Describing these highly varied components is one function of voting system documentation .But it is not only voting system technology that is heterogeneous; so are voting systems users, and the environments in which the systems are used. Election officials, poll workers, and voters often need guidance from documents in order to administer or use a voting system. In addition, voting system certification—the process by which a system is approved for use in state— demands evidence that a voting system complies with one or more sets of standards or guidelines.

             Documentation provides the details that certification bodies need to evaluate the

System. Taken as a whole, voting system documentation must explain the system in several ways to meet the needs of these multiple audiences.

   

               As the modern organizations are automated and computers are working as per the instructions, it becomes essential for the coordination of human beings, commodity and computers in a modern organization.

             Many big cities where the life is busy needs the transaction of the goods within few minutes of time. So, this online information recorded by the distributor helps him to complete this task within the time.                      

 The administrators and all the others can communicate with the system through this project, thus facilitating effective implementation and monitoring of various activities of the voting Software.

Analysis : HOSPITAL MANAGEMENT SYSTEM PROJECT

 

1. Existing System

Hospitals currently use a manual system for the management and maintenance of critical information. The current system requires numerous paper forms, with data stores spread throughout the hospital management infrastructure. Often information (on forms) is incomplete, or does not follow management standards. Forms are often lost in transit between departments requiring a comprehensive auditing process to ensure that no vital information is lost. Multiple copies of the same information exist in the hospital and may lead to inconsistencies in data in various data stores.

2. Proposed System

The Hospital Management System (HMS) is designed for Any Hospital to replace their existing manual, paper based system. The new system is to control the following information; patient information, room availability, staff and operating room schedules, and patient invoices. These services are to be provided in an efficient, cost effective manner, with the goal of reducing the time and resources currently required for such tasks.

3. Objective of the System

Hospitals currently use a manual system for the management and maintenance of critical information. The current system requires numerous paper forms, with data stores spread throughout the hospital management infrastructure. Often information (on forms) is incomplete, or does not follow management standards. Forms are often lost in transit between departments requiring a comprehensive auditing process to ensure that no vital information is lost. Multiple copies of the same information exist in the hospital and may lead to inconsistencies in data in various data stores.

A significant part of the operation of any hospital involves the acquisition, management and timely retrieval of great volumes of information. This information typically involves; patient personal information and medical history, staff information, room and ward scheduling, staff scheduling, operating theater scheduling and various facilities waiting lists. All of this information must be managed in an efficient and cost wise fashion so that an institution's resources may be effectively utilized HMS will automate the management of the hospital making it more efficient and error free. It aims at standardizing data, consolidating data ensuring data integrity and reducing inconsistencies.

.

System Specifications - HOSPITAL MANAGEMENT SYSTEM PROJECT

Hardware Requirements:-

·         Pentium-IV(Processor).

·         256 MB Ram

·         512 KB Cache Memory

·         Hard disk 10 GB

·         Microsoft Compatible 101 or more Key Board

Software Requirements: -

• Operating System :           Windows XP
• Programming  language:   .NET
• Web-Technology:               ASP.NET 2.0
• Front-End:                          C#.NET
• Back-End:                           Sql Server 2000
• Web Server:                        IIS

 

DESIGN - HOSPITAL MANAGEMENT SYSTEM PROJECT

INTRODUCTION:

                      Design is the first step in the development phase for any techniques and principles for the purpose of defining a device, a process or system in sufficient detail to permit its physical realization.

                      Once the software requirements have been analyzed and specified the software design involves three technical activities - design, coding, implementation and testing that are required to build and verify the software.

                      The design activities are of main importance in this phase, because in this activity, decisions ultimately affecting the success of the software implementation and its ease of maintenance are made. These decisions have the final bearing upon reliability and maintainability of the system. Design is the only way to accurately translate the customer’s requirements into finished software or a system.

                       Design is the place where quality is fostered in development. Software design is a process through which requirements are translated into a representation of software. Software design is conducted in two steps. Preliminary design is concerned with the transformation of requirements into data.

UML Diagrams:

Actor:
A coherent set of roles that users of use cases play when interacting with the use `cases.

Use case:

A description of sequence of actions, including variants, that a system performs that yields an observable result of value of an actor.

UML stands for Unified Modeling Language. UML is a language for specifying, visualizing and documenting the system. This is the step while developing any product after analysis. The goal from this is to produce a model of the entities involved in the project which later need to be built. The representation of the entities that are to be used in the product being developed need to be designed.

There are various kinds of methods in software design:

They are as follows:

Ø  Use case Diagram

Ø  Sequence Diagram

Ø  Collaboration Diagram

Ø  Activity Diagram

Ø  State chat Diagram

USECASE DIAGRAMS:   

                       

Use case diagrams model behavior within a system and helps the developers understand of what the user require. The stick man represents what’s called an actor.

Use case diagram can be useful for getting an overall view of the system and clarifying who can do and more importantly what they can’t do.

Use case diagram consists of use cases and actors and shows the interaction between the use case and actors.

·         The purpose is to show the interactions between the use case and actor.

·         To represent the system requirements from user’s perspective.

·         An actor could be the end-user of the system or an external system.

USECASE DIAGRAM:

A Use case is a   description of  set of  sequence   of actions   Graphically it is rendered as an ellipse  with solid line including only its name.  Use case diagram  is a   behavioral diagram that shows a set of use cases and actors and their relationship.  It is an association between the use cases and actors.  An actor represents a real-world object.

SEQUENCE DIAGRAM:

Sequence diagram and collaboration diagram are called INTERACTION DIAGRAMS. An interaction diagram shows an interaction, consisting of set of objects and their relationship including the  messages that may be dispatched among them.

            A sequence diagram is an introduction that empathizes the time ordering of messages. Graphically a sequence diagram is a table that shows objects arranged along the X-axis and messages ordered in increasing time along the Y-axis

COLLABORATION DIAGRAM:

A collaboration diagram is an introduction diagram that emphasizes the structural organization of the objects that send and receive messages. Graphically a collaboration diagram is a collection of vertices and arcs.

CLASS DIAGRAM:

            Class is nothing but a structure that contains both variables and methods.  The Class Diagram shows a set of classes, interfaces, and collaborations and their relating ships.  There is most common diagram in modeling the object oriented systems and are used to give the static view of a system.  It shows the dependency between the classes that can be used in our system.

The interactions between the modules or classes of our projects are shown below.  Each block contains Class Name, Variables and Methods.

Activity Diagram

DATA FLOW DIAGRAMS: HOSPITAL MANAGEMENT SYSTEM PROJECT

            

 The DFD takes an input-process-output view of a system i.e. data objects flow into the software, are transformed by processing elements, and resultant data objects flow out of the software.

              Data objects represented by labeled arrows and transformation are represented by circles also called as bubbles. DFD is presented in a hierarchical fashion i.e. the first data flow model represents the system as a whole. Subsequent DFD refine the context diagram (level 0 DFD), providing increasing details with each subsequent level. 

             The DFD enables the software engineer to develop models of the information domain & functional domain at the same time. As the DFD is refined into greater levels of details, the analyst perform an implicit functional decomposition of the system. At the same time, the DFD refinement results in a corresponding refinement of the data as it moves through the process that embody the applications.

             A context-level DFD for the system the primary external entities produce information for use by the system and consume information generated by the system. The labeled arrow represents data objects or object hierarchy.

RULES FOR DFD:

·         Fix the scope of the system by means of context diagrams.

·         Organize the DFD so that the main sequence of the actions

·         Reads left to right and top to bottom.

·          Identify all inputs and outputs.

·         Identify and label each process internal to the system with Rounded   circles.

·         A process is required for all the data transformation and Transfers. Therefore, never connect a data store to a data Source or the destinations or another data store with just a Data flow arrow.

·         Do not indicate hardware and ignore control information.

·         Make sure the names of the processes accurately convey everything the process is done.

·         There must not be unnamed process.

·         Indicate external sources and destinations of the data, with  Squares.

·         Number each occurrence of repeated external entities.

·         Identify all data flows for each process step, except simple Record retrievals.

·         Label data flow on each arrow.

·         Use details flow on each arrow.

·         Use the details flow arrow to indicate data movements.

E-R Diagrams: HOSPITAL MANAGEMENT SYSTEM PROJECT

    The Entity-Relationship (ER) model was originally proposed by Peter in 1976 [Chen76] as a way to unify the network and relational database views. Simply stated the ER model is a conceptual data model that views the real world as entities and relationships. A basic component of the model is the Entity-Relationship diagram which is used to visually represents data objects. Since Chen wrote his paper the model has been extended and today it is commonly used for database design For the database designer, the utility of the ER model is:

• it maps well to the relational model. The constructs used in the ER model can easily be transformed into relational tables.
• it is simple and easy to understand with a minimum of training. Therefore, the model can be used by the database designer to communicate the design to the end user.
• In addition, the model can be used as a design plan by the database developer to implement a data model in a specific database management software.

Connectivity and Cardinality

                      The basic types of connectivity for relations are: one-to-one, one-to-many, and many-to-many. A one-to-one (1:1) relationship is when at most one instance of a entity A is associated with one instance of entity B. For example, "employees in the company are each assigned their own office. For each employee there exists a unique office and for each office there exists a unique employee.

A one-to-many (1:N) relationships is when for one instance of entity A, there are zero, one, or many instances of entity B, but for one instance of entity B, there is only one instance of entity A. An example of a 1:N relationships is

a department has many employees

each employee is assigned to one department

A many-to-many (M:N) relationship, sometimes called non-specific, is when for one instance of entity A, there are zero, one, or many instances of entity B and for one instance of entity B there are zero, one, or many instances of entity A. The connectivity of a relationship describes the mapping of associated

ER Notation

           There is no standard for representing data objects in ER diagrams. Each modeling methodology uses its own notation. The original notation used by Chen is widely used in academics texts and journals but rarely seen in either CASE tools or publications by non-academics. Today, there are a number of notations used, among the more common are Bachman, crow's foot, and IDEFIX.

        All notational styles represent entities as rectangular boxes and relationships as lines connecting boxes. Each style uses a special set of symbols to represent the cardinality of a connection. The notation used in this document is from Martin. The symbols used for the basic ER constructs are:

• entities are represented by labeled rectangles. The label is the name of the entity. Entity names should be singular nouns.
• relationships are represented by a solid line connecting two entities. The name of the relationship is written above the line. Relationship names should be verbs
• attributes, when included, are listed inside the entity rectangle. Attributes which are identifiers are underlined. Attribute names should be singular nouns.
• cardinality of many is represented by a line ending in a crow's foot. If the crow's foot is omitted, the cardinality is one.
• existence is represented by placing a circle or a perpendicular bar on the line. Mandatory existence is shown by the bar (looks like a 1) next to the entity for an instance is required. Optional existence is shown by placing a circle next to the entity that is optional

PROJECT MODULES - HOSPITAL MANAGEMENT SYSTEM PROJECT

Ø  Reception

Ø  Administration

Ø  Pharmacy

Ø  Laboratory

Ø  Registration

Ø  Discharge Summary

MODULE DESCRIPTION

Name of the module-1: Reception

Description: The reception module handles various enquiries about the patient's admission and discharge details, bed census, and the patient's movements within the hospital. The system can also handle fixed-cost package deals for patients as well as Doctor Consultation and Scheduling, Doctor Consultancy Fees and Time Allocation

 Sub modules:

·          Doctor visit schedule

·          Doctor Appointment Scheduling

·          Enquiry of Patient

·         Find History of Patient Enquired.

Name of the module-2: Administration

Description: This module handles all the master entry details for the hospital requirement such as consultation detail, doctor specialization, consultancy fee, and service charges.  

Employee 

Sub modules:

·         Employee Detail Recording.

·         Doctor Type .

·         Doctor Master

·         Referral Doctor

Name of the module-3: Pharmacy

Description: This module deals with all medical items. This module helps in maintaining Item Master, Receipt of Drugs/consumables, issue, handling of material return, generating retail bills, stock maintenance. It also helps in fulfilling the requirements of both IPD and OPD Pharmacy.

Name of the module-4: Laboratory.

Description: This module enables the maintenance of investigation requests by the patient and generation of test results for the various available services, such as clinical pathology, X-ray and ultrasound tests. Requests can be made from various points, including wards, billing, sample collection and the laboratory receiving point. The laboratory module is integrated with the in-patient/ outpatient registration, wards and billing modules.

Name of the module-5: Registration.

Description: This module helps in registering information about patients and handling both IPD and OPD patient’s query. A unique ID is generated for each patient after registration. This helps in implementing customer relationship management and also maintains medical history of the patient.

Name of the module-6: Discharge Summary.

Description: The module helps in generating patient’s discharge summary, which includes patient’s health at the time of discharge, medical history, various diagnosis and drug prescriptions, history of present illness and course in hospital. 

DATABASE TABLES: HOSPITAL MANAGEMENT SYSTEM PROJECT

Doctor Registration

Name	NULL / NOTNULL	TYPE	KEY
Name	Null	Varchar (20)
Loginid	Null	Varchar(20)
password	Null	Varchar(20)
Department	Null	Varchar(20)
Specialization	Null	Varchar(20)
Phonenumber	Null	Bigint
Address	Null	Varchar(20)
Email	Null	Varchar(20)

Employee Registration

Name	NULL / NOTNULL	TYPE	KEY
Name	Null	Varchar (20)
Loginid	Null	Varchar(20)
password	Null	Varchar(20)
Department	Null	Varchar(20)
Phonenumber	Null	Bigint
Address	Null	Varchar(20)
Email	Null	Varchar(20)

Inpatient Registration

Name	NULL / NOTNULL	TYPE	KEY
Patientname	Null	Varchar (20)
Patientid	Not Null	Varchar(20)	Primary
Gender	Null	Varchar(20)
Age	Null	Int
Phoneres	Null	Bigint
Phonemob	Null	Bigint
Maritual	Null	Varchar(20)
Occupation	Null	Varchar(20)
Admid	Null	Int
Admdate	Null	Datetime
Admtime	Null	Datetime
Status	Null	Varchar(20)
Symptoms	Null	Varchar(20)
Department	Null	Varchar(20)
Wardno	Null	Int
Bedno	Null	Int
Doctor	Null	Varchar(20)

Out Patient Registration

Name	NULL / NOTNULL	TYPE	KEY
Patientname	Null	Varchar (20)
Patientid	Not Null	Varchar(20)	Primary
Gender	Null	Varchar(20)
Age	Null	Int
Address	Null	Varchar(20)
Assigndoctor	Null	Varchar(20)
Phoneres	Null	Bigint
Phonemob	Null	Bigint
Opdate	Null	Datetime
Department	Null	Varchar(20)

For Patient Information

Name	NULL / NOTNULL	TYPE	KEY
pid	Not null	Varchar(20)	Foreign
Patientname	Null	Varchar(20)
Age	Null	Int
Department	Null	Varchar(20)
Doctor	Null	Varchar(20)

For Surgery Information

Name	NULL / NOTNULL	TYPE	KEY
pid	Not null	Varchar(20)	Foreign
Patientname	Null	Varchar(20)
Age	Null	Int
Department	Null	Varchar(20)
Doctor	Null	Varchar(20)
Surgerydate	Null	Datetime

For Blood test

Name	NULL / NOTNULL	TYPE	KEY
Patienttype	Null	Varchar(20)
Patientid	Null	Varchar(20)
Patientname	Null	Varchar(20)
Mediclatestype	Null	Varchar(20)
Bloodgroup	Null	Varchar(20)
Haemoglobin	Null	Varchar(20)
Bloodsugar	Null	Varchar(20)
Sacid	Null	Varchar(20)
Description	Null	Varchar(20)

For Urine test

Name	NULL / NOTNULL	TYPE	KEY
Patienttype	Null	Varchar(20)
Patientid	Null	Varchar(20)
Patientname	Null	Varchar(20)
Mediclatestype	Null	Varchar(20)
Color	Null	Varchar(20)
Clarity	Null	Varchar(20)
Odor	Null	Varchar(20)
Specificgravity	Null	Varchar(20)
Glucose	Null	Varchar(20)
Description	Null	Varchar(20)

For Operation

Name	NULL / NOTNULL	TYPE	KEY
Patienttype	Null	Varchar(20)
Patientid	Null	Varchar(20)
Patientname	Null	Varchar(20)
Refdoctor	Null	Varchar(20)
Operationtype	Null	Varchar(20)
Operatonresult	Null	Datetime

For Pharmacy Information

Name	NULL / NOTNULL	TYPE	KEY
Patienttype	Null	Varchar(20)
Patientid	Null	Varchar(20)
Department	Null	Varchar(20)
Patientname	Null	Varchar(20)
Medicine	Null	Varchar(20)

For Discharge Summary

Name	NULL / NOTNULL	TYPE	KEY
Patientid	Null	Varchar(20)
Patientname	Null	Varchar(20)
Joiondate	Null	Datetime
Dischargedate	Null	Datetime

FEASIBILITY STUDY: HOSPITAL MANAGEMENT SYSTEM PROJECT

                          Feasibility study is conducted once the problem is clearly understood.  Feasibility study is a high level capsule version of the entire system analysis and design process.  The objective is to determine quickly at a minimum expense how to solve a problem.  The purpose of feasibility is not to solve the problem but to determine if the problem is worth solving.

            The system has been tested for feasibility in the following points.

               1. Technical Feasibility

               2. Economical Feasibility

               3. Operational Feasibility.

1. Technical Feasibility

                 The project entitles "Courier Service System” is technically feasibility because of the below mentioned feature.  The project was developed in Java which Graphical User Interface.

           It provides the high level of reliability, availability and compatibility.  All these make Java an appropriate language for this project.  Thus the existing software Java is a powerful language.

2. Economical Feasibility

               The computerized system will help in automate the selection leading the profits and details of the organization.  With this software, the machine and manpower utilization are expected to go up by 80-90% approximately.  The costs incurred of not creating the system are set to be great, because precious time can be wanted by manually.

3. Operational Feasibility

               In this project, the management will know the details of each project where he may be presented and the data will be maintained as decentralized and if any inquires for that particular contract can be known as per their requirements and necessaries.

Implementation:

       Implementation is the stage where the theoretical design is turned into a working system. The most crucial stage in achieving a new successful system and in giving confidence on the new system for the users that it will work efficiently and effectively.

      The system can be implemented only after thorough testing is done and if it is found to work according to the specification.

         It involves careful planning, investigation of the current system and its constraints on implementation, design of methods to achieve the change over and an evaluation of change over methods a part from planning. Two major tasks of preparing the implementation are education and training of the users and testing of the system.

          The more complex the system being implemented, the more involved will be the systems analysis and design effort required just for implementation.

              

       The implementation phase comprises of several activities. The required hardware and software acquisition is carried out. The system may require some software to be developed. For this, programs are written and tested. The user then changes over to his new fully tested system and the old system is discontinued.

TESTING: HOSPITAL MANAGEMENT SYSTEM PROJECT

 

            The testing phase is an important part of software development. It is the puterized system will help in automate  process of finding errors and missing operations and also a complete verification to determine whether the objectives are met and the user requirements are satisfied.

Software testing is carried out in three steps:

  

            1.     The first includes unit testing, where in each module is tested to provide its correctness, validity and also determine any missing operations and to verify whether the objectives have been met. Errors are noted down and corrected immediately. Unit testing is the important and major part of the project. So errors are rectified easily in particular module and program clarity is increased. In this project entire system is divided into several modules and is developed individually.  So unit testing is conducted to individual modules.

              2.        The second step includes Integration testing. It need not be the case, the software whose modules when run individually and showing perfect results, will also show perfect results when run as a whole. The individual modules are clipped under this major module and tested again and verified the results. This is due to poor interfacing, which may results in data being lost across an interface. A module can have inadvertent, adverse effect on any other or on the global data structures, causing serious problems.

                                   

               3.        The final step involves validation and testing which determines which the software functions as the user expected. Here also some modifications were. In the completion of the project it is satisfied fully by the end user.

 Maintenance and environment: HOSPITAL MANAGEMENT SYSTEM PROJECT

                    AS the number of computer based systems, grieve libraries of computer software began to expand. In house developed projects produced tones of thousand soft program source statements. Software products purchased from the outside added hundreds of thousands of new statements. A dark cloud appeared on the horizon. All of these programs, all of those source statements-had to be corrected when false were detected, modified as user requirements changed, or adapted to new hardware that was purchased. These activities were collectively called software Maintenance.

    The maintenance phase focuses on change that is associated with error correction, adaptations required as the software's environment evolves, and changes due to enhancements brought about by changing customer requirements. Four types of changes are encountered during the maintenance phase.

Ø  Correction

Ø  Adaptation

Ø  Enhancement

Ø  Prevention

Correction:

         Even with the best quality assurance activities is lightly that the customer will uncover defects in the software. Corrective maintenance changes the software to correct defects.

       Maintenance is a set of software Engineering activities that occur after software has been delivered to the customer and put into operation. Software configuration management is a set of tracking and control activities that began when a software project begins and terminates only when the software is taken out of the operation.

    We may define maintenance by describing four activities that are undertaken after a program is released for use:

 

Corrective Maintenance

Adaptive Maintenance

Perfective Maintenance or Enhancement

Preventive Maintenance or reengineering

Only about 20 percent of all maintenance work are spent "fixing mistakes". The remaining 80 percent are spent adapting existing systems to changes in their external environment, making enhancements requested by users, and reengineering an application for use.

  ADAPTATION:

                 Over time, the original environment (E>G., CPU, operating system, business rules, external product characteristics) for which the software was developed is likely to change. Adaptive maintenance results in modification to the software to accommodate change to its external environment.

ENHANCEMENT:

      As software is used, the customer/user will recognize additional functions that will provide benefit. Perceptive maintenance extends the software beyond its original function requirements.

PREVENTION :

         Computer software deteriorates due to change, and because of this, preventive maintenance, often called software re engineering, must be conducted to enable the software to serve the needs of its end users. In essence, preventive maintenance makes changes to computer programs so that they can be more easily corrected, adapted, and enhanced.  Software configuration management (SCM) is an umbrella activity that is applied throughout the software process. SCM activities are developed to    

SOFTWARE METHODOLOGY - HOSPITAL MANAGEMENT SYSTEM PROJECT

The software methodology followed in this project includes the object-oriented methodology and the application system development methodologies. The description of these methodologies is given below.

      Application System Development – A Life cycle  Approach  

Although there are a growing number of applications (such as decision support systems) that should be developed using an experimental process strategy such as prototyping, a significant amount of new development work continue to involve major operational applications of broad scope. The application systems are large highly structured. User task comprehension and developer task proficiency is usually high. These factors suggest a linear or iterative assurance strategy. The most common method for this stage class of problems is a system development life cycle modal in which each stage of development is well defined and has straightforward requirements for deliverables, feedback and sign off. The system development life cycle is described in detail since it continues to be an appropriate methodology for a significant part of new development work.

         The basic idea of the system development life cycle is that there is a well-defined process by which an application is conceived and developed and implemented. The life cycle gives structure to a creative process. In order to manage and control the development effort, it is necessary to know what should have been done, what has been done, and what has yet to be accomplished. The phrases in the system development life cycle provide a basis for management and control because they define segments of the

flow of work, which can be identified for managerial purposes and specifies the documents or other deliverables to be produced in each phase.

         The phases in the life cycle for information system development are described differently by different writers, but the differences are primarily in the amount of necessity and manner of categorization. There is a general agreement on the flow of development steps and the necessity for control procedures at each stage.

The information system development cycle for an application consists of three major stages.

1)      Definition.

2)      Development

3)      Installation and operation

       

The first stage of the process, which defines the information requirements for a feasible cost effective system. The requirements are then translated into a physical system of forms, procedures, programs etc., by the system design, computer programming and procedure development. The resulting system is test and put into operation. No system is perfect so there is always a need for maintenance changes. To complete the cycle, there should be a post audit of the system to evaluate how well it performs and how well it meets the cost and performance specifications. The stages of definition, development and installation and operation can therefore be divided into smaller steps or phrases as follows.

Definition

Proposed definition        : preparation of request for proposed applications.

Feasibility assessment :  evaluation of feasibility and cost benefit of proposed system.

Information requirement analysis : determination of information needed.

Design

Conceptual design           :  User-oriented design of application development.

Physical system design  :  Detailed design of flows and processes in applications processing system and preparation of program specification.

Development 

Program development      :  coding and testing of computer programs.

Procedure development    : design of procedures and preparation of user instructions.

Installation and operation

Conversion                            :     final system test and conversion.

Operation and maintenance  :     Month to month operation and maintenance

Post audit                       :     Evaluation of development process,application system and results of use at the completion of the each phase, formal approval sign-off is required from the users as well as from the manager of the project development.

Testing: HOSPITAL MANAGEMENT SYSTEM PROJECT

                       Testing is a process of executing a program with the indent of finding an error. Testing is a crucial element of software quality assurance and presents ultimate review of specification, design and coding.

System Testing is an important phase. Testing represents an interesting anomaly for the software.  Thus a series of testing are performed for the proposed system before the system is ready for user acceptance testing.

A good test case is one that has a high probability of finding an as undiscovered error. A successful test is one that uncovers an as undiscovered error.

Testing Objectives:

1.      Testing is a process of executing a program with the intent of finding an error

2.      A good test case is one that has a probability of finding an as yet undiscovered error

3.      A successful test is one that uncovers an undiscovered error

Testing Principles:

Ø  All tests should be traceable to end user requirements

Ø  Tests should be planned long before testing begins

Ø  Testing should begin on a small scale and progress towards testing in large

Ø  Exhaustive testing is not possible

Ø  To be most effective testing should be conducted by a independent third party

        The primary objective for test case design is to derive a set of tests that has the highest livelihood for uncovering defects in software. To accomplish this objective two different categories of test case design techniques are used. They are

§  White box testing.

§  Black box testing.

White-box testing:

White box testing focus on the program control structure. Test cases are derived to ensure that all statements in the program have been executed at least once during testing and that all logical conditions have been executed.

Block-box testing:

Black box testing is designed to validate functional requirements without regard to the internal workings of a program. Black box testing mainly focuses on the information domain of the software, deriving test cases by partitioning input and output in a manner that provides through test coverage. Incorrect and missing functions, interface errors, errors in data structures, error in functional logic are the errors falling in this category.

Testing strategies:

A strategy for software testing must accommodate low-level tests that are necessary to verify that all small source code segment has been correctly implemented as well as high-level tests that validate major system functions against customer requirements.

Testing fundamentals:

Testing is a process of executing program with the intent of finding error. A good test case is one that has high probability of finding an undiscovered error. If testing is conducted successfully it uncovers the errors in the software. Testing cannot show the absence of defects, it can only show that software defects present.

Testing Information flow:

Information flow for testing flows the pattern. Two class of input provided to test the process. The software configuration includes a software requirements specification, a design specification and source code.

Test configuration includes test plan and test cases and test tools. Tests are conducted and all the results are evaluated. That is test results are compared with expected results. When erroneous data are uncovered, an error is implied and debugging commences.

Unit testing:

Unit testing is essential for the verification of the code produced during the coding phase and hence the goal is to test the internal logic of the modules.  Using the detailed design description as a guide, important paths are tested to uncover errors with in the boundary of the modules.  These tests were carried out during the programming stage itself. All units of Vienna SQL were successfully tested.

Integration testing:

Integration testing focuses on unit tested modules and build the program structure that is dictated by the design phase.

System testing:

System testing tests the integration of each module in the system. It also tests to find discrepancies between the system and it’s original objective, current specification and system documentation. The primary concern is the compatibility of individual modules. Entire system is working properly or not will be tested here, and specified path ODBC connection will correct or not, and giving output or not are tested here these verifications and validations are done by giving input values to the system and by comparing with  expected output. Top-down testing implementing here.

Acceptance Testing:

              This testing is done to verify the readiness of the system for the implementation. Acceptance testing begins when the system is complete. Its purpose is to provide the end user with the confidence that the system is ready for use. It involves planning and execution of functional tests, performance tests and stress tests in order to demonstrate that the implemented system satisfies its requirements.

Tools to special importance during acceptance testing include:

Test coverage Analyzer – records the control paths followed for each test case.

Timing Analyzer – also called a profiler, reports the time spent in various regions of the code are areas to concentrate on to improve system performance.

Coding standards – static analyzers and standard checkers are used to inspect code for deviations from standards and guidelines.

Test Cases:

Test cases are derived to ensure that all statements in the program have been executed at least once during testing and that all logical conditions have been executed.

Using White-Box testing methods, the software engineer can drive test cases that

·         Guarantee that logical decisions on their true and false sides.

·         Exercise all logical decisions on their true and false sides.

·         Execute all loops at their boundaries and with in their operational bounds.

·         Exercise internal data structure to assure their validity.

The test case specification for system testing has to be submitted for review before system testing commences.

CONCLUSION: HOSPITAL MANAGEMENT SYSTEM PROJECT

The package was designed in such a way that future modifications can be done easily. The following conclusion can be deduced from the development of the project.

Ø  Automation of the entire system improves the efficiency

Ø  It provides a friendly graphical user interface which proves to be better when compared to the existing system.

Ø  It gives appropriate access to the authorized users depending on their permissions.

Ø  It effectively overcomes the delay in communications.

Ø  Updating of information becomes so easier.

Ø  System security, data security and reliability are the striking features.

Ø  The System has adequate scope for modification in future if it is necessary.

FUTURE ENHANCEMENTS: HOSPITAL MANAGEMENT SYSTEM PROJECT

 This application avoids the manual work and the problems concern with it. It is an easy way to obtain the information regarding the various travel services that are present in our System.

                       Well I and my team member have worked hard in order to present an improved website better than the existing one’s regarding the information about the various activities. Still, we found out that the project can be done in a better way. Primarily, In this system patient login and then go to reception. By using this patient will send request for consulting the doctor. Reception will set the date for doctor appointments. After that doctor see his appointments and see the patients, surgeries also done.

                       The next enhancement is, we will develop online services. That mean, if patient have any problems he can send his problem to the doctor through internet from his home then doctor will send reply to him. In this patients have some login name and password.                               

BIBLIOGRAPHY

The following books were referred during the analysis and execution phase of the project



MICROSOFT .NET WITH C#

Microsoft .net series



ASP .NET 2.0 PROFESSIONAL

Wrox Publishers



ASP .NET WITH C# 2005

Apress Publications



C# COOK BOOK

O reilly Publications



PROGRAMMING MICROSOFT ASP .NET 2.0 APPLICATION

Wrox Professional Guide





BEGINNING ASP .NET 2.0 E-COMMERCE IN C# 2005

Novice to Professional.

WEBSITES:

             www.google.com

               www.microsoft.com