M.E./M.

Tech Degree Practical Examination

Name ……………………………………………….

Branch ……………………………………………….

Semester ……………………………………………….

Reg. No ..……………………………………………….

Academic Year ……………………………………………….

1
Name ……………………………………………….
Reg. No. ……………………………………………….
Sem. /Branch ……………………………………………….
Sub. Code / Subject ……………………………………………….

Certified that this is the Bonafide record of the Practical done for the
above subject in the Laboratory during the period

……………………

Staff in Charge Head of the Department

Submitted for the University Practical Examination held at

DHANALAKSHMI SRINIVASAN ENGINEERING COLLEGE,
PERAMBALUR on ……………………

INTERNAL EXAMINER EXTERNAL EXAMINER

2
 EXPERIMENTS
S.NO DATE PARTICULARS PAGE SIGN
NO

Write a Problem Statement to define a title of the project with

1
bounded scope of project

Select relevant process model to define activities and related task

2
set for assigned project

Prepare broad SRS (Software Requirement Specification) for the

3
above selected projects

Prepare USE Cases and Draw Use Case Diagram using modeling
4
Tool

Develop the activity diagram to represent flow from one activity to

5
another for software development

6 Develop data Designs using DFD Decision Table & ER Diagram.

Draw class diagram, sequence diagram, Collaboration Diagram,

7
State Transition Diagram for the assigned project

Write Test Cases to Validate requirements of assigned project

8
from SRS Document

Evaluate Size of the project using function point metric for the
9
assigned project

Estimate cost of the project using COCOMO and COCOCMOII

10
for the assigned project

11 Use CPM/PERT for scheduling the assigned project

Use timeline Charts or Gantt Charts to track progress of the

12
assigned project

3
Ex.No:1 Write a Problem Statement to define a title of the project with bounded scope of
Date: project
.

Aim:

Write problem statement to define the project title with bounded scope of the project.

Introduction

Problem Statement

A problem statement is a clear description of the issue(s), it includes a vision, issue

staternent, and method used to solve the problem
A problem statement is usually one or two sentences to explain the your problem
process improvement project will address. In general, a problem statement will outline the
negative points of the current situation and explain why this matters. It also serves as a great
communication tool, helping to get buy in and support from others.

Project Scope

A project scope, or project scope statement, is a tool used to describe the major
deliverables of a project including the key milestones, high level requirements, assumptions,
and constraints. The project scope statement is a useful tool for future decision making when
new change requests are considered to modify the project scope.

Library management system

Problem statement

The purpose of the Library Management system is to allow for storing details of a
large number of books, magazines, Journals, thesis and allow for add, search, borrow, return
facilities separately to administrator/Librarian, staff and students. Different privileges are
given to different types of users.

The tasks to be done are:

1. Identify the main entities (objects) for this system.

2. Find out the relationships between these objects.
3. Find the necessary attributes and functions that need to be associated with each object
to implement the functionality mentioned above.

Project Scope

The scope of Library Management System includes:

 Create distinct product users based on their roles and permissions.

4
  Authenticate users at their login.
 Provide the list of books the users can borrow. Facility to reserve books that
are available.
 Facility to cancel the reservation for a book made earlier.
 Providing interface to add or delete books to staffs.

Conclusion:

The problem statement was written successfully.

5
Ex.No:2 Select relevant process model to define activities and related task set for assigned
Date: project

Aim:

Select relevant process model to define activities and related task set for assigned
project

Process model:-

A software process model is define simplified process representation of software

process each methods represent a process from a specific perspective.
Waterfall model:
The waterfall model is also called as the linear-sequential model or classic life cycle
model. The software development starts with requirements gathering phase. Then
progress through analysis, design, coding, testing & maintenance

Advantages of waterfall model.

1. It is very simple to understand.

2. For implementation of small systems waterfall model is useful.

Disadvantages of waterfall model

1. It is not useful for large projects.

2. It is very difficult to modify systems requirement if the middle of the
development process.
3. It is not suitable for projects in which requirement software are not clear
initially.

6
 We have used waterfall model for the projects because requirements of Projects
because requirements of projects are very well known. Clear and fixed our projects is
very small to be implemented. In our project there is no need of customer involvement
in the project. Development cycle product definition of project are not changed the
frequently. In our project there is no need of our participation in all phase. Software
the waterfall model is suitable process model for our project

Conclusion:

The relevant process model was defined successfully.

7
Ex.No:3 Prepare broad SRS (Software Requirement Specification) for the above selected
Date: projects

Aim:

Prepare broad SRS for the above selected project.

Introduction

The output of the requirements phase of the software development process is Software
Requirements Specification (SRS) (also known as requirements document).
This document lays a foundation for software engineering activities and is created
when entire requirements are elicited and analyzed. SRS is a formal document, which
acts as a representation of software that enables the users to review whether it (SRS) is
according to their requirements. In addition, it includes user requirements for a system
as well as detailed specifications of the system requirements.

Characteristics of SRS

Software requirements specification should be accurate, complete, efficient, and of

high quality, so that it does not affect the entire project plan. An SRS is said to be of
high quality when the developer and user easily understand the prepared document.
Other characteristics of SRS are discussed below.

1. Correct: SRS is correct when all user requirements are stated in the requirements
document. The stated requirements should be according to the desired system. This
implies that each requirement is examined to ensure that it (SRS) represents user
requirements. Note that there is no specified tool or procedure to assure the
correctness of SRS. Correctness ensures that all specified requirements are performed
correctly.

2. Unambiguous: SRS is unambiguous when every stated requirement has only one
interpretation. This implies that each requirement is uniquely interpreted. In case there
is a term used with multiple meanings, the requirements document should specify the
meanings in the SRS so that it is clear and easy to understand.

3. Complete: SRS is complete when the requirements clearly define what the software
is required to do. This includes all the requirements related to performance, design and
functionality.

4. Ranked for importance/stability: All requirements are not equally important,

hence each requirement is identified to make differences among other requirements.
For this, it is essential to clearly identify each requirement. Stability implies the
probability of changes in the requirement in future.

