specification czech team hotels duif and duinpan

97
Název prezentace Specification Czech team Hotels Duif and Duinpan

Upload: cisco

Post on 25-Feb-2016

86 views

Category:

Documents


3 download

DESCRIPTION

Specification Czech team Hotels Duif and Duinpan. Table of contents. Introduction Software development Specification Conclusion. Introduction. Our team made the specification of Hotels Duif and Duinpan in Nederland. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Specification Czech team Hotels Duif and Duinpan

Název prezentace SpecificationCzech teamHotels Duif and Duinpan

Page 2: Specification Czech team Hotels Duif and Duinpan

Nadpis

1. Introduction

2. Software development

3. Specification

4. Conclusion

Table of contents

Page 3: Specification Czech team Hotels Duif and Duinpan

Nadpis

Our team made the specification of Hotels Duif

and Duinpan in Nederland.

We sent our specification to Sweden team and

they implemented the prototype.

Introduction

Page 4: Specification Czech team Hotels Duif and Duinpan

NadpisHow we did the work?

Page 5: Specification Czech team Hotels Duif and Duinpan

Nadpis

We chose SCRUM methodology with RUP elements

SCRUM is not an acronym, it comes from rugby It is method used at the beginning of match, in

which the forwards of each team crouch side by side with locked arms; Game starts when the ball is thrown in between them and the two sides compete for possession of it.

How did we work?

Page 6: Specification Czech team Hotels Duif and Duinpan

Nadpis

Iterative way of software development Core idea is adaptability of the process Useable for

Software development Software maintenance Software management

Process for agile software development

SCRUM

Page 7: Specification Czech team Hotels Duif and Duinpan

Nadpis

Trying to minimize risks Developing in iterations Developing in short time periods

1-4 weeks Intensive communication

In team With customer

Agile method

Page 8: Specification Czech team Hotels Duif and Duinpan

NadpisSCRUM process

Page 9: Specification Czech team Hotels Duif and Duinpan

Nadpis

3 types of meetings Planning – before the sprint starts Review – in the end of the sprint Retrospective – evaluating the last sprint

We merged them into one type of meeting Meeting was held every Thursday We started every meeting with review Than we did a retrospective (what we did

wrong/well) Finally we planned work for next week

SCRUM Meetings

Page 10: Specification Czech team Hotels Duif and Duinpan

Nadpis

There is no classic project manager in SRUM methodology

Team activities are driven by SCRUM master Team participate in project planning Tasks are not being assigned, team members

chooses them

SCRUM Roles

Page 11: Specification Czech team Hotels Duif and Duinpan

Nadpis

Committed role (called „Pigs“) Project owner SCRUM master Team

Involved (called „Chickens“) Users Stakeholders Managers

SCRUM Roles (2)

Page 12: Specification Czech team Hotels Duif and Duinpan

Nadpis

A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved."

Roles fairytale

Page 13: Specification Czech team Hotels Duif and Duinpan

Nadpis

We were following best practices of RUP Develop iteratively Manage requirements

keep requirements up to date and follow them Use components

break down system to smaller parts Model visually

use UML models Verify quality

brainstorming, attacking system specification Control changes

RUP elements

Page 14: Specification Czech team Hotels Duif and Duinpan

NadpisRUP elements

RUP life cycle consists of: Inception

Indentify stakeholders and their needs Understand requirements

Elaboration We have been creating specification following

requirements Construction

Transfer use case into sophisticated software (CaseComplete) and made some documents

Transition Send specification to customer and implementation team

Page 15: Specification Czech team Hotels Duif and Duinpan

NadpisOur SCRUM process based on RUP

Page 16: Specification Czech team Hotels Duif and Duinpan

NadpisIndetify stakeholders

Page 17: Specification Czech team Hotels Duif and Duinpan

Nadpis

Owner

Receptionist

Facility manager

Guest

Admin

Indetify stakeholders

Page 18: Specification Czech team Hotels Duif and Duinpan

Nadpis

Owner

Description Owner(s) of the hotel

Responsibilities Statistic and management functions

Indetify stakeholders

Page 19: Specification Czech team Hotels Duif and Duinpan

Nadpis

Receptionist

Description Subject who works in reception

