New Project

PROJECT REPORT

On

SAPETEL

Submitted in Partial Fulfillment of requirement forMaster of Computer Applications

Sandeep Kumar

Roll No 200800094

Supervised by

Pallika ChopraFaculty In charge

Sanjeev Kumar Industry Coordinator

School of Mathematics and Computer ApplicationsTHAPAR UNIVERSITY

PATIALA

DECLARATION

1

I hereby declared that the project work entitled “SAPETEL” is an authentic

record of my own work carried out at Sapient, Gurgaon as requirements of

project semester for the award of degree of M.C.A., Thapar University,

Patiala, under the guidance of Sanjeev Kumar and Pallika Chopra.

Sandeep Kumar200800094

Dated: May 12, 2011

Certified that the above statement made by the student is correct to the best of our knowledge and belief.

Pallika ChopraFaculty Coordinator

Sanjeev Kumar Industry Coordinator

2

TABLE OF CONTENTS

1. Organization overview

2. Chapter 1 – Introduction

3. Chapter 2 – System Analysis

4. Chapter 3 – Feasibility Study

5. Chapter 4 – Requirement Specification

6. Chapter 5 – System Design

7. Chapter 6 – Testing

8. Chapter 7 – Output Screens

9. Chapter 8 - Conclusions

ORGANIZATION OVERVIEW

Profile:-

3

We are a leading IT services firm that plans, designs, implements, and manages

information technology to improve business performance for Global 2000 clients. Sapient was

founded in 1990 based on a single promise: to deliver the business which suits best for the client.

Sapient's Fixed-Time / Fixed-Price model, combined with industrial, design, technological, and

process expertise, provides its clients the highest business value at the least cost of ownership.

Sapient's integrated delivery centers are located across the United States, Canada, United

Kingdom, Germany, and in India. More information about Sapient can be found at

www.sapient.com. Our unique culture lends itself to a progressive management approach. Our

leaders are unassuming and non-hierarchical. Everyone in the organization, including our co-

CEOs, share office space and there is an open atmosphere in every office. While we are not

penny-wise, pound-foolish, our leaders are highly cost-conscious as our market rewards such

discipline. As a result, our executives are self-sufficient and approach their work with a "roll up

your sleeves" work ethic. For their people, our executives provide an environment with

challenging opportunities, strong leadership, and support for the team to grow. They must

work to ensure that a trusted environment is created that promotes initiative, experimentation,

and risk-taking. They proactively raise and openly address issues and problems quickly and

constructively and are open-minded and adaptable to new ideas, approaches, and change.

4

CHAPTER 1

INTRODUCTION

INTRODUCTION

5

SAPETEL is a web based tool which is used by the call center people. With the help of

this tool they can fulfill the requirement of customers. SAPETEL is used for tracking, changing

and managing the information related to mobile phone services of customer. It internally

interacts with other database using web services call. SAPETEL refers to the use of handheld

devices for the purpose of sending short emails.

1.1 EXISTING SYSTEM

SapeTel provides Quick Messaging service to its customer’s via Mobi2Mail Network

where customers use old RIM devices not compatible with GPRS networks. And via Mobi2Net’s

GPRS Network where customers use normal GPRS compatible devices (BlackBerry etc). Such

devices typically support voice as well. As Mobi2Mail is becoming obsolete and difficult to use

(because customers need a separate device for data messaging and separate for voice), SapeTel

wants to migrate ‘willing’ customers to the Mobi2Net network from Mobi2Mail.

1.2 PROVISIONING SYSTEM

In order to ‘provision’ customers on the Mobi2Net GPRS network, SapeTel needs a new

Provisioning System.

Provision means

Activating a new customer on Mobi2Mail and Mobi2Net system

Migrating an existing Mobi2Mail customer to Mobi2Net system

Deactivating a customer on Mobi2Mail and Mobi2Net system

Modifying the ‘attributes’ of a customer on the Mobi2Net system

Since both Mobi2Mail and Mobi2Net are systems external to SapeTel, manually

processing a ‘provision’ request is not a simple task

e.g. Migrating a customer involves confirming the user credentials from

Mobi2Mail and activating the same customer on Mobi2Net

Hence, the need for a system that can provide the Provisioning features without the need

for manual intervention

6

CHAPTER 2

SYSTEM ANALYSIS

2.1 SYSTEM STUDY

7

To provide flexibility to the users, the interfaces have been developed that are accessible through

