DEPARTMENT OF : COMPUTER SCIENCE AND ENGINEEIRNG

LAB :

NAME :

BRANCH :

YEAR / SEC :

H.T.No. :

Certified that this is the bonafide record of Practical Work

done in the laboratory by the candidate
……………………………………………………
during the year ……………………
No. of Experiments Conducted: No. of Experiments Attended:

Signature Lab in-charge Signature Head of the Department

Submitted for the practical examination held on ………………………………….

Internal External
 Signature
S. Page Marks /
Date Name of the Experiment of the
No No Garde
Faculty

Do the Requirement Analysis and

1
Prepare SRS

2 Using COCOMO model estimate effort.

Calculate effort using FP oriented

3
estimation model.

Analyze the Risk related to the project

4
and prepare RMMM plan.

Develop Time-line chart and project

5 table using PERT or CPM project
scheduling methods

Draw E-R diagrams, DFD, CFD and

6
structured charts for the project.

Design of Test cases based on

7
requirements and design.

8 Prepare FTR

Prepare Version control and change

9
control for software configuration items.

10
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 1

SOFTWARE REQUIREMENT SPECIFICATION FOR

ATTENDNACE MANAGEMENT SYSTEM

1. INTRODUCTION
1.1 Purpose
The purpose of developing attendance management system is to computerized the tradition
way of taking attendance. Another purpose for developing this software is to generate the
report automatically at the end of the session or in the between of the session. This
document detailed functional and non-functional requirements for attendance maintenance
system. The purpose of this document is that the requirements mentioned in it should be
utilized by software developer to implement the system.

1.2 Scope
This system allows the teacher to maintain attendance record of the classes to which it is
teaching. With the help of this system Teacher should be in a position to send e-mail to the
students who remain absent for the class. The system provides a cumulative report at every
month end for the corresponding class.

1.3 Overview
This system provides an easy solution to the teacher to keep track of student attendance,
and statistics

2. General Description
This attendance maintenance system replaces the traditional, manual attendance system by
which a lot of paper work will be reduced. The teacher should able to view photograph of
student along with his attendance in his laptop. This is the primary feature of this system.

Another feature is that Teacher can be allowed to edit particular record at desired time. The
system should produce monthly attendance report. And there should be facility to send an
e-mail/warning to the student remaining absent in the class. Every Teacher should have

SE Lab Manual 1
SASI Institute of Technology & Engineering CSE Department

laptop with wireless internet connection. A teacher may teach to different classes and a
separate record for the corresponding classes should be maintained.

2.1 User manual

The system should provide Help option in which how to operate the system should be
explained. Also hard copy of this document should be given to the user in a booklet form.

3. Functional Requirements
The identity of student is verified and then marked present at particular date and time. The
system should display student photograph along with their names for the corresponding
class. The student may be marked present or absent students. A statistical report should
display individuals report or a cumulative report whenever required.

3.1 Description
The identity of student is verified and then marked present at particular date and time. The
system should display student photograph along with their names for that corresponding
class. The student may be marked present or absent depending upon his display individuals
report or a cumulative report whenever requirement.

3.2 Technical Issues

The system should be implemented in VC++.

4. Interface Requirements
4.1 GUI
GUI 1: Main menu should provide option such as File, Edit, Report, help.
GUI 2: In File menu one can create a new record file or can open an existing record file..
GUI 3: The display of record
GUI 4: Report option should display statistical report. It may be particular student or for
the whole class.
GUI 5: Help option should describe functionality of the system. It should be written in
simple HTML.

4.2 Hardware Interface

Hardware Interface 1: The system should be embedded in the laptops.
Hardware Interface 2: The laptop should use wireless Ethernet Card to send departmental
database server.

4.3 Software Interface:

Software Interface 1: Attendance maintenance system.
Software Interface 2: The attendance database should be transmitted to departmental
database server.
Software Interface 3: E-mail message generator which generates standard message of
absence.
Software Interface 4: Report generators.

SE Lab Manual 2
SASI Institute of Technology & Engineering CSE Department

5. Performance Requirements
• This system should work concurrently on multiple processors between college
hours. The
system should support 50 users.
• The email should be sent within one hour after class gets over.
• The system should support taking attendance of maximum 10 students per class.
6. Design Constraints
The system should be designed within 6 months.

7.Other Non-Functional Attributes

7.1 Security - The teacher should provide password to log on to the system. He/she
should be able to see
the record of his/her class.
7.2 Reliability - Due to wireless connectivity, reliability cannot be guaranteed.
7.3 Availability - The system should be available during college hours.
7.4 Maintainability - There should be a facility to add or delete or update teachers and
students for each
semester
7.5 Reusability - There should be a facility to add or delete or update teachers and
students for each
semester.

8. Operational Scenarios:
There will be student database, teacher database. The student database will contain students
name, class, attendance, email address, address, and phone number. The teacher database
will contain teachers name, class taught, e-mail address, phone number.

9. Preliminary Schedule
The system has to be implemented within 6 months.

SE Lab Manual 3
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 4
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 2

CONSTRUCTIVE COST ESTIMATION MODEL (COCOMO)

Estimate effort by using COCOMO model.

Objective
To estimate effort for developing Attendance Management System project using
COCOMO model. The COCOMO model reflects your software development
environment and produces more accurate estimates. It computes software development
effort(cost) as a function of program size expressed in estimated lines of code (LOC).
The main objective of basic COCOMO model gives an approximate estimate of the
project parameters. Several COCOMO packages allow the user to estimate the tasks
outside the scope using a percentage of the estimated software development effort.

Overview
The Constructive Cost Model (COCOMO) is an algorithmic software cost
estimation model developed by Barry W. Boehm. Boehm postulated that any software
development project can be classified into one of thefollowing three categories based on
the development complexity: organic, semidetached, and embedded. In order to classify
a product into the identified categories, Boehm not only considered the characteristics of
the product but also those of the development team and development environment.
Roughly speaking, these three product classes correspond to application, utility and
system programs, respectively. Normally, data processing programs are considered to be
application programs. Compilers, linkers, etc., are utility programs. Operating systems
and real- time system programs, etc. are system programs. System programs interact
directly with the hardware and typically involve meeting timing constraints and
concurrent processing.

Organic:
A development project can be considered of organic type, if the project deals with
developing a well understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar types of
projects.

Semi-detached:
A development project can be considered of semidetached type, if the
development consists of a mixture of experienced and inexperienced staff. Team members
may have limited experience on related systems but may be unfamiliar with some aspects
of the system being developed.

