Pharmacy System (PS) : Software Project Management Plan

SOFTWARE PROJECT MANAGEMENT PLAN
For
PHARMACY SYSTEM
(PS)
Acquirer:
Syed Amjad Ali
Prepared By:
GROUP MEMBERS: Nesrin Duman, Onur Öztürker,
Oğuz Bedir, Mert Öcal
Due Date: 17 November

PS Software Project Management Plan Version 1.0
Change History
Date Version File Name Document Format Status
30 November 1.0 Spmp_report.v1.0.doc Microsoft Word Created
2
Preface
This document provides the Software Project Management Plan of PHARMACY

SYSTEM (PS) project, which is about providing the control of drug flow in a hospital or a
clinic in a web-based environment using with PDA and Wireless Network.
PS Software Requirement Specification report is prepared according to IEEE Std. 830-

1998, IEEE Recommended Practice for Software Project Management Plan. This document
includes the information such as purpose, scope, constraints and assumptions of the project. In
addition to this information, managerial, technical and supporting process plans will be also
exist in this document.
3
Table of Contents
Change History .........................................................................Error! Bookmark not defined.
Preface ......................................................................................Error! Bookmark not defined.
Table of Contents................................................................................................................... 4
List of Figures ....................................................................................................................... 6
List of Tables ......................................................................................................................... 7
1 OVERVIEW........................................................................................................................ 8
1.1 Project Summary .................................................................................................................... 8
1.1.1 Purpose, Scope and Objectives ......................................................................................................... 8
1.1.2 Assumptions and Constraints ........................................................................................................... 9
1.1.2.1 Assumptions.............................................................................................................................. 9
1.1.2.2 Constraints ................................................................................................................................ 9
1.1.3 Project Deliverables ........................................................................................................................ 10
1.1.4 Schedule and Budget Summary ...................................................................................................... 11
1.2 Evolution of the Plan............................................................................................................. 12
2 REFERENCES ................................................................................................................ 12
3 DEFINITIONS & ABBREVATIONS ............................................................................. 13
4 PROJECT ORGANIZATION .......................................................................................... 14
4.1 External Interfaces ................................................................................................................ 14
4.2 Internal Structure ................................................................................................................. 15
4.3 Roles and Responsibilities .................................................................................................... 16
5 MANAGERIAL PROCESS PLANS ................................................................................ 17
5.1 Start-up Plan ......................................................................................................................... 17
5.1.1 Estimation Plan ............................................................................................................................... 17
5.1.2 Staffing Plan ................................................................................................................................... 21
5.1.3 Resources Acquisition Plan ............................................................ Error! Bookmark not defined.
5.1.4 Project Staff Training Plan ............................................................. Error! Bookmark not defined.
5.2 Work Plan .............................................................................................................................. 22
5.2.1 Work Activities............................................................................................................................... 22
5.2.2 Schedule Allocation ........................................................................................................................ 46
5.2.3 Resource Allocation ....................................................................................................................... 46
5.2.4 Budget Allocation ........................................................................................................................... 47
5.3 Control Plan........................................................................................................................... 47
5.3.1 Requirements Control Plan ............................................................................................................. 47
5.3.2 Schedule Control Plan .................................................................................................................... 48
5.3.3 Budget Control Plan ....................................................................................................................... 48
5.3.4 Quality Control Plan ....................................................................................................................... 49
5.3.5 Reporting Plan ................................................................................................................................ 49
5.3.6 Metrics Collection Plan .................................................................................................................. 50
5.4 Risk Management Plan ......................................................................................................... 51
5.5 Project Closeout Plan............................................................................................................ 53
6 TECHNICAL PROCESS PLANS ................................................................................... 54
6.1 Process Model ........................................................................................................................ 54
6.2 Methods, Tools and Techniques........................................................................................... 54
4
6.3 Infrastructure Plan ............................................................................................................... 54

6.4 Product Acceptance Plan...................................................................................................... 55
7 SUPPORTING PROCESS PLANS ................................................................................. 55
7.1 Configuration Management Plan ........................................................................................ 55
7.2 Verification and Validation Plan ......................................................................................... 55
7.3 Documentation Plan.............................................................................................................. 56
7.4 Quality Assurance Plan ........................................................................................................ 57
7.5 Review and Audits Plan ........................................................................................................ 57
7.6 Problem Resolution Plan ...................................................................................................... 58
7.7 Subcontractor Management Plan ........................................................................................ 58
8 APPENDIX A – Project Plan .......................................................................................... 59
APPENDIX B – Change Request Form ............................................................................. 62
APPENDIX C – Schedule Control Plan Form .................................................................. 63
APPENDIX D – Schedule Control Report ......................................................................... 64
APPENDIX E – Budget Control Report ............................................................................ 65
5
List of Figures
Figure 1 External Structure .................................................................................................. 15
Figure 2 Internal Structure ................................................................................................... 15
Figure 3 Process Model ........................................................................................................ 57
6
List of Tables
Table 1 Schedule of the Project....................................... Error! Bookmark not defined.
Table 2 Evolution of the Plan .......................................... Error! Bookmark not defined.
Table 3 The Roles and Responsibilities ........................ Error! Bookmark not defined.6
Table 4 Unadjusted Function Point Table ....................................................................... 19
Table 5 Degree of Influences .......................................................................................... 19
Table 6 Staff Training Plan ........................................... Error! Bookmark not defined.2
Table 7 Work Activities ................................................................................................ 222
Table 8 Schedule Allocation ........................................................................................... 46
Table 9 Resource Allocation ........................................................................................... 47
Table 10 Metrics Collection Plan .................................................................................... 50
Table 11 List of Identical Risk ........................................................................................ 51
Table 12 Probability Evolation Criteria .......................................................................... 52
Table 13 Consequence Evalatuon Criteria ...................................................................... 52
Table 14 Risk Management............................................................................................. 53
Table 15 Documentation Schedule ................................................................................. 58
7
1 OVERVIEW
PS Software Project Management Plan is prepared according to IEEE Std. 1058-1998,
IEEE Standard for Software Project Management Plans.
1.1 Project Summary
1.1.1 Purpose, Scope and Objectives
The purpose of the software requirements specification is to produce a list of

specifications for Pharmacy System (PS) which is binding for the development and is as
unambiguous as possible. To this end, it contains the sum of all the requirements which have
been made (and accepted) on this product and project management from the perspective of the
project.
The use of the document is Hospital or Clinic users which are Doctors Nurses, and
Pharmacy Worker. The system is designed to be a platform which brings the drugs
information with the doctors and nurses together and let them share their information.
Pharmacy System (PS), which is a project with a goal of creating a web-based