8
5. Modifiable: The requirements of the user can change, hence requirements.
document should be created in such a manner that those changes can be modified
easily, consistently maintaining the structure and style of the SRS.

6. Traceable: SRS is traceable when the source of each requirement is clear and
facilitates the reference of each requirement in future. For this, forward tracing and
backward tracing are used. Forward tracing implies that each requirementshould be
traceable to design and code elements. Backward tracing implies defining each
requirement explicitly referencing its source.

7. Verifiable: SRS is verifiable when the specified requirements can be verified with
a cost-effective process to check whether the final software meets those requirements.
The requirements are verified with the help of reviews.

8. Consistent: SRS is consistent when the subsets of individual requirements defined

do not conflict with each other. For example, there can be a case when different
requirements can use different terms to refer to the same object. There can be logical
or temporal conflicts between the specified requirements and some requirements
whose logical or temporal characteristics are not satisfied.

Conclusion:

The SRS (Software Requirement Specification) wasprepared successfull

9
 Ex.No:4 Prepare USE Cases and Draw Use Case Diagram using modeling Tool
Date:

Aim:

To prepare USE Cases and Draw Use Case Diagram using modelling Tool for Book
Bank project.

Introduction

Library management:

The purpose of the system is to allow for storing details of a large number of books and
allow for add, search, borrow, return facilities separately to administrator.staff and students.
Different privileges are given to different types of users. Using the OOSE (Object Oriented
Software Engineering) we try to express the requirements as use cases consisting of actors
and how they interact with the system. We Define the objects and use cases as system objects.
We define the functions and attributes within these system objects.

Actors -
1. Administrator (Category User)
2. Staff (Category User)
3.Students (Category User)
4.Library Account (Category System)
5. Book (Category System)
6. Transaction (Category System)
7. Report (Category System)
8. Search (Category System)
9. Registration (Category System)

Objects that define the system-

1. Book (Attributes: title, author, isbn, price:Functions: add book, remove book
Extended Functions: login, login failed search book, requisituion ist)
2. Transaction (Attributes: student id, book id.staff idFunctions: borrow book,
return book Extended functions: search student, search staff, search book)
3. Registration (Attributes:student_name, student_rollno, student_id,Staff name,
staff designation, staff id)Functions: register student, register staff Extended Function:
login, login failed.search student, search staff, search unsuccessful)
4. Report (Attributes: book id, student id, date of returnFunctions: defaulters list,
borrower listrequisition listExtended Functions: login, login failed)
5.Search (Attributes: student id,book id, staff idFunctions: login, login failed.
search book, search student, search staff, search unsuccessful)
6. Administrator (Attributes: name, administrator idExtended Functions: login,
register, search,transaction, report)
7.Staff (Attributes name, staff_idExtended Functions: login, register, search,
view)

10
 8. Student (Attributes: name, student idFunctions: login, search)
9.Login (Attributes: student_id,administrator_id,staff_id,Password,Functions:
login, login failedExtended Functions: register student,regisater_staff)
10. View/Edit (Attributes: student id,staff id.administrator_idFunctions: view
student, edit student, view book, edit book, view staff, edit staff, Extended Functions:
login, login failed search student, search book, search staff, search unsuccessful)

Use Cases-

1. Use Case #1 Registration

Primary Actors: Administrator, Staff

Pre- Condition: The student should have a valid college membership document which
contains his name, date of birth, course, rollno to obtain library membership. The same
criteria apply for registration of library and other staff members including the administrator.

Main Scenario

1. To register a student the administrator or staff has to first login

2. After login the administrator or staff searches for the existing Students
3. If the student is already registered there is no need to register him.
4. If the saalent is not already registered then his name, toll no is to been tered
for registration..
5. A student id for library membership is generated and provided to the Student
6. To register a staff member the administrator has to first log m.
7. After successful login he searches among the existing staff members If the staff
member is already registered there is no neod to regisser ion.
8. If the staff member is not already registered then his name, designation is
Entered
9. After successful registration the staff member is provided with a unique id.

Allemate Scenarios

1. The administrator or caff fails to login

2. Administrator or staff can search fot his id among existing members
3. If he is already a member and unable to login he should contact the administrator
otherwise he should get re-registered.

2. Use Case #2 Search

Primary Actors: Administrator, Staff, Students

Pre-Condition: The book or student to be searched should have been registered in

the database of the library management system

11
Main Scenario

1. The student or staff or administrator logins to the system.

2. If the login is successful student or staff or administrator enters the book name or ISBN or
author name and presses search
3. If the search is successful then that book is displayed on the screen.
4. To search for a student the administrator or staff logins to the system.
5. If the login is successful then it is possible to search for any student by entering his id.
6. To search for a staff member the administrator enters his login id..
7. If successful he can search for any of the staff members.

Altemative Scenario

1. The login fails.

2. The student or staff or administrator can re-register themselves
3. If the search is unsuccessful then the administrator should add that members.
4. If the book search is unsuccessful then that book should be added.

12
3. Use Case #3 Transaction

Primary Actors: Administrator, Staff

Pre-Condition: To retum or borrow any book it is important that the student or staff member
is registered with the library and the book to be borrowed is available witj the library. To
return the book the pre-condition is that the student and the staff member is registered and that
book data is available with the library

Main Scenario

1. If a student wants to borrow or retum a book the staff or administrator should login
to the system.
2. If login is successful the staff or administrator should enter the student id to be
searched.
3. If student search is successful the staff or administrator should enter the book id.
4. If the book is available it can be borrowed.
5. If the book is available the staff and administrator should check The report data for
any pending fine.
6. If no fine is pending the book can be returned.

Alternate Scenarios

1. If the login fails the staff or administrator should re-register Themselves.

2. If the student search is unsuccessful and no data is found then the administrator
should re-register the student.
3. If the book search is unsuccessful and book data is not found then administrator must
enter the book in requisition report

13
4. Use Case #4 Book (Add/Remove)

Primary Actors: Administrator, Staff

Pre-Condition: To add any book that book should be part of the requisition list and to delete
the book the book must be part of the library.

Main Scenario

1. The staff or administrator login to the system.