Responsibilities Reservations, check-in, check-out, invoicing, facility

reservations

Indetify stakeholders

Page 20: Specification Czech team Hotels Duif and Duinpan

Nadpis

Facility manager

Description Subject who works at some facility E.g.

Sauna, bar, bowling, tenis, etc.

Responsibilities Facility reservations, facility management

Indetify stakeholders

Page 21: Specification Czech team Hotels Duif and Duinpan

Nadpis

Guest

Description A client of the hotel

Responsibilities Reservations

Indetify stakeholders

Page 22: Specification Czech team Hotels Duif and Duinpan

Nadpis

Admin

Description Subject who maintains the system

Responsibilities To maintain the system

Indetify stakeholders

Page 23: Specification Czech team Hotels Duif and Duinpan

Nadpis

Matrix indicates which functions can use each user (1/2)

Indetify stakeholders

Function Receptionist Owner Guest Facility manager Admin

Actual bill overview X X

Make an Invoice X

View all invoices X X

Edit/Delete Facility Bill X

Make a Disccount X

Display list of room reservations X X

Check availability of rooms X

Make an Reservation X

Cancel Reservation X

Change Reservation X

Create guest X

Change guest details X

Maintainn system X

Page 24: Specification Czech team Hotels Duif and Duinpan

Nadpis

Matrix indicates which functions can use each user (2/2)

Indetify stakeholders

Function Receptionist Owner Guest Facility manager Admin

Delete guest X

View guest details X

Check In X

Check Out X

Show Room Details X X

Check Availability of Facility X X X

Make an Reservation for Facility X X

Cancel reservation for facility X X

Edit reservation for facility X X

Add facility cost X XOverview of the average room occupancy

Overview of the use of facilities

Display list of employees X

Page 25: Specification Czech team Hotels Duif and Duinpan

NadpisComunication with customer

Page 26: Specification Czech team Hotels Duif and Duinpan

Nadpis

Comunication with customers allow us to specified software exactly as he want.

With Mrs. Cupido we have choosen to comunicate via e-mail, so we were able to discuss changes and her specific needs. And also, she could control our progress and how the future system will look like.

The key part is communication with customer

Comunication with customer

Page 27: Specification Czech team Hotels Duif and Duinpan

NadpisFunctional requirements (FR)

Page 28: Specification Czech team Hotels Duif and Duinpan

Nadpis

Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform.

What is FR good for?

Page 29: Specification Czech team Hotels Duif and Duinpan

Nadpis

Understanding the application domain Identifying the sources of requirements Analyzing the stakeholders Selecting the techniques, approaches, and

tools to use Eliciting the requirements from stakeholders

and other sources

Requirements elicitation

Page 30: Specification Czech team Hotels Duif and Duinpan

Nadpis

Domain analysis Group work Brainstorming Observation Scenarios …

Techniques and approaches for RE

Page 31: Specification Czech team Hotels Duif and Duinpan

Nadpis

System shall handle facilities(user stands for facility manager or receptionist)

User may add new facility Desc.: Facility will represent real life objects, such as sauna. So we will create new facility,

called sauna, fill in capacity and ect. User may place reservation on facility

Desc. System will be just like system for room reservations. We will check capacity and place a reservation on the given time.

User may manage/delete facility System shall display important information about facility.

Desc.: We may display a list of guests currently using e.g. sauna. System shall calculate bill for facility usage

Desc.: Guest leaves sauna and comes to “pay”. We start calculator module, where we select one of services. In our case service called “sauna”. This service has information about cost per hour or cost per unit (one entrance to sauna, no time limit), our calculator will take this information and count final price. We may then assign this bill to room number, or cash it.

FR example 1

Page 32: Specification Czech team Hotels Duif and Duinpan

Nadpis

System shall manage reservations(user stands for receptionist)

System shall check availability of all room types for given time period Desc.: Guest calls/emails reception and explains, that he would like to stay in the hotel for given

time period. He specifies number of people and type of rooms they would like to use. Example given: family wants one double room for children and single room for grandma. System will then check availability of specified room types and show the result.

System shall fill in all necessary forms in case the guest is already in data store Desc.: Receptionist will enter guest’s name into the system, which will check data store and find