a browser. The GUI’S at the top level have been categorized as

1. Administrative user interface.

2. BSS User Provision Tool.

The ‘Administrative user interface’ concentrates on the consistent information that is practically,

part of BSS User activities and which needs proper authentication for the data collection. These

interfaces help the administrators with all the transactional states like Create / Modify / Activate /

De Activate BSS User and also having the privileges to access the Reports and Transaction log

of the Customer Requests.

The ‘BSS User provision Tool’ helps BSS to Activate, Deactivate, Migrate and Re-Activate

services to the end users (i.e. customers) and also maintain the transaction log for each request.

2.2 INPUT & OUTPOUT REPRESENTETION SYSTEM

Input design is a part of overall system design. The main objective during the input design is as

given below:

To produce a cost-effective method of input.

To achieve the highest possible level of accuracy.

To ensure that the input is acceptable and understood by the user.

INPUT STAGES:

The main input stages can be listed as below:

Data recording

Data transcription

Data conversion

Data verification

8

Data control

Data transmission

Data validation

Data correction

INPUT TYPES:

It is necessary to determine the various types of inputs. Inputs can be categorized as follows:

External inputs: These are prime inputs for the system.

Internal inputs: These are user communications with the system.

Operational inputs: These are computer’s communication to the system.

Interactive: These are inputs entered during a dialogue.

INPUT MEDIA:

At this stage choice has to be made about the input media. To conclude about the input

media consideration has to be given to;

Type of input

Flexibility of format

Speed

Accuracy

Verification methods

Rejection rates

Ease of correction

Storage and handling requirements

Security

Easy to use

Portability

Keeping in view the above description of the input types and input media, it can be said that

most of the inputs are of the form of internal and interactive. As

9

Input data is to be the directly keyed in by the user, the keyboard can be considered to be the

most suitable input device.

OUTPUT DESIGN:

In general are:

External Outputs whose destination is outside the organization.

Internal Outputs whose destination is with in organization and they are the User’s main

interface with the computer. Outputs from computer systems are required primarily to

communicate the results of processing to users. They are also used to provide a

permanent copy of the results for later consultation. The various types of outputs

Operational outputs whose use is purely with in the computer department. Interface

outputs, which involve the user in communicating directly with the system.

OUTPUT DEFINITION

The outputs should be defined in terms of the following points:

Type of the output

Content of the output

Format of the output

Location of the output

Frequency of the output

Volume of the output

Sequence of the output

It is not always desirable to print or display data as it is held on a computer. It should be decided

as which form of the output is the most suitable.

For Example

Will decimal points need to be inserted

Should leading zeros be suppressed.

10

OUTPUT MEDIA:

In the next stage it is to be decided that which medium is the most appropriate for the output. The

main considerations when deciding about the output media are:

The suitability for the device to the particular application.

The need for a hard copy.

The response time required.

The location of the users

The software and hardware available.

Keeping in view the above description the project is to have outputs mainly coming under

the category of internal outputs. The main outputs desired according to the requirement

specification are:

The outputs were needed to be generated as a hard copy and as well as queries to be viewed on

the screen. Keeping in view these outputs, the format for the output is taken from the outputs,

which are currently being obtained after manual processing. The standard printer is to be used as

output media for hard copies.

2.3 PROCESS MODEL USED WITH JUSTIFICATION

SDLC (Agile Model):

“Agile Model is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with "just enough" ceremony that produces high quality solutions in a cost effective and timely manner  which meets the changing needs of its stakeholders.”

Agile Model consists the following phases

1. Pre-project planning 2. Project inception 3. Construction iterations 4. Release iterations 5. Production

11

2.4 SYSTEM ARCHITECTURE

12

CHAPTER 3

FEASIBILITY STUDY

13

FEASIBILITY STUDY:

Preliminary investigation examines project feasibility; the likelihood the system will be useful to

the organization. The main objective of the feasibility study is to test the Technical, Operational

and Economical feasibility for adding new modules and debugging old running system. All

systems are feasible if they are given unlimited resources and infinite time. There are aspects in

the feasibility study portion of the preliminary investigation:

Technical Feasibility

Operation Feasibility

Economical Feasibility

3.1 TECHNICAL FEASIBILITY

The technical issue usually raised during the feasibility stage of the investigation includes the

following:

Does the necessary technology exist to do what is suggested?

