LIST OF CONTENTS

1.

Introduction 1.1 1.2 1.3 Current system Need for the New system Detailed Problem Definition

2 3 3 4 5 8 Requirement Analysis Use-case Analysis 3.2.1 Use-case Diagram 3.2.2 Use-case Description 9 14 14 15 16 System Flow Diagram 18 20 21 22 34 38 Test cases and Test Results 39 42

2. 3.

System Development life Cycle Analysis 3.1 3.2

4.

Design 4.1

5.

Implementation 5.1 5.2 5.3 Hardware Specification Source code Snap shots

6.

Testing 6.1

7.

Conclusion and suggestions for further work

CHAPTER 1

INTRODUCTION

CHAPTER1 INTRODUCTION

Electronic Phone Directory becomes the most useful type of source of information that people can find when they want to get in touch with any type of person. So there are many things that have changed a lot, but in this way they have improved and they have become much easier to be used by people. All the improvements that have been brought by technology are to our advantage and people are able to use them for their own good and for all the things that they need. The things that we can do are extremely different and technology can help us resolve various tasks without many efforts because we have all the needed means.

1.1 CURRENT SYSTEM:A Electronic Phone Book is a collection of documents in organized electronic form, which was feed by the users. Depending on the specific Electronic Phone Directory, a user may be able to access name, phone number/contact number, residential address, office address.

1.2 NEED OF PROPOSED SYSTEM:There are many things that now can be done only with the help of technology and the modern means that we have today for this type of things. The information that people are used to have in physical format or on printed papers is now available in electronic format because in this way the access is much easier for people and they can use it whenever 3

they need or want it. The great types of sources of information that we usually need to use, like books, newspapers or phone directories are now available in electronic form. The books and magazines, newspapers can be found easily and can be stored much easier without any other efforts. The electronic phone directory is something very useful for people because they can have a more accurate source of information that they can use all the time when they need it. The information can be found easier, people can find it easier, they can access it at any time, no matter where they are, what they do and in this way they can find all the time the right phone numbers for them.

1.3 PROBLEM DEFINATION:There are so many problems are there with old manual phonebook like searching of numbers ,unsorted lists, limited storing capacity, handling, problems that is why electronic directory has been invented.

CHAPTER 2

SYSTEM DEVELOPMENT LIFE CYCLE

CHAPTER 2 SYSTEM DEVELOPMENT LIFE CYCLE

A software process model or a software engineering paradigm is an abstract representation of a software process. It is a software development strategy that encompasses the process, methods and tool layers plus the three generic phases namely, definition phase, development phase and support phase. A process model is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required.

2.1 Linear Sequential Model:

The waterfall model or the classic life cycle is sometimes called the linear sequential model. It suggests a systematic approach to software development that begins at the system level and progresses through analysis, design, coding, testing and support. The principal stages of the model are explained as follows:-

1. Requirements Analysis And Definition :- The systems services, constraints and goals are established by consultation with system users. They are then defined in detail and serve as a system specification.

2. System And Software Design :- The system design process partitions the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships.

3. Implementation And Unit Testing :- During this stage the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specifications.

4. Integration And System Testing :- The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer.

5. Operation And Maintenance :- Normally this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the systems services as new requirements are discovered.

Linear Sequential Model for Software Engineering

CHAPTER 3

ANALYSIS

CHAPTER 3 ANALYSIS

3.1 Requirement Analysis

Requirements are a feature of a system or description of something that is capable of doing in order to fulfill the systems purpose. It provides the appropriate mechanism for understanding what the customer wants, analyzing the needs, assessing feasibility, negotiating a solution, specifying the solution unambiguously, validating the specification and managing the requirements as they are translated into an operational system. Requirement Analysis is a task done under software engineering that bridges the gap between system level requirements engineering and software design. While requirements engineering specifies softwares operational characteristics i.e. function, data and behavior, indicates softwares interface constraints, requirements analysis let the software engineer (called analyst) to refine the software allocation and construct models of data, functional and behavioral domains. Moreover, requirements analysis provides software developer with a representation of data, function and behavior that can be converted to data, architectural, interface and component-level designs. At last, we can say that the requirement specification makes available, the developer and the customer, a means to assess quality, once the software has been built.

Software requirements analysis can be categorized into four areas of effort, as follows Evaluation and synthesis Modeling Specification 9

