SURESH GYAN VIHAR UNIVERSITY, JAIPUR

Project Report
On

Telephone Directory System

Submitted Guided To: Birendra Bright KESWANI

(iv sem)

By: k.
(HOD CA Dept..)

Rathor
M.C.A.

CERTIFICATE
This is to certify that this report embodies the original work done by Birendra k. Rathor during this project submission as a partial fulfilment of the requirement for the System Design Project of Masters of Computer Application ! Semester" of the Suresh Gyan Vihar University, Jaipur Bright Keswani (HO o! ".#.$ ept.% Suresh Gyan Vihar Universe

ACKNOWLEDGEMENT
The satisfaction that accompanies that the successful completion of any task would be incomplete without the mention of people whose ceaseless cooperation made it possible" whose constant guidance and encouragement crown all efforts with success# $e are grateful to our project guide "r. Bright Keswani for the guidance" inspiration and constructi%e suggestions that helpful us in the preparation of this project# Birendra k.Rathor
MCA (4th sem)

Tab e !" C!#te#ts

Chapte$ %&'
1.1 Introduction 1.2 Objective 1.3. Application 1.4. Feature 1.5. DFD 1.5. Overview 5 5 6 6 7 8

Chapte$ (&'
2.1. !"te# De"cription 2.2. %loc& Dia'ra# $ 11

Chapte$ )&'
3.1. (ec)nolo'ie" *"ed 3.2. %a"ic +o#ponent" 13 16

3.3 . Liquid Crystal Display Chapte$ 4&'

18

4.1. Fea"ibilit!

tud!

1$

Chapte$ *&'
5.1. Data (able" 21

Chapte$ +&'
6.1. Cost estimation 6.2. +onclu"ion 23 26

CHAPTER: 1 1.1 Introdu tion

A telephone directory (also called a telephone book and phone book) is a listing of telephone subscribers in a geographical area or subscribers to services provided by the organization that publishes the directory. It consists of the na e as !ell as the telephone nu ber of people added as contact in the directory. "a e and telephone nu ber are displayed in alphabetical order.

1.! Content
Subscriber names are generally listed in alphabetical order, together with their postal or street address and telephone number. In principle every subscriber in the geographical coverage area is listed, but subscribers may request the exclusion of their number from the directory, often for a fee. Their number is then said to be "unlisted" American nglish, "ex!directory" #nglish or "private" Australia and "ew #ealand. $ractices as to the display of %aller!I& on calls made by unlisted subscribers vary by 'urisdiction. Sometimes the %aller!I& on outbound calls is not shown( in other 'urisdictions unlisted numbers are displayed unless the caller dials
$

a bloc)ing code( in others the customer may request automatic bloc)ing by the telephone company. In the *S, under current rules and practices, mobile phone and +oice over I$ listings are not included in telephone directories. fforts to create cellular directories have met stiff opposition from several fronts, including a significant percentage of subscribers who see) to avoid telemar)eters.In ,--, the *.S. Supreme %ourt ruled .in Feist v. Rural/ that telephone companies do not have a copyright on telephone listings, because copyright protects creativity and not the mere labor of collecting existing information. 0ithin the geographical reach of the %ourt, the Feist ruling has resulted in the availability of many innovative telephone directory services on %&!123 and the 0orld 0ide 0eb.

1.3 "#$e ti%es

%e are deter ined to design a syste !hich is intended in saving na e and nu ber of desired persons. &he ain ob'ective of telephone directory is to add( search( edit and delete various contacts.

1.4 Appli ations

&elephone directory has been fre)uently in use in our daily life. %eco only see telephone directory installed in *+&" telephone sets( obile phone etc. &elephone ,irectory application provides the ability to search( vie!( and anage entries in a directory. -obile ,irectory application should allo! any subscriber !ith any type of obile device that supports .*/+ to instantly search telephone contact nu ber of any individual . &he search result data loads directly to the obile screen and gives the user option 01 2A33( +A4#( 4I#%(
5

+#", &6 7/", or ,I+2A/,. -obile ,irectory eli inates the need to call any other call center.

1.5 Features:Secure asy to use 1eliable and accurate "o need of remember

1.6 Data Flow Diagram :-

1.8 "%er%ie& o' Pro$e t :(

