PROJECT REPORT

On

SAPETEL

Submitted in Partial Fulfillment of requirement for Master of Computer Applications

Sandeep Kumar Roll No 200800094

Supervised by

Pallika Chopra Faculty In charge

Sanjeev Kumar Industry Coordinator

School of Mathematics and Computer Applications THAPAR UNIVERSITY PATIALA

DECLARATION

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 Kumar 200800094 Dated: May 12, 2011

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

Pallika Chopra Faculty Coordinator

Sanjeev Kumar Industry Coordinator

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: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 coCEOs, 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.

CHAPTER 1 INTRODUCTION

INTRODUCTION 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 customers via Mobi2Mail Network where customers use old RIM devices not compatible with GPRS networks. And via Mobi2Nets 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

CHAPTER 2 SYSTEM ANALYSIS

2.1 SYSTEM STUDY To provide flexibility to the users, the interfaces have been developed that are accessible through a browser. The GUIS 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: y y y 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: y Data recording y Data transcription y Data conversion 8

y Data verification y Data control y Data transmission y Data validation y Data correction

INPUT TYPES: It is necessary to determine the various types of inputs. Inputs can be categorized as follows: y External inputs: These are prime inputs for the system. y Internal inputs: These are user communications with the system. y Operational inputs: These are computers communication to the system. y 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; y Type of input y Flexibility of format y Speed y Accuracy y Verification methods y Rejection rates y Ease of correction y Storage and handling requirements y Security y Easy to use y 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 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: y y External Outputs whose destination is outside the organization. Internal Outputs whose destination is with in organization and they are the Users 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 y 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

10

y y

Will decimal points need to be inserted Should leading zeros be suppressed.

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: y y y y y 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

11

1. 2. 3. 4. 5.

Pre-project planning Project inception Construction iterations Release iterations Production

2.4 SYSTEM ARCHITECTURE

12

13

CHAPTER 3 FEASIBILITY STUDY

14

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: y y y 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: y y 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? y Will the proposed system provide adequate response to inquiries, regardless of the number or location of users? y Can the system be upgraded if developed?

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

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.

15

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 POJOs and Controller provided by the f Struts Framework.

3.3 ECONOMIC FEASABILITY The computerized system takes care of the present existing systems 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.

16

CHAPTER 4 REQUIREMENT SPECIFICATION

17

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. The requirement specification for any system can be broadly stated as given below: The system should be able to interface with the existing system y y 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 18

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 RAM Additional Tools HTML Designing Development Tool kit : Dream weaver Tool : Eclipse : Pentium based systems with a minimum of P4 : 256MB (minimum)

19

CHAPTER 5 SYSTEM DESIGN

20

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.

21

5.2 USER CLASSES AND CHARACTERISTICS

22

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.

y y

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.

23

Class Diagram for Account Profile Management :

24

Activity Diagram for Activate Service:

25

Activity Diagram for DeActivate Service:

26

Activity Diagram for Migrate Service:

27

Sequence Diagram:

Fig: 1.3 Sequence Diagram:

28

CHAPTER 6 TESTING

29

6.1 OVERVIEW The Sapetel project is about creating an application that Business Support Services (BSS) users (similar to customer service) can use to act upon customers 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.

30

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 Customer Account Management Deactivate user Activate user Customer account is successfully activated on both M2M and M2N services Customer account is successfully deactivated from M2M andM2N services Migrate user Customers 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 customers profile is changed successfully Change Username The username of customers profile is changed successfully Change GPRS Domain The GPRS domain of customers profile is Changed successfully Features to be tested

Infra

Create menu

All the links of the menu are working 31

properly and redirected to proper page clicking on them Create login page User is able to login successfully after providing valid username and password Change password BSS User Administration Create BSS User Modify BSS User Activate/De-activate BSS User The password is successfully changed BSS users account is created successfully BSS users account is modified successfully 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 Transaction summary report

Administrator activity report is generated successfully for the given date range Transaction summary report is generated successfully for given set of data

Transaction error report

Transaction error report is generated successfully for the given date

32

Database testing  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 33

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

2. Functional Testing : 34

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

35

 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 projects 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 TARs lifecycle. TARs can be logged by a Team Member or the Client.

The diagram below shows the TAR defect life cycle:

36

Retest

New

Open

Fixed

Closed

Duplicate

Cannot Reproduce

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:

37

 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 customers 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 Sniff Test QA Team Deliverables/what Location is performed of test

results/notifications RS3 (Result Space)

Story of one Email notification. module e.g. De-Activate Customer User Account Screen

Functional Testing

QA Team

Module. e.g. Customer Account Management

Test report which RS3 includes progress. defects, (Result Space)

38

Functional Integration Testing

QA Team

Combined modules. Modules which are

Test report, defect RS3 report. (Result Space)

functionally and sanity

tested will be combined together functional integration testing will be performed and

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 39

 Intel Pentium Machine  CPU 3.0GHz  Windows XP Professional Service pack 2  2GB of RAM  80GB of Hard disk

6.8 RESPONSIBILITIES Name Shuchi Singla Role Sapetel Test SME Responsibilities y y Test Management Overall management Testing of &

Functional

