hotel management system content quality …bsit-4110.weebly.com/.../chapter_3_-_qa_content.docx ·...

Hotel Management System Content Quality Assurance Results

RISK MITIGATION, MONITORING AND MANAGEMENT (RMMM)

Requirements Actual Compliance Correctness Remarks Passed or

Failed

1.0 INTRODUCTION Includes the

General Overview

of the Risk

Monitoring and

Management of the

system

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.

Passed

1.1 Scope and intent of

RMMM activities

The scope and

intent are stated

clearly.

1. Determine

the scopes and

intent of RMMM

activities of the

We would like to give an-

organised 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

Passed

Facilities Management System


Facilities

Management

System.

2. Must indicate

the purpose of

preventing,

avoiding and

managing the risks

in the Hotel.

difficulties that we may

encounter.

We also conducted an

interview with the company

representatives and analysed

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

analyse it and look for the

best possible solutions as we

create our proposed system.

1.2 Risk Management

Organization Role

The risk

management

organization role

Failed



must be correct.

1. Identify the role

and responsibility

of each

member/module of

the Facilities

Management

System in risk

management.

2. Describes how

the risks will be

managed.

2.0 RISK DESCRIPTION Describes the risk

that will be

encountered during

development and

implementation of

the software.

Failed



It has the meaning

of the risk and why

is it important to

learn and avoid.

2.1 Risk Table Describes the risk

associated to the

project.

1. It must include

the following:

Risk Category

Risk

Probability

Impact

The following table describes

the risks associated with the

project. The appropriate

categories of the risks are

also given, as well as

probability of each risk and its

impact on the development

process.

No table Failed

2.1.1 Description of

Risk

Must contain the

detailed meaning

and importance of

each risk.

Process Risk

Process risk involves risks

regarding product quality. If

Lacking of

other

important

risks

Failed



Product Size

Business Impact

Customer Risks

Process Risks

Technology Risks

Development Risks

Employee Risks

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.

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

Compliance

Risk is not

an important

risk in the

implementati

on



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 the

software 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 in

development 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 the

product 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 of Risk

The table of the

probability and

Impact Risk must

be elaborated

clearly.

The impact values

Elaborate

more other

risks.

Failed



are related and

reasonable for each

risk.

Impact Values

- Catastrophic 1

- Critical 2

- Marginal 3

- Negligible 4

3.0 RISK MITIGATION,

MONITORING AND

MANAGEMENT

Describes the

overall description

of the RMMM

Failed

3.1 Risk Mitigation for Risk m This explains the

importance of the

prevention of risks.

It provides a

general overview of

This 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

Failed to

give an

overview of

the

mitigation

during

Passed



the mitigation of

risks during

implementation.

development of the system

always on track.

implementati

on of the

system.

3.1.1 Product Size Must indicate the

lines of codes and

the size of the

system and the

database to prevent

it from long time

interval in running

the system.

Failed

3.1.2 Business Impact

Risks

Must indicate the

prevention of risk in

the business.

1. How to mitigate

Hotel entire

Facilities

Management

System risks?

In this risk category we are

concerned about the quality

of the final product. As

mitigation 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

Passed



2. How to mitigate

risks in the internet

connection of the

Hotel?

3. How to manage

Facilities

Management

System

management risks?

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

with just 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.1.3 Customer (User)

Risk

Must focus on the

prevention of risk

If the users of the product fail

to participate during the

Passed



for the customer

after

implementation of

the system in a real

Hotel.

1. Risk about the

wrong use of the

system.

2. Risk about the

wrong output of the

users.

3. Risk about the

training of the

users.

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.4 Process Risks Must focus on the

prevention of risk

for the process

after

implementation.

1. Wrong entry of

facilities information

2. Wrong approval

of facilities

3. Wrong report

outputs.

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. 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

Give also

guidelines to

the future

users and

how will they

mitigate

facilities

management

process

risks.

Failed



the market. This will help

bring in more clients in the

future. It will also save

customer from getting low

quality product.

3.1.5 Technology

Risks

Must focus on the

prevention of

technology risk in

implementation

1. Must watch for

new technologies

2. Change the

unupdated software

/ obsolete

technology

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

Passed



obsolete in near future.

3.1.6 Development

Risks

Must focus on the

prevention of

development risk

1. Getting the right

resources

2. Programming

3. Database

integration

4. Transactions

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

cost for latest technology and

tools needed to achieve the

desired product.

Passed

3.1.7 Employee Risks

(Teammates)

Must focus on the

prevention of risk

for the employee

after

implementation.

Failed



1. Risk about

misunderstanding

of employees.

2. Risk about

software use.

3. Risk about

training of

employees.

3.2 Risk Monitoring for Risk

m

This explains the

importance of the

monitoring of risks.

1. It provides a

general overview of

the monitoring of

risks during

implementation.

This section we will identify

the possible risks in

monitoring the system.

Passed


monitoring of

Failed



product size risks in

the system.

3.2.2 Business Impact Must indicate the

monitoring of risk in

the business.

1. How to monitor

Hotel facilities

risks?

2. How to mitigate

risks in business’

wrong Facilities

Management

System reports and

information?

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.

Failed

3.2.3 Customer(User) Must focus on the To monitor this risk we will Focus on Failed



Risk monitoring of risk

for the customer

after

implementation.

1. Risk about the

wrong use of the

system

2. Risk about the

wrong output of the

users.

3. Risk about the

training of the users

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.

implementati

on customer/

user risks

about

facilities.


prevention of risk

for the process

after

implementation.

1. Wrong entry of

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

Focus on

implementati

on process

risks about

facilities.

Failed




2. Wrong approval

of facilities

3. Wrong report

outputs.

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.5 Technology

Risks

Must focus on the

monitoring of

technology risk in

implementation

1. Must watch for

new technologies

2. Change the

unupdated software

/ obsolete

technology

For monitoring phase during

the development of the

software we will keep eye on

new technology. This will help

us to keep up with new

technology.

Passed



3.2.6 Development

Risks

Must focus on the

monitoring of

development risk


resources

2. Programming

3. Database

integration

4. Transactions




tools being used and their

effectiveness. This will help

us to keep up with new

technology.

Give more

details on

monitoring

programmin

g and

integration

risks.

Lacking of

details.

Almost the

same with

previous

section.

Failed


(Teammates)

Must focus on the

monitoring of risk

for the employee

after

implementation.

1. Risk about

Failed



misunderstanding

of employees.

2. Risk about

software use.

3. Risk about

training of

employees.

3.3 Risk Management for

Risk m

This explains the

importance of the

management of

risks.

1. It provides a

general overview of

the management of

risks during

implementation.

In this section will take its part

in the risk management and

the actions in the risk to be

dealt with.

Passed


management of

Failed



product size risks.

3.3.2 Business Impact

Risks

Must indicate the

prevention of risk in

the business.

1. How to manage

Hotel entire

Facilities

Management

System risks?

2. How to manage

risks in the internet

connection of the

Hotel?

3. How to manage

Facilities

Management

System

management risks?

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.

Focus on

FMS

business

risks?

Answer the

questions on

the

requirements

column.

Failed