2. If login is successful then to add a book the staff or administrator must search for the
book.
3. If the book is not found then it is checked in the requisition list.
4. If the book is not currently available and is part of the requisition list it can be added
to the book database.
5. To remove a book it is again searched in the library system.
6. If it is found it should be checked in borrower list
7. If it is not in the borrowed list it can be removed.

Alternate Scenarios

1. If the login is unsuccessful then staff should re-register themselves.

2. If a book is to be added and on search it is already found it should not e added
again.
3. If book is to be removed and on search it is not found and is also not part of
borrowers list then there is any need to remove it.

14
5. Use Case #5 Report

Primary Actors: Administrator, Staff

Pre-Condition: To generate any report the staff or administrator should be registered with the
library and to generate report on any book or student they should be part of the library system

Main Scenario

1. The staff or administrator logins to the system,

2. To generate report on defaulters the staff or administrator should first search for that
student.
3. If the student is found then he can be checked in the defaulters list.
4. To generate report on borrowed books the staff or administrator must search for that
book.
5. If found that book can be checked in the borrowed books list.
6. To generate report on requisition list of book the he staff or administrator should first
search for that book.
7. If book is not found then it should be checked in the requisition list.

Alternate Scenarios

1. If the login is not successful then staff or administrator should go to the registration
page.
2. If student is not found after search he should be re-registered.
3. If book is not found then that book should be added again before checking it in the
borrowers list

15
6. Use Case #6 Login

primary Actors: Administrator, Staff, Student

Pre-Condition: If the student or staff or administrator wants to login then he should have
been first registered.

Main Scenario

1. To login the student or staff or administrator should first open the Login page
2. They should then enter their ids and passwords.
3. Once the id and password are verified they are moved to the options page
where they can search, view and perform other operations.

Alternate Scenario

1 The login fails after entering login and password.

2. It is the responsibility of the administrator to see that all staff and students are
properly registered and can login to the system

16
7. Use Case #7 View/Edit

Primary Actors: Administrator, Staff

Pre-Condition: To view the details of any book or edit book details that book should be part
of the library database. To view or edit student or staff details thal student or staff should be
part of the library database. Whoever is viewing or editing should be registered with the
library.

Main Scenario

1. To view details or edit details of any book the administrator or staff should first
login to the library system.
2. If login successfully they must search for that book by putting book id or title or
isbn.
3. If the book is found they should enter book id to view the details and also edit it.
4. To view details or edit details of any student or staff the administrator or staff
should first login to the library system.
5. If login successfully they must search for that student or staff by putting student id
or staff id.
6. If the student or staff is found they should enter student id or staff id to view the
details and also edit it.
7. If book search is unsuccessful then that book cannot be viewed or edited.

Alternate Scenarios

1. If login fails the administrator should re-register that staff

2. If book search is unsuccessful them book cannot be viewed or edited.
3. If staff search is unsuccessful then that staff member cannot be viewed or
edited

17
Conclusion:

The Usecase Diagram was drawn successfully

18
Ex.No:5 Develop the activity diagram to represent flow from one activity to another for
Date: software development

Aim:

To Develop the activity diagram to represent flow from one activity to another for
software development

Activity Diagram

Activity diagram is a flowchart to represent the flow of control among the activities in
the system. The flow of operation can be sequential, branched or concurrent. The
activity diagram is sometimes considered a flowchart

 Initial node. The filled in circle is the starting point of the diagram. An initial node
isn‘t required although it does make it significantly easier to read the diagram.
 Activity final node. The filled circle with a border is the ending point. An activity
diagram can have zero or more activity final nodes.
 Activity. The rounded rectangles represent activities that occur. An activity may be
physical, such as Inspect Forms, or electronic, such as Display Create Student Screen
.  Flow/edge. The arrows on the diagram. Although there is a subtle difference
between flows and edges,never a practical purpose for the difference although.
 Fork. A black bar with one flow going into it and several leaving it. This denotes
the beginning of parallel activity.
 Join. A black bar with several flows entering it and one leaving it. All flows going
into the join must reach it before processing may continue. This denotes the end of
parallel processing.  Condition. Text such as [Incorrect Form] on a flow, defining a
guard which must evaluate to true in order to traverse the node.
 Decision. A diamond with one flow entering and several leaving. The flows leaving
include conditions although some modelers will not indicate the conditions if it is
obvious.
 Merge. A diamond with several flows entering and one leaving. The implication is
that one or more incoming flows must reach this point until processing continues,
based on any guards on the outgoing flow.
 Partition. If figure is organized into three partitions, it is also called swimlanes,
indicating who/what is performing the activities (either the Applicant, Registrar, or
System).
 Sub-activity indicator. The rake in the bottom corner of an activity, such as in the
Apply to University activity, indicates that the activity is described by a more finely
detailed activity diagram.
 Flow final. The circle with the X through it. This indicates that the process stops at
this point.

19
Guidelines associated for drawing an activity diagram:

1.General Guidelines
2.Activities
3.Decision Points
4.Guards
5.Parallel Activities
6.Swimlane Guidelines
7.Action-Object Guidelines

1.General Guidelines

Figure1. Modeling a business process with a UML Activity Diagram

1. Place The Start Point In The Top-Left Corner. A start point is modeled with a filled
in circle, using the same notation that UML State Chart diagrams use. Every UML
Activity Diagram should have a starting point, and placing it in the top-left corner
reflects the way that people in Western cultures begin reading. Figure1, which models
the business process of enrolling in a university, takes this approach.
2. Always Include an Ending Point. An ending point is modeled with a filled in circle
with a border around it, using the same notation that UML State Chart diagrams use.

20
3. Flowcharting Operations Implies the Need to Simplify. A good rule of thumb is that
if an operation is so complex you need to develop a UML Activity diagram to
understand it that you should consider refactoring it.

2. Activities
An activity, also known as an activity state, on a UML Activity diagram typically
represents the invocation of an operation, a step in a business process, or an entire
business process.
1. Question ―Black Hole‖ Activities. A black hole activity is one that has
transitions into it but none out, typically indicating that you have either missed one
or more transitions.
2. 2. Question ―Miracle‖ Activities. A miracle activity is one that has transitions
out of it but none into it, something that should be true only of start points.
3. Decision Points
3.A decision point is modeled as a diamond on a UML Activity diagram.

