ACKNOWLEDGEMENT

On every step there is need of proper guidance, support & motivation. The encouragement enables the person to give his best performance & thus to achieve his goal. Though we really worked hard to complete all of our assignments, given to us in training period but still from core of our heart we feel that the fruit of success comes up with the emissive support of our colleagues and time-to-time guidance from our respected Project Incharge Mr. Naval Dhamaloo. The skill that we are able to explore here will definitely help us in our future. The spirit of team working and coordination made us know our responsibilities. Here we learnt how to work under pres-sure, pressure of responsibilities, pressure of performance and above all pressure of competition. I would express my deep sense of regard to Cellebrum Technologies Pvt. Ltd. Mohali and Mr. Dilip Modi (Director) of Company for extend-ing me the opportunity for project training and providing all the necessary resources and expertise for this purpose. I sincerely acknowledge, with thanks, the encouraging guidance and critical supervision of Mr. Naval who is our project guide in Mohali, during this assignment. I am deeply indebted to Executive. Mrs. Simerjeet Kaur, for all his kind help, valuable suggestions & erudite guidance whenever need. We are grateful to Mr. Manoj Kashyap, our Technical Head in Cellebrum, to pursue this project in a smooth and organized manner.

PREFACE
The well planned properly executed and evaluated training helps a lot in including good culture. It provides linkage between the student and the institution in order to develop the awareness of approach to problem solving based on broad understanding of process and mode of operation of an organization. This report serves the purpose of elaborating the analysis and the implementation phases of the above-mentioned project. All the features that have been included in the final implementation have been clearly explained to make the project easy to understand. It has been taken care that this document elicits the system development process in a clear and welldocumented manner. In the beginning we have provided an abstract into the general features of the project. As we proceed, well delve into more intricate details regarding the working of the project. During our stay here we learnt how an actual project progresses, what sort of problems actually occur during the development of such projects, how to produce quality products and so on.

CONTENTS
1. OVERVIEW OF ORGANISATION 2. STUDY OF PROPOSED SYSTEM 3. PROBLEM ANALYSIS 3.1 Introduction 3.2 Product Definition 3.2.1 Problem Statement 3.2.2 Functions to be provided 3.2.3 Processing environment- hardware, software 3.2.4 Solution strategy 3.3Feasibility analysis 3.4Project plan 3.4.1 Team structure 3.4.2 Development Schedule 3.4.3 Programming Language 4. SYSTEM REQUIREMENTS SPECIFICATION 4.1 Introduction 4.1.1 Purpose 4.1.1 Scope 4.1.2 Developers responsibility 4.2 Overall Description 4.2.1 Functional overview 4.2.2 General Constraints 4.2.3 General assumptions 4.3 Specific Requirements 4.3.1 External interface requirements 4.3.2 Functional requirements 4.3.3 Performance requirements 4.3.4 Design constraints 4.3.5 Acceptance criteria 5.DESIGN 5.1 Introduction 5.2 System Design 5.2.1 Overview 5.2.2 High level DFD 5.2.3 Most abstract input output elements 5.2.4 First level factoring

5.3 Detailed Design 5.3.1 Detailed DFD 5.3.2 Module specification 5.4 Data Dictionary 5.5 Database Design 6. CODING 7. TESTING 7.1 Introduction 7.2 Test Plan 7.3 Features to be tested 8. PROJECT LEGACY 8.1 Current status of project 8.2 Further recommendation 9. BIBLIOGRAPHY

. OVERVIEW OF ORGANIZATION
Cellebrum is a flagship company of MCorp Global group with interests in the field of telecom solutions, office automation and information technology and Value added services. Strong IT foundations and an excellent mobile domain understanding have helped us in becoming the leading Wireless Application Providers in India with installations for most of the telecom service providers Like Hutch, IDEA, BPL, Escotel, BSNL, Reliance, MTNL and other corporate like Hero, ICICI, Vardhman, HDFC, Nahar International etc. At Cellebrum we provide value added services and solutions to major telecom players and corporate across the globe. Our vision is to be a technology enabler in a wire-free world connecting data source or application to any device and make the mobile phone an integrated communications device, with the ability to provide information and perform real time online transactions anytime... anywhere.

PARTNERS

Oracle
For 27 years, Oracle has been helping customers manage critical information. Our goal is to make sure that you spend less money on your systems while getting the most up-to-date and accurate information from them.

Intel
Intel offers a broad range of building blocks that can be used in many different types of telecom solutions in various communications environments, including enterprise and service provider. A single building block can support a variety of solutions. Once a building block is installed, it can be used to add new features and capabilities to a solution

Parity Software Parity Software Development Corporation was founded in 1989, with the first release of VOS, a powerful computer telephony application . Microsystems Everyone and everything connected to the network. Eventually every man, woman, and child on the planet will be connected to the network. So will virtually everything with a digital or electrical heartbeat -- from mobile phones to automobiles, thermostats to razor blades with RFID tags on them. Software Jataayu is ideally placed to offer end-to-end solutions for Value added services to mobile operators in the arena of MMS, WAP, SMS, SyncML, Instant Messaging, Over the Air Provisioning and wireless applications

CLIENTS
MobileFirst The cellular revolution has left none untouched. Defining our lifestyles, dictating our relationships and connecting our needs.

BPL
BPL Mobile is committed to business leadership in providing world class technology services and solutions, by focusing on People, Customers,

RPG Cellular
RPG Cellular is part of a conglomerate with a reputation for innovation and outstanding business practices. In Telecom, RPG has an established presence in all services including Cellular, Paging, V-SAT and e-mail. And ties with world leaders like NTT and Itochu Corp. of Japan, Star Paging of Hong.

Escotel
Escotel Mobile Communications Limited is a joint venture of Escorts Limited, one of the leading industrial houses in India, and First Pacific Company Limited of Hong Kong.

SPICE Telecom
Spice Telecom is a joint venture between Distacom of Hong Kong, and Spice Corp the flagship company of the B.K. Modi group. It is one of the leading cellular providers in India today.

HUTCH-Delhi
Hutchison established its presence in India in 1994, through a joint venture with Max India Limited. In 1995, Hutchison Max Telecom became the first operator in India to launch its cellular service.

Zee News
In just a decade, the Zee Telefilms Group has made forays in each and every growth segment of the knowledge, information and entertainment economy; addressing and enthralling audiences across the globe

AAJ TAK

Aaj Tak, India Today Groups foray into the audiovisual media, began in 1988 with News track, a video newsmagazine that shook up the establishment. By 1995, TV Today Network had evolved to produce one of the most influential current affairs programmes, Aaj Tak.

SOLUTIONS
Cellebrum is involved in providing cutting edge communication software products & solutions to global communication OEMs and service providers. Our solutions have been deployed for a number of Telecom Operators to enhance operational efficiency, reduce expenses and implement innovative revenueBroadly, our products and solutions can be categorized into:

CUSTOMIZED SOLUTIONS
MUSIC Jukebox Jukebox gives you a unique voice based ring tone download option . Voice clips can be dedicated to any mobile or landline number anywhere in India. Music Quiz Providing more excitement and entertainment to subscribers, this is another musical service called 1 2 ka 4. In this game subscriber is given a sound clip to hear, he needs to identify it and then answer some simple questions based on the heard sound clip. GAMING Tambola MobileFirst, an alliance of leading cellular operators including BPL Mobile, Escotel, RPG Cellular and Spice Telecom announce the launch unique mobile game - Tambola for all their subscribers across the country. FUN Online Comedy & Jokes This is Service based on Automatic Speech recognition. This service is based on voice recognition tech. The input to the application is in the form of Speech, based o the users input the application performs various options LOGOS Logos application enables users to customize their Mobile phones with exciting operator logos. This is a web based service. The user has the option to choose the Logo from various categories and download directly from website to his mobile phone. Picture Messages

Picture Message application enables users to customize their Mobile phones with exciting Picture Messages. This is a web based service. The user has the option to choose the Picture Messages from various categories and download directly from website to his mobile phone.

Ringtones Ring Tone application enables users to customize their Mobile phones with exciting Ring Tones. This is a web based service. The user has the option to choose the Ring Tones from various categories and download directly from website to his mobile phone. CHAT Now, you can let your subscribers chat by using SMS Chat. Its loads of fun and it is as simple as sending an SMS. This is an anonymous chat. Subscriber's phone number is never displayed during the chat and can use any chat name that the subscriber wants. Information ZingMail/Email Zing Mail is a voice email service. Record your message and send it to any email address. A single message is restricted to 30secs. News This is also a information based service. This service provides the latest News to the user. This is a SMS based service. Horoscope This service provides the user the latest Horoscope for a particular Sun sign. Cricket Score This service provides the user the latest CRICKET SCORE for a particular match Movie Info Know about Latest Filmi Fundas, Latest releases this week, Hot Bollywood Masala, the Movies in your nearby Theatre. Be the first one to know all this with Movie Line service. Gurbani Subscribers can listen to Mukhwak passed on by the Golden Temple. Subscribers can also listen Japji Sahib Paath recital with and without meaning Rehras Sahib Paath recital. Bhaktisagar If you have not realized your body's potential, you have not missed much. If you have not realized your mind's potential, you have missed a little. If you have not realized your heart's potential, you have missed much.

Products VMS It is a service that works as your personal message-receiving centre, 24 hours a day. Whenever a caller needs to get in touch with the subscriber while he/she is busy or unavailable voice mail service takes a message for them .

SMSC Product Description The explosive growth of SMS usage & users has driven wireless carriers around the world to add the ability to send brief text messages over their own networks to capitalize on the phenomenon. Business Benefits Open system architecture (allows easy integration with various network elements) could be used as main SMSC (with MO/MT) or as simply as an Bulk SMS SMSC without disturbing the existing infrastructure / user experience.

2.

STUDY OF PROPOSED SYSTEM

Earlier, the same service was being provided by our company, but with a difference in it. That difference is that earlier the promo calls/Outdials was done via NMS and via SIU. It sometimes irritates the person who operates the Outdials he wishes to avoid such call. Customers queries are also a headache because it requires knowledge of oracle and applying the queries directly on oracle. A lot of queries regarding logs also require CDR search and queries and also reports were made manually which was a time consuming task. Hence some modification in the project is required. Then I suggested my project guide the solution to the problem in existing system. I gave him the idea to automate reports and also to run two exe files from a single interface. Outdialers provide benefits to both company. Through Outdialers company can tell the customer about the various and latest services and user also get to know about new services offered by the company without any efforts. The target for the out dialers on daily bases is 9, 00,000 and it add 30%-40% revenue of the company. Customer received the call send by Outdial method and can subscribe the service by just responds to the prompts.

What is OBD ?
As a job duty descriptor, you may see or hear the term outbound calling. As a homeowner or business executive, youve likely experienced the result of outbound calling first hand. Outbound calling refers to phone calls made by a company to a specified list of contacts. In sales, outbound calling encompasses telemarketing, lead generating, and other steps necessary in the sales process. As opposed to employees who handle inbound calling, employees who perform outbound calling may be required to abide by certain laws that apply to their job or type of work. When a job description requires employees to handle inbound calling, they are usually fulfilling duties that are governed by the companys policies. Customer service, company or business inquiries, and so forth are handled through incoming calls. However, outbound calling, such as in sales or collections, is partially mandated by state and federal law. For example, a company who uses outbound calling as a way to build a client base to sell a product or service is required by law to remove names from their contact list if the contact requests them to do so. It can be considered harassment under the statutes of law if a company repeatedly calls upon an individual or business for the purposes of solicitation once they have been asked to stop. Calling lists for outbound calling are usually purchased from third parties who compile lists based on any number of specific factors, from homeownership status to income bracket to previous purchasing history. In many cases, outbound calling lists are preprogrammed into