out if the guest has already been accommodated in either of the hotels. If so, system will pre-fill reservation form and then the receptionist has to fill in only date of arrival and departure.

User may modify reservation details, regarding to the length of stay, number of guests, service etc. Desc.: Reservation has already been made, however, guest wishes to change few details, such

as length of stay or he would like to come 2 days later. And in the case, that there are 2 rooms booked for one person, he might want to cancel one, if for example his companions are sick and he wants to come alone..

FR example 2

Page 33: Specification Czech team Hotels Duif and Duinpan

Nadpis

Prioritization helps to identify the most valuable requirements

Precedence and Priority

Page 34: Specification Czech team Hotels Duif and Duinpan

Nadpis

For stakeholders to decide on the core requirements for the system

To plan optimal set of requirements for the successive releases

To trade off desired project scope against sometimes conflicting constraints (time, budget, …)

To balance the business benefit of each requirement against its cost

To balance implications of requirements on the software architecture

To select only a subset of the requirements and still produce a system that will satisfy the customers

Prioritization provides support for: (1/2)

Page 35: Specification Czech team Hotels Duif and Duinpan

Nadpis

To estimate expected customer satisfaction To get a technical advantage and optimize market

opportunity To minimize rework and schedule slippage (plan stability) To handle contradictory requirements, focus the

negotiation process, and resolve disagreements between stakeholders

To establish relative importance of each requirement to provide the greatest value at the lowest cost

Prioritization provides support for: (2/2)

Page 36: Specification Czech team Hotels Duif and Duinpan

NadpisOur precedences and priorities (1/2)

Priority 1 Managing reservations Handle check-in Handle check-out Handle invoice forms Calculate all cost and prepare invoice for manager to approve

Priority 2 Manage room types Manage equipment Manage hotel rooms Manage employees Manage price lists

Page 37: Specification Czech team Hotels Duif and Duinpan

NadpisOur precedences and priorities (2/2)

Priority 3 Handle facilities Manage services

Priority 4 Manage manager overviews

Page 38: Specification Czech team Hotels Duif and Duinpan

NadpisNon functional requirements

Page 39: Specification Czech team Hotels Duif and Duinpan

Nadpis

Non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.

In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be.

NFR - introduction

Page 40: Specification Czech team Hotels Duif and Duinpan

Nadpis

FURPS is an acronym representing a model for classifying software quality attributes (functional & non-functional requirements): Functionality - Feature set, Capabilities, Generality, Security Usability - Human factors, Aesthetics, Consistency,

Documentation Reliability - Frequency/severity of failure, Recoverability,

Predictability, Accuracy, Mean time to failure Performance - Speed, Efficiency, Resource consumption,

Throughput, Response time Supportability - Testability, Extensibility, Adaptability,

Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability

FURPS as model for NFR

Page 41: Specification Czech team Hotels Duif and Duinpan

Nadpis

The model, developed at Hewlett-Packard, was first publicly elaborated by Grady and Caswell. The + was later added to the model after various campaigns at HP to extend the acronym to emphasize various attributes.

FURPS+ is now widely used in the software industry.

FURPS - about

Page 42: Specification Czech team Hotels Duif and Duinpan

Nadpis

Localizability System support Multicurrency System can be translated into multiple languages.

FURPS based NFR in our spec.

Page 43: Specification Czech team Hotels Duif and Duinpan

Nadpis

Localizability System support Multicurrency System can be translated into multiple languages.

FURPS based NFR in our spec.

Why is it important?

Multilanguage environment of system and multicurrency support contributes better work efficiency, it is more friendly and more intuitive for end users – hotel staff and customers (eg. hotel guest).

Page 44: Specification Czech team Hotels Duif and Duinpan

Nadpis

Scalability System can be extended to other clients. More rooms, fees or price lists can be added to the

system. Unlimited number of users can access to the

system. In fact – it is utopical requirement but in real we are

expecting maximally about 500 connections at one time. New facilities and services can be added through

intuitive interface without any programming skills.

FURPS based NFR in our spec.

Page 45: Specification Czech team Hotels Duif and Duinpan

Nadpis

Usability The system is controlled through an intuitive

interface. Availability

