EX.

NO: 1 Write a Problem Statement to define a title of the project with

DATE: bounded scope of project

AIM:
To prepare Problem Statement for any project.

REQUIREMENTS:

Hardware Interfaces
Pentium(R) 4 CPU 2.26 GHz, 128 MB RAM Screen resolution of at least 800 x 600 required for
proper and complete viewing of screens. Higher resolution would not be a problem.

 D ROM Driver Software Interfaces

 Any window-based operating system (Windows 95/98/2000/XP/NT)
 WordPad or Microsoft Word

THEORY:
The problem statement is the initial starting point for a project. It is basically a one to three page
statement that everyone on the project agrees with that describes what will be done at a high
level.

 The problem statement is intended for a broad audience and should be written in non-
technical terms.
 It helps the non-technical and technical personnel communicate by providing a
description of a problem. It doesn't describe the solution to the problem.
 The input to requirement engineering is the problem statement prepared by customer. It
may give an overview of the existing system along with broad expectations from the new
system.
 The first phase of requirements engineering begins with requirements elicitation i.e.
gathering of information about requirements.
 Here, requirements are identified with the help of customer and existing system
processes.
 So from here begins the preparation of problem statement. So, basically a problem
statement describes what needs to be done without describing how.
EX.NO: 2 Select relevant process model to define activities and related task set
DATE: for assigned project

AIM:
To select relevant process model to define activities and related task set for assigned project.

Software Process
The software process comprises activities performed to create a software product. It deals with
the technical and management aspects of software development.

Software process includes:

Tasks – focus on a small, specific objective.

Action – set of tasks that produce a major work product.
Activities – group of related tasks and actions for a major objective.
A process framework for software engineering defines five framework activities.
Framework activities include communication, planning, modelling, construction and
deployment.
Each framework activity includes a set of engineering actions and each action defines a
set of tasks that incorporates work products, project milestones and software quality
assurance (SQA) points that are required.
Umbrella activities are carried throughout the process.

Process Framework Activities:

Communication – Communicate with stakeholders and customers to obtain objectives
of the system and requirements for the software.
Planning – Software project plan has details of resources needed, tasks and risk factors
likely to occur, schedule.
Modelling – Architectural models and design to better understand the problem and for
work towards the best solution.
Construction – Generation of code and testing of the system to rectify errors and
ensuring all specified requirements are met.
Deployment – Entire software product or partially completed product is delivered to the
customer for evaluation and feedback.

Umbrella activities:
Activities that occur throughout a software process for better management and tracking of the
project.
EX.NO: 3 Prepare broad SRS (Software Requirement Specification) for the
DATE : above selected projects
AIM:
To prepare broad SRS (Software Requirement Specification) for the above selected projects.

Requirements:
Hardware Requirements:
 PC with 300 megahertz or higher processor clock speed recommended; 233 MHz
minimum required.
 128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported)
 1.5 gigabytes (GB) of available hard disk space
 CD ROM or DVD Drive
 Keyboard and Mouse (compatible pointing device).

Software Requirements:
Rational Rose, Windows XP, 7, 8, 10

Theory:
1. An SRS is basically an organization's understanding (in writing) of a customer or
potential client's system requirements and dependencies at a particular point in time (usually)
prior to any actual design or development work.
2. It's a two-way insurance policy that assures that both the client and the organization
understand the other's requirements from that perspective at a given point in time.
3. The SRS document itself states in precise and explicit language those functions and
capabilities a software system (i.e., a software application, an ecommerce Web site, and so on)
must provide, as well as states any required constraints by which the system must abide.
4. The SRS also functions as a blueprint for completing a project with as little cost
growth as possible.
5. The SRS is often referred to as the "parent" document because all subsequent project
management documents, such as design specifications, statements of work, software architecture
specifications, testing and validation plans, and documentation plans, are related to it.
6. It's important to note that an SRS contains functional and nonfunctional requirements
only; it doesn't offer design suggestions, possible solutions to technology or business issues, or
any other information other than what the development team understands the customer's system
requirements to be.
A well-designed, well-written SRS accomplishes four major goals:
EX.NO: 4 Prepare USE Cases and Draw Use Case Diagram using modelling
DATE : Tool

AIM:
To Prepare USE Cases and Draw Use Case Diagram using modelling Tool

Use Case Diagram:

Use Case Diagram captures the system’s functionality and requirements by using actors
and use cases.
Use Cases model the services, tasks, function that a system needs to perform.
Use cases represent high-level functionalities and how a user will handle the system.
Use-cases are the core concepts of Unified Modelling language modeling.

Why Use-Case diagram?

A Use Case consists of use cases, persons, or various things that are invoking the
features called as actors and the elements that are responsible for implementing the use
cases.
Use case diagrams capture the dynamic behavior of a live system. It models how an
external entity interacts with the system to make it work.
Use case diagrams are responsible for visualizing the external things that interact with
the part of the system.

