Bt Wholesale Adsl Pre Registration System

Published Date: 02 Nov 2017

Dr. Anastasis Petrou

Prepared For

COURSE TITLE: RAPID APPLICATION DEVELOPMENT

COURSE CODE: IMM006

Prepared by

Anita Sachan (u0848528)

Sateesh Javaraya Vijaya (u0921410)

Soolmaz Razmjooei (u0824088)

November 27th, 2009

TABLE OF CONTENTS

1. Abstract 4

2. Keywords 5

3. Introduction 6

4. Related Work / Literature review 7

5. Identification of a System 14

6. System Assessment 15

Innovation and Usability 15

Interoperability and Usability 15

7. System Design and creation of prototype 15

System Design 15

Prototype 16

8. Use-Case Diagrams 17

Diagram 17

Use Case Scenarios 18

9. Class Diagrams 21

10. Sequential Diagrams 23

11. Discussion 25

12. Benefits and weaknesses of the sub-system prototype design 26

Benefits 26

Weakness 26

13. Conclusions 27

14. Appendices 28

Group Meetings 28

Collaboration Diagram 29

Activity diagram 30

15. References 31

Abstract

Our research work explores the usage of Rapid Application Development methodology in developing a Software System in a very short span of time. British Telecommunications Plc, world’s oldest telecommunications company has grown at a rapid pace in technology developments and uses RAD methodologies for developing many of its Software Systems against tight deadlines.

The current research is about ‘BT ADSL PRE REGISTRATION SYSTEM’ which was developed using RAD. When a Broadband Service Provider enters the market they usually go into markets where there is a presence of Broadband and hence awareness and the need exist. In 2002 BT decided to accelerate its Broadband coverage to areas in UK which were not covered by broadband technology.

BT was faced with a task of gauging the demand and deciding whether to add a particular exchange into its broadband network or not within a time span of two months. The entire development of the Demand Tracking System (Pre-Registration form) from requirements capturing to system delivery needed to be done in a short span of just 2 months. It was also critical that the system had to be flexible and scalable for future enhancements, so was ease of use. Rapid development of the application was a priority coupled with scalability, ease of use and interfacing the application with BT’s current database.

Hence, BT decided to use RAD methodology and tools for developing the Pre-Registration form. The purpose of this form is to enable end users â€" customers to pre-register their interest for obtaining a broadband connection from BT. (Stevens & May, 2004)

Keywords

Actor

Asymmetric digital subscriber line (ADSL)

BT ADSL Pre Registration Form

British Telecommunications Plc (BT)

ISP (Internet Service Provider)

Pre-Registration System

Rapid Application Development (RAD)

Use Case

Waterfall Methodology

Introduction

Broadband is a high bandwidth always on connection to the Internet. It’s faster and easier to use and does not require dialling in to get connected unlike earlier methods of connecting to the Internet. It can be provided over a telephone line, cable or satellite link. It is also 10 to 100 times faster than connecting through dial up modem connections. (Broadbandguide.org, 2003)

ADSL short for Asymmetric Digital Subscriber Line provides high speed internet access over copper telephone lines. The signals are sent digitally and the download speed is much higher. It is called Asymmetric because the download speeds are much higher than the upload speeds as a typical upload like a request for a web page does not consume a lot of bandwidth. It provides an always on connectivity to the internet and though it connects through the telephone, a splitter connected to the line ensures that both the telephone and the internet are available simultaneously. (tech-faq.com, 2009)

BT is one of the largest broadband providers in UK. Over the years BT Broadband has covered most of UK, some areas were still uncovered and BT decided to cover those areas also.

Providing Broadband coverage to an area involves significant investments in infrastructure, for e.g., setting up an exchange etc., this is done by the Broadband Service provider. As the infrastructure involves large investment it is feasible only if there is sufficient demand in the area for Broadband connections.

Ascertaining the demand is difficult in areas where there is no Broadband coverage and only dial up services exist. After the Exchange and the required infrastructure are set up, people might buy the Broadband connection or might not. If the service provider does not sell sufficient connections then it is a loss making proposition for the organisation which is setting up the infrastructure. In the past service providers would base their decision to include an exchange into the Broadband roll out by analysing the existing internet traffic via dial-up services. This analysis would give them an approximate figure of potential broadband end users.

To gauge and track the demand BT decided to implement a Broadband Demand Tracking System and advertise it to public asking them to Pre register for a broadband connection which would give BT a more reliable figure of potential Broadband end users exchange wise.