Integration Testing y Review Test plan y Manage and track all issues until resolution y y Technical guidance Coordination with the test teams y Providing resources Test Approach,

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: reports: Administrator

Admin/transaction User activity, activity and 40

transaction summary report. Shikha QA Customer Account management: Reactivate user BSS user administration:

Deactivate user Admin/transaction Transaction error report Shweta Mishra QA Customer Account Management: Activate, Deactivate and migrate user Simardeep QA BSS User Administration: reports:

Create, Modify and Activate BSS user Umesh Baraili QA Infra: Create menu, login page and change password

6.9 SNIFF TEST CHECKLIST

41

Proper linking of pages (NAVIGATION)

Browser compatible

Story Name m

L g M

P g h W BSS U m P g S

-A v S -A v S h S h g P BSS -A v A S g

BSS U BSS U m U P g f m m

h g MSIS Mg m A S h S U f m T T A m b m g m

U m & g .

S mm y E A v y U T f A v y mm y M2M

M2

42

No Missing features

UI is not distorted

Correct Headings

Execution Date

Owner

Ch g GP S m S -A v U Custom S M tain transaction (sav & roll back) in M2M and M2

FUNCTIONAL TEST CASE

Functional Test cases for "Re-Activate Customer Screen" Sandeep Kumar Description Start the Sapetel Application. Enter a valid combination of username and password which exists in the database. Enter incorrect username or password in the login screen. Click on Login button with no values in the username and password text fields. Mouse over the 'Customer Account' tab in the menu bar on the home page. Click on the 'Reactivate user' link from the drop down. Verify that the heading on the screen is "Re-activate Customer". Expected Results Login screen will appear. Navigated to the home page of the application. Message "Please enter valid credentials" will be displayed on the login screen. "Username is required" and "Password is required" will be displayed below the corresponding text fields. Drop down with four menu items:: Activate user, Migrate user, Reactivate user and Deactivate user will be displayed. Re-activate Customer screen will be displayed. Re-activate Customer written on the screen. Actual Remarks

43

Verify the presence of Sapetel logo. Verify the presence of Sapient logo. 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. Validate that all the tabs in the Menu Bar are navigating to the corresponding links. Verify that all the labels (i.e. MSISDN and Username) on the screen are aligned properly 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". Validate that if all the fields are left blank, it should not proceed further. Verify that the text fields of similar size appear beside the labels, aligned one below the other and should not overlap. 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.

Sapetel logo should appear on top left corner. Sapient logo should appear on top right corner. A validated Menu Bar should appear below the logos.

All the menu items are proper links to the corresponding WebPages. Labels on the screen are properly aligned and not overlapping each other.

The mandatory fields are marked with (*) and " * indicates required field " information should appear on the top of the labels. Appropriate error messages are displayed below the text fields. Text fields of similar size are properly aligned on the screen.

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

44

Verify that the 'Reactivate' button 'Reactivate' button aligned centrally is centrally aligned at the bottom below the fields. of the screen below the fields. Enter exactly 10 digits in the MSISDN field which exists in the database. Enter less than 10 digits in the MSISDN field. Enter more than 10 digits in the MSISDN field. Enter Values in the MSISDN field other than numeric. Enter username (not more 19 characters) containing values a-z, 0-9 or '_' in the username field which exists in the database. Enter username containing spaces or any special character other than '_' in the username field. Enter values other than a-z, 0-9 and '_' the field 'Username'. Enter more than 19 characters in the username field. It will accept MSISDN without any error. An error message "TBD" will appear below the text field An error message "TBD" will appear below the text field An error message "TBD" will appear below the text field It will accept Username without any error.

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

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

Enter MSISDN in the MSISDN field An error message "Old MSISDN does which does not exist in the not exist" will appear in the error database. module. Enter Username in the Username field which does not exist in the database. Enter MSISDN and Username in the corresponding fields which is not a valid combination in the database. Enter MSISDN and Username in the corresponding fields for the customer whose status field is 'active' in the database. Error message "User name does not exist" will appear in the error module. Error message "Username and MSISDN do not match" will appear in the error module. Message "Username already activated on M2N" will be displayed.

45

Verify that the copyright text "COPYRIGHT@2011 SAPIENT CORPORATION ALL RIGHT RESERVED" with sapient logo is displayed on the screen. Validate that on clicking the 'Reactivate' button it will reflect the status of the customer as 'Active' in the database. Check all the tabs in the menu bar by clicking them to navigate from the current page.

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

Status field of the customer is "Active" in the database. And "Customer with MSISDN XXXX reactivated successfully" will be displayed on the screen. All the tabs are working links and are navigating to the clicked page.

46

CHAPTER 7 OUTPUT SCREENS

47

48

49

50

51

52

53

54

55

56

CHAPTER 8 CONCLUSION

57

CONCLUSION AND FUTURE SCOPE 7.1 Conclusion y 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

y y

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 y 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: y There is new requirement SapeTel intends to migrate willing customers to the Mobi2Net network. y In order to provision customers on the Mobi2Net GPRS network, SapeTel needs a new Provisioning System. y 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 y Since here we are working on struts 2.0 framework. We can use spring framework for enhancing the application. y 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