Do the proposed equipments have the technical capacity to hold the data required to use

the new system?

Will the proposed system provide adequate response to inquiries, regardless of the

number or location of users?

Can the system be upgraded if developed?

Are there technical guarantees of accuracy, reliability, ease of access and data security?

14

3.2 OPERATIONAL FEASIBILITY

User-friendly

BSS Used will use the forms for their various transactions i.e. for Activate / De activates /

Migrate Users, viewing the transaction log details. Also the Customer wants the reports to

view the various transactions based on the constraints. Theses forms and reports are

generated as user-friendly to the Client.

Reliability

The package wills pick-up current transactions on line. Regarding the old transactions, User

will enter them in to the system.

Security

The web server and database server should be protected from hacking, virus etc

Portability

The application will be developed using standard open source software (Except Oracle) like

Java, Tomcat web server, JBoss Application Server, Internet Explorer Browser etc these

software will work both on Windows and Linux o/s. Hence portability problems will not

arise.

Availability

This software will be available always.

Maintainability

The system implements using MVC Architecture i.e. Model View Controller Architecture, in

which JSP used as View and Model created using Java POJO’s and Controller provided by

the f Struts Framework.

3.3 ECONOMIC FEASABILITY

15

The computerized system takes care of the present existing system’s data flow and

procedures completely and should generate all the reports of the manual system besides a

host of other management reports.

It should be built as a web based application with separate web server and database server.

This is required as the activities are spread through out the organization customer wants a

centralized database. Further some of the linked transactions take place in different locations.

CHAPTER 4

REQUIREMENT

SPECIFICATION

16

4.1 FUNCTIONAL REQUIREMENTS SPECIFICATION

This application mainly consist six modules

1) BSS Module

2) Customer Profile Management Module

3) Account Profile Management Module

4) Proxy Module

5) Services

6) Reports Module

4.2 PERFORMANCE REQUIREMENTS

Performance is measured in terms of the output provided by the application. Requirement

specification plays an important part in the analysis of a system. Only when the requirement

specifications are properly given, it is possible to design a system, which will fit into required

environment. It rests largely with the users of the existing system to give the requirement

specifications because they are the people who finally use the system. This is because the

requirements have to be known during the initial stages so that the system can be designed

according to those requirements. It is very difficult to change the system once it has been

designed and on the other hand designing a system, which does not cater to the requirements of

the user, is of no use.

17

The requirement specification for any system can be broadly stated as given below:

The system should be able to interface with the existing system

The system should be accurate

The system should be better than the existing system

The existing system is completely dependent on the user to perform all the duties.

4.3 SOFTWARE REQUIREMENTS

J2EE application

Application Server – JBoss 5

Web Server - Apache

Database – Oracle 9i/10g

JSP/Servlets and Struts for presentation

JDBC for communication with DB

Database

Oracle 9i/10g

SQL queries for data management

4.4 HARDWARE REQUIREMENTS

Hardware : Pentium based systems with a minimum of P4

RAM : 256MB (minimum)

Additional Tools

HTML Designing : Dream weaver Tool

Development Tool kit : Eclipse

18

CHAPTER 5

SYSTEM DESIGN

19

5.1 INTRODUCTION

Systems design is the process or art of defining the architecture, components, modules,

interfaces, and data for a system to satisfy specified requirements. One could see it as the

application of systems theory to product development. There is some overlap and synergy with

the disciplines of systems analysis, systems architecture and systems engineering.

20

5.2 U SER CLASSES AND CHARACTERISTICS

21

5.3 UML DIAGRAMS

High Level Use Case Diagram:

There are two actors BSS User and System administrator who can communicate with SapeTel Quick Messaging System.

BSS User takes care of the entire customer needs i.e. Activation, deactivation, migration and reactivation of the customer account.

BSS User can also modify the customer details whereas the System Administrator can create, update, deactivate and reactivate the BSS User as well. System Administrator can also perform the role of BSS User.

Class Diagram for Account Profile Management :

22

Activity Diagram for Activate Service:

23

Activity Diagram for DeActivate Service:

24

Activity Diagram for Migrate Service:

25

Sequence Diagram:

26

Fig: 1.3 Sequence Diagram:

27

CHAPTER 6

TESTING

6.1 OVERVIEW

28

The Sapetel project is about creating an application that Business Support

Services (BSS) users (similar to customer service) can use to act upon customer’s