platfom, using PDA device with Windows operating system and access to a TCP/IP network
via ethernet or wireless network.
This project has two main parts. First approach is to establish the right connection
between the patient and the doctor in order to make the right diagnosis for the patient and
have the best treatment. The second approach is to provide stock control and to provide stock
information to doctors while they are making a prescription.
Within this project we are going to establish the information between Doctor, Nurse
and the Pharmacy workers. The pharmacy system on web is going to be adapted with the
Wireless Network, by using a PDA it is going to provide the communication between the
doctor and the nurse , nurse -patient -doctor and pharmacy worker.
The PS database system will collect and supply required drugs, patient and illnesses
information and PS web interface will be the source which provides a secure and interactive
platform between the users and the database.
8
Objectives and goals of this project:

 To provides drug information to nurses, doctors and pharmacy worker.
 To provide illnesses information to doctors while they are making an examination.
 To provide patient personal information.
 To provide patient medical history registration.
 To provide doctors read the medical history of patient.
 To provide doctors make true decisions while they are making a prescription.
 To provide to reach patient information for Nurse.
 To provide Nurse give the drugs to patient at the right time.
 To provide input-output operations for Pharmacy Staff.
1.1.2 Assumptions and Constraints
1.1.2.1 Assumptions
 The project staff is consisting of 4(four) persons and each person will work 3(three)
hours a day.
 All the necessities such as server, account and PDA will be supplied by CTIS.
 The system will be used by
o Doctors
o Nurse
o Pharmacy Worker
o Database Administrator
1.1.2.2 Constraints
 PS will be developed by four students in CTIS as a part of Senior Project hence

there will be no payments for this project. Te other important constraint is the fixed
schedule to finish the project. The Software Development process ends in May 2007.
 The software development process and documents will be prepared according to
the IEEE Standards 1058 – 1998. 1058 is the SPMP Standard.
 PS will be developed by CTIS students; hence there will be no payment for the
Project team.
9
1.1.3 Project Deliverables

 Initial Plan: The document will be prepared until 17 October 2006.
 Initial Revision: The subcontractors will review the initial plan until 11 November
2006. Initial Revision will be submitted to MONO Group.
 Initial Revision Plan: Then Initial Revision Plan will be written by MONO
according to the corrections of the Initial Revision.
 SRS: This is the Software Requirements Specification document, which will be
prepared until 18 November 2006.
 SRS Revision: The subcontractors will review the SRS until 30 November 2006.
Then SRS Revision will be submitted to MONO Group.
 SRS Revision Report: SRS Revision Report will be prepared by MONO according
to the corrections of SRS Revision.
 SPMP: This is the Software Project Management Plan, which is a controlling
document for managing the software project. It will be prepared until 30 November
2006.
 SPMP Revision: The subcontractors will review the SPMP until 20 December
2006. Then SPMP Revision will be submitted to MONO Group.
 SPMP Revision Report: SPMP Revision Report will be prepared by MONO
according to the corrections of SPMP Revision.
 SDD: This is the Software Design Document, which is the representation of the
software system for communicating software design information. It will be prepared
until 20 December 2006.
 SDD Revision: The subcontractors will review the SDD until 25 December 2006.
Then SDD Revision will be submitted to MONO Group.
 SDD Revision Report: SDD Revision Report will be prepared by MONO
according to the corrections of SDD.
 Starting the Coding: will be started on January 2007.
 Finishing the Coding: will be finished on March 2007.
 Detailed Design: will be started on March 2007 and it will continue until the
demonstration.
 Demonstration of Product: It will be made on May 2007.
 User Manual: will be prepared after demo review until May 2007.
10
 Delivery of Final Product: The final product will include the software, the
software source codes and the database. The delivery will be on May 2007.
1.1.4 Schedule and Budget Summary
Due Date Document Name
17 October 2006 Initial Plan
November 2006 Initial Revision
November 2006 Initial Revision Plan
18 November 2006 SRS
November 2006 SRS Revision
November 2006 SRS Revision Report
30 November 2006 SPMP
December 2006 SPMP Revision
December 2006 SPMP Revision Report
20 December SDD
December 2006 SDD Revision
December 2006 SDD Revision Report
January 2007 Starting the Coding
March 2007 Finishing the Coding
March 2007 Detailed Design
May 2007 Demonstration of Product
May 2007 User Manual
May 2007 Delivery of Final Product
Table 1 Schedule of the Project
No budget will be associated with PS by the MONO members, because all needs such
as server, account for web-address or database will be supply by the CTIS.
11
1.2 Evolution of the Plan
This SPMP is evolved from the Initial Plan of the PS project that is simple version of
this document. Hence, this document is developed by the MONO Group Members with the
approval of the acquirer.
There are three scheduled versions of this plan. The following table summarizes the
scheduled versions.
Due Date Document name
17 October 2006 Initial Plan
11 November 2006 Initial Revision Plan
18 November 2006 SRS
30 November SPMP
Table 2 Evolution of the Plan
2 REFERENCES
[1] IEEE STD 1058-1998, IEEE Standard for Software Project Management Plans
[2] Ian Sommerville, Software Engineering Seventh Edition, Addison-Wesley 2004
[3] Humphrey, W, Managing the Software Process, Addison-Wesley 1989
[4] Arthur M. Langer, Analysis and Design of Information System, Springer-Verlag New
York, Inc., 2001
[5] CTIS 455 Software Engineering Lecture Notes.
[6] http://www.rspa.com/spi/ Software Engineering Resource Page
[7] http://www.geocities.com/ResearchTriangle/Campus/6025/fpa/fpa.htm, Functional Size
Measurement (FSM) Page.
12
3 DEFINITIONS & ABBREVATIONS

CTIS: Computer Technology and Information System
CRS: Change Request Form
DB: Database
DBMS: Database Management Systems
FP: Function Point
HTTP: Hypertext Transmission Protocol
IE: Internet Explorer
IEEE: Institute of Electrical & Electronics Engineers
MHZ: Mega hertz
MONO: Group members of the software development team (Mert, Oğuz, Nesrin, Onur)
MSSQL: Structured Query Language
RAM: Random Access Memory
RSS: Really Simple Syndication
SCPF: Schedule Control Plan Form
SCR: Schedule Control Report
SDD: Software Design Document
SPMP: Software Project Management Plan
SRS: Software Requirement Specification
SSL: Secure Socket Layer
TCP/IP: Transmission Control Protocol / Internet Protocol
UC: Use Case
UI: User Interface
UM: User Manual
URL: Universal Resource Location
XML: Extensible Markup Language
.NET: Dot Network
WBS: Work Breakdown Structure
Acquirer: Specifies requirements for and accepts delivery of a new or modified software
product. In this project acquirers refer to our two instructors.
Project Deliverable: A work product to be delivered to the acquirer
13
Senior Project: Refers to a lecture that is to be finished by the fourth year students to
graduate.
Subcontractor: Refers to the review group who make necessary corrections in the documents
in order to improve the quality of the product and documentation. In this project subcontractor
refer to our Software Engineering course instructor.
User: Refers to people in the hospital or clinic who are doctor, nurse, pharmacy worker and
database administrator.
4 PROJECT ORGANIZATION
4.1 External Interfaces
Acquirer: CTIS Instructor Symed Amjad Ali.
Customer: CTIS Instructor Neşe Şahin Özçelik.
Project Group: MONO Mert Öcal, Oğuz Bedir, Nesrin Duman, Onur Öztürker.
Subcontractor: Software Engineering Instructor Beyhan Akporay.
CTIS
Acquirer Customer
Project Group
Subcontractor
Figure 1 External Interfaces
14
4.2 Internal Structure