Guest must be able to access to the hotel webpage 24 hours a day, seven days a week with exceptions for database backup (in detail – we will talk later in Security part).

Other stakeholders must be able to access their accounts 24 hours a day, seven days a week too with exceptions for database backup (in detail – we will talk later in Security part).

FURPS based NFR in our spec.

Page 46: Specification Czech team Hotels Duif and Duinpan

Nadpis

System Requirements Server side:

Software Server systems supported: Windows XP professional, Windows 2003 Server, Windows Vista Professional, Windows 2008 Server, Windows 7 Professional or Ultimate, Microsoft SQL Server 2005, .NET Framework 3.5 installed.

Client station (for employee): Software requirements: Windows based system - Windows

XP or newer with .NET Framework 3.5 installed.

FURPS based NFR in our spec.

Page 47: Specification Czech team Hotels Duif and Duinpan

Nadpis

Benefits and disadvantages of our platform recommendation: .NET is wide platform and it is continuously

innovated and maintained and we have vast and positive experience with this platform

.NET platform provides strong type environment and there are many extensions for it

.NET is expensive development plaform .NET is very tight connected to other Microsoft‘s

products

FURPS based NFR in our spec.

Page 48: Specification Czech team Hotels Duif and Duinpan

Nadpis

Security Requirements Every employee or every guest has it’s own

account. Personal information is protected. Database backup is done every night from 3 am. to

4 am. in worst case. The system logs all employee’s activity.

Data Integrity Data must be preserved on system error.

FURPS based NFR in our spec.

Page 49: Specification Czech team Hotels Duif and Duinpan

NadpisUse cases

Page 50: Specification Czech team Hotels Duif and Duinpan

Nadpis

Use cases describe the interaction between one or more actors and the system itself

Each use case represents a specific sequence of action

An actor is someone or something outside the system that interacts with the system

Use cases

Customer

Withdraw Money

Bank System Check Balance

Page 51: Specification Czech team Hotels Duif and Duinpan

Nadpis

Specification contains 36 main functions described by use cases

Use cases were made in CaseComplete 2010 program

Use cases

Example of usage

Page 52: Specification Czech team Hotels Duif and Duinpan

NadpisUse cases - New Employee

Description Use case for creating employee.

Attributes first name, last name, pin, sex, street, city, zip code,

phone, email, login, password, comment, one or more roles, isValid (if user can login into system)

Page 53: Specification Czech team Hotels Duif and Duinpan

NadpisUse cases - New Employee

Main Success Scenario1. System displays the form for inserting new employee2. User inserts required information about new employee3. System checks mandatory attributes4. System checks if login doesn't already exist5. System saves new employee

Extensions3.a If some mandatory attribute aren't filled

1. System displays information message2. Go to step 2

4.a If login already exists1. System displays message that login already exists2. Go to the step 2

Page 54: Specification Czech team Hotels Duif and Duinpan

NadpisUse case realization

Systems have simple dynamic behavior that can be expressed using UML diagram(sequence diagram) or simple text description(use case realization)

It helps to demonstrate connections between classes, shows what methos are called and etc.

Demonstrates when exactly is method fired

Page 55: Specification Czech team Hotels Duif and Duinpan

NadpisUse case realization New Employee

Description related to class diagram1. Class Role uses method Select() to load all roles in

system4. Class Employee uses method

CheckIfLoginExists(string login) to check if login doesn't already exists

5. Class Employee uses method Add(Employee employee) to add new employee to systém

Class UserInRole uses method Add() to add employee to role

Page 56: Specification Czech team Hotels Duif and Duinpan

NadpisUML sequence diagram

Page 57: Specification Czech team Hotels Duif and Duinpan

NadpisUse case realization 2nd example

Main Success Scenario1. System displays form for new reservation 2. Receptionist fills in date of arrival and departure, number

and types of rooms, and standard of accommodation3. System checks availability of rooms for given time period and

displays the chosen form, where guest (personal) data should be filled

4. Receptionist fills in guest's information5. System saves reservation and updates Planning Board

Page 58: Specification Czech team Hotels Duif and Duinpan

NadpisUse case realization 2nd example

Main Success Scenario3. Class Reservation uses method

CheckAvailabilityOfReservation(Reservation) to check availability of reservation in given time period, room/s and hotel