A poll among the public was required to collect the data from the market. Due to regulatory restrictions within which BT wholesale operates it was not possible for BT to approach the public directly for a poll as the regulations restricted BT to supply directly to end users.

All the pre registrations were to be collected by ISP’s and the Retail wings of BT like BT Retail, BT Openworld and BT Global Services. This data was to be forwarded to BT wholesale and BT wholesale would then fulfil those requirements in a demand based method. The BT ADSL PRE-REGISTRATION FORM was a front end form available on the website of ISP’s in that particular area. This info was then given to BT for demand analysis and tracking. BT had set a Trigger Level for exchanges and once an exchange reaches that Trigger Level then BT decides to include that exchange in its Broadband rollout plan.

It is necessary to mention here that the Telecommunications market place is dynamic in terms of the products. New and innovative products â€" twice as good need to be delivered in half the time â€" the pressure is on delivering a product NOW which meets the rapidly changing demands of the market. A new system was urgently required to support the BT ADSL PRE-REGISTRATION FORM and timeline was a short span of two months. Within two months BT had to capture the requirements, develop a system which is flexible, scalable and user friendly and implement a pre registration form â€" which by any standards is a challenge and very unlikely to be addressed by the traditional software development methods such as the Waterfall method. This development required an entirely workable, quick and efficient methodology and BT decided to use RAD â€" Rapid Application Development. (Stevens & May, 2004)

Related Work / Literature review

WHAT IS RAD?

Rapid Application Development â€" a term coined by James Martin, in a text he published with the title ‘Martin in 1992’ - is defined as “Rapid Application Development (RAD) is a development lifecycle designed to give much faster development and higher-quality results than those achieved with the traditional Lifecycle methods. It is designed to take the maximum advantage of powerful development software that has evolved recently” (CASEmaker.com, 2005)

A definition by Professor Clifford Kettemborough of Whitehead College, University of Redlands gives a much precise explanation of RAD. According to him Rapid Application Development is “an approach to building computer systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for top-notch quality and productivity. RAD drastically raises the quality of finished systems while reducing the time it takes to build them.” (CASEmaker.com, 2005)

While Online Knowledge defines RAD as “a methodology that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality. This is achieved by using a series of proven application development techniques, within a well-defined methodology.” (CASEmaker.com, 2005)

RAD is one of the many ideas that is being touted as a potential solution to many of the problems being faced by software industry in developing quicker and efficient solutions. RAD gains its strength from its methodology - A RAD project starts with initial feasibility study to establish the objectives and benefits of the project, based on Joint Application Development structured, joint sessions of user representatives and the software design team. Users are then shown as fast as possible, a prototype of the system, the initial prototype will go through at least two iterations before it is finalised into a working solution.

User-driven prototyping enables the analyst and the user to identify the correct requirements and data required to develop the system. The review of prototype by the user avoids last minute changes to the system and gives the user an opportunity to analyse whether the system does fulfil the requirements. This iterative method eliminates last minute modifications to the system thus saving considerable effort, time and money.

The RAD methodology includes aspects of project management, quality assurance and systems testing.

In short, Rapid Application Development is a process through which the development cycle of an application is expedited. Rapid Application Development thus enables quality products to be developed faster, saving valuable resources.

(Bellalcheru, 2008)

WHY RAD?

According to a study by Battles, Mark and Ryan 80 percent of systems are delivered late and over budget. (Girling & McManus, 1998)

1. Frequent requests for change by users

2. Users lack of understanding of their own requirements

3. Overlooked tasks

4. Insufficient user-analyst communications

5. Poor or imprecise problem definition

6. Lack of adequate methodology

The above mentioned symptoms were highlighted by Professor Alber Lederer to be the key symptoms in the failure to deliver IT systems. Such symptoms are characteristic of the traditional methodology like Waterfall Method wherein Business and Technology are moving twice as fast as IT systems developments. (Girling & McManus, 1998)

Software development methodologies can be categorized into the traditional, e.g., Waterfall method and the modern or evolutionary methodologies like prototype, spiral and scrum methodologies. The shorter-time-to-market, deadline oriented, dynamic market of today needs a software development method which adapts itself to the changing dynamics and enables on-the-go requirement clarification. Building prototypes is an accepted practice in evolutionary models. They help clarify requirements, allow them to be tested, are iterative and in some cases they could even be extensible into another solution. And it is here that RAD methodology and tools play a very important role.