All the responsibilities will be shared by all of the members of this project. The main
parts of the organization are Software System Engineering, Software Configuration
Management, Software Quality Assurance, Coding and Training. The Internal Structure of
the project is given in Figure 2:
PS
Project
Software Training Software Software

System Configuration Quality
Engineering Management Assurance
Software
Requirements Testin Design Content
Enginering
Version
Engineering Management Control
Analysis Architectural
Concept Design
Requirement Interface
Elicitation Design
Requirement Content
s Design
Figure 2 Internal Structure
15
4.3 Roles and Responsibilities
Name E-mail Roles and Responsibilities

Nesrin DUMAN Project Manager, Software
Engineer, Configuration
Manager, Programmer, DB
Administrator, Meeting
Tracer, Test Team Member,
Training Coordinator.
Mert ÖCAL Software Engineer,
Programmer, DB
Administrator, Test Team
Member, User Interface
Designer.
Oğuz BEDİR Software Engineer,
Programmer, Test Team
Member, Configuration
Manager, Training
Coordinator.
Onur ÖZTÜRKER Software System Engineer,
Software Engineer,
Programmer,
DB Administrator, Test
Team Member,
Programmer, Configuration
Manager
Table 3 the Roles and Responsibilities
Software Engineer: will plan, analyze and design the software project during preparing the
documentations of project.
Programmer: will write the code of the system.
Test Team Member: will test the system to augment the quality.
Training Coordinator: will prepare the stuff-training plan to ensure that necessary skill levels
in sufficient numbers will be available to successfully conduct the software project.
Meeting Tracer: will organize and coordinate the meetings of team members and also
meetings with customers.
DB Administrator: will be responsible from database configuration and management.
16
Software System Engineer: will help the project team to identify, control, and track
requirements and changes to requirements at any time as the project proceeds and make the
architectural design of the project accordingly.
Project Manager: will plan (schedule, cost and budget), motivate, organize and control the
software team.
User interface designer: will design the web-based user interfaces.
Configuration Manager: will manage different versions of the work products, control the
changes that are imposed and audit and report on the changes that are made. And also will
update the project’s web page regularly.
5 MANAGERIAL PROCESS PLANS
5.1 Start-up Plan
5.1.1 Estimation Plan
The cost and schedule for conducting the project (PS) as well as the methods, tools,
techniques, used to estimate project cost, schedule, resource requirements, external input and
output data associated confidence levels are presented below.
Function Point method is used for size estimation of the project. The functions of the
project are identified according to the user requirements defined during the initial meetings.
These functions are:
External inputs:
 New Patient Information Add
 New Patient Information Delete
 New Patient Information Update
 Patient Disease Identification and Therapy Information Add
 Patient Disease Identification and Therapy Information Delete
 Patient Disease Identification and Therapy Information Update
 Drug Information Add
 Drug Information Delete
 Drug Information Update
 Drug Stock Input-Output Information Add
17
 Drug Stock Input-Output Information Delete

 Drug Stock Input-Output Information Update
 Disease Information ICP-10 Add
 Disease Information ICP-10 Delete
 Disease Information ICP-10 Update
External Output:
 Patient Registration
 Drug Registration
 Stock Registration
 Warning Message
External Enquiry:
 Access to Patient Records
 Access drugs which are given to patient before
 Access to Drugs Records
 Access to stock records
 Access number of decreasing drugs records
 Access to drug names and codes records
External Interface Files:

 Wireless network interface
Internal Logical File:

 Doctor Table
 Patient Table
 Drug Table
 Disease Names Table
 Disease Groups Table
18
Function Levels
Components Low Average High Total
External Inputs 9x3 6x4 1x6 54
External Outputs 2x4 2x5 0x7 18
External Inquiries 4x3 2x4 1x6 26
Internal Logical Files 5x 7 0 x 10 0 x 15 35
External Interface Files 0x5 0x7 1 x 10 10
Total Unadjusted FP (UFP): 143
Table 4 Unadjusted Function Point Table
In Table 4, the Degree of Influences (DI) is shown:

Characteristic Degree of Description
Influence (DI)
1. Data Communication 2 Output Data Entry is required
2. Distributed data processing 4 Online and in both directions
3. Performance 3 Response time is critical
4. Heavily used configuration 2 Security and timing issues
5. Transaction rate 4 Service level agreements are high level
6. Online data entry 5 More than %90 is online data entry
7. End user efficiency 3 Six of more of the elements
8. Online update 5 Data lost is essential
9. Complex processing 3 Three of the elements
10. Reusability 4 Modulated coding
11. Installation ease 1 Only server-side installation
12. Operational ease 1 Minimizes the need of paper handling
13. Multiple sites 1 Identical hardware and software
14. Facilitate change 3 Three of the elements
Total Degree of Influence (TDI): 41
Table 5 Degree of Influences
The scale of criteria weights for the table 4 (TDI):

0 1 2 3 4 5
No influence Incidental Moderate Average Significant Essential
The table shown above lists the replies of the system to the specific questions
depending on the IFPUG documents.
Three Formulas for Size Estimation of the FIS;

 Total Degree of Influence (TDI) = Sum of the Influence Factors
 Value Adjustment Factor (VAF) =0.65 + (0.01 * TDI)
19
 Function Points (FP) = VAF * unadjusted FP
Value Adjustment Factor (VAF) = (TDI x 0.01) + 0.65 = (41 x 0.01) + 0.65 = 1.06
Adjusted Function Point Count (FP) = UFP x VAF = 1.06 x 143 = 151.58
The number of lines of code is then defined by:

Line of Code = (SLOC per FP for Java) x FP = 30 x 151.58 = 4547.4
Effort Estimation
An LOC-oriented estimation model is used for effort estimation.

The number of lines of code is then defined by:
LOC = FP x Language Factor
KLOC = 4.547 (4547.4 LOC)
Then the effort is:

Effort (Coding) = a x Size b
a and b are constants that depend on the project, and size is measured in thousands of
lines of code (KLOC).
a = 3.2 is determined for PS
b = 1.05 is determined for PS
Because of the decision, that the software project has an “organic” structure.
E = 3.2 x 4.547 1.05
E = 3.2 x 4.90 = 15.68 (man month)
COCOMO model is used to calculate the schedule estimation for the PS. COCOMO
model calculates effort in man months.
COCOMO: Schedule = 2.5 x Effort e

“e” depends on the modes of the difficulty so that e is decided as 0.38 as it is for the
other organic software projects.
COCOMO = 2.5 x 15.68 0.38

COCOMO =2.5 x 2.85
COCOMO = 7.125 months ~ 7.1 months
20
Therefore such a software project needs:
Staff = Effort’ / Duration

Staff = 15.68 / 7.1 = 2.20 persons
COCOMO model calculates effort in staff months (19 days per month or 152 working
hours per month). The payment is $10 for hourly.
Cost Estimation
The hourly salary of each group member is $10, therefore the estimated cost of the
Project is:
15.68 man month = 15.68 x 152 (hours in a month) = 2383,36~ 1383 man hours
Cost = Effort x $ (the hourly salary)
C = 2383 man-hours x $10/man-hours
C = $23.830
5.1.2 Staffing Plan

