SRI VENKATESWARA INSTITUTE OF TECHNOLOGY

(Affiliated to JNTU, ANANTHAPURAMU and Approved by A.I.C.T.E New Delhi)

NH-44, HAMPAPURAM, ANANTHAPURAMU-515722

LABORATORY MANUAL(R20)
for
SOFTWARE ENGINEERING
(SUBJECT CODE: 20A05403P)
(for Academic Year: 2021 – 2022)

Prepared By

J RAVI KISHORE
(ASSISTANT PROFESSOR)
EXP 1: Draw the work break down structure for the system to be automated

Breaking work into smaller tasks is a common productivity technique used to make the work
more manageable and approachable. For projects, the Work Breakdown Structure (WBS) is
the tool that utilizes this technique and is one of the most important project management
documents. It singlehandedly integrates scope, cost and schedule baselines ensuring that project
plans are in alignment.
The Project Management Institute (PMI) Project Management Book of Knowledge (PMBOK)
defines the Work Breakdown Structure as a “deliverable oriented hierarchical decomposition of
the work to be executed by the project team.” There are two types of WBS: 1) Deliverable-
Based and 2) Phase-Based. The most common and preferred approach is the Deliverable-Based
approach. The main difference between the two approaches are the Elements identified in the
first Level of the WBS.
Deliverable-Based Work Breakdown Structure
A Deliverable-Based Work Breakdown Structure clearly demonstrates the relationship between
the project deliverables (i.e., products, services or results) and the scope (i.e., work to be
executed). Figure 1 is an example of a Deliverable-Based WBS for building a house. Figure 2 is
an example of a Phase-Based WBS for the same project.

FIGURE 1 – DELIVERABLE BASED WORK BREAKDOWN STRUCTURE

In Figure 1, the Level 1 Elements are summary deliverable descriptions. The Level 2 Elements
in each Leg of the WBS are all the unique deliverables required to create the respective Level 1
deliverable.
Phase-Based Work Breakdown Structure
In Figure 2, a Phase-Based WBS, the Level 1 has five Elements. Each of these Elements are
typical phases of a project. The Level 2 Elements are the unique deliverables in each phase.
Regardless of the type of WBS, the lower Level Elements are all deliverables. Notice that
Elements in different Legs have the same name. A Phase-Based WBS requires work associated
with multiple elements be divided into the work unique to each Level 1 Element. A WBS
Dictionary is created to describe the work in each Element.
 FIGURE 2 - PHASE BASED WORK BREAKDOWN STRUCTURE
A good WBS is simply one that makes the project more manageable. Every project is different;
every project manager is different and every WBS is different. So, the right WBS is the one that
best answers the question, “What structure makes the project more manageable?”.
How to Make a Work Breakdown Structure
A good Work Breakdown Structure is created using an iterative process by following these
steps and meeting these guidelines:
1. GATHER CRITICAL DOCUMENTS
a. Gather critical project documents.
b. Identify content containing project deliverables, such as the Project Charter, Scope
Statement and Project Management Plan (PMP) subsidiary plans.
2. IDENTIFY KEY TEAM MEMBERS
a. Identify the appropriate project team members.
b. Analyze the documents and identify the deliverables.
3. DEFINE LEVEL 1 ELEMENTS
a. Define the Level 1 Elements. Level 1 Elements are summary deliverable
descriptions that must capture 100% of the project scope.
b. Verify 100% of scope is captured. This requirement is commonly referred to as
the 100% Rule.
4. DECOMPOSE (BREAKDOWN) ELEMENTS
a. Begin the process of breaking the Level 1 deliverables into unique lower Level
deliverables. This “breaking down” technique is called Decomposition.
b. Continue breaking down the work until the work covered in each Element is
managed by a single individual or organization. Ensure that all Elements are
mutually exclusive.
c. Ask the question, would any additional decomposition make the project more
manageable? If the answer is “no”, the WBS is done.
5. CREATE WBS DICTIONARY
 a. Define the content of the WBS Dictionary. The WBS Dictionary is a narrative
description of the work covered in each Element in the WBS. The lowest Level
Elements in the WBS are called Work Packages.
b. Create the WBS Dictionary descriptions at the Work Package Level with detail
enough to ensure that 100% of the project scope is covered. The descriptions should
include information such as, boundaries, milestones, risks, owner, costs, etc.
6. CREATE GANTT CHART SCHEDULE
a. Decompose the Work Packages to activities as appropriate.
b. Export or enter the Work Breakdown Structure into a Gantt chart for further
scheduling and project tracking.
EXP 2: Schedule all the activities and sub-activities using PERT/CPM charts.
Introduction to PERT/CPM charts:

What Is the Critical Path?

In project management, the critical path is the longest sequence of tasks that must be
completed to successfully conclude a project, from start to finish. The tasks on the critical path
are known as critical activities because if they’re delayed, the whole project will be delayed. By
identifying the critical path, you can determine the total duration of a project.

Calculating the critical path is key during the planning phase because the critical path identifies
important deadlines and the activities which must be completed on time. Once a critical path is
determined, you’ll have a clear picture of the project’s actual schedule.

To find this, project managers use the critical path method (CPM) algorithm to define the least
amount of time necessary to complete each task with the least amount of slack.

Once done by hand, nowadays the critical path is calculated automatically by project
scheduling software. That makes the whole method much easier.

What is the Critical Path Method in Project Management?

The critical path method (CPM), also known as critical path analysis (CPA), is a scheduling
procedure that uses a network diagram to depict a project and the sequences of tasks required to
complete it, which are known as paths. Once the paths are defined, the duration of each path is
calculated by an algorithm to identify the critical path, which determines the total duration of the
project.

The critical path method (CPM) is used in project management to create project schedules and
helps project managers create a timeline for the project. The critical path method includes:
 1. Identifying every task necessary to complete the project and the dependencies between

them
2. Estimating the duration of the project tasks

3. Calculating the critical path based on the tasks’ duration and dependencies to identify

the critical activities

4. Focusing on planning, scheduling and controlling critical activities

5. Setting project milestones and deliverables

6. Setting stakeholder expectations related to deadlines

After making these considerations, you gain insight into which activities must be prioritized. Then,
you can allocate the necessary resources to get these important tasks done. Tasks you discover that
aren’t on the critical path are of a lesser priority in your project plan, and can be delayed if they’re
causing the project team to become overallocated.

Gain Insight When Planning Tasks

Projects are made up of tasks that have to adhere to a schedule in order to meet a deadline. It
sounds simple, but without mapping the work it can quickly get out of hand and you’ll find your
project off track.

When you’re analyzing the critical path, you’re looking closely at the time it will take to complete
each task, taking into account the task dependencies and how they’ll impact your schedule. It’s a
technique to find the most realistic project deadline. It can also help during the project as a metric
to track your progress.

Therefore, when you’re doing critical path analysis, you’re finding the sequence of tasks that are
both important and dependent on a previous task. Less important tasks aren’t ignored and are part
of the analysis; however, they’re the ones you know can be jettisoned if time and money won’t
permit.
Critical Path – Definition of Terms
To properly understand the concept of critical path, you first need to understand the various terms
used in this method.

Earliest start time (ES): This is simply the earliest time that a task can be started in your project.
You cannot determine this without first knowing if there are any preceding tasks, or figuring out
other constraints that might impact the start of this task.

