1. Business trip scheduler ARD Lital Badash Yanir Quinn Eran Banouz

2. Contents Background System architecture + Technologies Main Functional Requirements Main Non Functional Requirements Major Use cases Risks December 20102 Business trip scheduler ARD

3. Contents Background System architecture + Technologies Main Functional Requirements Main Non Functional Requirements Major Use cases Risks December 20103 Business trip scheduler ARD

4. Background- Problem Domain Amdocs Employees usually divided to Groups that consists up to 30 people. Occasionally, each group is signed up for a mission (at customer sites) and has to decide which of its members will be sent as part of the mission. December 20104 Business trip scheduler ARD

5. Background- Problem Domain Mission is composed of the following: Destination: destination country Name. Start_date: start date of the mission. End_date: end date of the mission. Group: Group ID. Number_of_people : represents the needed amount of employees. Knowledge_requirement[][] – two dimensional array of the needed positions and level of experience  For example: ((QA, 5), (java programmer, 8)). December 2010 Business trip scheduler ARD 5

6. Background- Problem Domain Before assigning an employee for a mission, constraints must take into account: Personal constraints: dynamic constraints reflecting the availability of each employee on every day.  These constraints considered as “hard constraints” and represent absolute limitations imposed on the system. December 2010 Business trip scheduler ARD 6

7. Background- Problem Domain Personal constraints examples:  Not available on dates: 1.2.2011 – 15.2.2011 (honeymoon)  Not available on dates: 28.04.2011 – 06.05.2011 (wife is about to give birth). December 2010 Business trip scheduler ARD 7

8. Background- Problem Domain System constraints: dynamic and static constraints reflecting technical issues, fairness and managerial preferences.  This constraints considered as hard/soft.  Soft: express a preference of some solutions. December 2010 Business trip scheduler ARD 8

9. Background- Problem Domain System constraints examples:  Duration of time between missions for a team member. – Hard.  Group of peoples desired to go to a mission together. – Soft. December 2010 Business trip scheduler ARD 9

10. Background- Current situation No system. Manually decision. No centered Database – to hold all constraints and data.  Group Manger has to remember\manage all the past assignments of his group members.  Group Manger has to consider all special requests of the system and user. Lack of decision method standardization. December 2010 Business trip scheduler ARD 10

11. Background- Proposed Solution. Create a system that will help decide which of the employees is preferable to go on a mission. To support this we will:  Create a dynamic rule engine that will take into account both personal and system constraints.  Generate, with the help of a suitable algorithm, a list of possible prioritized candidates.  Support a world wide access to the application through the web. December 2010 Business trip scheduler ARD 11

12. Background- Proposed Solution. December 2010 Business trip scheduler ARD 12

13. Contents Background System architecture + Technologies Main Functional Requirements Main Non Functional Requirements Major Use cases Risks December 201013 Business trip scheduler ARD

14. System architecture December 2010 Business trip scheduler ARD 14

15. System architecture- Technologies Communication to the consumer of the API will be done via web browser in dynamic web pages, using HTTP protocol (with CSS styling and underlying JavaScript). The application's logic (written in Java) will run on the web server alongside the application server under the platform of WebLogic (Oracle). December 2010 Business trip scheduler ARD 15

16. System architecture- Technologies Communication between the application server and web pages will be done with JSP. The managed Database in the persistent layer will be run on a MSSQL (possibly mySQL) platform. Communication between the database and the application server will be done under JDBC. December 2010 Business trip scheduler ARD 16

17. System architecture - Algorithm Our main algorithm will make use of some principles and solutions from known problems:  RCPSP - Resource-constrained Project Scheduling Problem.  Manpower Scheduling Problems.  Nurse scheduling problem (NSP). December 2010 Business trip scheduler ARD 17  The algorithm is not going to take in account the following:  The location of the customer site.  Flights schedule or any other transportation concerns.  Any economic or financial issues.

18. Contents Background System architecture + Technologies Main Functional Requirements Main Non Functional Requirements Major Use cases Risks December 201018 Business trip scheduler ARD

19. Main Functional Requirements Three main actors in the system:  Group/ Team member  Group manager  Administrator Different types of users can perform different Actions. December 2010 Business trip scheduler ARD 19

20. Main Functional Requirements Team member:  Login to the system.  View his personal details and status.  Add/Remove personal constraints. December 2010 Business trip scheduler ARD 20

21. Main Functional Requirements December 2010 Business trip scheduler ARD 21 Team Manager( in addition to team member’s functions. )  Modify/Create a new mission – define a new mission with all of its details.  Generate/refresh team members list for a mission – getting the most updated list.  Manage group constraints – add or remove constraints from the manager’s team constraints pool.  Manage team members – add/remove team member to the manager’s team.