Review

The analyst starts with the studies of system specification and the software project plan. It is then important to understand the software in a system context. Also, the review of the software scope, used to generate planning estimates, is necessary. Next, communication for analysis must be established, so as to ensure problem recognition. The reason behind is to recognize the basic problem elements perceived by the customer. The next major area of effort for analysis is problem evaluation and solution synthesis. The engineer (or analyst) must define all data objects that are extremely observable. He must evaluate the content and flow of information. Also, he must define and describe all software functions, understand software behavior in the context of the system affected events, establish the characteristics of system interface, and uncover additional design constraints.

After evaluating the current problems and desired information (i.e., input and output), the engineer and analyst starts synthesizing one or more solutions. Initially, the data objects, processing functions and the system behavior are defined in detail. Once establishing this information, the analyst then considers basic architectures for implementation.Thus the process of evaluation and synthesis proceeds until both analyst and the customer are sure that software can be adequately specified for subsequent development steps.

During the evaluation and synthesis activity, the analyst creates the system model so as to better understand data and control flow, functional processing, operational behavior and the information content. The model provides a base for software design and the creation of specifications for the software.

3.2 Requirement Specification:

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 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 Non-Functional (or supplementary) Requirements. Non-Functional Requirements are requirements which 10

impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).

Functional Requirements:In software engineering, a functional requirement defines a function of a software-system or component. A function is described as a set of inputs, the behavior and outputs. Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that show how a use case to be fulfilled.

Typically, a requirements analyst generates functional requirements after building use cases. However, this may have exceptions since software development is an iterative process and sometime certain requirements are conceived prior to the definition of the use cases. Both artifacts (use cases documents and requirements documents) complement each other in a bidirectional process.

A typical functional requirement will contain a unique name and number, a brief summary, and a rationale. This information is used to help the reader understand why the requirement is needed, and to track the requirement through the development of the system. The core of the requirement is the description of the required behavior, which must be a clear and readable description of the required behavior. This behavior may come from organizational or business rules, or it may be discovered through elicitation sessions with users, stakeholders and other experts within the organization. Software requirements must be clear, correct, unambiguous, specific and verifiable.

11

Detailed Description of Functional Requirements:Template for describing functional requirements.

Purpose Inputs

a description of the functional requirement and its reason(s) what are the inputs; in what form will they arrive; from what sources can the inputs come; what are the legal domains of each input

Processing

Describes the outcome rather than the implementation; includes any validity checks on the data, exact timing of each operation (if needed), how to handle unexpected or abnormal situations

Outputs

The form, shape, destination and volume of output; output timing; range of parameters in the output; unit measure of the output; process by which the output is stored or destroyed; process for handling error message produced as output

Non Functional Requirements:In systems engineering and requirements engineering, non-functional requirements are requirements which specify criteria that can be used to judge the operation of the system, rather than specific behaviors. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are constraints, quality attributes, quality goals and quality of service requirements. Qualities, i.e. non-functional requirements can be divided into 2 main categories:

1. Execution qualities, such as security and usability, are observable at runtime. 2. Evolution qualities, such as extensibility and scalability, embody in the static structure of the software system. 12

The nonfunctional requirements in our project are:

Time :The project should be completed within the stipulated time period.

Cost :The cost involved in making the project should be less.

Usability :This requirement is present, as this system will interact with user.

Reliability :This system must be highly robust.

13

Use Case Diagram :-

ADD RECORD

SEARCH RECORD

VIEW ALL

EXIT

14

3.3.2 Use case Description User

Here user is the second actor in this use case model. His Use Cases are

Search:-User can search any details from the phone book with person name. Add data:-Here user can add the details. View all:-Here user can view all the saved data.

15

CHAPTER 4

DESIGN

16

CHAPTER 4 DESIGN
4.1 System Flow Diagram
A System Flow Diagram (SFD) shows the relationships between the major components in the system. It is a systematic representation of an algorithm or a process. The steps in a process are shown with symbolic shapes, and the flow of the process is indicated with arrows connecting the symbols.

In order to improve a process, it is first necessary to understand its operation in detail. Describing this in text lacks the clarity of a pictorial diagram, where individual steps are more easily seen. The flowchart is a simple mapping tool that shows the sequence of actions within a process, in a form that is easy to read and communicate. The mapping of what follows what is shown with arrows between sequential action boxes, as in the illustration. This also shows the boxes for process start and end points of which there are normally one each.