Latest start time (LS): This is the very last minute in which you can start a task before it threatens
to upset your project schedule. And you need to calculate what the latest finish time is for the same
reason. By having a clear picture of this timeframe, you can better schedule the project to meet its
deadline.

Earliest finish time (EF): The earliest an activity can be completed, based on its duration and its
earliest start time.

Latest finish time (LF): The latest an activity can be completed, based on its duration and its latest
start time.
Float. Also known as slack, float is a term that describes how long you can delay a task before it
impacts the planned schedule and threatens the project’s deadline. The tasks on the critical path
have zero float. You can either calculate the float using the steps above, or by using project
management software. If an activity has a float greater than zero, it means it can be delayed without
affecting the project completion time.

Crash duration. This describes the shortest amount of time that a task can be scheduled. You can
get there by moving around resources, adding more towards the end of the task, to decrease the
time needed to complete the task. This often means a reduction in quality, but is based on a
relationship between cost and time.

Critical path drag. If time is added to the project because of a constraint, that is called a critical
path drag, which is how much longer a project will take because of constraints on tasks in the
critical path.

How to Calculate the Critical Path

Now that you know the key definitions of CPM, here are the steps to calculate the critical path in
project management:

 Collect Activities: Use a work breakdown structure to collect all the project activities that lead
to the final deliverable.
 Identify Dependencies: Figure out which tasks are dependent on other tasks before they can
begin.
 Create a Network Diagram: A critical path analysis chart, or network diagram, depicts the
order of activities.
 Estimate Timeline: Determine the duration of each activity.
 Use the Critical Path Algorithm: The algorithm has two parts; a forward pass and a
backwards pass.
 Forward Pass: Use the network diagram and the duration of each activity to determine their
earliest start (ES) and earliest finish (EF). The ES of an activity is equal to the EF of its
predecessor, and its EF is determined by the formula EF = ES + t (t is the activity duration).
The EF of the last activity identifies the expected time required to complete the entire project.
 Backward Pass: Begins by assigning the last activity’s earliest finish as its latest finish. Then
the formula to find the LS is LS = LF – t (t is the activity duration). For the previous activities,
the LF is the smallest of the start times for the activity that immediately follows.
 Identify the Float of Each Activity: The float is the length of time an activity can be delayed
without increasing the total project completion time. Since the critical path has no float, the
float formula reveals the critical path: Float = LS – ES
 Identify the Critical Path: The activities with 0 float make up the critical path.
 Revise During Execution: Continue to update the critical path network diagram as you go
through the execution phase.

These steps determine what tasks are critical and which can float, meaning they can be delayed
without negatively impacting the project by making it longer. Now you have the information you
need to plan the schedule more accurately and have more of a guarantee you’ll meet your project
deadline.

You also need to consider other constraints that might change the project schedule. The more you
can account for these issues, the more accurate your critical path method will be. If time is added to
the project because of these constraints, that is called a critical path drag, which is how much
longer a project will take because of the task and constraint.
What Is the Critical Path?
In project management, the critical path is the longest sequence of tasks that must be
completed to successfully conclude a project, from start to finish. The tasks on the critical path
are known as critical activities because if they’re delayed, the whole project will be delayed. By
identifying the critical path, you can determine the total duration of a project.

Calculating the critical path is key during the planning phase because the critical path identifies
important deadlines and the activities which must be completed on time. Once a critical path is
determined, you’ll have a clear picture of the project’s actual schedule.

To find this, project managers use the critical path method (CPM) algorithm to define the least
amount of time necessary to complete each task with the least amount of slack.

Once done by hand, nowadays the critical path is calculated automatically by project scheduling
software. That makes the whole method much easier.

What is the Critical Path Method in Project Management?

The critical path method (CPM), also known as critical path analysis (CPA), is a scheduling
procedure that uses a network diagram to depict a project and the sequences of tasks required to
complete it, which are known as paths. Once the paths are defined, the duration of each path is
calculated by an algorithm to identify the critical path, which determines the total duration of the
project.

The critical path method (CPM) is used in project management to create project schedules and
helps project managers create a timeline for the project. The critical path method includes:

 Identifying every task necessary to complete the project and the dependencies between them
 Estimating the duration of the project tasks
 Calculating the critical path based on the tasks’ duration and dependencies to identify the
critical activities
 Focusing on planning, scheduling and controlling critical activities
 Setting project milestones and deliverables
 Setting stakeholder expectations related to deadlines

After making these considerations, you gain insight into which activities must be prioritized. Then,
you can allocate the necessary resources to get these important tasks done. Tasks you discover that
aren’t on the critical path are of a lesser priority in your project plan, and can be delayed if they’re
causing the project team to become overallocated.

Gain Insight When Planning Tasks

Projects are made up of tasks that have to adhere to a schedule in order to meet a deadline. It
sounds simple, but without mapping the work it can quickly get out of hand and you’ll find your
project off track.

When you’re analyzing the critical path, you’re looking closely at the time it will take to complete
each task, taking into account the task dependencies and how they’ll impact your schedule. It’s a
technique to find the most realistic project deadline. It can also help during the project as a metric
to track your progress.

Therefore, when you’re doing critical path analysis, you’re finding the sequence of tasks that are
both important and dependent on a previous task. Less important tasks aren’t ignored and are part
of the analysis; however, they’re the ones you know can be jettisoned if time and money won’t
permit.
Critical Path – Definition of Terms
To properly understand the concept of critical path, you first need to understand the various terms
used in this method.

Earliest start time (ES): This is simply the earliest time that a task can be started in your project.
You cannot determine this without first knowing if there are any preceding tasks, or figuring out
other constraints that might impact the start of this task.

Latest start time (LS): This is the very last minute in which you can start a task before it threatens
to upset your project schedule. And you need to calculate what the latest finish time is for the same
reason. By having a clear picture of this timeframe, you can better schedule the project to meet its
deadline.

Earliest finish time (EF): The earliest an activity can be completed, based on its duration and its
earliest start time.

Latest finish time (LF): The latest an activity can be completed, based on its duration and its latest
start time.

Float. Also known as slack, float is a term that describes how long you can delay a task before it
impacts the planned schedule and threatens the project’s deadline. The tasks on the critical path
have zero float. You can either calculate the float using the steps above, or by using project
management software. If an activity has a float greater than zero, it means it can be delayed without
affecting the project completion time.

Crash duration. This describes the shortest amount of time that a task can be scheduled. You can
get there by moving around resources, adding more towards the end of the task, to decrease the
time needed to complete the task. This often means a reduction in quality, but is based on a
relationship between cost and time.

Critical path drag. If time is added to the project because of a constraint, that is called a critical
path drag, which is how much longer a project will take because of constraints on tasks in the
critical path.

How to Calculate the Critical Path

Now that you know the key definitions of CPM, here are the steps to calculate the critical path in
project management:

 Collect Activities: Use a work breakdown structure to collect all the project activities that lead
to the final deliverable.
 Identify Dependencies: Figure out which tasks are dependent on other tasks before they can
begin.
 Create a Network Diagram: A critical path analysis chart, or network diagram, depicts the
order of activities.
 Estimate Timeline: Determine the duration of each activity.
 Use the Critical Path Algorithm: The algorithm has two parts; a forward pass and a
backwards pass.
 Forward Pass: Use the network diagram and the duration of each activity to determine their