3.3.3 Customer(User)

Risk

Must focus on the

management of risk

for the customer

after

implementation.

1. Risk about the

wrong use of the

system

2. Risk about the

wrong output of the

users.

3. Risk about the

training of the users

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.

Passed


management of risk

for the process

after

implementation.

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

Focus on

process risks

and not into

quality

assurance.

Failed



1. Wrong entry of


2. Wrong approval

of facilities

3. Wrong report

outputs.

swap the work of the member

whose work does not meet

the quality standards.

3.3.5 Technology

Risks

Must focus on the

management of

technology risk in

implementation

1. Must watch for

new technologies

2. Change the

unupdated software

/ obsolete

technology




new technology. If we spot

new techniques that can be

implement without major

changes in our project we will

include such techniques in


project. We will also keep a

look out for major shifts in the

technology and how it affects

the software that we are

This is about

management

of

technology

risks.

Failed



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.6 Development

Risks

Must focus on the

management of

development risk


resources

2. Programming

3. Database

integration

4. Transactions

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.

How can you

have more

time with

coding if you

reschedule

the

development

?

Failed




(Teammates)

Must focus on the

management of risk

for the employee

after

implementation.

1. Risk about

misunderstanding

of employees.

2. Risk about

software use.

3. Risk about

training of

employees

Failed

4.0 SPECIAL CONDITIONS These are special

conditions of risks

that may happen /

are happening.

Failed



SOFTWARE CONFIGURATION MANAGEMENT (SCM)


Failed

1.0 INTRODUCTION Introduces the

Software

Configuration

Management of the

Facilities

Management

System.

The system must

introduce what the

Software

Configuration

Management will

contribute to the

development and

implementation of

the whole Hotel

software.

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.

Focus on the

Facilities

Management

System

Configuratio

n

Management

Passed



1.1 Scope and Intent of

SCM activities

Describes the

scope and purpose

of doing the SCM

activities.

1. Define the

main

purpose of

the SCM

2. How to keep

track of

changes

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.

Omit the

word “we.”

Use the third

person

noun/pronou

n in all parts

of the

document.

Passed



1.2 SCM Organizational

Role

Cites down the

responsible

persons for the task

given in SCM

Activities.

1. Cites down the

SCM

responsibilities

of the persons

in the Facilities

Management

System

2. Must state how

the responsible

person will

execute his/her

roles in the

organization

during the

implementation

As the project team our

organization is needed to be

really responsible for the

software configuration

management. Each member

will accept the full

responsibility to act to their

specific roles but not just

bound unto it, every member

should know what’s going on

to the wholeness of the

project and participate to the

needed action and act as one

to minimize or eliminate every

single mistake.

The thing we must also

consider is to share with the

client team the changes and

orient them for them to be

aware and to make sure the

Focus on

how the

configuration

of the

FACILITIES

MANAGEME

NT SYSTEM

will happen.

Focus also

on the

persons

involved not

during the

development

Passed

Failed



of the system. success of the project. As we

unify to them, the chance of

success is very reachable.

2.0 SCM TASKS The activities to be

done in SCM must

be stated.

The FACILITIES

MANAGEMENT

SYSTEM must

explain what are

the important SCM

tasks and the

responsibilities of

each member.

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.

Focus on

SCM Tasks

during the

implementati

on

Passed



2.1 Identification Introduce and

identifies the task to

be done to ensure

the proper

configurations of

the system.

In this section describe the

way software configuration

items will be identified for the

software configuration

management plan.

Passed

2.1.1 Description The detailed

description of the

SCM task

identification is

stated.

The FACILITIES

MANAGEMENT

SYSTEM must

identify what are

the changes in their

system and on how

those changes

affect the

development and

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 analyse if it is needed to

be implemented. Each should

suggest and participate if the

Focus during

the

implementati

on.

Manual-

based.

Passed



implementation of

the software.

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 counsellor

and the documented change

should be modified.

2.1.2 Works Products

and

Documentation

States the revision

history of the

system and

documentation.

Identify change - Once the

change is identified, project

team will hold a short

orientation and record it and

Focus during

the

implementati

on.

Passed



Must identify how

the changes of the

software will be

handled during the

development and in

the implementation

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.

Manual-

based.

2.2 Configuration Control Describes on how

the proponents will

control the changes



in the system.

2.2.1 Description Describes on how

the developers will

control the changes

in the system.

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

Passed



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.3 Version Control Cites down the way

of the proponents in

numbering the

versions of the

FACILITIES

Failed



MANAGEMENT

SYSTEM

documents and

system.

2.3.1 Description Describes the

versioning

technique in

revised documents

and systems.

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.

“This will be

tackled in

this section.”

Where is it?

Passed

2.3.2 Increasing

Version

Number

Describes the way

of increasing the

version number of

systems.

Failed

2.3.3 Work Products States the revision There will be a documented Passed



and

Documentation

history of the

system and

documentation.

history of the versions for the

system. This document will be

containing the detailed

information of the version

revisions.

2.4 Configuration Status

Accounting

Describes the

recording and

reporting of

information

required to

effectively manage

the configuration of

a system or

product.

We will be using three

different ways to

communicate with the team

members and to inform others

that changes may concern.

Focus on

how you will

take into

accounts the

configuration

Failed

2.4.1 Description Describes on how

the Configuration

Status Accounting

will be done.

Three ways or the three tools

that we will be using to

communicate with other

members or the people

associated with software

Focus on

configuration

status

accounting.

Failed



development.

Verbal communication:

Since our software

development team is small

and all the team members are

in constant touch with each

other it would be better to

communicate verbally.

Telephone communication:

This tool will help us to

communicate with clients; the

client will easily inform about

the things that he/she wants

to know.

Reports

This tool will help to inform

the other team members

about the state of the system,



this will give also information

not only to the team members

but also in the people

associated in the software

development.

2.4.2 Work Products

and

Documentation

States the revision

history of the

system and

documentation.

Generate reports

Good communication

Correlation

Explain each

Work

Products

and

Documentati

on.

Passed

3.0 SOFTWARE QUALITY

ASSURANCE OVERVIEW

Introduces the

Software Quality

Assurance of the

Facilities

Management

System.

1. General

overview of the

Failed



Software Quality

Assurance of

the module.

2. Reason of

evaluation of the

system or the

module.

Scope and Intent of the SQA

Activities

Describes the

scope and purpose

of doing the SQA

activities.

1. Must identify the

scope and intent of

SQA for

FACILITIES

MANAGEMENT

SYSTEM

2. Assurance

information must be

Failed



precise

Reviews and Audits States generic

review guidelines

and formal

technical reviews.

Reviews and

Audits must

be detailed.

Failed

3.1 Generic Review

Guidelines

ISO 9001 is the quality

assurance standard that

applies to software

engineering. These are some

requirements delineated by

them. We are to follow as our

quality assurance plan.

Management responsibility

Quality system

Design control

Document and data control

Process control

Inspection and testing

Training

Passed



3.1.1 Conducting a

Review

Description of

reviews

1. Must describe

the reviews.

2. Description

should be clear.

3. If multiple

reviews make it

in bulleted.

Failed

3.1.2 Roles and

