Company: Amdocs

Academic advisor: Ehud GudesTechnical advisor :Gabby Shimony

Team:Uzi LewinElina Shlangman

Background

Amdocs provides billing services for major communication and cable companies.

Among their customers are major companies such as AT&T, T-mobile & Vodafone, and minor ones such as Cellcom & Orange.

Amdocs is a company who provides services to be integrated in external systems.

The Problem Domain

When Amdocs upgrades its systems it produces new files that should be tested in external systems (companies Amdocs works with).

The external systems are not always available for testing.

The current situation is that new files are tested manually, which makes the testing process really slow.

The Problem Domain

Company

(The customer)

Company's Client

Customer Feedback Simulator

Output file

Amdocs

Data gathering

Data processing

Proposed solution

The project’s goal is to create a software to simulate the customers Amdocs works with, and give a feedback on the newly created files.

This simulator must be as generic as possible in order for it to simulate current and future companies.

This will save time and money.

System Architecture

Functional Requirements

Rule configuration definition

File checking

Log file production

Non-Functional Requirements Speed Capacity & Throughput:

• File definition & configuration will last less than a second.

• processing the file will last less than a minute.

• 95% of the time the proper result report will be produced, while in other cases a specific error message will appear.

•Only one user may use the system at any given time.

Non-Functional Requirements Reliability: The simulator is expected to deliver correct valid results at 99% of the time. Usability:

The simulator is simple and easy to learn. A couple of hours are enough to master the simulator.

Platform:The simulator’s language is English. Programming language: Java.OS: Microsoft windows.

Use Cases

Rule definition

Rules loading

File testing

Use cases: Rule definition

Course of action:

1. User informs that he wants to create a new rule.2. System presents the GUI tools.3. User picks a rule.4. System remembers rule.5. Go to 2 until user satisfied.6. System stores the new rule in a file.

Use cases: Rule definition

Use cases: Rules loading

Course of action:

1. User informs that he wants to Load a file.2. System presents all files saved.3. User picks a file & confirms.4. System loads file.

Use cases: Rules loading

Use cases: File testing

Course of action:

1. User specifies a file to the system.2. System checks that the file is consistent

with the rule.3. System writes a log file.

Use cases: File testing

Risks

Our major risk lies in the definition of the language we are to create.

This language is to be as generic as possible, so we are able to simulate any current or future company Amdocs works with.

The end