Each one of the members of MONO is fourth grade students with the experience of in
different programming language and have the skills required for the software project. Some of
the skills which are required for each of the group member are listed below:
 Programming Standards
 Software Development Process
 Software Project Management
 Estimation Techniques
 Personal Software Process
 Analysis and Testing
The Gantt Charts are used to depict the staffing plan by project phase; this chart is
given on Appendix A.
21
5.1.3 Resources Acquisition Plan
Each one of the group members has the same designated responsibilities which are
required to acquire resources as needed through the evolution of the project.
 Since our customers are allocated in Bilkent Campus, there is no transportation cost
for the meetings.
 MONO members need training. Since, all the training will be given by the team
members; there is no need to assign a budget for training.
 Both hardware and software are supplied by the group members.
5.1.4 Project Staff Training Plan
Subject Start End Trainer Method
.Net Nov 14, Nov 28, Oğuz Bedir,Mert Lectures and

Öcal discussion
Table 6 Staff Training Plan
5.2 Work Plan
5.2.1 Work Activities
Work activities of PS project are given in table 10. The milestone tasks are identified
at the third column by *Milestone mark.
WBS No: Task Name: Milestone

1. PS Project
1.1 Problem Analysis
1.1.1 Meeting with the Customer
1.1.2 Determining the Problems
1.2 Initial Plan
1.2.1 Studying about IEEE std 1058
1.2.2 Determining Cases for Initial Plan
1.2.3 Documenting Initial Plan
1.2.4 Discussion about issues of Initial Plan
1.2.5 Delivery of the first version of Initial Plan *Milestone
1.2.6 Feedback of Initial Plan
1.2.7 Delivery of updated Initial Plan *Milestone
1.3 Software Requirement Specification
22
1.3.2 Determining actors and use cases

1.3.3 Detailing use cases
1.3.4 Documenting SRS
1.3.5 Discussion about issues of SRS
1.3.6 Delivery of the first version of SRS *Milestone
1.3.7 Feedback of SRS
1.3.8 Delivery of updated SRS *Milestone
1.4 Software Project Management Plan
1.4.2 Determining Cases for SPMP
1.4.3 Documenting SPMP
1.4.4 Discussion about issues of SPMP
1.4.5 Delivery of the first version of SPMP *Milestone
1.4.6 Feedback of SPMP
1.4.7 Delivery of updated SPMP *Milestone
1.5 Software Design Description
1.5.2 Determining Design Entities
1.5.3 Determining Design Entity Attributes
1.5.4 Drawing Design Views
1.5.5 Documenting SDD
1.5.6 Discussion about issues of SDD
1.5.7 Delivery of the first version of SDD *Milestone
1.5.8 Feedback of SDD
1.5.9 Delivery of updated SDD *Milestone
1.6 Coding
1.6.1 Determining the Coding Standard
1.6.2 Coding of General Interfaces
1.6.3 Coding of Infrastructure of Project
1.6.4 Code Review of General Interfaces
1.6.5 Testing of Code side of Product
1.6.6 Meeting with Customer about the Product
1.6.7 Update and Delivery of Product *Milestone
1.7 User Manual
1.7.1 Determining Cases for UM
1.7.2 Documenting UM
1.7.3 Discussion about issues of UM
1.7.4 Delivery of the first version of UM *Milestone
Table 7 Work Activities
23
Work packages for each activity are given below:
Activity Number 1.1.1

Activity Code M-Cstm.
Activity Name Meeting with the Customer
Estimated Duration/Effort 0.12 day/ 1.30 man-hour
Resources Needed Personnel: Team Members
Skill: Communication
Tool: Notebook
Travel: N/A
Outputs Borders of the Project
Baselines No
Predecessors
Successors 1.1.2
Completion Criteria Confirmation of the Customer
Implementation
Personnel Assigned Team Members
Starting Date 08 October 06
Completion Date 08 October 06
Cost (Budgeted and Actual) NA
Legacy Comments None

Activity Code Dtrm.-Prob.
Activity Name Determining the Problem
Estimated Duration/Effort 1 day/ 2 man-hour
Skill: Problem Solving Analysis, Brainstorming
Tool: Notebook
Travel: N/A
Outputs Explanation of the Problems
Baselines No
Predecessors 1.1.1
Successors
Completion Criteria Problems are defined
Implementation
24

Activity Code STD-IEEE-1058
Activity Name Studying about IEEE std. 1058
Skill: Capability of understanding standards.
Tool: IEEE Document
Travel: N/A
Outputs Having a Vision about IEEE std. 1058
Baselines No
Predecessors 1.1.1-1.1.2
Successors 1.2.2
Completion Criteria Adaptation with IEEE std. 1058
Implementation

Activity Code DeCa-IP
Activity Name Determining Cases for Initial Plan
Tool: Notebook, IEEE document
Travel: N/A
Outputs Borders of the IP
Baselines No
Predecessors 1.2.1
Successors 1.2.3
Completion Criteria Index of Initial Plan is determined
Implementation
25

Activity Code Doc-IP
Activity Name Documenting Initial Plan
Estimated Duration/Effort 3 day/ 3.5 man-hour
Tool: Notebook, MS-Word, MS- Project, MS-Visio.
Travel: N/A
Outputs IP
Baselines No
Successors 1.2.5
Completion Criteria Initial Plan is documented
Implementation

Activity Code Dis-IP
Activity Name Discussing about issues of IP
Tool: Notebook, IEEE document, Existing IP
Travel: N/A
Outputs Borders of IP
Baselines No
Predecessors 1.2.3
Successors 1.2.5
Completion Criteria Initial Plan is reviewed
Implementation
26

Activity Code Del-IP
Activity Name Delivery of the first version of IP
Tool: PC , E-mail, Flash memory
Travel: N/A
Outputs IP
Baselines No
Successors 1.2.7
Completion Criteria Initial Plan is established
Implementation

Activity Code Fb-IP
Activity Name Feedback of IP
Skill: Communication, Web-page skill
Tool: Notebook, MS-Visio, Ms-Project, MS-Word
Travel: N/A
Outputs Reviewed IP
Baselines No
Predecessors 1.2.5
Successors 1.2.7
Completion Criteria Initial Plan is reviewed and corrected.
Implementation
Starting Date 11 November 06
Completion Date 13 November 06
27

Activity Code UDel-IP
Activity Name Delivery of Updated IP
Skill: Web-page skill
Travel: N/A
Outputs Updated IP and web-page
Baselines No
Predecessors 1.2.6
Successors
Completion Criteria IP is updated and established.
Implementation

Skill: Capability of understanding standards
Tool: IEEE Document
Travel: N/A
Baselines No
Predecessors
Successors 1.3.2-1.3.3
Implementation
Cost (Budgeted and Actual) N/A
28

Activity Code De-AcUc
Activity Name Determining actors and use cases
Tool: Notebook, IEEE document, IP
Travel: N/A
Outputs Actors, use cases
Baselines No
Predecessors 1.3.1
Successors 1.3.3
Completion Criteria Actors and use cases are identified.
Implementation