requests. This application will provide interfaces to BSS users to activate and

deactivate customer's account on Mobi2mail and Mobi2net services. It will also

enable BSS users to migrate customer's account from mobi2mail to mobi2net

services.

The application will also provide interface to an administrator to manage the

profiles of BSS users. Using this application, an administrator can create, modify

and deactivate BSS users. He can also perform all the tasks which are done by

BSS users.

The Sapetel project is divided into 8 modules: Customer account management,

Customer profile change, Transaction management, Infra, BSS User

Administration, Admin reports, Transaction reports and QA. These modules are

further divided into different stories.

The different testing techniques which are performed to test the entire application

are:

Unit Testing: The purpose of unit testing is to test each

module/service or component developed in isolation to ensure that the defined

modular functionality is met. It is performed by developers’ team.

Sanity Testing: It is performed by developers as well as QA Team.

Sanity testing will verify each integrated system element and basic paths, thus

providing confidence in the test environment. This will form the entry criteria for

allowing full Functional and Integration testing.

Functional Testing: Functional testing ensures that the entire system

functions correctly and has met the requirements documented in the BRS and

adheres to the solution design documented in Design documents. It is performed

by QA team.

29

Functional Integration Testing: The objective of FIT is to validate

the application design, and prove that the application components are

successfully integrated to perform one or more application functions. It

performed by QA team.

6.2 SCOPE

6.2.1 Features to be tested

Module Name Functionality

delivered as a part of

the module

Features to be tested

Customer

Account

Management

Activate user Customer account is successfully activated

on both M2M and M2N services

Deactivate user Customer account is successfully deactivated

from M2M andM2N services

Migrate user Customer’s account is migrated from M2M

to M2N

Re-Activate User Customer account is reactivated on M2M

and M2Nservices

Customer

profile change

Change MSISDN The MSISDN number of customer’s profile

is

changed successfully

Change Username The username of customer’s profile is

changed successfully

Change GPRS

Domain

The GPRS domain of customer’s profile is

Changed successfully

Infra Create menu All the links of the menu are working

properly and redirected to proper page

30

clicking on them

Create login page User is able to login successfully after

providing valid username and password

Change password The password is successfully changed

BSS User

Administration

Create BSS User BSS user’s account is created successfully

Modify BSS User BSS user’s account is modified successfully

Activate/De-activate

BSS User

BSS user is deactivated successfully if his

account already exists and activated

successfully if he was deactivated earlier

Admin reports/

Transaction

reports

User activity report User activity report is generated successfully

for

the given date range

Administrator activity

report

Administrator activity report is generated

successfully for the given date range

Transaction summary

report

Transaction error

report

Transaction summary report is generated

successfully for given set of data

Transaction error report is generated

successfully for the given date

Database testing

31

Checking the integrity of UI data with Database Data

Checking whether any junk data is displaying in UI other than that

stored in Database

Checking if the database constraints are effective

Checking if query is properly processing

6.2.2 Features not to be tested

Security testing: It is a process to determine that an information

system protects data and maintains functionality as intended. Security testing is out of

scope from Sapetel project.

Performance testing: Performance testing is used to determine

the speed or effectiveness of a computer, network, software program or device.

We do not perform performance testing on Sapetel project. Also we will not do

testing for scalability of the application.

Accessibility testing: Accessibility testing is the technique of

making sure that your product is accessibility compliant. Accessibility testing is

out of scope from the Sapetel project .

6.3 APPROACH

1. Unit Testing Approach :

QA team assumes that the development team has successfully performed unit testing

of their respective tasks of their track. They should check every task individually.

Every JSP pages which development team has coded comes to QA team after being

tested by development team. Development team should write test suite to test each of

the functionality of the controller/action classes they write. Every JSP pages and

32

controller/action classes which the development team develops should undergo

testing and should be passed upon only if the track functions as per the requirement.

2. Customer Testing Approach :

In this approach, the testing team checks each story for their completeness,

functionality, security and performance. The description of each approach is as

follows:

1. Sniff Testing:

Sniff testing will be performed on a fully configured QA box environment with test

instances for web services, stubs and data. Following listed are tested to check that

sniff testing succeeded:

The QA team tests that the interface pages which the developer

team develops should must be user friendly.

It should have proper UI.

The text field and the button should be properly aligned.

The error messages should be understandable and should be

highlighted so that user can easily identify them and understands what faults he

made.

