2. PRESENTATION BY
B.Siva Rushi

3. Introduction:

4. Back ground Work:
• The software to be designed is a program that can
be used to maintain an address book.
• An address book holds a collection of entries, each
recording a person's first and last
names, address, city, state, zip, and phone number.
• The most important entries to add to a new entry
are the Name and zip code
• The name entry shows up as a "friendly" name, but
there are lots of spaces to fill in(like home
address, working address, home & work phone & fax
numbers etc…)
• The address book actually has 3 special components;
Sort by name & sort by zip and autosave.

5. Requirements
• User Requirements:
• It must be possible to add a new person to an
address book, to edit existing information
about a person , to delete a person.
• It must be possible to sort the entries in the
address book alphabetically by last name (with
ties broken by first name if necessary), or by
ZIP code (with ties broken by name if
necessary).
• It must be possible to print out all the
entries in the address book in "mailing label"
format.

6. Functional Requirements:
• If the user chooses the New or Open menu option, any
current address book will be closed before
creating/opening a new one.
• In this case, New and Open will result in creating a new
window, without affecting the current window.
• The program will keep track of whether any changes have
been made to an address book since it was last saved, and
will offer the user the opportunity to save changes when
an address book is closed either explicitly or as a result
of choosing to create/open another or to quit the
program.
• The program will provide the features like sort by name
or zip
• Colorful appearance to make the user satisfactory and
system is fast without any delay.

7. Non-Functional Requirements:
• Security for confidential details.
• Proper design of the system and
its architecture.
• Accessing to the system is very
fast.
• Good performance and efficiency.

8. System Requirements:
• The main functionality of the
software is generating the details
of a particular person by sorting in
the order of name or by zip.
• Updating the software when ever a
new changes occur

9. Domain Requirements:
• Even a person who don't have much idea
about how to use the software should
also be able to use it very easily.
• There shall not be any new user who
will see the private and protected
contents without the permission of the
administrator.
• There shall be an interface which shall
provide the information in proper, simple
and in readable format.

10. Critical System Specification
• Its objective is to understand the
risks faced by the system and
generate dependability
requirements to cope with them.
• The major risks in the system was
may be the software works slowly
i.e. takes lots of time to perform
the operations, stored data may
loss, etc..

11. Risk identification:
• The possible risks in a address book system can be:
• There can be overlapping of similar names & Zip
code.
• The person may not be available in particular
address.
• There should not be more details about the person.
• The system may be stopped working in middle.
• The system cannot be store more details than the
available once
• The address book memory size may be lower.
• Address or the details may be wrong.

12. RISK ANALYSIS AND
CLASSIFICATION
• We need to make this analysis to
understand whether a risk is a serious
threat to the system or environmental
and to provide a basis for deciding the
resources that should be used to
manage the risk
• The above risks can be categorized
as…
.
Risks

13. RISK DECOMPOSITION:
• Risk decomposition is the process of identifying the
root causes of risks in a particular system. Risk
analysis can be deductive or inductive.
RISK REDUCTION MANAGEMENT:
• There are three possible strategies that we can use
here are
• 1)Risk avoidance :The system is designed so that the
risk or hazard cannot arise.
• 2)Risk detection and removal: The system is
designed so that if risks arise and are detected they
should be neutralized before they result in an
accident.
• 3)Damage limitation: The system is designed so that
the consequences of an accident are minimized.

14. Safety Specification:
• The safety critical system is
designed and implemented such that
there cannot be any accidents due
to system hardware failure.
• Safety must also be managed during
the operation and the maintenance
of the system.

15. Security specification:
• Security analysis is based around
the assets to be protected and the
value it offers to an organization. A
possible security specification
process has three basic processes.
They are:

16. Asset Identification:
• Here the asset can be a person data
which is limited to his/her usage.
• This should be encrypted in order to
prevent them from malicious programs and
database has to hidden.
Threat analysis and risk assessment:
• As mentioned above these possible threats
has to be eliminated by possible means the
address book user have to be encrypted
using encryption techniques and the
algorithm should be kept hidden, database
has to hidden.

17. Threat assignment:
• For an identified threat there
should be an associated asset (here
assets include the
data/algorithm/user).
Technology analysis:
• The available techniques of the
modern technology has to be used.
Some of them are powerful anti-
virus to protect the system from
spyware and malware.

