K.J.

SOMAIYA COLLEGE OF ENGINEERING

VIDYAVIHAR , MUMBAI – 400 077

Department of Computer Engineering

Subject : Object Oriented Software Engineering

Term: odd(2010-2011) Class / Sem : T.E Comp / VI

List of Experiments

Exp TitleSr
of no.
the Title of the Experiment

1 Requirement Analysis for Mini Project.

2 Feasibility Analysis for Mini project.

Requirement and Design Modeling.

 Use case Diagram

 Activity Diagram
3
 Sequence Diagram

 Collaboration Diagram

 State chart Diagram

 Class Diagram
4 Design Document for Mini Project.

5 Project Plan Document for Mini project.

6 Testing plan for Mini Project.

Deployment Document for Mini Project.

7
 Component Diagram

 Deployment Diagram

Experiment No :1

Aim: To Prepare Requirement Specification Document

Document:
Introduction

1.1 Purpose
READER’S HUT is a library, which provides reading services to its members. This library provides
following facilities to the readers:
 Granting and renewal of membership.
 Issue and return of books.
 Purchase and Updation of books.

While providing the above facilities, the following drawbacks are encountered:
 Issuing more than 1 book to a member
 Issuing a book to a member whose membership has expired.
 Physically searching for required book.
 Time consuming process.

An online system is to be designed which would overcome drawbacks.

1.2 Scope

The online system to be designed should perform following major functions:

 Acquisition of books.
 Membership maintenance.
 Book issue.
 Book return.
 Renewal of membership.
 Answer management queries.

1.3 Definition and acronyms

TCP/IP: Protocols used for connection.

Module: A part of the system which performs a definite task.
Server: A part of the client server model. Has higher processing capacity and services
requests made by client
Client: A part of the client server model. Requests services from the server.

1.4 References http://www.howstuffworks.com/tcp-

ipconnections/1.html

5. Overall Description

2.2 Product Perspective

The library management system allows the librarian to perform the tasks of issuing, returning books,
and other tasks related to membership maintenance with an easy to use interface.

2.1.1. System Interfaces

The system consists of four modules namely, admin module, client module, server module and the
database module.
The server module is a server that accepts connection from the admin module and the client module
and interfaces them both with the database.
2.1.2. User Interfaces
The Admin module and the client module must provide a user interface to the user. The server module
and the database do not have a user interface.

2.1.3. Hardware Interfaces

All components must be able to execute on a personal computer.

2.1.4. Software Interfaces

The admin module and the client module must be java applets running within internet explorer 5(or
higher) or Firefox.
The server module must integrate with the DBMS using JDBC. The web server must run within a
server available for Windows NT.

2.1.5. Communication Interfaces

The admin module and the client module must communicate with the server module using TCP/IP
connections.
The server and the database components must be located on the same host.

2.1.6. Memory constraints

The admin module and the client module must be able to run within 64MB. The server module must be
able to run along with the database within 256 MB.

2.1.7. Operations
The operations of the client module and the admin module must be easy and intuitive to the users. No
specific knowledge must be required to operate the same. The server module must be installed and
maintained with no interaction with the existing software on the machine.
Back up operations must be defined.
Recovery operations must be specified in terms of user machine failures or database failures.
2.1.8. Site adaptation requirements

2.1.8.1 Website requirement

For online reservation of books, application for membership, renewal of membership etc a website
will be required. This website requires purchase of web space.

2.2 Product functions

The main functions of the library management system are to allow for membership maintenance,
acquisition of books, issuing and returning of books and generating reports.

A member has a unique identification number called the membership number. Membership has an
associated expiry date, which is used for notification to users and to the librarian. It also
maintains the amount of fine that is collected in the membership period.

The acquisition of books requires assignment of a unique acquisition number for each acquired
book and other details such as price, author name etc, which are used for report generation
purposes.

The issuing of book requires the verification of membership details and books are issued if the
member has a valid membership and has not already issued a book which is not returned yet.

While returning a book, the due date of the book is checked and if necessary fine calculations are
done and the database us updated accordingly.

Various reports generated are:

 List of overdue books.
 List of memberships expiring in the current month.
 List of books present in the library.
 List of members.

2.3 User characteristics

The users are untrained or have basic knowledge of computer functionalities. The
users do not have knowledge of software engineering and do not understand the underlying
functions of the system.

