DOCTORS SRS MODIFIED (Repaired)12.docx

8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx

1/64


2/64

DOCTORS APPOINTMENT MANAGEMENT SYSTEM 2

DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION

1.1.1. PURPOSE

The system should respond to the requests of doctors, their helping staff and patient. This

system enables doctors secretaries or themselves to give appointments to patients

according to doctorsavailability status. The system provides placing a new appointment,

modifying and deleting an existing appointment & showing weekly schedule.

This system should facilitate adding & deleting and updating schedule seamlessly.

Moreover, it should be user-friendly and understandable.

The aim of the project is to prepare a management system, which arranges the most

appropriate time for patients, their doctors ratings, recommendations. The system should

have a high usability level with its user-friendly interface (a professional graphics design

firm will be contracted to do this), simplicity in usage and success in practice.

1.1.2 SCOPE

The scope of the project can be summarized as follows:

To prevent getting lost of appointment and patients information.

To prepare suitable weekly schedule for the doctors.

To present a good user interface for creating, deferring, cancelling, editing, and

updating the appointment schedule.

To cut costs associated with appointment placements.

To report concisely the doctor-patient relationship by keeping every tiny detail

of every appointment that takes (will take) place between them.

To provide reporting for doctors and system administrators.

1.1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

SRS - Software Requirements Specification

Patient- A person to be treated by a doctor

DoctorA medical practitioner

SecretaryA medical practitioners assistant


3/64



AdministratorA person who manages the system, billing doctors etc.

Web 2.0An approach to web application development that focuses on the

interactivity of the system with the user. AJAX technology is severely

employed here.

MySQL The most advanced open database that will be used to

persistently store all the system data.

JAVAThe high-level, object-oriented programming language that is used

in the coding the software

JEE or Java EE is Oracle enterprise Java computing platform. The

platform provides an API and runtime environment for developing

software, including network and web services, and others large-scale, muti-

tiered, scalable, reliable and secure web applications.

STRIPES a presentation framework for building web applications using

the latest Java technologies.

jQueryjQuery is a fast, small, and feature-rich JavaScript library

Java Server Page (JSP)is a technology that helps software developers to

generate web pages based on HTML, XML or other document types.

Apache Tomcat an open source software implementation of the Java

Servlet and Java Server Pages technologies.

Apache web serverThe most popular web server (HTTP server).


4/64



1.1.4. REFERENCES

1. IEEE Recommended Practice for Software Requirements Specification-

IEEE STD 830-1993.

2. Software Engineering by - Roger S Pressmen publisher: McGraw-Hill: 7th

edition 2009

3. Software Engineering byIan Summerville publisher: AddisonWesley 7th

edition 2007

1.1.5. OVERVIEW

This document is intended for providing an abstract overview of doctors

appointment management system and a general overview of the entire project. The rest of

the document will provide detail instruction about: the Functional and Non-Functional

Requirements, Stake Holders, Team Architecture, System Functional and Non-Functional

Requirements. The software requirements specification is divided into sections: this

introduction, and the specific requirements of the project. The general description is an

overview of the projects requirements, including a product perspective, functional and

data requirements, constraints, assumptions, dependencies, and guidelines. The specific

requirements section is a more detailed look at the projects requirements, including the

functional requirements.

The application can be accessed by three kinds of users: the patient, the doctor's assistants,

the doctor himself and the administrator.


5/64



1.2. THE OVERALL DESCRIPTION

The doctor's management appointments management system provides an efficient way to

management all the appointments between the doctor and the different patients that he or

she follows. It provides a centralized and organized platform for the doctor and his or her

assistant to assist the patient during the treatment and all the interactions between them.

Each doctor will maintain a profile, the patient will decide to request an appointment, and

then according to the schedule of the doctor the appointment will be granted. All the

informationswill be saved into a database, the system will provide facility to generate

bills and reports.

1.2.1. PRODUCT PRESPECTIVE

The application is developed by using Java and JEE( Java enterprise environment). The

Stripes framework which is an action based framework will be used on the server side then

HTML/CSS and jQuery for the front end. The application will be accessible via the

Internet. Web browsers that can be used include Internet Explorer and NetscapeNavigator.

1.2.1.1. SYSTEM INTERFACES

The web interface is the main system interface, used for accessing the web

application.

1.2.1.2. INTERFACES

This project is a web application that can be developed in Eclipse IDE and having MySQL

as back end.

Input Design (JAVA)

Coding (Eclipse)

Database Design(MySQL)


6/64



1.2.1.3.HARDWARE INTERFACES

Processor : Pentium IV

Memory : 512MB RAM

Hard disk : 40 GB and above

Mouse : Optical mouse

Monitor : 15 color

Key board : 102 keys

1.2.1.4. SOFTWARE INTERFACS

Any windows based operating system.

MySQL as the DBMS-for database

IDE (Eclipse) for developing code.

Apache web server

Tomcat container

1.2.1.5 . COMMUNICATION INTERFACES

The system will use the standard TCP/IP protocol and HTTP for communications between

interfaces.

1.2.1.6. MEMORY CONSTARINTS

All the software are installed if the memory of the server having more than the particular

software .

The database information and backup will stored in the server ,whenever needs means

access and use it.


7/64



1.2.2. PRODUCT FUNCTIONS

Our programs functions;

The system allows secretary to see appointment information of the patients.

The system allows secretary to give, cancel or update appointment.

The system allows doctors to see their patients appointments and see their weekly

schedule.

The system allows doctors to determine the status of the treatment and can take

notes about the treatment.

The system allows patients to search and view doctors profiles.

1.2.3. USER CHARACTERISTICS

All the users with a valid password and username will be granted the access to the

system. There will four types of users: the patient, the doctor and assistant, finally the

administrator.

1.2.4. CONSTARINTS

The product is a web-based application, so a most recent internet browser is needed

(Internet Explorer 6/7, Firefox 2.0, Safari, Opera 8+).

Hardware limitations

Server hardware is unspecified as long as it meets the software requirements (JEE and

MySQL)

Interfaces to other applications