Activity Code Det-Uc
Activity Name Detailing use cases
Skill: Familiarity with UML
Tool: Notebook, MS-Word, Use Case Template
Travel: N/A
Outputs Detailed Use Case Diagrams
Baselines No
Predecessors 1.3.2
Successors 1.3.4
Completion Criteria Use Cases are defined with the use case template
Implementation
29

Activity Code Doc-SRS
Activity Name Documenting SRS
Skill: Familiarity with use case diagram, activity
diagram, ER diagram
Tool: Notebook, MS-Word, MS-Visio.
Travel: N/A
Outputs SRS document
Baselines No
Predecessors 1.3.1-1.3.2-1.3.3
Successors 1.3.5
Completion Criteria SRS document is created
Implementation

Activity Code Dis-SRS
Activity Name Discussion about issues of SRS
Tool: Notebook, IEEE document, Existing SRS
Travel: N/A
Outputs Borders of SRS
Baselines No
Predecessors 1.3.4
Successors 1.3.6
Completion Criteria SRS plan is reviewed
Implementation
Completion Date 15 Nowember 06
30

Activity Code Del-SRS
Activity Name Delivery of the first version of SRS
Travel: N/A
Outputs SRS and updated web-page
Baselines No
Completion Criteria SRS is established
Implementation

Activity Code Fb-SRS
Activity Name Feedback of SRS
Tool: Notebook, MS-Visio, MS-Word
Travel: N/A
Outputs Reviewed SRS
Baselines No
Predecessors 1.3.6
Successors 1.3.8
Completion Criteria SRS is reviewed and corrected.
Implementation
Starting Date -
Completion Date -
31

Activity Code UDel-SRS
Activity Name Delivery of Updated SRS
Travel: N/A
Outputs Updated SRS and web-page
Baselines No
Predecessors 1.3.7
Successors
Completion Criteria SRS is updated and established.
Implementation
Starting Date -
Completion Date -

Tool: IEEE Document
Travel: N/A
Baselines No
Predecessors
Successors 1.4.2
Implementation
32

Activity Code DeC-SPMP
Activity Name Determining Cases for SPMP
Tool: Notebook, IEEE document, IP
Travel: N/A
Outputs Updated IP, the main missing from IP
Baselines No
Predecessors 1.4.1
Successors 1.4.3
Completion Criteria The missing parts of the IEEE std. 1058 are
identified.
Implementation

Activity Code Doc-SPMP
Activity Name Documenting SPMP
Skill: Familiarity with project planning
Tool: Notebook, MS-Word, MS-Visio, MS-Project
Travel: N/A
Outputs SPMP document
Baselines No
Predecessors 1.4.2
Successors 1.4.4
Completion Criteria SPMP document is created
Implementation
33

Activity Code Dis-SRS
Activity Name Discussion about issues of SPMP
Tool: Notebook, IEEE document, Existing SPMP
Travel: N/A
Outputs Borders of SPMP
Baselines No
Predecessors 1.4.3
Successors 1.4.5
Completion Criteria SPMP plan is reviewed
Implementation

Activity Code Del-SPMP
Activity Name Delivery of the first version of SPMP
Travel: N/A
Outputs SPMP and updated web-page
Baselines No
Completion Criteria SPMP is established
Implementation
34

Activity Code Fb-SPMP
Activity Name Feedback of SPMP
Tool: Notebook, MS-Visio, MS-Word, MS-Project
Travel: N/A
Outputs Reviewed SPMP
Baselines No
Predecessors 1.4.5
Successors 1.4.7
Completion Criteria SPMP is reviewed and corrected.
Implementation
Starting Date -
Completion Date -

Activity Code UDel-SPMP
Activity Name Delivery of Updated SPMP
Travel: N/A
Outputs Updated SPMP and web-page
Baselines No
Predecessors 1.4.6
Successors
Completion Criteria SPMP is updated and established.
Implementation
Starting Date -
Completion Date -
35

Activity Name Studying about IEEE std 1016
Tool: IEEE Document
Travel: N/A
Baselines No
Predecessors
Successors 1.5.2-1.5.3-1.5.5
Implementation
Starting Date 01 December 06
Completion Date 01 December 06

Activity Code DeDE-SDD
Activity Name Determining Design Entities
Skill: Communication, Software Design
Tool: Notebook, IEEE document, SRS
Travel: N/A
Outputs Design Entities
Baselines No
Predecessors 1.5.1
Completion Criteria Design Entities will accepted by group members
Implementation
36

Activity Code DeDEA-SDD
Activity Name Determining Design Entity Attributes
Skill: Communication, Software Design
Tool: Notebook, IEEE document, SRS
Travel: N/A
Outputs Design Entity Attributes
Baselines No
Successors 1.5.4
Completion Criteria Design Entity Attributes will accepted by group
members.
Implementation

Activity Code DDW-SDD
Activity Name Drawing Design Views
Skill: Familarity with use-case, UML
Tool: Notebook, IEEE document, MS-Visio,
Photoshop
Travel: N/A
Outputs User Interfaces
Baselines No
Successors 1.5.5
Completion Criteria User Interfaces are identified and drawn.
Implementation
37

Activity Code Doc-SDD
Activity Name Documenting SDD
Skill: Familiarity with standards, GUI design
Tool: Notebook, MS-Word, MS-Visio
Travel: N/A
Outputs SDD document
Baselines No
Successors 1.5.6
Completion Criteria SDD document is created
Implementation

Activity Code Dis-SDD
Activity Name Discussion about issues of SDD
Tool: Notebook, IEEE document, Existing SDD
Travel: N/A
Outputs Borders of SDD
Baselines No
Predecessors 1.5.5
Successors 1.5.7
Completion Criteria SDD plan is reviewed
Implementation
38

Activity Code Del-SDD
Activity Name Delivery of the first version of SDD
Travel: N/A
Outputs SDD and updated web-page
Baselines No
Completion Criteria SDD is established
Implementation

Activity Code Fb-SDD
Activity Name Feedback of SDD
Tool: Notebook, MS-Visio, MS-Word
Travel: N/A
Outputs Reviewed SDD
Baselines No
Predecessors 1.5.7
Successors 1.5.9
Completion Criteria SDD is reviewed and corrected.
Implementation
Starting Date -
Completion Date -
39

Activity Code UDel-SDD
Activity Name Delivery of Updated SDD
Travel: N/A
Outputs Updated SDD and web-page
Baselines No
Predecessors 1.5.8
Successors
Completion Criteria SDD is updated and established.
Implementation
Starting Date -
Completion Date -

Activity Code De-CS
Activity Name Determining the Coding Standard
Skill: Familiarity with coding standards and
software development process
Tool: MS Word
Travel: N/A
Outputs Coding Standard
Baselines No
Predecessors
Successors 1.6.2
Completion Criteria Coding Standards are defined
Implementation
Starting Date -
Completion Date -
40

Activity Code Cod-GI
Activity Name Coding of General Interfaces
Skill: Familiarity with coding, GUI design and
database operations
Tool: .Net
Travel: N/A
Outputs General Interfaces
Baselines No
Predecessors 1.6.1
Completion Criteria General Interfaces are completed.
Implementation
Starting Date -
Completion Date -