automatic dialers that constantly move through the lists, dialing the numbers and simultaneously routing all answered calls to an employee. This is one way for a company to increase its productivity in outbound calling and maximize its sales base.

Increase Customer Contacts

Studies show that agents spend only 20 to 30 minutes of each hour talking to customers in a manual outbound call center. But agents in centers using a predictive dialer spend 45 to 50 minutes each hour talking to live customers, a 100 percent increase in productivity. Outbound campaigns reduce the time and overall cost of reaching customers. Using automated dialing and voice detection tools, the system connects only live, answered calls to an agent. Agents spend time talking to customers, not listening to ringing phones, busy signals, and answering machines. This results in direct savings and increased profits by allowing call centers to connect more calls each day with the same (or a reduced) number of agents.

A Predictive Dialer automates outbound calling procedure while managing multiple campaigns and leads. With a predictive dialer, the productivity of any contact center can be increased by more than 300% over manual dialing. It is very tedious to manually call up hundreds of prospects and track information pertaining to every customer. The job becomes more complicated when more than 60% of the calls are responded to by an answering machine, or with a busy signal. And we are not counting wrong numbers, dialing and response time, number of redials in this figure. With talk time of 10-15 minutes per hours, your business is taking a hit because of low prospect-to-customer conversion ratios. Your supervisor may never know whether an agent is actually talking with a customer, or his new-found girlfriend on the net. Moreover, you may also anger certain folks who have subscribed to Do-Not-Call (DNC) lists, or those who do not wish to be called at certain times of the day. Last but not the

least, there are no metrics to improve processes or manage multiple campaigns and the management does not have meaningful data in the form of structured reports or voice records for quality and policy compliance.

Powerful telemarketing IVR for seamless extension of large-scale Call Center systems Telecom-class

platform scaleable from 120 to 600 ports The Opencode Outbound IVR can manage up to 600 telemarketing calls simultaneously and perform up to 300,000 calls a day! It may be used in the standard unattended mode or live calls may be transferred to in-house or remote operator's representative.
Flexible service creation allowing almost unlimited integration of external data and applications The Opencode Outbound IVR includes web based service creation environment that allows easy design and deployment of VoiceXML logic on the IVR engine. While performing the telemarketing campaigns, the installed service logic can interact in real-time with the operator's specific applications and data, making external information easily accessible by phone. Comprehensive and simple Web administration The Outbound IVR allows management of the IVR configuration, download and upload voice prompts, allocate maximum line occupation for a campaign, check overall and per campaign call load, activate call monitoring and many others. Platform allowing easy hosting of telemarketing services to third parties The platform has built-in advanced hosting capabilities, allowing the operator to offer telemarketing services to third parties. The parties can remotely access the service creation, design and load their own campaigns, while securely using the allocated to them telecom resources!

Allow dialing-out usage by the entire operator's subscriber base Thanks to the hosting capabilities of the platform, the operator can let subscribers to configure over the web private notification calls. For example a doctor can schedule client notification for an upcoming appointment. A major retailer can notify customers for orders that are ready for pickup. Other uses for this feature are limited only by lack of imagination! Seamless integration with large-scale Call Center systems Opencode Outbound IVR can be integrated easily in almost any mobile network, thanks to its built-in SS7/ISDN gateway capabilities. Connectivity to the market's leading Call Center vendors is supported.

NETWORK SWITCHING SUBSYSTEM

Network Switching Subsystem, or NSS, is the component of a GSM system that carries out switching functions and manages the communications between mobile phones and the Public Switched Telephone Network. It is owned and deployed by mobile phone operators and allows mobile phones to communicate with each other and telephones in the wider telecommunications network. The architecture closely resembles a telephone exchange, but there are additional functions which are needed because the phones are not fixed in one location. Each of these functions handle different aspects of mobility management and are described in more detail below. The Network Switching Subsystem, also referred to as the GSM core network, usually refers to the circuitswitched core network, used for traditional GSM services such as voice calls, SMS, and Circuit Switched Data calls.

There is also an overlay architecture on the GSM core network to provide packet-switched data services and is known as the GPRS core network. This allows mobile phones to have access to services such as WAP, MMS, and Internet access. All mobile phones manufactured today have both circuit and packet based services, so most operators have a GPRS network in addition to the standard GSM core network.

Mobile Switching Center (MSC)

The Mobile Switching Center or MSC is the primary service delivery node for GSM, responsible for handling voice calls and SMS as well as other services (such as conference calls, FAX and circuit switched data). The MSC sets up and releases the end-to-end connection, handles mobility and hand-over requirements during the call and takes care of charging and real time pre-paid account monitoring. In the GSM mobile phone system, in contrast with earlier analogue services, fax and data information is sent directly digitally encoded to the MSC. Only at the MSC is this re-coded into an "analogue" signal (although actually this will almost certainly mean sound encoded digitally as PCM signal in a 64-kbit/s timeslot, known as a DS0 in America). There are various different names for MSCs in different contexts which reflects their complex role in the network, all of these terms though could refer to the same MSC, but doing different things at different times. A Gateway MSC is the MSC that determines which visited MSC the subscriber who is being called is currently located. It also interfaces with the Public Switched Telephone Network. All mobile to mobile calls and PSTN to mobile calls are routed through a GMSC. The term is only valid in the context of one call since any MSC may provide both the gateway function and the Visited MSC function, however, some manufacturers design dedicated high capacity MSCs which do not have any BSSes connected to them. These MSCs will then be the Gateway MSC for many of the calls they handle. The Visited MSC is the MSC where a customer is currently located. The VLR associated with this MSC will have the subscriber's data in it. The Anchor MSC is the MSC from which a handover has been initiated. The Target MSC is the MSC toward which a Handover should take place. An MSC Server is a part of the redesigned MSC concept starting from 3GPP Release 5.

Mobile Switching Centre Server (MSS)

The Mobile Switching Centre Server or MSC Server is a soft switch variant of Mobile Switching Centre, which provides circuit-switched calling, mobility management, and GSM services to the mobile phones roaming within the area that it serves. MSC Server functionality enables split between control (signalling) and user plane (bearer in network element called as Media Gateway), which guarantees more optimal placement of network elements within the network. MSC Server and MGW Media Gateway makes it possible to cross-connect circuit switched calls switched by using IP, ATM AAL2 as well as TDM.

Other GSM Core Network Elements connected to the MSC

The MSC connects to the following elements:

1. The HLR for obtaining data about the SIM and MSISDN 2. The Base Station Subsystem which handles the radio communication with 2G and 2.5G mobile
phones.

3. The UTRAN which handles the radio communication with 3G mobile phones. 4. The VLR for determining where other mobile subscribers are located.
5. Other Macs for procedures such as handover.

Procedures implemented
Tasks of the MSC include

1. Delivering calls to subscribers as they arrive based on information from the VLR. 2. Connecting outgoing calls to other mobile subscribers or the PSTN. 3. delivering SMSs from subscribers to the SMSC and vice versa 4. arranging handovers from BSC to BSC
5. carrying out handovers from this MSC to another

6. Supporting supplementary services such as conference calls or call hold.

7. generating billing information.

Home Location Register (HLR)

The 'Home Location Register' or HLR is a central database that contains details of each mobile phone subscriber that is authorized to use the GSM core network. There is one logical HLR per PLMN, although there may be multiple physical platforms. The HLR stores details of every SIM card issued by the mobile phone operator. Each SIM has a unique identifier called an IMSI which is the primary key to each HLR record. The next important items of data associated with the SIM are the MSISDNs, which are the telephone numbers used by mobile phones to make and receive calls. The primary MSISDN is the number used for making and receiving voice calls and SMS, but it is possible for a SIM to have other secondary MSISDNs associated with it for fax and data calls. Each MSISDN is also a primary key to the HLR record. Examples of other data stored in the HLR against an IMSI record is:

GSM services that the subscriber has requested or been given GPRS settings to allow the subscriber to access packet services Current Location of subscriber (VLR and SGSN) Call divert settings applicable for each associated MSISDN.

The HLR data is stored for as long as a subscriber remains with the mobile phone operator. The HLR is a system which directly receives and processes MAP transactions and messages from elements in the GSM network, for example, the Location Update messages received as mobile phones roam around.

Other GSM Core Network Elements connected to the HLR

The HLR connects to the following elements:

the Gateway MSC (G-MSC) for handling incoming calls The VLR for handling requests from mobile phones to attach to the network The SMSC for handling incoming SMS The voice mail system for delivering notifications to the mobile phone that a message is waiting

Procedures implemented
The main function of the HLR is to manage the fact that SIMs and phones move around a lot. The following procedures are implemented to deal with this:

Manage the mobility of subscribers by means of updating their position in administrative areas called 'location areas', which are identified with a LAC. The action of a user of moving from one LA to another is followed by the HLR with a Location area update while retrieving information from BSS as BSIC (cell identifier). Send the subscriber data to a VLR or SGSN when a subscriber first roams there. Broker between the GMSC or SMSC and the subscriber's current VLR in order to allow incoming calls or text messages to be delivered. Remove subscriber data from the previous VLR when a subscriber has roamed away from it.

Authentication Centre (AUC)

The 'Authentication Centre' or AUC is a function to authenticate each SIM card that attempts to connect to the GSM core network (typically when the phone is powered on). Once the authentication is successful, the HLR is allowed to manage the SIM and services described above. An encryption key is also generated that is subsequently used to encrypt all wireless communications (voice, SMS, etc.) between the mobile phone and the GSM core network.

If the authentication fails, then no services are possible from that particular combination of SIM card and mobile phone operator attempted. There is an additional form of identification check performed on the serial number of the mobile phone described in the EIR section below, but this is not relevant to the AUC processing. Proper implementation of security in and around the AUC is a key part of an operator's strategy to avoid SIM cloning. The AUC does not engage directly in the authentication process, but instead generates data known as triplets for the MSC to use during the procedure. The security of the process depends upon a shared secret between the AUC and the SIM called the Ki. The Ki is securely burned into the SIM during manufacture and is also securely replicated onto the AUC. This Ki is never transmitted between the AUC and SIM, but is combined with the IMSI to produce a challenge/response for identification purposes and an encryption key called Kc for use in over the air communications.

Other GSM Core Network Elements connected to the AUC

The AUC connects to the following elements:

the MSC which requests a new batch of triplet data for an IMSI after the previous data have been used. This ensures that same keys and challenge responses are not used twice for a particular mobile.

Procedures implemented
The AUC stores the following data for each IMSI:

the Ki Algorithm id (the standard algorithms are called A3 or A8, but an operator may choose a proprietary one).

When the MSC asks the AUC for a new set of triplets for a particular IMSI, the AUC first generates a random number known as RAND. This RAND is then combined with the Ki to produce two numbers as follows: The Ki and RAND are fed into the A3 algorithm and a number known as Signed RESponse or SRES is calculated. The Ki and RAND are fed into the A8 algorithm and a session key called Kc is calculated.

The numbers (RAND, SRES, KC) form the triplet sent back to the MSC. When a particular IMSI requests access to the GSM core network, the MSC sends the RAND part of the triplet to the SIM. The SIM then feeds this number and the Ki (which is burned onto the SIM) into the A3 algorithm as appropriate and an SRES is calculated and sent back to the MSC. If this SRES matches with the