Processes become more complex when decisions must be made on which, out of an alternative set of actions, must be taken. The decision is shown in a flowchart as a diamond shaped box containing a simple question to which the answer is yes or no.

17

Here are 6 steps which can be used as a guide for completing flow diagrams:

1. Describe the process to be charted and to give a chart the title.

2. Start with a trigger event i.e. begin to draw diagram by first describing the event which initiates the process.

3. Note each successive action concisely and clearly.

4. Go with the main flow i.e. when we reach a point at which the flowchart branches into a number of alternatives, and the resulting complexity threatens to overwhelm the exercise, choose the most important alternative to continue flowcharting with.

5. Make cross references to supporting information.

6. Follow the process through to a useful conclusion (end at a target point).

18

4.2 MODULES IDENTIFIED:

4.2.1 User Module

Search:-User can search any details from the phone book with person name. Add data:-Here user can add the details. View all:-Here user can view all the saved data.

4.2.2 Search Module:

In this module the user can search the contact details related to the name.He can also search the residential address , phone number etc.

19

CHAPTER 5

IMPLEMENTATION

20

CHAPTER 5 IMPLEMENTATION

5.1.1 Hardware Platform:

Processor : 166 MHz or above RAM : 64 MB Hard Disk Space : 20 GB Monitor: VGA or higher resolution, 800*600 resolution with 16 bit color Keyboard : Standard Keyboard Mouse : Standard Mouse

5.1.2 Software Platform:

Operating System: WindowsXP or above Front End: C++ Back End: FILE HANDLING

21

5.2 SOURCE CODE:

// ELECTRONIC DIRECTORY
/*

Instruction to Use:

* Please Wait Until the Phone Book load * Don't press any key until phone book loads * Use the arrow keys to navigate up and down{Select}. * Press 'Enter' key to proceed * To add new contact to the phone book Select "Add New" * To view all the existing contacts select "View" * To search a particular detail Select "Search" and enter a name to search * To quit select "Exit" * All the best!!!!!!!!!!! */

#include<iostream.h> #include<conio.h> #include<dos.h> #include<time.h> #include<graphics.h> #include<string.h> #include<stdio.h> #include<stdlib.h> #include<fstream.h>

void add(); 22

void view(); void search(); void print(char *str); void welcome(); int posn=1; int i=1;

void main() { welcome(); textbackground(GREEN); textbackground(GREEN); clrscr(); textcolor(WHITE); char ch; go: clrscr(); cout<<"\n\t\t\t\t\t\t Date : "; struct date dt; getdate(&dt); cout<<int(dt.da_day)<<'-' <<int(dt.da_mon)<<'-' <<dt.da_year; cout<<"\n\t\t\t\t\t\t ---";

cout<<"\n\t\t\t\t\t\t Time : "; struct time t; gettime(&t); cout<<int(t.ti_hour)<<':'<<int(t.ti_min); cout<<"\n\t\t\t\t\t\t ---"; ELECTRONIC

cout<<"\n\n\t\t\t=======================\n\t\t\t DIRECTORY\n\t\t\t=======================\n\n\n\n"; 23

if(posn==1) print(" Add Record"); else cprintf(" Add Record"); puts(""); if(posn==2) print(" View Record"); else cprintf(" View Record"); puts(""); if(posn==3) print(" Search Record"); else printf(" Search Record"); puts(""); if(posn==4) print(" Exit"); else cprintf(" Exit"); puts("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"); puts("\n\n\n\n\n\n\n\n Press 'Up' & 'Down' arrow keys to Navigate"); puts("\n Press Enter if 'Ok'"); do{ ch=getch(); if(ch==0) { ch=getch(); if(ch==72 && posn>1) { posn--; goto go; 24

} else if(ch==72 && posn==1) { posn=4; goto go; } else if(ch==80 && posn<4) { posn++; goto go; } else if(ch==80 && posn==4) { posn=1; goto go; } } }while(ch!=13);

switch(posn) { case 1: add(); goto go; case 2: view(); goto go; case 3: search(); goto go; case 4: 25

textcolor(0 +BLINK); gotoxy(15,25); cprintf("Do you wish to exit(Y/N)?"); ch=getch(); if(ch=='y' ||ch=='Y') exit(0); else { main(); } default: cout<<"\nInvalid choice\n\n"; goto go; } }

