bsit-4110.weebly.combsit-4110.weebly.com/.../1/6/5/...system_document.docx · web viewproject...

1.0PROJECT BACKGROUNDA computerized facilities management system, the clients invests in

computerized facilities management software. Computerized facilities

management system allows you to process your entire normal facility task via a

computerized system, rather than by hand. Like different word processors or

other computer programs, they largely offer the same types of features with

slightly different interfaces.Facilities management helps an organization’s

business and profits. It takecare of asset of property their maintenance and

minimizing the risks and alsoreduce the loss upon physical product.The

organization should provide facility to their employee because indirectly they

serve toguest only and help increasing revenue. It helps employees to work

efficiently by providing work friendly environment and reducing wastages and

hence increasing its profitability of an organization.

1.1Problem\Opportunity Description Maintenance management

- Poor and improper building maintenance will definitely cause more

damages and costly repair works if left unattended. System will provide a

maintenance checklist to regularly monitor all the equipment’s of the hotel

and avoid the destruction of equipment.

Report generation

- The organization couldn't track requests, and required heavy manual work

to generate reports with information on the number and type of requests,

to analyse service level agreements (SLA) compliance.

Asset management

- System will manage all the assets of the hotel, it will provide the security

and tracking of facilities, rooms and equipment’s inside and outside in

hotel it is also notify the housekeeper for cleaning the hotel.

- List of rooms;

Standard room, deluxe room and family room

- List of facilities

Hotel Facilities Management System

Kitchen, parking lot, laundry, spa, pool, gym and all equipment of hotel

1.2Benefits Both customers and administrations will benefits include the following:

- Manage, track, and maintain all work performed on your facilities,

buildings, and equipment.

- Configurable automated processes to generate preventive maintenance

work orders at the appropriate time, based on a time-based schedule.

- Track space standard compliances, room availability and occupancy rates,

in a single building, property, across the entire portfolio.

- Support for routine inspection and assessment of the condition of each

building system. Collect, analyse, and report on the condition of the entire

facility.

- Keep interruptions, system failures, and safety incidents to a minimum

The Researchers benefits are the knowledge that learned in the project and for

the future researcher they get an information and guide to make their project.

1.3Goal To help the customers and administrations ensure the organization's assets are

fully utilized at the lowest possible cost, while providing benefit to every phase of

a building's lifecycle.

To support operational.

And strategic facility management, i.e. all of the activities associated with

administrative, technical, and infrastructural FM tasks when the facility or building

is operational, as well as the strategic processes for facilities planning and

management.

1.4Stakeholders and client

Company


- this project can benefit them to solved their problem and issues regarding

the facilities management issues in their company, it greatly helped the

proposed protect to be successfully created

The group

- this project them got involved in working as a group and searching for the

right information by analyzing and knowing the better alternatives in

creating the proposed system

Professors

- they got involved in teaching the group and correct and analyze problem

by providing knowledge in programming and project management

Client/Customer

- who used the facilities management system

Future researcher

- Involved in searching the system or the company who used the system.

Thru the project they get an information that help to build/guide to their

project.


2.0 PROJECT SCOPE

2.1 Objectives

WORK BREAKDOWN STRUCTURE (WBS)

2.2 Deliverables

Objective 1-Asset Management

Project Deliverables Work Products/Description

Facilities InformationThis is all the information about the facilities listed in the

hotel, The details view of facilities.

Equipment InformationThis section can view all the information about the

equipment’s used in the hotel.


Asset Management

Report generation

Work Order Management


Work Order Request

Room Availability

report

Cost request

Facilities Information

Equipment Information

Facility Maintenance Management Equipment

Facilities Condition

Equipment Condition

Checklist report

Work Order

Work Order Charges

Material/Item request

Objective 2-Facilities Maintenance Management Equipment


Facilities Condition

This is where all the information about the rooms, facilities

listed, this help to properly maintain the usability of the

rooms, facilities inside and outside of the hotel.

Equipment Condition

Equipment Condition Monitor reduces unscheduled

downtime by predicting and preventing critical equipment

failures and diagnosing the root causes of poor

performance.

Checklist report

This section generates a paper of checklist for rooms,

facilities and equipment’s for daily checking. This help to

properly monitor the assets of the hotel.

Objective 3-Work Order Management



Work Order RequestIn this section guest or client can request to the maintenance

to repair the defective equipment.

Work Order The customer will receive a work order number for tracking

and follow up purposes along with the shop assigned the

repair. The supervisor will assign the job to the appropriate

staff that will in turn contact the requester and perform the

service work. A customer response tag will be left for the

requestor in order to communicate the status of the job.

After the work order has been completed and closed out,

Facilities Operations will send out at random, Customer

Satisfaction Surveys to help ensure that the customer is

receiving quality service in a timely manner.

Work Order Charges This section you can add charges to a work order whenever

you issue parts and materials to the work order.


Room Availability Report This report give to the front desk to inform them about the

status of the facilities and rooms, it indicates if the room is

clean, if all the items are good and complete, and if the


equipment’s are working.

Cost Request

This report give to the front desk to request for money to buy

the item that the customer consume every day like

toothpaste, soup, shampoo, toothbrush etc.

Material/Item Request This request gives to the procurement if there are

equipment’s that are not functioning properly.

Objective 4- Report Generation

2.3Out of Scope

Parking Lot MonitoringThe parking lot monitoring, this is out of scope. Our system will cannot monitor or

track the availability of parking lot outside of the hotel, unless it related in

Facilities management background.

3.0 Project Plan

3.1 Approach and Methodology

Conducting research, to find information about the system we have and help

to get ideas for our system.

Conduct interview to obtain information about the system of the company, to

know what problems they encountered, and also to have an idea on how to

solve that problem based on the information we got.

Conducting survey, to know the common problems of the company’s system,

whether it is computerized or manual, we prioritize the most serious problem

they encountered based on the survey we did.

Brainstorming, sharing information and knowledge about the system to

improve the project quality.


3.2 Project Timeline

ID Task Name Date Start Finish Duration

1 Chapter 1 Project charter

21. Project Background

June25 11:00

am

7:00

pm

8 hrs.

31.1. Problem / Opportunity

Description

June25 11:00

am

7:00

pm

8 hrs.

4

1.2. Benefits

June 25 11:00

am

7:00

pm

8 hrs.

5

1.3. Goals

June25 11:00

am

7:00

pm

8 hrs.

6 1.4. Stakeholders and Clients June 25 11:00

am

7:00

pm

8 hrs

7 2. Project scope June 25 11:00

am

7:00

pm

8 hrs.

82.1. Objectives

June 25 11:00

am

7:00

pm8 hrs

92.2. Deliverables

June 25 11:00

am

7:00

pm8 hrs.

102.3. Out of Scope

June 25 1:00

pm

5:00

pm4 hrs.


Encoding of Project Background July 2 1:00

pm

7:00

pm6 hrs.

123. Project Plan

July 2 1:00

pm

7:00

pm

6 hrs.

133.1. Approach and Methodology

July 2 1:00

pm

7:00

pm

6 hrs.

143.2. Project Timeline

July 2 1:00

pm

7:00

pm

6 hrs.

153.3. Success Criteria

July 4 2:00

pm

7:30

pm

7 hrs.

163.4. Issues and Policy Implications

July 4 2:00

pm

7:30

pm

7 hrs.

173.5. Risk Management Plan

July 4 2 :00

pm

7:30

pm

7 hrs.

183.6. Service Transition

July 4 2:00

pm

7:30

pm

7 hrs.

193.7. Option Analysis

July 4 2:00

pm

7:30

pm

7 hrs.

Encoding of Project Background July 5 10:00

am

1:00

pm

3 hrs.

4. Technical FeaturesJuly 5 10:00

am

1:00

pm

3 hrs.


Encoding of Project ScopeJuly 5 10:00

am

1:00

pm

3 hrs.

5. Project Organization and Staffing July 7 10:00

am

1:00

pm

3 hrs.


am

1:00

pm

3 hrs.

6. Project BudgetJuly 9 1:00

pm

5:00

pm

4 hrs.


pm

5:00

pm

4 hrs.

7. Appendix A – Additional InformationJuly 10 1:00

pm

2:00

pm

1 hrs.

Submission of chapter 1Julyb12- 13

6:00

am

12:00

pm

18 hrs.

Revision of chapter 1 and submission of chapter 2

July 27 onwards

6:00

am

6:00

pm

1 week

Chapter 2: Related Studies and SystemsAug 6 11:00

am

6:00

pm

7 hrs.

1.1. Foreign StudiesAug 6 11:00

am

6:00

pm

7 hrs.

1.2. Local Studies Aug 8 11:00 6:00 7 hrs.


am pm

1.3. Synthesis and Relevance to the Study (Matrix – Comparative Analysis)

Aug 9 11:00

am

1:00

pm

2 hrs.

Revisions of Chapter 2

Chapter 3: EIS Project Management and Development

August

8-14

3.1. Risk Mitigation, Monitoring and Management Plan

Aug 13

August

15

1.0. Introduction11:00

am

6:00 pm

7 hrs

1.1. Scope and Intent of RMMM Activities

10:00

pm

7:00

am

9 hrs

1.2. Risk Management Organizational Role

10:00

pm

7:00

pm

9 hrs

2.0. Functional Data Description

10:00

pm

7:00

pm

9 hrs

2.1. Risk Table

2.1.1. Description of Risk M

2.1.2. Probability and Impact for Risk M

Encoding of RMMM Plan 10:00

pm

7:00

pm

9 hrs

3.0. RMMM


August 20

3.1. Risk Mitigation for Risk M

12:00

pm

8:00

pm 8 hrs

3.1.1. Business Impact

3.1.2. Customer Risk

3.1.3. Employee Risk

3.1.4. Financial Risk

3.1.5. Process Risk

3.1.6. Product Size

3.1.7. Technical Risk

3.1.8. Technology Risk

3.2. Risk Monitoring for Risk M

august 22

august 27

11:00

am

7:00 pm

6hrs3.2.1. Business

Impact


11:00

am

6:00 pm

7 hrs



3.2.5. Process Risk

3.2.6. Product Size



3.3. Risk Management for Risk M


august 27

10:00

am

7:00 pm

9 hrs

3.3.1. Business Impact




3.3.5. Process Risk

3.3.6. Product Size



4.0. Special Conditions

Encoding of RMMMAug 29 10:00

am

7:00 pm

9hr

3.2. Software Configuration Management Plan (Riña)

Aug 29 10:00

am

7:00 pm

9 hrs

1.0. Introduction

1.1. Scope and Intent of SCM Activities

1.2. SCM Organizational Role

2.0. SCM Task

2.1. Identification

2.1.1. Description

2.1.2. Works Products & Documentation


Aug 29 10:00

pm

7:00 pm

9 hrs

2.2. Configuration Protocol

2.2.1. Description

2.2.2. Increasing Version Number


2.3. Configuration Status Accounting (CSA)

2.3.1. Description


3.0. Software Quality Assurance Overview

Aug 29 10:00

am

7:00 pm

9 hrs

Scope and Intent of SQA Activities

Reviews and Audits

3.1. Generic Review Guidelines

3.2. Formal Technical Reviews

3.3. SQA Audit

3.4. Problem Reporting & Corrective Action / Follow-up

3.4.1. Reporting Mechanism

3.4.2. Responsibilitie


s

3.4.3. Data Collection and Valuation

Encoding of SCM PlanAug 29 10:00

am 7:00

Pm

9 hrs

3.3. Software Quality Assurance Plan

Sept 1 9:00

am

1:00 pm

3 hrs

1.0. Introduction

1.1. Scope and Intent of SQA Activities

1.2. SQA Organizational Role

2.0. SQA Task

2.1. Task Overview

2.2. Standard, Practices & Conventions (SPC)

