business trip scheduler ard lital badash yanir quinn eran banouz

Business trip scheduler

ARDLital Badash

Yanir Quinn

Eran Banouz

2

Contents

Background System architecture + Technologies Main Functional Requirements Main Non Functional Requirements Major Use cases Risks

December 2010 Business trip scheduler ARD

3

Contents



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.


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


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.


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


8


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.


9


System constraints examples:

Duration of time between missions for a team

member. – Hard. Group of peoples desired to go to a mission

together. – Soft.


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.


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.


12

Background- Proposed Solution.


13

Contents



14

System architecture


User

Presentation Layer

Rule Engine LayerAlgorithm Logic Layer

Persistent Layer

DataBase

User Logic Layer

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


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.


Business trip scheduler ARD 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

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



19

Main Functional Requirements Three main actors in the system:

Group/ Team member Group manager Administrator

Different types of users can perform different Actions.


20

Main Functional Requirements Team member:

Login to the system. View his personal details and status. Add/Remove personal constraints.


21

Main Functional Requirements


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


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



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.


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.


26

Contents



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.


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.


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.


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”


31


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.


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.


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.


34


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.


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”


36


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.


37

Contents




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


Thank you!

December 2010

business trip scheduler ard lital badash yanir quinn eran banouz

Documents

dynamic constraints

hard constraints

static constraints

background proposed

background current situation

group manger

group members

group of peoples