The mandatory text field which the user cannot leave blank should

be marked with star (*), so that user doesn’t forget to do entry in that field.

Thus, in this approach, QA team checks how user friendly the

interface is that has been developed by the development team.

33

2. Functional Testing :

Functional testing is conducted on a complete, integrated system to evaluate the

system's compliance with its specified requirements. Functionality testing falls within

the scope of black box testing, and as such, should require no knowledge of the inner

design of the code or logic. The QA team tests to ensure that the system delivered is

fit for purpose, robust, reliable and integrates with any other systems as specified.

The functionality of every module is tested.

Following lists the module:

Login Validation: The QA team should ensure that BSS user

should be able to log in using the username and password provided by the admin.

Activation of new customer: It should be ensured that when a

new customer is activated by BSS user, they should be activated on both M2M and

M2N services. The entries filled in the activation form by BSS user should be

populated in the respective database tables.

Migration of Customer: For the old customer, customer who is

availing only M2M services, BSS user can migrate them to M2N services. Migration

of old existing customer means activating the customer in M2N services and once

customer is activated in M2N, they should remain activated in M2M services. QA

team imposes tests so that the system should perform this functionality. The

migration can be done only for old existing customer who is availing only M2M

services.

Deactivation of an existing customer: The BSS user should

deactivate any customer from the service he/she is availing using username of

customer. Once the customer is deactivated, the status column of the customer in the

database should be changed to deactivate status. The QA team should ensure that this

should happen.

34

Reactivation of the deactivated customer: The BSS user can also

reactivate the deactivated customer using their unique username. Here also QA team

ensure that the status of the customer should be changed from deactivate status to

active status.

Modification of customer attribute: The QA team should also

test that there should be interfaces to modify the attributes of customer and also BSS

user. The changes which are applied should be reflected in the database too.

Creation of new BSS user: Only admin should be able to carry

out this functionality. Admin creates a new user. The data of a new BSS user should

be populated in database.

Activation of BSS User: Admin can activate a BSS user if he/she

is being deactivated. The status of the BSS user should be changed to active from

deactivates status.

Deactivation of BSS User: Admin can deactivate the BSS user.

The status of the BSS user should be changed to deactivate in the database.

6.4 TAR MANAGEMENT

TAR is defined as Technical Assistance Request. All the defects found in the testing

process are logged in the TAR tracker. Result space 3 is used for tracking TAR.

Logging a TAR is a continuous activity and will exist throughout the project’s

lifecycle. Once a TAR is logged it will be classified, prioritized, and assigned an

owner. It is possible for the type, priority and owner to change over time. Every TAR

is eventually tracked to closure and its status is moved to ‘Closed,’ marking the end

of the TAR’s lifecycle. TARs can be logged by a Team Member or the Client.

The diagram below shows the TAR defect life cycle:

35

6.5 SUCCESS CRITERIA

1. Script Pass/Fail Criteria:

In this approach, the QA team ensures that all the tests are properly carried out and

the estimated and expected results have been analyzed. The script is analyzed and

checked about its success. The unit of code or component should work as required

and is stable enough to move into QA environment. This is ensured by the

development team. The script developed by the development team should ensure that

it does the functionality and fulfils the requirement. No P1 or P2 should remain open.

P3 and P4 defects can be seen later. Every individual script should be completed

without any defects.

2. System Acceptance Criteria:

The entire requirement stated by the client should be fulfilled. The QA team should

ensure that the goal is achieved. The criteria of the acceptance of system include the

following:

36

New Open Fixed Closed

Duplicate

Retest

Cannot Reproduce

New Open Fixed Closed

Duplicate

Retest

Cannot Reproduce

BSS user should be able to activate a new customer in M2M and M2N services.

Every customer should be provided with a unique username.

BSS user should be able to migrate an existing customer from M2M service to

M2N service.

BSS user should be able to deactivate and reactivate any customer from M2M or

M2N services or both using customer’s unique username.

All the BSS users should be managed by one Admin.

Admin should be able to create a new BSS user and can activate and reactivate

them.

Admin should also perform the functionality of BSS user.

6.6 TEST DELIVERABLES

Test type Tested by Performed

on

Deliverables/what

is performed

Location of test

results/notifications

Sniff Test QA Team Story of one

module

e.g.

De-Activate

Customer

User Account

Screen

Email notification. RS3

(Result Space)

Functional

Testing

QA Team Module.