2.3. SQA Resources

2.3.1. Description


3.0. Review and Audits

3.1. Generic Review Guidelines

3.2. Formal Technical Reviews

3.3. SQA Audits

4.0. Problem Reporting and Corrective Action / Follow-


up

Sept 7

12:00

pm

8:00 pm

8 hrs

4.1. Reporting Mechanism

4.2. Responsibilities

4.3. Data Collection and Valuation

4.4. Statistical SQA

5.0. Software Process Improvement Activities

5.1. Goal and Object of SPI

5.2. SPI Tasks and Responsibilities

Sept 8 7:00

am

5:00 pm

10hrs6.0. Software Configuration

Management and Overview

7.0. SQA Tools, Techniques, and Methods

Encoding of SQA Plan

3.4. System Specification

1.0. Introduction

1.1. Goals and Objectives


Sept 4

Sept 4

7:00am

7:00am

3:00pm

3:00pm

1.2. System Statement of Scope

1.2.1. Version 1 General Requirements

1.2.2. Version 2 General Requirements

1.2.3. Extended Enhancement Request

1.3. System Context

1.4. Major Constraints

2.0. Functional Data Description

2.1. System Architecture

2.1.1. Architecture Model

2.1.2. Current Subsystem Overview

2.2. SQA Resources

2.2.1. Major Data Objects

2.2.2. Relationships

Human Interface Description


3.0. Subsystem Description

Sept 4 7:00am 3:00pm

3.1. Subsystem Flow Diagrams

3.1.1. Create Checklist

3.1.2. Print Checklist

3.1.3. Generate Letter

4.0. Enhanced Interface Prototyping


4.1. Prototyping Requirements


3.5. System Requirements Specification

Sept 4 6:00pm 8:00p

1.0. Introduction



1.2.1. General Requirements

1.2.2. Extended Enhancement

1.3. System Context


2.0. Usage Scenario


m2.1. Read Only Users

2.2. Read/Write/Modify Own Users

2.3. Read/Write/Modify All Users

2.4. Full Control Users

3.0. Data Model and Description

3.1. Data Description

3.1.1. Data Objects and Dictionary

3.1.2. RelationshipsSept 4 6:00pm 8:00p

m

4.0. Functional Model and Description

Sept 4 9:00pm 11:00pm

4.1. Subsystem Flow Diagrams

4.1.1. Create Checklist

4.1.2. Print Checklist

4.1.3. Generate Letter

4.2. Human Interface

5.0. Restrictions, Limitations and Constraints

6.0. Validation Criteria

Encoding of SRSSept 4 11:00pm 11:30

pm


3.6. System Design Specification

(Ramirez)

Sept 5 Sept 5 Sept 5 Sept 5

1.0. Introduction

Sept 5

Sept 5

12:00

Am

12:00

am

2:00 am

2:00 am



1.2.1. General Requirements

1.3. System Context


2.0. Data Design

2.1. Database Description

3.0. Architectural and Component-Level Design

3.1. Program Structure

3.1.1. Overall

3.1.2. Create Inspection

3.1.3. During Inspection

3.1.4. Post-Inspection

3.1.5. Approval

3.2. Description for Components

3.2.1. Switch User


Sept 5

2:00am 5:00 am

3.2.2. Facility

3.2.3. Create/Modify Inspection – Step 1

3.2.4. Create/Modify Inspection – Step 2

3.2.5. File Result – Step 1

3.2.6. File Result – Step 2

3.2.7. Approval

3.2.8. Checklist Maintenance

3.2.9. Letter Maintenance

4.0. User Interface Design

Sept 5 7:00am 9:00am

4.1. Description of the User Interface

4.1.1. Screen Images

Login Screen

Search Pages

Approval Queue

4.1.2. Objects and Actions

Menu Items

4.2. Interface Design


Rules

4.3. Components Available

4.3.1. Intrinsic Controls

Sept 5 7:00am 9:00am

4.3.2. ActiveX Controls

5.0. Restriction, Limitations and Constraints

Sept 5 10:00

am

12:00pm

Time

Employee Skills

Insufficient Resources

6.0. Testing Issues

6.1. Classes of Test

6.2. Performance Bounds

6.3. Identification of Critical Components

7.0. Appendices

3.7. Test SpecificationAug 26 8:00

pm

3:00

am

1.0. Introduction

Aug 26 8:00

pm

3:00

am


1.2. Statement of Scope


2.0. Testing Plan


Sept 5

3:00 pm

2.1. Software (SCIS) to be Tested

2.1.1. Interfaces

2.2. Testing Strategy

2.2.1. Unit Testing

2.2.2. Integration Testing

2.2.3. Validation Testing

2.2.4. High-Order Testing

2.3. Testing Resources and Staffing

2.4. Test Record Keeping

Sept 5 12:00 pm 2:00 pm

2.5. Testing Tools and Environment

2.6. Test Schedule

3.0. Test ProcedureSept 3 12:00 pm 7:00

pm

3.1. Software (SCIS) to be Tested

Sept 312:00 pm 7:00p

m

3.2. Testing Strategy

3.2.1. Unit Testing

3.2.2. Integration Testing

3.2.3. Validation Testing

3.2.4. High-Order


Testing

3.3. Testing Resources and Staffing

3.4. Test Record Keeping and Log

3.3 Success Criteria

Deliver on time and on budget.

Established by the customer at the beginning of the project and listed in order

of priority.

Directly related to and supported by business goals.

Able to provide the basis for critical decision-making throughout the project.

The basis on which the product will be accepted by the customer at the end of

the project.

Measurable.

3.4 Issues and Policy Implications

One of the members of the group makes its own work not as a group

Misunderstanding of the group task

lacking the knowledge to accomplish its own task

Lack of equipped so there is one in the group had not done the task

3.5 Risk Management Plan

Risk FactorProbability

(H-M-L)

Impact

(H-M-L)Risk Management Action


Em

ploy

ee R

isks

Lack of training and

experienceH H

Monitoring and managing of

this risk will include looking out

for each other, that is if some

team-member is having

difficulties in performing some

tasks or using particular tool or

technique other members of

that team will help him out. This

is where teammembers may

have to spend little time with

each learning or teaching what

others know. If team member

lacks ability to use certain

programming language or

application, other team

members will take some time

off to teach the team member

basics related to that

application.

Pro

cess

Ris

k

Low product qualityH H

We want quality of the product

to be as high as possible. To

achieve this we will set up

guidelines to be followed for

each of the team members

during all the phases of the

software development cycle.


Pro

duct

Siz

e

Where size

estimates could be

wrong

M H

After careful monitoring of the

process, if we still end up with

underestimation of the FP, we

will put more man-hours into

the project. This is the only way

that we think we can manage

the risk.

Dev

elop

men

t Ris

k

Insufficient

ResourcesM M

If the necessary tools are not

provided to all of the team

members, their work will lack

quantity and quality. We will

make sure that the budget

includes cost for latest

technology and tools needed to

achieve the desired product.

Cus

tom

er R

isk

Customer may fail

to participateM M

If the users of the product fail to

participate during the different

phases of the software

development we fail to

recognize problems with the

software. To avoid this we will

try to meet the costumer

frequently and present software

in phases so that costumer and

we can have better

understanding the software

being developed.


Tech

nolo

gy R

isk

Obsolete

technologyL M

To avoid risk of using

technology that may become

obsolete in few years after the

product have been developed.

We will do excessive research

on what technology to use for

software development and will

use the latest technology

(programming language etc.) to

avoid this risk.

Bus

ines

s Im

pact

Product may harm

businessL L

In this risk category we

concerned about the quality of

the final product. We will spend

more time with the users to

understand their needs. This

way we can gather all the

information necessary for the

project to be successful. We

will try to understand business

environment and can try to

provide the user with help in

defining software requirements.

3.6Service Transition Assisting the employee in using the software, Users will be more convenient in

using the system if it has knowledge in using we will give the users a guide in

order to use the software correctly.

3.7Options Analysis


Since we use java language for front-end, we have optional suggestion that the

company can use to enable the system. You can use any Java language, like

Eclipse, any version of netbeans and etc., just java only. And for back-end also

you can choose SQLyog, MySql and other use for back-end.

4.0Technical Features Accurate in terms of monitoring the facilities

House keeper can easily inform if they already need to check the rooms, system

can provide their schedule in an easiest and simplest way to perform their task.

Availability of rooms

It’s much easier to know if their vacant rooms, unlike with the old system theirs a

high possibilities that an error will occur.

Security of files

The company can rest assure that the files are secured because it is in the

database they can also make an back-up on it, unlike in old system they only

compile their data inside a cabinet, and that’s is not a better place for it.

5.0 PROJECT ORGANIZATIONS AND STAFFING

ROLE RESPONSIBILITIES

Project Sponsor Serve as ultimate authority / responsibility for the

project

Provide strategic direction and guidance

Approve changes to scope

Identify and secure funding

Project Adviser Make business / approach decisions for the project


Participate in key activities

Make resources available

Approve work products, address issues, and

approve change requests

Project Manager Report to and receive direction from sponsors

Manage, review, and prioritize project work plans

Provide status reports

Manage project team

Recommend changes, escalate issues, and

mitigate risks

Lead Programmer Manage the application in creating the system

Provide information about the development of the

system

Manage the development of the system

Business Analyst Providing the rules in developing the documentation

and system

Managing the gathering of data’s

Organize and design the process

Assessing the business model and its integration w/

technology

Someone who analyzes an organization(real and

hypothetical) and design its processes and

systems, assessing the business model and its


integration with technology.

System Analyst Provide information about the process of the system

Manage the system process

To help organizations understand the challenges

before them to make this transition and to ensure

that needs and expectations of the client are

represented correctly in the final solution.

Document Specialist Mange the paperwork’s

Report about the development of documentation

Creating effective information

Documents not only paper based information but

also online context and multimedia

Evaluate the result

6.0PROJECT BUDGET

Budget Description Budgeted Costs

One- Time Costs

Project Study BookA book that serves as manual or guide to help in making a documentation.

1,500.00

Company Letter It is used for conducting an interview to the Company 5.00 Per Copy

Total One- Time Costs 1,505.00

Ongoing CostsFood and Drinks Foods and drinks that we will

be using in overnight activities

100.00 Per Meeting


Transportation To transport in the working area

600.00

Weekly Fund The fund that will be using in next semester

50.00 Per week

Hard Bond paper Use for the documentation 270.00 per ream

Total Ongoing Costs 1,020.00

CHAPTER 2 - REVIEW THE RELATED SYSTEM

2.0 INTRODUCTION

Facility management is an interdisciplinary field devoted to the coordination of

space, infrastructure, people and organization. The studies of different facilities

management of hotel give us information of what are we lacking off, knowing the

different between hotel facilities management gives us the opportunity to create a

unique system process and to make a new system that can be satisfied the needs of a

hotel in terms of facilities management.

2.1 LOCAL STUDIES

2.1.1

Name of system: JINISYS Software Inc.

Author: jinisyssoftware.com

Date published: PublishedDecember 13, 2013

URL: http://jinisyssoftware.com

Identity:

Jinisys Software Inc. is a Filipino-owned company and was established due to

the market demands on software applications on the Philippine market. Jinisys

Software offers property management systems for hospitality, real estates and

related industries. The company has also delivered turn-key application


development to more than a hundred companies and businesses all over the

Philippines since 2008.

Features:

Generate reports.

Member level access

Seamless integration with common desktop utilities.

Native data integration facility

Back-Up Schedule

2.1.2

Name of system:Facilities Management eXpress (FMX)

Author:gofmx.com

Date published: 2012

URL:https://www.gofmx.com/features

Identity:

Facilities Management eXpress (FMX) was formed to create software which

helps people solve everyday communication and scheduling problems for their