Responsibilities

Description of

Roles and

Responsibilities

1. Must describe

the Roles and

Responsibilities.

2. Description

should be clear.

3. Make it in

bulleted.

Failed



3.1.3 Review Work

Product

Indicates weekly

work report of each

member of the

module.

1. Be more specific

in each

member’s work

Failed

3.2 Formal Technical

Reviews

Specification of the

Formal Technical

Reviews

1. Description

should be clear

and specific.

The team will be conducting a

FTR every week as we

proceed in the software

development. We will be

doing this by every form

we’ve created and have some

discussions and consultations

with our perspective adviser.

Include

FTRs during

the

implementati

on

Failed

3.2.1 System

Specification

Review

Description of

System

Specification

Review

The team will be doing this

usually after a meet up with

the client and if we have

some important things to be

Focus on the

review of the

system

specification

Failed



1. Description

should be clear.

2. Should focus

on the correctness

of the parts that

has been designed

reviewed in the software. We

are about to change some

things according to the SCM.

review

3.2.2 Requirement

Review

Description of

Requirement

Review

1. Description

should be clear.

2. Should focus

on the correctness

of the parts that

has been designed

As time goes, as we continue

to develop the software,

changes in the system

requirements may change

also. Continuous review of

the system requirements may

add some another flows or

interfaces in the software.

Focus on

how to

review the

requirements

Passed

3.3 SQA Audits These are the

reports produced in

the quality

assurance results

Weekly report for all project

members will be held every

week. Question and answer

portions may also be

Passed



implemented as another idea

and changes may be

suggested and reviewed.

Any changes will be

consulted first to the adviser.

We will be just doing changes

in the program if the

suggested changed by the

client and project members

are approved by the adviser

and all of the project

members.

3.4 Problem Reporting and

Corrective Follow-up

Describe the

problem reporting

mechanisms that

occur as a

consequence of the

FTRs that are

conducted and the

means for

This 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.

Passed



corrective action

and follow-up

1. Description

should be clear and

well explained.

3.4.1 Reporting

Mechanisms

Mechanism of

reporting Facilities

Management

System is specified

It shows

information about

the procedure in

producing reports

about quality

assurance.

The 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.

Passed

3.4.2 Responsibilities Specify roles and

provide information

Members of our group will be

responsible for the specific

List down

the specific

Failed



about their roles. roles we have, but doesn’t

mean only be bound unto it.

Each member will help each

other out. By using verbal

communications and keeping

in touch with each other, we

will be uniting as one toward

a particular goal.

responsibiliti

es of each.

3.4.3 Data Collection

and Valuation

Quality assurance

for data collection

and valuation is

clearly identified.

As the team 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

Focus on

data

collection

and

valuation

after the

system has

been

implemented

.

Failed



there’s anything that we can

get that could improve the

project.



SOFTWARE QUALITY ASSURANCE


Failed

1.0 INTRODUCTION: Introduces the

Software Quality

Assurance of the

Facilities

Management

System.

The Facilities

Management

System must

introduce what the

Software Quality

Assurance will

contribute to the

development and

implementation of

the Hotel systems.


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

Passed



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

Describes the

scope and purpose

of doing the SQA

activities.

1. Must identify the

scope and intent of

SQA for

FACILITIES

MANAGEMENT

SYSTEM.

2. Quality

Assurance

information must be

precise.

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

Manual-

based.

Passed



A procedure to assure

compliance with software

development standards when

applicable

Measurement and reporting

mechanisms

1.2 SQA Organization Role Description for

every role is

available and must

specify

methodology or

diagrams providing

information about

organization roles

of the project.

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,

Passed



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.0 SQA Tasks Specify task of

software quality

assurance in

systems.

1. Definition of task

must be clear.

Here are the tasks we have for

the SQA:

Consultation of the adviser

Close contact with the client

Extensive detail design

Research on the subject

Focus on

the task of

Quality

Assurance

Tasks

Passed

2.1 Task Overview 1. Must provide

information about

task overview

considering SQA

Tasks

2. Task must be

precise and

appropriate in the

Tasks that described above

will cover the product quality

control, Saving Design Time &

Cost, Minimize Errors,

problem Tracking & Data

Flow.

Describe

each SQA

task of the

Facilities

Manageme

nt System

Failed



system.

2.2 Standards, Practices

and Conventions SPC

Detailed

information about

the standards,

considering system

task or

transactions.

1. Overview of the

task

2. Describes the

rules of each task.

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

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,

Passed



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

Extensive Detail Design

As we work the Facilities

Management System version

1 use Java to implement the

software. Even the client



request we 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 Subject

Version 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.3 SQA Resources Software Quality

Assurance

resources must be

listed.

No external SQA resources

are defined for this project.

What are

the internal

SQA

Resources

to be used?

Failed

3.0 REVIEWS AND AUDITS Set objectives for

the reviews and

audits.

1. Objectives must

be specific and

described.

2. Objectives must

be clear.

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

Passed



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.1 Generic Review

Guidelines

Conducting a

Review is existing

Conducting a Review

There are two kinds of reviews

we’ll do, review cases with the

client, and review cases with

Passed



Roles and

Responsibility is

precise

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.

Roles and Responsibilities

SQA Organizational Role, the

role of each team member

Project Manager: Lacebal,

Edison N.

Lead Programmer: Llagas,

Leslly C.

Passed



Must have an

information about

Review Work

Products

Document Analyst: Linga,

Norman O.

System Analyst: Artates

Jeruvin M.

Business Analyst: Morden,

Philip John

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,

Passed



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.2 Formal Technical

ReviewsSpecification of the

Formal Technical

Reviews

1. Description

should be clear and

specific.

The team will be conducting a

FTR every week as we

proceed in the software

development. We will be doing

this by every form we’ve

created and have some

discussions and consultations

with our perspective adviser.

System specification review

The team will be doing this

usually after a meet up with

Other

essential

reviews are

missing.

Failed



the client and if we have some

important things to be

reviewed in the software. We

are about to change some

things according to the SCM.

Requirement Reviews

As time goes, as we continue

to develop the software,

changes in the system

requirements may change

also. Continuous review of the

system requirements may add

some another flows or

interfaces in the software.

3.3 SQA Audits Specify team

approach to Quality

Assurance.

Team members will have a

weekly report on their

individual performance for the

past week. Any problems,

question regardless on the

Passed



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.0 PROBLEM REOPRTING Describes the This section will describe Passed



AND CORRECTIVE

ACTION/FOLLOW-UP

practices and

procedures to be

followed for

reporting, tracking,

and resolving

problems identified

in both software

items and the

software

development and

maintenance

processes.

1. State the specific

organizational

responsibilities

concerned with

their

implementation.

problem reporting

mechanisms that occur as a

consequence of the FTRs that

are conducted and the means

for corrective action and

follow-up.

4.1 Reporting Mechanism Mechanism of

reporting in

The clients can conveniently

call us through the use of

Passed



Facilities

Management

System is specified

It shows

information about

the procedure in

producing reports

about quality

assurance.

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.2 Responsibilities Specify roles and

provide information

about their roles.

Members of our group will be

responsible for the specific

