slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Specification Czech team Hotels Duif and Duinpan PowerPoint Presentation
Download Presentation
Specification Czech team Hotels Duif and Duinpan

Loading in 2 Seconds...

play fullscreen
1 / 97

Specification Czech team Hotels Duif and Duinpan - PowerPoint PPT Presentation


  • 264 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Specification Czech team Hotels Duif and Duinpan


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. Specification Czech team Hotels Duif and Duinpan

    2. Table of contents • Introduction • Software development • Specification • Conclusion

    3. Introduction Our team made the specification of Hotels Duif and Duinpan in Nederland. We sent our specification to Sweden team and they implemented the prototype.

    4. How we did the work?

    5. Howdidwework? • We chose SCRUM methodology with RUP elements • SCRUM is not an acronym, it comes from rugby • It is method usedatthe beginning ofmatch, in which the forwards of each team crouch side by side with locked arms; Game starts when the ball isthrown in between them and the two sides compete for possessionofit.

    6. SCRUM • 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

    7. Agilemethod • Trying to minimize risks • Developing in iterations • Developing in short time periods • 1-4 weeks • Intensive communication • In team • With customer

    8. SCRUM process

    9. SCRUM Meetings • 3 types of meetings • Planning – beforethe sprint starts • Review – in theendofthe sprint • Retrospective – evaluatingthe last sprint • We mergedthem into one type ofmeeting • Meeting was held every Thursday • Westartedevery meeting withreview • Thanwe did a retrospective (what we did wrong/well) • Finally we planned work for next week

    10. SCRUM Roles • Thereis no classicprojectmanager in SRUM methodology • Team activities are driven by SCRUM master • Team participate in projectplanning • Tasks are notbeingassigned, team members chooses them

    11. SCRUM Roles (2) • Committed role (called „Pigs“) • Project owner • SCRUM master • Team • Involved (called „Chickens“) • Users • Stakeholders • Managers

    12. Rolesfairytale • 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."

    13. RUP elements • 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

    14. RUP elements • RUP life cycle consists of: • Inception • Indentify stakeholders and their needs • Understand requirements • Elaboration • Wehavebeencreatingspecificationfollowingrequirements • Construction • Transfer use case into sophisticated software (CaseComplete) and made some documents • Transition • Send specification to customer and implementation team

    15. Our SCRUM process based on RUP

    16. Indetifystakeholders

    17. Indetify stakeholders • Owner • Receptionist • Facility manager • Guest • Admin

    18. Indetify stakeholders Owner • Description • Owner(s) ofthe hotel • Responsibilities • Statistic and management functions

    19. Indetify stakeholders Receptionist • Description • Subject who works in reception • Responsibilities • Reservations, check-in, check-out, invoicing, facility reservations

    20. Indetify stakeholders Facility manager • Description • Subject who works at some facility E.g. Sauna, bar, bowling, tenis, etc. • Responsibilities • Facility reservations, facility management

    21. Indetify stakeholders Guest • Description • A client of the hotel • Responsibilities • Reservations

    22. Indetify stakeholders Admin • Description • Subject who maintains the system • Responsibilities • To maintain the system

    23. Indetify stakeholders • Matrix indicates which functions can use each user (1/2)

    24. Indetify stakeholders • Matrix indicates which functions can use each user (2/2)

    25. Comunicationwithcustomer

    26. Comunication with customer • Comunicationwithcustomersallowus to specified software exactly as he want. • WithMrs. Cupidowehavechoosen to comunicate via e-mail, sowewereable to discusschangesand her specificneeds. And also, shecouldcontrolourprogressandhowthefuturesystemwill look like. • Thekey part iscommunicationwithcustomer

    27. Functionalrequirements (FR)

    28. Whatis FR goodfor? • Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions thesystem is required to perform.

    29. Requirementselicitation • 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

    30. Techniques and approaches for RE • Domain analysis • Groupwork • Brainstorming • Observation • Scenarios • …

    31. FR example 1 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 willcreate 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.

    32. FR example 2 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..

    33. Precedence and Priority • Prioritization helps to identify the most valuable requirements

    34. Prioritization providessupport for: (1/2) • 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

    35. Prioritization providessupport for: (2/2) • 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

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

    37. Our precedences and priorities (2/2) • Priority 3 • Handle facilities • Manage services • Priority 4 • Manage manager overviews

    38. Non functional requirements

    39. NFR - introduction • 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.

    40. FURPS as model for NFR • 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

    41. FURPS - about • 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.

    42. FURPS based NFR in our spec. • Localizability • System support Multicurrency • System can be translated into multiple languages.

    43. FURPS based NFR in our spec. • Localizability • System support Multicurrency • System can be translated into multiple languages. 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). Why is it important?

    44. FURPS based NFR in our spec. • 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.

    45. FURPS based NFR in our spec. • 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).

    46. FURPS based NFR in our spec. • System Requirements • Server side: • Software Server systemssupported: Windows XP professional, Windows 2003 Server, Windows Vista Professional, Windows 2008 Server, Windows 7 Professional orUltimate, Microsoft SQL Server 2005, .NET Framework 3.5 installed. • Client station (foremployee): • Software requirements: Windows based system - Windows XP or newer with .NET Framework 3.5 installed.

    47. FURPS based NFR in our spec. • Benefitsanddisadvantagesofourplatformrecommendation: • .NET iswideplatformanditiscontinuouslyinnovatedandmaintainedandwehavevastand positive experiencewiththisplatform • .NET platformprovidesstrong type environmentandthere are many extensionsforit • .NET isexpensivedevelopmentplaform • .NET isverytightconnected to other Microsoft‘s products

    48. FURPS based NFR in our spec. • 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.

    49. Use cases

    50. Use cases • Use cases describe the interaction between one or more actorsand 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 Withdraw Money Customer Bank System Check Balance