facilities, equipment maintenance, and transportation. The easy-to-use FMX web

application was created out of necessity when one of the country's leading

engineering firms searched everywhere for software to manage a recently

completed energy project and couldn't find anything that met their needs. With

necessity being the mother of invention, FMX was developed. After extensive

user testing, FMX was released in 2012 to rave reviews.

Features:

Work Orders

Planned Maintenance

Event Scheduling

Transportation


Asset Management

2.1.3

Name of system:eRPortal

Author:eRPortal Software Group

Date published:Oct. 4, 2011

URL:www.erportalsoftware.com

Identity:

The eRPortal Software Group provides enterprise asset management and

materials management software products and SaaS applications that enable

companies to optimize operations, maintain assets and infrastructure, and

manage all related materials, resources, and logistics. The software has been

developed with an architecture that provides customers a solution that is

exceptionally easy to use; with an interface that is configurable based on an

individual’s daily tasks and organizational role. eRPortal has customers in

multiple market segments and has developed lasting business relationships with

Fortune 500 corporations, municipalities and utilities across the country, and the

nation’s most prestigious educational institutions.

Features:

Asset Tracking


Preventive Maintenance

Report & Analysis

Cost of Ownership

2.1.4

Name of system: rosmiman facilities

Author: Rosmiman Asset Management

Date published: Feb. 21, 2011


URL: www.rosmiman.es

Identity:

Rosmiman Facilities is global solution for the preservation and management of

properties and real estate asset in general.

Rosmiman Facilities includes all required functionalities to ensure comprehensive

management of all real estate assets.

Features:

Health and safety prevention

Security and Emergency Management

Preventive and Corrective Maintenance

Asset Inventory Management

Facilities and Space Use Management

Energy Management

Automated Information and Report Management

2.2 FOREIGN STUDIES

2.2.1

Name of system: Primavera Facilities Management

Author: Chris Kanaracus

Date published:PublishedApr 8, 2013

URL:http://www.oracle.com/us/products/applications/primavera/facilities-

management/overview/index.html

Identity:

Primavera Facilities Management provides a powerful, flexible and easy-to-use

solution to plan, manage and maintain smooth operation of your facilities. From

defining and tracking building spaces to performing facility inspections, the


solution provides a flexible toolset that can adapt to customer-specific needs.

Primavera Facilities Management is part of the integrated Primavera Unifier

offering.

Features:

Maintenance Management

Space Management

Facility Condition Assessment

Document Management

2.2.2

Name of system: eFACiLiTYEnterprise Facility Management Software

Author: Giridhar JG.

Date published: Published Sep 26, 2014

Identity:

eFACiLiTY is a modular facilities management system that works together with

your business and allows day-to-day management of the processes, automates

operations, provides a management dashboard for critical analysis and enables

enterprise wide control in the most intelligent and efficient way.

URL: http://www.efacility.in

Features:

Maintenance Management System

Visitor Management System

Facility Booking System

Space Management System

Building Management System Integration

2.2.3

Name of system: mclaren CAFM Explorer


Author: Tony Leppard

Date published: March 21st, 2013

URL: http://www.cafmexplorer.com

Identity:

McLaren Software is a leading provider and one of the original pioneers of CAFM

or Computer Aided Facilities Management software following the acquisition of

FMx Ltd in 2012.

Available either as an on-premise or cloud-based privately hosted solution CAFM

Explorer is designed for ease of use by Windows, web and mobile users. CAFM

Explorer supports building maintenance, property management, help desk, space

management, room, resources scheduling and cost control within a single

integrated package.

Features:

Assets

Building & Integrate

Cost Control

Help Desk & PPM

Property Management

Reporting

Room Booking

Space

Web & Mobile

Work Planner

2.2.4

Name of system:DirectLineMegamation Systems

Author: megamation.com


Date published: May 1, 2000

URL:http://www.capterra.com/facility-management-software/spotlight/134244/

DirectLine/Megamation%20Systems

Identity:

Reduce maintenance and inventory costs while boosting efficiency - all for a low

monthly fee. With Directline Web-based EAM/CMMS service, you get an

advanced maintenance management solution that can be scaled easily, whether

you have a few users in one site or hundreds of users in multiple plants in

several time zones. Backed by unlimited training and support, DirectLine boasts

25 years of successful implementations. No wonder 99% of users say DirectLine

meets their needs year after year.

Features:

Alerts

Asset Management

Equipment Management

Inspection Management

Inventory Control

Room Scheduling


2.2.5

Name of system:Evolved FM

Author: Simple Solutions FM, LLC

Date published: Jan 14, 2014

URL:www.SimpleSolutionsFM.com

Identity:

EvolveFM facility management software from CAFM Resources helps facility

professionals achieve significant facilities related cost savings, giving them


greater influence and personal credibility. EvolveFM provides real-time insight

into available and used space, information that can be used to make better

decisions faster.

Developed from the ground up to utilize the newest browser technologies,

EvolveFM is the CAFM software solution that tackles the real challenges of

managing your facilities information – including Access, Integration, and

Distribution. EvolveFM is the most affordable, comprehensive, facilities

management software tool available.

Features:

Manage Space

Manage Assets

Move Occupants

Submit Online Service Request

Manage Work Order & PM

Produce Reports

2.3 SYNTHESIS

Facilities Management process is relevance in every hotel reservation where is, it

become more upgraded until now, to make it fast and less of consuming of time and to

avoid paper works. The advantages of every study are to avoid cheating and fraud

even though they still have encountered a minor problem. It can truly help in Hotel

Management System to improve and enhance the system to avoid some errors and to

make it better.

Implementing Facilities Management system in Hotel management system is to

make it easily for the core division. Tomanage, track, and maintain all work performed

on facilities, buildings, and equipment.


2.4 LOCAL STUDIES MATRIX

Features JINISYS

Software Inc.

Facilities

Management

eXpress

(FMX)

eRPortal rosmiman

facilities

Preventive maintenanceAsset Management

Report generation

Checklist

2.4 FOREIGN STUDIES MATRIX

Features Primavera

Facilities

Management

eFACiLiTY

Enterprise

Facility

Management

Software

mclaren

CAFM

Explorer

DirectLineMegamation

Systems

Evolved FM

Preventive maintenance


Asset ManagementReport generationChecklist

CHAPTER 3 – FMS PROJECT MANAGEMENT AND DEVELOPMENT

3.1 RISK MITIGATION, MONITORING, AND MANAGEMENT PLAN

1.0Introduction

This section gives a general overview of the Risk Mitigation, Monitoring and

Management Plan for the Facilities Management System. It is the detailed section for

which the management of the risks has given the fullness of its descriptions.

1.1Scope and intent RMMM activities

We would like to give an-organized actions for the course we have to deal with in

creating this kind of project. We have created a risk management plan for us to be

assisted in handling any difficulties that we may encounter.

We also conducted an interview with the company representatives and analyzed

some of the important pointers that we should consider in the managements of the

risk that may impact the development of creating the software. As we are assisted

by our adviser, we consider such risks written in this chapter and took time to

analyze it and look for the best possible solutions as we create our proposed

system.

1.2Risk Management organizational role


Advisers that given by the PEC can help to reduce risk in making some

plans to do for the first task to do. Every guide can help the project team to

make decision to achieve the goals needed to perform.

Clients can ease the risk in the development process for the changes that

make for every additional process added. A client has a big role in the

performance of the project team information that given by the clients will

help to achieve the objectives

Sponsors help for the reduction of the costing for every activity and also the

technologies that might have a project team to have. Realistic software to

make and the quality of it can help the improvement of the project.

2.0Risk Description

Creating a project connects an uncertain events or set of circumstances that, should it

occur will have an effect on achievement of one or more of the projects objectives.

2.1Risk Table

Risk FactorProbability

(H-M)

Impact

(H-M)

Em

ploy

ee

Ris

k

Lack of training and

experienceM M

Pro

cess

Ris

k

Low product qualityH H

Pro

duct

Siz

e

Where size estimates

could be wrongM H


Dev

elop

men

t

Ris

kInsufficient Resources M M

Cus

tom

er

Ris

k

Customer may fail to

participateM M

Tech

nolo

gy

Ris

k

Obsolete technology H H

Bus

ines

s

Impa

ct

Product may harm

businessM M

2.1.1 Description of Risk management

Employee Risk

- This risk is totally dependent on the ability, experience and willingness of

the software development team members to create the working product. If

the team members are not experience enough to use the application

necessary to develop the software it will keep pushing the development

dates until it’s too late to save the project. If one or more members of the

software development team are not putting in all the effort required to

finish the project it will cause the project to fail. Employee risk is one of the

major risks to consider while designing the software.

Process Risk

- Process risk involves risks regarding product quality. If the product

developed does not meet the standards set by the customer or the

development team it is a failure. This can happen because of the

customer’s failure to describe the true business need or the failure of the


software development team to understand the project than to use proper

equipment and employees to finish the project.

Product Size

- This risk involves misjudgment on behalf of the customer and also the

softwaredevelopment team. If the customer fails to provide the proper size

of the product that is to be developed it will cause major problems for the

completion of the project. If softwaredevelopment team misjudges the size

and scope of the project, team may be too small orlarge for the project

thus spending too much money on project or not finishing project atall

because of shortage of finances.

Development Risk

- If client fails to provide all the necessary equipment for the development

and execution of the software this will cause the software to become a

failure. So in other words customer has to be able to provide time and

resources for the software development team. If all the requested

resources are not provided to the software development team odds for the

software development to fail rises greatly.

Customer Risk

- This is the risk where concern is client’s motivation or willingness in

helping thesoftware development team. If the client fails to attend meeting

regularly and fails to describe the real need of the business the produces

software will not be one that helps the business

Technology Risk

- Technology risk involves of using technology that already is or is soon to

be obsolete indevelopment of the software. Such software will only be

functional for short period of time thus taking away resources from the

customer. Since the technology changes rapidly these days it is important

to pay importance to this risk. If customer request use of software that

soon to be obsolete software development team must argue the call and

have to pursue customer to keep-up with current technology.

Business Impact


- This is the risk where concern is that of the not being able to come up or

produce theproduct that has impact on the client’s business. If the

software produced does not achieve its goals or if it fails to help the

business of clients improve in special ways, the software development

basically fails.

2.1.2 Probability and Impact for Risk Management

CATEGORY RISK PROBABILITY IMPACT

Employee Risks Lack of training and

experienceM M

Process Risk Low product quality H H

Development Risk Insufficient resources M H

Product SizeWhere size estimates could be

wrongM M

Customer RiskCustomer may fail to

participateM M

Technology Risk Obsolete technology H H

Business ImpactProduct may harm the

businessM M

Impact Values Description


H Marginal

M Negligible

3 Risk Mitigation, Monitoring and ManagementThis section in detail describes Risk Mitigation, Monitoring and Management for

each of the possible risks. It will talk about ways to avoid, monitor and to have

ways to manage the risks.

3.1 Risk Mitigation for Risk MThis section, relief and mitigation has explained by details and we tried to give

some important pointers to keeps some several kinds of risk monitored and

keep the development of the system always on track.

3.1.1 Employee Risks (Team members)

- This risk concerns the knowledge and of the employees and their

willingness to helpmake the project succeed. As mitigation step of

this risk we will make sure that someonein all of the project

development phases knows exactly what to do and the tools to use

toachieve the goals. If the employees that have little knowledge in

the main softwareimplementation language fails to learn it, it may

cause big problems when coding partbegins.

3.1.2Process Risk

- We want quality of the product to be as high as possible. To

achieve this we will set upguidelines to be followed for each of the

team members during all the phases of the software development

cycle. The standard will be set and defined for all of the software

development. This will help the team in delivering the high quality

product thus increasing our reputation in the market. This will help