roles we have, but doesn’t

mean only be bound unto it.

Each member will help each

other out. By using verbal

communications and keeping

in touch with each other, we

will be uniting as one toward a

particular goal.

What are

these

responsibilit

ies about

quality

assurance?

Failed



4.3 Data Collection and

Valuation

Quality assurance

for data collection

and valuation is

clearly identified.

As the team 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.

Passed

4.4 Statistical SQA Quality assurance

for statistical SQA

is identified and

appropriate to

Facilities

Management

Failed



System

5.0 SOFTWARE PROCESS

IMPROVEMENT ACTIVITIES

Determines the

software quality

and organizational

effectiveness

Determinants for Software

Quality and Organizational

Effectiveness

No diagram. Failed

5.1 Goal and Object of SPI Goals and

Objectives of SPI is

clearly identified

and appropriate to

the System

Here 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.

Passed



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:



5.2 SPI Tasks and

Responsibilities

SPI task of the

System is specified

and clearly

identified

We have the responsibilities of

each team member will do

doing SPI activities.

Who are the

people in-

charge of

these tasks

and

responsibilit

ies?

Failed

6.0 SOFTWARE

CONFIGURATION

MANAGEMENT AND OVERVIEW

Software

configuration

management and

overview must be

During the time of the software

development we will be

making changes to our original

plans. Software Configuration

Focus on

the changes

of

FACILITIES

Passed



specified and

appropriate to

FACILITIES

MANAGEMENT

SYSTEM.

Management Plan is

developed so that we can

identify the changes, 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”.

MANAGEM

ENT

SYSTEM.

7.0 SQA TOOLS, TECHNIQUES,

METHODS

Tools and

techniques must be

clearly identified.

1. The FACILITIES

MANAGEMENT

SYSTEM must

identify the special

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

Passed



software tool,

techniques, and

methodologies that

supports SQA

2. State their

purposes and

describe their use.

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.



SYSTEM SPECIFICATIONS Requirements Actual Compliance Correctness Remarks Passed or

Failed

1.0 INTRODUCTION Gives a brief

description about

the system

specification.


overview of Facilities

Management System.

Focus on

system

specificatio

n section

Failed

1.1 Goals and

Objectives

Gives the main

purpose of the

system.

1. Why is

FACILITIES

MANAGEMENT

SYSTEM essential

to a Hotel

business?

2. What is its goal

in the transactions

of this business?

The main purpose of FMS is to

help automate the entire

process that customers and

administrations perform

throughout an inspection. The

goals of FMS are:

To provide an automated

system that can easily report

items in need of repair.

System proposed have simple

environment.

To develop a system

Focus on

the

objectives

of the

Facilities

Manageme

nt System.

Why is this

project a

need?

Do not

generalize.

Failed



3. Discuss the

different function

that the

FACILITIES

MANAGEMENT

SYSTEM aims to

have.

organized data information

System proposed has a

database that will store all the

information. This will assure

that the information would not

loss and unauthorized person

cannot access the

information.

Passed

1.2 System

Statement of

Scope

The Statement of

Scope must focus

on the range for the

Facilities

Management

System in the Hotel

industry.

Failed

1.2.1 General

Requirem

ents

Must have a

detailed General

Requirement for the

The following general

requirements were laid out for

our project name Facilities

Focus on

the system

functionality

Failed



FACILITIES

MANAGEMENT

SYSTEM in

accordance to its

system

specifications.

Management system.

A way in which User could

add new facilities to the

database

A search on all electronic

checklist

A way to search for existing

facilities

A way to print staff reports

A way in which they could

view data which was

entered into the database

prior to the software.

Interface enhancement

The user has requested some

enhancement in interface that

will increase the usability of the

general

requirement

Do not

generalize.



product for the user.

Database Administrative Interface

There is current no

documented interface for

Orange Place Hotel staff

members to maintain the

checklist and letter templates.

Should no such interface exist,

Team group will have to

implement one from scratch.

Online Help

To develop an extensive help

menu for the users and also to

setup the online help for the

need of the help in the future.

Training



The staff members have also

requested to undergo in

training for use with the

software

1.3 System Context Must have the

significance of the

system to the Hotel

industry.

It must have

detailed information

on the benefits of

having Facilities

Management

System.

This product hopefully can be

successful, can use by different

user to improve their facility

monitoring and leads to issues

about future support for a large

user base.

State the

significance

of the

system to

the Hotel

industry.

Do not copy

this to SRS

and SDS

system

context.

Failed

1.4 Major Constraints Must have detailed

information about

the constraint of the

Time

Two (2) of our member have

What are

the

hardware

Failed



Facilities

Management

System which

focuses on the

requirements for it.

It must explain why

this constraint is

essential

information.

their job so when we have to

make a meeting sometime they

don’t come, its limits the

knowledge that we can produce

to come up with a better idea.

Funding

We don’t have any source of

fund to buy the things that we

need to develop a system, the

money that has been use to

make the system is our own

money and there is a time that

we are lacking of it.

and

software

constraints?

What are

the

database

integration

constraints?

And the

like.

Do not

focus on

developmen

t

constraints.

2.0 FUNCTIONAL DATA DESCRIPTION

Introduction for the

Functional Data

Description and

why is it needed.

This section describes overall

system function and the

information domain in which it

operates.

Passed



2.1 System

Architecture

2.1.1 Architectu

re Model

1. In a diagram, the

whole process of

the system is easily

understood.

2. There are the

needed areas in the

system.

Explain the

diagram

more

clearly.

Passed

Passed

2.1.2 Current

Subsyste

m

Overview

1. Must explain all

the subsystems

briefly but clearly.

2. It has the major

sections of the

system

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

Passed



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

1. Must contain the

descriptions of the

attributes of all

tables to be used.

2. The attributes of

the data objects

must have a

description.

3. Tables must be

complete and the

Include

facilities

data objects

and others

that are

related to it.

Failed

Failed

Failed



relationships are

put correctly.

2.2.2 Relations

hips

1. Shows the

correct tables for

the system

2. Has correct

attributes for each

table.

3. There are

reference, dummy,

transaction tables

and etc.

Failed

2.3 Human Interface

Description

Must describe the

human interface

details of the

Facilities

Management

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

Focus on

what are

the human

interface

importance

Passed



System. 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 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

and

description

for the

FMS.



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 Must provide the Here are some of the diagrams Give Passed



Diagrams subsystem flow

diagrams regarding

the system

functions.

regarding subsystem dataflow

Add room status

Search room

explanation

for each.



Create Checklist

4.0 ENHANCED INTERFACE PROTOTYPING

4.1 Prototyping

Requirements

Must state all of the

requirements in

system prototyping.

Include

some

sample

Failed



prototype of

screens.

SOFTWARE REQUIREMENTS SPECIFICATION


Failed

1.0 INTRODUCTION It introduces the

whole requirements

of the Facilities

Management

System.

1. Includes what

Software

Requirements

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.

Passed



Specification is all

about.

1.1 Goals and Objectives 1. Must have the

information about

the goals and

objectives of having

a Software

Requirement

Specification for the

System.

2. Discussed how

System

Requirement

Specification differs