RAD tools can provide a set of reusable components that can be readily used in a solution, which can enhance productivity and reduce development time. The biggest advantage of using RAD tools is that it is possible to test a solution as it is being built. RAD uses a modular prototype approach, wherein each module or block is fully functional by itself and can be tested. So as soon as one module - a forms module, for instance, is developed focus group users can input data and test it!! As it is already tested, developers start with something that is already working and this reduces their development time. Components can be added and tested on the fly and you could end up with a complete and fully workable validated solution in a few iterations.

(Bellalcheru, 2008)

HISTORY OF RAD

Traditional lifecycles devised in the 1970s, which are still widely used today, are based upon a structured step-by-step approach to developing systems called Waterfall Method. This rigid sequence of steps forces a user to “sign-off” after the completion of each specification before development can proceed to the next step. The requirements and design are then frozen and the system is coded, tested, and implemented. With such conventional methods, there is a long delay before the customer gets to see any results and the development process can take so long that the customer’s business could fundamentally change before the system is even ready for use.

Barry Boehm, Chief SW Engineer at TRW, introduced his Spiral Model in response the step by step approach. His model is risk driven and as a way of reducing risk Boehm implemented software prototyping. The development process of the Spiral Model separates the product into several parts or levels while performing risk analyses and prototyping and these steps are repeated at each level.

At DuPont in the mid to late 1980’s the work of Boehm and Gilb led to the formulation of the methodology called Rapid Iterative Production Prototyping (RIPP). This work was then extended by James Martin into a larger, more formalized process, which later on came to be known as Rapid Application Development (RAD). It converts the sequential development conventional methods into an iterative process, wherein user requirements are gathered, solution designed, prototyped, the prototype reviewed, user input provided and the process iterates again.

(CASEmaker.com, 2005)

Source: http://www.casemaker.com/download/products/totem/rad_wp.pdf

ESSENTIAL ASPECTS OF RAD

Rapid Application Development has four essential aspects:

Methodology

People

Management

Tools

Inadequacy of any one of these ingredients will result in RAD not delivering at top speed.

METHODOLOGY

A combination of the best available techniques and specifying a sequence to make them work together in the most effective way

Using modular, evolutionary prototypes that eventually transform into the final product

Using Workshops, instead of interviews, to gather requirements and review design

Select a set of CASE tools to support modelling, prototyping, and code reusability, as well as automating most of the combination of techniques

Implementing timeboxed development that allows development teams to quickly build the core of the system and implement refinements in subsequent releases

Providing guidelines for success and describing pitfalls to avoid.

Users are involved actively throughout the RAD lifecycle to ensure that business requirements and user expectations are clearly understood. RAD takes advantage of powerful application development tools to develop high quality applications rapidly.

Modular Prototyping is used to help users visualize and request changes to the system as it is being built, allowing applications to evolve iteratively.

The structure of the RAD lifecycle is thus designed to ensure that developers build the systems that the users really need.

The project goes through the following four stages, covering activities to scope and define business requirements and design, develop, and implement the application system that supports those requirements.

􀂊 Requirements Planning: Business functions are defined and the systems scope is determined

􀂊 User Design: System’s data and processes are modelled in a workshop and a working prototype of critical system components is built

􀂊 Construction: Development stage wherein the physical application system is constructed

􀂊 Implementation: Implementation or deployment this stage includes final user testing and training, data conversion, and the implementation of the application system.

PEOPLE

Excellent tools by themselves do not guarantee success. Fast development relies equally heavily on the people involved and for RAD to work people with right skills and talents are very important. Each team member plays multiple roles and the teams are close knit requiring for the people to be carefully chosen, highly trained and highly motivated.

As speed is of essence in a RAD project management initiatives are mandatory to cut through political delays or red tape. Key end users must be made available to participate in workshops during the Requirements planning and User design stages.

The Construction team using the CASE toolset should be poised to move quickly and at the end of the development cycle, the cutover team handling training and cutover must also be ready to move quickly.

The key players in a Rapid Application Development project include:

Sponsor: Funds the system and values the new system, usually a high level executive and is dedicated to achieving results quickly

User Coordinator: Oversees the project from the user perspective and is appointed by the Sponsor

Requirements Planning Team: A team of high-level users who participate in the Joint Requirements Planning workshop

User Design Team: A team comprising of both high-level users from the Planning Team and lower-level users with a more detailed knowledge of the system to participate in the design workshop

User Review Board: A team of users who review the system after construction and decide whether modifications are necessary before cutover

Training Manager: The person responsible for training end users to work with the new system

Project Manager: The person who oversees the development effort