bring in more clients in the future. It will also save customer from

getting low quality product.

3.1.3 Product Size


- In this risk concern is of under or overestimation (mainly

underestimation) of the number of Function Points. If we estimate

too few LOC (line of code) necessary for the projectwe may get

wrong cost figures which can prove fatal to the software

development plan.To avoid this from happening we will use

conservative figures to reduce the probabilityof the risk. This means

we will overestimate the LOC a little. If we end up finishing

theproject earlier than that will not create any troubles. If the

software cost estimations arepassed with higher than actual cost

required to delivered the product, the softwaredevelopment team

can get credited for finishing the product sooner. Also for any

reason the delivery dates get pushed back development team can

still deliver the product on the time. In normal circumstances

companies are not picky about the product size, so increasing the

number will not cause any troubles in getting approval for the

project.

3.1.4Development Risk

- If the necessary tools are not provided to all of the team members,

their work will lack quantity and quality. As mitigation phase we will

make sure that the budget includes costfor latest technology and

tools needed to achieve the desired product.

3.1.5 Customer Risk

- If the users of the product fail to participate during the different

phases of the software development we fail to recognize problems

with the software. To avoid this in the mitigation phase we will try to

meet the customer frequently and present software in phases so

that customer and we can have better understanding the software

being developed. More the time team spends with the customer

better the understating the team will have regarding the software.

This will help in coming up with just right product at right price for

the customer. If customer fails to mention some special operations


that have to perform with totally separate checklist and have to be

stored separately, software development team does not know

anything about it thus leaving big problem in the software.

3.1.6 Technology Risk

- To avoid risk of using technology that may become obsolete in

few years after the product have been developed. We will do

excessive research on what technology to use for software

development and will use the latest technology (programming

languages etc.) to avoid this risk. Software development team has

to make sure that the equipment requested (i.e. Palm-size PC) are

current and will not be obsolete in near future.

3.1.7 Business Risk

- In this risk category we are concerned about the quality of the final

product. Asmitigation step we will spend more time with the users

to understand their needs. This way we can gather all the

information necessary for the project to be successful. We will try to

understand business environment and can try to provide the user

with help in defining software requirements. More the time team

spends with the customer better the understating the team will have

regarding the software. This will help in coming up withjust right

product at right price for the customer. Team has to make sure that

the palm size PC integration and the cost of the palm size PC is

justified, meaning that it really improves inspection process.

3.2 Risk Monitoring for Risk MThis section we will identify the possible risks in monitoring the system.

3.2.1 Employee Risk (Teammates)

- Monitoring and managing of this risk will include looking out for

each other, that is if some team-member is having difficulties in

performing some tasks or using particular tool or technique other

members of that team will help him out. This is where team


members may have to spend little time with each other learning or

teaching what others know.

3.2.2 Process Risk

- To monitor the risk here we will review each other’s work to find

the problems and to help each other in achieving better product

quality. We will also have the general guidelines set for all of the

work to be carried on for the software development. Software

development team will constantly check each other’s work; will

compare it with the set guidelines, and will inform a team member

who is failing to participate in following the guidelines.

3.2.3 Product Size

- Monitoring and managing of this risk will include looking out for

each other, that is if some team-member is having difficulties in

performing some tasks or using particular tool or technique other

members of that team will help him out. This is where team

members may have to spend little time with each other learning or

teaching what othersknow.

3.2.4 Development Risk

- For monitoring phase during the development of the software we

will keep eye on tools being used and their effectiveness. This will

help us to keep up with new technology.

3.2.5 Customer Risk

- To monitor this risk we will monitor the successes of the meeting

by keeping track of people that have attended the meeting. If the

outcome of the meeting is low we can contact responsible person

to help us overcome this problem. We will also have the login

charts to show the customer who is attending the meetings and

who needs to be reminded to start attending meetings.




will keep eye on new technology. This will help us to keep up with

new technology.

3.2.7 Business Risk

- If a mistake has been made, user input on the completed work will

provide us with information to fix or improve the software. We have

done very many meeting with the clients and plan to do meeting

every two weeks; this should clear any misunderstandings between

the software development team and customers. This is the best

way to go at since the work that is done on the project is revealed

during the meetings and customer gets chance to make

adjustments necessary.

3.3 Risk Management for Risk MIn this section will take its part in the risk management and the actions in

the risk to be dealt with.

3.3.1 Employee Risk (Teammates)

-Monitoring and managing of this risk will include looking out for

each other, that is ifsome team-member is having difficulties in

performing some tasks or using particulartool or technique other

members of that team will help him out. This is where

teammembers may have to spend little time with each learning or

teaching what others know.If team member lacks ability to use

certain programming language or application, other team members

will take some time off to teach the team member basics related to

that application.

3.3.2Process Risk

- If the problem exists with the quality of the work, the quality

assurance plan will be revised in the risk management phase.

Other team member will attempt to take over or swap the work of

the member whose work does not meet the quality standards.

3.3.3 Product Size


- After careful monitoring of the process, if we still end up with

underestimation of the FP, we will put more man-hours into the

project. This is the only way that we think we can manage the risk.

3.3.4 Development Risk

- In the management phase if the funding for the technology and

tools are not enough we will have to reschedule the phases of

software development cycle to allow more time to coding phase.

3.3.5 Customer Risk

- If the turn out in the meetings is not encouraging we will pass out

questionnaire to easily gather customers' view. We will ask them

question rather than waiting for them to ask us questions.



will keep eye on new technology. If we spot new techniques that

can be implemented without major changes in our project we will

include such techniques in the development of the project. We will

also keep a look out for major shifts in the technology and how it

affects the software that we are working on. If there is a need

change in the technology will be discussed among team members

and will be presented to the client. If client agrees necessary

changes will be made with the existing technology.

3.3.7 Business Risk

- If a mistake has been made, user input on the completed work will

provide us with information to fix or improve the software. We have

done very many meeting with the clients and plan to do meeting

every two weeks; this should clear any misunderstandings between

the software development team and customers. This is the best

way to go at since the work that is done on the project is revealed

during the meetings and customer gets chance to make

adjustments necessary.

4 Special Condition


Software Features/Appearance :

Since it has the same of the customer or company it has a common in the

features of the software. Buttons texts or labels must likely the same to

meet the user friendly for the end users.

Technical Features:

Proposed application must consider in every sub-system has a unique

process but the application used must in common. The sub-systems front

end and back end should be the same to connect each other for

integration of the system.

3.2 SOFTWARE CONFIGURATION MANAGEMENT PLAN

1.0 Introduction

The original plan will changes are sometimes very inevitable. We’ve developed this

phase for us to control whatever kinds of changes that we will be possibly encountered

in the project journey. Project team has implemented this phase correctly and carefully

to also inform the others the changes that we’ve made and also to be made.

1.1 Scope and Intent of SCM Activities

The main purpose of SCM is to makes, report and track any changes made to the

original software development plan. We as project team unifies ourselves to commit

to report the needed changes in the system and take the best capable action that

suits to the very needs of the client. In this phase the changes that possibly be

made is connected also to each subsystems which are relatively connected to the

business process. Changes should be met up for those subsystems which are also

connected to us and make sure that all of those are also properly implemented.

1.2 SCM Organizational Role

Each member in the project team will be responsible to report any changes they do

to every/other member of the project team to minimize confusion in the software


development phase so that the changes will be properly implemented, if one

member reports a changes then the remaining member have to take up a job of

authorizing change to avoid any mistakes.

We will also keep all the members on the client’s side for the acceptance of any

changes do and do not affect user’s knowledge to the software, and if the customer

accepted the changes in the software then those changes will be discussed to the

users of the software.

2.0SCM Task

In this section we describe the specific assigned responsibilities assigned for each

members of the project team and we’ve tried to detail all those things scoped by each

project member. Each should perform all those described responsibilities or else

problems may hinder the project development. As meetings are conducted occasionally,

one must report the change to be made and seek counsel from the counsellor if it is

should be implemented.

2.1IdentificationIn this section describe the way software configuration items will be identified

for the software configuration management plan.

2.1.1 Description Identify change – during the software development phase one must

accurately report the needed change in the software and conduct a

short meeting about it. One must reasonably report it and as for the

suggestions and approval for it to be implemented.

Approve the change – the team should take time to think and

analyze if it is needed to be implemented. Each should suggest and

participate if the suggested action should be implemented or to be

unimplemented.

Document the change – one important thing which to be considered

to be done is to document the change. Once the change is already

documented, it is already finalized. But once the client has

requested for a better change, the needed action should be


conducted to the team and to the counselor and the documented

change should be modified.

2.1.2 Works Products and Documentation Identify change - Once the change is identified, project team will

hold a short orientation and record it and ask for the approval of the

adviser and also of the other project members.

Approve the change – after the consultation, the change will be

implemented if both the adviser and all the project members are

agreed and if all the things pertaining to it will contribute for the

system development.

Document the change – once the change is approved, there will be

a written proof or documentation that will be made.

2.2Configuration Control2.2.1 Description

Changes will be implemented by the group members and all those things

related to it. By using logical procedures and basing from the client’s

needs, these are the steps which will be taken in order to control the

change.

Request the change

Ask for a consultation to the adviser

If approved by the adviser, the programmer will evaluate the change

request

The result of the evaluation will be presented as change report

Final decision on change will be made

If the change is approved

1. Define constraint(s)

2. Analyze the change that will be made

3. Ask for the adviser’s suggestions

4. Check for the necessary change in the deliverables

5. Make necessary change


6. Apply SQA activities

7. Test

8. Rebuilt the software

9. Modify the documentation

10.Distribute the software

2.3Version Control2.3.1 Description

The changes will implemented according to the client’s needs and

satisfactions for the software, there will be changes in the software’s

version. We’ve decided to use a universal version number system for all

modules. This will be tackled in this section.

2.3.2 Increasing Version Number

When a change request is filed, a change report will be created. After the

change is finalized, it will be documented in the library. We will be using a

decimal point version number system:

<major update>.<minor update><bug fix>

Bug Fix

If enough bug fixes have been done on the product/module, the bug fix

portion of the version number will be increased. The number of user

visible bug fixes will also affect when the bug fix number is increased. The

more visible bug fixes have been made, the closer the bug fix number will

need to be increased. For used for bug report is as follows.

Minor Update

If functionality is added to the product/module that will increase the user-

friendliness / performance but does not change the way a

function/interface work, the minor update number may be increased.

Several of these changes will warrant a version number change. Again,


visible changes (interface) will cause the version number to increase

sooner

Major Update

If a major functionality has been added to the product that greatly increase

the user’s experience or greatly improves the program performance, a

minor version update will be issued immediately.

2.3.3 Work Products and Documentation

There will be a documented history of the versions for the system. This

document will be containing the detailed information of the version

revisions.

2.4Configuration Status Accounting (CSA)The proponents have different ways to communicate with the project team

members and to inform others that has concern in the changes.

2.4.1 DescriptionThese ways are the tools to communicate with the project team

members and to the concerned people to the software (clients).

Networking site communication:

In our times now we have networking sites to use for

communicating other member or concerned people to the

software

Change request report:

Networking sites is very helpful to communicate with the

changes to the software. Sending it using email it’s free and it’s

fast for communicating to each other

Verbal Communication:

This is the most important communication process we do for

better communicating to each other for the changes to the


software, and at the same time all the team member are in

constant touch with each other.

2.4.2 Work Products and Documentation Verbal communication

Emails

Change request report form

Suggestions (changes to the system)

Recorded Verbal interview

Revision history

3.0Software Quality Assurance OverviewDescription of the methods for SQA or Software Quality Assurance Plan

This SQA will be focus in the issue of the management and specific activities for the

quality assurance for the clients.

Scope and intent of SQA ActivitiesThe Objectives are:

Quality Management Approach

Effective methods and tools for effective software engineering technology

Usability Enhancement

Control of software documentation and changes made to it

Reviews and AuditsTechnical reviewing is performed by the software developer (formal technical review

(FTR)). These are the objectives for review:

1. To avoid any errors in function (logic or implementation);

2. Review when the software meets its requirements to verify/ for verification;

3. To make it more manageable.


3.1Generic Review GuidelinesProponents apply this quality assurance standard to software engineering

(ISO 9001). And follow it as quality assurance plan.

Management Responsibility

Quality System

Contract Review

Design Control

Document and Data Control

Purchasing

Control of Customer Supplied Product

Product Identification and Trace Ability

Process Control

Inspection and Testing

Control of Inspection, Measuring, and Test Equipment

Inspection and Test Status

Control of Nonconforming Product

Corrective and Preventive Action

Handling, Storage, Packaging, Preservation, and Delivery

Control of Quality Audits

Training

Servicing

Statistical Techniques

3.1.1 Conduction a Review

Before the software go to the process of changing its content the team

should consult first in each teammates and the clients before and after the

changes.

3.1.2 Roles and Responsibilities

We have 5 members in our project team and this are:

Project Manager - the one who manage the development team


System Analyst -the one who analyze the existing system

Document Specialist -the one who made the documentation

Lead Programmer - the one has a task to make the system

Business Analyst - the one who analyze the business flow

3.1.3 Review Work Product

Each member will give their work report to monitor each member of the

project team for the correction, cautions and reminders for us. Even we

meet our clients will be record.

3.2 Formal Technical Reviews

Here are the FTR that we will conduct during the software process:

The proponent technical review every week we proceeding in the software

that are development. We via created and have discussions and

consultation with our perspective adviser.

3.2.1 Description of Review Walkthroughs

3.2.1.1System Specification Review

The proposed of the System Specification Review this usually after

a meeting up with the user or client and have some important

things to reviewed in the software.

3.2.1.2 Description and Focus of Review

3.2.2 RMMM Review

RMMM, Risk Mitigation, Monitoring & Management, is used to prevent,

Monitor, and manage the risk. For more information, please see the

document titled “RMMM”

3.2.3 Requirements Reviews(Model, Specification)

Software Requirements stated the data requirement, specifications. For

more information, please see the document titled “Requirement Plan”


3.2.4 Data Design Review

Data design review will work to analyze the proposed design of the major

data member for the Software. The review will focus on determining if the

design object of the software is within the bounds of languages of choices

(JAVA Netbeans) further focus will be on reviewing each data object

determine if the object is designed correctly and efficiently.

3.2.5 Architectural Design Review

The Architectural Design review will provide a basis for analysis of the

proposed architectural design of the software. The focus of this review will

be to assess the current design to ensure that data flow and data control

are being handled

3.2.6 Interface (GUI)

The interface design review will focus on determining if the proposed

graphical user-interface is possible, flexible, easy to use, and aesthetically

pleasing.

3.2.7 Test Specification Review

The Test Specification review focus on determining if the proper software

testing producers are being accounted for. Upon test specification

document completion to ensure that the proper testing procedures will

take place over the course of the implementation and completion.

3.3 SQA Audits

The project team most has a weekly report on their individual performance

for the past week Question problems regardless on the performance of other

project team member will also note another ideas and changes may be

suggested


Team members will have a weekly report on their individual performance

for the past week. Any problems, questions regardless on the

performance of other team members will also note there.

Members will write part of the help menu that related to their design parts.

And they also share between members.

Any changes that will affect the project will consult with other team

members before doing any changes. These are the changes that are

minor or require little code change, but still different from the original

architectural design.

3.4 Problem Reporting and Corrective Action/ Follow-up

This section describes the problem reporting mechanisms that occur as a

consequence of the FTR’s that are conducted and the means for corrective

action and follow-up.

3.4.1 Reporting Mechanisms

In this Reporting we needed to use a form / tool that will report the

problem from the team leader from other member. It will help the team to

know what are problem in any member task.

3.4.2 Responsibilities

The Responsibilities of every member is to help each other in the project

member for the proposed system. But if there someone who has a

knowledge or experience in doing the proposed project he/she most

considered as a team leader of the project team

3.4.3 Data Collection and Valuation

The Project team and project is responsible for all data collection and

evaluation. Any product defect or enhancement will be reported to the

Project team that he can record the problem and evaluate its priority.


3.3 SOFTWARE QUALITY ASSURANCE PLAN

1.0 Introduction

This section gives a general overview of the Software Quality Assurance Plan

(SQA) for the Facilities Management System (FMS) version 2. SQA will focus on the

management issues and the process specific activities that enable a software

organization to ensure that it does “the right things at the right time in the right way.”

SQA plan provides a road map for instituting software quality assurance.

Developed by the SQA group and the project team, the plan serves as a template for

SQA activities that are instituted for each software project.

1.1 Scope and intent of SQA activities

The objectives of SQA are:

A quality management approach


Effective software engineering technology (methods and tools)

Formal technical reviews that are applied throughout the software

process

A multi testing strategy is draw

Control of software documentation and the changes made to it

A procedure to assure compliance with software development

standards when applicable

Measurement and reporting mechanisms

1.2 SQA organizational role

We have a five member of the group.

- Project Manager: Lacebal, Edison N.

- Lead Programmer: Llagas, Leslly C.

- Document Analyst: Linga, Norman O.

- System Analyst: Artates Jeruvin M.

- Business Analyst: Morden, Philip John M.

A team has its advantages and disadvantages. The advantages of team is

communication is easier among other team members, team has a very close contact

with each other, we hold regular meeting, daily update using e-mails, phone texting, etc.

The disadvantage of team is between each team, we have many overlapping job

functions. For our team, we do not have a separate member as programmer.He may

also write the help menu, or even doing documentations, we will do it all together. To

prevent the case that we might miss any test, we will invite a member from our client to

monitor our testing process.


2.0SQA taskHere are the tasks we have for the SQA:

- Consultation of the adviser

- Close contact with the client

- Extensive detail design

- Research on the subject

2.1Task overviewTasks that described above will cover the product quality control, Saving

Design Time &Cost, Minimize Errors, problem Tracking & Data Flow.

2.2Standard, Practices and Conventions (SPC) Consultation of a system

We consult our adviser if the system we develop is good, the weekly

consultation of adviser will help to our system. Whenever we make some

decision for the change of the project, we must consultation of the adviser.

Each team member must cooperate.

Close Contact with the Client


Lacebal, Edison N.(Project Manager)Artates, Jeruvin M. (System Analyst)Linga, Norman O.(Document Specialist)Llagas, Leslly C.(Lead Programmer)Morden, Philip John M.(Business Analyst)

We already have 3 meeting with the client. We have meeting with the

Hotel Manager and two for the Adviser. They have been very helpful and

cooperative. Also, we have a consultation with the adviser.

During each meeting, we discuss the problems, options we have come up

with, with their experience on the field, and they provide solutions for the

team.

Meeting Schedule Table

Meeting Date Discussions/Subjects Time

8/11/14

- Project background

- Basic software function

- Gather project information

- Client request

3:00PM – 4:30PM

8/14/14

- Present draft designs of the interface

- Present different design options

- More client request

12:30PM – 2:00PM

8/18/14

- Present detail designs of the interfaces

- Confirm client request

- Client more request

4:00PM – 5:30PM

Extensive Detail DesignAs we work the Facilities Management System version 1 use Java to

implement the software. Even the client requestwe don’t have to use the


same implementation method, but because limited time we have,the idea

of putting the software in browser base is out of question.

After we define the method we will use to design the project, we will start

to design the interfaces for the software. Based on the Version 1 design, &

the request from the client, we come up with 9 new design interfaces.

Each interface will include all the elements that the client wanted, and the

new elements that we want. But the functions for each element wouldn’t

be implemented. We present the draft interface to the client (in the 2nd&

3rd meeting). Base on the input of the client, we do more modification on

the interface, add/delete elements. And also come up with 6 more new

meetings

The process described above wouldn’t involve any “actual” coding.

Instead of clearly separate the design and coding phase, we do the simple

interface (element layout design) coding in the design phase. The

advantage for this is to refresh the project background & provide a good

exercise for each of the team members who didn’t know the Java

programming.

Research on the SubjectVersion 1 has lot bugs or unknown errors. We were able to get a hold of

the copy of the program. After an inspection and test on the software, we

estimated Version 1 has complete about 30% - 40% of the tasks that

required by the client. Many of functions that sit behind the interfaces can

be reused, even though we are going to redesign the interface or

rearrange the elements on the old interface. For the extended

enhancement, palm pilot integration part, although we have some idea

how to approach the problem, we still haven’t got any feedback from the

client for the specific brand or price range they want. So we can’t do any

actual design on that part.

2.3SQA Resources


May or may not be applicable as of now

3.0Reviews and Audits A formal technical review (FTR) is a software quality assurance activity that is

performed by software engineers. The objectives of the FTR are:

To uncover errors in function, logic, or implementation for any representation

of the software;

To verify that the software under review meets its requirements;

To ensure that the software has been represented according to predefined

standards;

To achieve software that is developed in a uniform manner;

To make projects more manageable.

3.1Generic Review Guidelines3.1.1 Conducting a Review

There are two kinds of reviews we’ll do, review cases with the client, and

review cases with other teammates.

For the changes that will affect the clients’ performance when they use the

software, we have to consult them first. But before taking the cases to the

client, the entire team member has to agree with the change. And keep a

good record of the project before and after changes.

3.1.2 Roles and Responsibilities

SQA Organizational Role, the role of each team member

- Project Manager: Lacebal, Edison N.

- Lead Programmer: Llagas, Leslly C.

- Document Analyst: Linga, Norman O.

- System Analyst: Artates Jeruvin M.

- Business Analyst: Morden, Philip John M.

3.1.3 Review Work Product


For each period we’ll generate a work report from each member. In the

work report, we will state each member’s work for the past week,

problems encountered, problem that can’t be solved, and any cautions.

This report will be extremely helpful when comes to documentation.

When we meet with our client, we will have minutes for the record. In the

minutes, we will have the questions that we make before we go see the

client, answered got from the clients, clients’ request, opinions on the

current work, schedule for next meeting, etc.

3.2Formal Technical Reviews

Here are the FTR that we will conduct during the software process:

The proponent technical review every week we proceeding in the software

that are development. We via created and have discussions and

consultation with our perspective adviser.

3.2.1 Description of Review Walkthroughs

3.2.1.1System Specification Review

The proposed of the System Specification Review this usually after

a meeting up with the user or client and have some important

things to reviewed in the software.

3.2.1.2 Description and Focus of Review

3.2.2 RMMM Review

RMMM, Risk Mitigation, Monitoring & Management, is used to prevent,

Monitor, and manage the risk. For more information, please see the

document titled “RMMM”

3.2.3 Requirements Reviews (Model, Specification)


Software Requirements stated the data requirement, specifications. For

more information, please see the document titled “Requirement Plan”

3.2.4 Data Design Review

Data design review will work to analyze the proposed design of the major

data member for the Software. The review will focus on determining if the

design object of the software is within the bounds of languages of choices

(JAVA Netbeans) further focus will be on reviewing each data object

determine if the object is designed correctly and efficiently.

3.2.5 Architectural Design Review

The Architectural Design review will provide a basis for analysis of the

proposed architectural design of the software. The focus of this review will

be to assess the current design to ensure that data flow and data control

are being handled

3.2.6 Interface (GUI)

The interface design review will focus on determining if the proposed

graphical user-interface is possible, flexible, easy to use, and aesthetically

pleasing.

3.2.7 Test Specification Review

The Test Specification review focus on determining if the proper software

testing producers are being accounted for. Upon test specification