2.4 Constraints
The system should enforce authentication and guarantee validity and integrity of the database.

2.5 Assumptions and dependencies

No specific assumptions or dependencies.

6. Specific Requirement
3.6 External interface requirement

3.1.1 User Interface

Login screen: The login screen consists of user id and password fields and submit and cancel
buttons.

Acquisition entry screen: This screen consists of fields like book name, author, price, acquisition
number, publisher name, number of pages, date of publish, date of purchase and book status.

Application form: The form consists of Name, address, membership fee and caution money.

Admin screen: The admin screen consists of fields to update or add new data to the database. It
consists of fields for updating book status, membership details, generating invoices and report
generation.

3.7 Software product features

3.2.1 Membership management

Validity check is performed whenever a membership application is received.
The librarian can modify the details of membership like the amount of fine collected etc.
Any errors occurring are reported.

3.2.2 Book management

For acquisition of books as well as issue and return of books, validity check is performed.
Members are allowed to reserve a book for issue. The librarian has to update the book status when
it is returned by the member.
Any errors occurring are reported.

3.2.3 Staff accounts management

The staff accounts consist of staff details and their respective login details. These details are used
while login of staff members. These details can be updated by the librarian.
Any errors occurring are reported.

3.2.4 Invoice generation management

While generating invoices validity checks are performed to verify the quantity and name of books to
be bought.
The librarian has to handle the generation of invoices. Any errors
occurring are reported.

3.2.5 Report generation

3.2.5.1 Overdue Books

It consists of following format:
S.No. ACCE TITLE PRICE PUBLI MEMB MEMB MEMB BOOK PROP
SSION OF OF SHER ERSHI ER ER ISSUE OSED
NUMB BOOK BOOK NAME P NAME ADDR D ON DATE
ER NUMB ESS OF
ER RETU
RN

3.2.5.2 Memberships expiring in the current month

It consists of following format:
S.No. MEMBERSHIP NAME ADDRESS MEMBERSHIP MEMBERSHIP
NO. BEGINNING EXPIRE DATE
DATE

3.2.5.3 List of books present in the library

It consists of following format:

S.No. ACQ ACCE BOO AUTH AUTH PUBL PRIC NO. DATE DATE
UISITI SSIO K OR-I OR-II ISHE E OF OF OF
ON N TITLE NAM NAM R PAGE PUBL PURC
NUM NUM E E NAM S ISH HASE
BER BER E

3.2.5.4 List of members

It consists of following format:
S.No. MEMBE NAME ADDRE DATE DATE MEMBE CAUTIO CUMUL
RSHIP SS OF OF RSHIP N ATIVE
NO. MEMBE MEMBE FEE MONEY FINE
RSHIP RSHIP COLLE
BEGINS EXPIRY CTED
3.8 Performance requirement
Our system will be scalable enough to handle the concurrent users accessing through web. We will be
maintaining the resource pools in our system for e.g. connection pools, object pools to achieve
scalability. However the response time to various users will vary depending upon the kind and
amount of information retrieved.

3.9 Software system attributes

Maintainability: The system is to be developed using modular approach, hence it any errors in a
particular module can be easily identified and corrected without any effect on other modules.

Portability: The system is to be developed using java (platform independent tools), hence the system
will be portable.

Recoverability: Recovery steps have to be defined in case of system or database failures. For
database log based recovery is used.

Security: The system provides password based security.

3.10 Logical database requirements

The database is required to store all the information about the books in the library, as
well as details about all the members of the library. The database also stores the details of the staff in
the library. It is also required to store the login details of the members as well as the staff of the
library.

3.11 Other requirements

No other specific requirements.

Roll no Signature of Faculty with date

 Experiment No :2

Aim : To Perform Feasibility Analysis .

Theory:

Feasibility Analysis:

No project should be undertaken without detailed cost estimates and scope controls.  Even if
a project is already underway, feasibility analysis can determine likely outcomes well ahead
of time.  The following is a brief outline of the feasibility process.

Constraints:

There are four constraints to project success:

1. Cost :The cost incurred in developing this project include the cost of software
developers,the system (computers required) and the softwares required.

2. Quality :The developers working on the project are highly skilled .

3. Time :The time taken for the project development is 6 months.

4. Scope: The online system to be designed should perform following major functions:

 Acquisition of books.
 Membership maintenance.
 Book issue.
 Book return.
 Renewal of membership.
 Answer management queries.