earliest start (ES) and earliest finish (EF). The ES of an activity is equal to the EF of its
predecessor, and its EF is determined by the formula EF = ES + t (t is the activity duration).
The EF of the last activity identifies the expected time required to complete the entire project.
 Backward Pass: Begins by assigning the last activity’s earliest finish as its latest finish. Then
the formula to find the LS is LS = LF – t (t is the activity duration). For the previous activities,
the LF is the smallest of the start times for the activity that immediately follows.
 Identify the Float of Each Activity: The float is the length of time an activity can be delayed
without increasing the total project completion time. Since the critical path has no float, the
float formula reveals the critical path: Float = LS – ES
 Identify the Critical Path: The activities with 0 float make up the critical path.
 Revise During Execution: Continue to update the critical path network diagram as you go
through the execution phase.

These steps determine what tasks are critical and which can float, meaning they can be delayed
without negatively impacting the project by making it longer. Now you have the information you
need to plan the schedule more accurately and have more of a guarantee you’ll meet your project
deadline.

You also need to consider other constraints that might change the project schedule. The more you
can account for these issues, the more accurate your critical path method will be. If time is added to
the project because of these constraints, that is called a critical path drag, which is how much
longer a project will take because of the task and constraint.

What Is Critical Path Software?

Critical path software is used to automatically calculate the critical path in your project schedule.
Without using software, managers would have to manually calculate the time-consuming and
complicated equation.

Time is one of the triple constraints of a project, so it’s understandable why critical path software
has become popular in project management. Any opportunity to gain efficiencies steers the project
closer to meeting its goals and objectives.
Since critical path is a very specific technique, critical path software is usually associated with a
larger project planning tool that organizes tasks, prioritizes the sequence of activities and other
features that go into creating the schedule. One of the most commonly used project management
software to identify the critical path is Microsoft Project. However, it has major drawbacks that
make ProjectManager.com a better choice.

Benefits of Critical Path Method

Knowing the critical path and having a tool to recalculate it as your schedule evolves over the
course of the project is key to getting back on track when you’re behind schedule. More benefits to
using critical path Method include the following.

1. Quick Calculations Save Time and Effort

2. Track Progress To Know If You’re Behind

3. Recalculate As Project Schedule Changes

4. Keep Track of Task Dependencies

5. Set Milestones and Save Important Dates

6. Get Insightful Data When Planning Tasks

7. Create Schedule Baseline for Project Variance

PERT

What Does Program Evaluation and Review Technique (PERT) Mean?

Program evaluation and review technique (PERT) is a technique adopted by organizations to analyze and
represent the activity in a project, and to illustrate the flow of events in a project. PERT is a method to evaluate
and estimate the time required to complete a task within deadlines.
PERT serves as an management tool to analyze, define and integrate events. PERT also illustrates the activities
and interdependencies in a project. The main goal of PERT is to reduce the cost and time needed to complete a
project.

Techopedia Explains Program Evaluation and Review Technique

(PERT)

PERT was developed in 1950 by the U.S. Navy during the Cold War and is intended for large projects, which
are:

● Complex
● Require a series of sequential tasks
● Performed in parallel with other projects

PERT planning usually involves the following steps:

1. Identifying Tasks and Milestones: Every project involves a series of required tasks. These tasks are
listed in a table allowing additional information on sequence and timing to be added later.
2. Placing the Tasks in a Proper Sequence: The tasks are analyzed and placed in a sequence to get the
desired results.
3. Network Diagramming: A network diagram is drawn using the activity sequence data showing the
sequence of serial and parallel activities.
4. Time Estimating: This is the time required to carry out each activity, in three parts:
1. Optimistic timing: The shortest time to complete an activity
2. Most likely timing: The completion time having the highest probability
3. Pessimistic timing: The longest time to complete an activity
5. Critical Path Estimating: This determines the total time required to complete a project.

PERT not only determines the time to complete a specific software development activity, but also determines
the cost.
EXP:3 Define usecases and represent them in use case document for all
stakeholders of the system to be automated.

A use case describes how a user uses a system to accomplish a particular goal. A use case
diagram consists of the system, the related use cases and actors and relates these to each other to
visualize: what is being described? (system), who is using the system? (actors) and what do the
actors want to achieve? (use cases), thus, use cases help ensure that the correct system is
developed by capturing the requirements from the user’s point of view.
A use case diagram is usually simple. It does not show the detail of the use cases:
 It only summarizes some of the relationships between use cases, actors, and systems.
 It does not show the order in which steps are performed to achieve the goals of each use
case.
As said, a use case diagram should be simple and contains only a few shapes. If yours contain
more than 20 use cases, you are probably mis-using usecase diagram.
The figure below shows the UML diagram hierarchy and the positioning of UML Use Case
Diagram. As you can see, use case diagrams belong to the family of behavioral diagrams.
Use Case Diagram at a Glance
A standard form of use case diagram is defined in the Unified Modeling Language as shown in
the Use Case Diagram example below:

Notation DescriptionVisual Representation

Actor
 Someone interacts with use case (system function).
 Named by noun.
 Actor plays a role in the business
 Similar to the concept of user, but a user can play different roles
 For example:
 A prof. can be instructor and also researcher
 plays 2 roles with two systems
 Actor triggers use case(s).
 Actor has responsibility toward the system (inputs), and Actor have expectations from the
system (outputs).

Use Case
 System function (process — automated or manual)
 Named by verb + Noun (or Noun Phrase).
 i.e. Do something
 Each Actor must be linked to a use case, while some use cases may not be linked to actors.



Communication Link
 The participation of an actor in a use case is shown by connecting a actor to a use case by
a solid link.
 Actors may be connected to use cases by associations, indicating that the actor and the use
case communicate with one another using messages.
Boundary of system
 The system boundary is potentially the entire system as defined in the requirements
document.
 For large and complex systems, each modules may be the system boundary. 
 For example, for an ERP system for an organization, each of the modules such as personal,
payroll, accounting, etc.
 can form a system boundary for use cases specific to each of these business functions.
 The entire system can span all of these modules depicting the overall system boundary

Structuring Use Case Diagram with Relationships

Use cases share different kinds of relationships. Defining the relationship between two use cases
is the decision of the software analysts of the use case diagram. A relationship between two use
cases is basically modeling the dependency between the two use cases. Reuse of an existing use
case by using different types of relationships reduces the overall effort required in developing a
system. Use case relationships are listed as the following:
Use Case Relationship — Visual Representation
Extends
 Indicates that an “Invalid Password” use case may include (subject to specified in the
extension) the behavior specified by base use case “Login Account”. 
 Depict with a directed arrow having a dotted line. The tip of arrowhead points to the base
use case and the child use case is connected at the base of the arrow. 
 The stereotype “<<extends>>” identifies as an extend relationship. 
USECASE DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM
EXP 4: Identify and analyze all the possible risks and its risk mitigation plan
for the system to be automated.

Software development is a multi stage approach of design, documentation, programming,