document completion to ensure that the proper testing procedures will

take place over the course of the implementation and completion.

3.3SQA Audits Team members will have a weekly report on their individual performance

for the past week. Any problems, question regardless on the performance

of other team members will also note there.


Members will write part of the help menu that relates to their design work.

And they also share between members.

Any changes that will affect the project will be presented to other team

members before doing any changes. These are the changes that are

minor or require little code change, but still are different from the original

architectural design.

The client should be notified of all changes made to the. For minor

changes, we will just notify a reprehensive from the client instead of the

whole team from the client. This rule only applies to the minor changes or

cosmetic changes, or minor functional changes. Any major functional

change will still require the agreement from the whole team from the client

side (two inspectors and one division manager).

A changed version will also been carefully recorded. That included the

copy of the project before and after the changes. And noted on the

document that what kind of change will make on where. A version system

always helpful. See software project plan 6.2 for more details.

4.0Problem Reporting and Corrective Action/Follow-upThis section will describe problem reporting mechanisms that occur as a

consequence of the FTRs that are conducted and the means for corrective action

and follow-up.

4.1Reporting MechanismsThe clients can conveniently call us through the use of cellular phones and

also by sending us the change request form that we will be giving unto them

as we distribute the system. They can send it to us anytime in a soft copy

format and sending it to us using an email or another social networking site.

4.2ResponsibilitiesEach members of the project team has tasks to observe and to be

responsible with. The PEC required that the project team must have a project

manager to manage the team but it doesn’t mean that all of the decision-

making procedures will be decided only by the PM although it is necessary for


the PM to have a straight-forward decision-making, all of the members must

be decide with something and as one for a unified decision. By this, it will

show coordination and cooperation as a part of a Project Team.

Responsibilities:

Project Manager: Lacebal, Edison N.

System Analyst: Artates, Jeruvin M.

Lead Programmer: Llagas, Leslly C.

Business Analyst: Morden, Philip John M.

Document Specialist: Linga, Norman O.

4.3Data Collection and ValuationAs the team we gather information from the client, each of the group

members should take a great opportunity to seek important pointers that

could contribute to the system’s development. Every meeting from the client

and adviser for at least once a week, revisions from the documentation and

the software will also be done if there’s anything that we can get that could

improve the project.

4.4Statistical SQANot yet applicable

5.0Software Process Improvement ActivitiesDeterminants for Software Quality and Organizational Effectiveness


5.1Goal and Object of SPIHere are some of the goals of SPI:

1. All errors and defects are categorized by origin (e.g. flaw in specification,

flaw in logic, non-conformance to standards).

2. The cost to correct each error and defect is recorded.

3. The number of errors and defects in each category are counted and

ordered in descending order.

4. The overall cost of errors and defects in each category is computed.

5. Resultant data are analysed to uncover the categories that result in highest

cost to the organization.

6. Plans are developed to modify the process with the intent of eliminating (or

reducing the frequency of occurrence of) the class of errors and defects that

is most costly.

The graph below illustrated the error that we expected for the project. They

categorized in six fields:


Field % Reason

Logic 30 None of the member have any experience on doing a project in this

size,nor the experience on the project in this degree of difficulties

Interface 25 We have 15+ interfaces that contain more than 400+ elements

combined. And each element has average of 3+ functions behind it.

Data Handing 15 This project involved a lot of data accessing/storing, data flow

betweeneach interfaces. It’s not easy to keep track of them.

And the queries that the database used are pretty much outdated.

Error Checking 10 We practically proud of this field because for a job in this size and

theexperience we had in this field, we should get a higher error

percentage.Since we have a very close contact with the client, and

have done exceptional work on research

HW/SW 10 This mainly for the palm pilot integration section. We still haven’t gotany

news from the client yet, regardless on the brand, price, model thatwant

for the palm pilot. So it’s very difficult to do any further research.And the

palm pilot that we choice might be replace in few years or evenshorter,

or the government decide to go with different brand, or model.

Standard 10 Again, since we have no experience on such degree of project, so other

errors might be uncover, but we been optimist here since we did a

pretty good research on the project, and spent many times on

designing phase before any actual coding


30%

25%

15%

10%

10%

10%

Error Graph

LogicInterfaceData HandlingError checkingHW/SWStandard

5.2 SPI Task and Responsibilities

We have the responsibilities of each team member will do doing SPI activities.

Project Manager: Lacebal, Edison N.

System Analyst: Artates, Jeruvin M.

Lead Programmer: Llagas, Leslly C.

Business Analyst: Morden, Philip John M.

Document Specialist: Linga, Norman O.

6.0Software Configuration Management and OverviewDuring the time of the software development we will be making changes to our

original plans. Software Configuration Management Plan is developed so that we

can identify the changed, control the changes, making sure that the plan is

implemented correctly and to making sure that we report the change to other team

members and the clients. For further information on this topic, please go to the

document titled “Software Configuration Management Plan”.

7.0SQA Tools, Techniques, Methods


30%

25%

15%

10%

10%

10%

Error Graph

LogicInterfaceData HandlingError checkingHW/SWStandard

We have described a lot tools, techniques, methods for SQA. Using Consultation of

the adviser, close contact with the client, extensive detail design, and research on

the subject to minimize the errors. Different tools had been use for the SQA for this

project. Using software review, problem tracking.

We try to follow the ISO 9001 Standard as our organizational structure,

responsibilities, procedures, processes, and resources for implementing quality

management. But the truth is, limited by the time and the size of the team; we are

overlapping many of the functions to the same team member.

3.4 SYSTEM SPECIFICATION


1.0 Introduction

Hotel Facilities Management System (HFMS) views the systems overview what

process been undertaken. To manage, track, and maintain all work performed on your

facilities, buildings, and equipment. Configurable automated processes to generate

preventive maintenance work orders at the appropriate time, based on a time-based

schedule. Track space standard compliances, room availability and occupancy rates, in

a single building, property, across the entire portfolio. Support for routine inspection and

assessment of the condition of each building system. Collect, analyze, and report on the

condition of the entire facility.

1.1 Goals and objectives

The main purpose of HFMS is to help you manage your business because it forces you

to have a process for doing very important key activities such as preventive

maintenance and responding to work requests and emergencies or tracking and

managing office moves and related furniture and other assets, for instance.

To help the customers and administrations ensure the organization's assets are







management.

1.2 System statement of scope

The Facilities Management System is software that canmanage, track, and

maintain all work performed on your facilities, buildings, and equipment.Track space

standard compliances, room availability and occupancy rates, in a single building,

property, across the entire portfolio. Support for routine inspection and assessment of


the condition of each building system. Collect, analyze, and report on the condition of

the entire facility.

1.2.1 General requirements

A way to track all facilities and equipment

A way to search room availability and occupancy rates

A way to search for existing facilities

A way to print maintenance reports

A way to collect analyze and reports the condition of entire facilities

1.2.2 Extended Enhancement

Interface enhancement

Staff members of a hotel requested a lot of interface enhancements that will

increase the usability and ease of to handle of this product.

Database Administrative Interface

There is currently no documented interface for staff members to maintain checklist

and templates.

Training

The staff members has also requested for the entire staff for the proper training for

the use of the software.

1.3 System context

Eventually, the user of this product has benefits that receive in using Billing

System. Therefore, the project team assures that this system is user friendly and free

from any error or malfunctions. In addition, this is trial product. If it is successful

hopefully, it can be used in any branches.


1.4 Major Constraints

TimeEver since, we had a limited time to finish all documentation. There have a

lot of group meeting or gathering that been not surely met or postpone. The

project team still works on it to make the tasks furnished.

ResourceThe project team needs at least 4 laptops each for the faster development

of the system and also for the documentation. To create finish documentation we

must have some resource like laptop that will help to lessen the time to consume

for working every task.

2.0 Functional data description

This section describes overall system function and the information domain in which it

operates.


2.1 System architecture

2.2.1 Architecture model

No

Yes


Developers Info

Add client Info

Update Info

Facility

Rooms

Rooms

Facility

Equipment’s

Help

Facilities Information

Login

valid

Main FormExt

Asset Management

Standard Room

Family Room

Cost Request

Deluxe Room

Report generation

Room Availability Report

Material/Item Request

Facilities Mtn. Mgt. Equipment

Equipment Condition

Facility Condition

Equipment’s

Print

Start Equipment Information

2.2.1 Subsystem overview

Adding a new facility/Update existing facility information

A form in which user can add new facilities in data. It includes some dropdown

boxes in order to avoid mistake when typing in administrative information. User

can also add information about the facility.

Find existing facilities

User can search for facilities number or room number, it will help to easily

determine if the facility is already occupied or not.

Printing checklist

This allows the user to print out a copy of checklist for hotel stuff to properly

monitor the facilities. There are two kinds of checklist, first is the room check list,

it includes all the guest room available in the hotel and the item in every rooms,

and the second is hotel item, and it includes the florescent lamp, fire

extinguisher, emergency light etc.

Data transfer and retrieve

System can transfer data from other department and retrieve for fast transaction.

2.2 Data description

2.2.1 Major Data Objects

Administrator Information

1. Admin_ID

The ID number given to each qualified administrators

2. Admin_Lname:

Administrator’s last name.


3. Admin_Fname:

Administrator’s first name.

4. Admin_Mname:

Administrator middle name.

5. User_Level:

Employee’s type of accounts.

6. Position:

The entire work of a user.

7. Address

This field contains administrator complete address.

8. Email Address

This field contains administrator valid and updated email address.

9. Contact Number

This field contains administrator updated contact number.

10. Admin_Password:

Administrator’s password use to log in to the system

Add User Accounts

1. User_Fname:

Employee’s first name.

2. User_Fname:

Employee’s middle name.


3. User_Level:


4. Password:

Employee’s password use to log in to the system

5. User_ID:

Unique ID number of an employee.

6. User_Lname:

Employee’s last name.

Add Facilities/Equipment

1. Item_ID:

The identity of item to easily track the item

2. Category:

Category if it is facilities or equipment

3. Type_Name:

The type name of facilities and equipment

4. Location:

The location of item where item stored

5. Date_Stored:

When placed the item

6. Prize_Item:

The amount of item


7. Status:

The status of item if it is active or Inactive

Room Status

1. Room_Number:

The room number of guest

2. Type_Room:

Type of room if it is Standard, Deluxe or Family Room

3. Name:

Name of guest

4. Check_In_Date:

When guest check in

5. Check_Out_Date:

When guest check out

6. Rooms_Occupied:

Rooms whichnot yet available

7. Rooms_Available

Rooms available for check in

8. RoomW_Reservation

Rooms has been reserved

9. Rooms_outofOrder

Rooms that may have damage or lack of facilities


Checklist Report

1. Room_No:

Room number of guest

2. Type_Room:


3. Category:

List of item

4. Remarks:

Checking of item if it’s ok not ok

6. Start_Date:

Date start of maintaining

7. Due_Date:

Due date of maintaining

Search Facilities/Equipment

1. Item_ID:


2. Category:


3. Type_Name:


4. Location:



5. Date_Stored:


6. Prize_Item:

The amount of item

7. Status:


Search Room Availability

1. Room_Number:


2. Type_Room:


3. Rooms_Occupied:

Rooms which not yet available

4. Rooms_Available




6. Rooms_outofOrder



2.2.2 Relationships

2.3 Human interface description

In the proposed system without use of hand held PC, inspectors from the hotel

goes out to facilities with checklist in the paper format and records any violation

in a checklist. When the inspector returns from the facilities he/she has to insert

the data into the database which uses Java as front end. The software uses


Facilities and Equipment‘s Information

Item_ID

Category

Type_Name

Location

Date_Stored

Prize_Item

Status

Room status

Room_No

Type_Room

Name

Check_In