SRES in the triplet (which it should if it is a valid SIM), then the mobile is allowed to attach and proceed with GSM services. After successful authentication, the MSC sends the encryption key Kc to the Base Station Controller (BSC) so that all communications can be encrypted and decrypted. Of course, the mobile phone can generate the Kc itself by feeding the same RAND supplied during authentication and the Ki into the A8 algorithm. The AUC is usually collocated with the HLR, although this is not necessary. Whilst the procedure is secure for most everyday use, it is by no means crack proof. Therefore a new set of security methods was designed for 3G phones.

Visitor Location Register (VLR)

The Visitor Location Register or VLR is a temporary database of the subscribers who have roamed into the particular area which it serves. Each Base Station in the network is served by exactly one VLR, hence a subscriber cannot be present in more than one VLR at a time. The data stored in the VLR has either been received from the HLR, or collected from the MS. In practice, for performance reasons, most vendors integrate the VLR directly to the V-MSC and, where this is not done, the VLR is very tightly linked with the MSC via a proprietary interface. Data stored includes:

IMSI (the subscriber's identity number) authentication data MSISDN (the subscriber's phone number) GSM services that the subscriber is allowed to access Access Point (GPRS) subscribed the HLR address of the subscriber

Other GSM Core Network Elements connected to the VLR

The VLR connects to the following elements:

the Visited MSC (V-MSC) to pass data needed by the V-MSC during its procedures, e.g. authentication or call setup. The HLR to request data for mobile phones attached to its serving area. Other VLRs to transfer temporary data concerning the mobile when they roam into new VLR areas (for example TMSI which is an ephemeral temporary IMSI used in communication).

Procedures implemented
The primary functions of the VLR are:

to inform the HLR that a subscriber has arrived in the particular area covered by the VLR to track where the subscriber is within the VLR area (location area) when no call is ongoing to allow or disallow which services the subscriber may use to allocate roaming numbers during the processing of incoming calls to purge the subscriber record if a subscriber becomes inactive whilst in the area of a VLR. The VLR deletes the subscriber's data after a fixed time period of inactivity and informs the HLR (e.g. when the phone has been switched off and left off or when the subscriber has moved to an area with no coverage for a long time). to delete the subscriber record when a subscriber explicitly moves to another, as instructed by the HLR

EIR
The EIR (Equipment Identity Register) is often integrated to the HLR. The EIR keeps a list of mobile phones (identified by their IMEI) which are to be banned from the network or monitored. This is designed to allow tracking of stolen mobile phones. In theory all data about all stolen mobile phones should be distributed to all EIRs in the world through a Central EIR. It is clear, however, that there are some countries where this is not in operation. The EIR data does not have to change in real time, which means that this function can be less distributed than the function of the HLR.

Other support functions

Connected more or less directly to the GSM core network are many other functions.

BC
The Billing Centre is responsible for processing the toll tickets generated by the VLRs and HLRs and generating a bill for each subscriber. it is also responsible for to generate billing data of roaming subscriber.

SMSC
The Short Message Service Centre supports the sending and reception of text messages.

MMSC
The Multimedia Messaging System Centre supports the sending of multimedia messages (e.g. Images, Audio, Video and their combinations) to (or from) MMS-enabled Handsets.

VMS The

Voicemail System records and stores voicemails.

3. PROBLEM ANALYSIS
3.1 INTRODUCTION
The Analysis Phase is where you break down the high-level Project Definition into the more detailed business requirements. The Analysis Phase is also the part of the project where you identify the overall direction that the project will take through the creation of the project strategy documents. Gathering requirements is the main attraction of the Analysis Phase. The process of gathering requirements is usually more than simply asking the customer of their requirements. Depending on the complexity of the application, the process for gathering requirements has a clearly defined process of its own. This process consists of a group of repeatable processes that utilize certain techniques to capture, document, communicate, and manage requirements. This formal process, which will be developed in more detail, consists of four basic steps. 1. Elicitation I ask questions, you talk, I listen 2. Validation I analyze, I ask follow-up questions 3. Specification I document, I ask follow-up questions 4. Verification We all agree In our case, following are the analysis tasks that needed to be accomplished Outdials should not sent to the person who are in roaming or whose mobile is switched off. Outdials should not sent to the person whose number is barr. How to increase the revenue through Outdials. Sending Promo calls through server does not result in increase in the load.e Making Excel Reports Automation. Customers Queries Handling. Graphs showing status of services Logs management

3.2 PRODUCT DEFINITION

In the Define the Software Product step of the acquisition process, the software requirements are elicited, analyzed, specified and validated. This step drives the direction of the acquisition. The desired product must be adequately analyzed and its individual features and quality attributes decided on and documented. The Acquisition Team should prioritize the requirements and separate needs from wants. Successful acquisition projects are dependent on clearly defined requirements. We cannot stress enough the importance of good requirements documentation. As identified in a Standish Group survey, IT executive managers believe that the three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements. Opinions about why projects are impaired and ultimately canceled ranked incomplete requirements and lack of user involvement at the top of the list. [Standish-95] In order to write good requirements documentation we need to understand the basic categories of requirements. Requirements are classically referred to in two categories: Functional and Non-Functional requirements and design constraints. The functional category specifically addresses tangible features, capabilities or functions of the desired software. This includes requirements for the various modes of operation, operational scenarios, data input/generation, data transformations and data outputs/storage. The non-functional category addresses requirements that must be inherent throughout the design and are not tied directly to any single feature or function. Non-functional requirements include requirements for usability, reliability, performance, supportability, safety, security and other product attributes. Design constraints include any predefined limitations on how the system can be designed and implemented. Constraints should include: 1. 2. 3. 4. Any required standards or policies that must be used Any external interfaces, communication protocols or operational limitations Any existing budget or schedule limitations Any platform limitations (e.g., hardware, operating system, language, tools) The software requirements should be verified to ensure that they are: 5. Unambiguous: Every requirements statement should have one and only one interpretation. 6. Complete: Includes all the functions and functional attributes of the software and all constraints that must be satisfied. 7. Testable: There exists a reasonably cost-effective way to determine that the software satisfies the requirements. 8. Traceable: Each requirement should be traceable back to its source (e.g., system level requirements, standard,enhancement request). It should also be specified in a manner that allows traceability forward into the design, implementation and tests. 9. Consistent: Internal conflicts do not exist between requirements. 10. Modifiable: Each requirement should be specified in a coherent, easy-tounderstand manner. The requirements should be non-redundant (i.e., each requirement is stated in only one place). Each requirement should be specified in a manner that allows it to be changed without excessive impact on other requirements. 11. Reasonable: The requirements can be implemented using available technologies, techniques, tools, resources and personnel within the specified cost and schedule constraints..

3.2.1 PROBLEM STATEMENT Earlier the interface used for the OBD has to face some type of problems. So we had to develop new interface so that it can be used for both type of OBD operations whether through NMS or through SIU. The interface should provide report-viewing facility along with proper designed elements. It also has some facilities to create MIS report automatically and saving it to a proper location.

Features to be added in the new system 1. 2. 3. 4. 5. 6. 7. 8. Should be properly designed. Report viewing facilities. Dynamic coding. Common Interface for NMS and SIU Queries Enhancement Alerts sending Maintaining graphs Logs management

3.3.2 FUNCTIONS TO BE PROVIDED: Secure Access: This application provides to only those employees who are employee of celllebrum. Each employee is provided with a unique username and password and only after the user has entered correct username and password, he/she will be allowed to entered in the broadcasting system. Login / logout Function:It keeps the record of the time gap between the user login time and user logged out time. Auto Testing Processing Message and cli length is checked. Message length should not exceed by 159 characters whereas cli length should not exceed by 12 characters. Message is sent and delivered to the particular base for checking. Mobile length and series is checked along with the number of channels allocated for the call. Auto Mail Module Some Reports or CDRS are to be auto mailed. So we have to make a program in java for that. Auto Reviewing Status It counts for the various status and then review every status count regularly after a interval of time. It then tells about condition of status whether it is normal or not.

Update schedule Insertion and deletion of the data into the table automatically Report Calculation are performed for total sending and total delivery along with percentage. Graphs Calculating graphs for months for services. Queries Handling Several type of queries.

3.2.3

PROCESSING ENVIOREMENT- HARDWARE, SOFTWARE:

Both hardware and software requirements are studied for implementation of this application. The application has ten tables in its database, so it requires good permanent storage. Platform configuration This includes the operating system of the computer used in the development of the website Software Operating System Used Microsoft Window 2000 Server JAVA Microsoft Windows XP Professional ORACLE 8i Minimum : Microsoft Window NT Server 4.0 Service Pack 5 (SP 5) or Window 2000 Standard Server or Windows 2000 Advanced Server or window 2000 Data Center Server. Recommended: Microsoft Window 2000 Server Microsoft suggests the following minimum hardware requirements. * Intel 486 or higher. RISC support is also available. * 24 MB Ram for Intel chips 32 MB Ram for RISC. * 10 MB Disk space needed for installation. 100 MB + .5 MB per client for Cache space. * 2 Network interfaces (Adapters, Dial-Up, LAN. Etc) Following is the suggested minimum software requirements.

* Windows XP or Higher version * JAVA jdk1.3 or higher version * Java script runtime package for grid display. * Oracle 8i and JDBC oracle drivers. * Apache Tomcat Server /Web server or other third party server. * TCP/IP It is highly recommended that it be installed on an NTFS partition. If an NTFS partition is not used, not only are you losing NTFSs advanced security features, but also the caching mechanisms of Proxy Server will not work. It is also recommended that your two network interfaces be configured prior to installation. On interface configured to the external network, and one configured for the internal network RHN Proxy Server:

Pentium III processor, 1.26GHz, 512K cache or equivalent 256 MB of memory 3 GB storage for base install of Windows

Keep in mind, the frequency in which client systems connect to the Proxy is directly related to load on the Apache HTTP Server. If you do reduce the default interval of four hours (or 240 minutes), as set in the /etc/sysconfig/rhn/rhnsd configuration file of the client systems, you will increase the load on this component significantly. 3.2.4 SOLUTION STRAREGY Strategy means policies and procedures that is to be used in performing different activities, to make the output more efficient and accurate to the specifications. The strategy that to be used to solve the problem is an important aspect to be considered. Strategy means the procedure or policy that is to be followed throughout the project for getting the pre specified results client' or to fulfill the clients requirements. Solution Strategy adopted by management should be developed according to their needs. Solution Strategy establishes the relationship between the management plan for a candidate system. Objective of solution strategy should be the basis for system development, which dictate operating goals in the form of specific actions plan. Solution Strategy adopted for the development of OBD interface is as follows:1. Develop a dynamic interface. 2. POI package to automate Excel Reports. 3. Proper design of interface etc

3.3 FEASIBILITY ANALYSIS