prototyping, testing etc which follows a Software Development Life Cycle (SDLC) process.
Different tasks are performed based on SDLC framework during software development.
Developing and Maintaining software project involves risk in each step.
Most enterprises rely on software and ignoring the risks associated with any phase needs to be
identified and managed/solved otherwise it creates unforeseen challenges for business. Before
analyzing different risks involved in software development, Let’s first understand what is
actually risk and why risk management is important for a business.
Risk and importance of risk management :
Risk is uncertain events associated with future events which have a probability of occurrence
but it may or may not occur and if occurs it brings loss to the project. Risk identification and
management are very important task during software project development because success
and failure of any software project depends on it.
Various Kinds of Risks in Software Development :
1. Schedule Risk :
Schedule related risks refers to time related risks or project delivery related planning risks.
The wrong schedule affects the project development and delivery. These risks are mainly
indicates to running behind time as a result project development doesn’t progress timely
and it directly impacts to delivery of project. Finally if schedule risks are not managed
properly it gives rise to project failure and at last it affect to organization/company
economy very badly.
Some reasons for Schedule risks –
 Time is not estimated perfectly
 Improper resource allocation
 Tracking of resources like system, skill, staff etc
 Frequent project scope expansion
 Failure in function identification and its’ completion
2. Budget Risk :
Budget related risks refers to the monetary risks mainly it occurs due to budget overruns.
Always the financial aspect for the project should be managed as per decided but if
financial aspect of project mismanaged then there budget concerns will arise by giving rise
to budget risks. So proper finance distribution and management are required for the success
of project otherwise it may lead to project failure.
Some reasons for Budget risks –
 Wrong/Improper budget estimation
 Unexpected Project Scope expansion
 Mismanagement in budget handling
 Cost overruns
 Improper tracking of Budget
3. Operational Risks :
Operational risk refers to the procedural risks means these are the risks which happen in day-
to-day operational activities during project development due to improper process
implementation or some external operational risks.
Some reasons for Operational risks –
 Insufficient resources
 Conflict between tasks and employees
 Improper management of tasks
 No proper planning about project
 Less number of skilled people
 Lack of communication and cooperation
 Lack of clarity in roles and responsibilities
 Insufficient training
4. Technical Risks :
Technical risks refers to the functional risk or performance risk which means this technical
risk mainly associated with functionality of product or performance part of the software
product.
Some reasons for Technical risks –
 Frequent changes in requirement
 Less use of future technologies
 Less number of skilled employee
 High complexity in implementation
 Improper integration of modules
5. Programmatic Risks :
Programmatic risks refers to the external risk or other unavoidable risks. These are the
external risks which are unavoidable in nature. These risks come from outside and it is out
of control of programs.
Some reasons for Programmatic risks –
 Rapid development of market
 Running out of fund / Limited fund for project development
 Changes in Government rules/policy
 Loss of contracts due to any reason
Risk mitigation plans:
Mitigating options include:
 Accept: Acknowledge that a risk is impacting the project. Make an explicit decision to
accept the risk without any changes to the project. Project management approval is
mandatory here.
 Avoid: Adjust project scope, schedule, or constraints to minimize the effects of the risk.
 Control: Take action to minimize the impact or reduce the intensification of the risk.
 Transfer: Implement an organizational shift in accountability, responsibility, or authority
to other stakeholders that will accept the risk.
 Continue Monitoring: Often suitable for low-impact risks, monitor the project
environment for potentially increasing impact of the risk.
 Communicate:Throughout the project, it’s vital to ensure effective communication
among all stakeholders, managers, developers, QA—especially marketing and customer
representatives. Sharing information and getting feedback about risks will greatly increase
the probability of project success.
 EXP 5: Diagnose any risk using Ishikawa Diagram(Can be called as Fish Bone
Diagram or Cause & Effect Diagram)

Also called: cause-and-effect diagram, Ishikawa diagram

Variations: cause enumeration diagram, process fishbone, time-delay fishbone, CEDAC (cause-
and-effect diagram with the addition of cards), desired-result fishbone, reverse fishbone
diagram

This cause analysis tool is considered one of the seven basic quality tools. The fishbone
diagram identifies many possible causes for an effect or problem. It can be used to structure a
brainstorming session. It immediately sorts ideas into useful categories.
 When to use a fishbone diagram
 Fishbone diagram procedure
 Fishbone diagram example
 Create a fishbone diagram
 Fishbone diagram resources
WHEN TO USE A FISHBONE DIAGRAM
 When identifying possible causes for a problem
 When a team’s thinking tends to fall into ruts
FISHBONE DIAGRAM PROCEDURE

Fishbone Diagram Example

Materials needed: marking pens and flipchart or whiteboard.
1. Agree on a problem statement (effect). Write it at the center right of the flipchart or
whiteboard. Draw a box around it and draw a horizontal arrow running to it.
2. Brainstorm the major categories of causes of the problem. If this is difficult use generic
headings:
 Methods
 Machines (equipment)
 People (manpower)
 Materials
 Measurement
 Environment
3. Write the categories of causes as branches from the main arrow.
4. Brainstorm all the possible causes of the problem. Ask "Why does this happen?" As each
idea is given, the facilitator writes it as a branch from the appropriate category. Causes can be
written in several places if they relate to several categories.
5. Again ask "Why does this happen?" about each cause. Write sub-causes branching off the
causes. Continue to ask "Why?" and generate deeper levels of causes. Layers of branches
indicate causal relationships.
6. When the group runs out of ideas, focus attention to places on the chart where ideas are
few.
FISHBONE DIAGRAM EXAMPLE
This fishbone diagram was drawn by a manufacturing team to try to understand the source of
periodic iron contamination. The team used the six generic headings to prompt ideas. Layers of
branches show thorough thinking about the causes of the problem.

Fishbone Diagram Example

For example, under the heading "Machines," the idea "materials of construction" shows four
kinds of equipment and then several specific machine numbers.
Note that some ideas appear in two different places. "Calibration" shows up under "Methods" as
a factor in the analytical procedure, and also under "Measurement" as a cause of lab error. "Iron
tools" can be considered a "Methods" problem when taking samples or a "Manpower" problem
with maintenance personnel.

How to diagnose risk using Fish Bone Diagram

ishbone Diagrams which are also referred to as cause and effect diagrams, are a problem
solving and fault finding tool which facilitates the thought process in dissecting an issue or
problem into a standard four contributing sources from which users than think of possible
causes of the problem. It is a very useful tool and can be used to analyse problems within
operations, supply chain, or any other areas of a business. Below on this page we have carried
out a fish bone diagram problem solving exercise step by step.
Step 1:
Before starting a fish bone diagram as part of any problem solving or kaizen initiative, the
problem statement must be well defined. For this example we will use the following problem
statement:

Customer orders for custom mountain bikes are delivered 4 weeks later than regular mountain
bikes.

Step 2:
Once the problem statement has been defined, production, warehouse and supply chain data
relating to the product in question may be collected in theis case to better identify possible
causes. This will make the process of checking the possible causes and theories a lot easier.

Step 3:
The next step is to draw the fish bone diagram including the possible cause and the four
standard problem sources. The four possible sources are:

Machinery and Equipment

Materials
Methods
People

This can be seen below:

Step 4:
For each problem source, the user must brainstorm and think of possible causes and hypothesis
related to that source. The production and supply chian data collected in step 2 can be very
helpful in this step. This can be seen below:
Step 5:
For each of the causes identified in the step above the same thought process is repeated as in
step 4 to try and identify the root cause of each cause. This process is similar to the 5 whys
approach of problem solving.