Cost-Effectiveness:

Cost-effectiveness analysis can include the following:

 Estimated direct costs:The direct cost includes cost of the softwares required and software
developers.
 Indirect costs: The indirect cost includes training provided to the end user.

Risk Analysis:

Project success depends on meeting the following requirements:

 The software developers working on this project are highly skilled and have good
experience on current platform being used.
 The project is developed using agile project management methodology.
 Strong project management procedures
 Contingency plans are developed in case of system failure .

Complexity Analysis:

The complexity of the task assigned to the developers depends upon the experience and job
knowledge of developer.

Requirements Definition :

A Requirements Definition gives the rationale, goals and description of a system. It is both a
roadmap for the project and criteria for assessing completion. Thus the following task are
performed during the project development :

 Assess existing operations: Review systems, interview users, discuss options with
management.
 Review constraints: budget, time, personnel and technical.
 Evaluate strengths and enabling conditions.


Project Success :

Software projects are inherently risky.  Ethical approaches combined with good management
mitigates those risks.

 System requirements are discussed with the customer time to time.

 The projects is feasible for given budget, time, personnel and technical constraints.
 The projects include all the factors critical for success: the right goals, the right staff, the
right vendors, the right work breakdown, the right budget and the right schedule.
Conclusion:Thus, feasibility analysis is performrd for the project .

Roll no Signature of Faculty with date

 Experiment No :3

Aim : To Model the requirements using UWE approach.

Theory:

Requirement Modeling:

It is displayed using USE case diagram and activity Diagram.

Use cases

It represents the functions of a system from the users point of view.

Use Case Diagram :

Use Case for Administrator:

Use Case for Librarian:

Use Case for member:

Use Case for clerk:

Use Case for helper:
Acivity Diagram
In its basic form, an activity diagram is a simple and intuitive illustration of what happens in a
workflow, what activities can be done in parallel, and whether there are alternative paths
through the workflow. Activity diagrams as defined in the Unified Modeling Language are
derived from various techniques to visually illustrate workflows. Activity diagrams are used
to visualize the workflow of a business use case. A complete workflow description will have
a basic flow, and one or several alternative flows. This workflow has a structure that we can
define textually, using informal if, if-then-else, or does-until statements of various kinds. For
a simple workflow with a simple structure such textual definitions may be quite sufficient,
but in the case of more complex structures, activity diagrams help to clarify and make more
apparent what the workflow is. Historically, activity diagramming techniques have mostly
been used in the business process modeling domain, but this article will also briefly discuss
how you can use it in the system modeling domain.

Basic Activity Diagram Notation:

As common for most notations, the activity diagram notation has some elements that are
necessary for you to understand if you want to be “conversant” about activity diagrams. A
basic activity diagram can have the following element:

 Activity states, which represent the performance of a step within the workflow.
 Transitions that show what activity state follows after another. This type of transition is
sometimes referred to as a completion transition, since it differs from a transition in that it
does not require an explicit trigger event, it is triggered by the completion of the activity the
activity state represents.
 Decisions for which a set of guard conditions are defined. These guard conditions control
which transition of a set of alternative transitions that follows once the activity has been
completed. You may also use the decision icon to show where the threads merge again.
Decisions and guard conditions allow you to show alternative threads in the workflow of a
business use case.
Synchronozation Bars ,which you can use to show parallel subflows .Synchronization bars
allow you to show concurrent threads in the workflow of a business use case.
Activity Diagram:

Activity Diagram for librarian:

Activity Diagram for clerk:
Sequence Diagram:
UML defines two types of interaction Diagrams :the Sequence Diagram and the collaboration
diagram.
Sequence Diagram shows essentially the same information,but concentrates on the time-
ordered communication between objects rather than their relationships.The dashed vertical
lines represent the lifeline io the object.

Sequence Diagram :
Sequence Diagram for book return:

.
Sequence Diagram for Issue book :
Collabrotion Diagrams:
In collaboration diagrams,objects are drawn as rectangles and the lines between them
indicates links.
A link is an instance of an association.The order of the messages along the links
between the objects is indicated by the number at the head of the message.
Collabration Diagrams are spatial representation of objects,links,interactions.

Collabration Diagram:
Collabration Diagram:
Content Modeling:
Content modeling is done using Class Diagram and state diagram.

Class Diagram:

Class diagrams are the most popular UML diagrams used by the object oriented
community. It describes the objects in a system and their relationships. Class diagram
consists of attributes and functions.

A single class diagram describes a specific aspect of the system and the collection of
class diagrams represents the whole system. Basically the class diagram represents the
static view of a system.

Class diagrams are the only UML diagrams which can be mapped directly with object
oriented languages. So it is widely used by the developer community

Class Diagram :
Statechart diagram
Represents the behavior of a class in terms of states at run time.

Statechart diagram define different states of an object during its lifetime. And these states
are changed by events. So Statechart diagrams are useful to model reactive systems.
Reactive systems can be defined as a system that responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered.
So the most important purpose of Statechart diagram is to model life time of an object from
creation to termination.

State Diagram :

State Chart Diagram for book:

Roll no Signature of Faculty with date
 Experiment No :4

Aim : To Prepare Software Design Description Document

Document:

a. Purpose

READER’S HUT is a library, which provides reading services to its members. This library provides
following facilities to the readers:
 Granting and renewal of membership.
 Issue and return of books.
 Purchase and Updation of books.

While providing the above facilities, the following drawbacks are encountered:
 Issuing more than 1 book to a member
 Issuing a book to a member whose membership has expired.
 Physically searching for required book.
 Time consuming process.

An online system is to be designed which would overcome drawbacks.

b. Scope

The online system to be designed should perform following major functions:

 Acquisition of books.
 Membership maintenance.
 Book issue.
 Book return.
  Renewal of membership.
 Answer management queries.

c. Definitions and Acronyms

TCP/IP: Protocols used for connection.

Module: A part of the system which performs a definite task.

Server: A part of the client server model. Has higher processing capacity services

requests made by client

Client: A part of the client server model. Requests services from the server.

References
http://www.howstuffworks.com/tcp-ipconnections/1.html
9. Decomposition Description
a. Module Description
i. Admin Module Description

The admin module allows the user (Librarian) to make changes to the database. It allows him/her
the generation of various reports and invoices. It also allows him/her to manage membership
accounts.

ii. Client Module Description:

The client module allows the members to login and query the database for available books and for
membership details.
It allows for requesting of books.
It also provides interface for membership application and renewal.

iii. Server Module Description

The server module interfaces with the database and allows the admin and client module to query
information from the database.
All the database operations are performed by the Server module.
The client and admin module interface with the server module using TCP/IP connections.

b. Concurrent Process Description i.

Admin process description

Admin process starts whenever the Librarian logs in. This process then connects to the Server
process and maintains the connection till the librarian logs out. It passes the queries to the
server module over the connection.

ii. Client process description

The client process starts whenever any member logs in. This process then connects with the
Server Process and maintains the connection till the member logs out. Queries are passed by
this process to the Server process over the connection.

iii. Server process description

The Server process is always active, regardless of whether any user has logged in or not. This
process accepts connections from the admin and client process and replies with the result set
for the queries. It interfaces with the database using JDBC connections.

c. Data Description
i. Member

Member entity stores the information about the members of the Library. It is required for validating
member information while issuing books and it is updated every time books are issued, returned
or fine is to be calculated.

ii. Books

The Book entity stores the information of the books in the library. A new record is created
whenever new books are acquired. Book status is updated every time books are issued or
returned.

iii. Issuance

Issuance entity stores the records of books issued to members. These records are used for
calculating fine for delayed returns and to keep a track of books that are issued.

10. Dependency Description

a. Inter-Module Dependency

The Admin and Client modules require connecting to the Server module using TCP/IP connections
and all the transactions are made using these two modules.

b. Inter-Process Dependency

The Client and Admin processes send queries to the Server process. These queries are then
passed on to the Database management system by the Server process using the JDBC
connection.

c. Data Dependency

The Issuance records require member id from the member records and acquisition number from
the book records. These are necessary to maintain information for issuing books and for
calculating fines for members.
11. Interface Description
a. Module Interface
i. Admin Module Interface

The admin module interfaces with the server module using the TCP/IP connection. It also provides
a user interface for the librarian to manage member accounts as well as for managing the book
details.

ii. Client Module Interface

The client module interfaces with the server module using the TCP/IP connections. It also provides
 a user interface for the member to access membership details and also renew membership.
It also provides a user interface to unregistered members to apply for memberships.

iii. Server Module Interface