1. Decision Points Should Reflect the Previous Activity. In figure1 we see that
there is no label on the decision point, unlike traditional flowcharts which would
include text describing the actual decision being made, we need to imply that the
decision concerns whether the person was enrolled in the university based on the
activity that the decision point follows. The guards, depicted using the format
[description], on the transitions leaving the decision point also help to describe the
decision point.
2. Avoid Superfluous Decision Points. The Fill Out Enrollment Forms activity in
FIGURE1 includes an implied decision point, a check to see that the forms are
filled out properly, which simplified the diagram by avoiding an additional
diamond.

4. Guards

A guard is a condition that must be true in order to traverse a transition.

1. Each Transition Leaving a Decision Point Must Have a Guard
2. Guards Should Not Overlap. For example guards such as x 0 are consistent whereas
guard such as x <= 0 and x >= 0 are not consistent because they overlap – it isn‘t clear
what should happen when x is 0.
3. Guards on Decision Points Must Form a Complete Set. For example, guards such as
x < 0 and x >0 are not complete because it isn‘t clear what happens when x is 0.
4. Exit Transition Guards and Activity Invariants Must Form a Complete Set. An
activity invariant is a condition that is always true when your system is processing an
activity.
5. Apply a [Otherwise] Guard for ―Fall Through‖ Logic.
6. Guards Are Optional. It is very common for a transition to not include a guard, even
when an activity includes several exit transitions.

5. Parallel Activities

21
 it is possible to show that activities can occur in parallel, as you see in FIGURE 1
depicted using two parallel bars. The first bar is called a fork, it has one transition
entering it and two or more transitions leaving it. The second bar is a join, with two or
more transitions entering it and only one leaving it.
1. A Fork Should Have a Corresponding Join. In general, for every start (fork)
there is an end (join). In UML 2 it is not required to have a join, but it usually makes
sense.
2. Forks Have One Entry Transition. 3. Joins Have One Exit Transition 4. Avoid
Superfluous Forks. FIGURE 2 depicts a simplified description of the software process
of enterprise architectural modeling, a part of the Enterprise Unified Process (EUP).
There is significant opportunity for parallelism in this process, in fact all of these
activities could happen in parallel, but forks were not introduced because they would
only have cluttered the diagram.

6. Swimlane

Guidelines A swimlane is a way to group activities performed by the same actor

on an activity diagram or to group activities in a single thread. FIGURE 2 includes
three swimlanes, one for each actor.

A UML activity diagram for the enterprise architectural modeling (simplified).

22
 1. Order Swimlanes in a Logical Manner.
2. Apply Swim Lanes To Linear Processes. A good rule of thumb is that swimlanes
are best applied to linear processes, unlike the one depicted in FIGURE 3.
3. Have Less Than Five Swimlanes.
4. Consider Swimareas For Complex Diagrams.
5. Swimareas Suggest The Need to Reorganize Into Smaller Activity Diagrams.
6. Consider Horizontal Swimlanes for Business Processes. In FIGURE 3 you see that
the swimlanes are drawn horizontally, going against common convention of drawing
them vertically.
7 Action-Object Guidelines Activities act on objects, In the strict object-oriented
sense of the term an action object is a system object, a software construct. In the
looser, and much more useful for business application modeling, sense of the term an
action object is any sort of item. For example in the ExpenseForm action object is
likely a paper form.
1. Place Shared Action Objects on Swimlane Separators
2. When An Object Appears Several Time Apply State Names
3. State Names Should Reflect the Lifecycle Stage of an Action Object
4. Show Only Critical Inputs and Outputs
5. Depict Action Objects As Smaller Than Activities

Conclusion:

The activity diagram was made successfully by following the steps described
above.

23
 Ex.No:6 Develop data Designs using DFD Decision Table & ER Diagram.
Date:

Aim:

Develop data design using DFDs, Decision tables and E-R diagram.

Introduction

Data flow diagram is graphical representation of flow of data in an information system.

It is capable of depicting incoming data flow, outgoing data flow and stored data. The
DFD does not mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts
flow of control in program modules. DFDs depict flow of data in the system at various
levels. DFD does not contain any control or branch elements.

Types of DFD

Data Flow Diagrams are either Logical or Physical.

Logical DFD - This type of DFD concentrates on the system process, and flow of data in the
system. For example in a Banking software system, how data is moved between different
entities.

Physical DFD - This type of DFD shows how the data flow is actually implemented in the
system. It is more specific and close to the implementation.

DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of
components-

Entities - Entities are source and destination of information data. Entities are represented by a
rectangles with their respective names,

Process- Activities and action taken on the data are represented by Circle or Round- edged
rectangles.

24
Data Storage- There are two variants of data storage it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with only one side
missing.

Data Flow- Movement of data is shown by pointed arrows. Data movement is shown from
the base of arrow as its source towards head of the arrow as destination.

Level 0: Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire
information system as one diagram concealing all the underlying details. Level 0 DFDs are
also known as context level DFDS.

Level 1: The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD
depicts basic modules in the system and flow of data among various modules. Level 1 DFD
also mentions basic processes and sources of information

Level 2: At this level, DFD shows how data flows inside the modules mentioned in Level 1..
Higher level DFDs can be transformed into more specific lower level DFDs with deeper level
of understanding unless the desired level of specification is achieved.

25
Decision Tables

A Decision table represents conditions and the respective actions to be taken to

address them, in a structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group similar information
into a single table and then by combining tables it delivers easy and convenient
decision-making.

Creating Decision Table

To create the decision table, the developer must follow basic four steps:
 Identify all possible conditions
 Determine actions for all identified conditions
 Create Maximum possible rules
 Define action for each rule
Decision Tables should be verified by end-users and can lately be simplified by
eliminating duplicate rules and actions.

Example