Construction (SWAT) Team: A small Team of two to six developers who are highly trained to work together at high speed called The SWAT (Skilled Workers with Advanced Tools). To achieve the fastest possible development, the team members must be highly skilled in the RAD methodology and in using the chosen CASE toolset.

Workshop Leader: Joint Requirements Planning and Joint Application Design workshops are his forte.

MANAGEMENT

Bureaucracy and political obstacles usually stand in the way of achieving high speed development. Managing a RAD project is tricky as it needs total commitment from the management for it to succeed. The management should be able to motivate the users and IT staff, manage the SWAT teams and prove that RAD means speed, quality and productivity.

TOOLS

The twin goals of the goals of high-speed and high quality are achieved by RAD methodology using both computerized tools and human techniques. The success of any Rapid Application Development project is primarily dependent upon the tools used.

Software industry faces many problems in developing software and it requires Power tools to overcome the problems involved with software development. These power tools can change the methods of construction by using design-automation techniques, code generation, and computer aided planning and analysis. The power tools utilized in Rapid Application Development are Computer-Aided Systems Engineering (CASE) tools. Such CASE tools enable us to overcome many of our software development problems through process innovations such as Rapid Application Development. (CASEmaker.com, 2005)

IMPACT OF RAD ON SOFTWARE INDUSTRY

In the pre RAD era, software was developed in a sequential manner. Each step of the application design and development was documented and completed sequentially. System designers interview the users, document the requirements and start working on the design phase. When they complete the design phase, it is presented to the user and the user is asked to sign an agreement to the effect that the design being presented will meet their needs.

The development team then starts working on the next phase which is development. Usually the design documents consist of technical jargon and architecture diagrams which the user may not understand. And often, after the development is completed and the user is presented with the completed design for testing, the user finds that it does not meet their requirements at all.

This stepwise, sequential approach was called the Waterfall Methodology which is a Traditional methodology for software development.

The world, Technology in particular seems to be on a perpetual fast forward to future.

We are always looking for faster ways to do things â€" internet is faster, networks transport bits faster, machines crunch numbers and hard disks spin faster. Code gurus are always at work spinning out miles of code and trying to put innovative products in the hands of consumers quickly. The human mind, of course, is limited by its ability to process only so much information and requires assistive technology and tools to do more. To deliver a system quickly, we need tools to analyse, design and build systems at a rapid pace. (Bellalcheru, 2008)

With its ability to deliver faster and better, RAD has a very high impact on the Software Industry. It enables a development to be made in a modular prototype approach which improves the development speed. Organisations can take up more development projects; software developers can get the end product to the users’ hands quickly. Users can test, confirm and accept or suggest changes in the development at early stages. Organisations save time, effort and money as they spend less time on developments and during that time the software developers develop features which are important and critical. They also spend less time, effort and money on redoing something that does not meet their requirements since it’s done in early stages of the development.

Identification of a System

The system we have identified for discussion is the BT ADSL Pre Registration System. The system allows a customer who is interested in obtaining a Broadband connection from BT to pre register his/her interest on an ISP’s website. The pre registration data is then sent to BT which validates the telephone number and documents the pre registration. BT had set a Trigger level and once interest from a particular exchange reaches the Trigger Level, BT includes that exchange into its Broadband rollout plan.

The system as is has the following features:

It is a form for registering a customer’s interest in obtaining a Broadband connection from BT.

It is hosted on a local ISP’s website.

The customer can enter his/her telephone number through which he/she wants to be connected to Broadband.

He/She then needs to enter his/her postcode, address, email and contact details.

After completing the form the customer submits it online through the ISP’s website.

The form is then linked to BT’s Pre Registration System called FastPRoBe.

The application was developed using the Microsoft .Net Framework and an SQL 2000 database. Then there was also the issue of customers registering multiple times from the same telephone number, which was overcome by linking the FastPRoBe to BT’s largest legacy system â€" CSS (Customer Services System) to validate the Pre Registration.

Another requirement that came along during the development was to link FastPRoBe to a MapInfo GIS application to indicate ADSL roll-out geographically. (Stevens & May, 2004)

System Assessment

BT’s pre registration ADSL system is used by the ISPs to directly submit customer data to register for ADSL pre-registration scheme. Customer can register for ADSL service by using pre-registration form on their ISP’s website. After careful discussion, we are suggesting following improvements in existing system on the basis of innovation, interoperability and usability.

Innovation and Usability