void add() { char *name,*addr,*ph,ch; clrscr(); ofstream out("ph.dat",ios::app); cout<<"\t\t\tELECTRONIC DIRECTORY\n"; cout<<"\t\t\t================\n\n"; cout<<"\n\n\nName\t\t:\n\n"; cout<<"PhoneNo.\t:\n\n"; cout<<"Address\t\t:\n\n"; gotoxy(20,7); gets(name); name=strupr(name); gotoxy(20,9); gets(ph); 26

gotoxy(20,11); gets(addr); addr=strupr(addr); if(name[0]=='\0' || ph[0]=='\0' || addr[0]=='\0') { clrscr(); cout<<"All the fields have to be filled completely"; getch(); out.close(); return; } out<<'\n'<<name<<'#'<<ph<<'#'<<addr<<'#'; out.close(); cout<<"\n\n\nDo you want to continue(Y/N):"; ch=getch(); if(ch=='n' || ch=='N') exit(0); else main(); }

void print(char *str) { textcolor(RED); cprintf("%s",str); textcolor(WHITE); }

void view() { 27

clrscr(); char name[30],ph[15],addr[100],ch; FILE *fp; int x=1,y=10; fp=fopen("ph.dat","r"); cout<<"\n\n------------------------------------------------------------------------------"; cout<<"\n| Name\t\t| Phone Number\t| Residential Address |\n";

cout<<"------------------------------------------------------------------------------\n\n"; for(int i=4;i<50;i++) { gotoxy(x,i); printf("|"); gotoxy(x+24,i); printf("|"); gotoxy(x+48,i); printf("|"); gotoxy(x+77,i); printf("|"); }

x=2,y=5; while(1) { ch=fgetc(fp); if(ch=='#') { if(x>2 && x<25) x=27; else if(x>27 && x<60) x=51; continue; 28

} else if(x>77) { x=50; y++; } else if(ch==EOF) { fclose(fp); break; } else if(ch=='\n') { cout<<"\n------------------------------------------------------------------------------\n"; y+=2; x=2; } gotoxy(x++,y); cout<<ch; } getch(); }

int p=0;

void search() { FILE *fp; char ch,ch1,*s; int i=0,l=0,f=0; clrscr(); 29

fp=fopen("ph.dat","r"); cout<<"\nEnter the name to search\t:"; cin>>s; s=strupr(s); clrscr(); cout<<"\n\n------------------------------------------------------------------------------"; cout<<"\n| Name\t\t| Phone Number\t| Residential Address |\n";

cout<<"------------------------------------------------------------------------------\n\n"; l=strlen(s); ch=fgetc(fp); int x=2,y=7; while(1) { for(i=0;i<l;i++) { ch=fgetc(fp); if(ch==EOF) { fclose(fp); cout<<"\n\nSearch completed"; getch(); main(); } if(s[i]==ch) continue; else { while(ch!='\n') { ch=fgetc(fp); if(ch==EOF) 30

{ fclose(fp); textcolor(BLUE); puts(" "); cprintf("Search completed"); textcolor(WHITE); if(f==0) { textcolor(MAGENTA +BLINK); cout<<"\n\n\n"; cprintf("No Records found"); textcolor(WHITE); } getch(); return; } } break; } } x=2; if(i==l) { f=1; y+=2; gotoxy(x,y); cout<<s; x+=l; while(ch!='\n') { ch=fgetc(fp); 31

if(ch=='#') { if(x<25) x=27; else if(x>25 && x<49) x=52; continue; } if(ch==EOF) { fclose(fp); textcolor(BLUE+BLINK); puts(" "); cprintf("Search completed"); textcolor(WHITE); getch(); return; } gotoxy(x++,y); if(x>72) x=52,y=y+1; cout<<ch; } } } } void welcome() { delay(50); window(1,1,80,80); textbackground(WHITE); 32

textcolor(RED); clrscr(); gotoxy(25,12); cprintf(" ELECTRONIC DIRECTORY"); gotoxy(25,13); cprintf(" ~~~~~~~~~~~~~~~~~~~~"); gotoxy(40,25); cprintf("Designed by"); gotoxy(40,26); cprintf("-----------"); gotoxy(32,31); textcolor(0); cprintf("SYSITS"); gotoxy(38,32); cprintf("RATLAM"); delay(500); gotoxy(39,28); textcolor(GREEN + BLINK); cprintf("VANITA ZANJE,NITESH JAIN, NAKUL PANDEY"); printf("\n\n\n\n\n\n\n\n\n\n\n Loading Please Wait"); delay(500); delay(700); printf("."); delay(500); printf("."); delay(500); printf(".."); delay(750); printf("..."); delay(750); } 33