18. Reliability:
Hardware reliability: We need to check the
level of hardware failure in a system. In this
system the probability of hardware failure is
more compared to other systems but it should
not be neglected.
Software reliability:
Software failures are different from hardware
failures in that software does not wear out. It
can continue operating correctly after producing
the incorrect result. In this system there can be
failure in the system due to data errors, same
names for persons, same pins can be assigned to
the people , linking of the database with the
system etc….

19. • Operator reliability:
• Admin unknowingly might make
errors.
• The User/person might unknowingly
give wrong inputs.

20. Software Process Model:
• Software Process Model is an abstract
representation of a software process.
Each process model represents a
process from a particular
perspective, and thus provides only
partial information about that process.
• The model used in this project is

21. Why this model..??
• We used this model for our model
because we need reusability of code
• As we use the address book so many
times the code should be able to run
it as many of times .. So we chooses
this model..

22. • the three important parts of component
based software engineering are:
1)Component analysis:
• It takes into consideration the basic
components required by any system for
proper functionality and data flow.
• The components that can be taken into
consideration in this system are
• Actors- The actors in our system is the
user.
Database- which includes the list of persons
, the we going to sort the entries such as by
name or by zip.

23. 2) Requirements modification:
• As stated the basic requirement of this
system is the database which holds the
address details of the people details along
with the name and zip.
3) System design with reuse:
• Here the concept of reusability is best
utilized. The existing framework .
• Here the code used for interface design
is reused along with the data linkage
that is the data linked to the people can be
edited any number of times and any
number of new users can be edited and
deleted.

24. System testing:
Software testing process has 2goals
• 1.To demonstrate to the developer and
the customer that the software meets
its requirements .
• 2.To discover faults and defects in
the system where the behavior of the
software is incorrect, undesirable or
does not conform to its specification.

25. Software Testing:
• A)Component Testing:
• 1) Test whether the software can hold high amount
of data in its database.
• 2) Test the reaction time taken for a address to be
stored.
• 3) Test the individual Software and Hardware
components of the working system.
• 4) Testing all operations associated with an object
• 5) Setting and interrogating all object attributes
• 6) Composite components with defined interfaces
used to access their functionality.
•

26. B) System Testing:
• 1) Test the login mechanism to check that only
administrator can use when it is locked, else every
one can access it when unlocked.
• 2) Test the search facility using different queries
against known sources to check that the search
mechanism is actually finding the required data
relevant to the user input.
• 3) Test the mechanism to request permission for
sharing and receiving data and business cards from
other.
• 4) Test whether the data stored on a particular
name is stored properly and can retrieve back when
needed.
• 5) Test that whether it can be updated when ever a
new changes takes place.

27. • Performance testing:
• Test the Performance of the
System because performance is the
only thing which most people will
expect from any software more
than the look and feel.
• Performance tests usually involve
planning a series of tests where the
load is steadily increased until the
system performance becomes
unacceptable.

28. System Design and
Architecture:
• The system is designed based on the architectural
and system characteristics:
• 1)It’s designed such that it will produce better
performance.
• 2)Offers better security through RSA-Encryption
technique.
• 3)It’s is a safety system no loss of life etc…..
• 4)Ease of maintenance through time to time updates
of the system.

29. • The Architectural model used is the Repository
model
• The repository model Sub-systems must exchange
data.
• This may be done in two ways: Shared data is held in
a central database or repository and may be
accessed by all subsystems;
• Each sub-system maintains its own database and
passes data explicitly to other sub-systems.
• When large amounts of data are to be shared, the
repository model of sharing is most commonly used.

30. Verification &Validation:
• Verification and validation are not
the same thing.
They can be termed as
• Verification : “Are we building the
right product?”
• Validation : “Are we building the
product right?”

31. Verification :
• Verify that the new,open,save,delete and other
functions of the software is working properly.
• Verify does the software reaches specifications .
• Only the stored data members of system can edit or
Delete the above mentioned several topics so, this
should be verified.
• Verification involves checking that the software
confirms to its specifications.
• We should check that the software meets its
specified functional and non functional
requirements.
• Here our project on address book meets all its
specified functional and non functional requirements

32. Validation :
• The aim of validation is to ensure that the
software system meets the customer’s
expectations.
• It mainly reflects that did the software
actually satisfies the user.
•
• The ultimate goal of the verification and
validation process is to establish confidence
that the software system is “fit for purpose”.
• This means that the software is good enough
for the intended use.
•

33. Conclusion
• Thus the simple address book
system developed provides the user
a basic address book which is used
to store the details of the persons.
• The special functions or operations
in it are auto save,sorting.