Název prezentace SpecificationCzech teamHotels Duif and Duinpan

Nadpis

1. Introduction

2. Software development

3. Specification

4. Conclusion

Table of contents

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

NadpisHow we did the work?

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?

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

Nadpis

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

1-4 weeks Intensive communication

In team With customer

Agile method

NadpisSCRUM process

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

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

Nadpis

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

Involved (called „Chickens“) Users Stakeholders Managers

SCRUM Roles (2)

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

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

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

NadpisOur SCRUM process based on RUP

NadpisIndetify stakeholders

Nadpis

Owner

Receptionist

Facility manager

Guest

Admin

Indetify stakeholders

Nadpis

Owner

Description Owner(s) of the hotel

Responsibilities Statistic and management functions

Indetify stakeholders

Nadpis

Receptionist

Description Subject who works in reception

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

reservations

Indetify stakeholders

Nadpis

Facility manager

Description Subject who works at some facility E.g.

Sauna, bar, bowling, tenis, etc.

Responsibilities Facility reservations, facility management

Indetify stakeholders

Nadpis

Guest

Description A client of the hotel

Responsibilities Reservations

Indetify stakeholders

Nadpis

Admin

Description Subject who maintains the system

Responsibilities To maintain the system

Indetify stakeholders

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

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

NadpisComunication with customer

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

NadpisFunctional requirements (FR)

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?

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

Nadpis

Domain analysis Group work Brainstorming Observation Scenarios …

Techniques and approaches for RE

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

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

Nadpis

Prioritization helps to identify the most valuable requirements

Precedence and Priority

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)

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)

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

NadpisOur precedences and priorities (2/2)

Priority 3 Handle facilities Manage services

Priority 4 Manage manager overviews

NadpisNon functional requirements

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

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

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

Nadpis

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

FURPS based NFR in our spec.

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

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.

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.

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.

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.

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.

NadpisUse cases

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

Nadpis

Specification contains 36 main functions described by use cases

Use cases were made in CaseComplete 2010 program

Use cases

Example of usage

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)

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

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

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

NadpisUML sequence diagram

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

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

NadpisDefine architecture

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

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

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

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

NadpisDesign GUI

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

NadpisGUI Design

New employee

Nadpis

New special offer

GUI Design

Nadpis

New room type

GUI Design

NadpisStructural view

Nadpis

Static entities are identified in use cases.

Using Use cases to generation class diagram

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

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

NadpisObject-relational mapping

Nadpis

Invoice class is transformed to Invoice table.

Invoice is composed by InvoiceItem classes.

Tables Charge, FacilityReservation, RentedRoom inherits from InvoiceItem.

Object-relational mapping

NadpisObject-relational mapping

NadpisDB model

NadpisDB model - Security

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

NadpisDB model - Making a reservation

Nadpis

Guest reservation is stored in table ‘Reservation‘.

Reservation consists of reserved room types.

DB model - Making a reservation

NadpisDB model - Invoicing

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

NadpisDB model - Invoicing – Rented rooms

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

NadpisVision document

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.

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

NadpisRestriction and rules for data

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

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

Nadpis

Create special offer

Rules and restrictions for data

NadpisSAD document

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.

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

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

NadpisConclusion

Questions and Answers

NadpisConclusion

Thank you for your attention.