DOCTORS SRS MODIFIED (Repaired)12.docx
Short Description
Download DOCTORS SRS MODIFIED (Repaired)12.docx...
Description
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
1
1. SOFTWARE REQUIREMENT SPECIFICATION 1.1. INTRODUCTION Introduction to the Doctor’s Appointment Management System: A doctor‟s appointment management system is prepared for health sector medical practitioners. Using this system both doctors and their assisting personnel can prepare and easily manage their patients‟ appointment schedule. This management system is a good way of arranging the appointments, which help doctors work efficiently.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
2
1.1.1. PURPOSE The system should respond to the requests of doctors, their helping staff and patient. This system enables doctor‟s secretaries or themselves to give appointments to patients according to doctor‟s availability 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 doctor‟s 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
Doctor – A medical practitioner
Secretary – A medical practitioner‟s assistant
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
3
Administrator – A person who manages the system, billing doctors etc.
Web 2.0 – An 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.
JAVA – The 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, mutitiered, scalable, reliable and secure web applications.
STRIPES – a presentation framework for building web applications using the latest Java technologies.
jQuery – jQuery 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 server – The most popular web server (HTTP server).
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
4
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 by –Ian Summerville publisher: Addison –Wesley 7th
edition 2007
1.1.5. OVERVIEW This document is intended for providing an abstract overview of doctor‟s 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 project‟s 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 project‟s 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
5
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 information‟s will 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 Netscape Navigator.
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)
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
6
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
7
1.2.2. PRODUCT FUNCTIONS Our program‟s 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
8
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 product produced 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 user‟s 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
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 doctor‟s 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 patient‟s treatment.
Doctor registers their assistant with the system.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
9
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
10
Administrator To-Do List
Administrator does the general upkeep of the system.
Administrator draws reports from the system.
Administrator activates or deactivates doctor‟s or patient‟s 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 another important 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
Operational, which are computer department‟s communications to the system?
Interactive, which are inputs entered during a dialogue.
11
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
User‟s main interface with the computer.
Operational outputs whose use is purely within the computer department.
Interface outputs, which involve the user in communicating directly.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
12
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
13
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 on every 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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
14
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
15
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 database‟s 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:
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
16
Front-End Selection Front-End means a language that is usedFor user interface designing and coding. FrontEnd 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
Various drivers must be available.
Efficient data handling.
Easy to implement with Front-End
17
2.2. OPERATIONAL FEASIBILITY Proposed projects are beneficial only if they can be turned out into information system. That will meet the organization‟s 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:
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
18
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. It‟s 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 from historical project data and current as well as future project characteristics. COCOMO was first published in Boehm's 1981 book Software Engineering Economics as 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 COCOMO is 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 COCOMO takes these Cost Drivers into account and Detailed COCOMO additionally accounts for the influence of individual project phases.
Basic COCOMO computes 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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
19
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)bb[ person-months ] Development Time (D) = cb(Effort Applied)db[months] People required (P) = Effort Applied / Development Time [count] where, KLOC is the estimated number of delivered lines (expressed in thousands ) of code for project. The coefficients ab, bb, cb and db are given in the following table:
SOFTWARE PROJECT Organic
ab
bb
cb
db
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
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
20
Intermediate COCOMO Intermediate COCOMO computes 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)bb[ person-months ] Development Time (D) = cb(Effort Applied)db[months] People required (P) = Effort Applied / Development Time [count] where, KLOC is the estimated number of delivered lines (expressed in thousands ) of code for project. The coefficients ab, bb, cb and db are given in the following table:
SOFTWARE PROJECT Organic
ab
bb
cb
db
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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
21
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 COCOMO computes 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
ai
bi
Organic
3.2
1.05
Semi_Detached
3.0
1.12
Embedded
2.8
1.20
PROJECT
The Development time D calculation uses E in 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 Sensitive effort 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
22
3. PROCESS MODEL INTROUCTION After analyzing the requirements of the task to be performed, the next step is to analyze 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 MODEL was 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:
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
23
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 customer‟s 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:
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
Spiral Model
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
24
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
25
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 designer‟s 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 customer‟s 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 system – one 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 activities – architectural design, data structure design, interface design and procedural design.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
26
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
27
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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
28
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 other components 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 DFD‟S 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
29
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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
30
CONSTRUCTING DFD Several rules of thumb are used in drawing DFD‟S: 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. Missing interfaces redundancies and like is then accounted for often through interviews.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
31
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
DOCTOR DETAILS DATA FLOW 1st LEVEL DFD
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
32
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
PATIENT DETAILS DATA FLOW 1st LEVEL DFD
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
33
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
34
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
35
This makes them difficult to update and not specialized. The entire application must be updated because layers aren‟t separated.
4.5. PATTERN DESIGN (USING UML)
MVC( model-view-controller)
Model-view-controller(MVC) architecture
Definition: Model–view–controller (MVC) is a software pattern for implementing user interfaces. It divides 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 Model–view– 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. A passive implementation of MVC omits these notifications, because the application does not require them or the software platform does not support them.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
36
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
37
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 user‟s 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 diagram at 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
Doctor Use Case Diagram:
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
38
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
Patient use case diagram:
Admin use case diagram:
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
39
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
40
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
41
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
4.6. USER INTERFACE DIAGRAM
LOGIN FORM
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
42
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
PATIENT FORM
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
43
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
DOCTOR PROFILE
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
44
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
45
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 wellplanned 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 wellplanned 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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
46
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
Component Testing
SUB-SYSTEM TESING
SYSTEM TESTING Integration Testing
ACCEPTANCE TESTING User Testing
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
47
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
48
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
49
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
50
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.1 PURPOSE 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. C – Configuration control is the exercising of established ocedures implement, and confirm changes to the agreed upon fications and baselines
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
51
6.2 OBJECTIVE 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.3 CONFIGURATION 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
52
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 center‟s 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 the center 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
53
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 ProjectSolve2 website 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
54
Change Procedures: The configuration control process provides for an orderly incorporation and documentation of approved changes to the formal configuration baseline. Changes can originate 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)
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
55
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 of the 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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
7.2. NETWORK DIAGRAM
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
56
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
57
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
58
Network diagrams are schematic displays of project schedule activities and the interdependencies between these activities. When developed properly, this graphical view of a project‟s activities conveys critical schedule characteristics required to effectively 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, View→ 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 Information – The 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 Calendars – The 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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
59
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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
60
7.3. ACTIVITY-ON-ARROW (AOA) DIAGRAM
1 2 3 4 5 6 7 8 9 10
KEY SRS DOCUMENTATION FEASIBILITY STUDY PROCESS MODEL DESIGN DOCUMANTATION TESTING CONFIGURATION GANTT CHART CONCLUSION FUTURE SYSTEM REFERENCE
DAYS A = 10 B = 07 C =08 D=15 E=10 F=09 G=05 H=08 I=05 J=04
Arrow Diagram (because the pictorial display has arrows in it)
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
61
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
62
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.
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
63
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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
DOCTOR’S APPOINTMENT MANAGEMENT SYSTEM
64
10. RFERENCES [1]. Pressman, R. Software Engineering, “A Practitioner’s Approach 4th Edition”, McGraw-Hill(1997). [2].
Preece,
J.
“Human-Computer
Interaction”,
Addison-Wesley
Publishing
Company(1994). [3].imothyC.Lethbridge&RobertLaganière.
“Object-Oriented
Practical Software Development using UML and
Software
Engineering:
Java (SecondEdition”). McGraw-
Hill, 2005. [4] . T. Verhoeff. "Software Engineering Reference Framework". Technical Report CSReport 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
DEPARTMENT OF COMPUTER SCIENCE AND APPLICATION
View more...
Comments
