KMITL OSRS Document for ISAD by Nathan Yiangsupapaanontr

KMITL Online Space Reservation System

A project by Kavin Ruengprateepsang Kunanon Srisuntiroj Thitipat Worrarat Nathan Yiangsupapaanontr Pornprom Kiawjak

59070009 59070022 59070043 59070087 59070113

Prepared for Information System Analysis and Design Course of 2017 Assist. Prof. Dr. Manop Phankokkruad Assist. Prof. Dr. Boonprasert Surakratanaskul

Faculty of Information Technology King Mongkutâ&#x20AC;&#x2122;s Institute of Technology Ladkrabang

System Request P roject nam e R equested by Em ail

KMITL Online Space Reservation System Kunanon Srisuntiroj 59070022@it.kmitl.ac.th

Business Requirements The traditional methods for space reservation in King Mongkut's Institute of Technology Ladkrabang require unnecessarily complicated, slow and repetitive processes. Once a requester needs a space, or usually, a room, he or she must contact a room manager directly to check for availabilities. The room manager then needs to look up through calendars, spreadsheets, or even papers (depending on each manager) to make sure the room hasnâ&#x20AC;&#x2122;t already been reserved at a certain time. If the room is available, then the requester receives a reservation form and fills it up. The form needs physical signatures from various persons, e.g. teachers, staff, and authorities, before being returned to the room manager which will register the reservation on their records to finish the process. The Online Room Reservation System is the system to improve this workflow by allowing the whole process to be done online. This means any student, teacher, and staff in the institute can reserve a room at any time and from any place theyâ&#x20AC;&#x2122;re comfortable with. Just log in with an existing organization account, search for a room, select an available time, then submit a request and wait for an approval.

Functionalities 1. Students, teachers, and staff in the institute can request spaces online. 2. Users can check space availabilities and present a reservation proof to relevant authorities. 3. Users can scan a QR code in front of a room to view its information and interact with the system. 4. Users can make a recurring reservation. 5. Users can edit or cancel their requests right away, and authorities will be notified. 6. The system can notify authorities and staff to approve or deny room requests. 7. The system is easy to use and supports mobile devices. 8. The system supports role and permission management to suit the variable requirements of each faculty.

Business Values Tangible -

Reduces the use of paper and printer ink. Speeds up request time and simplifies the request process.

Intangible -

Creates user satisfaction. Reduces human errors from the staff and the users. Minimizes overlapping requests created by redundant information.

Special constraints The user needs to be connected to the Internet.

Planning Write system request

Collect system requirements

Create work plan

Analysis

Write use case diagram

Write activity diagram

Write data flow diagram

Write ER diagram

Planning

Plan Website Interface

Plan view space function

Plan reservation and approval function

Plan space management function

Plan user roles and permission function

Implementation

Implement view space function

Implement reservation and approval function

Implement space management function

Implement user role and permission function

1.2

1.3

2.1

2.2

2.3

2.4

3.1

3.2

3.3

3.4

3.5

4.1

4.2

4.3

4.4

Task Name

1 1.1

No.

3.4

3.3

3.2

3.1

5.3

5.2

5.1

1.1

Predecessor

1, 2, 3, 4, 5

1, 4, 5

1, 2, 5

2, 3, 4

1, 2, 5

1, 2

2, 3

Assignee

08 Apr 18

29 Mar 18

19 Mar 18

09 Mar 18

06 Apr 18

27 Mar 18

17 Mar 18

07 Mar 18

01 Mar 18

20 Feb 18

13 Feb 18

06 Feb 18

29 Jan 18

10 Jan 18

17 Jan 18

10 Jan 18 10 Jan 18

Start

12 Apr 18

02 Apr 18

23 Mar 18

13 Mar 18

12 Apr 18

07 Apr 18

28 Mar 18

18 Mar 18

08 Mar 18

06 Mar 18

07 Apr 18

28 Feb 18

19 Feb 18

12 Feb 18

05 Feb 18

28 Feb 18

28 Jan 18

28 Jan 18 16 Jan 18

Finish

18 6

Duration (Days)

Test reservation and approval function

Test space management function

Test user roles and permission function

Delivering and Documentation

Write documentation

Prepare presentation

Write project summary

5.2

5.3

5.4

6.1

6.2

6.3

Kavin Ruengprateepsang Kunanon Srisuntiroj Thitipat Worrarat Nathan Yiangsupapaanontr Pornprom Kiawjak

Test view space function

5.1

Assignee No. 1 2 3 4 5

Testing

Task Name

No.

59070009 59070022 59070043 59070087 59070113

6.1, 6.2

4.4

4.3

4.2

4.1

Predecessor

2, 3

2, 3, 4

1, 3, 5

1, 2, 3, 4, 5

Assignee

16 Apr 18

18 Apr 18

16 Apr 18

13 Apr 18

03 Apr 18

24 Mar 18

14 Mar 18

Start

22 Apr 18

15 Apr 18

05 Apr 18

26 Mar 18

16 Mar 18

15 Apr 18

Finish

Duration (Days)

14 days

1.3 Create work plan

5 days 7 days

2.3 Write data flow diagram