4.3 SNAP SHOTS:

HOME

34

SELECTION WINDOW

35

SEARCH RECORD

36

VIEW ALL RECORDS

37

CHAPTER 6

TESTING

38

CHAPTER 6 TESTING

Software testing is a critical phase of software quality assurance. It indicates the ultimate review of specification, design and code generation. Once source code has been generated, software must be tested to uncover and correct maximum possible errors, before being delivered. Testing emphasizes on a set of methods for the creation of test cases that fulfill overall testing objectives.

The primary objectives of software testing are as follows: 1. Testing is a process of executing a program to find an error in it. 2. A good test case should have a high probability of finding an as-yet-undiscovered error. 3. A test case will be considered successful if it uncovers an as-yet-undiscovered error.

i. TESTING TECHNIQUE

i) UNIT TESTING:-

Unit testing aims the verification effort on the smallest unit of software design i.e., a software component or module. It uses procedural design as a guide to test major control paths and uncover errors within the module boundary. It is white box oriented and the step can be conducted in parallel for multiple components. Unit testing is a dynamic method for verification, where the program is actually compiled and executed. It is one of the most widely used methods, and the coding phase is sometimes called coding and unit testing phase. The goal of unit testing is to test modules or units, not the whole software system. Unit testing is most often done by the programmer himself/herself. The goal of unit testing is to isolate each part of the program 39

and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits.

ii) INTEGRATION TESTING:

Integration testing is a phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing. The major objective of integration testing is to tackle the problem of interfacing i.e. putting all the acceptable imprecision (view) may be magnified to unacceptable levels; global data structure can cause problems and to truncate this list of problems we use integration testing.

Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure that has been dictated by the design.

Integration testing strategy used is Bottom-Up Integration Testing. In it all the bottom or low level modules, procedures or functions are integrated and then tested. After the integration testing of lower level integrated modules, the next level of modules will be formed and can be used for integration testing. This approach is helpful only when all or most of the modules of the same development level are ready. This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage.

iii) VALIDATION TESTING:

At the climax of integration testing, software is developed as a package having all the errors uncovered and corrected. At this time, a final series of software test may begin. It is called validation testing. Validation succeeds when software functions in a reasonably 40

expectable manner. Validation attempts to uncover errors, but the emphasis is on the requirement level i.e. the things that will be immediately apparent to the customer.

A major element of the validation process is a configuration review, which is conducted to ensure that all software configuration elements have been well developed, wellcataloged, and have the essential detail to bolster the support phase of the software life cycle.

41

CHAPTER 7

CONCLUSION

42

CHAPTER 7 CONCLUSION

7.1 ADVANTAGES: Unlimited number of contacts in the phonebook is stored no doesnt matter how many time it is viewed it remains same. Tools to search contacts stored in memory. Easy-to-use tools to create new contacts.. Easy to view records .

7.2 DISADVANTAGES:
Each and every system has a disadvantage. This application also has some disadvantages. The contact details are available only in English Language.

43

CONCLUSION
Electronic Phone Directory becomes the most useful type of source of

information that people can find when they want to get in touch with any type of person. So there are many things that have changed a lot, but in this way they have improved and they have become much easier to be used by people. All the improvements that have been brought by technology are to our advantage and people are able to use them for their own good and for all the things that they need. The things that we can do are extremely different and technology can help us resolve various tasks without many efforts because we have all the needed means. A Electronic Phone Book is a collection of documents in organized electronic form, which was feed by the users. Depending on the specific Electronic Phone Directory, a user may be able to access name, phone number/contact number, residential address, office address.

References:
Er. Govind Jhawar www.google.com www.wikipedia.com

44