&he report is organized in chapters9 each dedicated to e:plaining the pro'ect in easier !ay. Although detailed infor ation is not provided due to security reasons of the pro'ect and its replication protection( but the chapters are brief enough to convey the !ork done. In the chapter( a brief introduction of the pro'ect is presented. &he second deals !ith the syste description of the pro'ect !here !e have describe the block diagra of the pro'ect and hard!are and soft!are portion of the pro'ect. In the third ( !e have described the detail infor ation of pro'ect !here function of each hard!are co ponents and soft!are portion is described. 7ourth deals !ith observation. 7ifth deals !ith li itation and further i ple entation of pro'ect. And finally it gives conclusion to the pro'ect.
;

#H$&'(R )

!.1 )*)TE+ DE)CRIPTI",:(

&he ain ai of the pro'ect is to create a directory that is able to provide the ability to search( vie!( and anage entries in a directory about various individuals. 2.1 <lock ,iagra &he basic block diagra of the pro'ect !hich sho!s ho! =&elephone ,irectory> !orks is sho!n belo!.

).) iagra*+,

!.! -lo . Dia/ram :(

1@

!.3 Des ription o' t0e #lo . dia/ram :(

&he above block diagra describes the pro'ect architecture. 7ro the block diagra !e can understand the flo! of the syste . As sho!n above first of all nu ber and na e are entered via keypad .&hese data are displayed regularly in the lcd connected to a port of icrocontroller.&hese contact of the individual can be stored in the e:ternal e ory (##*/6-). As further these records can be further anipulated by retrieving the fro the ##*/6-. &hese contacts can be edited( deleted( also searched as re)uired by the user . &here are ainly t!o parts in the block diagra .

a. +oft!are part b. Aard!are part )o't&are part 11 +oft!are enables us to perfor specific tasks. +oft!are is a tool that interfaces !ith hard!are and i ple ents the user specifications. 7or interfacing bet!een icrocontroller and 32,( icrocontroller and Beypad and ##*/6- various soft!are tools are used. &he soft!are tools used are as follo!s0 a. 21progra b. +,22 c. #C1,o!nloader d. &op vie! si ulator e. *roteus
11

ing