The server module interfaces to the client and admin modules through TCP/IP connections. It also
interfaces with the database using JDBC.
It does not provide a user interface.
It also provides a web server component.

b. Process Interface
i. Client Process Interface

The client process interfaces with the server process. The client process requires identification
information for connecting to the server process.

ii. Admin Process Interface:

The admin process interfaces with the server process. The client process requires identification
information for connecting to the server process. The admin process has higher priority over the
client process when it comes to connect to the server.

iii. Server Process Interface

The Server process interfaces with the client and admin process after validating the identification
information from the connecting process. The server process also interfaces with the database
using JDBC.

12. Detailed Design

a. Module Detailed Design
i. Admin Module Design

The admin module has following components:  Book

management
o Updation of book status.
o Adding of new books.
o Removal of older and damaged books.
 Membership management
o Fine calculation.
o Adding new member.
o Deleting expired membership records.
o Renewing membership
 Report generation
 Invoice generation ii. Client Module Design
The client module has the following components:
 Book search.
 Membership access.
 Book reservation.

iv. Server Module Design

The server module is designed to provide connectivity to the database. It has the following
components:
 Database interface
 Interface for connecting with the admin and client module. The server module is
required to remain active always.
The server module has also a web server component that handles the TCP/IP connections and
also provides server side validation.

c. Data Detailed Design

i. Members

Attribute name Type Size

3.1.1 Membership ID String 10
3.1.2 Name String 50
3.1.3 Address String 100
3.1.4 Registration date Date 10
3.1.5 Fee Float 10
3.1.6 Caution money Float 10
3.1.7 Membership expiry Date 10
date
3.1.8 Renewal amount Float 15
3.1.9 Password String 20

ii. Books

Attribute name Type Size

3.2.1 Acquisition No. String 10
3.2.2 Accession No. String 10
3.2.3 Title String 30
3.2.4 Author 1 String 25
3.2.5 Author 2 String 25
3.2.6 Publisher String 25
3.2.7 Price Float 15
3.2.8 No. Of Pages Integer 30
3.2.9 Date of publication Date 10
3.2.10 Date of purchase Date 10

iii. Issuance

Attribute name Type Size

3.3.1 Member ID String 10
3.3.2 Accession No. String 10
3.3.3 Date of Issue Date 10
3.3.4 Date of Return Date 10
3.3.5 Calculated Fine Float 15

Roll no Signature of Faculty with date

 Experiment No : 5

Aim: To Prepare Software Project Management Plan

1.1 Project overview:

The purpose of the software is to make the library systematic, easy to access and user
friendly.

1.2 Project deliverables:

1. SRS
2. Software project management plan
3. Software design document(data design, architectural design, interface design and procedural
design)
4. Software testing documents(test plan, test cases )
5. User manuals

2. Project Organization:

2.1 Software Process Model:

WATERFALL MODEL:

Planning Analysis Design

Implementation Testing Coding

2.2 Roles and Responsibilities:

In order to complete the project successfully, the various tasks are assigned amongst the group
members according to there ability. Each member should perform the given task efficiently. The
members should give proper design for the code, based on which the functions have to be
performed:

Following table shows the roles and responsibilities of the each member:

ROLES NAME RESPONSIBILITIES

Team Leader Kavita Kelkar  Design generation

 Requirement
gathering

Project Analyzer Prafull Bhosale  Analysis

 Evaluation of codes
Project Manager Yogesh Jadhav  Integration and
testing modules
Management of
database
Project Advisors Rahul Bansode  Coordinating
 Development of
user interface
module

2.3 Tools and Techniques:

System requirements:

Operating systems: Windows 9x/2000/xp

Hardware:
 RAM-256 MB or above
 Any Intel Processor of 1.0 GHz or above
 Barcode reader
 Hub

Front end: ASP.NET

Back end: MS SQL SERVER

3. Project management plan:

3.1 Tasks:

Sr. Task Description Deliverables Resources Dependencies Risks and

No. and Needed and Contingencies
Milestones Constraints
3.1.1 Interacting Get Prepare Developer Coding cannot Fixing of
with the requirement analysis manuals be started appointment
client specifications report
3.1.2 Development Develop the Actual VS.NET Version of Availability of
actual development and SQL software software v/s
application of project Server waiting for it
3.1.3 Testing Execute and Validating Code Getting right Availability of
check the the code inputs for knowledgeable
table for testing
project respective
modules