e.g.

Customer

Account

Management

Test report which

includes defects,

progress.

RS3

(Result Space)

Functional QA Team Combined Test report, defect RS3

37

Integration

Testing

modules.

Modules

which are

functionally

and sanity

tested will be

combined

together and

functional

integration

testing will be

performed

report.

(Result Space)

6.7 ENVIRONMENTAL NEEDS

1. Java Technology

Eclipse-jee-helios-win32

jboss-eap-4.2.0.GA_CP09

Apache Server

Log 4J

Java SDK 1.5

Ant 1.6.5

JUnit for Unit Testing

2. Database

Oracle 10g

3. Computer system configuration

Intel Pentium Machine

38

CPU 3.0GHz

Windows XP Professional Service pack 2

2GB of RAM

80GB of Hard disk

6.8 RESPONSIBILITIES

39

40

Name Role Responsibilities

Shuchi Singla Sapetel Test SME Test Management

Overall management of

Functional Testing &

Integration Testing

Review Test Approach,

Test plan

Manage and track all issues

until resolution

Technical guidance

Coordination with the test

teams

Providing resources

Sandeep Kumar QA

(Sapetel Test Lead)

Module: Customer Profile Change:

Change MSISDN, username and

GPRS domain, Sniff test template

and test case report.

Pramod Singh Deo QA Module: Admin/transaction

reports: User activity,

Administrator activity and

transaction summary report.

Shikha QA Customer Account management:

Reactivate user

BSS user administration:

Deactivate user

Admin/transaction reports:

Transaction error report

Shweta Mishra QA Customer Account Management:

Activate, Deactivate and migrate

user

Simardeep QA BSS User Administration:

Create, Modify and Activate BSS

user

6.9 SNIFF TEST CHECKLIST

Story Name

Ow

ner

Exe

cuti

on

Dat

e

UI i

s n

ot

dis

tort

ed

Pro

per

lin

kin

g o

f p

ages

(N

AV

IGA

TIO

N)

Bro

wse

r co

mp

atib

le

Co

rrec

t H

ead

ing

s

No

Mis

sin

g f

eatu

res

Nam

e

Login Page             

Menu on the Welcome Page             

Create BSS User Screen             

De-Activate BSS User Screen

Re-Activate BSS User Screen

Change Customer Username Screen

Change Password Page for BSS

De-Activate Customer Account Screen

Change MSISDN screen             

Migrate Customer User Account Screen

Change Domain Name Screen

Update Database error & information message.

Transaction Summary Report             

Transaction Error Report             

Admin Activity Report             

41

Create User Activity report             

Create Transaction summary error report for M2M and M2N screen

Change GPRS Domain Screen

Re-Activate User Customer Screen

Maintain transaction (save & roll back) in M2M and M2N

FUNCTIONAL TEST CASE

Functional Test cases for "Re-Activate Customer Screen"

Sandeep Kumar

Description Expected Results Actual Remarks

Start the Sapetel Application. Login screen will appear.

Enter a valid combination of username and password which exists in the database.

Navigated to the home page of the application.

Enter incorrect username or password in the login screen.

Message "Please enter valid credentials" will be displayed on the login screen.

Click on Login button with no values in the username and password text fields.

"Username is required" and "Password is required" will be displayed below the corresponding text fields.

Mouse over the 'Customer Account' tab in the menu bar on the home page.

Drop down with four menu items:: Activate user, Migrate user, Reactivate user and Deactivate user will be displayed.

42

Click on the 'Reactivate user' link from the drop down.

Re-activate Customer screen will be displayed.

Verify that the heading on the screen is "Re-activate Customer".

Re-activate Customer written on the screen.

Verify the presence of Sapetel logo.

Sapetel logo should appear on top left corner.

Verify the presence of Sapient logo.

Sapient logo should appear on top right corner.

Verify that the Menu Bar with 6 tabs: Home, Customer Account, Change Customer Profile, Admin, Reports, settings and Logout on the right corner of the Menu bar.

A validated Menu Bar should appear below the logos.

Validate that all the tabs in the Menu Bar are navigating to the corresponding links.

All the menu items are proper links to the corresponding WebPages.

Verify that all the labels (i.e. MSISDN and Username) on the screen are aligned properly and not overlapping each other.

Labels on the screen are properly aligned and not overlapping each other.

Verify if the mandatory fields are marked as mandatory with the symbol (*). Meaning of * should appear on the top of the fields as "indicates required field".