SE Lab Manual 5
SASI Institute of Technology & Engineering CSE Department

Embedded:
A development project is considered to be of embedded type, if the software being
developed is strongly coupled to complex hardware, or if the stringent regulations on the
operational procedures exist.
The COCOMO cost estimation model is used by thousands of software project
managers, and is based on a study of hundreds of software projects. Unlike other cost
estimation models, COCOMO is an open model, so all of the details are published,
including:
• The underlying cost estimation equations
• Every assumption made in the model (e.g. "the project will enjoy good
management")
• Every definition (e.g. the precise definition of the Product Design phase of a
project)
• The costs included in an estimate are explicitly stated (e.g. project managers are
included,secretaries aren't)

Procedure
COCOMO consists of a hierarchy of three increasingly detailed and accurate forms.
1. The first level, Basic COCOMO is good for quick, early, rough order of magnitude
estimates of software costs, but its accuracy is limited due to its lack of factors to
account for difference in project attributes (Cost Drivers).
2. Intermediate COCOMO takes these Cost Drivers into account and Detailed
COCOMO additionally accounts for the influence of individual project phases.
3. The Constructive Cost Model (COCOMO) is an algorithmic software cost
estimation model developed by Barry Boehm. The model uses a basic regression
formula, with parameters that are derived from historical project data and current
project characteristics.

The basic COCOMO model gives an approximate estimate of the project parameters. The
basic COCOMO estimation model is given by the following expressions:
Effort = a1х (KLOC)^a2 pm
Tdev = b1x (Effort)^b2 Months
P= Effort/ Tdev
Where
• KLOC is the estimated size of the software product expressed in Kilo Lines of
Code.
• P is the number of persons required to complete the work.
• a1, a2, b1, b2 are constants for each category of software products.
• Tdev is the estimated time to develop the software, expressed in months.
• Effort is the total effort required to develop the software product, expressed in

SE Lab Manual 6
SASI Institute of Technology & Engineering CSE Department

person-months (PMs).
The coefficients a1, a2, b1, b2 for various types of software projects

Software
a1 a2 b1 b2
Projects
Organic 2.4 1.05 2.5 0.35
Semi-detached 3.0 1.12 2.5 0.32
Embedded 3.6 1.20 2.5 0.38

Estimation of development effort: - for the three classes of software products, the
formulas for estimating the effort based on the code size are shown below:
Organic : Effort = 2.4(KLOC)^1.05PM
Semi-detached : Effort = 3.0(KLOC)^1.12PM
Embedded : Effort = 3.6(KLOC)^1.20PM
For the three classes of software products, the formulas for estimating the development
time based on the effort are given below:
Organic : Tdev = 2.5(Effort)^0.38Months
Semidetached : Tdev = 2.5(Effort)^0.35Months
Embedded : Tdev = 2.5(Effort)^0.32Months.

The Intermediate COCOMO

Effort (E) = a1х (KLOC)^a2 x EAF pm
Scheduled Time (D) = b1x (Effort)^b2 m

Where,
E = Total effort required for the project in Person-Months (pm).
D = Total time required for project development in Months (M).
KLOC = The size of the code for the project in Kilo lines of code.
a, b, c, d = The constant parameters for the software project.
EAF = It is an Effort Adjustment Factor, which is calculated by multiplying the
parameter values of different cost driver parameters. For ideal, the value is 1.

OST DRIVERS VERY VERY

LOW NOMINAL HIGH
PARAMETERS LOW HIGH
Product Parameter
Required Software 0.75 0.88 1 1.15 1.4
Size of Project Database NA 0.94 1.08 1.16
Complexity of The 0.7 0.85 1.15 1.3
Project
Hardware Parameter
Performance Restriction NA NA 1 1.11 1.3
Memory Restriction NA NA 1.06 1.21
virtual Machine NA 0.87 1.15 1.3
Environment

SE Lab Manual 7
SASI Institute of Technology & Engineering CSE Department

OST DRIVERS VERY VERY

LOW NOMINAL HIGH
PARAMETERS LOW HIGH
Required Turnabout Time NA 0.94 1.07 1.15
Personnel Parameter
Analysis Capability 1.46 1.19 1 0.86 0.71
Application Experience 1.29 1.13 0.91 0.82
Software Engineer 1.42 1.17 0.86 0.7
Capability
Virtual Machine 1.21 1.1 0.9 NA
Experience
Programming Experience 1.14 1.07 0.95 NA
Project Parameter
Software Engineering 1.24 1.1 1 0.91 0.82
Methods
Use of Software Tools 1.24 1.1 0.91 0.83
Development Time 1.23 1.08 1.04 1.1

SE Lab Manual 8
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 9
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 10
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 3

FP (Function Point) ORIENTED ESTIMATION MODEL

Calculating effort for Attendance Management System using FP

oriented model.

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 requirements and/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 an empirical 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 determined and counts are provided in the appropriate table location. Information
domain values are defined in the following manner:

SE Lab Manual 11
SASI Institute of Technology & Engineering CSE Department

Number of user inputs: Each user input that provides distinct application-oriented data to
the software is counted. Inputs should be distinguished from inquiries, which are counted
separately.
Number of user outputs: Each user output that provides application-oriented information
to the user is counted. In this context output refers to reports, screens, error messages, etc.
Individual data items within a report are not counted separately.
Number of user inquiries: An inquiry is defined as an on-line input that results in the
generation of some immediate software response in the form of an on-line output. Each
distinct inquiry is counted.
Number of files: Each logical master file (i.e., a logical grouping of data that may be one
part of a large database or a separate file) is counted.
Number of external interfaces: All machine-readable interfaces (e.g., data files on
storage media) that are used to transmit information to another system are counted. Once
these data have been collected, a complexity value is associated with each count.
Organizations that use function point methods develop criteria for determining whether a
particular entry is simple, average, or complex. Nonetheless, the determination of
complexity is somewhat subjective.

Procedure: FPA provides different estimation mechanism within it for development and
maintenance projects. (Having different multiplication factors). This approach computes
the total function points (FP) value for the project, by totaling the number of external user
inputs, inquiries, outputs, and master files, and then applying the following weights: inputs
, outputs , inquiries, and master files.

Advantages:
1. This method is independent of programming languages.
2. It is based on the data which can be obtained in early stage of project
3. Function Points are easily understood by the non-technical user. This helps
communicate sizing information to a user or customer.

Disadvantages:
1. This method is more suitable for Business systems and can be developed for that
domain
2. Many aspects of this method are not validated
3. The functional point has no significant ant meaning, it’s just a numerical value.

FP POINTS COMPUTATION
To compute function points (FP), the following relationship is used:
• FP = count total [0.65 + 0.01 Σ ( Fi )]
• where count total is the sum of all FP entries.
• The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the
following questions:
1. Does the system require reliable backup and recovery?

SE Lab Manual 12
SASI Institute of Technology & Engineering CSE Department

2. Are data communications required?

3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?

Each of these questions is answered using a scale that ranges from 0 (not important or
applicable) to 5 (absolutely essential). The constant values in Equation and the weighting
factors that are applied to information domain counts are determined empirically.
Once function points have been calculated, they are used in a manner analogous to LOC as
a way to normalize measures for software productivity, quality, and other attributes:

Errors per FP.

Productivity = FP/ Person-Month
Quality = No of faults / FP
Cost = $/FP
Documentation = Pages count / FP.
Effort = FP/ Person-Month

Count Total can be obtained using the following table

Weighting factor
Domain characteristics Count Count
Simple Average Complex
No of user input * 3 4 6
No of user output * 4 5 7
No of user queries * 3 4 6
No of files * 7 10 15
No of external interfaces * 5 7 10
Count total:

SE Lab Manual 13
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 14
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 15
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 4

RMMM (RISK MITIGATION, MONITORING AND

MANAGEMENT) PLAN

Analyze the risk which is related to the project and prepare RMMM
plan.

Objective
Risk Mitigation is a problem avoidance activity, Risk Monitoring is a project tracking
activity, Risk Management includes contingency plans that risk will occur. The goal of the
risk mitigation, monitoring and management plan is to identify as many potential risks as
possible. Risk is a potential problem it might happen, it might not. To determine the
potential risks checklists are used. These checklists help to identify potential risks in a
generic sense. The project will then be analyzed to determine any project-specific risks.
When all risks have been identified, they will then be evaluated to determine their
probability of occurrence. Plans will then be made to avoid each risk, to track each risk to
determine if it is more or less likely to occur, and to plan for those risks should they occur.
The primary objective of risk mitigation can be achieved by developing a plan. The
objectives of monitoring are to assess whether predicted risks do/in-fact occur, to ensure
that risk aversion steps defined for the risk are being properly applied, to collect
information that can be used for future risk analysis.

Overview
The proactive management of risks throughout the software development life-cycle is
important for project success. The risk management practice, which involves risk
identification, analysis, prioritization, planning, mitigation, monitoring, and
communication ..Software development risks that seem to reoccur in educational and
industrial projects .A risk-driven process for selecting a software development model. Risk
in itself is not bad; risk is essential to progress, and failure is often a key part of learning.
But we must learn to balance the possible negative consequences of risk against the
potential benefits of its associated opportunity. A risk is a potential future harm that may
arise from some present action such as, a schedule slip or a cost overrun. The loss is often
considered in terms of direct financial loss, but also can be a loss in terms of credibility,
future business, and loss of property or life.

The Risk Management

The risk management process can be broken down into two interrelated phases, risk
assessment and risk control, as outlined in Figure 1. These phases are further broken down.
Risk assessment involves risk identification, risk analysis, and risk prioritization. Risk
control involves risk planning, risk mitigation, and risk monitoring. It is essential that risk
management be done iteratively, throughout the project, as a part of the team’s project
management routine.

SE Lab Manual 16
SASI Institute of Technology & Engineering CSE Department

Risk Identification

In the risk identification step, the team systematically enumerates as many project risks as
possible to make them explicit before they become problems. There are several ways to
look at the kinds of software project risks, as shown in Table 1. It is helpful to understand
the different types of risk so that a team can explore the possibilities of each of them. Each
of these types of risk is described below

Generic risks are potential threats to every software project. Some examples of generic
risks are changing requirements, losing key personnel, or bankruptcy of the software
company or of the customer. It is advisable for a development organization to keep a
checklist of these types of risks. Teams can then assess the extent to which these risks are
a factor for their project based upon the known set of programmers, managers, customers,
Identify Analyze Prioritize Plan (Top) Mitigate (Top) Monitor Risk Management and
policies. There are some specific factors to consider when examining project, product, and
business risks. Some examples of these factors are listed here, although this list is meant to
stimulate yourthinking rather than to be an all-inclusive list.

Types of Risks Involved

1. People risks are associated with the availability, skill level, and retention of the people
on the development team.
2. Size risks are associated with the magnitude of the product and the product team.

SE Lab Manual 17
SASI Institute of Technology & Engineering CSE Department

Larger products are generally more complex with more interactions. Larger teams are
harder to coordinate.
3. Process risks are related to whether the team uses a defined, appropriate software
development process and to whether the team members actually follow the process.
4. Technology risks are derived from the software or hardware technologies that are
being used as part of the system being developed. Using new or emerging or complex
technology increases the overall risk.
5. Tools risks, similar to technology risks, relate to the use, availability, and reliability
of support software used by the development team, such as development environments
and other Computer-Aided Software Engineering (CASE) tools.
6. Organizational and managerial risks are derived from the environment where the
software is being developed. Some examples are the financial stability of the company
and threats of company reorganization and the potential of the resultant loss of support
by management due to a change in focus or a change in people.
7. Customer risks are derived from changes to the customer requirements, customers’
lack of understanding of the impact of these changes, the process of managing these
requirements changes, and the ability of the customer to communicate effectively with
the team and to accurately convey the attributes of the desired product.
8. Estimation risks are derived from inaccuracies in estimating the resources and the
time required to build the product properly.
9. Sales and support risks involve the chances that the team builds a product that the
sales force does not understand how to sell or that is difficult to correct, adapt, or
enhance.

Procedure
Risk Mitigation
Related to risk planning, through risk mitigation, the team develops strategies to reduce the
possibility or the loss impact of a risk. Risk mitigation produces a situation in which the
risk items are eliminated or otherwise resolved.
Risk avoidance: When a lose-lose strategy is likely, the team can opt to eliminate the risk
is an example of a risk avoidance strategy is the team opting not to develop a product or a
particularly risky feature.
Risk protection: The organization can buy insurance to cover any financial loss should
the risk become a reality. Alternately, a team can employ fault tolerance strategies, such as
parallel processors, to provide reliability insurance. Risk planning and risk mitigation
actions often come with an associated cost. The team must do a cost/benefit analysis to
decide whether the benefits accrued by the risk management steps outweigh the costs
associated with implementing them. This calculation can involve the calculation of risk
leverage.

Risk Leverage = (risk exposure before reduction – risk exposure after reduction) /
cost of risk reduction

If risk leverage value, rl, is ≤1, clearly the benefit of applying risk reduction is not worth
its cost. If rl is only slightly > 1, still the benefit is very questionable, because these
computations are based on probabilistic estimates and not on actual data. Therefore, rl is

SE Lab Manual 18
SASI Institute of Technology & Engineering CSE Department

usually multiplied by a risk discount factor ρ< 1. If ρ rl > 1, then the benefit of applying
risk reduction is considered worth its cost. If the discounted leveraged valued is not high
enough to justify the action, the team should look for other, less costly or more effective,
reduction techniques.

Risk Monitoring:
After risks are identified, analyzed, and prioritized, and actions are established, it is
essentialthat the team regularly monitor the progress of the product and the resolution of
the risk items, taking corrective action when necessary. This monitoring can be done as
part of the team project management activities or via explicit risk management activities.
Often teams regularly monitor their “Top 10 risks.” Risks need to be revisited at regular
intervals for the team to reevaluate each risk to determine when new circumstances caused
its probability and/or impact to change. At each interval, some risks may be added to the
list and others taken away. Risks need to be reprioritized to see which are moved “above
the line” and need to have action plans and which move “below the line” and no longer
need action plans. A key to successful risk management is that proactive actions are
owned by individuals and are monitored.

RMMM Plan

Risk Information Sheet

Risk ID: Date: Probability: Impact:
Description:

Refinement / Context:

Mitigation / Monitoring:

Management / Contingency Plan / Trigger:

Current Status:

Originator: Assigned:

SE Lab Manual 19
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 20
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 21
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 5

PERT & CPM

Program Evaluation and Review Technique & Critical Path Method

Objective
PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are
two of the most widely used techniques for planning and coordinating large-scale projects.
Although PERT and CPM were developed independently, they have a great deal in
common. PERT is a statistical tool, used in project management, which was designed to
analyze and represent the tasks involved in completing a given project. It is commonly
used in conjunction with the critical path method(CPM).It is applied as a decision-making
tool designed to save time in achieving end- objectives, and is of particular interest to
those engaged in research and development programs for which time is a critical factor.

The main objective of PERT is:

1. To facilitate decision-making
2. To reduce both the time and cost required to complete a project.

PERT: The emphasis was on completing the program in the shortest possible time.
CPM: The emphasis was on the trade-off between the cost of the projects and its overall
completion time.

Overview
The program evaluation and review technique (PERT) chart is used to schedule,
organize, and coordinate tasks within the project. The objective of PERT chart is to
determine the critical path, which comprises critical activities that should be completed
on schedule. This chart is prepared with the help of information generated in project
planning activities, such as estimation effort, selection of suitable process model for
software development, and decomposition of tasks into subtasks. The advantages of using
PERT chart are:

1. It represents the project in graphical form.

2. It provides information about the expected completion time of the project.
3. It describes the probability of completion of project before the specified date.
4. It specifies the activities that from the critical path.
5. It specifies the start and end dates of activities involved in project.
6. It describes the dependencies of one or more tasks on each other.

Below figure shows example of PERT chart. The milestones are numbered as ‘1’, ‘2’, ‘3’,
‘4’, ‘5’ and are represented either by circles or rectangles. When a milestone is completed,
it is assigned a greater number than the milestones. Each milestone is linked with one or
more arrows. The activities of the projects are represented by ‘A’, ‘B’, ‘C’, ‘D’, E’,’F’.
The direction of arrows determines the sequence of activities. When activities are

SE Lab Manual 22
SASI Institute of Technology & Engineering CSE Department

completed in sequence, they are known as serial activities. When activities are completed
in sequence, they are known as serial activities. Here activities ‘A’,’C’, ‘F’ are performed
in a sequence. Similarly, activities ‘B’, ‘E’ are serial activities. On the other hand when
two or more are performed simultaneously, they are known as concurrent activities or
parallel activities. Here, activities ‘A’, ‘B’ and activities ‘C’, ‘D’ are performed
concurrently. Each activity is allocated a specific amount of time, which is depicted by
’t’. Here activity ‘A’ requires three week to get completed, activity ‘B’ requires for weeks,
and so on.

Steps for Creating Pert Chart

1. Identify activities and milestones: In this step, the activities and milestones that are
required to complete the project are described. Once the tasks and milestones are
specified, it is easy to understand the sequence and duration of each activity.
2. Identify sequence of activities: In this step, the sequence of activities is determined.
The sequence describes the dependency of one activity on another. These activities can
either be serial or concurrent. Based on the sequence and dependency of activities, the
relationships among activities are depicted. Not that this step is sometimes combined
with step1.
3. Prepare PERT chart: In this step, the PERT chart is prepared.
4. Estimate the time consumed in activities: In this step, the amount of time consumed
in carrying out each activity is specified. The time can be estimated in months, weeks,
or days.

Generally, the time estimates followed to determine the time consumed in

activities are:
(a.) Optimistic time : It is the shortest time in which activity can be completed.
(b.) Most likely time : It is the shortest time in which an activity can be
completed.
(c.) Pessimistic time : It is the longest time that an activity may require for
completion.

SE Lab Manual 23
SASI Institute of Technology & Engineering CSE Department

5. Determine critical path: In this step, the critical path for completion of activities is
specified. Critical path determines the calendar time required to complete a series of
activities according to the project schedule. Note that the speed-up or delays in
activities that are outside the critical path do not affect the total project time.
6. Update PERT chart: In this step, the PERT chart is modified as changes takes place
in the project and on completion of each activity. This chart is also updated when there
is delay in completion of activities or when additional resources are required to
complete the project on time.

CPM (Critical Path Method): Critical path method is a technique that determines those
activities, which have the least scheduling flexibility (that is, critical activities). Note that
if the critical activities are delayed, the entire project is delayed. After determining these
activities, CPM specifies the project schedule according to the activities that lie on the
critical path.
The advantages of using the critical path method are:
• It represents the project in graphical form
• It predicts the time required to complete form.
• It specifies how to speed up the project so that it is completed on schedule.
• It specifies the optimal plan for speeding up the project.

Procedure

STEPS FOR CREATING PERT CHART for ATTENDANCE MAINTENANCE

SYSTEM

1. Identify activities and milestones.

a. Specification of Requirements
b. Design Database
c. Design GUI
d. Code for Database
e. Code for GUI
f. Write user manual
g. Integrate and test
2. Identify sequence of activities
a. Specification-Design database-code database-Integrate and test
b. Specification-Design GUI-Code GUI-Integrate and test
c. Specification-Write user manual
d. The above-mentioned sequences can be performed simultaneously
3. Prepare PERT chart
4. Estimate the time consumed in activities.
Assumptions are made for various activities in days:
a. Specifications - 15 days
b. Design Database - 45 days
c. Design GUI - 30 days

SE Lab Manual 24
SASI Institute of Technology & Engineering CSE Department

d. Code for Database - 105 days

e. Code for GUI - 45 days
f. Write User Manual- 45 days
g. Integrate and Test - 120 days
5. Determine critical path
The longest path from start to finish in a PERT chart

Time-Line Chart:

Critical path: Specification-->Design database part-->code database part-->integrate and

test-->Finish

Project Table:

Tasks EST EFT LST LFT ST

Specification part 0 15 0 15 0
Design Database part 15 60 15 60 0
Design Database part 15 45 90 120 75
Code Database part 60 165 60 165 0
Code GUI part 45 90 120 165 75
Integrate and Test 165 285 165 285 0
Write User-Manual 15 75 225 285 210

SE Lab Manual 25
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 26
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 27
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 6

Draw E-R (Entity Relationship) Diagrams, DFD (Dataflow Diagrams), CFD

(Control Flow Diagrams) and structured charts for the project.

Aim:

Introduction:
Developing databases is a very important task to develop a system. Before going to form exact
database, tables and establishing relationships between them, we conceptually or logically can
model our database using ER diagrams. In this experiment we will learn how to find the entities,
its attributes and how the relationships between the entities can be established for a system.

Objectives:
After completing this experiment, you will be able to identify entity sets, their attributes, and
various relationships Represent the data model through ER diagram

Entity-Relationship model:
It is used to represent a logical design of a database to be created. In ER model, real world objects
(or concepts) are abstracted as entities, and different possible associations among them are
modelled as relationships. For example, student and school -- they are two entities. Students study
in school. So, these two entities are associated with a relationship "Studies in". As another
example, consider a system where some job runs every night, which updates the database. Here,
job and database could be two entities. They are associated with the relationship "Updates".

Entity Set and Relationship Set

An entity set is a collection of all similar entities. For example, "Student" is an entity set that
abstracts all students. Ram, John are specific entities belonging to this set. Similarly, a
"Relationship" set is a set of similar relationships.

Attributes of Entity
Attributes are the characteristics describing any entity belonging to an entity set. Any entity in a
set can be described by zero or more attributes. For example, any student has got a name, age, an
address. At any given time, a student can study only at one school. In the school he would have a
roll number, and of course a grade in which he studies. These data are the attributes of the entity
set Student.

Keys
One or more attribute(s) of an entity set can be used to define the following keys:

Super key: One or more attributes, which when taken together, helps to uniquely identify an
entity in an entity set. For example, a school can have any number of students. However, if we
know grade and roll number, then we can uniquely identify a student in that school.

SE Lab Manual 28
SASI Institute of Technology & Engineering CSE Department

Candidate key: It is a minimal subset of a super key. In other words, a super key might contain
extraneous attributes, which do not help in identifying an object uniquely. When such attributes
are removed, the key formed so is called a candidate key.

Primary key: A database might have more than one candidate key. Any candidate key chosen for
a particular implementation of the database is called a primary key.
Prime attribute: Any attribute taking part in a super key

Weak Entity
An entity set is said to be weak if it is dependent upon another entity set. A weak entity can't be
uniquely identified only by it's attributes. In other words, it doesn't have a super key.
For example, consider a company that allows employees to have travel allowance for their
immediate family. So, here we have two entity sets: employee and family, related by "Can claim
for". However, family doesn't have a super key. Existence of a family is entirely dependent on the
concerned employee. So, it is meaningful only with reference to employee.

Entity Generalization and Specialization

Once we have identified the entity sets, we might find some similarities among them. For example,
multiple persons interact with a banking system. Most of them are customers, and rest employees
or other service providers. Here, customers, employees are persons, but with certain
specializations. Or in other way, person is the generalized form of customer and employee entity
sets. ER model uses the "ISA" hierarchy to depict specialization (and thus, generalization).

Mapping Cardinalities
One of the main tasks of ER modeling is to associate different entity sets. Let's consider two entity
sets E1 and E2 associated by a relationship set R. Based on the number of entities in E1 and E2
are associated with, we can have the following four type of mappings:

1. One to one: An entity in E1 is related to at most a single entity in E2, and vice versa
2. One to many: An entity in E1 could be related to zero or more entities in E2. Any entity in
E2 could be related to at most a single entity in E1.
3. Many to one: Zero or more number of entities in E1 could be associated to a single entity in
E2. However, an entity in E2 could be related to at most one entity in E1.
4. Many to many: Any number of entities could be related to any number of entities in E2,
including zero, and vice versa.

ER Diagram
From a given problem statement we identify the possible entity sets, their attributes, and
relationships among different entity sets. Once we have this information, we represent them
pictorially, called an entity-relationship (ER) diagram.

SE Lab Manual 29
SASI Institute of Technology & Engineering CSE Department

Graphical Notations for ER Diagram:

Importance of ER modelling: The following figure shows the different steps involved in
implementation of a (relational) database

Figure: Steps to implement a RDBMS

Given a problem statement, the first step is to identify the entities, attributes and relationships. We
represent them using an ER diagram. Using this ER diagram, table structures are created, along
with required constraints. Finally, these tables are normalized in order to remove redundancy and
maintain data integrity. Thus, to have data stored efficiently, the ER diagram is to be drawn as
much detailed and accurate as possible.

SE Lab Manual 30
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 31
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 32
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 7

Design of Test cases based on requirements and design

Aim:

Objectives:
Development of new software, like any other product, remains incomplete until it subjected to
exhaustive tests. The primary objective of testing is not only to verify that all desired features have
been implemented correctly, but also includes the verification of the software behavior in case of
"bad inputs". In this experiment we discuss in brief about different types of testing, and provide
tools and mechanisms to have hands-on experience on unit testing.

Software Testing:
Testing software is an important part of the development life cycle of software. It is an expensive
activity. Hence, appropriate testing methods are necessary for ensuring the reliability of a
program. According to the ANSI/IEEE 1059 standard, the definition of testing is the process of
analyzing a software item, to detect the differences between existing and required conditions i.e.
defects/errors/bugs and to evaluate the features of the software item. The purpose of testing is to
verify and validate software and to find the defects present in software. The purpose of finding
those problems is to get them fixed. Verification is the checking or we can say the testing of
software for consistency and conformance by evaluating the results against pre-specified
requirements. Validation looks at the systems correctness, i.e. the process of checking that what
has been specified is what the user actually wanted. Defect is a variance between the expected and
actual result. The defect’s ultimate source may be traced to a fault introduced in the specification,
design, or development (coding) phases.

Test Cases and Test Suite

A test case describes input descriptions and an expected output descriptions. Input are of two
types: preconditions (circumstances that hold prior to test case execution) and the actual inputs
that are identified by some testing methods. The set of test cases is called a test suite. We may
have a test suite of all possible test cases.

Types of Software Testing

Testing is done in every stage of software development life cycle, but the testing done at each
level of software development is different in nature and has different objectives. There are
different types of testing, such as stress testing, volume testing, configuration testing,
compatibility testing, recovery testing, maintenance testing, documentation testing, and usability
testing. Software testing are mainly of following types.
• Unit Testing
• Integration Testing
• System Testing

SE Lab Manual 33
SASI Institute of Technology & Engineering CSE Department

Various Fields in a Test Case:

Test Case Field Description

Each test case should be represented by a unique ID. To

Test case ID: indicate test types follow some convention like “TC_UI_1”
indicating “User Interface Test Case#1.”
It is useful while executing the test.
• Low
Test Priority:
• Medium
• High
Determine the name of the main module or sub-module
Name of the Module:
being tested
Test Designed by: Tester’s Name
Date of test designed: Date when test was designed
Test Executed by: Who executed the test- tester
Date of the Test
Date when test needs to be executed
Execution:
Name or Test Title: Title of the test case
Description/ Summary
Determine the summary or test purpose in brief
of Test:
Any requirement that needs to be done before execution of
Pre-condition:
this test case. To execute this test case list all pre-conditions
Determine any dependencies on test requirements or other
Dependencies:
test cases
Mention all the test steps in detail and write in the order in
Test Steps: which it requires to be executed. While writing test steps
ensure that you provide as much detail as you can
Use of test data as an input for the test case. Deliver
Test Data:
different data sets with precise values to be used as an input
Mention the expected result including error or message that
Expected Results:
should appear on screen
What would be the state of the system after running the test
Post-Condition:
case?
Actual Result: After test execution, actual test result should be filled
Mark this field as failed, if actual result is not as per the
Status (Fail/Pass):
estimated result
If there are some special conditions which is left in above
Notes:
field

SE Lab Manual 34
SASI Institute of Technology & Engineering CSE Department

Optionally you can have the following fields depending on the project requirements
1. Link / Defect ID: Include the link for Defect or determine the defect number if test status
is fail
2. Keywords / Test Type: To determine tests based on test types this field can be used. Eg:
Usability, functional, business rules, etc.
3. Requirements: Requirements for which this test case is being written
4. References / Attachments: It is useful for complicated test scenarios, give the actual path
of the document or diagram
5. Automation (Yes/No): To track automation status when test cases are automated
6. Custom Fields: Fields particular your project being tested due to client/project
requirements.

Sample Test Case:

Test Case ID BU_001 Test Case Description Test the Login Functionality in Banking
Created By Mark Reviewed By Bill Version 2.1

QA Tester’s Log Review comments from Bill incorporate in version 2.1

Tester's Name Mark Date Tested 1-Jan-2017 Test Case (Pass/Fail/Not Pass
Executed)

S# Prerequisites: S# Test Data

1 Access to Chrome Browser 1 Userid = mg12345
2 2 Pass = df12@434c
3 3
4 4

Test Verify on entering valid userid and password, the customer can login
Scenario

Step # Step Details Expected Results Actual Results Pass / Fail / Not executed / Suspended

1 Navigate to Site should open As Expected Pass

http://demo.guru99.com
2 Enter Userid & Password Credential can be entered As Expected Pass
3 Click Submit Customer is logged in As Expected Pass
4

SE Lab Manual 35
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 36
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 37
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 8

Prepare FTR (Formal Technical Review) Document

Objective:
1. Useful to uncover error in logic, function and implementation for any representation of the
software.
2. The purpose of FTR is to verify that the software meets specified requirements.
3. To ensure that software is represented according to predefined standards.
4. It helps to review the uniformity in software that is development in a uniform manner.
5. To makes the project more manageable.

The review meeting:

Each review meeting should be held considering the following constraints- Involvement of
people:

1. Between 3, 4 and 5 people should be involve in the review.

2. Advance preparation should occur but it should be very short that is at the most 2 hours of
work for every person.
3. The short duration of the review meeting should be less than two hours. Gives these
constraints, it should be clear that an FTR focuses on specific (and small) part of the overall
software.

At the end of the review, all attendees of FTR must decide what to do.
1. Accept the product without any modification.
2. Reject the project due to serious error (Once corrected, another app needs to be reviewed),
or
3. Accept the product provisional (minor errors are encountered and should be corrected, but
no additional review will be required).
4. The decision was made, with all FTR attendees completing a sign-of indicating their
participation in the review and their agreement with the findings of the review team.

SE Lab Manual 38
SASI Institute of Technology & Engineering CSE Department

Review reporting and record keeping

1. During the FTR, the reviewer actively records all issues that have been raised.
2. At the end of the meeting all these issues raised are consolidated and a review list is
prepared.
3. Finally, a formal technical review summary report is prepared.

Review guidelines
Guidelines for the conducting of formal technical reviews should be established in advance. These
guidelines must be distributed to all reviewers, agreed upon, and then followed. A review that is
unregistered can often be worse than a review that does not minimum set of guidelines for FTR.

1. Review the product, not the manufacture (producer).

2. Take written notes (record purpose)
3. Limit the number of participants and insists upon advance preparation.
4. Develop a checklist for each product that is likely to be reviewed.
5. Allocate resources and time schedule for FTRs in order to maintain time schedule.
6. Conduct meaningful training for all reviewers in order to make reviews effective.
7. Reviews earlier reviews which serve as the base for the current review being conducted.
8. Set an agenda and maintain it.
9. Separate the problem areas, but do not attempt to solve every problem notes.
10. Limit debate and rebuttal.

SE Lab Manual 39
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 40
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 41
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 9

Prepare Version Control and Change Control for Software Configuration

Items.

Introduction
Software Configuration Management

• Software Configuration Management is a set of activities carried out for identifying,

organising, and controlling changes throughout the lifecycle of computer software.
• During the development of software change must be managed and controlled in order to
improve quality and reduce error. Hence software configuration management is a quality
assurance activity that is applied throughout the software process.
• To manage and control Software Configuration Item (SCI), each should be separately named
and organized using object-oriented approaches.
• The SCM process defines a series of tasks that have four primary objectives:
1. To identify all items that collectively define the software configuration (Identification).
2. To manage changes to one or more of these items (Change Control).
3. To facilitate the construction of different versions of an application (Version Control).
4. To ensure that software quality is maintained over time (Configuration Audit).

Following fig shows the layers of SCM process.

SE Lab Manual 42
SASI Institute of Technology & Engineering CSE Department

Version Control
• Version Control Combines procedures and tools to manage different version of configuration
objects that are created during the software process.
• A version control system implements or is directly integrated with four major capabilities:
1. A project database that stores all relevant configuration objects,
2. A version management capability that stores all version of configuration object,
3. A make facility that enables the software engineer to collect all relevant configuration
objects, and
4. Construct a specific version of the software.
• A number of version control systems establish a set – a collection of all changes (to some
baseline configuration) that are required to create a specific version of the software.
• “Changes set” captures all changes to all files in the configuration along with reason for
changes and details of who made the changes and when.
• A number of named change set can be identified for an application or system. This enables a
software engineer to construct a version of the software by specifying the changes set (by
name) that must be applied to the baseline configuration.
• To accomplish this, a system modelling approach is applied. The system model contains
1. A template that includes a component hierarchy and build order for the component that
describe how the system must be constructed,
2. Construction rules, and
3. Verification rules.

Change Control
• Change control is manual step in software lifecycle. It combines human procedures and
automated tools.
1. Change control process is illustrated in the below following figure.
2. Change request submitted and evaluated to assess technical merit, potential side effects,
overall impact on other configuration object and system function, and project cost of
change.
• The result of the evaluation is presented as a change report, which is used by the change
control authority (CCA) – A person or group who make final decision on the status and priority
of the change.
• An engineering change order (ECO) is generated for each approved change. The ECO
describes the change order to be made, the constraints that must be respected, and the criteria
for view and audit.
• The object to be changed can be placed in a directory that is controlled by software engineer
making the change. As an alternative, the object to be changed can be “checked out” of the
project database, change is made, and appropriate SQA activities are applied.
• The object is then “checked in” to the database and appropriate version control mechanism
are used to create the next version of the software.
• Checked in and checked out mechanism require two important elements
• Access Control
• Synchronization Control
1. The Access control mechanism gives the authority to the software engineer to access and
modify the specific configuration object.

SE Lab Manual 43
SASI Institute of Technology & Engineering CSE Department

2. The Synchronization control mechanism allows to make parallel changes or the change
made by two different people without overwriting each other’s work.

SE Lab Manual 44
SASI Institute of Technology & Engineering CSE Department

Version Control and change control system often implements an issue tracking (also called bug
tracking) capability that enables the team to record and track the status of all outstanding issues
associated with each configuration object.

Process of Change Control

Before we look into what is involved in Change Control process, we will get familiarize with what
documents are used in Change Control. While carrying out Change Control, there are mainly two
documents involved
Change Log: A change log is a document that list the details about all the Change Requests like
project number, PCR (project change request) ID, priority, Owner details, Target date, status and
status date, raised by, date when raised etc.

Change Request Form: It is used to document details required to support the decision -making
process like type of change, benefits of change, name of resource requesting the change, time and
estimate cost, priority of change, authorized person detail, change request status etc.

SE Lab Manual 45
SASI Institute of Technology & Engineering CSE Department

Change Process Flow-Diagram: Change Process follows a specific pattern to implement the
changes in the product or system. Here through flow-diagram we explained what are the steps
involved in the Change Process.

Steps for Change Control

Steps for Change

Action
Control
Change request • Identify the need for a change and describe it on the project
identification change request form
• If the change is not valid, it has to be deferred or rejected
• Determine appropriate resources required to analyze the
Change request change request
assessment • Perform quick assessment of the potential impact and update
the change request form
• At this stage, rejected change request should stopped

SE Lab Manual 46
SASI Institute of Technology & Engineering CSE Department

Steps for Change

Action
Control
• For analysis assign the change request to an authorized
Change request member
analysis • Deferred change re-enter this analysis step
• At this stage, rejected change request should stopped
• Identify change risk and complexity level before approval
• Identify the impact level of the change before approval
Change request
• Review impact of Change Request to authorized person for
approval
approval
• At this stage, rejected change request should stopped
• Update project procedure and management plans
• Inform about the changes to the team
Change request
• Monitor progress of change request
implementation
• Record the completion of change request
• Close change request

SE Lab Manual 47
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 48
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 49
SASI Institute of Technology & Engineering CSE Department

EXPERIMENT No: 10

MINI PROJECT

TABLES OF CONTENTS:

CHAPTER TOPIC DESCRIPTION

A. Four to Five Lines about the Project

(E.G: Library Management System)
I Synopsis
B. Scope of the project
C. Objective of the project

II Modules Area of functionality

A. Entity - Creating Registration Page

E-R Diagrams (Entity– B. Decision Symbol
III
Relationship Diagrams) C. Connection Arrows
D. Attribute Symbol

DFD Diagram (Data Flow A. Level - 0

IV
Diagram) B. Level - 1

Entity–Relationship Diagrams: ER Model stands for Entity Relationship Model is a high-level

conceptual data model diagram. ER model helps to systematically analyze data requirements to
produce a well-designed database. The ER Model represents real-world entities and the
relationships between them. Creating an ER Model in DBMS is considered as a best practice before
implementing your database.

Entity Relationship Diagram Symbols & Notations mainly contains three basic symbols which
are rectangle, oval and diamond to represent relationships between elements, entities and
attributes. There are some sub-elements which are based on main elements in ERD Diagram. ER
Diagram is a visual representation of data that describes how data is related to each other using
different ERD Symbols and Notations.

Following are the main components and its symbols in ER Diagrams:

1. Rectangles : This Entity Relationship Diagram symbol represents entity types

2. Ellipses : Symbol represent attributes
3. Diamonds : This symbol represents relationship types

SE Lab Manual 50
SASI Institute of Technology & Engineering CSE Department

4. Lines : It links attributes to entity types and entity types with other relationship types
5. Primary key : attributes are underlined
6. Double Ellipses : Represent multi-valued attributes

What is Entity?: A real-world thing either living or non-living that is easily recognizable and
nonrecognizable. It is anything in the enterprise that is to be represented in our database. It may be
a physical thing or simply a fact about the enterprise or an event that happens in the real world.

An entity can be place, person, object, event or a concept, which stores data in the database. The
characteristics of entities are must have an attribute, and a unique key. Every entity is made up of
some ‘attributes’ which represent that entity.

Examples of entities:

1. Person: Employee, Student, Patient

2. Place: Store, Building
3. Object: Machine, product, and Car
4. Event: Sale, Registration, Renewal
5. Concept: Account, Course
6. Notation of an Entity

Entity set:
Student
An entity set is a group of similar kind of entities. It may contain entities with attribute sharing
similar values. Entities are represented by their properties, which also called attributes. All
attributes have their separate values. For example, a student entity may have a name, age, class,
as attributes.

SE Lab Manual 51
SASI Institute of Technology & Engineering CSE Department

Example of Entities:
A university may have some departments. All these departments employ various lecturers and
offer several programs. Some courses make up each program. Students register in a particular
program and enroll in various courses. A lecturer from the specific department takes each course,
and each lecturer teaches a various group of students.

Relationship
Relationship is nothing but an association among two or more entities. E.g., Tom works in the
Chemistry department.

Entities take part in relationships. We can often identify relationships with verbs or verb phrases.

For example:
1. You are attending this lecture
2. I am giving the lecture
3. Just loke entities, we can classify relationships according to relationship-types:
4. A student attends a lecture
5. A lecturer is giving a lecture.

Attributes: It is a single-valued property of either an entity-type or a relationship-type. For

example, a lecture might have attributes: time, date, duration, place, etc. An attribute in ER
Diagram examples, is represented by an Ellipse.

SE Lab Manual 52
SASI Institute of Technology & Engineering CSE Department

How to Create an Entity Relationship Diagram (ERD)?

Now in this ERD Diagram Tutorial, we will learn how to create an ER Diagram. Following are
the steps to create an ER Diagram:

Steps to Create an ER Diagram

Step 1) Entity Identification