Step 6:
Each possible root cause or hypothesis is checked for validity with support from production,
warehouse, and other data collected along the supply chain to verify its valididty or rule the
possible cause asa credible one. Once this process has been completed a handful of possible
causes will be proved valid. These should provide a focuss area to address in order to eliminate
the problem, issue, or seize the opportunity named in the problem statement.
EXP 6: Define complete project plan for the system to be automated using
Microsoft project tool.

What Is Microsoft Project?

Microsoft Project (MSP) is a project management software made for project managers so they
can control their projects. Depending on your plan, Microsoft Project lets you plan projects,
assign tasks, manage resources, make reports and more. It offers a full plate of services and was
quick to dominate the project management software field when it was first introduced.
Microsoft Project is part of the larger suite of Microsoft Office products, yet it is not packaged
with other Office software, such as Word, Excel and Outlook. There are two editions available,
the standard and professional versions. Both share a unique file format, called MPP.
It was first commercially available in 1984. The first version for Windows was released in 1990.
The next year, Microsoft created a Mac version of Project, but it was quickly discontinued and
by 1994 was no longer being sold to the public. Currently, Microsoft Project isn’t compatible
with Mac computers, but there is a workaround if you need to run MS Project for Mac.
Microsoft Project Features
There are plenty of features that project managers and their teams need to manage their work
better, and MSP has a number of them. However, to get a full picture, here is a list of all
features available to customers who put up the big bucks.
 Grid View: A project view that is used to plan and manage projects with a task list.
 Board View: A visual kanban board view that helps with managing workflow and status.
 Timeline View: The traditional Gantt chart used for scheduling tasks over a project
timeline.
 Communication & Collaboration: Teams can work together on projects.
 Coauthoring: Stakeholders and team members work together to edit and update task lists
and schedules.
 Reporting: Pre-built reports that can track progress, resources, programs and portfolios.
 Roadmap: Track programs and project portfolios.
 Timesheets: Collect project and non-project time for payroll and invoicing.
 Resource Management: Manage resources by requesting and assigning tasks.
Related: Microsoft Teams, Microsoft Planner
Plans and Pricing
The newest version is Microsoft Project 2019, which runs only on Windows 10. There are
three pricing plans for cloud-based solutions, the lowest tier with an annual commitment of $10
per user, per month. It has limited features and doesn’t include such essential tools as reporting,
timesheet submission and resource management.
The next pricing tier is $30 per user, per month, with an annual commitment. It does include
some of the features not available at the lower pricing tier, but not portfolio selection and
optimization, demand management or enterprise resource planning and management.
Finally, there’s the top tier payment plan of $55 per user, per month, with an annual
commitment. This version has all the bells and whistles, but can become prohibitively
expensive depending on the number of licenses you need.
There is also an on-premise solution, which again offers a three-tier plan for payment: $620 for
Project Standard 2019, $1,030 Project Professional 2019 (both of which cover only one PC per
person), and a Project Server—which requires a quote for accurate pricing.
Pros and Cons of Microsoft Project
Nothing is perfect. Even Microsoft Project has its drawbacks. If you’re thinking of trying it out,
take a moment to look over its pros and cons.
Pros
 One of the biggest pros is that it’s Microsoft, and so it integrates with the company’s
other products, most notably Office 365, but also Skype and Sharepoint.
 It has a similar interface to other MS products.
 It’s been around for a long time, and its features have developed over time.
 It’s part of Microsoft and has the reliability and support that coming from such an
established company represents.
 It has financial management tools that help project managers with estimating budgets.
 It can be licensed as a desktop application. While this might make it seem more like a
dinosaur, there are still organizations that will want this instead of a cloud solution.
 It has templates to help users get started, which saves time.
Cons
 It’s a desktop application. Yes, this was a pro, as well, but the number of organizations
that want a project management software that is siloed is rare.
 Though MS Project does have a cloud-based solution, it is not very agile. Even with
Sharepoint, which is designed to take advantage of the cloud, MS Project has great
limitations on the cloud.
 It’s difficult to learn and use. There’s a lot of time and effort, and even intensive training,
that must first be invested in the software before project managers and their teams are
comfortable using the software. This adds time to the project during the implementation
stage.
 It’s expensive. The prices quoted above, again, are per person, per month. This quickly
adds up as you buy licenses for team members who must have access to the software in
order to take advantage of its collaborative features. Otherwise, it’s more of an expensive
tool solely for the project manager.
 It’s not shareable. As mentioned earlier, files are saved as MPP, a proprietary format, so
that if you’re not using MS Project, you can’t read those files. This would be less of a
problem if the software was less expensive, but if you must have a MS Project license to
view a MPP file, then it adds up. This creates a lot of unnecessary hurdles when sharing
project files.
Project plan:
Create a project in Project desktop
In Project, you can:
 Create project plans.
 Build project teams and allocate resources.
 See different views of task and resources.
 Measure progress.
 Manage budgets.

Notes:
 This Quick Start is specific to Microsoft Project 2019, 2016, and the Microsoft 365
subscription Project Online Desktop Client. Project Online has some additional features that
support online interaction. 
 For more detailed information about creating a new project, see Create a new project.
Create a project from a template
1. Open Project.
Or select File > New if you're already working in a project plan.
2. Select a template or type in the Search for online templates box and then press Enter.
Or, choose Blank Project to create a project from scratch.
3. When you select a template, select the options you want, and select Create.
Change the resources, tasks, and durations in the template so they are right for your project.
Note: To create a new project from an existing project, change the project start and finish dates,
and then save the project file with a new name or in a different location.

Add tasks to a project

1. Select View > Task Views > Gantt Chart.
2. Type a task name in the first empty Task Name field.
3. Press Enter.
 4. Repeat steps 2 and 3 to enter the tasks you want.
If adding tasks one at a time starts to take too long, you can also:
 Add multiple tasks at once.
 Cut and paste a list from another program.
 Import a tasks list from a SharePoint site.
EXP 7: Define the Functional and Nonfunctional requirements of the system to
be automated by using Usecases and Document in SRS document.

Requirements are essential signs on the road that leads to a successful project. They establish a
formal agreement between a client and a provider that they are both working to reach the same
goal. High-quality, detailed requirements also help mitigate financial risks and keep the project
on a schedule. According to the Business Analysis Body of Knowledge definition,
requirements are a usable representation of a need.
Creating requirements is a complex task as it includes a set of processes such as elicitation,
analysis, specification, validation, and management. In this article, we’ll discuss the main types
of requirements for software products and provide a number of recommendations for their use.
Classification of requirements
Prior to discussing how requirements are created, let’s differentiate their types.

High-level requirements cascade down to specific details

Business requirements. These include high-level statements of goals, objectives, and needs.
Stakeholder requirements. The needs of discrete stakeholder groups are also specified to
define what they expect from a particular solution.
Solution requirements. Solution requirements describe the characteristics that a product must
have to meet the needs of the stakeholders and the business itself.
 Nonfunctional requirements describe the general characteristics of a system. They are
also known as quality attributes.
 Functional requirements describe how a product must behave, what its features and
functions.
Transition requirements. An additional group of requirements defines what is needed from an
organization to successfully move from its current state to its desired state with the new product.
Let’s explore functional and nonfunctional requirements in greater detail.
Functional requirements and their specifications
Functional requirements are product features or functions that developers must implement to
enable users to accomplish their tasks. So, it’s important to make them clear both for the
development team and the stakeholders. Generally, functional requirements describe system
behavior under specific conditions. For instance:
A search feature allows a user to hunt among various invoices if they want to credit an issued
invoice.
Here’s another simple example: As a guest, I want a sofa that I can sleep on overnight.
Requirements are usually written in text, especially for Agile-driven projects. However, they
may also be visuals. Here are the most common formats and documents:
 Software requirements specification document
 Use cases
 User stories
 Work Breakdown Structure (WBS) (functional decomposition)
 Prototypes
 Models and diagrams