from the System

Specification.


help automate the entire process

that customers and



goals of FMS are:

To provide an automated system

that can easily report items in

need of repair.


environment.

To develop a system organized

data information



information. This will assure that

Must not be

the same

with the

objectives

in the

system

specificatio

n section.

Focus on

the

requirement

objectives

of the

Facilities

Manageme

nt System.

Do not

Passed

Failed



the information would not loss

and unauthorized person cannot

access the information.

generalize.

1.2 System Statement of

Scope

The Statement of

Scope must focus

on the requirements

for the FACILITIES

MANAGEMENT

SYSTEM.

1. Must have a table

that includes the

requirements,

priority, references

and description of

each requirement.

2. Must have a

description about

what is in the table

element such as the

Failed



priority and the

reference.

3. Must have a table

name with

description about

the table for User

Requirements.

1.2.

1

General

Requirements

Must have a

detailed General

Requirement for the

FACILITIES

MANAGEMENT

SYSTEM.

1. Process

Requirements for

the FACILITIES

MANAGEMENT

SYSTEM.

- Recording of all



our project name Facilities

Management system.

A way in which User could add

new facilities to the database


checklist


facilities

Passed



facilities

-Managing Facilities

of Customers

- Checking available

rooms.

- Facilities

Maintenance.

- Facilities Item

Request

- Generating

facilities inspection

report


A way in which they could view

data which was entered into the

database prior to the software.

User wanted a product that

would allow them to easily add

new checklists and letters or

change existing checklists and

letters.

Passed

Failed

Passed

Failed

Failed

Failed

1.2.

2

Extended

Requirements

These are the

extended

requirements

needed by the

Interface Enhancements



Add more

enhanceme

nts of the

system.

Passed



FACILITIES

MANAGEMENT

SYSTEM to make

the system

functioning well.




There is current no documented

interface for Orange Place Hotel

staff members to maintain the





Online Help





Training




requested to undergo in training

for use with the software

1.3 System Context 1. Must have the

description about

the significance of

the Facilities

Management

System to a Hotel.

2. It must have

detailed information

on the benefits of

having the Facilities

Management

System.






user base.

Must not be

the same

with the

system

context in

the system

specificatio

n section.

Focus on

the

requirement

benefits.

Focus on

the

importance

and not

Failed

Failed



what you

hope to get.

1.4 Major Constraints These are the major

system

requirements

constraint in the

requirements. It is

not about the time,

funding.

Time







Funding








Focus on

the

requirement

s

constraints.

Failed

2.0 USAGE SCENARIO



2.1 User Profiles Must contain all the

user roles and what

they are doing in the

system.

1. Must have the

role of the

administrator

2. Must have the

role of the person

who manages

facilities.

3. Must have a user

who inspects the

facilities.

4. Must have the

role for guests and

customers

The roles and

There will be four levels of users:

Full Control (Administrator)

Read/Write/Modify All

(Manager)

Read/Write/Modify Own

(Inspector)

Read Only (General Public)

Describe

each user

role.

Passed

Passed

Passed

Passed

Failed



description must be

in a tabular form.

2.2 Use-Cases Must contain the

typical interaction of

the system to the

external

environment.

The use-cases that

must be seen on

this section are as

follows:

Log in of System

Checking Facility

Details

Checking Room

Availability

Entering

Customer

Read Only Users

The read-only users will only

read the database and cannot

insert, delete or modify any

records.

Read/Write/Modify Own Users

This level of users will be able to

insert new inspection details,

facility information and generate

letters. They will be also able to

modify the entries they made in

the past.

Read/Write/Modify All Users

This level of users will be able to

do all the record maintenance

tasks. They will be able to

List all the

specific

use-cases

and not

what a user

can access.

Failed

Failed

Failed

Failed



Information

Requesting

Facility Items

Facility

Maintenance

Log out

modify any records created by

any users.

Full Control Users

This is the system administrative

level which will be able to

change any application settings,

as well as maintaining user

profiles.

Failed

Failed

Failed

2.2.1 Use Case

Diagram

The Use-case

diagram must

contain the different

actors included in

the FACILITIES

MANAGEMENT

SYSTEM.

Put a use-

case

diagram for

all the users

and their

scenarios.

Failed

2.2.2 Use Case

Description

Must have all the

use case including

the primary actor,

preconditions,

Failed



trigger, exceptions,

scenarios and

goals.

2.3 Special Usage

Considerations

Must contain the

considerations for

special users of the

system.

Failed

2.4 Activity Diagram Must have diagrams

of the main activities

in the system.

The following are

the activity diagram

that must be on the

on the FACILITIES

MANAGEMENT

SYSTEM:

Log in of System

Checking Facility

Failed

Failed



Details

Checking Room

Availability

Entering

Customer

Information

Requesting

Facility Items

Facility

Maintenance

Log out

Failed

Failed

Failed

Failed

Failed

3.0 DATA MODEL AND DESCRIPTION

3.1 Data Description

3.1.1 Data Objects

and

Must contain the

descriptions of the

Administrative Information

(Linked with Form)

Instead of

admin form,



Dictionary attributes in the

table.

1. The attributes

of the data objects

must have a

description.

2. Tables must be

complete and the

relationships are put

correctly.

Actions Completed on a Facility

Inspection Form

Inspection Results

Inspector Details

Compliance Options

EPA Code

Letter Template and checklist

Inspection Details (Linked with

Form)

Unmatched Records

Unmatched Records with Facility

Number

user form

can be

used.

Include

facilities

and

customer

data

objects.

Include data

attributes.

Failed

Failed

3.1.2 Relationship

s

Must contain the

descriptions of the

relationships of

Failed



tables.

1. Must be in a

diagram.

2. Must be

complete and

explained well.

4.0 FUNCTIONAL MODEL AND DESCRIPTION

4.1 Subsystem Flow

Diagrams

It contains the

subsystem of the

module.

1. Must have

the process flow

diagram of the

following subsystem

under FACILITIES

MANAGEMENT

SYSTEM.

Add room status Give

explanation

for each

diagram.

Passed



Search room



Create Checklist

4.2 Human Interface It is the human

interface

requirements of the

system.

1. Includes the

purpose of the

Human Interface.

2. Includes the

requirements for the

user who will use

the 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. In the

proposed system without use of

Include

interface

purpose.

Failed

Passed



3. Describe

what human

interface is all

about.

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 and

can update the status of a

facility, can find existing facility,

Failed



print checklist for next

inspection, a help button to view

the developer’s information and

a button to exit the java

environment.



information of the client to easily

monitor the transaction and the

availability of the facility. It can

also update the status of the

room.






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.








information.

Search window enable the user

to search for a facility that






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








5.0 RESTRICTIONS, LIMITATIONS AND CONSTRAINTS

It includes things

that the system

cannot do.

Time


Focus on

the

requirement

Failed








Funding








s

constraints.

6.0 VALIDATION CRITERIA The Functional and

Non Functional

Requirements of the

system.

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

Passed



makes the inspector’s work very

tedious with used 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



SOFTWARE DESIGN SPECIFICATION


Failed

1.0 INTRODUCTION It introduces the

whole design of

This section describes the