Let us take a simple example of day-to-day problem with our Internet connectivity.
We begin by identifying all problems that can arise while starting the internet and
their respective possible solutions.
We list all possible problems under column conditions and the prospective actions
under column Actions.

26
Entity-Relationship Model

Entity-Relationship model is a type of database model based on the notion of real

world entities and relationship among them. We can map real world scenario onto ER
database model. ER Model creates a set of entities with their attributes, a set of
constraints and relation among them.
ER Model is best used for the conceptual design of database. ER Model can be
represented as follows:

 Entity An entity in ER Model is a real world being, which has some properties
called attributes. Every attribute is defined by its corresponding set of values,
called domain.
o For example, Consider a school database. Here, a student is an entity.
Student has various attributes like name, id, age and class ete.
 Relationship The logical association among entities is called relationship.
Relationships are mapped with entities in various ways. Mapping cardinalities
define the number of associations between two entities.
 Mapping cardinalities:
o one to one
o one to many
o many to one
o many to many

27
Library management:

28
29
Conclusion:

The Data Flow Diagram was drawn successfully

30
 Ex.No:7 Draw class diagram, sequence diagram, Collaboration Diagram, State Transition
Date: Diagram for the assigned project

AIM:

To Draw class diagram, sequence diagram, Collaboration Diagram, State Transition

Dia for Library management system.

Introduction

Class diagram:

In software engineering a Class diagram in the UML(Unified Modelling Language)

is a typeof static structure diagram that describes the structure of a system by
showing the system classes, theirattributes, operations(or methods) and the
relationships among objects.
Class diagram notation consists of three parts –

Class name The name of the class appears in the first partition
Class attributes Attributes are shown in the second partition. They map on to membe
rvariables in code
Class methods Methods are shown in the third partition. They are services the class
provides

Relationships

Existing relationships in a system describe legitimate connections between the classes

in that system

31
Association:

It is an instance level relationship that allows exchanging messages among the objects
of both ends ofassociation. A simple straight line connecting two class boxes
represent an association. We can give aname to association and also at the both
end we may indicate role names and multiplicity of the adjacentclasses. Association
may be uni-directional.

Example:

In structure model for a system of an organization an employee (instance of

‘Employee’ class) is alwaysassigned to a particular department (instance of ‘Department’
class) and the association can be shown
by a line connecting the respective classes.

Aggregation:

It is a special form of association which describes a part-whole relationship between a

pair of classes.It means, in a relationship, when a class holds some instances of related
class, then that relationship can be designed as an aggregation.Example:For a
supermarket in a city, each branch runs some of the departments they have. So, the
relation among the classes ‘Branch’ and ‘Department’ can be designed as an aggregation.
In UML, it can be shown as in the fig. below

32
Composition:

It is a strong from of aggregation which describes that whole is completely owns its
part. Lifecycle of the part depends on the whole.Example:Let consider a shopping
mall has several branches in different locations in a city.The existence of branches
completely depends on the shopping mall as if it is not exist any branch of it will no
longerexists in the city.This relation can be described as composition and can be
shown as below

Multiplicity:

It describes how many numbers of instances of one class is related to the number of
instances ofanother class in an association.

Example:

One vehicle may have two or more wheels.

33
Sequence diagram:

Sequence diagram simply depicts interaction between objects in a sequential order.

Sequencediagram describe how and in what order the objects in a system functions. These
diagrams are widelyused by businessman and software developers to document and
understand requirements for new andexisting systems.

Sequence diagram notations:

A sequence diagram is structured in such a way that it represents a timeline which

begins at the topand descends gradually to mark the sequence of interactions. Each
object has a column and themessages exchanged between them are represented by arrows.

34
35
36
Collaboration diagram:

Collaboration diagram is also called as communication or interaction diagram. It is an

illustration of the relationships among software objects in UML.
A collaboration diagram resembles a flowchart that portrays the roles, functionality
and behaviour of individual objects as well as the overall operation of the system in
real time.

37
Collaboration diagram notations:

State transition diagram

The state transitioni diagram is one method for representing the behaviour of a system
By depicting its states and the events that cause the system to change state. In
addition, the state diagram indicates actions taken as a consequence of a particular
event

38
State transition diagram notations:

conclusion:

The class diagram, sequence diagram, Collaboration Diagram, State Transition

Diagram for Library management system was drawn successfully.

39
 Ex.No:8 Write Test Cases to Validate requirements of assigned project from SRS
Date: Document

Aim:

Write test cases to validate requirements of assigned project from SRS document.

Introduction:

What are the requirements of library management system?

1. User able to register and login.
2. User can search the added books, and check in or out.
3. User can pay the fine or extend the duration of borrowed period.
4. User can change the password and other profile details.
5. User can add the books.
6. User can place the holds and modify existing holds.
7. User can manage the inventory of the books.
These are some of the common features expected from the library management
system. So you now have some test scenarios to check for. In addition to these test
scenarios, you have GUI based software to check for the bugs, usability and
functional

Testing Login of Library System:

 Check if the username field accepts valid username and password field accepts
valid password.
 Check if the wrong username and valid password allows access to any specific
account.
 Check if the valid username and wrong password allows access to any specific
account.
 Check if the invalid credentials open the random account.

Testing User Management:

You can also check the transactions of the member and also search for the member.
 Check if the member can be searched using the firstname or lastname.
 Check if the member transactions are updated.
 Check if the user data can be modified if you are admin.
 Check if the user can be removed using delete member feature.

Testing Search system of Library:

Search system should allow you to search for either member profiles or books.
 Check if the search function allows searching of books as per title, ISBN,
author, genre or all of the criteria.

40
  Check if the search filter exists as per books, cds, magazines, videos and
software or all of them
 Check if the search filter has categories feature.

Library has the resources system where you can either search for the books available or you
can add or remove the books in the system. This tab should have the resources like books,
magazines, courseware, CDs or other resources,
 Check if the resources can be searched using the search feature.
 Check if you can add the resource using type, and other categorized
information.
 Check if you can modify or edit the resource.
 Check if you can save the resource information.
 Check if you can add category for the resource.
 Check each field for the limit of the text fields and also valid input for the
form

Test Cases For Library Management System:

Login form:

S.No Test Case Excepted Result Test Result

1 Enter valid name and password Software should Successful

& click on login button display main
window

2 Enter invalid Software should not Successful

display main
window

41
BOOK ENTRY FORM:

S.No Test Case Excepted Result Test

Result

1 On the click of ADD At first user have to fill all fields with proper successful
button data, if any Error like entering text data instead
of number or entering number instead of text..is
found then it gives proper message otherwise
Adds Record To the Database

2 On the Click of This deletes the details of book by using successful

DELETE Button Accession no.

3 Modified records are Updated in database by successful

On the Click of
UPDATE Button

4 Displays the Details of book for entered successful

On the Click of Accession no. Successful Otherwise gives
SEARCH Button proper Error message.

5 On the Click of Clears all fields successful

CLEAR Button

6 On the Click of EXIT On the Click of EXIT Exit the current book successful
button details form button

42
 7 On the Click of NEXT Display the next form successful
button

USER ACCOUNT FORM:

SL.No Test Case Excepted Result Test Result

1 On the click of ADD button At first user have to successful

fill all fields with
proper data, if any
Error like entering
text data instead of
number or entering
number instead of
text..is found then it
gives proper message
otherwise Adds
Record To the
Database

2 On the Click of DELETE Button This deletes the successful

details of book by
using Accession no.
3 Modified records are successful
On the Click of UPDATE Button Updated in database
by
4 Displays the Details successful
On the Click of SEARCH Button of book for entered
Accession no.
Successful Otherwise
gives proper Error
message.

5 On the Click of CLEAR Button Clears all fields successful

6 On the Click of EXIT button On the Click of successful

EXIT Exit the
current book details
form button

7 On the Click of NEXT button Display the next successful

form

43
BOOK ISSUE FORM:

SL.No Test Case Excepted Result Test Result

1 On the click of ADD At first user have to successful

button fill all fields with
proper successful
data if the accession
number book is
already issued then it
will giving proper
msg.

2 On the Click of This deletes the successful

DELETE Button details of book by
using Register no.

3 Modified records are successful

On the Click of Updated in database
UPDATE Button by clicking UPDATE
button.

4 Displays the Details successful

On the Click of of issued
SEARCH Button book..Otherwise
gives proper Error
message,

5 On the Click of Clears all fields successful

CLEAR Button

6 On the Click of Exit the current book successful

EXIT button details form

7 On the Click of Display the next successful

NEXT button form.

44
BOOK RETURN FORM:

SL.No Test Case Excepted Result Test Result

1 On the click of ADD At first user have to successful

button fill all fields with
proper data, if any
Error like entering
text data instead of
number or entering
number instead of
text.. is found then it
gives proper message
otherwise Adds
Record To the
Database

2 On the Click of successful

DELETE Button Which deletes the
details of book by
using Register no.

3 Modified records are successful

On the Click of Updated in database
UPDATE Button by clicking UPDATE
button
4 Displays the Details successful
On the Click of of returned book...
SEARCH Button Otherwise. gives
proper Error message.

5 On the Click of Clears all fields successful

CLEAR Button

6 On the Click of EXIT Exit the current book successful

button details form

7 On the Click of Display the next form successful

NEXT button

conclusion:
Test Cases to Validate requirements of assigned project from SRS Document was
drawn successfully.

45
 Ex.No:9 Evaluate Size of the project using function point metric for the assigned project
Date:

Aim:

Evaluate size of the project using function point metric for the assigned project.

Introduction

A function point (FP) is a component of software development which helps to approximate

the cost of development early in the process. It is a process which defines the required
functions and their complexity in a piece of software in order to estimate the software's size
and scope upon completion.
A function point calculates software size with the help of logical design and performance of
functions as per user requirements. It also helps in determining the business functionality of a
software application. A function point has a number of benefits, including increase in
productivity and reduction in the risk of inflation of created code. Function points can be
derived from software's requirements and can be estimated in the early phases of software
development, before the actual lines of code can be determined. The number of function
points in a code depends on function complexity.
How to calculate FP?
1. The data for following information domain characteristics are collected:
Number of user inputs- Each user input which provides distinct application data to the software
is counted.
2. Number of user outputs- Each user output that provides application data to the user
is counted,e.g. Screens, reports, error messages.
3. Number of User inquiries - An on-line inputs that results in the generation of some
immediate software response in the form of an output.
4. Number of files- Each logical master file, i.e. a logical grouping of data that may
be part of database.
5. Number of external interfaces All machine -readable interfaces that are used to
transmit information to another system are counted.
6. The organization needs to develop criteria which determine whether a particular
entry is simple, average or complex.

The weighting factor should be determined by observation or by experiments.

Measurement Weighting Factor Count

parameter Simple Average

Count* Complex.

Number of user * 3 4 6
inputs

46
 Number of user * 4 5 7
outputs

Number of User * 3 4 6
inquiries

Number of files * 7 10 15

Number of * 5 7 10
external
interfaces
Count Total

Productivity= FP/person-month
Cost per FP=labor rate productivity
Total estimated project cost-=Cost per FP FP

Assume Library Management software has produced following result:

1. Number of user inputs-7

2. Number of user outputs- 10
3. Number of User inquiries-6
4. Number of files-17
5. Number of external interfaces- 4

Input and external interface function point attributes are of average complexity and all other
function points attributes are of low complexity.
Determine adjusted function points assuming complexity adjusted value is ∑(f)=32.
Let us calculate
Measurement Weighting Factor Count

parameter Simple Average

Count Complex.

Number of 7 4 6 28
user
inputs

Number of 10 4 7 40
user outputs

47
 Number of 6 3 6 18
User
inquiries

Number of 17 7 15 119
files

Number of 14 7 10 28
external
interfaces
Count Total 233

Function Point =Count Total [0.65+0.01* ∑ (Fi)]

=2.33[0.65\div0.01*32]
=233*0.97-226.01

Estimated efforts =30 person-month

Labor rate =8000 per month.
Productivity-=FP/person-month =226.01/30=7.5
Cost per FP= labor rate/ productivity =8000/7.5=1067
Total estimated project cost= Cost per FP*FP=1067*226.01=24. 1200 (approximate)