When customer provides their telephone number, the phone number is first validated and then that phone no is checked in already registered customer’s list. If customer’s phone number is on the registered list then the customer is informed that he/she is already registered and a status report in the form of pie chart is displayed which shows how many people have shown interest from customer’s area for the ADSL pre-registration scheme. By doing this, customer is informed just by filling his/her phone number that whether he/she is already registered or not. The customer need not fill the entire form to find out that he/she is already registered.

BT was first rolling out the ADSL to the exchanges where maximum number of people showed interest in the scheme. As more and more people register for the scheme it increases the chances of early arrival of ADSL to their exchange. The innovative approach of pie chart will encourage the people who have shown interest in the BT pre-registration scheme to encourage more people from their area to show interest in ADSL pre-registration scheme. This will be a win-win situation for BT as well as for the customer.

Interoperability and Usability

When customer provides his/her post code, the ISP (internet service provider) will pass on the post code to BT to retrieve the list of all possible addresses. After validation of post code, BT will retrieve the possible addresses. Customer need not fill the complete address, he/she can select it from the retrieved possible addresses.

System Design and creation of prototype

The proposed system is designed by using prototype, use case diagram, activity diagram, class diagram, sequence diagram and collaboration diagram. These diagrams provide better clarity about system and are very useful in understanding the system. Use case diagram, Activity diagram, Class diagram and Sequence diagram are created with the help of Rational Rose.

System Design

Customer opens the pre-registration form on ISP’s website to complete the ADSL pre-registration scheme. Customer enters the phone number (intended ADSL installation telephone number). ISP sends phone number to BT and BT validates the phone number. If phone number is invalid then customer can re-enter the phone number or terminate the form. If phone number is valid, BT checks if phone number is already registered or not. If phone number is already registered then BT sends a message back to the ISP that customer is already registered for this scheme and customer is shown the status report which will show how many people have shown interest from customer’s area in the form of a pie chart. If phone number is not in the list of already registered phone number then customer proceeds to provide his/her post code. ISP sends customer’s post code to BT and BT validates the post code. If post code is invalid, customer can re-enter the post code or terminate the form. For a valid post code, BT retrieves the possible addresses for that post code. BT sends the list of possible addresses to the ISP. Customer proceeds to select his/her address. After that, customer provides his/her e-mail address. Customer enters the contact number if he/she wants to provide a different phone number form the phone number he/she entered previously for the intended ADSL installation telephone number.

After completing all the required fields on the registration form, the customer submits the form. ISP sends the form to BT. BT saves all the details provided by customer. BT prepares the status report in the form of pie chart, for that first BT finds out the total number of people who have shown interest from customer’s area from list of already registered people. The ISP shows success message to the customer that he/she has successfully completed the ADSL pre registration form. He/she is now shown a status report (pie chart) for his/her area.

Prototype

Included improvements and Developments are based on the form available on adsl2go

Source: http://www.adsl2go.co.uk/CheckTest.php

Use-Case Diagrams

Diagram

Main Use Case Diagram for BT Pre-Registration System

Use case model for BT Pre-Registration scheme is depicting the use case interactions in the BT Pre-Registration system. It is a logical view of BT Pre-Registration system.

Customer as an actor will provide phone number, post code, e-mail and contact number to register for BT’s Pre-Registration system.

The “Validation Phone Number” use case validates the phone number and verifies if the customer is already registered. If customer is already registered for the Pre-registration system then he/she does not require registering again and a status report will displayed for customer to show percentage of people who have shown interest for BT Pre-Registration system from customer’s area.

The “Retrieve Address” use case validates the post code and than retrieves the all possible addresses.

The “Submit Pre Registration form” use case save the details (phone number, post code, address, e-mail and contact number) of the customer.

The “Pre registration Area Status Report” use case provide the status report in the form of pie chart which will show that how many people have shown interest in customer’s area.

The complete description for each use case shown in the use case diagram is provided in the next section “Use Case Scenarios”.

Use Case Scenarios

Use Case Scenario is a description about all the use case used in use case diagram.

Validate Phone Number

Use Case ID

BT- PRE REG-1

Use Case Name

Validate Phone Number

Created By

Anita Sachan

Last Updated By

Anita Sachan

Date Created

22-11-2009

Date Last Updated

23-11-2009

Actors

Customer

Description

This use case is started by the Customer. It provides the capability for the Customer to provide his/her phone no.

Trigger

When customer will enter phone no and comes out of that field.

Precondition

The customer is on the ADSL pre registration form web page.

Post-conditions

The customer has successfully provided his/her phone no.

Normal Flow