design for the Facilities



the Facilities

Management

System.

1. Must have an

overview about

the Facilities

Management

System for the

Hotel which

focuses on

design.

2. Includes the

information on

the importance

of design in an

Facilities

Management

System.

3. Includes

Management System (FMS).

Passed

Failed

Failed



what Software

Design

Specification is

all about.

1.1 Goals and

Objectives

Focuses on the

goals of the

system in the

design.

1. Must have the

information

about the goals

and objectives of

having a

Software

Requirement

Specification for

the System.


help automate the entire

process that customers and



goals of FMS are:

To provide an automated

system that can easily report

items in need of repair.


environment.

To develop a system organized

data information


Must not

be the

same with

the

objectives

in the

system

specificatio

n section.

Focus on

the design

requiremen

t objectives

of the

Facilities

Manageme

Failed




information. This will assure that

the information would not loss

and unauthorized person cannot

access the information.

nt System.

Do not

generalize.

1.2 System

Statement of

Scope

The scope of the

system in the

design.

The Statement of

Scope must

focus on the

importance of

the design for

the FACILITIES

MANAGEMENT

SYSTEM.

Failed

1.2.1 General

Requirem

ents

Must have a

detailed General

Requirement for



our project name Facilities Passed



the Facilities

Management

System.

1. Design

Requirement for

the FACILITIES

MANAGEMENT

SYSTEM:

- Searchable

existing facilities.

- Checking of

data that has

been stored on

the database.

- Search and

Generate

Reports.

Management system.

A way in which User could add

new facilities to the database


checklist


facilities


A way in which they could view

data which was entered into the

database prior to the software.

User wanted a product that

would allow them to easily add

new checklists and letters or

change existing checklists and

letters.

Interface Enhancements

Passed

Passed

Passed








There is current no documented

interface for Orange Place Hotel

staff members to maintain the





Online Help







Training


requested to undergo in training

for use with the software

1.3 System Context 1. Must have the

significance of

the FMS design

to the Hotel.

2. It must have

detailed

information on

the benefits of

having Facilities

Management

System.






user base.

Focus on

the design

requiremen

ts.

Reconstruc

t your

sentence

about this.

Failed

Passed

1.4 Major Constraints 1. Must have

detailed

information

about the

Time



Focus on

the design

requiremen

ts

Failed



constraint of the

Facilities

Management

System System

which focuses on

the requirements

for it.

2. It must explain

why this

constraint is an

essential

information to

know





Funding








constraints

.

2.0 DATA DESIGN

2.1 Database

Description

Contains the

tables together

with the

attributes and

table description.

Failed



3.0 ARCHITECTURAL AND COMPONENT-LEVEL DESIGN

Must have the

process

description of the

architectural

design.

Failed

3.1 Program

Structure

Comprises of the

System

Composition

1. It must be a

composition of

the content of

the Hotel Menus.

- Configuration

- Data Build Up

- Core

- Financial

- Logistics

Menu Items

The following shows the

architecture of the main menu:

Add room/status

Standard room

Family room

Deluxe room

Concentrat

e on the

Hotel

Overall

Structure.

The FMS

can fall

under the

core and

logistics

systems.

Failed



- Queries

- Reports

Search

Standard room

Family room

Deluxe room

Checklist

Hotel room

Equipment’s

Create Inspection

During Inspection

3.2 Description for

Components

The Description

of components

must have:

Switch User

Major Form(s) : pLogin

Must have

component

for each

Failed



1. Component

Name

2. It contains the

attributes

3. Contains the

function

4. Contains the

basic information

of the class.

5. Has the

responsibility of

the component.

6. Processing

narrative of the

component.

7. Interface

description of the

component

Major Action(s) : Login

The form pLogin will appear.

User enters their username in

txtUsername and password in

txtPassword. Then click the

button Login, user will be logged

in if it is a valid username and

password pair. If user click

button Cancel on this form,

application will end if they

confirm their action.

Main form

Major Forms(s): pAdd

room/Status, pSearch,

pChecklist

Major Action(s): Add, Update,

Save, Search

Add

user that

contains

the

requiremen

ts for each.



8. Algorithmic

Description

To add data user need to click

the Add room/status then a new

form will come up and have

three button, the Standard

room, Family room, Deluxe

room. User need to choose

where the data will be saving.

Update

To update data user need to

click the Add room/status then a

new form will come up and have




where is the data that he/she

wants to update.

Save

After the adding or updating the

data user can save it through



save button.

Search

User can search rooms by

simply clicking the search

button; it will give an option of

what kind of room that the user

wants to search.

Search/Availability

Major Forms(s): Search

Major Action(s): Search

Search

User can search the room

information that already saves

in the database; it can also

check the availability of the



room.

View hotel equipment’s/Item

Major Forms(s): Checklist

Major Action(s): View

View

In this form user can view all the

hotel daily checklist of

equipment’s and room items, all

the defective and effective item

in the hotel are listed here.

Room item checklist/Report

Major Forms(s): Hotel room

Major Action(s): Print, Report



Print

In this form, user can print a

checklist for monitoring of the

house keeper. This checklist

only contain of the room item.

Report

It also can generate a report

about the hotel room items.

4.0 USER INTERFACE DESIGN

4.1 Description of the

User Interface

1. Must have a

brief description

about User

Interface.

2. Must have the

importance of

User Interface of

FACILITIES

MANAGEMENT

Failed



SYSTEM.

3. The

description on

the software that

used in

developing the

user interface of

FACILITIES

MANAGEMENT

SYSTEM.

4.1.1 Screen

Images

Sample

screenshots of

FMS design.

Login Screen

Search Pages

Approval Queue

Add screen

images

Failed

4.1.2 Objects

and

Actions

All of the objects

that will be used

by the system

and what will be

the main actions

Login Screen

-User Name

User name can be ranged from

6 to 20 letters (numbers), as the



afterwards.

1. Objects and

Actions for

logging in into

the system.

2. Object and

Actions on

accessing the

Main Screen

3. Object and

Action for the

forms.

industry standard. No special

characters, space. And mostly

likely the users will use their

user name for this system as

well.

There are 10 people using this

project, as current status. Eight

of them are inspectors, one

manager, and one network

administrator. Even with a small

group like that, we are not going

to use the drop down menu for

the login name. Logically

speaking, drop down menu do

save time, and more

convenience. But we change

our mind after one of the

inspector we corresponded with

make an interesting comments,

“if someone can’t even

Passed

Passed

Passed



remember their login name,

they would find a new job.”

Further, more with a blind login

name system, it will provide

extra level of security. Because

it’s harder to get a user’s user

name and password compare to

just get their password.

Password

Password can be ranged from 6

to 20 letters (numbers), as the

industry standard. No special

characters, space.

OK

If the users enter the right user

name with the matching

password, it will immediately

take them to the main interface.



Cancel

If the user wishes to exit the

program, hit the “Cancel”

button.

Main Interface

Menu Items

Add room/status

Standard room

Family room

Deluxe room

Search

Standard room

Family room



Deluxe room

Checklist

Hotel room

Equipment’s

Switch User















Main form



pChecklist


Save, Search

Add