TCP/IP interface to MySQL, port 3306.

Safety and security considerations: HTTPS for the login form.


8/64



An extra security as SSL must be used to secure the username and password details and

other examination information.

1.3. SPEIFIC REQUIREMENTS

This section provides software requirements to a level of detail sufficient to enable

designers to design the system and testers to test the system.

1.3.1. EXTERNAL INTERFACES

Therequirements work productproduced during system or application development that

formally specifies the interfaces to all external systems and applications

1.3.2. USER INTERFACES

The doctor appointment management system shall be a web-enabled application

compatible with all major web browsers like Internet Explorer, Netscape Navigator,

Mozilla FireFox, etc.

1.3.3. HARDWARE INTERFACES

The target audience of this product shall be using an Apple, Windows PC or a computer

running Linux with X windows. There is no special hardware that is required. The web

browser will be the interface between the hardware and software.

1.3.4. SOFTWARE INTERFACES

It requires Java + Java web container(Tomcat) , MySQL and Apache web server.

1.3.5. COMMUNICATION INTERFACES

HTTP/HTTPS will be used to communicate between the Doctor's appointment

management system website and the users web browser. The interface used to

communicate between the backend application and database will be SQL. Custom

TCP/TLS based protocols will be used to communicate between servers.
http://www.opfro.org/Components/WorkProducts/RequirementsSet/RequirementsSet.htmlhttp://www.opfro.org/Components/WorkProducts/RequirementsSet/RequirementsSet.html


9/64



1.3.6. FUNCTIONAL REQUIREMENTS

Patient To-Do list management

Patient registers with the system.

Patient logs into the system.

Patient searches for the nearest doctor.

Patient places a doctors appointment

Patient updates an appointment

Patient checks their upcoming appointments

Patient rates doctors

Patient logs out from the system

Assistant To-Do list management

Assistant logs into the system

Assistant registers a patient

Assistant places an appointment for the patient

Assistant updates an appointment

Assistant checks all the appointments in the system

Assistant logs out from the system

Doctor To-Do List

Doctor registers with the system.

Doctor updates his profile.

Doctor checks his/her appointment schedule.

Doctor writes notes/comments about the patients treatment.

Doctor registers their assistant with the system.


10/64



Administrator To-Do List

Administrator does the general upkeep of the system.

Administrator draws reports from the system.

Administrator activates or deactivates doctors orpatients accounts.

1.3.7. PERFORMANCE REQUIREMENTS

The Doctor's appointments management system can be applied to any community of

doctors and their patients. The performance of the system will be appropriate for medical

practitioners, which requires a high speed of interaction, and so all tasks will be carried out

within a few clicks and seconds. The scalability requirements of the system are anotherimportant issue as well as the performance requirements. The scheduled appointment

management system will have ability to provide all involved participants with efficient

support, which will not be broken down.

1.3.8. LOGICAL DATABASE REQUIREMENTS

The types of information used by various functions shall be mostly strings,

Dates and integer values.

1.3.9. DESIGN CONSTRAINTS

Input design

Input design is a part of overall system design. The main objective during the input

design is as given below:

To produce a cost-effective method of input.

To achieve the highest possible level of accuracy.

To ensure that the input is acceptable and understood by the user.

Input type

It is necessary to determine the various types of inputs. Inputs can be categorized as

follows:

External inputs, which are prime inputs for the system.

Internal inputs, which are user communications with the system.


11/64



Operational, which are computer departments communications to the system?

Interactive, which are inputs entered during a dialogue.

Input media

At this stage choice has to be made about the input media. To conclude about the

input media consideration has to be given to;

Type of input

Flexibility of format

Speed

Accuracy

Verification methods

Rejection rates

Ease of correction

Storage and handling requirements

Security

Easy to use

Portability

Keeping in view the above description of the input types and input media, it can be

said that most of the inputs are of the form of internal and interactive. As

Input data is to be the directly keyed in by the user, the keyboard can be considered to be

the most suitable input device.

Output design

Outputs from computer systems are required primarily to communicate the results

of processing to users. They are also used to provides a permanent copy of the results for

later consultation. The various types of outputs in general are:

External Outputs, whose destination is outside the organization.

Internal Outputs whose destination is within organization and they are the

Users main interface with the computer.

Operational outputs whose use is purely within the computer department.

Interface outputs, which involve the user in communicating directly.


12/64



1.3.10. SOFTWARE SYSTEM ATTRIBUTES

There are a number of attributes of software that can serve as requirements. It is

important that required attributes by specified so that their achievement can be objectively

verified. The following items provide a partial list of examples. These are also known as

non-functional requirements or quality attributes.

1.3.10.1. USABILITY

The system provides medical practitioners to have appointments well scheduled. The only

requirement is to have computers with Internet connection. The program provides doctors

to see their weekly appointments while they are not at their offices. Accessibility of the

information and usability of the program is easy. With few clicks the user can reach the

destination information.

1.3.10.2. RELIABILITY AND AVAILABILITY

Any reliability problem will not take place throughout the lifecycle of the software system.

Every data can be accessed and seen just after data entrance. The system will provide at

least 99% uptime on Web hosting sites. Reliability factors will be supplied through:

Success track record.

Physical server security.

Disaster recovery plan

1.3.10.3. SECURITY

Since we use Java, STRIPES and JSP, all the security precaution that Java and

A STRIPE framework provides is our security policy. Apart from it, the login system will

protect the information in the system from outside users. All user types such as secretary,

doctors and head doctor have distinct pages to which only they can access. The password

safety will be provided by the encryption of the passwords saved in the database.

Addition to all; JEE (Java enterprise environment) Procedures will be provided.


13/64



1.3.10.4. MAINTAINABILITY

Making changes in the system will not be that much difficult. By having some knowledge

of programming, some features of the system might be converted to a new version.

According to the needs of upgrade, system requirements might change such as change in

hardware or operating system or not.

1.3.10.5. PORTABILITY

The scheduled appointment management system is a web based system and can be run onevery computer with an Internet access. The system will can be installed for any operating

system e.g. Microsoft Windows XP/Vista/7, or Linux. The system will be easily accessible