A feasibility study is defined as an evaluation or analysis of the potential impact of a proposed project or program. A feasibility study is conducted to assist decision-makers in determining whether or not to implement a particular project or program. The feasibility study is based on extensive research on both the current practices and the proposed project/program and its impact on the school foodservice operation. The feasibility study will contain extensive data related to financial and operational impact and will include advantages and disadvantages of both the current situation and the proposed plan. The feasibility study is conducted to assist the decision-makers in making the decision that will be in the best interest of the school foodservice operation. The extensive research, conducted in a non-biased manner, will provide data upon which to base a decision. Who Conducts the Feasibility Study? A feasibility study may be conducted by the school foodservice director in the district considering a central kitchen. The school foodservice director often does not have the time required to conduct the in-depth analysis required to complete a feasibility study. Also, the director may lack the expertise necessary for completing the study. Thus, a consultant often is hired to conduct the feasibility study. A feasibility analysis is an important tool to help you assess the viability of starting a new valueadded business, or re-organizing or expanding an existing business. It provides important information needed to make the critical decision of whether to go forward with a business venture. The analysis often takes the form of a formal study conducted by someone outside of the business (ie. consultant). However, it is critical that the business venture founders are involved in the study and question its assumptions and conclusions.
The feasibility of a project can be ascertained in terms of technical factors, economic factors, or both. A feasibility study is documented with a report showing all the ramifications of the project.

Depending on the result of the initial investigation, this is simply a report a formal document detail, the nature and scope of the proposed solution. The result of the feasibility study is a formal proposal. It serves as a decision document. The three consideration involved in the feasibility study are

Economic Feasibility: The cost involved in designing and implementation of the proposed system is as follow
ANALYSIS AND DESIGN COST Calculating the number of human days spends on the analysis and design of the project and then multiplying the number of days with cost of human day can work out the cost of analysis and design. Every project has this whether the person charges or not.

PROGRAMMING COST

This cost is also calculated by calculating the numbers of human days spend on the coding of the project and then multiplying the number of cost of human day. STATIONARY AND MISCELLANEOUS EXPENSES In my case the cost of the computer stationary is comparatively more than the cost of other not computer based stationary, which is mostly used in the police station. The extra cost will also include the cost of computer floppies for backup and electricity to run the system. TECHNICAL FEASIBILITY Basic technical requirements of the system and all the existing system facilities of this study revolve around the hardware and software requirements in the proposed system. HARDWARE In case of my project there is as such no computer system available for the implementation of the project, but the official posted there feel that the installation of a computer system can help a lot in reducing their work- load.

MANPOWER Both the technical and the non-technical staff require implementing this system there.
SUPPORT FACILITIES

The database is to store on the hard disk. The availability and retrieval will be a no problem once a system is installed there. A printer is also needed to get the reports.
BEHAVIORAL FEASIBILITY

Since the staff members posted at the police station is willing to adopt the new system therefore the reaction of the staff members is quite promising. Resistance of the people to change is evaluated and the degree of their resistance is measured.

SCOPE OF FEASIBILITY ANALYSIS

In general terms, the elements of a feasibility analysis for a project should cover the following:

Need Analysis. This indicates a recognition of a need for the project. The need may affect the organization itself, another organization, the public, or the government. A preliminary study is then conducted to confirm and evaluate the need. A proposal of how the need may be satisfied is then made. Pertinent questions that should be asked include:

Is the need significant enough to justify the proposed project? Will the need still exist by the time the project is completed? What are the alternate means of satisfying the need? What are the economic, social, environmental, and political impacts of the need?

Process Work. This is the preliminary analysis done to determine what will be required to satisfy the need. The work may be performed by a consultant who is an expert in the project field. The preliminary study often involves system models or prototypes. For technology-oriented projects, artist's conception and scaled-down models may be used for illustrating the general characteristics of a process. A simulation of the proposed system can be carried out to predict the outcome before the actual project starts. Engineering & Design. This involves a detailed technical study of te proposed project. Written quotations are obtained from suppliers and subcontractors as needed. Technology capabilities are evaluated as needed. Product design, if needed, should be done at this time. Cost Estimate. This involves estimating project cost to an acceptable level of accuracy. Levels of around -5% to +15% are common at this level of a project plan. Both the initial and operating costs are included in the cost estimation. Estimates of capital investment and of recurring and nonrecurring costs should also be contained in the cost estimate docuement. Sensitivity analysis can be carried out on the estimated cost values to see how sensitive the project plan is to the estimated cost values. Financial Analysis. This involves an analysis of the cash flow profile of the project. The analysis should consider rates of return, inflation, sources of capital, payback periods, breakeven point, residual values, and sensitivity. This is a critical analysis since it determines whether or not and when funds will be available to the project. The project cash flow profile helps to support the economic and financial feasibility of the project. Project Impacts. This portion of the feasibility study provides an assessment of the impact of the proposed project. Environmental, social, cultural, political, and economic impacts may be some of the factors that will determine how a project is perceived by the public. The value added potential of the project should also be assessed. A value added tax may be assessed based on the price of a product and the cost of the raw material used in making the product. The tax so collected may be viewed as a contributon to government coffers. Conclusions and Recommendations. The feasibility study should end with the overall outcome of the project analysis. This may indicate an endorsement or disapproval of the project.

Recommendations on what should be done should be included in this section of the feasibility report. FEASIBILITY OF OUR PROJECT 1.The Projects Technical Feasibility We have opted JAVA and JSP as development languages for developing the project and ORACLE as backend. JAVA is the main language used in the development of broadcasting system. 2.The Projects Economical Feasibility The system investigation cost is very low. We already have JAVA and JSP installed on every system in our company. JAVA and JSP are from Sun Microsystems. 3. The projects Behavirial Feasibility There was very good response from the top management and from the user, in lieu for development of the project. Besides it , no harm could be foreseen to developers or to other environment due to this project. Hence, with all these economical, technical and behavioral feasibility study, the project was found feasible to be carried out.

3.4 PROJECT PLAN

The detailed roadmap for the particular project is the Project Plan that specifies what specifies activities to perform for this particular project, when and how to ensure that project progresses smoothly. A process limits the decreases of freedom of a project by specifying by what type of activities must be done and in what order. Further restrictions on the degree of freedom for a particular project are specified for the project plan, which, in itself, is within the boundaries established by the process (i.e. a project plan cant include performing an activity that is not there in the project.)

Broadly, Project management activities can be viewed as having three major phases: 1. Project planning 2. Project monitoring and control 3. Project termination Planning entails all activities that must be performed before starting the development work. Once the project is started, project control begins. In other words, during planning all the activities that

management needs to perform are planned. While during project control the plan is executed and updated. Planning is the most important management activity. Without a proper plan. No real monitoring or controlling of the project is possible. A improper planning may be the cause of many software failures. The basic goal of planning is to look into the future, identify the activities that need to be done to complete the project successfully, an plan the scheduling an resource allocation for these activities. A good plan is flexible enough to handle the unforeseen events that inevitably occur in large project. Project plan is the document describing aspects of the plan. It is the instrumental in driving the development process through the remaining phases. The major issues project plan addresses are: Cost Estimation Schedule and Milestones Personnel Plan Software Quality Assurance Plan Configuration Management Plans Project Monitoring Risk Management

Guidelines for Project Plans.

Use project plans to coordinate rather than to control. Make use of different personalities within the project environment. Preschedule frequent revisions to project plans. Empower workers to estimate their own work. Describe value-creating tasks rather than activities. Define specific and tangible milestones. Use check lists, matrices, and other supplements to project plans.

Project Execution Plan Development

Planning is an ongoing process that is conducted throughout the project life cycle. Initial planning may relate to overall organizational efforts. This is where specific projects to be undertaken are determined. Subsequent planning may relate to specific objectives of the selected project. In general, a project plan should consist of the following components:

Components

Summary of Project Plan. This is a brief description of what is planned. Project scope and objectives should be enumerated. The critical contraints on the project should be outlined. The types of resources required and available should be specified. The summary should include a statement of how the project complements organizational and national goals, budget size, and milestones. Objectives. The objectives should be very detailed in outlining what the project is expected to achieve and how th expected achievements will contribute to overall goals of the project. The performance measures for evaluating the achievement of the objectives should be specified. Approach. The managerial and technical methodologies of implementing the project should be specified. The managerial approach may relate to project organization, communication network, approval heirarchy, responsibility, and accountability. The technical approach may relate to company experience on previous projects and currently available technology. Policies and Procedures. Development of a project policy involves specifying the general guidelines for carrying out tasks within the project. Project procedure involves specifying the detailed method for implementing a given policy relative to the tasks needed to achieve the project goal. (calls for a Project Procedure Manual) Contractural Requirements. The portion of the project plan should outline reporting requirements, communication links, customer specifications, performance specifications, deadlines, review process, project deliverables, delivery schedules, internal and external contacts, data security, policies and procedures. This section should be as detailed as practically possible. Any item that has the slightest potential of creating problems later should be documented. Project Schedule. The project schedule signifies the commitment of resource against time in pursuit of project objectives. A project schedule should specify when the project will be initiated and when it is expected to be completed. The major phases of the project should be identified. The schedule should include reliable time estimates for project tasks. The estimates may come from knowledgeable personnel, past records, or forecasting. Task milestones should be generated on the basis of objective analysis rather than arbitrary stipulations. The schedule in this planning stage contstitutes the master project schedule. Detailed activity schedules should be generated under specific project funtions. Resource Requirements. Project resources, budget, and costs are to be documented in this section of the project plan. Capital requirements should be specified by tasks. Resources may include personnel, equipment, and information. Special personnel skills, hiring, and training should be explained. Personnel requirements should be aligned with schedule requirements so as to ensure their availability when needed. Budget size and source should be presented. The basis for estimating budget requirements should be justified, and the cost allocation and monitoring approach should be shown.

Performance Measures. Measures of evaluating project progress should be developed. The measures may be based on standard practices or customized needs. The method of monitoring, collecting, and analyzing the measures should also be specified. Corrective actions for specific undesirable events should be outlined. Contingency Plans. Courses of actions to be taken in the case of undesirable events should be predetermined. Many projects have failed simply because no plans have been developed for emergency situations. In the excitement of getting a project under way, it is often easy to overlook the need for contingency plans. Tracking, Reporting, and Auditing. These involve keeping track of the project plans, evaluating tasks, and scrutinizing the records of the project.

3.4.1 TEAM STRUCTURE: The team structure for creating this application consisted of two developer i.e. Manoj and Rishu . 3.4.2 DEVELOPMENT SCHEDULE: Development schedule is the one of the important planning activity during project plan. Development schedule is define as the time period or time schedule to develop the system. Schedule estimation is one of the important planning activities. In his phase we estimate that, how much time will be spending on different developing activities. The project should be developed with in pre specified schedule. In real sense the schedule that is to be estimated before any actual development process. This is just the estimation development schedule. In this schedule we plan different activities regarding cost, time, efficiency, performance. Etc. so that the developed system must be efficient, effective and accurate working. The Development Schedule that should be used as a starting point for all projects at Stanford is shown on the following page. It is structured based on the Process phases as shown graphically at the bottom of this page. The specific design and construction tasks for each phase are purposefully not listed to highlight the overall organization and logic of the Software Project. The durations listed are typical and are dependent on numerous variables that are unique to each project. The level of detail provided in the sample is representative of the Programming Phase. The schedule is to be monitored and updated as the project moves through the process of design, agency approval, construction and activation. For each project, the Project Manager will be responsible for compiling and maintaining this overall Management Schedule. The Management Schedule does not replace the detailed Project Schedule comprising the Management Schedule and the design and construction contractors schedules. The Project Manager can determine on a project-by-project basis which member of the Project Team will be responsible for maintaining the Project Schedule.

In OBD SYSTEM development schedule was planned by me it self and also according to our technical head and manager requirements, and it was estimated to 4 months. It was started of February and ends after mid of May. In this plan we implemented to develop the various function of interface. The development of site is divided into various phases. These phases are shown in Diagram :-