This use case begins when the Customer provides his/her phone no. to register for BT’s Pre Registration Scheme. First, system will verify the phone no (if phone no. is invalid then Alternate Flow “Invalid Phone No” will be executed).

If phone no is valid then system will check that whether this phone no is in the list (list of phone numbers of already registered customer). If phone no is already in the list then Alternate Flow “Phone no is in already registered list” will be executed, otherwise use case ends.

Alternative Flow

Invalid Phone No.: An invalid phone no is entered. The user can re-enter a phone no or terminate the use case.

Phone no is in already registered list: The user will be informed that he/she is already shown your interest. “Pre registration Area Status Report” use case will be invoked. The status will be shown in pie chart.

Priority

High

Frequency of Use

High

Special Requirements

There are no special requirements.

Retrieve Address

Use Case ID

BT- PRE REG-2

Use Case Name

Retrieve Address

Created By

Anita Sachan

Last Updated By

Anita Sachan

Date Created

22-11-2009

Date Last Updated

23-11-2009

Actors

Customer

Description

This use case is started by the Customer. It provides the capability for the Customer to provide his/her post code.

Trigger

When customer will enter post code and comes out of that field.

Precondition

The customer is on the ADSL pre registration form web page.

Post-conditions

The customer has successfully provided his/her post code.

Normal Flow

This use case begins when the Customer provides his/her post code to register for BT’s Pre Registration Scheme. System will pull out the possible house addresses for the provided post code (if post code is invalid then Alternate Flow “Invalid Post Code” will be executed). The use case ends.

Alternative Flow

Invalid Post Code: An invalid post code is entered. The customer can re-enter a post code or terminate the use case.

Priority

High

Frequency of Use

High

Special Requirements

There are no special requirements.

Submit Pre Registration form

Use Case ID

BT- PRE REG-3

Use Case Name

Submit Pre Registration form

Created By

Anita Sachan

Last Updated By

Anita Sachan

Date Created

22-11-2009

Date Last Updated

23-11-2009

Actors

Customer

Description

This use case is started by the Customer. It provides the capability for the Customer to submit his/her phone no, post code, e-mail, Contact no.

Trigger

When customer will submit the pre registration form.

Precondition

The customer submitted the ADSL pre registration form.

Post-conditions

“Pre registration Area Status Report” use case will be invoked.

Normal Flow

This use case begins when the Customer provides his/her phone no, post code, e-mail, contact no (if contact no field is empty, alternate flow “Same Phone no” will also be executed) to register for BT’s Pre Registration Scheme. The information is saved and “Pre registration Area Status Report” use case will be invoked which will produce status report for his/her area.

Alternative Flow

Same Phone no: Same phone no will be use for contact and use case will continue.

Priority

High

Frequency of Use

High

Special Requirements

There are no special requirements.

Pre registration Area Status Report

Use Case ID

BT- PRE REG-4

Use Case Name

Pre registration Area Status Report

Created By

Anita Sachan

Last Updated By

Anita Sachan

Date Created

22-11-2009

Date Last Updated

23-11-2009

Actors

This use case is not directly used by actor, it will be invoked from “Submit Pre Registration form” use case.

Description

This use case is started by the “submit pre registration form” use case. It provides the statistics in the form of pie chart, for people who have shown interest in pre registration scheme for his/her area.

Trigger

There will be two trigger for Pre registration Area Status Report use case. One is, when customer is already registered for pre registration scheme and the other is, when customer will submit his/her complete pre registration form.

Precondition

After “submit pre registration form” use case, this use case will begin.

Post-conditions

The system will display the total percentage of people who have shown interest in pre registration form in that area.

Normal Flow

This use case begins when “submit pre-registration form” use case will end. The system will first retrieve the potential customers from the customer’s area. Then the system will calculate the total percentage of people who have shown interest in the pre registration scheme.

Alternative Flow

None

Priority

High

Frequency of Use

High

Special Requirements

There are no special requirements.

Class Diagrams

Class Diagram for BT Pre-Registration System

In class diagram, there are three control classes :ValidatePhoneNumbers, :RetrieveAddress and :SavePreRegistrationForm and one utility class :StatusReport.

ValidatePhoneNumbers

A phone number is required to register for Pre Registration Scheme. After validating phone number, this class will check the phone number in the list of already registered phone number. If phone number is in the list of already registers phone number, percentage of people who have shown interest will be displayed in the form of pie chart.

This is a control class.

Public Operations:

ValidPhoneNumber (PhoneNumber : String) : String