to all practitioners and their patients.

1.4. CHANGE MANAGEMENT PROCESS

Once software is created as per its customer requirement it needs to be maintained

by time to time. Documentation should be maintained for the project to know what the

previous person has done with the project. The project can also be future enhanced for the

purpose of betterment of the entire system

1.5. DOCUMENT APPROVALS

Document help is provided for each of the feature available with doctor's appointment

management system. All the applications provide to help system to assist the user. The

nature of these systems is unique to application development as they combine aspects of

programming (hyperlinks, etc) with aspects of technical writing (organization,

presentation). This help is provided for each and every feature provided by the system .The

User Manual describes the use of the system to Administration and others. An installation

document will be provided that includes the installation instructions and configuration


14/64



guidelines, which is important to a full solution offering. Also, a Read Me file is typically

included as a standard component.

1.6. SUPPORTING INFORMATION

.

1. Structural models.

2. Use case diagrams.

3. Behavioural models.

4. Non-functional requirements model.

5. Feasibility.

6. Project Plan.


15/64



2.FEASIBILITY STUDY

Preliminary investigation examine project feasibility, the likelihood the system will be

useful to the organization. The main objective of the feasibility study is to test the

Technical, Operational and Economical feasibility for adding new modules and debugging

old running system. All system is feasible if they are unlimited resources and infinite time.

There are aspects in the feasibility study portion of the preliminary investigation:

Technical Feasibility

Operational Feasibility

Economical Feasibility

2.1. TECHNICAL FEASIBILITY

The technical issue usually raised during the feasibility stage of the investigation

includes the following:

Earlier no system existed to cater to the needs of Secure Infrastructure

Implementation System. The current system developed is technically feasible. It is a web

based user interface for audit workflow at NIC-CSD. Thus it provides an easy access to the

users. The databases purpose is to create, establish and maintain a workflow among

various entities in order to facilitate all concerned users in their various capacities or roles.

Permission to the users would be granted based on the roles specified. Therefore, it

provides the technical guarantee of accuracy, reliability and security. The software and

hard requirements for the development of this project are not many and are already

available in-house at NIC or are available as free as open source. The work for the project

is done with the current equipment and existing software technology. Necessary bandwidth

exists for providing a fast feedback to the users irrespective of the number of users using

the system.

This system can be made in any Language that support good user interface and easy

database handling.

Technical needs may include:


16/64



Front-End Selection

Front-End means a language that is usedFor user interface designing and coding. Front-

End should have following Qualities.

It must have a graphical user interface that assist employees that are not from some

IT background.

Scalability and Extensibility

Robustness

According to the organization requirements and culture.

Must provide excellent reporting features with good printing support.

Platform independent.

Easy to deploy and maintain.

Event driven programming.

Front-End must support some popular Back-End like MS Access, SQL

Back-End Selection

Back-End means a language that is usedFor database management. Back-End should have

following qualities:

Multiple user support.

Provide inherent feature for security.

Efficient data retrieval and maintenance.

Stored procedures.

Popularity.

Operating System compatible.

Easy to install.


17/64



Various drivers must be available.

Efficient data handling.

Easy to implement with Front-End

2.2. OPERATIONAL FEASIBILITY

Proposed projects are beneficial only if they can be turned out into information

system. That will meet the organizations operating requirements. Operational feasibility

aspects of the project are to be taken as an important part of the project implementation.

Some of the important test the operational feasibility of a project includes the following: -

This system is sufficient support for the management from the users.

Before hand, the management issues and user requirements have been taken into

consideration.

there is no question of resistance from the users that can undermine the possible

application benefits.

The well-planned design would ensure the optimal utilization of the computer resources

and would help in the improvement of performance status.

2.3. ECONOMICAL FEASIBILITY

A system can be developed technically and that will be used if installed must still

be a good investment for the organization. In the economical feasibility, the development

cost in creating the system is evaluated against the ultimate benefit derived from the new

systems. Financial benefits must equal or exceed the costs.

The system is economically feasible. It does not require any addition hardware or

software. Since the interface for this system is developed using the existing resources and

technologies available at NIC, There is nominal expenditure and economical feasibility for

certain.

In this we consider following costs:


18/64



1. The cost to conduct a full system investigation.

2. The cost of hardware and software for class of application being considered.

3. The benefit in the form of the reduced cost.

Our system has a lot of features at a minimum cost so it is feasible to Implement and it will

be very much beneficial to the users in the reduced cost. Its software and hardware cost is

also low then the existing system.

In this economic feasibility we are considering the model called COCOMO to calculate

cost estimation.

The Constructive Cost Model(COCOMO) is an algorithmic software cost estimation

model. The model uses a basic regression formula with parameters that are derived fromhistorical project data and current as well as future project characteristics.

COCOMO was first published in Boehm's 1981 book Software Engineering Economicsas

a model for estimating effort, cost, and schedule for software projects. The study

examined projects ranging in size from 2,000 to 100,000 lines of code, and programming

languages ranging from assembly to PL/I.

COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The

first level,Basic COCOMOis good for quick, early, rough order of magnitude estimates of

software costs, but its accuracy is limited due to its lack of factors to account for difference

in project attributes (Cost Drivers).Intermediate COCOMOtakes these Cost Drivers into

account andDetailed COCOMOadditionally accounts for the influence of individual

project phases.

Basic COCOMOcomputes software development cost as a function of program size.

Program size is expressed in estimated thousands of source lines of code (SLOC)

COCOMO applies to three classes of software projects:

Organic projects - "small" teams with "good" experience working with "less than

rigid" requirements


19/64



Semi-detached projects - "medium" teams with mixed experience working with a

mix of rigid and less than rigid requirements

Embedded projects - developed within a set of "tight" constraints. It is also

combination of organic and semi-detached projects.(hardware, software,

operational, ...)

The basic COCOMO equations take the form

Effort Applied (E)= ab(KLOC)b

b[ person-months ]

Development Time (D)= cb(Effort Applied)db[months]

People required (P)= Effort Applied / Development Time [count]