Activity Code Cod-IOP
Activity Name Coding of Infrastructure of Project
Skill: Familiarity with coding and database
operations
Tool: .Net, MySQL
Travel: N/A
Outputs Infrastructure of project
Baselines No
Predecessors 1.6.2
Successors 1.6.4
Completion Criteria Infrastructure of project is completed.
Implementation
Starting Date -
Completion Date -
41

Activity Code CodRe-GI
Activity Name Code Review of General Interfaces
Skill: Familiarity with coding
Tool: .Net, MSSQL
Travel: N/A
Outputs Issue list
Baselines No
Predecessors 1.6.2
Successors 1.6.7
Completion Criteria Issue list is prepared.
Implementation
Starting Date -
Completion Date -

Activity Code CodRe-GI
Activity Name Testing of Code side of Product
Skill: Familiarity with testing standard
Tool: .Net, MySQL
Travel: N/A
Outputs Tested product
Baselines No
Successors 1.6.7
Completion Criteria Testing process of the product is completed.
Implementation
Starting Date -
Completion Date -
42

Activity Code M-Cust-Prod
Activity Name Meeting with Customer about the Product
Estimated Duration/Effort 0.5 day/ 1.30 man-hour
Tool: Notebook, existing product
Travel: N/A
Outputs Product which is reviewed by the customer.
Baselines No
Predecessors 1.6.5
Successors 1.6.7
Completion Criteria The customer give an approval about the product
Implementation
Starting Date -
Completion Date -

Activity Code Del-UM
Activity Name Update and Delivery of Product
Skill: Coding
Tool: Software development tool
Travel: N/A
Outputs Updated product
Baselines No
Predecessors 1.6.6
Successors
Completion Criteria Product is updated
Implementation
Starting Date -
Completion Date -
43

Activity Code DeC-UM
Activity Name Determining Cases for UM
Skill: Communication, software documentation
Tool: Notebook, IEEE document
Travel: N/A
Outputs User manual cases
Baselines No
Predecessors
Successors 1.7.3
Completion Criteria The sections of UM are discussed and agreed.
Implementation
Starting Date -
Completion Date -

Activity Code Doc-UM
Activity Name Documenting UM
Skill: Familiarity with software documentation
Tool: MS-Word.
Travel: N/A
Outputs User Manual
Baselines No
Predecessors 1.7.1
Successors 1.7.3
Completion Criteria UM is created
Implementation
Starting Date -
Completion Date -
44

Activity Code Dis-UM
Activity Name Discussion about issues of UM
Tool: Notebook, IEEE document, Existing UM
Travel: N/A
Outputs Borders of UM
Baselines No
Predecessors 1.7.2
Successors 1.7.4
Completion Criteria User manual is reviewed
Implementation
Starting Date -
Completion Date -

Activity Code Del-UM
Activity Name Delivery of the first version of UM
Travel: N/A
Outputs UM and updated web-page
Baselines No
Predecessors 1.7.3
Successors
Completion Criteria UM is established
Implementation
Starting Date -
Completion Date -
45
5.2.2 Schedule Allocation
Table 8 Schedule Allocation
46
5.2.3 Resource Allocation
Group members have the general information about design techniques of .Net
language. PCs will be used for documentations of the reports that are IP, SRS, SPMP and
SDD and coding. Table 9 shows software tools to be used by project phase. Personnel
allocation for each WBS item is given in Table 8.
WBS WBS Item SOFTWARE RESOURCES

No
1.2 Initial Plan MS Word, MS Project, MS Visio,
Photoshop
1.3 Software Requirement Specification MS Word, MS Visio
1.4 Software Project Management Plan MS Word, MS Project, MS Visio
1.5 Software Design Description MS Word, MS Visio, Photoshop
1.6 Coding MS Word, Visual Studio 2005
Professional Edition, ASP .NET
1.7 User Manual MS Word
Table 9 Resource Allocation
5.2.4 Budget Allocation
There is no budget allocated for PS project.
5.3 Control Plan
5.3.1 Requirements Control Plan
The lecture’s instructor predefines the schedule of the project. All of the requirements
in the SRS are written as a result of the meeting with the acquirers. Hence, the requirements
are constant and certain. However, small changes that do not affect the scope of the project
can be occurred by the request of the acquirers during the project.
The schedule and resources of the project are fixed. Therefore, all of the requirements which
are defined in the SRS are almost definite and stable. Only minor changes will be made in the
continuity of the project because major changes effects the over schedule of the project.
For minor changes, “A Change Request Form (CRF)” (Appendix B) is filled by the
acquirer for the requested minor changes and submitted to the software development team for
evaluation. After the evaluation, the acquirer’s request will be accepted or rejected. If the
47
request rejected, document of the objection will be send to the acquirer. If the request
accepted, necessary changes will be made in the all related plans. After the changes are made,
“Requirement Change Report (RCR)” (Appendix B) will be prepared and submitted to the
acquirer.
5.3.2 Schedule Control Plan
The project schedule is fixed. While preparing the schedule plan, MS Project tool is
used and all the milestones of the project phases are defined. The software development team
sticks the milestones. At every milestone, necessary deliverables send to the acquirer and
subcontractor and subcontractor will be check and compare the actual process and planned
process.
The schedule of the Project is under control due to the deadlines. The project team is
very strict about the team management planning. There are some specific days that the team
members come together and work on the project in every week. Sometimes, these meetings
are not enough. At these times, team members come together on weekends.
The milestones of the projects are predefined by the CTIS 455 Lecture’s Instructor, so
it is not possible to change the date of submission of any deliverables. The MONO members
cannot delay the dates. So, group members mark the milestones on their own calendars.
MONO also uses a Schedule Control Plan (SCP) (Appendix C) to measure and control
schedule progress. It is supply a vision of the current deliverable. Achievement and quality of
that deliverables will be evaluated by the consultant.
If the actual progress does not conform to the planned progress, a Schedule Control
Report (SCR) (Appendix D) will be prepared and submitted to the acquirer and subcontractor.
In this report schedule corrections will be defined.
5.3.3 Budget Control Plan
There is no need budget control plan because there is no budget allocated for the PS
project. The cost of the project depends on achievement of the schedule and deadlines and the
effort spend by the project group. Budget Control Report (Appendix E) will be prepared for
the acquirer by the Project Manager.
48
5.3.4 Quality Control Plan
Quality control plan will be applied all deliverables of the project. These deliverables
is controlled by both internal and external reviews which are defined in the WBS and
schedule allocation. Internal reviews will be made by the software development team and
external reviews will be made by the subcontractor.
After every review meeting, the software development team discusses the meeting
subjects, make the necessary reviews and update the product according to the subcontractor’s
corrections.
5.3.5 Reporting Plan
All of the reports which are prepared during the project phase prepared according to
the IEEE standards [1, 2, 3, and 4] and project schedule. These reports are Initial Plan,
Software Requirement Specification, Software Project Management Plan and Software
Design Document. MS Project 2003 and MS Word 2003 tools will be used for reporting.
On the other hand, the four control reports that are listed below will be used during the
project:
Change Request Form: This form is used when the acquirer wants new
requirements or any changes to the existing ones. More details can be found in
section 5.3.1.
Schedule Control Report: If there is any distortion from the actual progress, a
SCR will be prepared for the acquirer. The report is supplied by MONO
members using MS Project 2003. More details can be found in section 5.3.2.
Budget Control Report: If there is any distortion from actual cost, a BCR will
be prepared for the acquirer. The report is prepared by Project Manager using
MS Project 2003. More details can be found in section 5.3.3.
Schedule Control Plan Form: These reports are supplied by the MONO group
members after every meeting. More details can be found in section 5.3.2.
49
5.3.6 Metrics Collection Plan
The metrics to be collected, their units, and the frequency of collection are given in
Table13.
Metric Unit Frequency of Collection
Project Size* LOC During Initial Plan and SPMP
Effort Person. months During Initial Plan
Working Time Person. hours/day During Initial Plan and SPMP
Resource Cost US dollars ($) / During Initial Plan and SPMP

