8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
1/64
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
3/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 3
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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).
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
4/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 4
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
5/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 5
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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)
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
6/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 6
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
7/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 7
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
8/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 8
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.html8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
9/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 9
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
10/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 10
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
11/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 11
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
12/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 12
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
13/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 13
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
14/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 14
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
15/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 15
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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:
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
16/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 16
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
17/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 17
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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:
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
18/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 18
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
19/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 19
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
20/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 20
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
21/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 21
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
22/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 22
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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:
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
23/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 23
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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:
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
24/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 24
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
Spiral Model
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
25/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 25
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
26/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 26
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
27/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 27
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
28/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 28
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
29/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 29
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
30/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 30
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
31/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 31
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
32/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 32
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR DETAILS DATA FLOW
1st
LEVEL DFD
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
33/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 33
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
PATIENT DETAILS DATA FLOW
1stLEVEL DFD
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
34/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 34
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
35/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 35
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
36/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 36
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
37/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 37
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
38/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 38
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
Doctor Use Case Diagram:
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
39/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 39
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
Patient use case diagram:
Admin use case diagram:
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
40/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 40
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
41/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 41
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
42/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 42
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
4.6. USER INTERFACE DIAGRAM
LOGIN FORM
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
43/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 43
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
PATIENT FORM
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
44/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 44
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR PROFILE
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
45/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 45
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
46/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 46
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
47/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 47
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
48/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 48
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
49/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 49
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
50/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 50
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
51/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 51
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
52/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 52
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
53/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 53
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
54/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 54
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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)
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
55/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 55
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
56/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 56
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
7.2. NETWORK DIAGRAM
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
57/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 57
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
58/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 58
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
59/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 59
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
60/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 60
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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)
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
61/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 61
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
62/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 62
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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.
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
63/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 63
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
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
8/10/2019 DOCTORS SRS MODIFIED (Repaired)12.docx
64/64
DOCTORS APPOINTMENT MANAGEMENT SYSTEM 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
Recommended