100 90 80 70 60 50 40 30 20 10 0

Requirement & Analysis

Design

Coding

Testing

Maintenance

FEB

MARCH

APRIL

MAY

JUNE

3.5 PROGRAMMING LANGUAGES

1) 2) 3) 4) 5) Java, JDBC (Type 4 Driver) J2EE (Servlets , JSP ) Oracle 8i JDK 1.4 TOMCAT 5.0 J2SDKEE 1.3

Type 4 Driver: Type 4 Drivers the JDBC Calls to direct network calls using vendor specific networking protocols. They do this by making direct socket connections with the database. Type 4 drivers generally offer better performance that type and type 2 drivers. Type 4 drivers are also one of the simplest drivers to deploy since there are no additional libraries or middleware to install. All The Major Database vendors 0provide TYPE-4 Drivers for their databases and they are also available from third party vendor also.

Fig: Type 4 driver

JAVA SERVER PAGES Java Server Pages (JSP) technology enables to mix regular, static HTML with dynamically generated content from servlets. Many Web pages that are built by CGI programs are primarily static, with the parts that change limited to a few small locations. For example, the initial page at most on-line stores is the same for all visitors, except for a small welcome message giving the visitors name if it is known. But most CGI variations ,including servlets , helps to generate the entire page via your program, even though most of it is always the same. JSP lets you create the two parts separately. Most of the page consists of regular HTML, which is passed to the visitor unchanged. Parts that are generated dynamically are marked with special HTML-like tags and mixed right into the page.

ARCHITECTURE The 3-tier architecture: Database Server Web /Application Server Clients

Database Server

Store overall data instructions

Web Server Or Application erver

Clients

Clients

Clients

Why ORACLE is used as data base? Its a relational database management system that has an excellent binding with JSP. Any no. of records can be maintained in the ORACLE database. Efficient retrieval of records using SQL commands such as SELECT. TOAD (Tool for ORACLE Application Development) provides the fast and better view of table contents. SQL Database Structure The SQL database structure consists of one or more tables. Each table is contained in a file. Tables are defined by rows and columns. Column 1 Column 2 Column 3 Column 4

Row 1

Row- record - Information about a specific object such as a person. column -field - category of information key - A unique value in a table that is used to identify that particular object SQL database is a type of database technology that is the most widely used in today's computing environment. Here the data is stored in a very structured format that provides high levels of functionality. SQL databases are generally more robust, secure and have better performance than other older database technologies INTRODUCTION TO JAVA

JAVA is related to C++, which is direct descendent of C. Much of character of JAVA is inherited from these two languages. This language was initially called Oak but was renamed as JAVA. The trouble with C and C++ is that they are designed to be compiled for a specific target. Although it is possible to compile a C++ program for just about any type of CPU, to do so requires a full C+ + compiler for that CPU. The problem is that compilers are expensive and time consuming to create. The solution of this problem led to the creation of java. Some important features of JAVA: 1) Simple: JAVA is SIMPLE because in it we dont use pointers as in C++ and it was designed to be easy professional programmer to learn and use effectively. If one already understands the basic concepts of object oriented programming learning Java will be even easier. 2) Object-Oriented: JAVA is pure OBJECT-ORIENTED because in the |JAVA main within the class. Object Oriented Programming is a way to software that is reusable, extensible and maintable. 3) Platform Independent: JAVA is platform independent. For e.g. C++ programs are designed for specific target. For that we require C++ compiler which are expensive and time consuming to create. But in JAVA programs will also run on another PC because every operating system has Java Virtual Machine. 4) Multithreded: A single-threaded application has one thread of execution running at all times, all such programmers can do only one task at a time. If a single threaded program need to perform a task that will take several minutes. But JAVA supports multithreaded programming which allows you to write programs that do many things simultaneously. Java synchronized keyword can be used to prevent two threads from entering the same critical block of code at the same time. 5) Security: When you use a JAVA compatible Web-browser you can safely download Java applets without fear of viral infection by confining a Java program to the JAVA execution environment and not allowing it to access other parts of the computer. 6) Robustness: The ability to create robust programs was given a priority in the design of JAVA .Java is strictly typed language, it checks your code at compile time. It checks code at run time. To better understand how Java is robust, consider two of the reasons for program failure, memory management mistakes and mishandled exception condtions.Memory management can be difficult tedious task in traditional programming

environments. For example in C/C++ the programmer must manually allocate and free dynamic memory. This sometimes lead to problems because programmer will either forgot to free memory that has been previously allocated or worse try to free some memory that another part of their code is still using. Java virtually eliminates these problems by managing memory allocation and deallocation .Exceptional conditions in traditional environments often arises in a situation such as division by zero or file not found and they must be managed with clumsy and hard-to-hard construct. Java helps in this area by providing object oriented exception handling. In well written Java programs, all run time errors can be managed by your program. 7) Distributed: Java is designed for the distributed environment of the Internet because it handles TCP/IP protocols. 8) Dynamic: In the windows operating systems, parts of programs can be placed into Dynamic link libraries so that they can be shared and loaded dynamically i.e. when the program is running. The operating system does the final stage of linking at execution time. Using shared DLL (Dynamic Link Library) saves memory and improves the modality of the software. Java takes Dynamic Libraries a step further. The VM class loaded fetches class files from the network as well from the disk, providing location transparency making java applications distributed as well dynamic. JAVA SCRIPT JavaScript is a compact, object-oriented scripting language. It can provide interactive web pages, validate from data, and make your web pages clearer. JavaScript is most well known for its use in Websites. It was originally developed by Brendan Eich of Netscape Communication. It adds functions to HTML pages, which are otherwise static. JavaScript is easier than Java, but not as powerful and deals mainly with elements on the Web page. On the client, JavaScript is maintained as source code embedded into an HTML page. On the server, it is compiled into byte code, similar to java programs. Features of Java Script: JavaScript was designed to add interactivity to HTML pages. A JavaScript is an interpreted language. JavaScript is usually embedded directly in HTML pages. JavaScript is supported by all major browsers, like Netscape and Internet Explorer. Functions of Java Script: It performs following functions:

Control document appearance and content. Read and write client state with cookies. It can manipulate Embedded Images. It can control the browser. Interact with the user.

Limitations of JavaScript: JavaScript does not support networking of any kind. JavaScript does not have any graphic capabilities. Client side JavaScript cannot read or write files.

PACKAGES Packages are of the basic components of a Java Program. To avoid the problem that, the name of a class will be unique & not collide with class names chosen by other programs. Java provides a mechanism for partitioning the class name space into more manageable chunks. This mechanism is the package. We can define classes inside a package that are not accessible by code outside the package. To create a package is quite easy; simply include a package command as the first statement in a Java Source a package command as the first statement in a Java Source File. The package statement defines a name space in which classes are stored. If you omit the package statement, the class names are put into the default package, which has no name. Packages are mainly of two types: 1. User Defined 2. Predefined Since packages give an easy handle on the entire hierarchy, they will guide to explore the java class hierarchy. The most commonly used predefined packages are: Package java.lang contains the main language support classes. These with object wrappers, strings, multithreading, and related areas. Package java.util contains language support classes of more utilitarian nature. These include collection and calendar classes, as well as some abstract design codified by the interfaces comparator, iterator and observer. Package java.io provides device-independent file and steam I/O service. Package java.awt hides the bulk of all graphical classes. Because it contains javas abstract window tool kit (AWT), contained in java.awt and 12 sub packages, the package should really be considered as the heart of the entire hierarchy. Package java.net combines the classes supporting low-level Internet programming plus pluggable look-and-feel. Package java.applet contains a single class with support for HTML embedded java applets. Package java.swing is required for frame. JDBC JDBC is a Java API for executing SOL statements. It consists of a set of classes and interfaces written in JAVA programming language. JDBC provides a standard API for tool/database developers and makes it possible to write database applications using a pure JAVA API. Basic JDBC interaction in its simplest form can be broken down into four steps: 1. Open a connection to the database. 2. Execute a SQL statement. 3. Process the results.

4. Close the connection to the database Using JDBC API, it isnt necessary to write one program to access a system database, another program to access an Oracle database, another program to access an Informix database and so on. One can write a single program using a JDBC API and the program will be able to send SQL statement to the appropriate database. And with an application returning JAVA programming language, one also doesnt have to worry about writing different applications to run on different platforms. The combination of JAVA and JDBC lets programmers write it once it anywhere. Microsofts ODBC API is probably the most widely used programming interface for accessing relational databases. It offers the ability to connect almost all databases on all platforms. So why not just use ODBC from JAVA? The answer is that you can use ODBC from JAVA, but this is the best done with the help of JDBC in the form of the JDBC-ODBC bridge. The question now becomes, Why do we need JDBC? There are several answers to these questions: 1. ODBC is not appropriate for direct use from JAVA because it uses a C interface. Calls from JAVA to native C code have a number of drawbacks in the security, implementations, robustness and automatic portability of applications. 2. A literal transmission of ODBC C API into a JAVA API would not be desirable. For example, JAVA has no pointers and ODBC makes copies use of them, including the notoriously errorprone generic pointer void. You can think of JBBC as ODBC translated into an object oriented interface that is natural for JAVA programmers. 3. ODBC is hard to learn. It makes simple and advanced features together and it has complex options even for simple queries. JBBC on the other hand was design to keep simple thing while allowing more advanced capabilities where required. 4. A JAVA API like JDBC is needed in order to enable a pure JAVA solution. When ODBC is used, the ODBC driver manager and drivers must be manually installed on every client machine. When the JDBC driver i.e. written completely in JAVA. However JDBC code is automatically installable, portable and secure on all JAVA platforms from network computers to the mainframe. WHAT IS HTML? HTML (Hyper Text Markup Language): A markup language used to structure text and multimedia documents and to set up hypertext links between documents, used extensively on the World Wide Web. HTML is a markup language that uses a fixed set of markup tags. HTML is a programming language in that an HTML document is a program that, when run by a browser, displays its text as Hypermedia. HTML itself is the set of customizable markup tags that are inserted into HTML document govern its format, multimedia content, and hyperlinks. The HTML is really only a collection of predefined tags which, when inserted into regular text, tell a web browser how to:

1. Format the document and its text. 2. Link into other locations, in the same document, in another web page, or even on another server. 3. Incorporate i.e. insert a graphic image, videos or sound clips into displayed document. Features of HTML: 1. 2. 3. 4. 5. An HTML file can be created using a simple text editor. HTML file must have an htm or html file extension. An HTML file is a text file containing small markup tags. The markup tags tell the browser how to display the page. HTML is a display only technology. JAVA SERVER PAGES(JSP) JSP is acronyms as Java Server Pages. JSP is a Java based technology that simplifies the process of developing dynamic websites. We call it Java Server Pages because these are run on server & written on Java. Within the JSP we process a request & display the request. Life cycle of JSP. There are 2 phases of JSP cycle 1) Translation Phase. 2) Request Processing Phase. Advantages of JSP: 1. Write Once, Run Anywhere Properties i.e. Java Server Pages Technology is platform Independent. 2. It support high quality tool. 3. The Java Server Pages technology emphasizes the use of reusable components such as Java Beans components, Enterprise Java Beans Components & tag libraries. 4. The JSP technology enables the separation of static content from dynamic content. The separation is supported by beans specifically designed for the interaction with server side objects & by tags extension mechanism. 5. Java Server Pages technology support scripting elements as well as actions. 6. JSP technology is an integral part of the Java2Platform Enterprise Edition (J2EE), which brings Java Technology to enterprise computing. 7. JSP is typically implemented via servlets. When a web server receives a request for a JSP page, it forwards it to a special process dedicated to handling servlet execution. This process is referred to as the servlet container. 8. JSP support splitting of presentation i.e. the display of information to the end user and program implementation. The code used to generate that information in the first place.