2.4 Write ER Diagram

2 days 2 days 2 days

3.3 Plan reservation and approval function

3.4 Plan space management function

3.5 Plan user roles and permission function

3 days 5 days

4.3 Implement space management function

4.4 Implement user roles and permission function

3 days 2 days

5.3 Test space management function

5.4 Test user roles and permission function 6 days 4 days 6 days

6.1 Write documentation

6.2 Prepare documentation

6.3 Write project summary

5 days

2 days

5.2 Test reservation and approval function

6 Delivering and Documentation

3 days

5.1 Test view space function

23 days

5 days

4.2 Implement reservation and approval function

5 Testing

3 days

4.1 Implement view space function

25 days

2 days

3.2 Plan view space function

4 Implementation

4 days

3.1 Plan website interface

27 days

5 days

2.2 Write activity diagram

3 Planning

6 days

2.1 Write use case diagram

23 days

9 days

1.2 Collect system request

2 Analysis

5 days

13 days

73 days

February 2018 March 2018 April 2018 6 8 10121416182022 24 26 28 30 1 3 5 7 9 111315171921 23 25 27 1 3 5 7 9 11131517192123 25 27 29 31 2 4 6 8 10121416182022 24 26

Duration January 2018

1.1 Write System Request

1 Planning

Space Reservation System

Name

Requirement Documentation Our team has examined the requirements that most faculties require to reserve a space. We collected the requirements from real staff and students all over the campus through a number of interviews and document analysis. You can find our analysis as follows.

Issues of the Current System In the current workflow, there are many steps to creating a reservation request. This may create a lot of difficulties to space requesters. So, administrators need some helper methods to process all the many requests. For example, writing it down on a big whiteboard; filling it into the Outlook service and many other methods.

Workflow of the Current System STEP 1: ASK AN ADMINISTRATOR ABOUT A SPACE’S AVAILABILITY A requester needs to ask a relevant administrator about his desired space’s availability and gives his requirements to the administrator to choose a space that is right for the requester. Administrators will have their own constraints and space selection procedures—they might choose one space over the others. STEP 2: FILL-IN A FORM via a proposal

via a form

via a proposal & a fee