Software requirements specification document
Functional and nonfunctional requirements can be formalized in the requirements specification
(SRS) document. (To learn more about software documentation, read our article on that topic.)
The SRS contains descriptions of functions and capabilities that the product must provide. The
document also defines constraints and assumptions. The SRS can be a single document
communicating functional requirements or it may accompany other software documentation
like user stories and use cases.
We don’t recommend composing SRS for the entire solution before the development kick-off,
but you should document the requirements for every single feature before actually building it.
Once you receive the initial user feedback, you can update the document.
SRS must include the following sections:
Purpose. Definitions, system overview, and background.
Overall description. Assumptions, constraints, business rules, and product vision.
Specific requirements. System attributes, functional requirements, database requirements.
It’s essential to make the SRS readable for all stakeholders. You also should use templates with
visual emphasis to structure the information and aid in understanding it. If you have
requirements stored in some other document formats, link to them to allow readers to find the
needed information.
Example: If you’d like to see an actual document, download this SRS example created at
Michigan State University, which includes all points mentioned above in addition to presenting
use cases to illustrate parts of the product.
Use cases
Use cases describe the interaction between the system and external users that leads to achieving
particular goals.
Each use case includes three main elements:
Actors. These are the users outside the system that interact with the system.
System. The system is described by functional requirements that define an intended behavior of
the product.
Goals. The purposes of the interaction between the users and the system are outlined as goals.
There are two formats to represent use cases:
 Use case specification structured in textual format
 Use case diagram
A use case specification represents the sequence of events along with other information that
relates to this use case. A typical use case specification template includes the following
information:
 Description
 Pre- and Post- interaction condition
 Basic interaction path
 Alternative path
 Exception path
Example:

Use case specification template

A use case diagram doesn’t contain a lot of details. It shows a high-level overview of the
relationships between actors, different use cases, and the system.
The use case diagram includes the following main elements:
Use cases. Usually drawn with ovals, use cases represent different use scenarios that actors
might have with the system (log in, make a purchase, view items, etc.)
System boundaries. Boundaries are outlined by the box that groups various use cases in a
system.
Actors. These are the figures that depict external users (people or systems) that interact with the
system.
Associations. Associations are drawn with lines showing different types of relationships
between actors and use cases.
Example:
 Use case diagram example
User stories
A user story is a documented description of a software feature seen from the end-user
perspective. The user story describes what exactly the user wants the system to do. In Agile
projects, user stories are organized in a backlog, which is an ordered list of product functions.
Currently, user stories are considered to be the best format for backlog items.
A typical user story is written like this:
As a <type of user>, I want <some goal> so that <some reason>.
Example:
As an admin, I want to add descriptions to products so that users can later view these
descriptions and compare the products.
User stories must be accompanied by acceptance criteria. These are the conditions that the
product must satisfy to be accepted by a user, stakeholders, or a product owner. Each user story
must have at least one acceptance criterion. Effective acceptance criteria must be testable,
concise, and completely understood by all team members and stakeholders. They can be written
as checklists, plain text, or by using Given/When/Then format.
Example:
Here’s an example of the acceptance criteria checklist for a user story describing a search
feature:
 A search field is available on the top-bar.
 A search is started when the user clicks Submit.
 The default placeholder is a grey text Type the name.
 The placeholder disappears when the user starts typing.
 The search language is English.
 The user can type no more than 200 symbols.
 It doesn’t support special symbols. If the user has typed a special symbol in the search
input, it displays the warning massage: Search input cannot contain special symbols.
Finally, all user stories must fit the INVEST quality model:
 I – Independent
 N – Negotiable
 V – Valuable
 E – Estimable
 S – Small
 T – Testable
Independent. This means that you can schedule and implement each user story separately. This
is very helpful if you implement continuous integration processes.
Negotiable. This means that all parties agree to prioritize negotiations over specification. This
also means that details will be created constantly during development.
Valuable. A story must be valuable to the customer. You should ask yourself from the
customer’s perspective “why” you need to implement a given feature.
Estimatable. A quality user story can be estimated. This will help a team schedule and
prioritize the implementation. The bigger the story is, the harder it is to estimate it.
Small. Good user stories tend to be small enough to plan for short production releases. Small
stories allow for more specific estimates.
Testable. If a story can be tested, it’s clear enough and good enough. Tested stories mean that
requirements are done and ready for use.
EXP 8: Define the following traceability matrices:
1. Usecase Vs Features
Features:
Once we understand user needs, we translate them into features – one or more features meet one
or more user needs.

Features are descriptions of high-level product functionality. Usually a feature is something

you’ll print on a detailed datasheet of your product – i.e. to share with your customers and
prospective customers.

Use Cases:
We then derive one or more use cases from each feature. A use case defines how a user
achieves a goal using our product.

Here’s how use cases are related to requirements:

 Use cases are a way to document a specific type of requirement – called “Functional
Requirements”. There are many benefits to using use cases to document functional
requirements.
Requirements:
After defining use cases, we define other types of requirements – such as non-functional
requirements, UI requirements, etc.

Typical Workflow
In a typical project – we start by understanding user needs. Then we translate needs
into features. We then create functional requirements – i.e. use cases – to describe how users
will achieve a need using our product. Then we define other types of requirements: non-
functional requirements, UI requirements, etc.

For those of you who like pictures, here you go!

Finally, we send all of these to the engineering team – who use them to build an awesome
product!
EXP 9 :Estimate the effort using the following methods for the systems to be
automated

1. Function point metric

2. Usecase point metric

Function Point Metric(FPM)

This metric overcomes the shortcoming of the LOC metric

Why we use it? Because it can be used to easily estimate the size of the software product
directly from the problem specification. The conceptual Idea behind the FPM is that size of
the software product is directly dependent on the number of different functions or features it
supports.

Steps to compute function point:

• When function is invoked, read some input data and transform it to corresponding output
data.

Example the issue book feature of a library automation software takes the name of the book
as input and displays its location and the number of copies available.

• Beside using the number of the input and output data values function point metric computes
the size of a software product(in unit of function points or FPs.)

Function point is computed in two steps:

1) computing the unadjusted function point(UFP): UFP is refined to reflect the

differences in the complexity of the different parameters.

UFP=(number of input)*4+(number of outputs)*5+(number of enquiries)*4+(number of

files)*10+ (number of interfaces)*10
1) number of inputs: In this is data item input by the user is counted. Data import should be
distinguished from the inquiries.

2) Individual data items input by the user are not considered in the calculation of the number
of input, but a group of related inputs are considered as single input.
Example:

3) Number of outputs: it refers to- reports printed, screen outputs, error messages produced

While outputting the number of output individual data items with in a reports are not
considered, but a set of related data items is counted as one input.

4) number of inquiries: Distinct interactive queries which can be made by the users. This
inquiries are the user commands which require specified action by the system.
5) Number of files: Each logical file is counted.

6) Number of interface: Interfaces used to exchange information with other systems.