JSP Tag Convention: 1. Directive: Directive element is used to use a library or import a page or include the output of another file of a jsp. <% @ taglib prefix=c user=http://java.sun.com/jsp/jstl/core%> Taglib: This tag is used to use a library. URI: Uniform Resource Identifier. C: C is small name of core. 2. Scriptlet: This is used to insert a java code in JSP. It has 3 forms: <% int a = = 6; %> : <% = a %> : <% .. %>: Initialization Output Java Code

3. Standard action: These contain standard JSP tags that are used for setting the values taken from HTML form & store it in the Java class and vice versa. SERVLETS Servlets are the small programs that execute on the server side of a web connection. Servlet is a java class i.e. used to process the client request and send response back to the client. So basically servlet is an interface. Since servlets run inside servers, they dont need a graphical user interface. Major advantage is that they do not require creation of new process for each request. Clients of the servlets can be written in any language. All servlets implements this interface, either directly or by extending a class that implements it such as: 1. Generic Servlet: It will listen only that request that will follow Http protocol. 2. Http Servlet: It will listen all the request doesnt matter what type of protocol. In Java Servlet we have to packages: 1. Javax .servlet 2. Javax.servlet.http Both of these contain classes and interfaces but the difference is that javax.servlet package is protocol independent and javax.servlet.http is protocol dependent. The servlet interface provides for methods that manage the servlet and its communications with clients. When a server accepts a call from client, it receives two objects i.e. ServletRequest and ServletResponse. The ServletRequest class encapsulates the communication from the client to the server, while the ServletResponse class encapsulates the communication from the servlet back to the client. We have three methods of Servlet interface. 1. init( ): This method allow a servlet to perform any initialization before being invoke against http request 2. service( ): This is the entry point for executing application logic in a servlet.

3. destroy( ): The container calls this method before removing a servlet request out of service. INTRODUCTION TO TOMCAT Webserver And JSP TOMCAT is the server container that is used in the official Reference Implementation for the Java Servlet and Java Server Pages technologies. The Java Servlet and Java server Pages specification are developed by Sun under the Java community Process. Tomcat is developed in an open and participatory environment and released under the Apache Software License. Tomcat is intended to be a collaboration of the best-of-breed developers from around the world.

Tomcat Version For the impatient, current Tomcat production quality releases vs. Servlet/JSP specifications: Servlet/JSP Spec Tomcat Version 2.4/2.0 5.5.9 2.3/1.2 4.1.31 2.2/1.1 3.3.2 Note that although we offer downloads and documentation of older releases, such as Tomcat 3.x and 4.x, we strongly encourage users to use the latest stable version of Tomcat. We recognize that upgrading across major version not be a trivial task, and some support is still offered on the mailing list for users of old versions. Tomcat 5.X Tomcat 5.5 is the current focus of development. While it supports same Servlet and JSP Specification versions as Tomcat 5.0.x, there are significant changes in many areas under the hood, resulting in improved performance, stability, and total cost of ownership.

SYSTEM REQUIREMENT SPECIFICATION

1. INTRODUCTION
A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Nonfunctional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is thecustomer's assurance that the development organizationunderstands the issues or problems to be solved and the software behavior necessary to address those problems.Therefore, the SRS should be written in natural language(versus a formal language, explained later in this article), in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

The following subsections of the Software Requirements Specifications (SRS) document should provide an overview of the entire SRS. The thing to keep in mind as you write this document is that you are telling what the system must do so that designers can ultimately build it. Do not use this document for design!!!

1.1 PURPOSE

Identify the purpose of this SRS and its intended audience. In this subsection, describe the purpose of the particular SRS and specify the intended audience for the SRS.

1.2 SCOPE
The scope of SRS document is valid until the end of the project. Because, it is the bases for all the phases. Only on the basis of the SRS, whole project is developed. This is the only document that describes the requirement of the system. It is meant for used by the developer and will be the basis for validating the final delivered system. Any change made to the requirement in the future will have to go through a formal change process.
In this subsection:

(1) Identify the software product(s) to be produced by name (2) Explain what the software product(s) will, and, if necessary, will not do (3) Describe the application of the software being specified, including relevant benefits, objectives, and goals (4) Be consistent with similar statements in higher-level specifications if they exist This should be an executive-level summary. Do not enumerate the whole requirements list here.

1.3 DEVELOPERS RESPONSIBILITY

1. To Study the SystemDeveloper must study the system thoroughly. He should study all the aspects of the system. He must have a thorough knowledge of factors affecting the system. In this case, I studied the system for making a standard format for the information of employees. For this, I had to consider what all fields should be there inboth so that there should be no problem in the future. 2. To Create System DesignDeveloper has the responsibility of creating a system design on the basis of study of the system. He must draw appropriate DFDs and flowcharts before starting coding. 3. Coding Developer has the responsibility for writing the code for the system. He must take care that coding should be error free and free of bugs as far as possible so that less time is wasted during testing. Code should be properly documented by the developer. 4. Testing

Developer also has the responsibility of testing the code which is the most time consuming activity. Testing should be done very carefully so as to make the system error free. 5. Implementation Developer has to implement the system created by him. He must check whether it has been done properly. He must ensure that the minimum hardware and software requirements are met for efficient working of the system.

1.4 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS.

Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendices in the SRS or by reference to documents. This information may be provided by reference to an Appendix.

1.5 REFERENCES
In this subsection: (1) Provide a complete list of all documents referenced elsewhere in the SRS (2) Identify each document by title, report number (if applicable), date, and publishing organization (3) Specify the sources from which the references can be obtained. This information can be provided by reference to an appendix or to another document. If your application uses specific protocols or RFCs, then reference them here so designers know where to find them.

1.6 OVERVIEW
In this subsection: (1) Describe what the rest of the SRS contains (2) Explain how the SRS is organized Dont rehash the table of contents here. Point people to the parts of the document they are most concerned with. Customers/potential users care about section 2, developers care about section 3. Describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in section 3, and makes them easier to understand. In a sense, this

section tells the requirements in plain English for the consumption of the customer. Section3 will contain a specification written for the developers.

4.2 OVERALL DESCRIPTION

Describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in section 3, and makes them easier to understand. In a sense, this section tells the requirements in plain English for the consumption of the customer. Section3 will contain a specification written for the developers. 4.2.1 FUNCTIONS Provide a summary of the major functions that the software will perform. Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product. For clarity: (1) The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time. (2) Textual or graphic methods can be used to show the different functions and their relationships. Such a diagram is not intended to show a design of a product but simply shows the logical relationships among variables. AH, Finally the real meat of section 2. This describes the functionality of the system in the language of the customer. What specifically does the system that will be designed have to do? Drawings are good, but remember this is a description of what the system needs to do, not how you are going to build it. (That comes in the design document). 4.2.2 CONSTRAINTS Provide a general description of any other items that will limit the developer's options. These can include: (1) (2) (3) (4) (5) (6) (7) (8) (9) Regulatory policies Hardware limitations (for example, signal timing requirements) Interface to other applications Parallel operation Audit functions Control functions Higher-order language requirements Signal handshake protocols (for example, XON-XOFF, ACK-NACK) Reliability requirements

(10) Criticality of the application (11) Safety and security considerations This section captures non-functional requirements in the customers language. A more formal presentation of these will occur in section 3. Our projects general Constraints :-- Must be able to run on windows platform Must use links relative to its main page Must have monitor with minimum resolution of 8000x600 pixels Must have 256MB of RAM Must have processor-450 Mhz Oracle 8i works on Microsoft Window 2000 server and Microsoft Window XP JAVA and JSP works on Microsoft Window 2000 server, Microsoft Window 2003 Server and Microsoft Window XP Professional. Must have Microsoft Mouse or compatible pointing device. Must have 2GB of Disk Space

4.2.3 ASSUMPTIONS AND DEPENDENCIES List each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption might be that a specific operating system would be available on the hardware designated for the software product. If, in fact, the operating system were not available, the SRS would then have to change accordingly. This section is catchall for everything else that might influence the design of the system and that did not fit in any of the categories above. Text should be kept to a minimum to increase readability Any click able areas should be large for easier selection Color choice should be appropriate to accommodate users with color blindness Pictures should have names associated with them in case a text browser is being used User knows how to operate the mouse Minimal reading skills required Link colors coordinate with page colo

 Every graphic link has a matching text link

4.3 SPECIFIC REQUIREMENTS

This section contains all the software requirements at a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. Throughout this section, every stated requirement should be externally perceivable by users, operators, or other external systems. These requirements should include at a minimum a description of every input (stimulus) into the system, every output (response) from the system and all functions performed by the system in response to an input or in support of an output. The following principles apply: (1) Specific requirements should be stated with all the characteristics of a good SRS correct unambiguous complete consistent ranked for importance and/or stability verifiable modifiable traceable (2) Specific requirements should be cross-referenced to earlier documents that relate (3) All requirements should be uniquely identifiable (usually via numbering like 3.1.2.3) (4) Careful attention should be given to organizing the requirements to maximize readability (Several alternative organizations are given at end of document) Before examining specific ways of organizing the requirements it is helpful to understand the various items that comprise requirements as described in the following subclasses. This section reiterates section 2, but is for developers not the customer. The customer buys in with section 2, the designers use section 3 to design and build the actual application. Remember this is not design. Do not require specific software packages, etc unless the customer specifically requires them. Avoid over-constraining your design. Use proper terminology: The system shall A required, must have feature The system should A desired feature, but may be deferred til later The system may An optional, nice-to-have feature that may never make it to implementation. Each requirement should be uniquely identified for traceability. Usually, they are numbered 3.1, 3.1.1, 3.1.2.1 etc. Each requirement should also be testable. Avoid imprecise statements like, The system shall be easy to use Well no kidding, what does that mean? Avoid motherhood and apple pie type statements, The system shall be developed using good software engineering practice

Avoid examples, This is a specification, a designer should be able to read this spec and build the system without bothering the customer again. Dont say things like, The system shall accept configuration information such as name and address. The designer doesnt know if that is the only two data elements or if there are 200. List every piece of information that is required so the designers can build the right UI and data tables.

4.3.1 EXTERNAL INTERFACES

This contains a detailed description of all inputs into and outputs from the software system. It complements the interface descriptions in section 2 but does not repeat information there. Remember section 2 presents information oriented to the customer/user while section 3 is oriented to the developer. It contains both content and format as follows: Name of item Description of purpose Source of input or destination of output Valid range, accuracy and/or tolerance Units of measure Timing Relationships to other inputs/outputs Screen formats/organization Window formats/organization Data formats Command formats End messages

4.3.2 FUNCTIONS
Functional requirements define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. These are generally listed as shall statements starting with "The system shall These include: Validity checks on the inputs Exact sequence of operations Responses to abnormal situation, including Overflow Communication facilities Error handling and recovery

Effect of parameters Relationship of outputs to inputs, including Input/Output sequences Formulas for input to output conversion

It may be appropriate to partition the functional requirements into sub-functions or sub-processes. This does not imply that the software design will also be partitioned that way.

4.3.3 PERFORMANCE REQUIREMENTS