where, KLOCis the estimated number of delivered lines (expressed in thousands ) of code for

project. The coefficients ab, bb, cband dbare given in the following table:

Basic COCOMO is good for quick estimate of software costs. However it does not account

for differences in hardware constraints, personnel quality and experience, use of modern

tools and techniques, and so on.

SOFTWARE

PROJECTab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi_Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32


20/64



Intermediate COCOMO

Intermediate COCOMOcomputes software development effort as function of program size

and a set of "cost drivers" that include subjective assessment of product, hardware,

personnel and project attributes. This extension considers a set of four "cost drivers",each

with a number of subsidiary attributes:-

Semi-detached projects - "medium" teams with mixed experience working with a

mix of rigid and less than rigid requirements

Embedded projects - developed within a set of "tight" constraints. It is also

combination of organic and semi-detached projects.(hardware, software,

operational, ...)

The basic COCOMO equations take the form

Effort Applied (E)= ab(KLOC)b

b[ person-months ]

Development Time (D)= cb(Effort Applied)db[months]

People required (P)= Effort Applied / Development Time [count]

where, KLOCis the estimated number of delivered lines (expressed in thousands ) of code for

project. The coefficients ab, bb, cband dbare given in the following table:

SOFTWARE

PROJECTab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi_Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32


21/64



Basic COCOMO is good for quick estimate of software costs. However it does not account

for differences in hardware constraints, personnel quality and experience, use of modern

tools and techniques, and so on.

Intermediate COCOMO

Intermediate COCOMOcomputes software development effort as function of program size

and a set of "cost drivers" that include subjective assessment of product, hardware,

personnel and project attributes. This extension considers a set of four "cost drivers",each

with a number of subsidiary attributes:-

SOFTWARE

PROJECTai bi

Organic 3.2 1.05

Semi_Detached 3.0 1.12

Embedded 2.8 1.20

The Development time Dcalculation uses Ein the same way as in the Basic COCOMO.

Detailed COCOMO

Detailed COCOMO incorporates all characteristics of the intermediate version with an

assessment of the cost driver's impact on each step (analysis, design, etc.) of the software

engineering process.

The detailed model uses different effort multipliers for each cost driver attribute. These

Phase Sensitiveeffort multipliers are each to determine the amount of effort required to

complete each phase. In detailed cocomo,the whole software is divided in different

modules and then we apply COCOMO in different modules to estimates effort and then

sum the effort In detailed COCOMO, the effort is calculated as function of program size

and a set of cost drivers given according to each phase of software life cycle.


22/64



3. PROCESS MODEL

INTROUCTION

After analyzing the requirements of the task to be performed, the next step is toanalyze the problem and understand its context. The first activity in the phase is studying

the existing system and other is to understand the requirements and domain of the new

system. Both the activities are equally important, but the first activity serves as a basis of

giving the functional specifications and then successful design of the proposed system.

Understanding the properties and requirements of a new system is more difficult and

requires creative thinking and understanding of existing running system is also difficult,

improper understanding of present system can lead diversion from solution.

This document play a vital role in the development of life cycle (SDLC) as it describes the

complete requirement of the system. It means for use by developers and will be the basic

during testing phase. Any changes made to the requirements in the future will have to go

through formal change approval process.

SPIRAL MODELwas defined by Barry Boehm in his 1988 article, A spiral

Model of Software Development and Enhancement. This model was not the first model to

discuss iterative development, but it was the first model to explain why the iteration

models.

As originally envisioned, the iterations were typically 6 months to 2 years long.

Each phase starts with a design goal and ends with a client reviewing the progress thus far.

Analysis and engineering efforts are applied at each phase of the project, with an eye

toward the end goal of the project.

The steps for Spiral Model can be generalized as follows:

The new system requirements are defined in as much details as possible. This

usually involves interviewing a number of users representing all the external or

internal users and other aspects of the existing system.

A preliminary design is created for the new system.

A first prototype of the new system is constructed from the preliminary design.

This is usually a scaled-down system, and represents an approximation of the

characteristics of the final product.

A second prototype is evolved by a fourfold procedure:


23/64



1. Evaluating the first prototype in terms of its strengths, weakness, and

risks.

2. Defining the requirements of the second prototype.

3. Planning an designing the second prototype.

4. Constructing and testing the second prototype.

At the customer option, the entire project can be aborted if the risk is deemed too

great. Risk factors might involve development cost overruns, operating-cost

miscalculation, or any other factor that could, in the customers judgment, result in

a less-than-satisfactory final product.

The existing prototype is evaluated in the same manner as was the previous

prototype, and if necessary, another prototype is developed from it according to the

fourfold procedure outlined above.

The preceding steps are iterated until the customer is satisfied that the refined

prototype represents the final product desired.

The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is

carried on a continuing basis to prevent large scale failures and to minimize down

time.

The following diagram shows how a spiral model acts like:


24/64



Spiral Model


25/64



4. SYSTEM DESIGN

4.1. INTRODUCTION

Software design sits at the technical kernel of the software engineering process and

is applied regardless of the development paradigm and area of application. Design is the

first step in the development phase for any engineered product or system. The designers

goal is to produce a model or representation of an entity that will later be built. Beginning,

once system requirement have been specified and analyzed, system design is the first of the

three technical activities -design, code and test that is required to build and verify software.

The importance can be stated with a single word Quality. Design is the place where

quality is fostered in software development. Design provides us with representations of

software that can assess for quality. Design is the only way that we can accurately translate

a customers view into a finished software product or system. Software design serves as a

foundation for all the software engineering steps that follow. Without a strong design we

risk building an unstable systemone that will be difficult to test, one whose quality

cannot be assessed until the last stage.

During design, progressive refinement of data structure, program structure, and procedural

details are developed reviewed and documented. System design can be viewed from either

technical or project management perspective. From the technical point of view, design is

comprised of four activitiesarchitectural design, data structure design, interface design

and procedural design.


26/64



4.2. ER DIAGRAM

An Entity Relation(ER) Diagram is a specialized graphics that illustrates the