hour
Elapsed Time to hours After Review Meetings

Completion
Source LOC delivered LOC After coding & testing
Source LOC reused from LOC After coding & testing

libraries, etc.)
Source LOC modified LOC After coding & testing
Defects error/LOC After testing
Resource Allocation % Assigned task/ SPMP

total task
Risk Probability Percentage (%) SPMP
Remaining Work hour SPMP
Work complete Percentage (%) SPMP
Actual cost of work $ SPMP

Package
Duration day SPMP
Work hour SPMP
Table 10 Metrics Collection Plan
50
5.4 Risk Management Plan
Project risks are identified in Table 15. These risks can be monitoring during the
development of product or documentation. If these risks are occur, they will be evaluated in
team meetings. Because the project group is responsible to take correct decisions and perform
these decisions if the risks are become real.
Risks Category Probability Impact

(%)
Uncertainty in the format Process definition 90 Moderat
of PS file e
Development tool Staff experience 70 High
unfamiliar
Not enough time for SW Business impact 87 Moderat
integration e
Staff inexperienced Staff 72 High
Absentees of personnel Staff 75 High
could result in loss of effort
Design and coding Process definitions 70 High
deficiencies.
Expected technical changes Development 40 Moderat
environment e
Documentation Process definition 30 Moderat
e
May have to train the Staff 55 Low
trainer
Incorrect and missing Process definition 45 High
Work package definition
Optimistic schedule for Business impact 25 Low
HW/SW integration
Less reuse than planned Product size 25 Moderat
e
Customer may change Product size 20 Critical
requirement
Misunderstood and/or Product size 20 Critical
undetermined requirements
Process demands not Product size 15 High
adequately planned in
estimates
Inappropriate metrics Product size 18 Moderat
e
Table 11 List of Identical Risks
51
Probability Uncertainty Statement Evaluation

>80% Almost, certainly, highly, 5
likely
61 – 80% Probable, likely, probably, 4
we believe
41 – 60% We doubt, improbable, 3
better than even
21 – 40% Unlikely, probably not 2
1 – 20% Highly, unlikely, changes 1
are slight
Table 12 Probability Evaluation Criteria
Criterion Cost Schedule Technical

Low Less than 2% Slip 1 day Slight effect on
performance
Moderate Less than 4% Slip 2 days Moderate effect on
performance
High Less than 7% Slip 5 days Severe effect on
performance
Critical 7% or more Slip over 5 days Mission can not be
accomplished
Table 13Consequence Evaluation Criteria
52
PRIORITY Risk Scenarios Risk Alternatives / Monitoring

Resolutions
Environment: not Alternatives: Choose a work During the group
suitable for team environment that allows team meetings.
1 communication. communication.
Resolution: Optimizing the
environment situation.
Group deficiency: One Resolution: Other group Dead line is very

1 of the members is sick. members are over work. close.
Communication skill is Alternatives: Group will make Middle of the coding
4 not enough: In the code a meeting with customers. phase.
phase, the new
requirements will be
come.
The development tool is Alternatives: If project During the
hard to use. member is not enough implementation phase.
knowledge about development
tool, they will take a related
2 info from project training
coordinator.
Resolution: Before
implementation MONO team
will make mini projects with
development tool.
Table 14 Risk Management
5.5 Project Closeout Plan
A final report including lessons learned and analysis of project objectives achieved
will be prepared by the software development team.
The final deliverable documents that are IP, SRS, SPMP, and SDD will be submitted
to the consultant who is our Software Engineering lecture’s Instructor. The Project group will
hold an interview with project customer.
After the documents are accepted by consultant, the documents will be established in
the group’s web side. After all these process are completed at the end of the next semester
project group will make a demonstration of the product to the customer a few instructors.
Because this project is a part of fourth year students’ senior project.
53
6 TECHNICAL PROCESS PLANS
6.1 Process Model
The process model of the project is “Waterfall” model. All work activities of the Work
Breakdown Structure (Appendix A) includes major milestones, project deliverables of each
phase, reviews and schedules. The deliverables produced at the end of the each phase stated in
top level WBS items shall be the input for the next phase.
Initia SRS SPM SDD Coding

l P
Update Update Update Update Testing

d d SRS d d SDD
Initial SPMP
Plan
Product
Delivery
Figure 3 Process Model
6.2 Methods, Tools and Techniques
The waterfall methodology shall be used. .Net shall be the programming development
environment and user interface environment. Ms-SQL database management system shall be
used storing and processing data. The main tools to be used for documentation shall be
Microsoft Word 2003 for documents and Microsoft Project 2003 for project planning.
Microsoft Visio 2003 shall be used for ER diagrams, design diagrams and process models.
IEEE Std. 1058-1998, IEEE Standard for Software Project Management Plans; IEEE
Std. 830-1998, IEEE Recommended Practice for Software Requirements Specifications; IEEE
Std. 1016-1998, Recommended Practice for Software Design Descriptions will be used for
standardization of the documents .
6.3 Infrastructure Plan
During the development project group members shall use their own hardware and
software environments. The hardware used shall be minimum 512 MB RAM. Microsoft .Net
and Ms-SQL database management system shall be installed on computers of the group
54
members. Photoshop and MS Visio 2003 shall be used for analysis and design. Internet
Explorer shall be minimum IE 3.0. This project will be web based, so the network
infrastructure and speed is important. The system will be hosted by a Bilkent University
server. Because of the high quality network speed and infrastructure of Bilkent University,
users can reach the system very fast. Also, the response time of the system will be high.
6.4 Product Acceptance Plan
o The documents must deliver on predefined dates. Late submission will not be
accepted.
o Each project team must have “Project Web Site” to publish their deliverables
o The documents must be prepared according to the IEEE Standards.
o The each documents shall be updated and established after the consultant is
reviewed the documents.
o The product shall be demonstrated to the customer and instructors at the end of
the semester.
o The acceptance criterion is the customer’s and the instructors’ satisfaction with
that demonstration. However, the product which is not work correctly will not
be accepted.
7 SUPPORTING PROCESS PLANS
7.1 Configuration Management Plan
The configuration manager is responsible to manage different versions of the work

