1.

Introduction

This project is aimed to solve the problems of customers that

have been stated in the previous document. Clients of Filwuha
spa enterprise will be able to view the organization’s services
schedules and be able to reserve for services using this
application which is simple, fast, user friendly, secured, accurate
and complete electronic reservation system. It works on different
web browsers and operating systems. The core purpose of the
system is to increase efficiency, profitability and quality of
services of filwuha spa enterprise to ensure customer satisfaction.
The project incorporates the following major work activities:
• Studying feasibility of the proposed solution.
• Eliciting and analyzing customers’ requirements; to develop
requirement analysis document.
• Converting users’ requirement to high and low level design
specifications
• Developing and implementing workable product.
• Preparing administrative & user manuals and test plan
documents
2. Project resources

The resources for this project are primary data sources that are
found from the organization document review. Resources that can
be used for the requirement Elicitation and facilitate the design
process, organization employee that can help the project by
assisting us in the requirement analysis endeavor and the other

1
resource for the project include pc’s, application soft wares for the
development process.

3. Project organization

3.1. Process model

The life cycle model of the project is WATER FALL MODEL because
each phase’s product will be checked by the team members as
well as our advisor every phase will be well documented, and
each phase is preceded after securing approval of previous
phase. However; it will not be strictly following pure water fall
model as pure water fall model assumes that no defect is
introduced during any of the phases of the life cycle, which is
impossible in practical development environment as it may have
several iterations. Hence the model adopted will be Iterative
Water Fall Model.
In order to clearly visualize the process model of project, phases
and items are described in table 1.1:

2
Table 1.1: Project Process Model Description
Phases Requirement System Coding Documentation
Items s Elicitation Design
and Analysis
Activitie • Stating • Stating • Coding • Preparing User
s purpose, Design • Integrati Manual
scope and goals on • Preparing
objective of Administrative
the project Manual
• Stating • Reviewing
overview of current
current architectu
system re
• Defining • Developin
functional g
and proposed
nonfunction software
al architectu
Requiremen re
t

Inputs Interview RAD SDD Executable Program

Results
Observation
result
Delivera RAD SDD Source User and
bles Code & Administrative
Executable Manual
Program
Mileston Approved Approved Executable Program
e RAD SDD

3
3.2 Team organization and communication plan

Team organization: the team for this project is composed of four

students. The organization is horizontal and decentralized
because all of us work equally with the same level of
responsibility and we needn't assign project manager but this
implies that there will be a short term manager for each phase
our communication will be horizontal with the same level of
responsibility due to the level of complexity of the project. For
data gathering and a company's employee for the requirement
analysis assistance.

Table 3.1 Reporting and communication plan for the

project:
Report From To
Project report(RAD, SDD, Team Project advisor
SPMP) members
Status Report Each Member Respective Team

4
 Leader
Team Leader Team members

3.3 Project deliverables

During the course of this project, several documents and system

deliverables will be produced. The type of product (source code
and setup programs) the production and implementation will be
done electronically; while the form of documentation and
delivery will be through (hard copy). Accordingly the following
documents and products should be delivered:
• Requirements Analysis Document (RAD)
• System Design Document (SDD)
• Source code and executable program
• Software Project Plan (SPMP)

3.4. Risk analysis and management

Risk is anything (expected or unexpected) that happens through

the course of the project and may endanger the successful
completion of the project and as any software development
project our project will likely face potential risks (both general and
project specific). In our project we will use proactive approach
that is to develop risk list with associated impact rating and
mitigation plan.

In order to efficiently meet the risks and minimize their impact we

5
shall do the following tasks.

 Identifying and Reporting potential risks that may arise

during the course of the project;

 Maintain and monitor a risk mitigation action plan

Monitor;

 Designing risk management processes;

 Assessing risk management processes;

 Prioritize and manage risks;

 Facilitating the identification and evaluation of risks;

Impact rating

4. Catastrophic

3. High

2. Moderate

1. Low

Risk list

The possible risks that would arise during the whole course of the
project include.

Risk-1. Not all of the group members are well equipped with the
system design and implementation tools like HTML, JavaScript,
UML and PHP which might create problem in the system
development endeavor. (Category general, impact catastrophic
6
probability 30%)

Mitigation plan: For this risk; we plan to overcome it in such a

way that team members with better acquaintance of the above
tool would help the others with the problem and team
members are assigned a task which they are best in.

Risk-2. The short time schedule that we are given might be a

problem in the process of gathering the necessary requirements
that needs to be analyzed in order to fix the problems. We plan to
move as fast as we possibly can to solve this problem. (Category
general impact high probability 50%)

Mitigation plan: To overcome this problem team members

are required to complete their assigned task according to
the scheduled time and if possible ahead of the schedule. As
a team, members meet regularly to assess the status of the
project this will minimize the risk.

Risk-3.Natural risks like health problems to group members might

cause delay we will be solving this kind of risk by covering each
others back in case of such happenings. (Category general,
impact moderate probability 20%)

Mitigation plan: in such cases the only solution will be

other team member will cover for each other

Risk-4.User willingness to be fully committed to the requirement

gathering the successful completion of the project.(category
project specific, impact high probability 10%)
7
 Mitigation plan: For the fourth risk we will try to
encourage the users to fully participate in the project and
convince them that the system is finally for their use.

Risk-5.The management willingness to full support the system

development endeavor. (Category project specific, impact high
probability 10%)

Mitigation plan: to convince the management team of

the importance of the project to get the best out of the
management team

Risk-6.Unexpected addition of requirements or features after the

requirement phase is completed. (Category general, impact high
probability 40%)

Mitigation plan: For this risk we will try to overcome the

risk by clearly defining the requirements before jumping to the
design phase.