interrelationship between entities in a database. ER diagrams often use symbols to

represent 3 different types of information. Boxes are commonly used to represent entities.

Diamonds are normally used to represent relationships and ovals are used to represent

attributes.

An Entity Relationship Model (ERM), in software engineering is an abstract and

conceptual representation of data. Entity Relationship modeling is a relational schema

database modeling method, used to produce a type of conceptual schema or semantic data

model of a system, often a relation database, and its requirements in a top-down fashion

Entity

The thing which we want to store information. It is an elementary basic building

block of storing information about business process. An entity represents an object defined

within the information system about which you want to store information. Entities are

distinct things in the enterprise.

Boxes are commonly used to represent entities

Relationships

A relationship is a named collection or association between entities or used

to relate two or more entities with some common attributes or meaningful interaction

between the objects.

Diamonds are normally used to represent relationships.


27/64



Attributes

Attributes are the properties of the entities and relationship, Descriptor of

the entity. Attributes are elementary pieces of information attached to an entity.

ovals are used to represent attributes.

It shows the key attribute of entity

Which specifies the relationship between entity and

relationship.

ER Diagram


28/64



4.3. DATA FLOW DIAGRAM

A data flow diagram is graphical tool used to describe and analyze movement of

data through a system. These are the central tool and the basis from which the othercomponents are developed. The transformation of data from input to output, through

processed, may be described logically and independently of physical components

associated with the system. These are known as the logical data flow diagrams. The

physical data flow diagrams show the actual implements and movement of data between

people, departments and workstations. A full description of a system actually consists of a

set of data flow diagrams. Using two familiar notations Yourdon, Gane and Sarson

notation develops the data flow diagrams. Each component in a DFD is labeled with a

descriptive name. Process is further identified with a number that will be used for

identification purpose. The development of DFDS is done in several levels. Each process

in lower level diagrams can be broken down into a more detailed DFD in the next level.

The lop-level diagram is often called context diagram. It consists a single process bit,

which plays vital role in studying the current system. The process in the context level

diagram is exploded into other process at the first level DFD.

The idea behind the explosion of a process into more process is that understanding

at one level of detail is exploded into greater detail at the next level. This is done until

further explosion is necessary and an adequate amount of detail is described for analyst to

understand the process.

Larry Constantine first developed the DFD as a way of expressing system

requirements in a graphical from, this lead to the modular design.

A DFD is also known as a bubble Chart has the purpose of clarifying system

requirements and identifying major transformations that will become programs in system

design. So it is the starting point of the design to the lowest level of detail. A DFD

consists of a series of bubbles joined by data flows in the system.


29/64



DFD SYMBOL

In the DFD, there are four symbols

1. A square defines a source(originator) or destination of system data

2. An arrow identifies data flow. It is the pipeline through which the information flows

3. A circle or a bubble represents a process that transforms incoming data flow into

outgoing data flows.

4. An open rectangle is a data store, data at rest or a temporary repository of data

5. An open rectangle is a data store, data at rest or a temporary repository of data

Process that transforms data flow.

Source or Destination of data

Data flow

Data Store


30/64



CONSTRUCTING DFD

Several rules of thumb are used in drawing DFDS:

1. Process should be named and numbered for an easy reference. Each name should be

representative of the process.

2. The direction of flow is from top to bottom and from left to right. Data traditionally

flow from source to the destination although they may flow back to the source. One

way to indicate this is to draw long flow line back to a source. An alternative way is to

repeat the source symbol as a destination. Since it is used more than once in the DFD it

is marked with a short diagonal.

3. When a process is exploded into lower level details, they are numbered.

4. The names of data stores and destinations are written in capital letters. Process and

dataflow names have the first letter of each work capitalized.

A DFD typically shows the minimum contents of data store. Each data store should

contain all the data elements that flow in and out.

Questionnaires should contain all the data elements that flow in and out. Missinginterfaces redundancies and like is then accounted for often through interviews.


31/64



DFD DIAGRAMS

LEVEL 0 DFD

Context Flow Diagram is a top level (also known as level 0) Data Flow

Diagram. It is only contains one process node, that generalize the function of the

entire system in relationship to external entities. In Context Flow Diagram the

entire system is treated as single process and all its inputs, outputs, sinks and

sources are identified and shown below.


32/64



DOCTOR DETAILS DATA FLOW

1st

LEVEL DFD


33/64



PATIENT DETAILS DATA FLOW

1stLEVEL DFD


34/64



2nd

LEVEL DFD:

4.4. ARCHITECUTRAL DESIGN

2-Tier architecture:

2-Tier Architectures supply a basic network between a client and a server. For example,

the basic web model is a 2-Tier Architecture. A web browser makes a request from a web

server, which then processes the request and returns the desired response, in this case, web

pages. This approach improves scalability and divides the user interface from the data

layers. However, it does not divide application layers so they can be utilized separately.


35/64



This makes them difficult to update and not specialized. The entire application must be

updated because layers arent separated.

4.5. PATTERN DESIGN (USING UML)

MVC( model-view-controller)

Model-view-controller(MVC) architecture

Definition:

Modelviewcontroller (MVC) is a software pattern for implementing user interfaces. Itdivides a given software application into three interconnected parts, so as to separate

internal representations of information from the ways that information is presented to or

accepted from the user.

In addition to dividing the application into three kinds of components, the Modelview

controller (MVC) design defines the interactions between them.

A controller can send commands to the model to update the model's state (e.g.,

editing a document). It can also send commands to its associated view to change the

view's presentation of the mode.

A model notifies its associated views and controllers when there has been a change

in its state. This notification allows the views to produce updated output, and the

controllers to change the available set of commands. Apassiveimplementation of

MVC omits these notifications, because the application does not require them or the

software platform does not support them.


36/64



A view requests information from the model that it needs for generating an output

representation to the user.

4.5.1. UNIFIED MODELING LANGUAGE DIAGRAM

The unified modeling language allows the software engineer to express an analysis

model using the modeling notation that is governed by a set of syntactic semantic and

pragmatic rules.

A UML system is represented using five different views that describe the system from