3.2 Assignments:
ROLES NAME RESPONSIBILITIES

Team Leader Kavita Kelkar  Design generation

 Requirement

gathering

Project Analyzer Prafull Bhosale  Analysis

 Evaluation of codes
Project Manager Yogesh Jadhav  Integration and
 testing modules
Management of
database
Project Advisors Rahul Bansode  Coordinating
 Development of
user interface
module
3.3 Timetable:

Tasks Description Days allotted Start date End date

Requirement Collection of 15 Jul 2008 Jul 2008

gathering information and
analysis
of various
books
Designing Front-end using 15 Jul 2008 Jul 2008
ASP.NET and
back-end using
MS SQL Server
Coding Managing 45 Aug 2008 Sept 2008
library system
using .NET
Testing Testing various 30 Sept 2008 Oct 2008
modules
Documentation Generating 15 Oct 2008 Oct 2008
different reports
as per
requirements.

Roll no Signature of Faculty with date

 Experiment No :6

Aim : To prepare SYSTEM TEST DOCUMENT

Test Approaches:

White box testing

Using white-box testing methods, the software engineer can derive test cases that do all of the
following:
5. Exercise all independent paths within the module at least once.
6. Exercise all logical decisions for both true and false scenarios.
7. Execute all loops at their boundaries and within their operational loops
8. Exercise all internal data structures to ensure their validity.

Black box testing

Black box testing attempts to find errors in the following categories:
6. Incorrect or missing functions
7. Interface errors
8. Errors in data structures or external database access
9. Performance errors
10. Initialization and termination errors

Unit testing
Unit testing focuses verification effort on the smallest unit of software design – the software module.
Using the component level design description as a guide, important control paths are tested to
uncover errors within the boundary of the module. The unit test is white box oriented, and the steps
can be conducted in parallel for multiple modules.

Integration testing
Interfacing of various modules can cause problems. Data can be lost across an interface, one
module may affect the other, and individually acceptable imprecision may be magnified when
combined.
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 design.

Stress testing
During earlier testing steps, white box and black box techniques result in a thorough evaluation of
 normal program functions and performance. Stress tests are designed to confront programs with
abnormal situations. Stress testing executes a system in a manner that demands resources in
abnormal quantity, frequency or volume. Essentially, the tester attempts to break the program.

Performance testing
Software that performs the required functions but does not conform to performance requirements is
unacceptable. Performance testing is designed to test run-time performance of software within the

context of an integrated system. Performance testing occurs through all the steps in the
testing process. However, it is not until all system elements are fully integrated that the
true performance of a system can be ascertained.

Security testing
Any computer-based system that manages sensitive information or causes actions that
can harm individuals is a target for improper or illegal penetration. Security testing
attempts to verify that protection mechanisms built into a system will, in fact, protect it from
improper penetration. During security testing, the tester plays the role of the hacker who
desires to penetrate the system. Given enough time and resources, good security testing
will ultimately penetrate a system. The role of the system designer is to make penetration
cost more than the value of the information that will be obtained.

Recovery testing
Many computer-based systems must recover from faults and resume processing within a
pre-specified time. In some cases, a system must be fault-tolerant, i.e. processing faults
must not cause overall system function to cease. In other cases, a system failure must be
corrected within a specified period of time or severe economic damage will occur.
Recovery testing is a system test that forces the software to fail in a variety of ways and
verifies that recovery is properly performed. If recovery is automatic, re-initialization,
check-pointing mechanisms, data recovery and restart are evaluated for correctness. If
recovery requires human intervention, the mean-time-to-repair (MTTR) is evaluated to
determine whether it is within acceptable limits.

Test Plan:

It is a document consisting of different test cases designed for different testing objects and
different testing attributes. The plan puts the test in sequential order as per the strategies
chosen that is, top down and bottom up. The test plan is matrix of test cases listed in order of
its execution.
Test Plan is developed to detect and identify potential problems before delivering the Software
to its users.
The scope of test will be limited just to the boundaries as the white box testing cannot be in detail.

Steps in delivering a Test Plan:

1. Prepare a Test Plan:

Identify members from quality assurance department, users and development to cover testing
in full extent.

2. Define Objectives of Testing:

Define objectives of testing and describe how to achieve them. Define which type of testing is
to be done and how will we be doing that. Define some testing milestones. Prepare detailed
test plan considering milestones.