First, Phone number will be validated if it exists and then phone number will be checked if it is already registered.

Private Operations:

IsPhoneNoRegistered (PhoneNumber : String) : boolean

Phone number will be checked that whether it is on the list of already registered phone number.

RetrieveAddress

A post code will be required to register for Pre Registration Scheme. After validation of post code, it will suggest the possible house addresses so that customer can select his/her house address.

This is a control class.

Public Operations:

RetrieveAddress (PostCode : String) : String

Post code validity will be verified and list of possible addresses will be provided.

Private Operations:

ValidatePostCode (PostCode : String) : boolean

Post code will be validated.

SavePreRegistrationForm

This class will save all the details provided by customer like phone number, post code, e-mail and contact number. After that this will call the status report class to get the information about status.

This is a control class.

Public Operations:

SavepreRegistrationForm (PhoneNumber : String, PostCode : String, AddressLine1 : String, City : String) : byte[]

Phone number, post code, e-mail and contact number will be saved. After that status report will be generated.

StatusReport

This class will prepare pie chart and for that class will calculate the percentage of people in the customer’s area who have shown interest in the BT Pre-Registration scheme. After calculating the percentage, pie chart will be prepared which will show the statistics for people from customer’s area who have shown interest in the pre-registration system.

This is a utility class.

Public Operations:

PreparePieChart (Percentage : int) : byte[]

After calculation of percentage of people have shown interest from customer's area, pie chart will be prepared.

Private Operations:

CalculatePercentage (PhoneNumber : String) : int

Percentage of people, who have shown interest from customer's area, will be calculated.

Sequential Diagrams

Sequence Diagram for BT Pre-Registration System

In BT Pre-Registration system, customer is an actor which is shown in the left. In the above sequence diagram, :ViewCustomerInterface is a boundary or interface class. This is the class or web form where customer provides his/her details. When customer provides his/her phone number in :ViewCustomerInterface class and enters then this web form goes to :ValidatePhoneNumbers class.

:ValidatePhoneNumber is a control class. :ValidatePhoneNumbers class validates the phone number, after that this class will check that whether phone number is in the list of already registered people. If a customer has already been registered he/she does not need to register again.

Now customer enters post code in web form which will transfer to :RetrieveAddress class. :RetrieveAddress class is control class. This class will first validate the post code and then will retrieve the list of all possible addresses. :RetrieveAddress class will send the possible addresses to :ViewCustomerInterface which will displayed to customer.

Customer will enter e-mail and then enter contact number in :ViewCustomerInterface. When customer clicks the submit, all details of customer will be send by :ViewCustomerInterface class to :SavePreRegistrationForm class.

:SavePreRegistrationForm class is a control class. All the details provided by customer like phone number, post code, address, e-mail and contact number will be saved. :SavePreRegistrationForm will send the customer’s post code to :StatusReport class. :StatusReport class is a utility class. :StatusReport class will prepare pie chart which will show that how many people have shown interest from customer’s area. Then this pie chart will send by :StatusReport class to :SavePreRegistrationForm class. :SavePreRegistrationForm class will send the pie chart to :ViewCustomerInterface class which will display pie chart to customer.

Discussion

The system we are discussing â€" BT ADSL PRE REGISTRATION SYSTEM was developed to ascertain the demand for BT Broadband connections in a particular area / exchange. Customers on dial up internet connections and who want faster, always on broadband connectivity from BT can pre register their interest using the form.

This form / system in turn gives BT a near accurate prediction of Broadband demand in that particular area and then based on the trigger levels, BT can decide to include that exchange in its Broadband rollout. Prior to designing this system, BT used to analyse the existing dial up internet traffic in a particular exchange and decide whether to include that exchange in its broadband roll out or not based on the potential demand. This system worked as a Broadband Demand Tracker for BT.

This system eliminated the guesswork and analysis which may not have given BT a near accurate figure of potential broadband users. BT also set a Trigger Level based on the number of Pre Registrations required before it can include the exchange into its broadband roll out scheme.

By developing this system BT achieved multiple goals of registering an interest for Broadband connectivity, gauging the demand, comparing the demand against a set trigger level and deciding to roll out broadband in a particular exchange.

Benefits and weaknesses of the sub-system prototype design

The Features and Benefits of the prototype design are as follow:

Benefits

Feature: As soon as the customer enters his/her phone number on the form, he/she gets a feedback instantly about his/her Pre Registration â€" whether he/she is already registered or not.

Benefit: The customer need not fill the whole form to find out his/her status.