4. Class Guest uses method Add(Guest) to save new guest

5. Class Reservation uses method Add(Reservation) to save new reservation

Page 59: Specification Czech team Hotels Duif and Duinpan

NadpisDefine architecture

Page 60: Specification Czech team Hotels Duif and Duinpan

Nadpis

Architecture - Quick view on architectural design

Computer with Web Browser

Database Server

Persistence LayerApplication Layer

Web Service Server Reception Client Analytics Client

Facility Client

Computer with Web Browser or special written connector for interoperability between

custom systems

Reception InterfaceAnalytics Interface

Facility Interface

Page 61: Specification Czech team Hotels Duif and Duinpan

Nadpis

System is based on : Application Layer Persistent Layer Database server.

Application Layer has three clients: Reception Client (web server) Analytics Client (web server) Web-service Server.

Soft. architecture – description

Page 62: Specification Czech team Hotels Duif and Duinpan

Nadpis

Users can connect to Reception Client, Analytics Client or to Facility Client (depends on their rights) via Web Browser.

Web service Server is used for automated process to manage facility taxes. Users can connect to this Web-service Server via Web Browser or through custom connectors. Custom connector can be written for other systems and this custom written connector provides interoperability between our system and the other custom system.

Soft. architecture – description

Page 63: Specification Czech team Hotels Duif and Duinpan

Nadpis

Benefits of this Architectural design are: Multi-layered architecture allows replace database

without rebuilding entire system Management of each facility can be automated or at

least support it System can manage unlimited count of clients

Maybe the small disadvantage can be: Programmers must respect the interconnection of

each layer

Benefits and disadvantages

Page 64: Specification Czech team Hotels Duif and Duinpan

NadpisDesign GUI

Page 65: Specification Czech team Hotels Duif and Duinpan

Nadpis

We designed GUI following the specific Use case

Each use case has own Form representation Fields in the Form are based on the

information contained in use cases

GUI Design

Page 66: Specification Czech team Hotels Duif and Duinpan

NadpisGUI Design

New employee

Page 67: Specification Czech team Hotels Duif and Duinpan

Nadpis

New special offer

GUI Design

Page 68: Specification Czech team Hotels Duif and Duinpan

Nadpis

New room type

GUI Design

Page 69: Specification Czech team Hotels Duif and Duinpan

NadpisStructural view

Page 70: Specification Czech team Hotels Duif and Duinpan

Nadpis

Static entities are identified in use cases.

Using Use cases to generation class diagram

Page 71: Specification Czech team Hotels Duif and Duinpan

Nadpis

MAIN SUCCESS SCENARIO• System displays a list of accommodated guests• Receptionist selects the guest• System displays guest's details• Receptionist selects items which should be used to create new invoice• System displays an invoice form and filled with details given• Receptionist saves the changes• System calculates total price and saves the invoice• System adds invoice to the guest details and displays it

This use case using static entity Invoice.

Use case - example

Page 72: Specification Czech team Hotels Duif and Duinpan

Nadpis

Object-relation mapping is technique for converting object-oriented language to relational databases.

Conceptual model on application side contains associations and inheritance, however on the relation database side using relations (association equivalence) is possible but using inheritance is not.

Object-relational mapping

Page 73: Specification Czech team Hotels Duif and Duinpan

NadpisObject-relational mapping

Page 74: Specification Czech team Hotels Duif and Duinpan

Nadpis

Invoice class is transformed to Invoice table.

Invoice is composed by InvoiceItem classes.

Tables Charge, FacilityReservation, RentedRoom inherits from InvoiceItem.

Object-relational mapping

Page 75: Specification Czech team Hotels Duif and Duinpan

NadpisObject-relational mapping

Page 76: Specification Czech team Hotels Duif and Duinpan

NadpisDB model

Page 77: Specification Czech team Hotels Duif and Duinpan

NadpisDB model - Security

Page 78: Specification Czech team Hotels Duif and Duinpan

Nadpis

New employee User is authenticated by comparing users

name and hash of users password. User can have many roles. Role allows user to make specific operations.

DB model - Security

Page 79: Specification Czech team Hotels Duif and Duinpan

NadpisDB model - Making a reservation