This subsection specifies both the static and the dynamic numerical requirements placed on the software or on human interaction with the software, as a whole. Static numerical requirements may include: (a) The number of terminals to be supported (b) The number of simultaneous users to be supported (c) Amount and type of information to be handled Static numerical requirements are sometimes identified under a separate section entitled capacity. Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions. All of these requirements should be stated in measurable terms. For example, 95% of the transactions shall be processed in less than 1 second rather than, An operator shall not have to wait for the transaction to complete. (Note: Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function.)

4.3.4 DESIGN CONSTRAINTS

Specify design constraints that can be imposed by other standards, hardware limitations, etc. Specify the requirements derived from existing standards or regulations. They might include:

(1) (2) (3) (4)

Report format Data naming Accounting procedures Audit Tracing

For example, this could specify the requirement for software to trace processing activity. Such traces are needed for some applications to meet minimum regulatory or financial standards. An audit trace requirement may, for example, state that all changes to a payroll database must be recorded in a trace file with before and after values. Logical Database Requirements This section specifies the logical requirements for any information that is to be placed into a database. This may include: Types of information used by various functions Frequency of use Accessing capabilities Data entities and their relationships Integrity constraints Data retention requirements

If the customer provided you with data models, those can be presented here. ER diagrams (or static class diagrams) can be useful here to show complex data relationships. Remember a diagram is worth a thousand words of confusing text. 4.3.5 SOFTWARE ACCEPTANCE CRITERIA There are a number of attributes of software that can serve as requirements. It is important that required attributes by specified so that their achievement can be objectively verified. The following items provide a partial list of examples. These are also known as non-functional requirements or quality attributes. These are characteristics the system must possess, but that pervade (or cross-cut) the design. These requirements have to be testable just like the functional requirements. Its easy to start philosophizing here, but keep it specific.

Reliability Specify the factors required to establish the required reliability of the software system at time of delivery. If you have MTBF requirements, express them here. This doesnt refer to just having a program that does not crash. This has a specific engineering meaning.

Availability

Specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart. This is somewhat related to reliability. Some systems run only infrequently on-demand (like MS Word). Some systems have to run 24/7 (like an e-commerce web site). The required availability will greatly impact the design. What are the requirements for system recovery from a failure? The system shall allow users to restart the application after failure with the loss of at most 12 characters of input. Security Specify the factors that would protect the software from accidental or malicious access, use, modification, destruction, or disclosure. Specific requirements in this area could include the need to: Utilize certain cryptographic techniques Keep specific log or history data sets Assign certain functions to different modules Restrict communications between some areas of the program Check data integrity for critical variables Maintainability Specify attributes of software that relate to the ease of maintenance of the software itself. There may be some requirement for certain modularity, interfaces, complexity, etc. Requirements should not be placed here just because they are thought to be good design practices. If someone else will maintain the system Portability Specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems. This may include: Percentage of components with host-dependent code Percentage of code that is host dependent Use of a proven portable language Use of a particular compiler or language subset Use of a particular operating system Once the relevant characteristics are selected, a subsection should be written for each, explaining the rationale for including this characteristic and how it will be tested and measured. A chart like this might be used to identify the key characteristics (rating them High or Medium), then identifying which are preferred when trading off design or implementation decisions (with the ID of the preferred one indicated in the chart to the right). The chart below is optional (it can be confusing) and is for demonstrating tradeoff analysis between different non-functional requirements. H/M/L is the relative priority of that non-functional requirement. ID 1 Characteristic Correctness H/M/L 1 2 3 4 5 6 7 8 9 10 11 12

2 3 4 5 6 7 8 9 10 11 12

Efficiency Flexibility Integrity/Security Interoperability Maintainability Portability Reliability Reusability Testability Usability Availability

Definitions of the quality characteristics not defined in the paragraphs above follow. Correctness - extent to which program satisfies specifications, fulfills users mission objectives Efficiency - amount of computing resources and code required to perform function Flexibility - effort needed to modify operational program Interoperability - effort needed to couple one system with another Reliability - extent to which program performs with required precision Reusability - extent to which it can be reused in another application Testability - effort needed to test to ensure performs as intended Usability - effort required to learn, operate, prepare input, and interpret output

Organizing the Specific Requirements For anything but trivial systems the detailed requirements tend to be extensive. For this reason, it is recommended that careful consideration be given to organizing these in a manner optimal for understanding. There is no one optimal organization for all systems. Different classes of systems lend themselves to different organizations of requirements in section 3. Some of these organizations are described in the following subclasses. System Mode Some systems behave quite differently depending on the mode of operation. When organizing by mode there are two possible outlines. The choice depends on whether interfaces and performance are dependent on mode User Class Some systems provide different sets of functions to different classes of users. Objects

Objects are real-world entities that have a counterpart within the system. Associated with each object is a set of attributes and functions. These functions are also called services, methods, or processes. Note that sets of objects may share attributes and services. These are grouped together as classes. Feature A feature is an externally desired service by the system that may require a sequence of inputs to effect the desired result. Each feature is generally described in as sequence eof stimulus-response pairs. Stimulus Some systems can be best organized by describing their functions in terms of stimuli. Response Some systems can be best organized by describing their functions in support of the generation of a response. Functional Hierarchy When none of he above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by either common inputs, common outputs, or common internal data access. Data flow diagrams and data dictionaries can be use dot show the relationships between and among the functions and data. Additional Comments Whenever a new SRS is contemplated, more than one of the organizational techniques given in 3.7 may be appropriate. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification. Three are many notations, methods, and automated support tools available to aid in the documentation of requirements. For the most part, their usefulness is a function of organization. For example, when organizing by mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful. In any of the outlines below, those sections called Functional Requirement i may be described in native language, in pseudocode, in a system definition language, or in four subsections titled: Introduction, Inputs, Processing, Outputs.

5. DESIGN
5.1 INTRODUCTION
The purpose of design phase is to plan a solution of the problem specified by the requirements document. The design phase focuses on the detailed implementations of the system accommodated in the feasibility study. Emphasis is on translating performance specification into design specifications. The design phase is a transition from a user-oriented document to a document oriented to the programmer or database personnel .The design must implement all of the explicit requirements contained in the analysis model and it must accommodate all of the implicit requirements desired by the organization. Main issues involved in the design phase: Design document must act as a guide for those who generate the code and for those who test and subsequently maintain the software. Design document must provide a complete picture of the software, addressing the data, functional and behavioral domains from an implementation perspective. A design should be modular; that is, software should be logically partitioned into elements, that performs specific functions and sub functions. A design should contain both data and procedural abstractions. A design should lead to interfaces that reduce the complexity of the connections between modules and with the external environment. Design should be derived using a repeatable method that is driven by information obtained during Software Requirement Analysis. The design activity is often divided into two separate phases:1. System Design or Top-level Design 2. Detailed Design or Logic Design

5.2 SYSTEM DESIGN

Even if the project is small and the requirements are simple, there is still a mental design process that occurs in between understanding the requirements and starting to construct. Design becomes more and more important as the project becomes larger, more complex and impacts more and more people. Once the requirements are known, one typically sees a myriad of alternatives for construction. These alternatives include the tools and technology that are to be utilized, the scalability of the solution, and the structure of the components to be built. In essence, the Design Phase is where one looks at the many potential solutions and narrows down the choices to determine the most effective and efficient way to construct the solution. The Design Phase answers the questions about "how" you will build the best solution for your organization and your environment. At the end of the Design Phase, we aim to come out with the logical solution. The solution is "logical" because it exists on paper. This logical solution will be then turned into a physical solution in coding phase. To accomplish the design phase I will be using help of Data Flow Diagrams, Flow charts and ER diagrams.

5.2.1 OVERVIEW
The system design refines the flow charts prepared during the study phase of the system development life cycle (SDLC). Each phase flow chart is reviewed for accuracy and the team decides upon the best way for the system to perform the data processing functions. System analysis describes what a system should do to meet the information needs of users. The strategy specifies how the system will accomplish the objectives. It consists of both logical and physical design activities. LOGICAL SYSTEM DESGIN Logical system involves developing general specifications for how basic information system activities of input, processing, output, storage and control can meet end-user requirements.

In the system investigation stage, logical design concepts may have been developed in a feasibility study. PHYSICAL SYSTEM DESIGN Physical system design involves detailed design of user interface products and methods, database structures, processing and control procedures. Hardware, software and personnel specification are developed for the processing for the proposed system. Software designers use their knowledge of business operations, information processing and hardware/software to specify the physical design of an information system. System design can be viewed as the design of User interface design (screen, form, report and dialog design). Data design (data element structure design). Process design (program and procedure design).

5.2.2 HIGH LEVEL DFD

The Data Flow Diagram shows the flow of data or information. It can be partitioned into single processes or functions. Data Flow Diagrams can be grouped together or decomposed into multiple processes. DFD Elements

Process Depending on the level of the diagram it may represent the whole system as in a Context (level 0) diagram or a business area, process (activity), function, etc. in lower levels. Symbol: Rectangle.

External Entity(s) Used for representing person/group, interacting with the system. Symbol: Rectangular box with a shadow.

Data Store

Used for representing information repository. In the physical model, this represents a file, table, etc. Symbol: Open ended rectangle Data Flows Used to represent directional movement of data to and from external entities, process and data Stores. Symbol: Solid line with arrow. Design for Outdial flow Collect the base for dialouts. Pick the mobile number one by one from this base for dialouts. Do check the mobile number for barr. In database a table is maintained for the barr numbers. If the mobile number is found in the table then the number is not valid for dialout. Pick next number for dialout. If the number is not found in the tables then do the SRI (Send Routing Information) of the number. If the SRI test results positive then insert the mobile number in a separate table in a database. Zero Level DFD Pick the number from this table and create the .lck file and .txt file for this number in a specified folder. An exe is then run that will pass the request for subscription of the subscriber for the particular service to the subscription procedure. And do entry in a database.

Cellebrum Service Provider

Service / Schemes

OBD PROCESS

PRMO Calls

SUBSCRIBER

5.2.3 ABSTRACT INPUT OUTPUT ELEMENTS

After the DFD, the second step in system design is to separate the transforms in the DFD that convert the input or output to the desired format from the ones that perform the actual transformations. Once the DFD is ready, the next step is to identify the highest abstract level of input and output. The most abstract input elements (MAI) are those data elements in the DFD that are further removed from the physical inputs but can still be considered inputs to the system. The most abstract input elements often have little resemblance to actual physical data. These are often the data elements obtained after operations like error checking, data validation, proper formatting, and conversations are examples. The most abstract output elements (MAO) are identified from the outputs in the DFD and traveling towards the inputs. These are the data element that is most removed form the actual outputs but can still be considered outgoing. The MAO data elements may also be considered the logical output data items, and the transforms in the DFD after these data items are basically to convert the logical output in the form in which the system is required to produce the output. User name and password Access to the particular from according to user name The MAO is the first and important MAI is the user name and password, in this user name is matched as stored in database and according to that access is provided. The first MAO is the results, that means, entries to database are recorded which can be further retrieved whenever required Our project includes: Abstract Inputs 1. User Name and Password. 2. Base File Inputs 3. Generic file Input

4. Channels occupation 5. Mobile number for test call 6. Base entry 7. Query Input Abstract Outputs 1. Query report 2. Base left 3. Activation and Outdials 4. Reports and Graphs

5.2.4 FIRST LEVEL FACTORING