Following object-oriented concepts are required to begin with UML:

Object: It is a real-world entity. There are multiple objects available within a single
system. It is a fundamental building block of UML.
Class: A class is nothing but a container where objects and their relationships are
maintained.
Abstraction: It is a mechanism of representing an entity without showing the
implementation details. It is used to visualize the behavior of an object.
Inheritance: It is a mechanism of extending an existing class to create a new class.
Polymorphism: It is a mechanism of representing an object having multiple forms
which are used for different purposes.
Encapsulation: It is a method of binding the object and the data together as a single
unit. It ensures tight coupling between the object and the data.

Use-case diagram notations

Following are the common notations used in a use case diagram:
EX.NO: 5 Develop the activity diagram to represent flow from one activity to
DATE : another for software development

AIM:
To develop the activity diagram to represent flow from one activity to another for software
development.

Activity Diagram
 Activity Diagram is basically a flowchart to represent the flow from one activity to
another activity.
 The activity can be described as an operation of the system.
 The basic purpose of activity diagrams is to capture the dynamic behavior of the system.
 It is also called object-oriented flowchart.
 This UML diagram focuses on the execution and flow of the behavior of a system
instead of implementation.

Components of Activity Diagram

Activities
It is a behavior that is divided into one or more actions.
Activities are a network of nodes connected by edges.
There can be action nodes, control nodes, or object nodes.
Action nodes represent some action.
Control nodes represent the control flow of an activity.
Object nodes are used to describe objects used inside an activity.
Edges are used to show a path or a flow of execution.
Activities start at an initial node and terminate at a final node.

Activity partition/swim lane

An activity partition or a swim lane is a high-level grouping of a set of related actions.
A single partition can refer to many things, such as classes, use cases, components, or
interfaces.
If a partition cannot be shown clearly, then the name of a partition is written on top of
the name of an activity.

Fork and Join nodes

Using a fork and join nodes, concurrent flows within an activity can be generated.
A fork node has one incoming edge and numerous outgoing edges.
It is similar to one too many decision parameters
EX.NO: 6 Develop data Designs using DFD Decision Table & ER Diagram.

DATE:
AIM:
To develop data Designs using DFD Decision Table & ER Diagram.

Practical Significance
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.

Practical Skills:
Deeper understanding of System modeling:
 Data model: entity-relationship diagram (ERD).
 Functional model: data flow diagram (DFD).
 Decision Table

Minimum Theoretical Background

A data flow diagram shows the way information flows through a process or system.
It includes data inputs and outputs, data stores, and the various sub processes the data
moves through.
DFDs are built using standardized symbols and notation to describe various entities and
their relationships. Decision tables are very much helpful in test design technique – it
helps testers to search the effects of combinations of different inputs and other software
states that must correctly implement business rules.
A decision table is basically an outstanding technique used in both testing and
requirements management.
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities”
such as people, objects or concepts relate to each other within a system.

Procedure
1. Select Diagram > New from the application toolbar.
2. In the New Diagram window, select Data Flow Diagram.
3. Click Next.
4. Enter the diagram name and description. The Location field enables you to select a model to
store the diagram.
5. Click OK
EX.NO: 7 Draw class diagram, sequence diagram, Collaboration Diagram,
DATE: State Transition Diagram for the assigned project

AIM:
To draw class diagram, sequence diagram, Collaboration Diagram, State Transition Diagram for
the assigned project.

Practical Significance
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system.
Sequence diagrams describe how and in what order the objects in a system function.
Collaboration diagrams are used to describe the structural organization of the objects
taking part in the interaction.
In state transition diagram we represent that what actions are leads to change the state of
the object. Behavioral diagrams basically capture the dynamic aspect of a system.
Dynamic aspect can be further described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams

Use case diagram
Sequence diagram
Collaboration diagram
State chart diagram

Activity diagram Procedure:

Select Diagram > New from the application toolbar.
In the New Diagram window, select the Diagram.
Click Next.
Enter the diagram name and description.
The Location field enables you to select a model to store the diagram.
Click OK.
 Class diagrams describe the static structure of a system or how it is
structured rather than how it behaves.
 These diagrams contain the following element with their symbol.

Class
 It represents entity with common characteristics or features. These features can include
attributes, operations and associations.
EX.NO: 8 Write Test Cases to Validate requirements of assigned project from
DATE: SRS Document

AIM:
To Write Test Cases to validate requirements of assigned project from SRS Document.

Requirements:

Hardware Requirements:
 PC with 300 megahertz or higher processor clock speed recommended; 233 MHz
minimum required.
 128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported)
 1.5 gigabytes (GB) of available hard disk space
 CD ROM or DVD Drive
 Keyboard and Mouse (compatible pointing device).

Software Requirements:
Rational Rose, Windows XP, 7, 8, 10