The proposal includes rea- The form includes struc- An outsider is required to sons to use the space, tured questions that are re- make a payment in addiequipment requirements quired to request a space. tion to writing a proposal. and a brief time schedule. STEP 3: ASK FOR AN APPROVAL FROM AUTHORITIES The forms will be forwarded to the dean and/or head of academic-support staff (depending on each faculty’s reservation guidelines. If the request does not conflict or does not contravene the faculty’s reservation guidelines, it is approved. Then, the approver will be notified by the administrator for the approval. STEP 4: CONFIRM AND VERIFY After the approval, the requester may use the space as requested. All the requested equipment is supplied to the space. However, some of the authorities—maids, security guards, etc.—are not yet notified about the space usage, so an approved copy of the form is given to them to confirm.

Rules and Conditions -

The current reservation process varies by each authority. The current reservation process requires physical signatures from an authority. Each reservation requires various formats of request forms.

Issues of the Current System -

Too many steps in order to reserve. Form fragmentation among faculties. Reservation information redundancy may lead to conflicts and overrides. Unnecessarily exporting a schedule consumes too much time.

Wanted Features -

A feature that will reduce the workload of administrators on the system. Reserving without physical contact and approval from approvers. Administrators can provision every part of the service easily and can export transaction results.

Features of the New System -

Users can quickly search for a space. Users can reserve a space using any internet-connected device. Users can report issues to administrative staff faster. Administrators can manage users and service freely. Administrators can export the new schedule for further usage and logging.

Data Storage Requirements of the New System 1. A relational database for keeping service data. 2. A time series database for logging and further audits. 3. File systems for other file formats that are not supported by the relational database system.

Documents Needed in the Old System TYPE OF DOCUMENT Schedules R eservation validation H istory logging

A REQUESTER

AN AUTHORITY

AN APPROVER

A new timetable (brief)

A new timetable

A reservation form

Reservation history

As we can see, the current process seems complicated. Moreover, this also varies across faculties. The next section is our summarized analysis of each administrative area.

Reservation Processes for Each Administrative Area Below are the reservation processes of six sampled administrative areas.

1. Faculty of Information Technology 1.1 A cadem ic Support An authority will receive a timetable from the Central Office. The authority will store the data in Microsoft Outlook and Google Calendar to further make a public timetable. M03

M04

Database

ISAD

203

204

207

9:00 – 10:00 10:00 – 11:00 11:00 – 12:00

Physics 101

12:00 – 13:00 13:00 – 14:00 A brief timetable for demonstration purpose from IT’s Administrative Department. For the timetables of the maids, the authority will need to re-input the same data in Microsoft Excel so that all data can fit tightly on a single page.

M03

M04

203

204

207

303

304

AUDI

9:00 10:00 11:00 12:00 13:00 Black: IT

Grey: Aeronautics Light grey: outside lecturers

Based on this timetable, if there is an immediate reservation cancellation, the maids will not acknowledge the timetable change. This means academic-support resources will be left unused and not available for use in other rooms. Moreover, many authorities do not have the same schedule; they might overbook the room and the conflicts will be dealt with difficulties. Additionally, there are repair forms present in all rooms for the lecturers to fill in, so they can report to the repair authorities with ease. But based on history, most of them were not acknowledged. So, the lecturers or the users that used the room would still use broken equipment, resulting in a non-learning-friendly environment, and the lecturers might need to buy a replacement upfront on their own.

1.2 IT Support IT Support maintains the facultyâ&#x20AC;&#x2122;s computers and laboratories. Information reported to IT Support is mostly repair tickets, which are organized by the Academic Support team. Another type of requests made by lecturers is software installation. For example, an English lecturer wants to install teaching material software. He cannot do it by himself, so he has to call IT Support and teaching time is then wasted by the delay of the support request. Many times, IT Support does not get any information about how and why a computer is broken, because they donâ&#x20AC;&#x2122;t directly talk with the lecturers that encounter the problem. Instead, Academic Support will contact IT Support, so many issues are left unknown and may not be resolved. We asked them how we could enhance the service with our system, and they came up with these ideas: -

An ability to contact IT Support directly and give a precise detail about an issue. An ability to contact IT Support for software installation before a usage period. An ability to note what an actual issue is and what equipment is currently broken.

They hoped that the system had reporting features to let users contact them directly and understand what was happening.

1.3 The M aids We were told that the maids were having an issue with cancellation. First, a cancellation occurred at Educational Support and after the reservation was canceled within a day, they did not get any notification on the schedule change. The maids normally have their own schedules (which are Educational Support’s printed schedules). They will unlock a room and switch on the air conditioners before the scheduled time. So, if they are notified of a reservation cancellation before the scheduled time, energy can be saved, and they will not have to unlock the room or recheck the room. Sometimes, lecturers that are trustworthy to the maids can tell them to open a room before they get their reservation confirmed. This is a violation of the policy as the reservation is not yet confirmed. 1.4 The R equest Form Faculty of Information Technology’s request form is not derived from other faculties’ form. The form asks for: -

a a a a

requester’s name, surname, and student or staff identification number reservation purpose space name, time to reserve, date to reserve, recurrences contact number

The faculty will approve the reservation when these conditions are met: -

It has a signature of an assistant lecturer (or a lecturer can self-sign this block). It has a signature of Academic Support staff. It has a signature of the Vice President of Faculty of Information Technology (for students and lecturers who will use a space multiple times).

For lecturers and students not from Faculty of Information Technology or its tenants, a formal form is required, and a reservation must be placed in advance. All instantaneous requests are mostly rejected. The problem of using a form is that students need to walk through the process manually and get staff’s signatures physically. The one who submits the form first is the one that gets the space. This process can cause schedule overlaps.

2. Administration and Management College (AMC) 2.1 Overview Normally, this college/faculty has a very few classrooms, so their schedule is quite reused and not much run into trouble of needing a room. In need of more rooms, they will use a room in Princess Sirindhorn’s General Instruction Building. Based on their request form, they have the same procedures and form requirements as other faculties. This means other faculties’ forms or written-type form can be used with AMC seamlessly. They also have a room usage schedule in front of every room that can be reserved. We have seen this format of schedule at Princess Sirindhorn’s General Instruction Building Educational Support, which was exported and printed from Office of Registrar website. Room 403, AMC Building | Seat capacity: 42 seats (6 x 7)

Day

9:00 – 10:00

10:00 – 11:00

11:00 – 12:00

12:00 – 13:00

13:00 – 14:00

14:00 – 15:00

15:00 – 16:00

16:00 – 17:00

17:30 – 18:00

18:00 – 18:00

Sun Mon

POM

Tue Wed Thu

SCLM MIS

MIS

Fri Sat

An example schedule of Administration and Management College.

19:00 – 19:30

2.2 The R equest Form The request form requires: -

a requester’s name, major, year a space name required seats

a reservation purpose a duration additional equipment

3. Supplies Division 3.1 Overview Supplies Division supports external and internal reservations for a variety of uses. They deal with requesters directly and contact the teams in each building about the requesters’ requirements. They manage: 1. 2. 3. 4. 5. 6.

5,000-Seat Convention Hall Faculty of Engineering’s Auditorium KMITL’s sports facilities KMITL’s dormitory Innovation building The areas around the Office of President

Reservation of the Convention Hall and the Auditorium requires a small fee for students and lecturers for educational uses. For external sources or profit-based events, there is another rate of charge. The division tries to bring in companies that want to use its facilities and collects them with a charge, so it deals with external sources directly. The companies, the lecturers and the students wanting to make a reservation must write a formal agreement and send it directly to the division. The division will try to manage and find a schedule that matches their requirements. Then, the requester must make an upfront payment for the reservation. These procedures can take weeks to process, so most instantaneous requests are much likely to be rejected. The division told us that they had no service to show the schedules to external sources. Requesters who want to make a reservation must call them first to check the schedules. They are still finding a way to let requesters view the schedules by themselves. They are currently using Google Calendar to manage reservations. Another issue in their workflow is an additional requirement. Some requesters want a maid and a guard, so the division must collaborate with those staff for an overtime agreement and payment. In this type of requests, the requester must make a reservation in advance of weeks prior to the reserved date and must detail it in the agreement.

3.1 5,000-Seat C onvention H all Form A nalysis To reserve the Convention Hall, the form requires basic information such as -

a requester’s name a requester’s information

a reservation purpose number of attendees

additional equipment additional staff

With an additional question for

additional security guards and audio technicians

tables, chairs an additional reception room

As the request is counted as non-educational or/and overtime, one who wish to use the convention hall, they might need to pay for additional cost for hiring a security guards and maid, as they will take it as overtime work.

4. Faculty of Engineering, ECC Building 4.1 Electrical Engineering Every room in the second and the third floors of ECC building is managed by Electrical Engineering. They are all laboratories and no lecture room in this building. All lecture rooms are in the 12-floor building and many other buildings. With these few rooms in this building, there is no need for a reservation. Lecturers are assigned to each laboratory and schedules are managed by the Faculty of Engineering instead. There is no case for overlapping or out-of-schedule reservations; all of those reservations are forwarded to other buildings instead. They normally write down schedules on a big whiteboard, filled with names of the laboratories, schedule times and classes that use that laboratory. Those are for dealing with staff from the Faculty of Engineering and for the maids to open the rooms. This building also has lecture rooms for Graduate and Ph.D. students. Those who want to use the room can reserve them in an instant and it will be approved immediately when there is a lecturer actually using the room. There is no case for overlapping reservation because those lecture rooms are rarely used. 4.2 C om puter Engineering In ECC building, the rooms on floors 7 to 9 are under Computer Engineering. Ten of them are laboratories and two are lecture rooms for Graduate and Ph.D. students. Based on their uses, there are very few conflicts of reservation time—mostly with the computer laboratories that are generally used in multiple subjects.

They used to have a service that lectures can check for room availability, but unfortunately, it was discontinued. With the old service: Users could check for room availability by clicking a drop-down button, which asked for a duration, a room, and a date. After filling in the form, it would return “Available” or “Not Available”. Lecturers and staff could add their own lab schedule. The service resided on the faculty’s website and was login-based, which blocked access from students and lecturers outside of Computer Engineering. The staff could see the schedules of each room in a time schedule format.

They told us that the service was unpopular, so we asked them why lecturers avoided using it. The service was hard to use. Lecturers could just walk to the staff and make a reservation. Most lecturers wanted to find a schedule on their phones, but the service’s user interface did not support small screens. The service was slow to load, thus walking was faster. Lecturers wanted to talk instead of using the service on-line. There were a very few overlapping reservations, so most reservations would be approved.

Ultimately, they decided to use Microsoft Excel instead of using the old service. It was easier, and they could customize it whatever they like their schedule to be. And they came up with this format of showing time schedules. ROOM 802

Date Time

9.00 – 12.00

Monday

13.00 – 16.00 Entrepreneurship

Tuesday

Design

Computer Programming

Wednesday

Probability

Thursday

Data Structures

Friday

Calculus

Computer Programming

An example schedule from Computer Engineering.

Room Usage Schedule System Analysis The Room Usage Schedule System displays a schedule of room usage of each faculty. Most faculties either don’t update their room usage or have them hidden, forcing all faculties to create their own schedules by themselves. Rooms that are visible to all users are mostly large lecture halls and are from the faculties that constantly push new information to the service (for example, Prince Sirindhorn’s General Instruction Building). The schedule gives information about: -

subjects that will use a room for a whole semester dates and times of use

The schedule, on the contrary, does not give information about events that will use a room only once or twice.

Faculty of Information Technology’s Auditorium usage schedule. (From http://www.reg.kmitl.ac.th/room_v20/index.php)

Students’ Study Schedules The study schedules inform students of which room a subject uses. Based on this information, each space schedule can be constructed. Every faculty opens these schedules to the public where they are accessible from KMITL website. As a lecturer, this is the only on-line way to view room availability. The schedule is complex, and students cannot create their own timetables easily. They need to use Microsoft Excel or online calendar services to help them make their own timetables. Yet, they still have to do it manually.

คุ ณคุ อผุ เยุ ุ ยมชมคนทุ 44,092,146 วุ นทุ 25 มกราคม 2561 เวลา 10:34:03 น.

ปรุ ญญาตรุ

บุ ณฑุ ตศุ กษา ตารางเรุ ยน ตารางสอบ รายวุ ชาทวไป ุ

ปุการศุ กษา : ภาคการศุ กษา : คณะ : ภาควุ ชา : สาขาวุ ชา : ชุ นปุ : รุ ปแบบการจุ ด เรุ ยง :

แสดงตาราง

2560 2 วุ ศวกรรมศาสตรุ <<ทุ กภาควุ ชา>> <<ทุ กสาขาวุ ชา>> <<ทุ กชุ นปุ>> เรุ ยงตามรหสวุ ุ ชา

คุ นหาวุ ชา

ดาวนุ โหลด :

ตารางสอบ: ปลายภาค ตารางเรุ ยน ตารางสอบ คณะเทคโนโลยุ สารสนเทศ ประจุ าภาคเรุ ยนทุ 2 ปุการศุ กษา 2560 ภาควุ ชา เทคโนโลยุ สารสนเทศ สาขาวุ ชา เทคโนโลยุ สารสนเทศ﴾ภาคปกตุ ﴿ ชุ นปุทุ 1

รหุ สวุ ชา ชุ อวุ ชา หนุ วยกุ ต﴾ทฤษฎุ ปฏุ บุ ตุ ﴿

ตารางเรุ ยน กลุ ม ุ หุ อง

วุ น เวลา

ตารางสอบกลางภาค อาจารยุ ผุ สอน ุ

ว ด ป

ตารางสอบปลายภาค

เวลา

ว ด ป

เวลา

หมายเหตุ

หุ องเรุ ยน

ตุ ก

226

ผศ.ดร.สมเกุ ยรตุ วุ งศุ รุ 13:3016:30 13:3016:30 รุ บ80คน พุ ทุ กษุ , อ. 27 ก.พ. 61 พ. 9 พ.ค. 61 น. น. ﴾ลง56﴿ ผศ.ดร.ปานวุ ทยุ ธุ วะนุ ตุ

ผศ.ดร.สมเกุ ยรตุ วุ งศุ รุ 13:3016:30 13:3016:30 รุ บ60คน พุ ทุ กษุ , อ. 27 ก.พ. 61 พ. 9 พ.ค. 61 น. น. ﴾ลง58﴿ ผศ.ดร.ปานวุ ทยุ ธุ วะนุ ตุ

Audi

ผศ. ดร.ภุ ทรชุ ย ลลุ ต 13:3016:30 13:3016:30 รุ บ120คน ตุ ดตุ อผุ ดุ ุแลระบบไดุ ทุ registrar kmitl.ac.th โรจนุ วงศุ , จ. 26 ก.พ. 61 อ. 8 พ.ค. 61 น. น. ﴾ลง116﴿ King Mongkut's Institute of Technology Ladkrabang. ทยุ ผศ.ดร.ปานวุ ธุ วะนุ ตุ

M 03

ดร.สุ ภวรรณ ทุ ศน ประเสรุ ฐ

M 03

ดร.สุ ภวรรณ ทุ ศน ประเสรุ ฐ

M 03

L203

วุ ชาบุ งคุ บ MATHEMATICS FOR 3﴾30 อ. 13:0016:00 น.﴾ท﴿ 06016302INFORMATION 1 6﴿ [1] TECHNOLOGY **หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 80 คน﴿ ﴾ลง56﴿ เฉพาะรหุ ส 6007000160070063 ﴾ไมุ รุ บนศ.อุ น﴿ เฉพาะ นศ. รหุ ส58070129 ﴾ไมุ รุ บนศ.อุ น﴿ 2

06016303

อ. 09:0012:00 น.﴾ท﴿

[1]

226

**หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 60 คน﴿ ﴾ลง58﴿ เฉพาะรหุ ส 6007006460070184 ﴾ไมุ รุ บนศ.อุ น﴿ DISCRETE สถาบุ 3﴾30 จ. 13:0016:00 น.﴾ท﴿ นเทคโนโลยุ พระจอมเกลุ าคุ ณทหารลาดกระบุ ง 1 าเจุ MATHEMATICS 6﴿ [1] นทรุ ชุ น 2 อาคารกรมหลวงนราธุ วาสราชนครุ

ตุ ดตุ อสุ านุ กทะเบุ ยนฯ โทร :คลุ ก

เลขทุ 1 ซอยฉลองกรุ ง 1

**หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ แขวงลาดกระบุ ง เขตลาดกระบุ ง บ 120 คน﴿ ﴾ลง116﴿ พฤ. 09:0011:00 น.﴾ท﴿ MULTIMEDIA กรุ 3﴾22 งเทพฯ 10520 06016311 1 [1] TECHNOLOGY 5﴿ **หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 41 คน﴿ ﴾ลง38﴿ เฉพาะรหุ ส 6007008460070184 ﴾ไมุ รุ บนศ.อุ น﴿ พฤ. 12:0014:00 น.﴾ท﴿

2 [1] **หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 40 คน﴿ ﴾ลง38﴿ เฉพาะรหุ ส 6007000160070041 ﴾ไมุ รุ บนศ.อุ น﴿

โทรสาร : 023298204

น.

ส. 3 มุ .ค. 61

13:3016:30 น.

อ. 15 พ.ค. 61

13:3016:30 รุ บ40คน น. ﴾ลง38﴿

ดร.สุ ภวรรณ ทุ ศน ประเสรุ ฐ

ส. 3 มุ .ค. 61

13:3016:30 น.

อ. 15 พ.ค. 61

13:3016:30 รุ บ41คน น. ﴾ลง39﴿

ดร.สุ ภวรรณ ทุ ศน ประเสรุ ฐ

ส. 3 มุ .ค. 61

13:3016:30 น.

อ. 15 พ.ค. 61

13:3016:30 รุ บ40คน น. ﴾ลง39﴿

L203

ดร.สุ ภวรรณ ทุ ศน ประเสรุ ฐ

ส. 3 มุ .ค. 61

13:3016:30 น.

อ. 15 พ.ค. 61

13:3016:30 รุ บ40คน น. ﴾ลง39﴿

L203

ดร.สุ ภวรรณ ทุ ศน ประเสรุ ฐ

ส. 3 มุ .ค. 61

13:3016:30 น.

อ. 15 พ.ค. 61

13:3016:30 รุ บ40คน น. ﴾ลง38﴿

Audi

ผศ.ดร.ปานวุ ทยุ ธุ วะนุ ตุ , 13:3016:30 พ. 28 ก.พ. 61 ผศ.ดร.กุ ตุ สุ ชาต พสุ ภา น.

ศ. 11 พ.ค. 61

13:3016:30 รุ บ121คน น. ﴾ลง115﴿

A study schedule of an Information Technology student. 3

พฤ. 14:0016:00 น.﴾ท﴿

[1] **หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 41 คน﴿ ﴾ลง39﴿ เฉพาะรหุ ส 6007004260070083 ﴾ไมุ รุ บนศ.อุ น﴿ ศ. 09:0011:00 น.﴾ป﴿

4 [3] **หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 40 คน﴿ ﴾ลง39﴿ เฉพาะรหุ ส 6007000160070041 ﴾ไมุ รุ บนศ.อุ น﴿

ศ. 12:0014:00 น.﴾ป﴿

5 [3] **หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 40 คน﴿ ﴾ลง39﴿ เฉพาะรหุ ส 6007004260070083 ﴾ไมุ รุ บนศ.อุ น﴿ 6

ศ. 14:0016:00 น.﴾ป﴿

[3] **หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 40 คน﴿ ﴾ลง38﴿ เฉพาะรหุ ส 6007008460070184 ﴾ไมุ รุ บนศ.อุ น﴿ พ. 09:0011:00 น.﴾ท﴿ COMPUTER 3﴾22 06016315 1 [1] PROGRAMMING 5﴿ **หมายเหตุ ** นุ กศุ กษาหลุ กสุ ตร พ.ศ.2559 ﴾ รุ บ 121 คน﴿ ﴾ลง115﴿

น.

﴾ลง38﴿

Robin Room Reservation System Robin is an enterprise-grade space reservation service. It has the same reservation procedures as our upcoming service, as it lets users search for an available space and reserve it. Their constraints exclude the approver mechanics, but other parts are quite the same. Robin is a subscription service priced at $5 per month per user, which may rack up to a whopping $100,000 annually. The service also includes APIâ&#x20AC;&#x2122;s that allow Internet of Thing devices to display current room usage and upcoming reservations. It is advertised to work on any screen size and even e-ink screens. Robin has an easy-to-use user interface. A user can click on a space to see more information about the space or click on a timeframe to reserve it right away.

Robinâ&#x20AC;&#x2122;s user interface

Hardware Specifications CLIENT Operating Windows, macOS, or a Linux distribution System Special Software Web browser (eg. Google Chrome, Mozilla Firefox, Internet Explorer 9 or more, Apple Safari) Hardware 4GB of memory 50GB of storage A dual-core processor Network 20Mbps Internet connection

WEB SERVER Operating Ubuntu or any Linux distribution System Special Software Node JS Hardware 2GB of memory 50GB of storage A real/virtual dual-core processor Network 1Gbps Internet connection

Application Server Operating Linux distribution System Special Software Java Runtime Environment (JRE) Hardware 2GB of memory 50GB of storage A real/virtual dual-core processor Network 1Gbps Internet connection

Database Server Operating Linux distribution System Special Software PostgreSQL Hardware 5GB of memory 250GB of storage Real / Virtual Dual Core Processor Network 2Gbps Internet connection

Online Space Reservat ion Syst em

Request a space

Cancel a request

Report a problem Guest

Client

Search and browse spaces

View report ed problems

Manage spaces Evaluat e request s

Approver

Manage Mat erial

Manage roles

Admin

Use Case Description Request a Space ID

Use Case Name

Request a space

Scenario

Client requests a space.

Triggering Event

Client wants to reserve a space.

Brief Description

To reserve a space, Client starts by choosing an available space based on their preferences. If the space requires an approval(s) before use, system will then notify Approver to decide whether to approve or reject the request.

Actor

Client

Related Use Case

Stakeholder

Client and Approver

Exception Condition

Another Client’s request gets approved before the request is sent.

Pre – Condition

Post – Condition

The system sends a notification to Approver to evaluate the request. Flow of Events

Client

No.

Choose a space

Submit a reservation request

2 3

Get notified about the request

System

Store the request

Use Case Description Page 1

Cancel a Request ID

Use Case Name

Cancel a request

Scenario

Client cancels a request or a reservation.

Triggering Event

Client wants to cancel a request.

Brief Description

Client cancels a request that has not been approved. If the space doesn’t require Approver, Client needs to cancel the reservation before a designated time.

Actor

Client

Related Use Case

Stakeholder

Client and Approver

Exception Condition

1. The request has been approved. 2. Client tries to cancel a reservation after a designated time.

Pre – Condition

A pending request is available in the system.

Post – Condition

The request will be marked as cancelled. Flow of Events

Client

No.

View pending requests

Choose a request

Submit a cancellation

Get notified about the cancellation result

System

Mark the request as cancelled

Notify Client about the cancellation result

Use Case Description Page 2

Report a Problem ID

Use Case Name

Report a problem

Scenario

Client reports a problem.

Triggering Event

When a user wants to report a problem to Admin.

Brief Description

Client can write a problem to the system which will be forwarded to a corresponding Admin.

Actor

Client

Related Use Case

Stakeholder

Client and Admin

Exception Condition

Pre – Condition

Post – Condition

System sends a notification to Admin to fix a problem. Flow of Events

Client

No.

Choose a space that client want to report

Submit a problem report

Client that have ‘admin’ permission will get notified with the report

System

Store the report

Serve the report to the ‘admin’ permission client

Use Case Description Page 3

Search and Browse Spaces ID

Use Case Name

Search and browse spaces

Scenario

Client views spaces’ details and availabilities.

Triggering Event

Client wants to view spaces’ details; e.g. availability, schedule, seats and amenities.

Brief Description

Client searches and browses through spaces. Each space shows its information (e.g. seats, available times, amenities) and options to reserve it or report its problem.

Actor

Client, Guest, Admin and Approver

Related Use Case

Stakeholder

Client and Approver

Exception Condition

Pre – Condition

Post – Condition

User can go to Reserve a Space. Flow of Events

Client Enter search filters

No.

System

1 2

See spaces matching the search filters

If satisfied, select a space to view its details

Find spaces matching the search filters

Use Case Description Page 4

Evaluate a Request ID

Use Case Name

Evaluate a request

Scenario

Approver views a reservation request, requested from user and evaluates it.

Triggering Event

Approver is notified of a new request.

Brief Description

Approver evaluates a pending request and accepts it or rejects it with a reason.

Actor

Approver

Related Use Case

Stakeholder

Approver and Client

Exception Condition

When there is no space to evaluate, this function will not be used.

Pre â&#x20AC;&#x201C; Condition

A pending request exists in the system.

Post â&#x20AC;&#x201C; Condition

1. The request is either marked as approved or rejected. 2. The system sends a notification to respective Client. Flow of Events

Approver

No.

View pending requests

Choose a request

Accept or reject the request

3 4

Get notified that the request is rejected or approved

System

Mark the request as approved or rejected. If there's enough approval, mark the request as approved, else wait for more Approver to approve

Use Case Description Page 5

View a Reported Problem ID

Use Case Name

View a reported problem

Scenario

Admin views a reported problem.

Triggering Event

Admin is notified of a new reported problem

Brief Description

When Client reports a problem, the system will notify Admin about the problem to take further actions.

Actor

Admin

Related Use Case

Stakeholder

Client and Admin

Exception Condition

Pre â&#x20AC;&#x201C; Condition

A problem report exists in the system

Post â&#x20AC;&#x201C; Condition

Flow of Events

Client

No.

View reported problems

Select a problem

2 3

See the selected problem

System

Find the selected problem

Use Case Description Page 6

Manage a Space ID

Use Case Name

Manage space

Scenario

When Admin wants to manage a space in the system.

Triggering Event

Admin wants to manage a space.

Brief Description

Admin has permissions to add, edit and delete spaces.

Actor

Admin

Related Use Case

Stakeholder

Admin and Client

Exception Condition

Pre â&#x20AC;&#x201C; Condition

Post â&#x20AC;&#x201C; Condition

Flow of Events User

No.

Choose an action to either add, edit and remove a space

Submit the chosen action

2 3

Get notified about the action result

System

Perform the action

Use Case Description Page 7

Manage a Material ID

Use Case Name

Manage a Material

Scenario

Modifying a material that bonds to a space

Triggering Event

Admin wants to add a material / bound material to a space / delete a material.

Brief Description

Managing a material to make it visible or delete from a space. User can reserve these material with the top of reserving a space.

Actor

Admin

Related Use Case

Stakeholder

Admin

Exception Condition

Pre – Condition

Post – Condition

Flow of Events

Admin

No.

Open ‘Material’ Dashboard

Create new or delete a current one

System

Add / Delete the material that admin select

Update the available material in department list

Use Case Description Page 8

Manage a Role ID

Use Case Name

Manage a role

Scenario

Admin can manage user roles and permissions.

Triggering Event

Admin wants to manage roles and permissions.

Brief Description

Admin has permissions to add, edit and delete roles.

Actor

Admin

Related Use Case

Stakeholder

Admin and Client

Exception Condition

Pre â&#x20AC;&#x201C; Condition

Post â&#x20AC;&#x201C; Condition

Flow of Events

Admin

No.

Choose an action to either add, edit or remove a role

Submit the chosen action

2 3

Get notified about the action result

System

Perform the action

Use Case Description Page 9

Request a space - Act ivit y Diagram Client

Syst em

Approver

Choose a space

Submit a reservat ion request

Get not if ied about t he request result

St ore t he request

Get not if ied about t he request

Cancel a request - Act ivit y Diagram Client

Syst em

View pending request s

Choose a request

Submit a cancellat ion

Mark t he request as cancelled

Get not if ied about t he cancellat ion result

Not if y Client about t he cancellat ion result

Report a problem - Act ivit y Diagram Client

Syst em

Admin

St ore t he report

Get not if ied about t he new problem report

Choose a space

Submit a problem report

Search and browse spaces - Act ivit y Diagram User

Syst em

Select t heir pref erences on space t ype

Find space t hat mat ched t heir crit eria

See t he result t hat mat ched t heir select ion

Show mat ched space t o user

User is not satisfied with result User satisfied with result

Select a space t o view space det ails

Evaluat e a request - Act ivit y Diagram Approver

Syst em

Client

Mark t he request as reject ed

Get not if ied t hat t he request is reject ed

View pending request s

Reject

Review a request

Approve

Record t hat Approver ID as approver of t hat space

Check if t here's enough approval

Not enough

Wait f or more Approver t o approve

Enough

Mark t he request as approved

Get not if ied t hat t he request is approved

View a report ed problem - Act ivit y Diagram Admin

Syst em

View report ed problems

Select a problem

See t he select ed problem

Find t he select ed problem

Manage spaces - Act ivit y Diagram Admin

Syst em

Choose an act ion

Add a space

Edit a space

Submit t he act ion

Get not if ied about t he act ion result

Remove a space

Perf orm t he act ion

Manage Mat erial - Act ivit y Diagram Admin

Syst em

Choose an act ion

Add a mat erial

Edit a mat erial

Submit t he act ion

Get not if ied about t he act ion result

Remove a mat erial

Perf orm t he act ion

Manage users - Act ivit y Diagram Admin

Syst em

View users

Choose a user

Assign a role or permission(s) t o t he user

Submit t he act ion

Get not if ied about t he act ion result

Perf orm t he act ion

client:Client

createdRequest

createRequest( input: CreateRequestInput)

createdRequest

:RequestPersist

isSuccess: Boolean

insert(entity: RequestEntity)

:RequestFacade

create(input: CreateRequestInput)

:RequestMutation

Request a space - Sequence Diagram

aClient:Client

isSuccess: Boolean

cancel(id: Uuid)

isSuccess: Boolean

:RequestPersist

setStatus (id: Uuid, status: RequestStatus)

:RequestFacade

Cancel a request - Sequence Diagram

:RequestMutation

cancelRequest(id: Uuid)

isSuccess: Boolean

Client

:ProblemFacade

isSuccess: Boolean

insert(entity: ProblemEntity)

Report a problem - Sequence Diagram

createdProblem

create(input: ReportProblemInput)

:ProblemMutation

reportProblem(input: ReportProblemInput) createdProblem

:ProblemPersist

Client

space

findSpace(id: Uuid)

searchResult

search(input: SearchInput)

:SpaceFacade

Search and browse spaces - Sequence Diagram

:SpaceQuery

search(input: SearchInput) searchResult

space(id: Uuid) space

find(query: String)

searchResult

findSpace(id: Uuid)

space

:SpacePersist

Approver

:ReviewFacade

isSuccess: Boolean

insert(review: Review)

Evaluat e a request - Sequence Diagram

createdReview

create(input: CreateReviewInput)

:ReviewMutation

createReview(input: CreateReviewInput)

createdReview

:ReviewPersist

Admin problem(id: Uuid)

problem

:ProblemFacade

problem

find(id: Uuid)

View a report ed problem - Sequence Diagram

:ProblemQuery

find(id: Uuid)

problem

:ProblemPersist

Admin

Manage spaces - Sequence Diagram

createSpace(input: CreateSpaceInput)

createdSpace

create(input: CreateSpaceInput)

update(entity: UpdateSpaceEntity)

:SpacePersist

createdSpace

update(input: UpdateSpaceInput)

isSuccess: Boolean

:SpaceFacade

updateSpace(input: UpdateSpaceInput)

updatedSpace

delete(id: Uuid)

:SpaceMutation

updatedSpace

delete(input: DeleteSpaceInput)

isSuccess: Boolean

insert(entity: SpaceEntity)

deleteSpace(input: DeleteSpaceInput)

isSuccess: Boolean

Admin

Manage roles - Sequence Diagram

createdRole

createRole(input: CreateRoleInput)

update(input: UpdateRoleInput)

createdRole

create(input: CreateRoleInput)

isSuccess: Boolean

update(entity: UpdateRoleEntity)

:RoleFacade

updateRole(input: UpdateRoleInput)

updatedRole

delete(id: Uuid)

:RoleMutation

updatedRole

delete(input: DeleteRoleInput)

isSuccess: Boolean

insert(entity: RoleEntity)

deleteRole(input: DeleteRoleInput)

isSuccess: Boolean

:RolePersist

Admin

isSuccess: Boolean

:DepartmentPersist

update(entity: UpdateMaterialsInput)

:DepartmentFacade

Manage Mat erials - Sequence Diagram

updatedMaterials

update(input: UpdateMaterialsInput)

:DepartmenMutation

updateMaterials (input: UpdateMaterialsInput) updatedMaterials