The first level factoring results in a very high level structure, where each subordinates module has a lot of processing to do. To simplify these modules, They must be factored into subordinate modules that will distribute a work of a module. Each of the input and output and transformation modules are considered for factoring. To factor an input module, the transform in the DFD, that produces the data item is treated as the central transformation, with the input module being considered the main module. A factoring input module is created for each input data stream coming into new central transform and a subordinate transform module is created fro new central transform. The new input modules now created can then be factored again until the physical inputs reached. The first level factoring divides the problem into input and output modules. These I/O modules are decided on basis of high level DFD. Input modules are: Login Activation and Outdials Query Graphs service selections File reading Output modules are: Entry to database

 Activation, Outdials and base left Graphs and Reports Alerts message sending Logs entry to files

6. CODING
Although or company doesnt provide the code but we had permission to show the name of modules that we use there. Some of the coding that we had done can be shown. It is shown below

7. TESTING : TEST PHASES AND CYCLES

7.1 INTRODUCTION
Software testing is the process used to assess the quality of computer software. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test[1] , with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs. Quality is not an absolute; it is value to some person. With that in mind, testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behaviour of the product against a specification. An important point is that software testing should be distinguished from the separate discipline of Software Quality Assurance (S.Q.A.), which encompasses all business process areas, not just testing.[citation needed] Over its existence, computer software has continued to grow in complexity and size. Every software product has a target audience. For example, a video game software has its audience completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it presumably must assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment.

Testing methods
Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. Black box testing treats the software as a black-box without any understanding of internal behavior. It aims to test the functionality according to the requirements.[14] Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix etc. White box testing, however, is when the tester has access to the internal data structures, code, and algorithms. White box testing methods include creating tests to satisfy some code coverage criteria. For example, the test designer can create tests to cause all statements in the program to be executed at least once. Other examples of white box testing are mutation testing and fault injection methods. White box testing includes all static testing.

White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested.[15] Two common forms of code coverage are function coverage, which reports on functions executed and statement coverage, which reports on the number of lines executed to complete the test. They both return a coverage metric, measured as a percentage. In recent years the term grey box testing has come into common usage. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey-box because the input and output are clearly outside of the black-box we are calling the software under test. This is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. Grey box testing may also include reverse engineering to determine, for instance, boundary values. Special methods exist to test non-functional aspects of software. Performance testing checks to see if the software can handle large quantities of data or users. Usability testing is needed to check if the user interface is easy to use and understand. Security testing is essential for software which processes confidential data and to prevent system intrusion by hackers. To test internationalization and localization aspects of software a pseudolocalization method can be used.

Testing process
A common practice of software testing is performed by an independent group of testers after the functionality is developed before it is shipped to the customer.[16] This practice often results in the testing phase being used as project buffer to compensate for project delays, thereby compromising the time devoted to testing.[17] Another practice is to start software testing at the same moment the project starts and it is a continuous process until the project finishes.[18] In counterpoint, some emerging software disciplines such as extreme programming and the agile software development movement, adhere to a "test-driven software development" model. In this process unit tests are written first, by the software engineers (often with pair programming in the extreme programming methodology). Of course these tests fail initially; as they are expected to. Then as code is written it passes incrementally larger portions of the test suites. The test suites are continuously updated as new failure conditions and corner cases are discovered, and they are integrated with any regression tests that are developed. Unit tests are maintained along with the rest of the software source code and generally integrated into the build process (with inherently interactive tests being relegated to a partially manual build acceptance process). Testing can be done on the following levels:

Unit testing tests the minimal software component, or module. Each unit (basic component) of the software is tested to verify that the detailed design for the unit has been correctly implemented. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors.[19]

Integration testing exposes defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system. [20] System testing tests a completely integrated system to verify that it meets its requirements. [21] System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements.[citation needed]

Before shipping the final version of software, alpha and beta testing are often done additionally:

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-theshelf software as a form of internal acceptance testing, before the software goes to beta testing.[citation needed] Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.[citation needed]

Finally, acceptance testing can be conducted by the end-user, customer, or client to validate whether or not to accept the product. Acceptance testing may be performed as part of the hand-off process between any two phases of development

7.2 TEST PLAN

A test plan is a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.

Introduction
State the purpose of the Plan, possibly identifying the level of the plan (master etc.). This is essentially the executive summary part of the plan. You may want to include any references to other plans, documents or items that contain information relevant to this project/process. Identify the objective of the plan or scope of the plan in relation to the Software Project plan that it relates to. Other items may include, resource and budget constraints, scope of the testing effort, how testing relates to other evaluation activities (Analysis & Reviews), and possible the process to be used for change control and communication and coordination of key activities. As this is the "Executive Summary" keep information brief and to the point.

Intention of this project has to be included

Test items (functions)

These are things you intend to test within the scope of this test plan. Essentially, something you will test, a list of what is to be tested. This can be developed from the software application inventories as well as other sources of documentation and information. This can be controlled on a local Configuration Management (CM) process if you have one. This information includes version numbers, configuration requirements where needed, (especially if multiple versions of the product are supported). It may also include key delivery schedule issues for critical elements. This section can be oriented to the level of the test plan. For higher levels it may be by application or functional area, for lower levels it may be by program, unit, module or build.

. Test plans in software development

In software testing, a test plan gives detailed testing information regarding an upcoming testing effort, including

Scope of testing. Schedule. Test Deliverables. Release Criteria. Risks and Contingencies

State the purpose of the Plan, possibly identifying the level of the plan (master etc.). This is essentially the executive summary part of the plan.

1. Design

Documentation - Requirements Specification & Functional Specification 2. System Test Plan 3. Unit Test Plans & Test Conditions 4. Unit Test Results 5. System Test Conditions 6. System Test Progress/Results 7. Post System Test Review 8. Integration Test Results 9. Pilot Implementation Review 10. Project Review The diagram above outlines the Test Approach. Boxes 1 - 6 show the major review stages prior to Test execution. Boxes 7 - 10 show the phases planned for & after test execution. While the above diagram concentrates on the testing aspect of SQA's role, there is an ongoing role also, in ensuring the quality of the major deliverables throughout the lifecycle of the project. SQA's role will be to ensure that all Quality Inspections occur for all the agreed deliverables and that follow up actions and initiatives are pursued.

Testing and production phases Before explaining the test and production configurations for WebSphere Application Server for z/OS, you must understand which test phase should be done on the z/OS platform and which should be done on other platforms.Before explaining the test and production configurations for the Application Server, you must understand which test phase should be done on the z/OS platform and which should be done on other platforms. The following sections explain the different phases:

Unit test phase Component test phase

Function test phase System test phase Production phase

Unit test phase The development platform for WebSphere Application Server for z/OS is a WebSphere distributed system (for example, Windows or Linux Intel). The development environment includes tools such as WSAD for Web content delivery. The IBM tooling solution assumes that you develop enterprise beans in WSAD and perform unit (basic) testing of the business logic in the WebSphere Test Environment. We used the TOM CAT Server. Component test phase Component testing involves the joining together of several beans into logical components, providing them with access to data, and testing them together. While this can be done on WebSphere Application Server for z/OS, most of our current installations perform this level of testing using a distributed platform such as Windows 2000 running WebSphere Application Server Advanced Edition. This allows a small team of developers to join the pieces of code that they have developed together and test the interactions. This testing does not test z/OS platform functions and features directly, but focuses on the individual beans and the relationships between them. Function test phase Function testing involves joining the various components together, connecting them to test data in the target database, and validating the function that the application provides. Where this test is performed is dependent on what the function is, and what its data requirements are. If the target deployment platform is z/OS, then it may make sense to do this level of testing there. This is possible by setting up one or more test servers into which the application is installed. When the application is installed into the test server, the installer defines where in the JNDI directory the references to the application will be stored. The test clients will need to be configured with this information that tells the clients the location of the test application. The test clients will then drive requests against the test server to perform the functional testing. You can also use remote debugging tools to diagnose problems you encounter along the way.

System test phase Before you put an application into production on z/OS, you should deploy the code into a WebSphere Application Server for z/OS server for testing. You may bring up the application and simulate a real load on the application. The important point here is that the code needs to run on z/OS before it goes into production. To do this, you need to define an additional test server (on a whole new cell dedicated to the test system) and install the application into it. When installed, beans that are part of the application should be registered in a different subtree of the JNDI directory (this occurs by default). The test clients need to be configured to the version of the application that is being tested and the tests run. Production phase You can install the application in a production WebSphere Application Server for z/OS cell after you are satisfied with the functional and system testing. The difference between a production cell and a test cell is whether the remote debugger is allowed to be attached. Normally, it is not acceptable for a production workload to stop because someone flowed a remote debugging request to it.

7.3 FEATURES TO BE TESTED

This is a listing of what is to be tested from the user's viewpoint of what the system does. This is not a technical description of the software, but a USER'S view of the functions. 8. It is checked that the person who has proper authentication can access the system .No other person can misuse the rights. Security level is checked 9. Entering Validate mobile number and length. 10. Excel Report program output. 11. Interface design and appearance on different systems. 12. Message is delivered or not. 13. Fast responses from the database. 14. Every connection of the query is properly closed. 15. Status check. 16. OBD Exception Check.

8. PROJECT LEGACY
8.1 CURRENT STATUS OF PROJECT
Description: Keeping in view, user requirements and problem definition, as described in earlier sections, following is recommended, it may be noted that of other alternative system was preferred due to advantages, such as simplicity, lower cost and flexibility. Activities defined as functions: After thorough analysis, it was found that it would prove to be more efficient to combine two or more activities. It has led to redefinition of combine of activities: 1. Updating of schedule 2. Testing 3. Checking status accordingly 4. Total Outdials and Activation calculation automatically 5. Preparation of MIS automatically 6. Graph Representation Making choices for activities: System is driven by main menu, listing the contents the choices for activities. Multiple Menus are provided along with submenus. Files: In many functions, files relevant to particular activity is created or opened. Thus different activities to perform result in a number of files, which not only preserve data but also indicate stages of development of data. Since files are stored in disks, problem of file storage and wear/tear is solved.

Input validation: At every step of data entry some input validation is applied, which checks the validity of data entered. If inputted data is not according to validation applied, the suitable error message is generated. Reports: Format of reports confirms to users requirements as given in appendix and is easily modified. Interface: System provides a user friendly interface using simple English. Language: It is proposed to make the system in JSP language for simplicity, flexibility, easy understandability and uniformity. CONCLUSION: The project developed by me is successfully implemented for administrative purpose. This project got overwhelming response from users. Project is still in the maintenance and testing phase and would be implemented within next month.

8.2 FURTHER RECOMMENDATIONS:

OBD services can also be run from the same interface. All work is same in OBD department except for few services. On addition of some features in the interface, the interface will work for the OBD department. The OBD can be automated if we have been provided all the data in advance. Just mention the order of services to be executed and the OBD will run automatically without any disturbance.

10. BIBLIOGRAPHY
BOOKS: 1. System Analysis and Design 2. Software Engineering 3. Object Oriented Modeling And Design 4. Data Base Management System 5. SQL, PL/SQL 6. JAVA How To Program7. The Complete Reference- Java7. JSPWEBSITE: www.cellebrum.com www.gsmworld.com www.spiceindia.com www.google.com http://www.enwikipedia.org From these sites and books we have searched for smscs, ivrs, java codes, oracle queries,jsp codes By: Elias M Awadh By : Pankaj jalote By: James Ramburg By: Bipin C. Desai By: Ivan Bayross By: Deitel and Deitel By: Herbert Schildt (McGraw Hill) By Wrox Publications