distinctly different perspective. Each view is defined by a set of diagram, which is as

follows.

User Model View

i. This view represents the system from the users perspective.

ii. The analysis representation describes a usage scenario from the end-users

perspective.

Structural model view

In this model the data and functionality are arrived from inside the system.

This model view models the static structures.

Behavioral Model View

It represents the dynamic of behavioral as parts of the system, depicting the

interactions of collection between various structural elements described in the

user model and structural model view.

It represents the dynamic of behavioral as parts of the system, depicting the

interactions of collection between various structural elements described in the

user model and structural model view.


37/64



Implementation Model View

In this the structural and behavioral as parts of the system are represented as

they are to be built.

Environmental Model View

In this the structural and behavioral aspects of the environment in which the system is to be

implemented are represented.

UML is specifically constructed through two different domains they are

UML Analysis modeling, this focuses on the user model and structural model views

of the system.

UML design modeling, which focuses on the behavioral modeling, implementation

modeling and environmental model views.

Use case Diagrams represent the functionality of the system from a users point of view.

Use cases are used during requirements elicitation and analysis to represent the

functionality of the system. Use cases focus on the behavior of the system from external

point of view.

4.5.2. OVER VIEW OF USE CASE DIAGRAMS

A use case diagramat its simplest is a representation of a user's interaction with the

system and depicting the specifications of a use case. A use case diagram can portray the

different types of users of a system and the various ways that they interact with the system.

This type of diagram is typically used in conjunction with the textual use case and will ften

be accompanied by other types of diagrams as well.


38/64



Doctor Use Case Diagram:


39/64



Patient use case diagram:

Admin use case diagram:


40/64



4.5.3. OVER VIEW OF CLASS DIAGRAM

Class diagram in the Unified Modeling Language (UML) is a type of static structure

diagram that describes the structure of a system by showing the system's classes, their

attributes, operations (or methods), and the relationships among objects.

In the diagram, classes are represented with boxes which contain three parts:

The top part contains the name of the class

The middle part contains the attributes of the class

The bottom part gives the methods or operations the class can take or undertake

In the design of a system, a number of classes are identified and grouped together in a class

diagram which helps to determine the static relations between those objects. With detailed

modelling, the classes of the conceptual design are often split into a number of subclasses.

In order to further describe the behaviour of systems, these class diagrams can be

complemented by state diagram or UML state machine.


41/64




42/64



4.6. USER INTERFACE DIAGRAM

LOGIN FORM


43/64



PATIENT FORM


44/64



DOCTOR PROFILE


45/64



5 . TESTING

5.1. INTRODUCTION

Software testing is a critical element of software quality assurance and represents the

ultimate review of specification, design and coding. In fact, testing is the one step in the

software engineering process that could be viewed as destructive rather than constructive.

A strategy for software testing integrates software test case design methods into a well-

planned series of steps that result in the successful construction of software. Testing is the

set of activities that can be planned in advance and conducted systematically. The

underlying motivation of program testing is to affirm software quality with methods that

5.2. LEVELS OF TESTING

The first level is unit testing. In this testing, individual components are tested to ensure

that they operate correctly. It focuses on verification efforts.

The second level is integration testing. It is a systematic technique for constructing the

program structure. In this testing, many tested modules are combined into the subsystem

which is then tested. The good here is to see if the modules can be integrated properly.

Third level is component testing System testing is actually a series of different tests

whose primary purpose is to fully exercise computer based system. These tests fall outside

scope of software process and are not conducted solely by software engineers.Software testing is a critical element of software quality assurance and represents the

ultimate review of specification, design and coding. In fact, testing is the one step in the

software engineering process that could be viewed as destructive rather than constructive.

A strategy for software testing integrates software test case design methods into a well-

planned series of steps that result in the successful construction of software. Testing is the

set of activities that can be planned in advance and conducted systematically. The


46/64



underlying motivation of program testing is to affirm software quality with methods that

can economically and effectively apply to both strategic to both large and small-scale

systems.

UNIT TESTING

MODULE TESTING

SUB-SYSTEM

TESING

SYSTEM TESTING

ACCEPTANCE

TESTING

Component Testing

Integration Testing

User Testing


47/64



5.3. STRATEGIC APPROACH TO SOFTWARE TESTING

The software engineering process can be viewed as a spiral. Initially system

engineering defines the role of software and leads to software requirement analysis where

the information domain, functions, behavior, performance, constraints and validation

criteria for software are established. Moving inward along the spiral, we come to design

and finally to coding. To develop computer software we spiral in along streamlines that

decrease the level of abstraction on each turn.

A strategy for software testing may also be viewed in the context of the spiral. Unit

testing begins at the vertex of the spiral and concentrates on each unit of the software as

implemented in source code. Testing progress by moving outward along the spiral to

integration testing, where the focus is on the design and the construction of the software

architecture. Talking another turn on outward on the spiral we encounter validation testing

where requirements established as part of software requirements analysis are validated

against the software that has been constructed. Finally we arrive at system testing, where

the software and other system elements are tested as a whole.


48/64



5.4. UNIT TESTING

Unit testing focuses verification effort on the smallest unit of software design, the module.

The unit testing we have is white box oriented and some modules the steps are conducted

in parallel.

5.4.1. WHITE BOX TESTING

This type of testing ensures that

All independent paths have been exercised at least once

All logical decisions have been exercised on their true and false sides

All loops are executed at their boundaries and within their operational bounds

All internal data structures have been exercised to assure their validity.

To follow the concept of white box testing we have tested each form .we have

created independently to verify that Data flow is correct, All conditions are exercised to

check their validity, All loops are executed on their boundaries.

5.4.2. BASIC PATH TESTING

Established technique of flow graph with Cyclomatic complexity was used to derive test

cases for all the functions. The main steps in deriving test cases were:

Use the design of the code and draw correspondent flow graph.

Determine the Cyclomatic complexity of resultant flow graph, using formula:

V(G)=E-N+2 or

V(G)=P+1 or

V(G)=Number Of Regions

Where V(G) is Cyclomatic complexity,

E is the number of edges,