Feature: If already Pre Registered the customer gets a status update of his/her request which gives information on the number of people already Pre Registered from that particular area and how many more are required to reach the Trigger Level.

Benefit: In turn, the customer can spread awareness about the Pre Registration and urge more people to sign up.

Feature: The system provides the status report of the customer’s area in the form of a pie chart.

Benefit: Visible status and easy to understand.

Feature: Customer fills in the postcode and the system retrieves the addresses.

Benefit: The customer need not key in the complete address.

Feature: If the customers contact number is same as the one on which he/she wants the installation, then he/she does not have to re enter the number.

Benefit: Need not enter the contact number twice.

Feature: The system prevents the customer from registering more than once from the same telephone number if he/she is already registered.

Benefit: BT will get more accurate information.

Feature: Customer has choice to show their interest. It is not like past, when BT will decide according to tracking traffic through ISP.

Benefit: Customer has choice to show their interest.

Weakness

Feature: The form is a front end which is hosted on an ISP’s website; it could lose connectivity to the backend at BT

Weakness: The data in the form could be lost

Feature: The ISP may go out of business for some reason

Weakness: The data of customers registered through that ISP will have to wait for another ISP to take over and then provide the connection which delays the process

Feature: The form may lose link with the address retrieval system based on postcode. Since the address field in the form is selection based the customer cannot key in his address

Weakness: The customer is not able complete the pre registration form

Feature: Customer registers for pre-registration form and does not want ADSL connection at a later stage

Weakness: Inaccurate information about demand

Conclusions

Through ADSL Pre Registration product, BT has designed a system which has potential use across all its businesses. The functionality of the form which is Demand Tracking can be used to track demand for a particular service before its introduction into the market. As on April 2004 909,087 pre registrations have been entered into BT database and 2734 exchanges have been broadband enabled. The same functionality can be used by BT to gauge demand for a new service it is planning to introduce, video calling on mobiles for instance. The form would give them almost precise number of potential users for video calling on mobile service. (www.samknows.com, 2004)

The same technology and system can be used to deliver the functionality across various other organisations as well, not just BT. As is typical of RAD prototypes, this could spin off into a complete solution by itself and some organisation could use it for a different purpose altogether.

Looking forward to the future this system has a huge potential. Organisations across can use this system of pre registering before introducing new service or a product. This way they could save a lot time and money by not trying to sell a product / service which does not have any demand at all.

Appendices

Group Meetings

First Meeting (13th Nov, 2009)

Our first group meeting was held on 13th Nov, 2009. In our first group meeting, as per the guidance of Module leader, we researched data on Athens. We searched using different keywords like Rapid application development, Agile etc. We read lot of documents and tried to find some company which has developed software using Rapid Application Development. Professor’s guidance was very helpful in this research. We downloaded lot of documents and we came to a decision that everybody will read these documents and also everybody will research more on same lines. We set a task for next meeting that everybody will come up with some topics which we will discuss in next meeting so we can finalize our topic in next meeting.

Second Meeting (17th Nov, 2009)

In our second group meeting which was on 17th Nov, 2009, as we decided, we all came with our topics. We exchanged and discussed our topics. Everybody explained their system. After rigorous discussion we as a group finalized to go ahead with BT ADSL Pre-Registration system. We agreed on this topic unanimously. We decided to research further on the topic to collect all possible relevant material.

 

Third Meeting (19th Nov, 2009)

We met on 19th Nov, 2009. We exchanged our researched material. We particularly discussed in detail the Pre-Registration form followed by a further discussion on improvements. The improvements were discussed on the lines of Innovation, Interoperability and Usability. In this group meeting we also finalized on the sections which each one of us going to work on.

After the group meeting, we discussed the identified system and assessed the improvement areas for innovation, interoperability and usability with the module leader.

 

Fourth Meeting (23rd Nov, 2009)

In our fourth meeting, we came up with the first draft for our individual assigned section. We discussed and explained our work with the other group members. We also suggested some improvement in each other’s work. We came to the conclusion that we are approaching the right direction and decided to further refine our individual sections. We decided to share our work on daily basis from now on and also decided to discuss the same over the phone.

 

Fifth Meeting (26th Nov, 2009)

This was our last group meeting; we were ready with the consolidated version of the coursework. We all reviewed it together and made the modifications as per the suggestions from the Module Leader. We were satisfied with our work and we decided to meet on the next day and submit the coursework.

Collaboration Diagram

Collaboration Diagram for BT Pre-Registration System

Activity diagram

Activity Diagram for BT Pre-Registration System