Step 2) Relationship Identification

Step 3) Cardinality Identification

Step 4) Identify Attributes

Step 5) Create the ERD Diagram

SE Lab Manual 53
SASI Institute of Technology & Engineering CSE Department

Data flow diagram

A data flow diagram shows how data is processed within a system based on inputs and outputs.
Visual symbols are used to represent the flow of information, data sources and destinations, and
where data is stored. Data flow diagrams are often used as a first step toward redesigning a system.
They provide a graphical representation of a system at any level of detail, creating an easy-to-
understand picture of what the system does. A general overview of a system is represented with a
context diagram, also known as a level 0 DFD, which shows a system as a single process. A level
1 diagram provides greater detail, focusing on a system’s main functions. Diagrams that are level
2 or higher illustrate a system’s functioning with increasing detail. It’s rare for a DFD to go beyond
level 2 because of the increasing complexity, which makes it less effective as a communication
tool.

Data flow diagram notations

The two main types of notations used for data flow diagrams are Yourdon-Coad and Gane-Sarson,
both named after their creators, all experts who helped develop DFD methodology: Ed Yourdon,
Peter Coad, Chris Gane and Trish Sarson. There are some differences in style between the notation
types. For example, Yourdon and Coad notation uses circles to represent processes, whereas Gane
and Sarson notation use rectangles with rounded corners. Another variation is the symbol used for
data stores—Yourdon and Coad uses parallel lines while Gane and Sarson notation uses an open-
ended rectangle. Because DFD symbols vary, it’s important to be consistent with whatever
notation you choose in order to avoid confusion. If you’re using DFD software, it will likely dictate
which set of symbols are available to use.