Once the unadjusted function point is computed, the technical complexity factor(TCF)
is computed next.

TCF refines the UFP measured by considering 14 other factors such as high transaction rate,
throughput, and response time requirement etc.

Each of these 14 factor is assigned from 0(not present or no influence) to 6 (strong influence).
The resulting number are summed, yielding the total degree of influence (DI).

Now TCF is computed as

=(0.65+0.1*DI)

and DI vary from 0-84 and TCF Vary from (0.65-1.35)

so FP=UFP*TCF

Shortcomings of Function Point Metric:

• Subjective Evaluations: It needs subjective evaluation with a lot of judgement involved.

 • Conversion need: Many efforts and models are based on LOC, a function point need to be
converted.

• Less Researched Data: Less research data is available on function point as compared to
LOC.

• Late performance: It is performed after creation of design specification.

• Low Accuracy: It has low accuracy of evaluating as a subjective judgement is involved.

• Long learning curve: As the learning curve is quite long it's not easy to gain proficiency.

• Time consuming: It is a time consuming method as less research data is available which
generate low accuracy and less effective results.
3. Usecase point metric

Unadjusted Use Case Weight (UUCW)[edit]

The UUCW is one of the factors that contribute to the size of the software being developed. It is
calculated based on the number and complexity of the use cases for the system. To find the
UUCW for a system, each of the use cases must be identified and classified as Simple, Average
or Complex based on the number of transactions the use case contains. Each classification has a
predefined weight assigned. Once all use cases have been classified as simple, average or
complex, the total weight (UUCW) is determined by summing the corresponding weights for
each use case. The following chart shows the different classifications of use cases based on the
number of transactions and the weight value assigned for each use case within the classification.
Use Case Classification No. of Transactions Weight

Simple 1 to 3 transactions 5

Average 4 to 7 transactions 10

Complex 8 or more transactions 15

UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) +
(Total No. Complex Use Cases x 15)
Unadjusted Actor Weight (UAW)[edit]
The UAW is another factor that contributes to the size of the software being developed. It is
calculated based on the number and complexity of the actors for the system. Similar to finding
the UUCW, each of the actors must be identified and classified as Simple, Average or Complex
based on the type of actor. Each classification also has a predefined weight assigned. The UAW
is the total of the weights for each of the actors. The following chart shows the different
classifications of actors and the weight value assigned.
Actor
Type of Actor Weight
Classification

External system that must interact with the system using a well-
Simple 1
defined API

External system that must interact with the system using standard
Average 2
communication protocols (e.g. TCP/IP, FTP, HTTP, database)

Complex Human actor using a GUI application interface 3

UAW = (Total No. of Simple actors x 1) + (Total No. Average actors x 2) + (Total No.
Complex actors x 3)
Technical Complexity Factor (TCF)[edit]
The TCF is one of the factors applied to the estimated size of the software in order to account
for technical considerations of the system. It is determined by assigning a score between 0
(factor is irrelevant) and 5 (factor is essential) to each of the 13 technical factors listed in the
table below. This score is then multiplied by the defined weighted value for each factor. The
total of all calculated values is the technical factor (TF). The TF is then used to compute the
TCF with the following formula:
TCF = 0.6 + (TF/100)
Factor Description Weight

T1 Distributed system 2.0

T2 Response time/performance objectives 1.0

T3 End-user efficiency 1.0

T4 Internal processing complexity 1.0

T5 Code reusability 1.0

T6 Easy to install 0.5

T7 Easy to use 0.5

T8 Portability to other platforms 2.0

T9 System maintenance 1.0

T10 Concurrent/parallel processing 1.0

T11 Security features 1.0

T12 Access for third parties 1.0

T13 End user training 1.0

Environmental Complexity Factor (ECF)[edit]

The ECF is another factor applied to the estimated size of the software in order to account for
environmental considerations of the system. It is determined by assigning a score between 0 (no
experience) and 5 (expert) to each of the 8 environmental factors listed in the table below. This
score is then multiplied by the defined weighted value for each factor. The total of all calculated
values is the environment factor (EF). The EF is then used to compute the ECF with the
following formula:
ECF = 1.4 + (-0.03 x EF)
Factor Description Weight

E1 Familiarity with development process used 1.5

E2 Application experience 0.5

E3 Object-oriented experience of team 1.0

E4 Lead analyst capability 0.5

E5 Motivation of the team 1.0

E6 Stability of requirements 2.0

E7 Part-time staff -1.0

E8 Difficult programming language -1.0

Use Case Points (UCP)[edit]

Finally the UCP can be calculated once the unadjusted project size (UUCW and UAW),
technical factor (TCF) and environmental factor (ECF) have been determined. The UCP is
calculated based on the following formula:
UCP = (UUCW + UAW) x TCF x ECF

Example[edit]
To illustrate the process of calculating the UCP, an Online Shopping System will be used. The
diagram below depicts the Use Case Diagram for the system to be developed.

Unadjusted Use Case Weight (UUCW)[edit]

To calculate the UUCW, the use cases must be defined and the number of transactions for each
use case identified. The Online Shopping System use case diagram is depicting that nine use
cases exist for the system. Assuming 2 of these use cases are simple, 3 are average and 4 are
complex, the calculation for UUCW is as follows:

UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) +
(Total No. Complex Use Cases x 15)
For the Online Shopping System, the UUCW = (2 x 5) + (3 x 10) + (4 x 15) = 100
UUCW = 100
Unadjusted Actor Weight (UAW)[edit]
To calculate the UAW, the actors must be identified. The Online Shopping System use case
diagram is depicting five actors; One simple for the Payment Processing System and four
complex for each of the human users actors (i.e. Online Customer, Marketing Administrator,
Warehouse Clerk, Warehouse Manager.) The calculation for UAW is as follows:
UAW = (Total No. of Simple Actors x 1) + (Total No. Average Actors x 2) + (Total No.
Complex Actors x 3)
For the Online Shopping System, UAW = (1 x 1) + (0 x 2) + (4 x 3) = 13
UAW = 13
Technical Complexity Factor (TCF)[edit]
To calculate the TCF, each of the technical factors is assigned a value based on how essential
the technical aspect is to the system being developed. The diagram below shows the assigned
values for the Online Shopping System. The values are multiplied by the weighted values and
the total TF is determined.
Assigned Weight x Assigned
Factor Description Weight
Value Value

T1 Distributed system 2.0 5 10

Response time/performance
T2 1.0 5 5
objectives

T3 End-user efficiency 1.0 3 3

T4 Internal processing complexity 1.0 2 2

T5 Code reusability 1.0 3 3

T6 Easy to install 0.5 1 0.5

T7 Easy to use 0.5 5 2.5

T8 Portability to other platforms 2.0 2 4

T9 System maintenance 1.0 2 2

T10 Concurrent/parallel processing 1.0 3 3

T11 Security features 1.0 5 5

T12 Access for third parties 1.0 1 1

T13 End user training 1.0 1 1

Total (TF): 42

Next, the TCF is calculated:

TCF = 0.6 + (TF/100)
For the Online Shopping System, TCF = 0.6 + (42/100) = 1.02
TCF = 1.02
Environmental Complexity Factor (ECF)[edit]
To calculate the ECF, each of the environmental factors is assigned a value based on the team
experience level. The diagram below shows the assigned values for the Online Shopping
System. The values are multiplied by the weighted values and the total EF is determined.
Assigned Weight x Assigned
Factor Description Weight
Value Value