The mandatory fields are marked with (*) and " * indicates required field " information should appear on the top of the labels.

Validate that if all the fields are left blank, it should not proceed further.

Appropriate error messages are displayed below the text fields.

Verify that the text fields of similar size appear beside the labels, aligned one below the other and should not overlap.

Text fields of similar size are properly aligned on the screen.

43

Verify that the validations are written next to the corresponding field. To inform user, '10 digits' with example should be written next to the MSISDN field and 'max 19 characters' next to the Username field.

10 digits e.g. 1234567653' should appear next to the MSISDN field and 'max 19 characters' next to the username field.

Verify that the 'Reactivate' button is centrally aligned at the bottom of the screen below the fields.

'Reactivate' button aligned centrally below the fields.

Enter exactly 10 digits in the MSISDN field which exists in the database.

It will accept MSISDN without any error.

Enter less than 10 digits in the MSISDN field.

An error message "TBD" will appear below the text field

Enter more than 10 digits in the MSISDN field.

An error message "TBD" will appear below the text field

Enter Values in the MSISDN field other than numeric.

An error message "TBD" will appear below the text field

Enter username (not more 19 characters) containing values a-z, 0-9 or '_' in the username field which exists in the database.

It will accept Username without any error.

Enter username containing spaces or any special character other than '_' in the username field.

An error message "TBD" will appear below the text field

Enter values other than a-z, 0-9 and '_' the field 'Username'.

An error message "TBD" will appear below the text field

Enter more than 19 characters in the username field.

An error message "TBD" will appear below the text field

Enter MSISDN in the MSISDN field which does not exist in the database.

An error message "Old MSISDN does not exist" will appear in the error module.

Enter Username in the Username field which does not exist in the database.

Error message "User name does not exist" will appear in the error module.

44

Enter MSISDN and Username in the corresponding fields which is not a valid combination in the database.

Error message "Username and MSISDN do not match" will appear in the error module.

Enter MSISDN and Username in the corresponding fields for the customer whose status field is 'active' in the database.

Message "Username already activated on M2N" will be displayed.

Verify that the copyright text "COPYRIGHT@2011 SAPIENT CORPORATION ALL RIGHT RESERVED" with sapient logo is displayed on the screen.

Copyright text appears at the bottom of the screen, aligned centrally.

Validate that on clicking the 'Reactivate' button it will reflect the status of the customer as 'Active' in the database.

Status field of the customer is "Active" in the database. And "Customer with MSISDN XXXX reactivated successfully" will be displayed on the screen.

Check all the tabs in the menu bar by clicking them to navigate from the current page.

All the tabs are working links and are navigating to the clicked page.

45

CHAPTER 7

OUTPUT SCREENS

46

47

48

49

50

51

52

53

54

55

56

CHAPTER 8

CONCLUSION

57

CONCLUSION AND FUTURE SCOPE

7.1 Conclusion

This software system will be a Messaging System for mobile service provider. This System is intended for service provider employees (BSS User) who can deactivate, activate, migrate, and reactivate the customers, who are availing or want to avail Mobi2Mail facility (only text messaging facility) or Mobi2Net facility (voice messaging system) or both.

The system administrator will work on BSS User who in turn will work on customers. Easy to Use Interface

The interface is indeed very flexible. Although a lot of check points are there but thus not a burden to the operator. We essentially feel that the interface should be interacting, clear and non ambiguous

Data Validity Checks

Yes, a lot validity checks – from null values to predetermined values from a given set like

category etc, to special check function for email Ids, dates etc. And all these things are done

in such abstract manner that it will be not reflected to the user.

7.2 Future Scope:

There is new requirement SapeTel intends to migrate ‘willing’ customers to the Mobi2Net network. In order to ‘provision’ customers on the Mobi2Net GPRS network, SapeTel needs a new Provisioning System. Activating a new customer on Mobi2Mail and Mobi2Net system ,Migrating an existing Mobi2Mail customer to Mobi2Net system, Deactivating a customer on Mobi2Mail and Mobi2Net system, Modifying the ‘attributes’ of a customer on the Mobi2Net system Since here we are working on struts 2.0 framework. We can use spring framework for enhancing the application. In this application a customer can have only one MAN an MSISDN number but we can enhance this to one to many that one customer can have more than one MAN number and MSISDN number.

58

59

60

61

62