Page 80: Specification Czech team Hotels Duif and Duinpan

Nadpis

Guest reservation is stored in table ‘Reservation‘.

Reservation consists of reserved room types.

DB model - Making a reservation

Page 81: Specification Czech team Hotels Duif and Duinpan

NadpisDB model - Invoicing

Page 82: Specification Czech team Hotels Duif and Duinpan

Nadpis

When guest checks in, a record in table ‘Invoice‘ is created.

All user charges, such as restaurant bills or financial penalties are stored in table ‘Charge‘.

All bills for using hotel facilities are stored in table ‘FaclityReservation‘

DB model - Invoicing

Page 83: Specification Czech team Hotels Duif and Duinpan

NadpisDB model - Invoicing – Rented rooms

Page 84: Specification Czech team Hotels Duif and Duinpan

Nadpis

Guest’s invoice consists of rented rooms. Each rented room have a type of room. When system calculates price for rented

rooms, it sumarizes the price for each room. For each room system identifies which days

belongs to special offer and which days has common price.

DB model - Invoicing – Rented rooms

Page 85: Specification Czech team Hotels Duif and Duinpan

NadpisVision document

Page 86: Specification Czech team Hotels Duif and Duinpan

NadpisVision document

Document describes general vision of software It identifies stakeholders of future system and

their key needs Contains an outline of the envisioned core

requirements, it provides the contractual basis for the more detailed technical requirements.

Page 87: Specification Czech team Hotels Duif and Duinpan

Nadpis

Introduction Purpose, Scope

Stakeholder Descriptions Summary, Profiles, Functions

Product Overview Perspective, Summary of capabilities

Product Features Quality Ranges

Localizability, Scalability, Usability, Availability, Capacity, Data Integrity

Precedence and Priority Other Product Requirements

System, Environmental, Performance, Security

Vision document - outline

Page 88: Specification Czech team Hotels Duif and Duinpan

NadpisRestriction and rules for data

Page 89: Specification Czech team Hotels Duif and Duinpan

Nadpis

Every input must be in correct format Example: Create room type

• title: string (0 - 50)• comment: text (0 - 4000)• Beds Count: integer• isValid: true/false

Example: Create invoice• Date From: format DD-MM-YYYY• Data To: format DD-MM-YYYY• Price: >= 0

Rules and restrictions for data

Page 90: Specification Czech team Hotels Duif and Duinpan

Nadpis

Every input must be in right format Example: Create Special offer

• Display on form NewSpecialOffer• Fields:• Date From : DD-MM-YYYY format• Date To : DD-MM-YYYY format• Price: number• Room Type: string format according to the type of class

RoomType attribute Title• SelectedDays: format 0000000 - 1111111, each bit

represent one day, week start with monday

Rules and restrictions for data

Page 91: Specification Czech team Hotels Duif and Duinpan

Nadpis

Create special offer

Rules and restrictions for data

Page 92: Specification Czech team Hotels Duif and Duinpan

NadpisSAD document

Page 93: Specification Czech team Hotels Duif and Duinpan

NadpisSAD document

The purpose of the software architecture document (SAD) is to provide information that is complementary to the code. This document shows four important views of future system

Scope of the SAD is whole system, how it works, distribution parts of the system and main architecture of the system. In every section of this document you can find description of that section and main features.

Page 94: Specification Czech team Hotels Duif and Duinpan

NadpisSAD document - views

Logical ViewAn abstraction of the design model that identifiesmajor design packages,subsystems and classes

Implementation ViewAn organization of static software modules (sourcecode, data files, components,executables, and others …)

Use-Case ViewKey use-case and scenarios

Deployment ViewVarious executables andother runtime componentsare mapped to the underlyingplatforms or computing nodes

Page 95: Specification Czech team Hotels Duif and Duinpan

Nadpis

Documentation Roadmap Purpose Scope

Architecture Use case view Logical view Deployment view Implementation view

Layers Data layer (database)

User interface System qualities

SAD document - outline

Page 96: Specification Czech team Hotels Duif and Duinpan

NadpisConclusion

Questions and Answers

Page 97: Specification Czech team Hotels Duif and Duinpan

NadpisConclusion

Thank you for your attention.