Familiarity with development

E1 1.5 3 4.5
process used

E2 Application experience 0.5 3 1.5

E3 Object-oriented experience of team 1.0 2 2

E4 Lead analyst capability 0.5 5 2.5

E5 Motivation of the team 1.0 2 2

E6 Stability of requirements 2.0 1 2

E7 Part-time staff -1.0 0 0

E8 Difficult programming language -1.0 4 -4

Total (EF): 10.5

Next, the ECF is calculated:

ECF = 1.4 + (-0.03 x EF)
 For the Online Shopping System, ECF = 1.4 + (-0.03 * 10.5) = 1.085
ECF = 1.085
Use Case Points (UCP)[edit]
Once the Unadjusted Use Case Weight (UUCW), Unadjusted Actor Weight (UAW), Technical
Complexity Factor (TCF) and Environmental Complexity Factor (ECF) has been determined,
the Use Case Points (UCP) can be calculated with the following formula:
UCP = (UUCW + UAW) x TCF x ECF
For the Online Shopping System, UCP = (100 + 13) x 1.02 x 1.085 = 125.06
UCP = 125.06
For the Online Shopping System, the total estimated size to develop the software is 125.06 Use
Case Points.
Now that the size of the project is known, the total effort for the project can be estimated. For
the Online Shopping System example, 28 man hours per use case point will be used.
Estimated Effort = UCP x Hours/UCP
For the Online Shopping System, Estimated Effort = 125.06 x 28
Estimated Effort = 3501 Hours
EXP 10 :Draw complete class diagram and object diagram using Relational
tools

Aim : To construct a class and object diagram using Relation tools

Required tools: Star UML or any other software for drawing

EXP 11 : Test a piece of code which executes a specific functionality to the code
to be tested and asserts a certain behaviour of state using J unit

What is Junit?

JUnit is an open source Unit Testing Framework for JAVA. It is useful for Java Developers to write
and run repeatable tests. Erich Gamma and Kent Beck initially develop it. It is an instance of xUnit
architecture. As the name implies, it is used for Unit Testing of a small chunk of code.

Developers who are following test-driven methodology must write and execute unit test first
before any code.

Once you are done with code, you should execute all tests, and it should pass. Every time any
code is added, you need to re-execute all test cases and makes sure nothing is broken.

What is Unit Testing?

Before discussing Junit testing in detail, it is imperative to understand what is Unit Testing?

Unit Testing is used to verify a small chunk of code by creating a path, function or a method. The
term "unit" exist earlier than the object-oriented era. It is basically a natural abstraction of an
object oriented system i.e. a Java class or object (its instantiated form).

Unit Testing and its importance can be understood by below-mentioned points:

7. Unit Testing is used to identify defects early in software development cycle.

8. Unit Testing will compel to read our own code. i.e. a developer starts spending more time
in reading than writing.
9. Defects in the design of code affect the development system. A successful code breeds the
confidence of developer.

Why you need JUnit testing

It finds bugs early in the code, which makes our code more reliable.
JUnit is useful for developers, who work in a test-driven environment.
 Unit testing forces a developer to read code more than writing.
You develop more readable, reliable and bug-free code which builds confidence during
development.

Features and advantages of JUnit5

JUnit has added many new features in JUnit4. You can understand it easily by comparing JUnit 3.x
and JUnit 4.x.

Below is quick comparison between JUnit4.x and JUnit 3.x -

All the old assert statements are same as before.

Most of the things are easier in JUnit4 as..
○ With JUnit 4 you are more capable of identifying exception. You can define expected
exception as a parameter while using @test annotation.
○ Parameterized test is introduced, which enables us to use parameters.
○ JUnit4 still can execute JUnit3 tests.
JUnit 4 can be used with java5 or higher version.
While using JUnit4, you are not required to extend JUnit.framework.TestCase. You can just
create a simple java class.
You need to use annotations in spite of special method name as before.
○ Instead of using setup method, you need to use @before annotation.
○ Instead of using teardown method, put @after annotation.
○ Instead of using testxxxx before method name, use @test annotation.

Example :

Step1 : create a java project named JUnitTest

Step2 : creare a package named testing

Step3 : create a class named JunitTesting in testing package

Step4 : in JunitTesting.java file write the below code

package testing;
public class JunitTesting {

public int square(int x) {

return x*x;

public int countA(String word) {

int count = 0;

for(int i = 0;i < word.length(); i++) {

if(word.charAt(i) == 'A' || word.charAt(i) == 'a') {

count++;

return count;

Step5 : create a JUnit test case with name squareTest and write the below code in squareTest.java
file

package testing;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

class squareTest {

@Test

void test() {
 JunitTesting test = new JunitTesting();

int output = test.square(5);

assertEquals(25,output);

Step 6 : run the squareTest.java file

Step 7 : create another testing file with named countATest and write the below code in the
countATest.java

package testing;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

class countATest {

@Test

void test() {

JunitTesting test = new JunitTesting();

int result = test.countA("alphabet");

assertEquals(2,result);

Step 8 : run the countATest.java file

Step 9 : write down the result of both the test cases.

EXP 12 : Define a complete call graph for any c/c++ code (note: The student
may use any tool that generate call graph for source code).

Call Graphs
CScout / clang++ & llvm can create call graphs that list how functions call each other. Keep in mind that the graphs only
indicate the calls detected by statically analyzing the program source. Calls via function pointers will not appear in the
call graph.

Two global options specify the format of the call graph and the content on each graph's node.
Through these options you can obtain graphs in

10. plain text form: suitable for processing with other tools,
11. HTML: suitable for browsing via CScout,
12. dot: suitable for generating high-quality graphics files,
13. SVG: suitable for graphical browsing, if your browser supports this format, and
14. GIF: suitable for viewing on SVG-challenged browsers.
All diagrams follow the notation

calling function -> called function

Two links on the main page (function and macro call graph, and non-static function call graph)
can give you the call graphs of the complete program. For any program larger than a few
thousand lines, these graphs are only useful in their textual form. In their graphical form, even
with node information disabled, they can only serve to give you a rough idea of how the program
is structured. The following image depicts how the three different programs we analyzed in the
bin example relate to each other.

More useful are the call graphs that can be generated for individual functions or files. These can
allow you to see what paths can possibly lead to a given function (call graph of all callers), which
functions can be reached starting from a given function, the function in context, and how
functions in a given file relate to each other.

As an example, the following diagram depicts all paths leading to the setfile function.
Correspondingly, the functions that can be reached starting from the copy_file function appears
in the following diagram.

while the following shows the function setsymtab in context, depicting all the paths leading to it
(callers) and leaving from it (called functions).
Finally, the following is an example of how the functions in a single file (parse.c) relate to each
other.

Example :

#include <vector>

struct A {

A(int);

void f(); // not defined, prevents inlining it!

};

int main() {

std::vector<A> v;

v.push_back(42);

v[0].f();

Commands to create call graph :

$ clang++ -S -emit-llvm main1.cpp -o - |

opt -analyze -std-link-opts -dot-callgraph

$ cat callgraph.dot |

c++filt |

sed 's,>,\\>,g; s,-\\>,->,g; s,<,\\<,g' |

gawk '/external node/{id=$1} $1 != id' |

dot -Tpng -ocallgraph.png

Call Graph of the above code :