a. C(pro/rammin/ 11 &he 2 progra ing is a popular and !idely used high level progra ing language for creating co puter progra s. *rogra ers around the !orld e brace 2 because it gives a:i u conco ponents used !hile developing progra . c. *roteus is ainly used in si ulation( a si ple odel of ckt !as created and !ith particular progra it !as loaded to vie! output. Hard&are part :1 a. -icrocontroller b.32, display c. ##*/6d.Beypad &he hard!are parts of the pro'ect includes

CHAPTER 3
12

3.1 TECHNOLOGIES USED

Front end as4 5T36 Bac end as: Advance 7ava Ser!er: Apache tomcat 8.9 Data"ase: 3icrosoft access #uer$%n& 'an&ua&e: Sql

3.2 -asi Components :(

It is i portant to get ac)uainted !ith the integral co ponents and its purpose that is used in this pro'ect before going through the pro'ect details. &he list of the a'or co ponents that are used are as follo!s0 Ae: Beypad 01 Beypads are a part of Au an -achine Interface and play really i portant role in a s all e bedded syste !here hu an interaction or hu an input is needed. -atri: keypads are !ell kno!n for their si ple architecture and ease of interfacing !ith any icrocontroller. -icrocontroller (A&;?c$1) 7eatures 01 &he A&;?2$1 1. 4B< of 7lash icrocontroller provides the follo!ing standard features0 e ory

2. 12; bytes of /A13

3.32 ID6 lines !ith t!o 151bit ti erDcounters 4.7ive vector t!o1level interrupt architecture $.7ull duple: serial port 5. @n1chip oscillator and clock circuitry.

3.3 Liquid Crystal Display2LCD3

Introduction 32, is a 3i)uid 2rystal ,isplay. A 32, is a thin( flat panel used for electronically displaying infor ation such as te:t( i ages( and oving pictures. Its uses include onitors for co puters( televisions( instru ent panels( and other devices ranging fro aircraft cockpit displays( to every1 day consu er devices such as video players( ga ing devices( clocks( !atches( calculators( and telephones.

32, *in ,escription 01

14

Ta#le o' LCD pin:(

3.4 -I2/626"&/633#/ (A&;?2$$)

DE)CRIPTI",:( &he A&;?2$$ is a lo!1po!er( high1perfor ance 2-6+ ;1bit icroco puter !ith 2@B <ytes of 7lash progra able and erasable read only e ory (*#/6-). &he device is anufactured using At el>s high1density nonvolatile e ory technology and is co patible !ith the industry1standard ;@2$1 instruction set and pin out.
1$

-icrocontroller <oard01

&he icrocontroller board consists of one crystal oscillator !hose function is to create an electrical signal !ith a very precise fre)uency. &his fre)uency is co only use to keep track of ti e( to provide a stable clock signal for digital integrated circuits( and to stabilize fre)uencies forradio trans itters.

3 Beypad and 32, Interfacing &o scan the keypad co pletely( !e need to ake ro!s lo! one by one and read thecolu ns. If any of the buttons is pressed in a ro!( it !ill take the correspondingcolu n to a lo! state !hich tells us that a key is pressed in that ro!. If button 1 of aro! is pressed then 2olu n 1 !ill beco e lo!( if button 2 then colu n2 and so on. #ach button of Beypad is assigned !ith various functions. %e have assigned keys!ith alphabets and nu ber. +o e keys have been allocated for special function like enu( delete( back. %hen these keys are pressed various special functions such asadd( edit( search etc has been generated !ith certain functions in progra ing. %hencontact has to be added !e insert na e as !ell as nu ber using keypad. Beypad isconnected to *2 through !hich input is given to icrocontroller. &hese datas areconcurrently displayed in the 32,. 32, is connected to *1 and *3( !hich serves as output device. 7irst of all 32, is initialized !ith follo!ing control codes as sho!n in the table. %hen data bus of 32, is provided !ith ;1bit data then certain output is generated.

15

3.$ /#+E3&

and ,I+2E++I6" 0

,#+2/I*&I6" 67 7I",I".01 %orking in this pro'ect led us to any findings !hich initially !e !ere una!are of. %e not only got chance to i ple ent our theoretical kno!ledge into practical but also got opportunity to learn ne! progra ing languages. &his pro'ect has helped us to enhance our kno!ledge about electronics co ponents( soft!are develop ent and !ireless co unication. %orking in 32, !e found out that to display alphanu eric value in 32, !e can either use 32, table !hich provides us he:. code corresponding to the data that is to be displayed or !e can use A+2II value of that data. %hile interfacing Beypad !ith -icrocontroller !e found out that sa e port ust be used for both colu n and ro!s. %hile interfacing of ##*/6- addressing is the key factor and using proper delay is very essential for output generation.

Limitations:&his pro'ect on F&#3#*A6"# ,I/#2&6/GH has follo!ing li itations I ,elay in pressing the keys cannot be achieved perfectly. I #,I& option in this pro'ect could not be i ple ented. I -e ory anage ent is a great dra!back. !hen back button is pressed.
18

I &his unit is having proble

*roble

6ccurred ,uring *rogra

ing occurredJ

I If !e don>tuse the sa e portfor key pad entry then proble

I %hile storing the flipped char in the array na eKrrL all the flipped characters !ere also stored so a ne! na e1KttL array !as stored ade and the last value

in na eKrrL after each case !as stored..eg..a(b(c !as pressed then another button pressed then at (MN)case values !as interchanged.. I *roble occurred !hen tried to break out of !hile loop

I 2alculation of particular delay !as difficult. ,uring Aard!are &esting I 2ables created !ere very fragile and ulti ately !e used glue stick to fi: it. I Cip +ocket is troubled us !ith it>s pin holdings. I *roble in 4oltage regulation for icrocontroller !as fetched

. I Interfacing of ##*/6- !as a great challenge. 7urther I ple entation01 electronics pro'ects. &his architecture is a basic backbone for other

I &he concept of F&elephone ,irectory Fcan be i ple ented !ith interfacing of --2 cards using +*I (+erial *eripheral Interface). I &his architecture can be used in syste s such as 1.*ass!ord <ased door lock 2./estaurant Auto ation +yste &his architecture can be i ple ented in all syste s that uses input as Beypad and 6utput as 32,

1;

CHAPTER 4 FEASIBILITY STUDY

(.1 ECONO)IC FE*SIBILIT+:conomic analysis is most frequently used for evaluation of the effectiveness of the system. 3ore commonly )nows as cost:benefit analysis the procedure is to determine the benefit and saving that are expected from a system and compare them with costs, decisions is made to design and implement the system. This part of feasibility study gives the top management the economic'ustification for the new system. This is an important input to themanagement the management, because very often the top management does not li)e to get confounded by the various technicalities that bound to be associated with a pro'ect of this )ind. A simple economic analysis that gives the actual comparison of costs and benefits . (., TECHNIC*L FE*SIBILIT+:Technical feasibility centers on the existing manual system of the test management process and to what extent it can support the system. According to feasibility analysis procedure the technical feasibility of the system is analy;ed and the technical requirements such as software facilities, procedure, inputs are identified. It is also one of the important phases of the system development activities. The system offers greater levels of user friendliness combined with greater processing speed. Therefore, the cost of maintenance can be reduced. Since,processing speed is very high and the wor) is reduced in the maintenance point of view management convince that the pro'ect is operationally feasible. (.3 BEH*-IOU.*L FE*SIBILIT+ :$eople are inherently resistant to change and computer has been )nown to facilitate changes. An estimate should be made of how strong the user is li)ely to move towards the development of computeri;ed system. These are various levels of users in order to ensure proper authentication and authori;ation and security of sensitive data of the organi;ation.
1?

CH*/TE. 5

2@

T*BLE DESIGN <., %ustomer4 Table

S."o. =ield "ame&ata Type , > ? @ Id "ame Addreess $rovider "umber Text Text Text

<.> Service $rovider 4 Table

S."o. =ield "ame , > ? @ < Id $lan IssueAdate &ueAdate $rovidername &ata Type "umber "umber &ate:time &ate:time Text
21

<.? &irectry4 Table

S."o. =ield "ame , > ? @ Broup 3ove %opy &ata Type "umber "umber "umber

add new "umber

22

CHAPTER 6 4.1 Cost estimation:(

Software cost estimation is the process of predicting the effort required to develop a software system. 3any estimation models have been proposed over the last ?9 years. This paper provides a general overview of software cost estimation methods including the recent advances in the field. As a number of these models rely on a software si;e estimate as input, we first provide an overview of common si;e metrics. 0e then highlight the cost estimation models that have been proposed and used successfully. 3odels may be classified into > ma'or categories4 algorithmic and non!algorithmic. ach has its own strengths and wea)nesses. A )ey factor in selecting a cost estimation model is the accuracy of its estimates. *nfortunately, despite the large body of experience with estimation models, the accuracy of these models is not satisfactory. The paper includes comment on the performance of the estimation models . 0.1 So1t2are s%3%n& The software si;e is the most important factor that affects the software cost. This section describes five software si;e metrics used in practice. The line of code and function point are the most popular metrics among the five metrics. L%ne o1 Code: This is the number of lines of the delivered source code of the software, excluding comments and blan) lines and is commonly )nown as LOC C,9D. Although 62% is programming language dependent, it is the most widely used software si;e metric. 3ost models relate this measurement to the software cost. 5owever, exact 62% can only be obtained after the pro'ect has completed. stimating the code si;e of a program before it is actually built is almost as hard as estimating the cost of the program. A typical method for estimating the code si;e is to use expertsE 'udgement together with a technique called PERT C?D. It involves expertsE 'udgment of three possible code!si;es4 Sl, the lowest possible si;e( Sh the highest possible si;e( and Sm, the most li)ely si;e. The estimate of the code!si;e S is computed as4 SF+1O+nO+ D5 Cost est%4at%on
23

There are two ma'or types of cost estimation methods4 algorithmic and non-algorithmic. Algorithmic models vary widely in mathematical sophistication. Some are based on simple arithmetic formulas using such summary statistics as means and standard deviations C-D. 2thers are based on regression models C?GD and differential equations C?9D. To improve the accuracy of algorithmic models, there is a need to ad'ust or calibrate the model to local circumstances. These models cannot be used off-the-shelf. ven with calibration the accuracy can be quite mixed. 0e first give an overview of non!algorithmic methods. Non-a'&or%t54%c )et5ods *na'o&$ cost%n&4 This method requires one or more completed pro'ects that are similar to the new pro'ect and derives the estimation through reasoning by analogy using the actual costs of previous pro'ects. stimation by analogy can be done either at the total pro'ect level or at subsystem level. The total pro'ect level has the advantage that all cost components of the system will be considered while the subsystem level has the advantage of providing a more detailed assessment of the similarities and differences between the new pro'ect and the completed pro'ects. The strength of this method is that the estimate is based on actual pro'ect experience. 5owever, it is not clear to what extend the previous pro'ect is actually representative of the constraints, environment and functions to be performed by the new system. $ositive results and a definition of pro'ect similarity in term of features were reported in C??D. E67ert 8ud&4ent4 4! This method involves consulting one or more experts. The experts provide estimates using their own methods and experience. xpert!consensus mechanisms such as &elphi technique or $ 1T will be used to resolve the inconsistencies in the estimates. The De'75% tec5n%9ue wor)s as follows4 ,/ The coordinator presents each expert with a specification and a form to record estimates. >/ ach expert fills in the form individually .without discussing with others/ and is allowed to as) the coordinator questions. ?/ The coordinator prepares a summary of all estimates from the experts .including mean or median/ on a form requesting another iteration of the expertsH estimates and the rationale for the estimates. @/ 1epeat steps >/!?/ as many rounds as appropriate. A modification of the &elphi technique proposed by Ioehm and =ahquhar C<D seems to be more effective4 Iefore the estimation, a group meeting involving the coordinator and experts is arranged to discuss the estimation issues. In step ?/, the experts do not need to give any rationale for the estimates. Instead, after each round of estimation, the coordinator calls a meeting to have experts discussing those points where their estimates varied widely. /ar %nson4 *sing $ar)insonEs principle Jwor) expands to fill the available volumeK C>GD, the cost is determined .not estimated/ by the available resources rather than based on an ob'ective assessment. If the software has to be delivered in ,> months and < people are available, the effort is estimated to be 89 person!months. Although it sometimes gives good estimation, this method is not recommended as it may provide very unrealistic estimates. Also, this method does not
24

promote good software engineering practice. /r%ce-to-2%n4 The software cost is estimated to be the best price to win the pro'ect. The estimation is based on the customerEs budget instead of the software functionality. =or example, if a reasonable estimation for a pro'ect costs ,99 person!months but the customer can only afford person!months, it is common that the estimator is as)ed to modify the estimation to fit 89 personmonthsH effort in order to win the pro'ect. This is again not a good practice since it is very li)ely to cause a bad delay of delivery or force the development team to wor) overtime. Botto4-u74 In this approach, each component of the software system is separately estimated and the results aggregated to produce an estimate for the overall system. The requirement for this approach is that an initial design must be in place that indicates how the system is decomposed into different components. To7-do2n4 This approach is the opposite of the bottom!up method. An overall cost estimate for the system is derived from global properties, using either algorithmic or non!algorithmic methods. The total cost can then be split up among the various components. This approach is more suitable for cost estimation at the early stage. *'&or%t54%c 4et5ods:The algorithmic methods are based on mathematical models that produce cost estimate as a function of a number of variables, which are considered to be the ma'or cost factors. Any algorithmic model has the form4 ffort F f.x1, x2, L, xn/ where Mx1, x2, L, xnN denote the cost factors. The existing algorithmic methods differ in two aspects4 the selection of cost factors, and the form of the function f. 0e will first discuss the cost factors used in these models, then characteri;e the models according to the form of the functions and whether the models are analytical or empirical. Cost 1actors:Iesides the software si;e, there are many other cost factors. The most comprehensive set of cost factors are proposed and used by Ioehm et al in the %2%232 II model C8D. These cost factors can be divided into four types4 /roduct 1actors4 required reliability( product complexity( database si;e used( required reusability( documentation match to life!cycle needs( Co47uter 1actors4 execution time constraint( main storage constraint( computer turnaround constraints( platform volatility( /ersonne' 1actors4 analyst capability( application experience( programming capability( platform experience( language and tool experience( personnel continuity(
2$

/ro8ect 1actors4 multisite development( use of software tool( required development schedule. The above factors are not necessarily independent, and most of them are hard to quantify. In many models, some of the factors appear in combined form and some are simply ignored. Also, some factors ta)e discrete values, resulting in an estimation function with a piece!wise form.

4.1 C",CL5)I",1(
&he ai of this pro'ect !as to build an &elephone directory through !hich allo!ed to add(search( delete contacts of individual andaccess toe:ternal e orydevice. At the co pletion of this pro'ect !e are able to add( search and delete contacts hence the pro'ect is co pleted successfully. A appro:i ate odel of &elephone ,irectory !as asse bled using keypad( lcd( icrocontroller and ##*/6-.

25