Embed Size (px)
Citation preview
LIST OF CONTENTS
1. Introduction 2
1.1 Current system 3
1.2 Need for the New system 3
1.3 Detailed Problem Definition 4
2. System Development life Cycle 5
3. Analysis 8
3.1 Requirement Analysis 9
3.2 Use-case Analysis 14
3.2.1 Use-case Diagram 14
3.2.2 Use-case Description 15
4. Design 16
4.1 System Flow Diagram 18
5. Implementation 20
5.1 Hardware Specification 21
5.2 Source code 22
5.3 Snap shots 34
6. Testing 38
6.1 Test cases and Test Results 39
7. Conclusion and suggestions for further work 42
1
CHAPTER 1CHAPTER 1
INTRODUCTIONINTRODUCTION
2
CHAPTER1INTRODUCTION
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.
4
CHAPTER 2CHAPTER 2
SYSTEMSYSTEM DEVELOPMENT LIFEDEVELOPMENT LIFE
CYCLECYCLE
5
CHAPTER 2SYSTEM 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 system’s 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.
6
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 system’s services as new
requirements are discovered.
Linear Sequential Model for Software Engineering
7
CHAPTER 3CHAPTER 3
ANALYSISANALYSIS
8
CHAPTER 3ANALYSIS
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 system’s 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 software’s operational characteristics i.e. function, data and
behavior, indicates software’s 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 a description of the functional requirement and its reason(s)
Inputs 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 :-
14
ADD RECORD
SEARCH RECORD
VIEW ALL
EXIT
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 4CHAPTER 4
DESIGNDESIGN
16
CHAPTER 4DESIGN
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 5CHAPTER 5
IMPLEMENTATIONIMPLEMENTATION
20
CHAPTER 5IMPLEMENTATION
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 ---- ";
cout<<"\n\n\t\t\t=======================\n\t\t\t ELECTRONIC 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 6CHAPTER 6
TESTINGTESTING
38
CHAPTER 6TESTING
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, well-
cataloged, and have the essential detail to bolster the support phase of the software life
cycle.
41
CHAPTER 7CHAPTER 7
CONCLUSIONCONCLUSION
42
CHAPTER 7CONCLUSION
7.1 ADVANTAGES:-
• Unlimited number of contacts in the phonebook is stored no doesn’t 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