Theory:
1. An SRS is basically an organization's understanding (in writing) of a customer or potential
client's system requirements and dependencies at a particular point in time (usually) prior to any
actual design or development work.
2. It's a two-way insurance policy that assures that both the client and the organization
understand the other's requirements from that perspective at a given point in time.
3. The SRS document itself states in precise and explicit language those functions and
capabilities a software system (i.e., a software application, an ecommerce Web site, and so on)
must provide, as well as states any required constraints by which the system must abide.
4. The SRS also functions as a blueprint for completing a project with as little cost growth as
possible.
5. The SRS is often referred to as the "parent" document because all subsequent project
management documents, such as design specifications, statements of work, software architecture
specifications, testing and validation plans, and documentation plans, are related to it.

6. It's important to note that an SRS contains functional and nonfunctional requirements only; it
doesn't offer design suggestions, possible solutions to technology or business issues, or any other
information other than what the development team understands the customer's system
requirements to be.
EX.NO: 9 Evaluate Size of the project using function point metric for the
DATE: assigned project

AIM:
To Evaluate Size of the project using function point metric for the assigned project.

Objective:
Calculating effort for Attendance Management System using Function Point oriented estimation
model. It is a method to break systems into smaller components, so they can be better understood
and analyzed. It is used to express the amount of business functionality, an information system
(as a product) provides to a user. Fps measure software size. They are widely accepted as an
industry standard for functional sizing. Function points are used to compute a functional size
measurement (FSM) of software. The cost (in dollars or hours) of a single unit is calculated from
past projects. Function Point Analysis can provide a mechanism to track and monitor scope
creep. Function Point Counts at the end of requirements, analysis, design, code, testing and
implementation can be compared. The function point count at the end of requirementsand/or
designs can be compared to function points actually delivered. The amount of growth is an
indication of how well requirements were gathered by and/or communicated to the project team.
If the amount of growth of projects declines over time it is a natural assumption that
communication with the user has improved.

Overview
Function-oriented software metrics use a measure of the functionality delivered by the
application as a normalization value. Since ‘functionality cannot be measured directly, it must be
derived indirectly using other direct measures. Function-oriented metrics were first proposed by
Albrecht, who suggested a measure called the function point. Function points are derived using
anempirical relationship based on countable (direct) measures of software's information domain
andassessments of software complexity. Function points are computed by completing the table as
shown below. Five information domain characteristics are
EX.NO: 10 Estimate cost of the project using COCOMO and COCOCMOII
DATE: for the assigned project

AIM:

To Estimate cost of the project using COCOMO and COCOCMOII for the assigned project.

Practical Significance:

COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines
of Code. It is a procedural cost estimate model for software projects and often used as a process
of reliably predicting the various parameters associated with making a project such as size,
effort, cost,time and quality. It was proposed by Barry Boehm in 1970 and is based on the study
of 63 projects, which make it one of the best-documented models.

According to Boehm, software cost estimation should be done through three stages: Basic
COCOMO, Intermediate COCOMO, and Complete COCOMO. Each of the models initially
estimates efforts based on the total estimated KLOC.

Minimum Theoretical Background

There are also different "flavors" of COCOMO in use for business estimates. For example, in a
model known as "detailed COCOMO," a step-by-step process includes attention to planning and
requirements, system design, detail design, module code and testing, integration and testing, and
estimation. Ingeneral, COCOMO provides a helpful framework to try to determine the cost and
scope of a software project.

The key parameters which define the quality of any software products, which are also anoutcome
of the Cocomo are primarily Effort & Schedule
EX.NO: 11 Use CPM/PERT for scheduling the assigned project
DATE:

AIM:
To Use CPM/PERT for scheduling the assigned project.

CPM / PERT Techniques

The methods are essentially network-oriented techniques using the same principle. PERT and
CPM are basically time-oriented methods in the sense that they both lead to determination of a
time schedule for the project. The significant difference between two approaches is that the time
estimates for the different activities in CPM were assumed to be deterministic while in PERT
these are described probabilistically. These techniques are referred as project scheduling
techniques.

In CPM activities are shown as a network of precedence relationships using activity-on- node
network construction

– Single estimate of activity time

– Deterministic activity times

USED IN: Production management - for the jobs of repetitive in nature where the activity
time estimates can be predicted with considerable certainty due to the existence of past
experience.

In PERT activities are shown as a network of precedence relationships using activity-on-arrow

network construction

– Multiple time estimates

– Probabilistic activity times

USED IN: Project management - for non-repetitive jobs (research and development work),
where the time and cost estimates tend to be quite uncertain. This technique uses probabilistic
EX.NO: 12 Use timeline Charts or Gantt Charts to track progress of the
DATE: assigned project

AIM:

To Use timeline Charts or Gantt Charts to track progress of the assigned project.

Practical Significance

Gantt charts are widely used in business to describe and monitor all kinds of projects according
to the rules of project management. Different Gantt applications have different features and
capabilities.

Theoretical Background

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.