Conclusion:

The project using function point metric for the assigned project was drawn
successfully.

48
 Ex.No:10 Estimate cost of the project using COCOMO and COCOCMOII for the assigned
Date: project

Aim:
Estimate the cost of the project using COCOMO/COCOMO II approach for the
assigned project.
Introduction

The Constructive Cost Model (COCOMO) is a procedural cost estimate model for
software projects that was created by Barry Bochm in the 1970s. It has been commonly used to
project costs for a variety of projects and business processes.

The Constants :

COCOMO in a Coconut-shell :
E = a (KLOC)
Where
E is the Effort in staff months
a and b are coefficients to be determined
KLOC is thousands of lines of code

The Modes
 Organic
2-50 KLOC, small, stable, little innovation
 Semi-detached
50-300 KLOC, medium-sized, average abilities, medium time-constraints
 Embedded
> 300 KLOC, large project team, complex, innovative, severe constraints

Examples

Suppose size is 200 KLOC,

Organic 2.4(200)1.05626 staff-months...
Semi-Detached, ,,3.0(200)1.12= 1,133 staff-months.
Embedded 3.6(200)1.20=2,077 stafl-months

49
Constrant for TDEV:

Project duration
TDEV=C(E)^D
Where
 TDEV is time for development
 c and d are constants to be determined
 E is the effort

Example:

Picking up from the last example...

Organic;E626 staff months
TDEV=2.5(626)0.38=29 months
Semi-detached..
E=1,133,
TDEV=2.5(1133)0.35=29 months
Embedded
E=2077
TDEV=2.5(2077)0.32=29 months

Library Management System:

Organic Type of Software

LOC: 32000
Salary of engineers: 15000/-
Efforts= 2,4*(32)^1.055=91PM
Development time=2.5 (91)^0.38=14 months
Cost required to develop the product=14* 15000=210,000/

Conclusion:

The project using COCOMO and COCOCMOII for the assigned project was drawn
successfully.
50
 Ex.No:11 Use CPM/PERT for scheduling the assigned project
Date:

Aim:

Use CPM/PERT for scheduling the assigned project.

Introduction

Critical path is the sequential activities from start to the end of a project. Although
many projects have only one critical path, some projects may have more than one
critical paths depending on the flow logic used in the project.
If there is a delay in any of the activities under the critical path, there will be a delay
of the project deliverables. Most of the times, if such delay is occurred, project
acceleration or re- sequencing is done in order to achieve the deadlines.
Critical path method is based on mathematical calculations and it is used for
scheduling project activities. This method was first introduced in 1950s as a joint
venture between Remington Rand Corporation and DuPont Corporation.
The initial critical path method was used for managing plant maintenance projects.
Although the original method was developed for construction work, this method can
be used for any project where there are interdependent activities. In the critical path
method, the critical activities of a program or a project are identified. These are the
activities that have a direct impact on the completion date of the project.

51
Key Steps in Critical Path Method

Let's have a look at how critical path method is used in practice. The process of using
critical path method in project planning phase has six steps.

Step 1: Activity specification

You can use the Work Breakdown Structure (WBS) to identify the activities involved
in the project. This is the main input for the critical path method.
In activity specification, only the higher-level activities are selected for critical path
method. When detailed activities are used, the critical path method may become too
complex to manage and maintain,

Step 2: Activity sequence establishment

In this step, the correct activity sequence is established. For that, you need to ask three
questions for each task of your list.
 Which tasks should take place before this task happens.
 Which tasks should be completed at the same time as this task.
 Which tasks should happen immediately after this task

Step 3: Network diagram

Once the activity sequence is correctly identified, the network diagram can be drawn
(refer to the sample diagram above).
Although the early diagrams were drawn on paper, there are a number of computer
softwares, such as Primavera, for this purpose nowadays.

Step 4: Estimates for each activity

This could be a direct input from the WBS based estimation sheet. Most of the
companies use 3-point estimation method or COCOMO based (function points based)
estimation methods for tasks estimation.
You can use such estimation information for this step of the process.

Step 5: Identification of the critical path

For this, you need to determine four parameters of each activity of the network..
Earliest start time (ES) - The earliest time an activity can start once the previous dependent
activities are over.
 Earliest finish time (EF)-ES+ activity duration.
 Latest finish time (LF) The latest time an activity can finish without delaying the
project.
 Latest start time (LS) LF-activity duration.
The float time for an activity is the time between the earliest (ES) and the latest (LS)
start time or between the earliest (EF) and latest (LF) finish times,

52
 During the float time, an activity can be delayed without delaying the project finish
date.
The critical path is the longest path of the network diagram. The activities in the
critical path have an effect on the deadline of the project. If an activity of this path is
delayed, the project will be delayed.
In case if the project management needs to accelerate the project, the times for critical
path activities should be reduced.

Step 6: Critical path diagram to show project progresses

Critical path diagram is a live artefact. Therefore, this diagram should be updated with
actual
values once the task is completed.
This gives more realistic figure for the deadline and the project management can know
whether they are on track regarding the deliverables.

Advantages of Critical Path Method

Following are advantages of critical path methods:

 Offers a visual representation of the project activities.
 Presents the time to complete the tasks and the overall project.
 Tracking of critical activities.

PERT (Program Evaluation and Review Technique) is one of the successful and proven
methods among the many other techniques, such as, CPM, Function Point Counting, Top-
Down Estimating, WAVE, etc.PERT was initially created by the US Navy in the late 1950s.
The pilot project was for developing Ballistic Missiles and there have been thousands of
contractors involved. After PERT methodology was employed for this project, it actually
ended two years ahead of its initial schedule.

The PERT Basics:

At the core, PERT is all about management probabilities. Therefore, PERT involves in many
simple statistical methods as well. Sometimes, people categorize and put PERT and CPM
together. Although CPM (Critical Path Method) shares some characteristics with PERT,
PERT has a different focus. Same as most of other estimation techniques, PERT also breaks
down the tasks into detailed activities,
Then, a Gantt chart will be prepared illustrating the interdependencies among the activities.
Then, a network of activities and their interdependencies are drawn in an illustrative
manner.In this map, a node represents each event. The activities are represented as arrows and
they are drawn from one event to another, based on the sequence. Next, the Earliest Time
(TE) and the Latest Time (TL) are figured for each activity and identify the slack time for
each activity.

The Three Chances:

There are three estimation times involved in PERT; Optimistic Time Estimate (TOPT), Most
Likely Time Estimate (TLIKELY), and Pessimistic Time Estimate (TPESS).
53
Following are further details on each estimate:

1. TOPT:
This is the fastest time an activity can be completed. For this, the assumption is made that all
the necessary resources are available and all predecessor activities are completed as planned.

2. TLIKELY:
Most of the times, project managers are asked only to submit one estimate. In that case, this is
the estimate that goes to the upper management.

3. TPESS:
This is the maximum time required to complete an activity. In this case, it is assumed that
many things go wrong related to the activity. A lot of rework and resource unavailability are
assumed when this estimation is derived.

The PERT Mathematics:

BETA probability distribution is what works behind PERT. The expected completion
time (E) is calculated as below:
E=(TOPT +4 x TLIEKLY + TPESS)/6

Conclusion:

The best thing about PERT is its ability to integrate the uncertainty in project times
estimations into its methodology. Using PERT, project managers can have an idea of the
possible time variation for the deliveries and offer delivery dates to the client in a safer
manner.

Library Management System

54
PERT:
Given data
TOPT=30
TLIKEL=-45
TPESS=60
Then
E=(TOPT+4 x TLIEKLY + TPESS)/6
E= (30+4*45+60)/6 =270/6
E = 45 days

Conclusion:

CPM/PERT for scheduling the assigned project was drawn successfully.

Ex.No:12 Use timeline Charts or Gantt Charts to track progress of the assigned project
Date:

55
Aim:
Use timeline Charts or Gantt Charts to track progress of the assigned project

Introduction:

A Gantt chart is a bar graph of a project’s tasks. A typical Gantt chart has the name of
individual tasks or group of tasks in the project on the Y-axis. The X-axis has a
timeline divided into days or weeks. Color bars indicate when a task is expected to
start. Different colors indicate how much of an activity has been completed and how
much remains unfinished.
The ability to grasp the overall status of a project and its tasks at once is the key
advantage in using a Gantt chart tool. Therefore, upper management or the sponsors
of the project can make informed decisions just by looking at the Gantt chart tool.
The software-based Gantt charts are able to show the task dependencies in a project
schedule. This helps to identify and maintain the critical path of a project schedule.
Gantt chart tools can be used as the single entity for managing small projects. For
small projects, no other documentation may be required; but for large projects, the
Gantt chart tool should be supported by other means of documentation For large
projects, the information displayed in Gantt charts may not be sufficient for decision
making.

Fig: A simple Gantt chart with multiple activities and their respective
dependencies

Procedure

56
 1. Develop a Work Breakdown Structure
2. Assign Tasks
3. Evaluate Task Dependencies
4. Share & Evaluate the Plan with Your Team

Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

Description

A Gantt chart can be very useful in planning and carrying out a project. There
are a number of ways to create a Gantt chart: from pen and paper or whiteboard to
very complex software programs.
Step 1: Develop a Work Breakdown Structure

What is a Work Breakdown Structure (WBS)? It is a process by which a project

is planned by breaking it into easily definable and understandable goals, milestones
and tasks. Listing the major components first is the first step in developing a WBS.
This can be done by in a word processor, spreadsheet, or using a Gantt chart program.
A key element in the WBS is to plan for intended outcomes, rather than planning
actions. That is, understand what the goals of the project are, define key milestones,
and then start the process of breaking those pieces down into tasks. If there are fixed
dates that need to be met, make sure those are shown in the Gantt chart. This way, as
the topics are broken into tasks, it will become clear upfront whether more resources
will need to be added to meet these deadlines.
After the major topics are determined, the process of breaking these into tasks is next.
Depending on the complexity of each task, the project planner may find it necessary
to continue breaking these items into sub-tasks until they are very specific.
For many project planners, a visual model of the WBS is easier to work with than the
"laundry list" dictated by the Gantt chart format. A mind map is ideal for this because
it lets you easily see the work breakdown. A good Gantt chart software program, such
as SmartDraw, will allow you to work in Gantt chart or mind map view, with
relational data that automatically updates both views when changes are made in either
one.
It is estimated that more than 90% of projects are late. The primary reason for this is
that they weren't properly planned with a well-thought-out work breakdown structure.
The more detailed the breakdown, the easier it is to plan, organize and schedule a
project accurately.

57
58
 Step 2: Assign Tasks

One of the most critical pieces in how to build a Gantt chart is the distribution of
work. There are several things to consider.
 Who is most qualified to complete this task?
 What is their availability vis-à-vis their currently scheduled workload?
 What is a reasonable expectation of their time needed to complete the
task(s)?
 Will additional people or resources be necessary to get these tasks
completed on time?
Step 3: Evaluate Task

Dependencies One of the benefits of creating a Gantt chart for project

planning is that it makes it easier to see dependencies. This is a situation where one
task is dependent upon the completion or outcome of another. For example, a
webmaster can't build a web page unless the copywriter and illustrator have finished
their tasks. Identifying these dependent relationships is critical, as delays in the
primary steps will almost certainly ripple throughout the entire project. Automated
software will allow you to add dependencies as you create your Gantt chart. If you're
doing this by hand or using a less sophisticated program, you'll need to remember to
do this crucial step manually.

59
Step 4: Share & Evaluate

The Plan with Your Team When the Gantt chart is complete, distribute it to team
members for review and feedback. It's important that each member of the project buys off on
the plan upfront. This helps to ensure that the plan is accurate and reasonable. It's much easier
to allow for contingencies, plan additional resources, or even propose a revised schedule at
this stage, rather than at a critical juncture later.

Conclusion:

Use timeline Charts or Gantt Charts to track progress of the assigned project was
drawn successfully.

60
61