All data flow diagrams include four main elements: entity, process, data store and data flow.

External Entity – Also known as actors, sources or sinks, and terminators, external entities
produce and consume data that flows between the entity and the system being diagrammed. These
data flows are the inputs and outputs of the DFD. Since they are external to the system being
analyzed, these entities are typically placed at the boundaries of the diagram. They can represent
another system or indicate a subsystem.

Process – An activity that changes or transforms data flows. Since they transform incoming data
to outgoing data, all processes must have inputs and outputs on a DFD. This symbol is given a
simple name based on its function, such as “Ship Order,” rather than being labeled “process” on a
diagram. In Gane-Sarson notation, a rectangular box is used and may be labeled with a reference
number, location of where in the system the process occurs and a short title that describes its
function. Processes are typically oriented from top to bottom and left to right on a data flow
diagram.

SE Lab Manual 54
SASI Institute of Technology & Engineering CSE Department

Data Store – A data store does not generate any operations but simply holds data for later access.
Data stores could consist of files held long term or a batch of documents stored briefly while they
wait to be processed. Input flows to a data store include information or operations that change the
stored data. Output flows would be data retrieved from the store.

Data Flow – Movement of data between external entities, processes and data stores is represented
with an arrow symbol, which indicates the direction of flow. This data could be electronic, written
or verbal. Input and output data flows are labeled based on the type of data or its associated process
or data store, and this name is written alongside the arrow.

0-level DFDM

The Level-0 DFD, also called context diagram of the result management system is shown in fig.
As the bubbles are decomposed into less and less abstract bubbles, the corresponding data flow
may also be needed to be decomposed.

SE Lab Manual 55
SASI Institute of Technology & Engineering CSE Department

1-level DFD
In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this level,
we highlight the main objectives of the system and breakdown the high-level process of 0-level
DFD into subprocesses.

SE Lab Manual 56
SASI Institute of Technology & Engineering CSE Department

TITLE OF THE PROJECT :

NAME OF THE TEAM MEMBERS:

S.NO H.T.No. STUDENT NAME

SE Lab Manual 57
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 58
SASI Institute of Technology & Engineering CSE Department

SE Lab Manual 59
SASI Institute of Technology & Engineering CSE Department

Result:

SE Lab Manual 60