3. Development of a Test Plan:

Develop test data, input, event or transaction and expected output for each test under consideration.

4. Perform Test Analysis:

After preparing test cases perform testing and examine test output and document the result. The
report will contain list with class, type and severity of defect.
Test Cases:

Item to be Input Expected Actual Output

Type of testing

tested Output

1.Login form Username: Welcome Welcome

admin

password:

******

Username: Re-enter Re-enter

_12admin username username

password: Password Password

* invalid. invalid.

2.Renewal form Member Accept ID Accept ID

Unit testing

ID:RH123

Member Invalid ID Invalid ID

ID:SS1213 Re-enter the ID Re-enter the ID

3.Application Name: ABC Accept Accept

form

Name: _____ Error. Name field Error. Name field

can’t be left can’t be left

blank. blank.

Integration 1. Connectivity Click on Page under Page under

testing hyperlink construction construction

Click on New page opens New page opens

hyperlink

2. Querying Post query Triggers an Triggers an

event event

Post query Data not found Data not found

1.login failure Backup system Backup system
at work at work

System testing Data lost Data lost

2. Security Unauthorized Unauthorized
access access
Welcome Welcome
Mr.Administrator Mr.Administrator
Critical Credit card no Credit card Credit card
applications accepted accepted
Beta testing
Expired Credit Credit card Credit card
card no rejected. rejected.
Password Password entry Password Password
Alpha testing encryption accepted safely accepted safely

Experiment No :7

Aim : To prepare Deployment Document.

Theory:
Deployment Plan is a ‘how-to’ guide to implement a solution into a live production environment.
It provides detailed deployment guidelines and helps drive the deployment phases.

Deployment Planning :
Careful planning ensures that the system is installed smoothly, on schedule, without any
significant problems, and to the complete satisfaction of the customer. Specific objectives
are to complete the plans for:
 
· contingencies to cover for unexpected problems,
· software deployment,
· deployment and warranty support services.
 

Environment Set-Up: The system is designed to run over the Internet and viewed through
browsers such as Netscape or MS Internet Explorer (MSIE). The software is to be created
primarily by the use of Java Servlets and other Java components (Beans, JSPs . . . ). This
system can be upgraded easily to support internet accessibility.

As with any internet program, a web server is needed. Although we could have used the free
Apache web server with JRun as the Java Virtual Machine, we prefer to use IBM’s Java
Web Server because of its simplicity. The servlets reside on the Web server. It is the web
server that takes the majority of traffic,

We will transfer the existing Customer database and Product/Service database to Oracle 8i. In
addition to the existing databases, the new data storage area for invoice transactions will be
on Oracle. Oracle and the Web server are directly connected via a gigabit Ethernet.

The user need to be connected to the network. we suggest using a hub-based network. All
the client computers are connected to the hub, which is in tern connected to the web server.

Installation and Configuration :

 Windows operating system.
 Web browser Netscape or IE.
 Oracle 8i.
 Configuring web server.

Rollout to End-Users :This module helps facilitates traning to end users .

Customization Modeling :

Component diagram.

Component diagrams document physical elements. Components are wired together by using
an assembly connector to connect the required interface of one component with the
provided interface of another component. This illustrates the service consumer - service
provider relationship between the two components.
An assembly connector is a "connector between two components that defines that one
component provides the services that another component requires. An assembly connector
is a connector that is defined from a required interface or port to a provided interface or
port."

When using a component diagram to show the internal structure of a component, the provided
and required interfaces of the encompassing component can delegate to the corresponding
interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a component (as
specified by its ports) to the internal realization of that behavior by the component’s parts."

Components diagrams can be used to illustrate the structure of arbitrarily complex systems.
The following example illustrates what a typical Insurance policy administration system
might look like:

It is possible to envisage that each of the components depicted in the above diagram will, in
turn, have other component diagrams illustrating their internal structure.

Component Diagram:
Deployment Diagram:
Deployment Diagram documents hardware elements .Deployment diagram in the UML serves
to model the physical deployment of artifacts on deployment targets .

Deployment Diagrams show “the location of artifacts to nodes according to the deployments
defined between them.

Deployment of an artifacts to a node is indicated by placing the artifact inside the node.
Instances of nodes are used in deployment diagram to indicate multiplicity of this node.

Deployment Diagram:

Roll no Signature of Faculty with date