N is the number of flow graph nodes,

P is the number of predicate nodes.

Determine the basis of set of linearly independent paths.


49/64



5.4.3. CONDITIONAL TESTING

In this part of the testing each of the conditions were tested to both true and false aspects.

And all the resulting paths were tested. So that each path that may be generate on particular

condition is traced to uncover any possible errors.

5.4.4. DATA FLOW TESTING

This type of testing selects the path of the program according to the location of definition

and use of variables. This kind of testing was used only when some local variable were

declared. The definition-use chain method was used in this type of testing. These were

particularly useful in nested statements.

5.4.5. LOOP TESTING

In this type of testing all the loops are tested to all the limits possible. The following

exercise was adopted for all loops:

All the loops were tested at their limits, just above them and just below them.

All the loops were skipped at least once.

For nested loops test the inner most loop first and then work outwards.

For concatenated loops the values of dependent loops were set with the help of connected

loop.

Unstructured loops were resolved into nested loops or concatenated loops and tested as

above.

Each unit has been separately tested by the development team itself and all the

input have been validated.


50/64



6.CONFIGURATION MANAGEMENT

Configuration management is a systems development discipline that promotes the

proper identification of the configuration, control of changes, and records the change

implementation status of the physical and functional characteristics of the Interim C2C

system.

6.1PURPOSE

Configuration Management identifies what is required, designed, and produced. It also

provides for the evaluation of changes including effects on technical and operational

performance. This leads to making the configuration visible and understood by all the

parties involved with the project.

Configuration management will be performed by participating Centers at the Configuration

Item level for SWCI(s) as explained in the Error! Reference source not found.section.

Entities developing software for use by Centers (e.g., Centers, PB Farradyne, and IBI) will

maintain baselines of released software.

Configuration management covers three basic essential interdependent activities:

1. Error! Reference source not found. Configuration identification is for the formal

step of identifying the configuration of an item (i.e., name, location, version), and

documenting its functional and physical characteristics.

2.6.5. CConfiguration control is the exercising of established ocedures implement, and

confirm changes to the agreed upon fications and baselines


51/64



6.2OBJECTIVE

It is a firm objective that this Configuration Management Plan shall apply through all

the system life cycle phases of the Interim C2C project which began with the requirements

phase through the production and maintenance phases and to the systems retirement phase.

Appropriate baselines are established at the start of the development phase and are applied

to each Configuration Item.

For SWCI(s) created during the development phase, all development organizations shall

implement software configuration management procedures which will be fully compatible

with and subject to this CMP. Once becoming available for release to the system (that is,successful completion of the Acceptance Test), the developed SWCI(s) will be subject to

the change methods and procedures outlined in this CMP.

6.3CONFIGURATION IDENTIFICATION

General:

Configuration identification consists of setting and maintaining baselines of each

individual Configuration Item (SWCI) that define the Interim C2C system at any point in

time. Depending on the system life cycle phase, different baselines are progressively

established. Details of each baseline established throughout the system life cycle shall be

maintained.

Baseline management:

The objective of establishing a baseline is to define a basis for further system life cycle

process activity and allow reference to, control of, and traceability among configuration

items and to requirements. It serves as the common reference that all system development

activity is built on and dictates to the development team the changes that are to be

implemented.

Baselines shall be established for the configuration items. Developmental baselines

will be established to aid in controlling the software development life cycle processes.


52/64



A Production baseline shall be established upon implementation of the first phase of

the Interim C2C system. Further changes to the Production baseline require review and

approval by the C2C CCB.

Baselines are established in a system development effort to define a formal departure point

for controlling future changes that affect performance or design. A baseline, once defined

and approved, is placed under CM, after which any changes in the baseline should be

formally documented and approved. Each package build should have a unique release

label. Product baselines should be reviewed and approved with an approval memo and

attachments for the description of any discrepancies that are part of the release.

The following items should go in each centers baseline

All C2C related requirement documents

All C2C related design documents. At a minimum these should contain:

o All Messages that the center will publish

o All Messages that the center will subscribe to

o Field by field description of how the published messages will be populated

o

Field by field description of how received messages will be used by thecenter

o Description of actions taken upon receipt of request messages

All C2C related test plans and test plan results

All non proprietary development code required to build the C2C components

All C2C related data and configuration files

Refer to the ICD for details of allowable messages and rules for creation of C2C specific

data fields, such as IDs.

6.4.HARDWARE/COMMUNICATIONS CONFIGURABLE ITEMS:

Each Center shall have responsibility for establishing the initial Production baseline of

all HCCIs affecting the communications network.


53/64



6.5. CONFIGURATION CONTROL :

General:

Configuration control covers the evaluation of all Change Requests and Problem

Reports and their subsequent approval or disapproval. This includes providing methods

and procedures for the systematic proposal, justification, evaluation, coordination, and

approval or disapproval of proposed changes to the Interim C2C system.

The following outlines the method to avoid the possibility of a change being implemented

without due consideration of its effect on the baselines, including logistics impact, costs,

schedules, performance, or interface with any associated Center or vendor.

To enable the configuration control process to operate correctly and effectively, it is

necessary for the CCB to oversee changes having the purpose of:

Providing the relevant information for best decisions on changes to be made;

Determining and implementing decisions;

Reviewing and controlling changes in accordance with policy established by the CCB.

Change Control Tools:

In order to provide a central repository from which to manage the change control

process, a collaborative tool such as the ProjectSolve2website is recommended (see section

Error! Reference source not found.). The ProjectSolve2 shall be used for the following

purposes:

Provide a platform in which participating Centers may access developed software,

interface definitions, and interface control documents;

CCB agendas and minutes which document decisions and policy;

Any policy or procedural documents;

Test plans, procedures, and results;

Submit change requests, repose approved and declined requests and changes

pending CCB approval, and implemented changes.


54/64



Change Procedures:

The configuration control process provides for an orderly incorporation and

documentation of approved changes to the formal configuration baseline. Changes canoriginate as enhancements to existing functionality, hardware problem reports, software

problem reports, or notifications of necessary hardware or software upgrades and/or