Check_Out

Rooms_Occupied

Rooms_Available

RoomsW_Reservation

RoomsOutOf_Order

Checklist Reports

Room_No

Type_Room

Category

Remarks

Start_Date

Due_Date

Availability Rooms

Room_No

Type_Room

Rooms_Occupied

Rooms_Available

RoomsW_Reservation

RoomsOutOf_Order

MySql Express as the back end system.The user logs into the system using

his/her ID. The first screen that the user will come across is the main form; it

contains four buttons with several different options to choose from. User can

choose a button to add new facilities into the database and can update the status

of a facility, can find existing facility, print checklist for next inspection, a help

button to view the developer’s information and a button to exit the java

environment.

Add room/Status window allow user to add new facility in database it can also

add the information of the client to easily monitor the transaction and the

availability of the facility. It can also update the status of the room.

Print checklist window user can print a checklist for the regular checking of

hotel facilities and equipment’s, there are two kinds of checklist that can be

generate, room checklist and equipment checklist. In the room checklist it divided

in three categories the standard room, family room and deluxe room, each of the

three contains the list of item inside the room. The equipment checklist listed all

the equipment’s inside the hotel like fire extinguisher, emergency light, switches

etc.

Checklist window allow the user to save the data that the inspector listed in

his/her checklist paper, this window will be the way to save the information into

the database to make sure the security of information.

Search window enable the user to search for a facility that already been entered

into the database search button divided in two categories, the room and

checklist. There are three rooms that can be search in room search button the

standard room, family room and deluxe room. In the checklist user can search

the previous checklist in an easier way. This will help the user to save time in

locating the information that he/she needs.

About window contains the information about the developer of the system that

has been said, user can contact the developers maintenance of the system or

technical purposes.


3.0 Subsystem Description

3.1 Subsystem Flow Diagram

Here are some of the diagrams regarding subsystem dataflow


3.1.1 Add room status


Update room information

Close

Create new facility

informationRoom status

Room information update D.B

does the room info required

updating

Room information from D.B

Yes

No

Yes

No

Enter room Information

Room information saved in D.B

is this a new

room

3.1.2 Search room


Search room

Deluxe roomFamily roomStandard room

Room information

from D.B

Room information

from D.B

Room information

from D.B

Searching room information/

status


status


status

3.1.3 Create Checklist

4.0 Enhanced Interface Prototyping4.1 Prototyping Requirements


Create Checklist

Print Checklist Report

Generate report

Equipment

Generate report

Print Checklist Report

Hotel room

Checklist information from D.B


3.5 SOFTWARE REQUIREMENTS SPECIFICATION

1.0 Introduction

The introduction of the Software Requirements Specification (SRS) provides an

overview of the entire SRS with purpose, scope, definitions, acronyms, abbreviations,

references and overview of the SRS.

1.1 Goals and Objectives

The main purpose of HFMS is to help you manage your business because it forces

you to have a process for doing very important key activities such as preventive

maintenance and responding to work requests and emergencies or tracking and

managing office moves and related furniture and other assets, for instance.

To help the customers and administrations ensure the organization's assets are







management.

1.2 System Statement of Scope

The Facilities Management System is software that can manage, track,

and maintain all work performed on your facilities, buildings, and equipment.

Track space standard compliances, room availability and occupancy rates, in a

single building, property, across the entire portfolio. Support for routine inspection

and assessment ofthe condition of each building system. Collect, analyze, and

report on the condition of the entire facility.


1.2.1 General Requirements







Interface enhancement

Staff members of a hotel requested a lot of interface enhancements that

will increase the usability and ease of to handle of this product.

Database Administrative Interface

There is currently no documented interface for staff members to maintain

checklist and templates.

Training

The staff members has also requested for the entire staff for the proper

training for the use of the software.

1.3 System Context

Eventually, the user of this product has benefits that receive in using

Billing System. Therefore, the project team assures that this system is user

friendly and free from any error or malfunctions. In addition, this is trial product. If

it is successful hopefully, it can be used in any branches.


1.4 Major Constraints

Time

Ever since, we had a limited time to finish all documentation. There have a lot

of group meeting or gathering that been not surely met or postpone. The


Resource

The project team needs at least 4 laptops each for the faster development of

the system and also for the documentation. To create finish documentation

we must have some resource like laptop that will help to lessen the time to

consume for working every task.

2.0 Usage Scenario

2.1 User Profiles

There will be only 2 user level:

Full Control (Administrator)

Read/Write/Modify All (User/Staff)

2.2 Use-Cases

Full Control (Administrator)

This is the system administrative level which will be able to maintenance

the application settings as well as the user profile.

Read/Write/Modify All (User/Staff)

This type of user will be able to do all task in billing and collection process.


3.0 Data Model and Description

3.1 Data Description

3.1.1 Data Objects and Dictionary

Administrator Information

1. Admin_ID

The ID number given to each qualified administrators

2. Admin_Lname:

Administrator’s last name.

3. Admin_Fname:

Administrator’s first name.

4. Admin_Mname:

Administrator middle name.

5. User_Level:


6. Position:

The entire work of a user.

7. Address

This field contains administrator complete address.

8. Email Address

This field contains administrator valid and updated email address.

9. Contact Number


This field contains administrator updated contact number.

10. Admin_Password:

Administrator’s password use to log in to the system

Add User Accounts

1. User_Fname:

Employee’s first name.

2. User_Fname:

Employee’s middle name.

3. User_Level:


4. Password:

Employee’s password use to log in to the system

5. User_ID:

Unique ID number of an employee.

6. User_Lname:

Employee’s last name.

Add Facilities/Equipment

1. Item_ID:


2. Category:



3. Type_Name:


4. Location:


5. Date_Stored:


6. Prize_Item:

The amount of item

7. Status:


Room Status

1. Room_Number:


2. Type_Room:


3. Name:

Name of guest

4. Check_In_Date:

When guest check in

5. Check_Out_Date:

When guest check out


6. Rooms_Occupied:


7. Rooms_Available




9. Rooms_outofOrder


Checklist Report

1. Room_No:

Room number of guest

2. Type_Room:


3. Category:

List of item

4. Remarks:

Checking of item if it’s ok not ok

6. Start_Date:

Date start of maintaining

7. Due_Date:

Due date of maintaining


Search Facilities/Equipment

1. Item_ID:


2. Category:


3. Type_Name:


4. Location:


5. Date_Stored:


6. Prize_Item:

The amount of item

7. Status:


Search Room Availability

1. Room_Number:


2. Type_Room:


3. Rooms_Occupied:



4. Rooms_Available




6. Rooms_outofOrder



3.1.2 Relationships


Facilities and Equipment‘s Information

Item_ID

Category

Type_Name

Location

Date_Stored

Prize_Item

Status

Room status

Room_No

Type_Room

Name

Check_In

Check_Out

Rooms_Occupied

Rooms_Available

RoomsW_Reservation

RoomsOutOf_Order

Checklist Reports

Room_No

Type_Room

Category

Remarks

Start_Date

Due_Date

Availability Rooms

Room_No

Type_Room

Rooms_Occupied

Rooms_Available

RoomsW_Reservation

RoomsOutOf_Order

4.0 Functional Model and Description

4.1 Subsystem Flow Diagrams


4.1.1 Add room status


Enter room Information

Room information saved in D.B

is this a new

room

Update room information

Close

Create new facility

informationRoom status

Room information update D.B

does the room info required

updating

Room information from D.B

Yes

No

Yes

No

4.1.2 Search room


Search room

Deluxe roomFamily roomStandard room

Room information

from D.B

Room information

from D.B

Room information

from D.B


status


status


status

4.1.3 Create Checklist

4.2 Human Interface

In the proposed system without use of hand held PC, inspectors from the hotel

goes out to facilities with checklist in the paper format and records any violation

in a checklist. When the inspector returns from the facilities he/she has to insert

the data into the database which uses Java as front end. The software uses

MySql Express as the back end system.In the proposed system without use of

hand held PC, inspectors from the hotel goes out to facilities with checklist in the

paper format and records any violation in a checklist. When the inspector returns

from the facilities he/she has to insert the data into the database which uses Java

as front end. The software uses MySql Express as the back end system.The user

logs into the system using his/her ID. The first screen that the user will come

across is the main form; it contains four buttons with several different options to

choose from. User can choose a button to add new facilities into the database


Create checklist

Print checklist

Generate report

Equipment

Generate report

Print checklist

Hotel room



and can update the status of a facility, can find existing facility, print checklist for

next inspection, a help button to view the developer’s information and a button to

exit the java environment.

Add room/Status window allow user to add new facility in database it can also

add the information of the client to easily monitor the transaction and the

availability of the facility. It can also update the status of the room.

Print checklist window user can print a checklist for the regular checking of

hotel facilities and equipment’s, there are two kinds of checklist that can be

generate, room checklist and equipment checklist. In the room checklist it divided

in three categories the standard room, family room and deluxe room, each of the

three contains the list of item inside the room. The equipment checklist listed all

the equipment’s inside the hotel like fire extinguisher, emergency light, switches

etc.

Checklist window allow the user to save the data that the inspector listed in

his/her checklist paper, this window will be the way to save the information into

the database to make sure the security of information.

Search window enable the user to search for a facility that already been entered

into the database search button divided in two categories, the room and

checklist. There are three rooms that can be search in room search button the

standard room, family room and deluxe room. In the checklist user can search

the previous checklist in an easier way. This will help the user to save time in

locating the information that he/she needs.

About window contains the information about the developer of the system that

has been said, user can contact the developers maintenance of the system or

technical purposes.


5.0 Restrictions, Limitations and Constraints

Time

Ever since, we had a limited time to finish all documentation. There have a lot of

group meeting or gathering that been not surely met or postpone. The project team still

works on it to make the tasks furnished.

Resource

The project team needs at least 4 laptops each for the faster development of the

system and also for the documentation. To create finish documentation we must have

some resource like laptop that will help to lessen the time to consume for working every

task.

6.0 Validation Criteria

We are creating new user interface using Java. This interface allows users to easily fill

the checklist and thus enter data regarding inspection into the database. The older

system makes the inspector’s work very tedious withused paper based system. The

interface that we will design will enable the user to complete the entire form with use of

a single window. The tests to be carried out on these interface windows are described

below.

We are concerned input of data into the software and their expected outputs. So we will

carry out black box testing where several different steps will be taken to test the

software so that when we use the software with specific data all the given outputs will

match our expected results.

To test we will select a specific number from regulation window and using the add

highlighted item button we will add the item to the inspected item list. This should list

correct item from the regulation box to the inspected item box.

We will also check for the description associated with regulation window in the details of

the regulation window. The details of the regulation must match with the list of details

and their regulation number provided by Orange Place Hotel.


We will test the additional comment window to see if the user is able to insert text in to

it. We will also check the correctness of the text from the letter generated by comparing

it with what we have entered in the addition comments box.

We will test if we are able to remove an item from inspected item box by using remove

highlighted item button. We will make sure that only the selected item is removed in

case the box contains more than one item in it. If the program is written correctly this

should work.

We will test if we can remove multiple items together from the inspected item box. We

should be able to remove multiple items at the same time without any trouble

We will test preview button to see if the letter is generated in the window to the right of

the Generate checklist window. This window will contain the letter with listing of all the

regulations selected. The letter should be generated without any troubles.

We will test for the correctness of the letter generated, that is all the regulation are listed

and their description presented must match the items we entered during the test and the

list of details provided from OPH listing the regulations and details associated with

them. We should achieve desired results without any problems.

We will check the cancel button to see if the user can exit out of the window without any

problems when the button is selected. This should work without any problem.

We will check the help button to see if the help menu is made available to the user

when help button is selected. The menu should popup without any problems when help

button is selected.