products, control the changes that are imposed and audit and report on the changes that are
made. S/he will also update the project’s web page regularly. In our project, two people who
are identified in Table 3 Roles and Responsibilities are responsible for this duty. The
documents and new version documents are controlled lastly and established by them.
7.2 Verification and Validation Plan
All group members are responsible for verification activities. Validation is the process
of making sure that the product is being built correctly. At the completion of each milestone, a
validation analysis should be done. The validation will be performed by group member during
internal reviews to make sure that the delivered products are right. A demonstration of the
55
user interfaces to the acquirer will be made for validation.
All the testing activities are under the test team members’ responsibilities. There will
be two types of testing. One of them will be done after coding of each part; the other will be
done before publishing of the web site.
Goals of Verification and Validation:

1. Enhancing product through cost-effective, timely detection of defects
2. Promoting personal growth and communication among software development
professionals
3. Fostering teamwork professionalism, participatory decision-making, and high
morale
4. Improving ability of reviews to prevent defects in their own work
5. Enhancing the effectiveness of testing by detecting errors prior to testing
6. Find errors, not fix them
7.3 Documentation Plan
The configuration manager is the responsible person to publish all the deliverables via
web. All the deliverables will be prepared by group members. The demonstration of the
product and final product will be done by group members. Documentation schedule is seen at
Table 15.
56
Version Who Will Prepare Due Date Document Name
Initial Plan V1.0 17 October 2006 Initial Plan
Initial Plan V 2.0 Review Initial Plan Revision

11 November 2006
Report
SRS V .1.0 18 November 2006 SRS
PROJECT GROUP
SRS V 2.0 Review - November 2006 SRS Revision Report
PROJECT GROUP
SPMP V1.0 30 November 2006 SPMP
SPMP V 2.0 Review - December 2006 SPMP Revision Report
SDD V1.0 20 December 2005 SDD
SDD V 2.0Review - December 2005 SDD Revision Report
DEMO Demonstration of
May 2006
Product
USER MANUAL May 2006 User Manual
PHARMACY SYSTEM May 2006 Final Product
Table 15 Documentation Schedule
7.4 Quality Assurance Plan
For quality assurance plan, review and configuration management methods will be
used. The project team will make both internal and external meetings. In internal meetings,
only team members will be in that meeting and they will make plans about their deliverables
deadlines. In external meetings, the project team will meet via customer, supervisor or
instructor to get the requirements. In these meetings team members will take notes to provide
that the deliverables are correct and meets the requirements specifications in SRS report. The
configuration manager will arrange these external meetings.
7.5 Review and Audits Plan

The acquirer-supplier reviews will be performed after the initial plan, the SRS, and
SPMP to ensure that the acquirer's requirements are satisfied. All the members of the team
members will participate in these reviews. Internal reviews and reviews between Software
quality team and team members will be done for verification and validation purposes. The
schedule of the internal reviews will be done during all the phases of the project and all the
members of the team members will participate in these reviews.
57
Before the delivery of each document, team members will have a meeting about the
existing document. These meetings are identified in 5.2 Work Activities section. Project
group is review the document lastly. If some corrections are necessary, these are made during
these meetings. After the document is established, the consultant examines the documents and
adds some comment to correct the fault. Then group members correct the faults and
established again with second version.
7.6 Problem Resolution Plan
None, problems would be resolved informally between the developer, the advisor and
the team members.
7.7 Subcontractor Management Plan
Subcontractor reviews the deliverables and highlights the points those need
corrections in order to improve the quality of the product and documentation.
58
8 APPENDIX A – Project Plan
59
60
61
APPENDIX B – Change Request Form
CHANGE REQUEST
FORM
Document Name:
Version No:
Section(s):
Identification No :
Proposed Change: Date:
Current Condition:
Proposed Change:
Change Information
Change Control Number:
Cost Impact:
Timing Impact:
Quality Impact:
Scope Impact:
Other Impact:
Change Review Information
Signatures
Follow up
Documentation Updated:
62
APPENDIX C – Schedule Control Plan Form
SCHEDULE CONTROL
PLAN FORM
Document Name: Version No:
Interview With The Acquirer:
Meeting Date Meeting Time Meeting Place
Works:
Submission Date:
Revised:
Revision Date:
Additional Information:
63
APPENDIX D – Schedule Control Report,
SCHEDULE CONTROL PEPORT
Task Name :
Identification No : Serial No of change :
Date of Control:
Authority seeking change :
Action Officer :
Proposed change : Date proposed change :
Action(s) Taken:
Approval authority
Project Management signature :
64
APPENDIX E – Budget Control Report
BUDGET CONTROL REPORT
Task Name :
Identification No : Serial No of change :
Date of Control:
Authority seeking change :
Action Officer :
Proposed change : Date proposed change :
Action(s) Taken:
Approval authority
Project Management signature :
65

Pharmacy System (PS) : Software Project Management Plan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pharmacy System (PS) : Software Project Management Plan

Uploaded by

Copyright:

Available Formats

SOFTWARE PROJECT MANAGEMENT PLAN

Due Date: 17 November

This document provides the Software Project Management Plan of PHARMACY

PS Software Requirement Specification report is prepared according to IEEE Std. 830-

6.3 Infrastructure Plan ............................................................................................................... 54

1.1 Project Summary

1.1.1 Purpose, Scope and Objectives

The purpose of the software requirements specification is to produce a list of

Pharmacy System (PS), which is a project with a goal of creating a web-based

Objectives and goals of this project:

1.1.2 Assumptions and Constraints

 PS will be developed by four students in CTIS as a part of Senior Project hence

1.1.3 Project Deliverables

1.1.4 Schedule and Budget Summary

Due Date Document Name

17 October 2006 Initial Plan

November 2006 Initial Revision

November 2006 Initial Revision Plan

18 November 2006 SRS

November 2006 SRS Revision

November 2006 SRS Revision Report

30 November 2006 SPMP

December 2006 SPMP Revision

December 2006 SPMP Revision Report

December 2006 SDD Revision

December 2006 SDD Revision Report

January 2007 Starting the Coding

March 2007 Finishing the Coding

March 2007 Detailed Design

May 2007 Demonstration of Product

May 2007 User Manual

May 2007 Delivery of Final Product

Table 1 Schedule of the Project

1.2 Evolution of the Plan

Due Date Document name

17 October 2006 Initial Plan

11 November 2006 Initial Revision Plan

18 November 2006 SRS

Table 2 Evolution of the Plan

3 DEFINITIONS & ABBREVATIONS

Project Deliverable: A work product to be delivered to the acquirer

4.1 External Interfaces

Acquirer: CTIS Instructor Symed Amjad Ali.

Customer: CTIS Instructor Neşe Şahin Özçelik.

Subcontractor: Software Engineering Instructor Beyhan Akporay.

Figure 1 External Interfaces

4.2 Internal Structure

Software Training Software Software

Figure 2 Internal Structure

4.3 Roles and Responsibilities

Name E-mail Roles and Responsibilities

Table 3 the Roles and Responsibilities

Programmer: will write the code of the system.

DB Administrator: will be responsible from database configuration and management.

User interface designer: will design the web-based user interfaces.

5 MANAGERIAL PROCESS PLANS

5.1 Start-up Plan

5.1.1 Estimation Plan

 Drug Stock Input-Output Information Delete

External Interface Files:

Internal Logical File:

In Table 4, the Degree of Influences (DI) is shown:

Table 5 Degree of Influences