Update


click the Add room/status then

a new form will come up and

have three button, the Standard




wants to update.

Save



save button.

Search







wants to search.

Add room/Update status

Major Forms(s): Add

room/Status


Save

Add

User can add new rooms

information in this section.

Update

The user can update the status

of the room if it is out-dated.

Save

After the adding and updating

user can save it to make



changes.

Search/Availability



Search





room.




View











Print





Report






Major Forms(s): Equipment’s


Print




only contains the Equipment’s

of the hotel, but not inside the

room.

Report


about the hotel equipment’s.

4.2 Interface Design

Rules

Must include:

The Eight

Golden Rules of

Interface design focuses on

three areas of concern:

1. The design of interfaces

Focus on

the Eight

Golden

Rules of

Failed



Design Interface:

1. Strive for

consistency

2. Enable

frequent users

to use

shortcuts

3. Offer

informative

feedback

4. Design dialog

to yield closure

5. Offer simple

error handling

6. Permit easy

reversal of

actions

between software modules;

2. The design of interfaces

between the software and other

nonhuman producers and

consumers of information (i.e.,

other external entities);

3. The design of the interface

between a human (i.e., the

user) and the computer.

Easy to Learn

Readability

Easy navigate between

interfaces

Design

Interface



7. Support

internal locus of

control

8. Reduce short-

term memory

load

4.3 Components

Available

All of the

components

available in the

template / design

are described

here.

Since we are using Java as our

front-end development

language, there are a lot of

ready-made components that

are available for us to use

already. The following is a list of

controls that we will be using for

this software.

Passed

4.3.1 Intrinsic

Controls

The basic

controls must be

- detailed

- with images

TextBox

A TextBox control, sometimes

called an edit field or edit

control, displays information

entered at design time, entered

Add

Images for

each

control.

Failed



by the user, or assigned to the

control in code at run time.

Label

A Label control is a graphical

control you can use to display

text that a user can't change

directly.

Line

A Line control is a graphical

control displayed as a

horizontal, vertical, or diagonal

line.

Image

Use the Image control to display

a graphic. An Image control can

display a graphic from a bitmap,

icon, or metafile, as well as

enhanced metafile, JPEG, or



GIF files.

ListBox

A ListBox control displays a list

of items from which the user

can select one or more. If the

number of items exceeds the

number that can be displayed, a

scroll bar is automatically added

to the ListBox control.

Scrollbars

Scroll bars provide easy

navigation through a long list of

items or a large amount of

information. They can also

provide an analog

representation of current

position. You can use a scroll

bar as an input device or

indicator of speed or quantity—



for example, to control the

volume of a computer game or

to view the time elapsed in a

timed process.

CommandButton

Use a CommandButton control

to begin, interrupt, or end a

process. When chosen, a

CommandButton appears

pushed in and so is sometimes

called a push button.

Menu

A Menu control displays a

custom menu for your

application. A menu can include

commands, submenus, and

separator bars. Each menu you

create can have up to four



levels of submenus.

ComboBox

A ComboBox control combines

the features of a TextBox

control and a ListBox control—

users can enter information in

the text box portion or select an

item from the list box portion of

the control.

Checkbox

A CheckBox control displays an

X when selected; the X

disappears when the CheckBox

is cleared. Use this control to

give the user a True/False or

Yes/No option. You can use

CheckBox controls in groups to

display multiple choices from

which the user can select one or



more. You can also set the

value of a CheckBox

programmatically with the Value

property.

OptionButton

An OptionButton control

displays an option that can be

turned on or off.

Shape

The Shape control is a graphical

control displayed as a rectangle,

square, oval, circle, rounded

rectangle, or rounded square.

4.3.2 ActiveX

Controls

The advanced

components

must be

- detailed

DataRepeater

The DataRepeater control

functions as a scrollable

container of data-bound user

Add

Images for

each

control.

Failed



- with images controls.

Each control appears in its own

row as a "repeated" control,

allowing the user to view

several data-bound user

controls at once.

DateTimePicker

The DateTimePicker control

enables you to provide a

formatted date field that allows

easy date selection. In addition,

users can select a date from a

dropdown calendar interface

similar to the MonthView

control.

MSFlexGrid

The Microsoft FlexGrid

(MSFlexGrid) control displays



and operates on tabular data. It

allows complete flexibility to

sort, merge, and format tables

containing strings and pictures.

When bound to a Data control,

MSFlexGrid displays read-only

data.

TreeView

A TreeView control displays a

hierarchical list of Node objects,

each of which consists of a

label and an optional bitmap. A

TreeView is typically used to

display the headings in a

document, the entries in an

index, the files and directories

on a disk, or any other kind of

information that might usefully

be displayed as a hierarchy.



StatusBar

A StatusBar control provides a

window, usually at the bottom

of a parent form, through which

an application can display

various kinds of status data.

The StatusBar can be divided

up into a maximum of sixteen

Panel objects that are

contained in a Panels

collection.

Toolbar

A Toolbar control contains a

collection of Button objects

used to create a toolbar that is

associated with an application.

CommonDialog

The CommonDialog control



provides a standard set of

dialog boxes for operations

such as opening and saving

files, setting print options, and

selecting colors and fonts. The

control also has the ability to

display help by running the

Windows Help engine.

5.0 RESTRICTIONS, LIMITATIONS AND COSNTRAINTS

1. It includes

things that the

system cannot

do when it

comes on the

design for the

FACILITIES

MANAGEMENT

SYSTEM.

It includes:

- Hardware

Time

Time is so far the biggest

restriction or constraint for our

project as we only have around

three months to finish entire

project. It is very important for

us to watch the time we spend

over every phase of the

software development project.

We could have included many

more components to the

software like online help menu

Include the

contraints

about what

are stated

in the

requiremen

ts column.

Failed



Constraints

- Software

Constraints

- Compatibility

Constraints

but time restricts us from doing

so.

Employee Skills

Employees programming and

design skills is also one of the

restriction. It does not have as

big of an impact on the project

as time but it sure does limit us

from doing more addition to the

projects.

Insufficient Resources

Not having all the necessary

instruments also is a problem

for our software. We planned to

use latest equipment for the

project like Hand Held PC with

keyboard etc. but the employers

cannot afford to provide such

tools to all their employees so



we had to abandon the plans.

6.0 TESTING ISSUES To validate the software we

need to test the software.

During the testing we will be

concerned about the inputs and

their expected outputs. We

emphasize on the testing where

we will input the data and will

compare the output with the

expected results. At this stage,

we are not concerned about the

process; we are only looking for

the correct outputs.

Passed

6.1 Classes of Test Must have the

classes of test

for

-system

interface,

The software has many different

additions and new

interfaces/functions added to it.

We will go through each of the

new interface and other

software function to describe

different types of test performed

Passed



- login,

- system setup,

-transactions;

and other

important parts

of the system.

on them.

Interface

We are creating new user

interface using Java. This

interface allows user to easily fill

the checklist and thus enter

data regarding inspection into

the database. The older system

makes inspector’s work very

tedious with used paper based

system. The interface that we

will design is automated it can

be easy to use. The tests to be

carried on these interface

windows are described below.