patches that may impact the Interim C2C system. Note that there are three types of

change requests that may be submitted. These are outlined within this section and example

forms are detailed in Error! Reference source not found.. One form will be used to

capture the change requests and problem reports. The three types of reports are defined

below: Software Change Request (SCR)

o This will document the nature and functional requirements addressed by a

proposed change to the software or Interface Control Documents. Requests

may be made by participating Centers or MTC. The process utilized to review,

deny, or approve the change is outlined by the form structure and the basic

procedure outlined below.

Problem Report (PR)

o Problem reports will be the basic mechanism for centers to report data or

functionality problems;

Maintenance Change Request (MCR)


55/64



7. MS PROJECT PLAN

7.1. GANTT CHART

A Gantt chart, commonly used in project management, is one of the most popular and

useful ways of showing activities (tasks or events) displayed against time. On the left ofthe chart is a list of the activities and along the top is a suitable time scale. Each activity is

represented by a bar; the position and length of the bar reflects the start date, duration and

end date of the activity. This allows you to see at a glance:

What the various activities are

When each activity begins and ends

How long each activity is scheduled to last

Where activities overlap with other activities, and by how much

The start and end date of the whole proje


56/64



7.2. NETWORK DIAGRAM


57/64




58/64



Network diagrams are schematic displays of project schedule activities and the

interdependencies between these activities. When developed properly, this graphical view

of a projects activities conveys critical schedule characteristics required to effec tively

analyze and adjust schedules thus resulting in accurate and feasible schedules. This

document addresses what should be considered in the development of a network diagram,

how network diagrams are created, and how they may be analyzed to identify necessary

corrective actions and ensure optimal schedule definition.

Network Diagram Creation

Network diagrams can be created manually but are also available as project views

in project scheduling tools such as Microsoft Project. (See Microsoft Project, V iew

More Views Network Diagram).

Inputs:

Project Scope Statement The schedule definition required in network diagram

development must be based on the approved scope documented in the Project Scope

Statement. If network diagram and schedule definition does not account for all

required deliverables in scope, the resulting network diagram and schedule will not

accurately reflect the time necessary to complete the work.

Work Breakdown Structure (WBS) The Project Team must include WBS project

work in the network diagram to ensure comprehensive reflection of project activities.

Historical Project InformationThe accuracy of network diagram/schedule estimation

is strengthened by actual schedule metrics from past projects. Project teams should

consider past level of effort and duration for comparable project activities.

WBS Dictionary The WBS Dictionary defines task durations, dependencies,

predecessor and successor relationships, and resources all of which need to be

defined prior to network diagram creation to ensure that the network diagram

accurately reflects the schedule required to successfully complete the project.

Resource CalendarsThe Project Team should develop and utilize a resource calendar

that includes holidays and personnel availability. Creation of this calendar prior to

network diagram creation will ensure that the schedule accounts for actual working

time.


59/64



Procedure:

Consider all inputs and enter all activity definition, sequencing, and duration

information into a software tool such as Microsoft Project. If using this tool, ensure all

tasks are linked.

Confirm all tasks are linked with accurate dependencies and with resource names

identified for each task.

Output:

Microsoft Project Plan with task dependencies, predecessors and successors defined,

and resources applied to tasks


60/64



7.3. ACTIVITY-ON-ARROW (AOA) DIAGRAM

KEY DAYS

1 SRS DOCUMENTATION A = 10

2 FEASIBILITY STUDY B = 07

3 PROCESS MODEL C =08

4 DESIGN DOCUMANTATION D=15

5 TESTING E=106 CONFIGURATION F=09

7 GANTT CHART G=05

8 CONCLUSION H=08

9 FUTURE SYSTEM I=05

10 REFERENCE J=04

Arrow Diagram (because the pictorial display has arrows in it)


61/64



PERT (Program Evaluation Review Technique) Diagram, and it is used for

identifying time sequences of events which are pivotal to objectives. In Critical Path

Analysis this helps the teams to comprehend specific event sequences driving time

requirements for objective achievement. Activity Network Diagrams are also very useful

when a project has multiple activities which need simultaneous management.

Activity Network Diagrams started out as an engineering and construction project

management tool. Critical Path Analysis draws on this methodology to identify and

standardize medical management activities.

An Activity Network Diagram helps to find out the most efficient sequence of events

needed to complete any project. It enables you to create a realistic project schedule by

graphically showing

the total amount of time needed to complete the project

the sequence in which tasks must be carried out

which tasks can be carried out at the same time

which are the critical tasks that you need to keep an eye on.


62/64



8. CONCLUSION

The Doctor's appointment management system is web application created in order to ease

the burden of managing and keeping track of the appointment between the doctor and the

patient. The project meets all the requirements but despite that, few features will be

welcomed to make the web application richer.


63/64



9. FUTURE ENHANCEMENTS

The project has been developed in a very short period of time and all the efforts have been

taken so that this project is very efficient in its execution there still exists some scope of

improvement in our project. The following lists some of the enhancement that can be

added incorporate into the project:

1. Treatment: to enable the doctor to take mention the treatment given to his patients. A

Treatment table will added in the database.

2. Accessibility to mobile devices: the actual system has been developed for the web only,

but a mobile based interface can be added to enable anyone to access the application via

mobile for example


64/64


10. RFERENCES

[1]. Pressman, R. Software Engineering, A Practitioners Approach 4th Edition,

McGraw-Hill(1997).

[2]. Preece, J. Human-Computer Interaction, Addison-Wesley Publishing

Company(1994).

[3].imothyC.Lethbridge&RobertLaganire. Object-Oriented Software Engineering:

Practical Software Development using UML and Java(SecondEdition).McGraw-

Hill, 2005.

[4] . T. Verhoeff. "Software Engineering Reference Framework".Technical Report CS-

Report 04- 039, Computer Science Reports, Department of Mathematics and Computer

Science, Eindhoven University of Technology, Eindhoven, The Netherlands, 2004.

[5]. Ian Summerville. Software Engineering (Seventh Edition).Addison-Wesley, 2004