22. Main Functional Requirements December 2010 Business trip scheduler ARD 22 Administrator( in addition to team manager’s functions. )  Manage constraints templates – create/remove constraints templates for manager’s use.  Manage permissions – admin can promote / demote corporation users (manager/team member).

23. Contents Background System architecture + Technologies Main Functional Requirements Main Non Functional Requirements Major Use cases Risks December 201023 Business trip scheduler ARD

24. Main Non Functional Requirements Speed & Throughput – The system should support four major transactions:  Submitting a new task (mission). <= 1 minute  Adding/editing general data such as new team members, new client sites, etc. <= 1 minute  Adding/removing new/old constraints. <= 1 minute  Output results.- up to 30 minutes per team. December 2010 Business trip scheduler ARD 24

25. Main Non Functional Requirements Usability – Our system will allow a range of possible usage, according to the user's experience and role. A basic usage that will support all major functionality will be available through an intuitive & friendly interface that should allow any inexperienced user to complete his usage in 10-15 minutes without the need of learning or reading instructions. December 2010 Business trip scheduler ARD 25

26. Contents Background System architecture + Technologies Main Functional Requirements Main Non Functional Requirements Major Use cases Risks December 201026 Business trip scheduler ARD

27. Major Use cases - UC1 Create a new trip mission  Primary actor: team manager.  Pre – Condition: the user is logged in as a team manager, the application is running.  Post-Condition: a new mission has been created and added to the group’s “ongoing missions”  Description: A team manager can create a new mission for the purpose of site support assignment consisting all of the mission details and constraints. December 2010 Business trip scheduler ARD 27

28. Major Use cases – UC1  Main Success scenario:  1. The user selects the "create new trip mission" option.  2. The user fills out of the needed details.  3. Optional. The user chooses team members that will not participate in this mission. Default is all group members.  4. Optional. The user chooses group constraints from the group’s pool of constraints that he would like to exclude from this mission. Default is all group constraints. December 2010 Business trip scheduler ARD 28

29. Major Use cases – UC1  5. The user selects the "confirm" option to add the new mission.  6. The new mission is added to the “ongoing missions” of the group and can be viewed/edit.  7. Success message is presented to the user. December 2010 Business trip scheduler ARD 29

30. Major Use cases – UC1  Alternative flows Expected:  One of the details is missing (a username or a password wasn't typed) An appropriate error message is generated. Return to step 2 of the “Main success scenario”  One or more fields are filled out incorrectly. The system will alert about the fields needed to be corrected. For example start date > end date. Return to step 2 of the “Main success scenario” December 2010 Business trip scheduler ARD 30

31. Major Use cases – UC1  Database read or communication error A message that apologizes for the inconvenience and indicates that an error has occurred is presented to the user and asks him to try the login later. End of use case. December 2010 Business trip scheduler ARD 31

32. Major Use cases – UC2 Add Group constraints.  Primary Actor: Manger.  Pre-Condition: The application is running. The user is logged in to the system as manger.  Post-Condition: System pool of constrained is refreshed according to changes.  Description: add or remove constraints to the manager’s group pool of constraints. December 2010 Business trip scheduler ARD 32

33. Major Use cases – UC2  Main Success scenarios:  1.The user selects the "edit Group constraints" option. The user perform one of the following: 1.1 The user chooses a desired template from the system pool of constraints. 1.2 The user fills in all the constraint parameters according to the template. 1.3 All fields are checked by the system for validity. 1.4 The user selects “add constraint”. 1.5 The constrained is added to the group pool of constraints. December 2010 Business trip scheduler ARD 33

34. Major Use cases – UC2 2.1 The user chooses a desired template from the system pool of constraints for the use of the team members. 2.2 The user selects “add constraint”. 2.3 The constrained is added to the group pool of constraints.  Success message is shown to the user.  The update list is saved and stored in the database. December 2010 Business trip scheduler ARD 34

35. Major Use cases – UC2  Alternative flows expected:  Cancelling. Before confirmation of the operation the user can regret and choose the “cancel” option. The system will go back to the main manage group constraints option. Incorrectly filled of fields.- after step b2.  Fields filled incorrectly. Appropriate message is shown. Return to step 1.2 of the “Main success scenario” December 2010 Business trip scheduler ARD 35

36. Major Use cases – UC2  Database read or communication error A message that apologizes for the inconvenience and indicates that an error has occurred is presented to the user and asks him to try the login later. End of use case. December 2010 Business trip scheduler ARD 36

37. Contents Background System architecture + Technologies Main Functional Requirements Main Non Functional Requirements Major Use cases Risks December 201037 Business trip scheduler ARD

38. Risks This project is very comprehensive and requires the following needs that might consume more time than available : o A deep and profound research in the field of constraints processing. o Understanding an uncovered field of application server and gaining knowledge of the web logic application server and utilities. December 2010 Business trip scheduler ARD 38

39. Thank you! December 2010 Business trip scheduler ARD 39