information of the client to easily



monitor the transaction and the

availability of the facility. It can

also update the status of the

room.






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.










information.

Search window enable the

user to search for a facility that




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








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

menu in this window. Add

room/Update status,

Search/Availability, View hotel

equipment’s/Item, Room item

checklist/Report are the drop

down menu that will be



available in this window we will

try to use all the menus and

different options available in

each of the window.

Switch User













Main form





pChecklist


Save, Search

Add








Update


click the Add room/status then a

new form will come up and have







wants to update.

Save



save button.

Search





wants to search.

Add room/Update status

Major Forms(s): Add



room/Status


Save

Add

User can add new rooms

information in this section.

Update

The user can update the status

of the room if it is out-dated.

Save

After the adding and updating

user can save it to make

changes.

Search/Availability





Search





room.




View











Print





Report




Major Forms(s): Equipment’s


Print






only contains the Equipment’s

of the hotel, but not inside the

room.

Report


about the hotel equipment’s.

6.2 Performance

Bounds

Contains how

long the system

will respond. It

includes the best

and worst case

scenario.

Failed

6.3 Identification of

Critical

Components

Describes the

detailed critical

components of

Failed



the system.

TEST SPECIFICATION Requirements Actual Compliance Correctness Remarks Passed or

Failed

1.0 INTRODUCTION It introduces the This section gives a general



whole test

requirements of the

Facilities

Management

System.

1. Must have an

overview about the

Facilities

Management

System for the Hotel

which focuses on

tests.

2. Includes the

information on the

importance of

testing a Facilities

Management

System.

3. Includes what

overview of the Test

Specification for the Facilities

Management System (FMS).

Passed

Failed

Failed



Test Specification is

all about.

1.1 Goals and Objectives States the goals and

objectives in doing

the test.

Put 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,

Give more

testing

goals of

Billing and

Collection

System.

Passed



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 Scope Indicate the range of

test in the Facilities

Management

System

An 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

Passed



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 Constraints List down the

constraints that will

affect the testing of

Facilities

Management

System

In 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 us schedule around

the available time of the

inspector that is to help us, so

Passed



time schedule 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 of lesser 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 the security.

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 have will 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.

Passed

2.1 Software (SCIs) to be

tested

2.1.1 Interfaces Indicates the

software (modules)

The tests to be carried on these

interface windows are

FMS

windows

Passed



to be tested. 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

can be

more

detailed.

Explain

why are

these

important

to be

tested.



this window we will try to use all

the menus than different

options available in each of the

window

2.2 Testing Strategy Insert the

screenshots of the

modules to be

tested.

In the following section we will

describe the testing strategy.

We will user four different

methods to test our product.

Passed

2.2.1 Unit Testing Describes the

strategies/ways in

testing individual

modules

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 be monitoring data to find

the errors.

We will be looking for entry and

Passed



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

finalise the testing.

2.2.2 Integration

Testing

Describes the

strategies/ways in

testing the

integration of EIS

systems.

In this method of testing we will

implement the software at the

client’s location and will run it.

So we will be testing the

product on client’s network. As

part of testing, will be looking

for any signs of the collision

between our software

components and those of the

clients. We want to make sure

It is about

the

integration

of the

whole

Hotel

Manageme

nt System

modules.

Failed



there is no confusion among

the application on the network

when they are running

simultaneously. We will install

the software at the client’s site

and will run it.

We will have several different

other applications open as well.

This applications will be the

once that have to interact with

our software on normal bases.

We will make sure that all the

data is saved correctly and

there is no loss of data or data

base anomalies in the product.

We will start from the login

window and will go through all

the software functions and will

test. We will be carefully

looking for any sort of collision



between several different

applications.

2.2.3 Validation

Testing

Describes the

strategies/ways in

testing the

validations/trapping

inside the system.

In this method of the test we will

be working with the customer to

find out if the software

developed in valid for the


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

Passed



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

Checks if the

software meets the

requirements stated

on the SRS of the

system’s document

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 testing

Here 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

Passed



loose data in case of system

shutdown or if the system

ceases.

Security Testing

In 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 Testing

In this test method we want to

monitor tress caused to system

and the software due to

simultaneous use. We want to

make sure that the system

does not break down under the



extreme use conditions.

Performance Testing

Performance 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

Indicate the

responsible persons

and resources

needed in testing

the system.

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

Give

sufficient

details

about the

testing

resources

and

staffing.

Passed



- Staff

- Resources

- Palm Size PC

- Bug Resource Report

- UMD Computer Resources

2.4 Test Record Keeping Describes the ways

of archiving test

results.

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

How can

we refer to

3.4 if it has

no

content?

Failed

2.5 Testing Tools and

Environment

Indicates the list of

tools/software

needed to test the

system.

Testing tools will involve the

computer resources form the

group.

Give more

resources

to be used.

Passed



2.6 Test Schedule Maps out the

schedule of testing

for each module

Following is the tentative

schedule for the testing of the

FMS.

Project Test Plan

System Testing

Generate Testing Report

There are

no

schedule

of each

testing.

Failed

3.0 TEST PROCEDURE In this section we will describe

the test procedures in detail.

3.1 Software (SCIs) to be

tested

List down the

software/modules

that will be tested

For detailed list of the software

component items please refer

to section 2.1 from the Test

Specification document.

Passed

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

Passed



outputs.

3.2.1 Unit Testing Lists down the

procedures on how

will the QA test the

individual modules.

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 be monitoring 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

Passed



module. Lead tester will than

carry out test on the modules to

finalise the testing.

3.2.2 Integration

Testing

Lists down the

procedures on how


EIS Modules

In this method of testing we will

implement the software at the

client’s location and will run it.

So we will be testing the

product on client’s network. As

part of testing, will be looking

for any signs of the collision

between our software

components and those of the


there is no confusion among

the application on the network

when they are running

simultaneously. We will install

the software at the client’s site

and will run it.

We will have several different

Focus on

the Hotel

System’s

Integration

Failed



other applications open as well.

This applications will be the

once that have to interact with

our software on normal bases.

We will make sure that all the

data is saved correctly and

there is no loss of data or data

base anomalies in the product.

We will start from the login

window and will go through all

the software functions and will

test. We will be carefully

looking for any sort of collision

between several different

applications.

3.2.3 Validation

Testing

Lists down the

procedures on how


integration of EIS

systems.


will be working with the

customer to find out if the

software developed in valid for

the clients. We want to make

Passed



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

Lists down the

procedures on how

will the QA test if the

system meets the

requirements.

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 testing

Here 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 Testing


want to make sure that the

security checks are working

Passed



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 Testing

In this test method we want to

monitor stress caused to

system and the software due to

simultaneous use. We want to

make sure that the system

does not break down under the

extreme use conditions.

Performance Testing

Performance 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

Indicates the

personnel and

resources involved

in testing the system

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

Make the

resources

detailed on

how it is

going to be

used in

testing.

Passed



3.4 Test Record Keeping

and Log

Describes the way

of archiving the

results and log files

of each test.

Failed


hotel management system content quality …bsit-4110.weebly.com/.../chapter_3_-_qa_content.docx ·...

Documents