At the end will test the save button to see if all the data is correctly recorded and the

generated letter is saved. This should work without any troubles


3.6 SOFTWARE DESIGN SPECIFICATION

1.0 Introduction

The Software Design Specification describes system design for the Hotel

Management System - HFMS. The HFMS focuses not only on the transaction but

also in functional and technical design for the Graphical User Interface (GUI) of

HMS. HFMS is an automated software application developed by the project team

that includes in Hotel Management System. HFMS will take over the Hotel Billing

Process of a company in creating an accurate billing statement of a guest.

For the system interface and front end, the group has chosen Java Netbeans.

Java Netbeans is an object-oriented computer programming language that can be

viewed as an evolution of javaeclipsed. For designing the database of the system the

project team will use MSSQL database for the system’s data storage. MSSQL is a

software product whose primary function is to store and retrieve data as requested

by the other software application.

1.1 Goals and ObjectivesThe main purpose of HFMS is to help you manage your business because

it forces you to have a process for doing very important key activities such as

preventive maintenance and responding to work requests and emergencies or

tracking and managing office moves and related furniture and other assets, for

instance.

To help the customers and administrations ensure the organization's

assets are fully utilized at the lowest possible cost, while providing benefit

to every phase of a building's lifecycle.



administrative, technical, and infrastructural FM tasks when the facility or

building is operational, as well as the strategic processes for facilities

planning and management.


1.2 System Statement of Scope

The Facilities Management System is software that can manage, track,

and maintain all work performed on your facilities, buildings, and equipment.

Track space standard compliances, room availability and occupancy rates, in a

single building, property, across the entire portfolio. Support for routine inspection

and assessment of the condition of each building system. Collect, analyze, and

report on the condition of the entire facility.

1.2.1 General Requirements







Interface enhancementStaff members of a hotel requested a lot of interface enhancements that

will increase the usability and ease of to handle of this product.

Database Administrative InterfaceThere is currently no documented interface for staff members to maintain

checklist and templates.

TrainingThe staff members has also requested for the entire staff for the proper

training for the use of the software.

1.2 System Context Eventually, the user of this product has benefits that receive in using

Billing System. Therefore, the project team assures that this system is user

friendly and free from any error or malfunctions. In addition, this is trial product. If

it is successful hopefully, it can be used in any branches.


1.3 Major Constraints Time

Ever since, we had a limited time to finish all documentation. There have a lot

of group meeting or gathering that been not surely met or postpone. The


Resource

The project team needs at least 4 laptops each for the faster development of

the system and also for the documentation. To create finish documentation

we must have some resource like laptop that will help to lessen the time to

consume for working every task.

2.0 Data Design

2.1Database Description

3.0Architectural and Component-Level Design

3.1Program Structure

3.1.1 Overall

3.1.2 Clients Information

4.0User Interface Design

4.1Description of the User

4.2 Interface Design Rules

4.3Components Available

4.3.1 Intrinsic Controls

4.3.2 Activex Controls

5.0Restriction, Limitation, and Constraints


Time

Employee

Insufficient Resource

6.0Testing Issues

6.1Classes of Test

6.2Performance Bounds

6.3Identification of Critical Components

7.0Appendices


3.7 TEST SPECIFICATION

1.0 Introduction

This section gives a general overview of the Test Specification for the Facilities

Management System (FMS).

1.1 Goals and ObjectivesPut it in a simple way, a good product will be work perfectly, doing the right thing

at the right time. To do that, the software has to go through a series of tests

before its final release. Error free software is extremely difficult to achieve. After

all, nothing is perfect. Especially for software developed in a short time frame.

But high quality can be achieved with a detailed test specification. All (or least

most) of the test case will be listed, the development team will follow it step by

step, item by item, to test all the necessary objects, data flows, limits,

boundaries, and constraints of the software.

The group would like to have a test specification to counter any difficulties that

may impact the development and the future performance of the software. The

team’s goal is to assist the project team in developing a strategy to deal with any

errors. For this, the team will take look at the most common errors to some very

uncommon errors as well.

1.2 Statement of ScopeAn overall plan for integration of the software and a description of specific tests

are documented in this section. Below are the different kinds of tests that the

team will take to ensure the quality of the software.

Unit Testing

Desktop Application

Database

Palm-size PC Application

Integration Testing

Desktop Application

Database



Validation Testing

Desktop Application

Database


High-order Testing

Desktop Application

Database


1.3 Major ConstraintsIn this section we will talk about the business, technical or resource related

constraint that may keep us from performing all tests necessary

1. The team has limitation on time to test the product at the client’s facility. We

have access to the facility only during the regular office hours. We also have to

set usschedule around the available time of the inspector that is to help us, so

timeschedule will be a major constraint when we talk about testing at the site.

2. The team also has got funding for only one hand held PC. This means that we

cannot test the software using the PC from some other brand or PC that is

oflesser price and lower hardware.

3. The team does not know any hacker that can help us test the security

problems. So we have to rely on our own knowledge and have to trust the

software for thesecurity.

4. The team also does not have large enough group to have many people use

the applications at the same time to perform real stress related testing. So we

havewill not be able to test the product for the larger user base.

2.0 Testing Plan

We want the product to be bug free. We also want to make sure that there are no

defects in the product. So we will be spending large amount of the total software

development time on the testing. Below is the description of the testing


procedure and strategy. We will also be presenting the timing and scheduled of

the tests to be carried out.

2.1 Software (SCIS) To Be Tested

2.1.1 Interfaces

The tests to be carried on these interface windows are described below.

Login Window

We will make use of several different names to log in to the system, so will be

testing login window. We will also test OK and Cancel buttons on this window by

performing test above.

FMS – Java [Design] Window

This is the main window that we will use to access the database using Java. We

will have several different drop-down menus in this window. File, Facility,

Inspection, approve, Reports, Maintenance and Help are the drop down menu

that will be available in this window we will try to use all the menus than different

options available in each of the window.

2.2 Testing Strategy

In the following section we will describe the testing strategy. We will user four

different methods to test our product.

2.2.1 Unit Testing

In the unit test case we will be testing the separate modules of the

software. We will carry out white box testing where each module or component of

the software is tested individually. We will test the components by passing data

through it and we will bemonitoring data to find the errors.

We will be looking for entry and exit conditions of the data. We will make

sure that all the components work without any troubles.


The test primarily will be carried out by the programmer who designed and

implemented the module. Lead tester will than carry out test on the modules to

finalizethe testing.

2.2.2 Integration Testing

In this testing will be install the system into the hotels prescribed

department. The other system would succeed in transferring data into our. Before

that we will be checking another systems and see what are the things to be

considered included and things that are not.

2.2.3 Validation Testing

In this method of the test we will be working with the customer to find out

if the software developed in valid for the clients. We want to make sure that the

client is getting what he asked for. We will look at the software requirement

document in the case of conflict or misunderstanding with client regarding

software components.

We will perform the black box testing where the software is completed and

we test all the software components together. We will have several input data or

test data that we will derive results for. We will insert this data in the software and

will get results from the software. We will compare the results from the software

with the results that we derived. This way will check for the validation of the

software. In case there are problems with the software we will create a deficiency

list and will record all the problems in there. We will test all the components and

subcomponents of the software to perform validation test.

We have and will try our best so that we don’t have to create deficiency

list. This is necessary because if the errors are found at this stage of the software

developed we cannot fix them by the time we reach the software deliverance

date. In this case we have to negotiate with the customer to give us extension on

the project.


2.2.4 High-Order Testing

In this test method we will combine several different other types of the testing.

We will test for several different conditions by following several different test

methods.

Recovery testingHere we are concerned with ability of the software to retrieve lost data. We

want to make sure that the software is fault tolerance and does not loose

data in case of system shutdown or if the system ceases.

Security TestingIn this method of the test we want to make sure that the security checks

are working and no one is able to temper with the data. This is crucial

since our software is design to track the activity that is not legal.

Stress TestingIn this test method we want to monitor tress caused to system and the

softwaredue to simultaneous use. We want to make sure that the system

does not break down under the extreme use conditions.

Performance TestingPerformance bounds are set during the design part of the software

development.These bounds will help us in determining the effectiveness of

the software. It will also help us to minimize stress level that is caused to

user because of our software.

2.3 Testing Resources and Staffing

We will use several different resources to carry out the test on our software.

Since the time is constraint for us we will try to use help from everyone that we

can. Following is non-detailed description of the test resources

- Staff

- Resources

- Palm Size PC


- Bug Resource Report

- UMD Computer Resources

2.4 Test Record Keeping

Test record keeping and Test work Products are described in section 3.4 of Test

Specifications Document. For Information regarding these topics, please refer to

section 3.4 of the Test Specification Document

2.5 Testing Tools AD Environment

Testing tools will involve the computer resources form the group.

2.6 Test Schedule

Following is the tentative schedule for the testing of the FMS.

Project Test Plan

System Testing

Generate Testing Report

3.0 TEST PROCEDURE

In this section we will describe the test procedures in detail.

3.1 SOFTWARE (SICS) To Be Tested

For detailed list of the software component items please refer to section 2.1 from

the Test Specification document.

3.2 Testing Procedures

In this section we will try to describe over all software specification. We will

describe the methods for all the different tests to be performed and will also

declare the expected outputs.


3.2.1 Unit Testing

In the unit test case we will be testing the separate modules of the

software. We will carry out white box testing where each module or component of

the software is tested individually. We will test the components by passing data

through it and we will bemonitoring data to find the errors.

We will be looking for entry and exit conditions of the data. We will make

sure that all the components work without any troubles.

The test primarily will be carried out by the programmer who designed and

implemented the module. Lead tester will than carry out test on the modules to

finalizethe testing.

3.2.2 Integration Testing

In this testing will be install the system into the hotels prescribed

department. The other system would succeed in transferring data into our. Before

that we will be checking another systems and see what are the things to be

considered included and things that are not.

3.2.3 Validation Testing

In this method of the test we will be working with the customer to find out if

the software developed in valid for the clients. We want to make sure that the

client is getting what he asked for. We will look at the software requirement

document in the case of conflict or misunderstanding with client regarding

software components.

We will perform the black box testing where the software is completed and

we test all the software components together. We will have several input data or

test data that we will derive results for. We will insert this data in the software and

will get results from the software. We will compare the results from the software

with the results that we derived. This way will check for the validation of the

software. In case there are problems with the software we will create a deficiency


list and will record all the problems in there. We will test all the components and

subcomponents of the software to perform validation test.

We have and will try our best so that we don’t have to create deficiency

list. This is necessary because if the errors are found at this stage of the software

developed we cannot fix them by the time we reach the software deliverance

date. In this case we have to negotiate with the customer to give us extension on

the project.

3.2.4 High-Order Testing

In this test method we will combine several different other types of the

testing. We will test for several different conditions by following several different

test methods.

Recovery testingHere we are concerned with ability of the software to retrieve lost data. We

want to make sure that the software is fault tolerance and does not loose

data in case of system shutdown or if the system ceases.

Security TestingIn this method of the test we want to make sure that the security checks

are working and no one is able to temper with the data. This is crucial

since our software is design to track the activity that is not legal.

Stress TestingIn this test method we want to monitor tress caused to system and the

softwaredue to simultaneous use. We want to make sure that the system

does not break down under the extreme use conditions.

Performance TestingPerformance bounds are set during the design part of the software

development.These bounds will help us in determining the effectiveness of

the software. It will also help us to minimize stress level that is caused to

user because of our software.

3.3 Testing Resources and Staffing


We will use several different resources to carry out the test on our

software. Since the time is constraint for us we will try to use help from everyone

that we can. Following is non-detailed description of the test resources

- Staff

- Resources

- Palm Size PC

- Bug Resource Report

- UMD Computer Resources

3.4 Test Record Keeping and Log
