Good Afternoon all

Software Metrics

 metric is “ a quantitative measure of the degree to which a system,

component, or process possesses a given attribute”.

 A software metric is a measure of some property of a piece of software or its

specifications.
 Characteristics of Metrics
 simple and computable: It should be easy to learn how to derive the metric and its computation should not be effort and time

consuming.

 Empirically and intuitively persuasive: The metric should satisfy the engineer's intuitive notion about the product under

consideration. The metric should behave in certain ways, rising and falling appropriately under various conditions

 consistent and Objective: The metric should always yield results that are unambiguous. The third party would be able to

derive the same metric value using the same information

 consistent in its use of units and dimensions: It uses only those measures that do not lead to bizarre combinations of units

 Programming language independent

 an effective mechanism for quality feedback.

 metric should be defined in an unambiguous manner.

 Software metric domain can be partitioned into

 process,

 project,

 product

 Process metrics are used for software process improvement such as defect rates, errors
found during development.

 Project metrics are used by software project manager to adapt project work flows.
Types of Metrics

 Function Points (FP)

 Source Line Of Code (SLOC)

 Cyclomatic complexity
Common software metrics include:

 • Source lines of code

 • Cyclomatic complexity

 • Function point analysis

 • Code coverage

 • Number of classes and interfaces

 • Cohesion

 • Coupling
Cyclomatic Complexity Measures

 Cyclomatic complexity is a software metric used to indicate the complexity of

a program. It is a quantitative measure of the number of linearly independent

paths through a program's source code.

 Cyclomatic Complexity Measures
 "Cyclomatic complexity measures the number of linearly independent paths
through the method, which is determined by the number and complexity of
conditional branches. 

 How to Calculate Cyclomatic Complexity McCabe?

 P = number of disconnected parts of the flow graph (e.g. a calling program and a
subroutine)

 E = number of edges (transfers of control)

 N = number of nodes (sequential group of statements containing only one transfer of

control)

 calculate cyclomatic complexity (CYC): CYC = E – N + 2P

 Control Flow Graphs

 Cyclomatic complexity is a source code complexity measurement that is being

correlated to a number of coding errors. It is calculated by developing a Control Flow

Graph of the code that measures the number of linearly-independent paths through a

program module.
 Cyclomatic complexity = E - N + 2*P where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points

IF A = 10 THEN
IF B > C THEN
A= B
ELSE
A=C
ENDIF
ENDIF
Print A
Print B
Print C

The Cyclomatic complexity is calculated using the above control flow diagram that shows seven
nodes(shapes) and eight edges (lines), hence the cyclomatic complexity is 8 - 7 + 2 = 3
 Software Quality Metrics

 Software Quality Metrics means measurement of attributes, pertaining to software quality along

with its process of development. The term "software quality metrics" illustrate the picture of
measuring the software qualities by recording the number of defects or security loopholes present in
the software.
 Software quality metrics are a subset of software metrics that focus on the quality aspects of the
product, process, and project. 
 Software quality metrics can be further divided into three categories −
 Product quality metrics
 In-process quality metrics
 Maintenance quality metrics
 Product Quality Metrics

 This metrics include the following −

 1, Mean Time to Failure - It is the time between failures. This metric is mostly used with safety critical
systems such as the airline traffic control systems, avionics, and weapons.

 2, Defect Density - It measures the defects relative to the software size expressed as lines of code or
function point
 3, Customer Problems -It measures the problems that customers encounter when using the
product.  It contains the customer’s perspective towards the problem space of the software, which
includes the non-defect oriented problems together with the defect problems.

 The problems metric is usually expressed in terms of Problems per User-Month (PUM).

 PUM = Total Problems that customers reported (true defect and non-defect oriented problems) for
a time period + Total number of license months of the software during the period

 4, Customer Satisfaction - Customer satisfaction is often measured by customer survey data

through the five-point scale − Very satisfied , Satisfied , Neutral , Dissatisfied , Very dissatisfied
 In-process quality metrics
 In-process quality metrics deals with the tracking of defect arrival during formal machine testing for
some organizations. 

  This metric includes −

 1, Defect density during machine testing - Defect rate during formal machine testing (testing after
code is integrated into the system library) is correlated with the defect rate in the field

 2, Defect arrival pattern during machine testing - The overall defect density during testing will
provide only the summary of the defects. The pattern of defect arrivals gives more information about
different quality levels in the field.(testing phase )
 3, Phase-based defect removal pattern -  it tracks the defects at all phases of the

development cycle, including the design reviews, code inspections, and formal verifications

before testing.

 4, Defect removal effectiveness - This metric can be calculated for the entire development

process, for the front-end before code integration and for each phase. It is called early defect

removal when used for the front-end and phase effectiveness for specific phases.

 Maintenance Quality Metrics

 Although much cannot be done to alter the quality of the product during this phase, following are the fixes that

can be carried out to eliminate the defects as soon as possible with excellent fix quality.

 1, Fix backlog and backlog management index - Fix backlog is related to the rate of defect arrivals and the

rate at which fixes for reported problems become available. It is a simple count of reported problems that remain

at the end of each month or each week.

 If BMI is larger than 100, it means the backlog is reduced. If BMI is less than 100, then the backlog increased.
 2, Fix response time and fix responsiveness - The fix response time metric is usually calculated as
the mean time of all problems from open to close. Short fix response time leads to customer
satisfaction.

 The important elements of fix responsiveness are customer expectations, the agreed-to fix time, and
the ability to meet one's commitment to the customer.

 3, Percent delinquent fixes –

 4, Fix quality - A fix is defective if it did not fix the reported problem, or if it fixed the original
problem but injected a new defect.
What is Software Project planning ?
Software project management is an art and science of planning
and leading software projects. It is a sub-discipline of project
management in which software projects are planned,
implemented, monitored and controlled. 

Software Project Planning involves developing estimates for

the work to be performed, establishing the necessary
commitments, and defining the plan to perform the work. ...
Iterating through these steps may be necessary to establish
the plan for the software project
Steps

 Software Project Planning involves developing estimates for

 the work to be performed,
 establishing the necessary commitments,
 defining the plan to perform the work. ...

 Iterating through these steps may be necessary to establish the plan for

the software project 
Basic Project Planning Steps

 Create and Analyze Business Case.

 Identify and Meet Stakeholders for Approval.
 Define Project Scope.
 Set Goals and Objectives.
 Determine Deliverables.
 Create Project Schedule and Milestones.
 Assignment of Tasks.
 Carry Out Risk Assessment.
Project Planning
Software project planning starts before technical work start. The various steps of planning activities
are:

The size is the crucial parameter for the estimation of other activities. Resources requirement are
required based on cost and development time. Project schedule may prove to be very useful for
controlling and monitoring the progress of the project this is dependent on resources and
development time.
Objectives –
 The aim of theses processes is to ensure that various project tasks are well coordinated and
they meet the various project objectives including timely completion of the project.

 To introduce project planning.

 To examine the stages of project planning:
Scoping, estimation, risk analysis and scheduling.
 To focus on the tools available to a project
Planner.
 To explain the responsibilities of software manager.
Scope -
The resources and work that goes into the creation of a
product or service are essentially what defines the scope of
the project. The scope generally outlines the goals that will
be met to achieve a satisfactory result.

Steps for Defining the Scope of a Project

1. Project objectives
2. Sub-phases
3. Tasks
4. Resources
5. Budget
6. Schedule
7. Goals
Software Cost Estimation -
For any new software project, Several estimation procedures have been developed
and are having the following attributes in common.

1.Project scope must be established in advanced.

2.Software metrics are used as a support from which evaluation is made.
3.The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4.Delay estimation
5.Used symbol decomposition techniques to generate project cost and schedule
estimates.
6.Acquire one or more automated estimation tools.
Cost Estimation Models –
A model may be static or dynamic.
In a static model, a single variable is taken as a key element for calculating cost and time.
In a dynamic model, all variable are interdependent, and there is no basic variable.
     

Static, Single Variable Models: 

When a model makes use of single variables to calculate desired values
such as cost, time, efforts, etc
Decomposition Techniques-
Decompose the problem or software, re-characterizing it as a set of
smaller problem or software.

There are four types of decomposition techniques :

 Data decomposition
 Recursive decomposition
 Exploratory decomposition
 Speculative decomposition
Data decomposition-
Data decomposition is a highly effective technique for breaking work into small tasks that can be
parallelized.
Do it well, and performance of your games and visual applications will noticeably improve.

Example : Metric

A B E F
C D G H

P3 AE + BG AF + BH P1

P4 CE + DG CF + DH P2
Recursive decomposition-
Recursive decomposition process whereby any complex informational event at one level of

description can be specified more fully at a lower level of description by decomposing the event into:
a number of components and processes that specify the relations among these components.

Example : Merge sort

Exploratory decomposition

Exploratory decomposition is used to decompose whose underlying computations correspond to a search

of a space for solutions. In exploratory  problems decomposition, we partition the search space into
smaller parts, and search each one of these parts concurrently, until the desired solutions are found.

Example : Puzzle
Speculative decomposition-

Consider the situation of a switch statement in a program.

Usually we wait to know the value of the expression the switch is based on 

and execute only the case corresponding to it.

In speculative decomposition we execute some or all of the cases in advance.

 Switch case is best example

 This action to be taken is based on O\P of preceding part.

 Topological sorting
METRICS is a system of measurement. Accurate estimation of project size is
central to satisfactory estimation of all other project parameters such as efforts,
completion time, and total project cost.

What does “project size” exactly means?

The size of project is obviously not the number of bytes that the source code
occupies, neither is it the size of the executable code.
The size of the project is measure of the program complexity in terms of the
efforts and time required to complete the project.

The two most popular metrics used to measure project size-

1. Lines Of Code (LOC)
2. Function Point (FP)
LINE OF CODE (LOC) :
As the name suggests, LOC count the total number of lines of the source code in a project. Obviously, while counting the
number of source instructions , comment lines and header lines are ignored. LOC is possibly the simplest among all the
metrics available to measure project size.

Determining the LOC count at the end of a project is very simple. However, accurate estimation of LOC count at the
beginning of the project is a very difficult task.
One can possibly estimate the LOC count at the beginning by some form of systematic guessing. This guessing involves
the following-
Project manager will divide the project into different modules and these modules into sub modules, until the modules are
small enough to be predicted.
For this prediction, experience in developing similar modules is very helpful.
By adding the estimates for all modules together, project manager arrives at the total size estimation.
Shortcomings of the LOC Metric:

1. LOC is a measure of coding activity alone- The estimation should consider the total effort needed to carry
out various life cycle activities ( Specification, design, code, test etc) not just the coding efforts. When the
design and testing issues are very complex , the code size might be small and vice-versa.

2. LOC count depends on the choice of specific instruction- LOC gives a numerical value of problem size
i.e., number of lines in the source code but the length of the codes developed by different developers can
vary. One might write several instructions in single line, whereas other might split single instruction
across several lines.

3. LOC measures correlates poorly with the quality and efficiency of the code- Larger code size does not
necessarily imply better quality of code or higher efficiency….
Calculating productivity as length of the code may encourage programmers to write lots of poor quality
code rather fewer lines of high quality code to achieve the same functionality.

4. LOC metric measures the lexical complexity of a program and does not address the more important
issues of logical and structural complexities- Logic of the program defines the quality of that program not
the length of the code.

5. It is very difficult to accurately estimate LOC of the final program from program specification-At project
initiation time, it is a very difficult task to accurately estimate the number of lines of code that the program
would have after development.
Advantages of LOC :

 1. Universally accepted and is used in many models like COCOMO.

 2. Estimation is closer to developer’s perspective.

 FUNCTION POINT (FP) METRIC :
 Function point metric was proposed by Albrecht in 1983. This metric overcomes many of the

shortcomings of the LOC metric.

 function point metric has steadily gained popularity.

 The conceptual idea - The size of a software product is directly dependent on the number of different

high level functions or features it supports. This assumption is reasonable, since each feature would

take additional effort to implement.

 Though each feature takes some effort to develop, different features take very different amounts of

efforts. A simple function will require very less efforts whereas a complex function requires too many

efforts.
In function point metric,

The project manager counts the number of input and output data items and the number of files accessed by the

function.

The implicit assumption made is that the more the number of data items that a function reads from the user

and outputs and the more number of files accessed, the higher is the complexity of the function.

This gives more accurate indication of the code size compare to simply counting the number of high level

functions supported by the system.

FUNCTION POINT METRIC COMPUTATION :

The size of a software product ( in units of FPs) is computed using different characteristics of the product

identified in its requirement specification. It is computed using the following three steps:
• Step 1: Unadjusted function point(UFP) computation- UFP is basically the sum of the five
characteristics of a function i.e.,

UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 +

(Number of files)*10 + (Number of interfaces)*10

1. Number of inputs – Each data item input by the user is counted.

2. Number of Outputs – The outputs considered include screen outputs, error messages etc.
3. Number of inquiries – Inquiries are user commands that require no data input by the user, such as print
account balance.
4. Number of files – The total number of files accessed by the function including data structures and
physical files.
5. Number of interfaces – Here the interfaces denote the different mechanisms that are used to exchange
information with other systems.

The weights associated with the five characteristics were determined by Albrecht through data gathered
from many projects.
• Step 2: Refine parameters – UFP computed at the end of the step 1 is a gross indicator of the problem size.
 This UFP needs to be refined because some input values can be extremely complex and some can be
extremely simple. This is done by taking into account the complexity of the parameters by grading it into
three broad categories- Simple, Average, Complex.
 Weights of the different parameters in UFP are determined based on the numerical values shown in the Table
1. For example, rather than each input being computed as four FPs, very simple inputs are computed as three
FPs and very complex inputs as six FPs.
Table 1: Refinement of Function Point Entities

Type Simple Averag Complex

e
Input(I) 3 4 6
Output(O) 4 5 7
Inquiry(E) 3 4 6
Number of Files(F) 7 10 15
Number of Interfaces 5 7 10
• Step 3: Refine UFP based on complexity of the overall project –
In the final step, several factors that can impact the overall project size are considered to refine the UFP
computed in step 2. Albrecht identified 14 such factors or parameters that can influence the overall project
size. These are-
Requirement for backup and recovery.
Requirement for data communication.
Extent of complex data processing.
Performance requirement.
Extent of online data entries.
Extent of multi screen data input.
Extent of online updating of master files.
Extent of complex input, output, queries and files.
Extent of Reuse.
Extent of installation included in design.
Extent of multiple installation in an organisation and variety of customer organisations.
Extent of change and focus on ease of use.
Expected operational environment.
Extent of distributed processing.
Now, each of these parameters will be assigned a value from 0 (No influence) to 6 (Strong influence) then
these values of each parameter is added and the sum we get is called “Degree of Influence” (DI). After
this, a factor which is called Technical Complexity Factor (TCF) is computed, that is,

TCF= (0.65+0.01*DI)

As DI can vary from 0 to 84, TCF can vary from 0.65 to 1.49.
TCF expresses the overall impact of the project parameters on the development effort.
Then this TCF is multiplied with the UFP(Unadjusted function point) that we calculated in step 1 and
refined in step 2 to yield FP.

FP = TCF * UFP
 • UFP computation= (number of inputs)*4 +(number of outputs)*5 +
(number of inquiries)*4 +(number of files )*10 +(number of
Step 1 interfaces)*10

• Refine parameters on the basis of complexity of each parameter.

Step 2
• Calculate Degree of Influence(DI)by addition of values assigned to 14
parameters that affect the overall development efforts.
• Calculated Technical complexity factor(TCF)= 0.65+0.01*DI
Step 3 • Calculate FP = TCF * UFP.
Shortcomings of the Function Point(FP)
Metric :

 1. It needs evaluations with a lot of judgement involved.

 2. It can only be performed after creation of design specifications.
 3.It has low accuracy of evaluation as a subjective judgement is
involved.
 4.It is a time consuming method.
Example of FP Metric-

A supermarket needs to develop the following software to encourage regular customers. For this,

the customer needs to supply his/her name, address and telephone number. Each customer who

register for this scheme is assigned a unique Customer ID by the software. Based on the

generated ID, a clerk manually prepares a customer identity card after getting the market

manager’s signature on it. A customer can present his ID to the check out staff when he makes

any purchase. In this case, the value of his purchase is credited against his CN. At the end of the

year, the supermarket intends to award surprise gifts to 10 customers who make the highest total

purchase over the year. The entries against the ID are reset on the last day of every year after the

prize winners list is generated. Assume that various project characteristics determining the

complexity of the software to be average.

Answer:
Step 1: Calculating Unadjusted Function Point(UFP)
From an examination of the problem description, we find that there are-
3 inputs(Name, Address, Telephone number) , 2 outputs(Customer ID, List of winners), 2 files(customer
details, daily purchases), no inquiry ,no interfaces. Putting these values in UFP Formula

UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 + (Number of files)*10 +

(Number of interfaces)*10

UFP = 3*4 +2*5 + 0*4 + 2*10 + 0*10 = 42

Step 2: All the parameters are of moderate complexity except the customer ID output which is simple. By,
consulting table 1, we find that the value for simple output is given to be 4. So UFP can be refined as
UFP = 3*4 +(1*5+1*4) + 0*4 + 2*10 + 0*10
UFP= 41.

Step 3: Since the complexity adjustment factors have average values, that is 3 for each of the 14 factors so,
Degree of Influence, DI= 3*14= 42.
Putting this DI in formula of TCF( Technical Complexity Factor),

TCF=0.65+0.01*DI
TCF=0.65+0.01*41 = 1.06
Now, putting TCF and UFP in Function Point Metric formula

FP= TCF*UFP
FP= 1.06*41= 43.46
 LINE OF CODE (LOC) FUNCTION POINT (FP)
LOC counts the total number of lines of the FP counts the number of functions in a
source code in a program. program .

LOC only considers the coding effort. Whereas, FP considers various parameters
that affect the development efforts.

Estimation using LOC before the FP can be easily computed from the
development of program is tough. problem specification itself.

More research data is available in LOC. Comparatively, less research data is

available

LOC is Less accurate in comparison to FP. Comparatively, more accurate.

 Process Based Estimation

 The functions of the software are identified.

 The framework is formulated.

 Estimate effort to complete each software function.

 Apply average labor rates, compute the total cost and compare the estimates.

 The most common technique for estimating a project is to base the estimate on

the process that will be used.

 That is, the process is decomposed into a relatively small set of tasks and the effort required

to accomplish each task is estimated.

 Empirical Estimation Models

Introduction
 Estimation models for computer software use empirically derived formulas to

predict effort as a function of LOC or FP

 Resultant values computed for LOC or FP are entered into an estimation model

 The empirical data for these models are derived from a limited sample of projects

 Consequently, the models should be calibrated to reflect local software development

54
conditions
COCOMO Models

 Application composition model - Used during the early stages of software

engineering when the following are important
 Prototyping of user interfaces

 Consideration of software and system interaction

 Assessment of performance

 Evaluation of technology maturity

 Early design stage model – Used once requirements have been stabilized and
basic software architecture has been established

 Post-architecture stage model – Used during the construction of the software

55
COCOMO Cost Drivers

 Personnel Factors  Product Factors

 Applications experience  Required software reliability
 Programming language experience  Database size
 Virtual machine experience  Software product complexity
 Personnel capability  Required reusability
 Personnel experience  Documentation match to life cycle needs
 Personnel continuity  Product reliability and complexity
 Platform experience
 Language and tool experience

56

(More on next slide)

COCOMO Cost Drivers (continued)

 Platform Factors  Project Factors

 Execution time constraint  Use of software tools
 Main storage constraint
 Use of modern programming practices
 Computer turn-around time
 Required development schedule
 Virtual machine volatility
 Classified security application
 Platform volatility
 Multi-site development
 Platform difficulty
 Requirements volatility

57
Make/Buy Decision

 It is often more cost effective to acquire rather than develop software

 Managers have many acquisition options
 Software may be purchased (or licensed) off the shelf
 “Full-experience” or “partial-experience” software components may be acquired and
integrated to meet specific needs
 Software may be custom built by an outside contractor to meet the purchaser’s
specifications
 The make/buy decision can be made based on the following conditions
 Will the software product be available sooner than internally developed software?
 Will the cost of acquisition plus the cost of customization be less than the cost of
developing the software internally?
 Will the cost of outside support (e.g., a maintenance contract) be less than the cost of
58
internal support?

What is COCOMO?
• COCOMO is Constructive Cost Model, On the basic level it is
the cost estimation model.

• Using this model you can find or you can make estimates of the cost of your
project.

• Key Parameters of Model:

• Effort : Means how much amount of labor is required to

complete a task. (Unit: Person-Month).

• Schedule: Means amount of time required for the completion

Three Level of Projects

• Creator of COCOMO Model divide the project into 3 levels.

• Organic: Small team, Understood things, Previous experience and knowledge.

• Semi-detached : Big team(as compare to organic), Little bit knowledge is required.

• Embedded: Complex Project, Skill challenging, training is required, big team required.
Constant values

Project Level a b c d
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
 Equations

Basic Equations of COCOMO

Effort Applied (E) = a(KLOC)b [person-months]

• KLOC = (kilo – Line of Codes)

• [Person-Month] = This is unit means one month of effort by one person.

 Equations

Basic Equations of COCOMO

Development Time (D) = c(Effort Applied)d [months]

•Effort applied = Use the value from 1st equation.

•[Month] = It is the unit to measure the development time.

 Equations
Basic Equations of COCOMO

Average staff size (SS) = Effort Applied / Development Time [person]

[Person]= Unit how much person required.

Basic Equations End here

Constant values for Intermediate level
estimation

Software project a b
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
 Equations
Intermediate Level Equation of COCOMO

E = a(KLoC)b x EAF

• Part 1 of Equation a(KLoC)b :

Same as basic equation.

•Part 2 of Equation EAF :

EAF is effort adjustment factor, We get these from cost driver factors, given in table
on next slide.
COCOMO Tool
68
69
70
 Software Analysis

 Software analysis and design includes all activities, which help the transformation of requirement
specification into implementation.

 Software systems analysis is a field in which analysts continually learn new techniques and approaches to
properly capture, maintain, understand, and develop more efficient and effective software
systems. ... Systems analysis is the study of a system under consideration (which may be real or
imagined)

 In software engineering, requirements analysis focuses on the tasks that determine the needs or

conditions to meet the new or altered product or project, taking account of the possibly conflicting
requirements of the various stakeholders, analyzing, documenting, validating and managing software 
 Grid Charts: Grid charts are a tabular method of representing relationship between two sets of
factors. ...

 Simulation: ADVERTISEMENTS: ...

 System Flow Chart: ...

 Decision Tree: ...

 Decision Tables:

 Structure system analysis is also called Structured System Analysis and Design method (SSADM) and the
whole process allows control over the analysis stage to reduce the risk of making mistakes through
the process.

 Analysis Model is a technical representation of the system. It acts as a link between system description
and design model. In Analysis Modelling, information, behavior and functions of the system is defined
and translated into the architecture, component and interface level design in the design modeling.
7 Steps of Agile System Analysis Process

 Identify System Users.

 Define Main Users Goals.

 Define System Usage Patterns.

 Invent Functional Solution to Meet Users Goals and Usage Patterns.

 Define Main Navigation Paths.

 Create UI Mock-ups.

 Polish UI Elements.
 Software Design
 Software design is a process to transform user requirements into some suitable form, which helps the
programmer in software coding and implementation.

 Software design is the process by which an agent creates a specification of a software artefact intended
to accomplish goals, using a set of primitive components and subject to constraints.

 Three levels of phases of design:

 Interface Design.

 Architectural Design.

 Detailed Design.
Software Analysis & Design using
Conventional approach
 Data Modeling (ER Diagram),

 Functional Model & Information Flow (DFDs),

 Behavioral Modeling,

 Structured Analysis,

 Data Dictionary
Data Modeling

 Data modeling is a process used to define and analyze data requirements needed to support the business processes within
the scope of corresponding information systems in organizations.

 Data modeling defines not just data elements, but also their structures and the relationships between them.

 Data modeling is the process of documenting a complex software system design as an easily understood diagram, using
text and symbols to represent the way data needs to flow. The diagram can be used to ensure efficient use of data, as a
blueprint for the construction of new software

 Data modeling enabled organizations to bring consistency, repeatability and well-ordered development to data processing.

 Data modeling is an important skill for data scientists or others involved with data analysis. Traditionally, data models have
been built during the analysis and design phases of a project to ensure that the requirements for a new application are fully
understood.
 ER Diagram
 An Entity Relationship Diagram (ERD) is a visual representation of different entities within a system and how
they relate to each other. For example, the elements writer, novel, and a consumer may be described
using ER diagrams the following way: ER diagram with basic objects. They are also known
as ERD's or ER models.

 An ER diagram illustrates the logical structure of databases. ER diagrams are used to sketch out the design
of a database.
 Entity - An entity can be a person, place, event, or object that is relevant to a given system. For example, a school
system may include students, teachers, major courses, subjects, fees, and other items. Entities are represented in ER
diagrams by a rectangle and named using singular nouns.

 Weak Entity - A weak entity is an entity that depends on the existence of another entity. In more technical terms it can
be defined as an entity that cannot be identified by its own attributes. The order item will be meaningless without an order
so it depends on the existence of the order.

 Attribute - An attribute is a property, trait, or characteristic of an entity, relationship, or another attribute. For example,
the attribute Inventory Item Name is an attribute of the entity Inventory Item. however, attributes are represented by oval
shapes. Meanwhile, attributes can also have their own specific attributes. For example, the attribute “customer address”
can have the attributes number, street, city, and state. These are called composite attributes. Note that some top level ER
diagrams do not show attributes for the sake of simplicity. 
 Multivalued Attribute - If an attribute can have more than one value it is called a multi-valued attribute.  For example, a
teacher entity can have multiple subject values.

 Derived Attribute - An attribute based on another attribute. This is found rarely in ER diagrams. For example, for a
circle, the area can be derived from the radius.

 Relationship - A relationship describes how entities interact. For example, the entity “Carpenter” may be related to the
entity “table” by the relationship “builds” or “makes”. Relationships are represented by diamond shapes and are labelled
using verbs.

 Recursive Relationship - If the same entity participates more than once in a relationship it is known as a recursive
relationship. In the below example an employee can be a supervisor and be supervised, so there is a recursive
relationship.
 How to Draw ER Diagrams

 Below points show how to go about creating an ER diagram.

 Identify all the entities in the system. An entity should appear only once in a particular diagram. Create
rectangles for all entities and name them properly.

 Identify relationships between entities. Connect them using a line and add a diamond in the middle
describing the relationship.

 Add attributes for entities. Give meaningful attribute names so they can be understood easily.
 ER Diagram Best Practices

 Provide a precise and appropriate name for each entity, attribute, and relationship in the diagram. Terms
that are simple and familiar always beats vague, technical-sounding words. In naming entities, remember
to use singular nouns. However, adjectives may be used to distinguish entities belonging to the same class
(part-time employee and full-time employee, for example). Meanwhile attribute names must be
meaningful, unique, system-independent, and easily understandable.

 Remove vague, redundant or unnecessary relationships between entities.

 Never connect a relationship to another relationship.

 Make effective use of colors. You can use colors to classify similar entities or to highlight key areas in your
diagrams.

 Drawing ER Diagrams Using C



 Functional Model & Information Flow
  a function model or functional model is a structured representation of the functions (activities, actions, processes, operations) within the modelled system
or subject area.

 In the Functional Model, software converts information. and to accomplish this, it must perform at least three common tasks- input, processing and output.

 An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to
specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include
relations with individual things.

 An information flow diagram (IFD) is a diagram that shows how information is communicated (or "flows") from a source to a receiver or target (e.g.
A→C), through some medium.

 Structural analysis started as an Information Flow Modelling technique. A computer-based system can be modelled as an information transform function 

 A rectangle represents an external unit. That is, a system element, such as a hardware, a person or another system that provides information for
transformation by the software or receives information provided by the software. A circle is used to represent a process or transform or a function that is
applied to data and changes it in some way. An arrow is used to represent one or more data items.

 All arrows should be labelled in a DFD. The double line is used to represent data store. 
DFD

 A data-flow diagram is a way of representing a flow of data through a process or a

system (usually an information system). The DFD also provides information about the
outputs and inputs of each entity and the process itself.
 It shows how data enters and leaves the system, what changes the information, and
where data is stored.
 The objective of a DFD is to show the scope and boundaries of a system as a whole. It
may be used as a communication tool between a system analyst and any person who
plays a part in the order that acts as a starting point for redesigning a system. The DFD
is also called as a data flow graph or bubble chart. DFD is part of the structured-analysis
modeling tools.
 DFD levels are numbered 0, 1 or 2, and occasionally go to even Level 3 or beyond. The
necessary level of detail depends on the scope of what you are trying to
accomplish. DFD Level 0 is also called a Context Diagram. It's a basic overview of the
whole system or process being analyzed or modeled.
 DFD rules and tips

 Each process should have at least one input and an output.

 Each data store should have at least one data flow in and one data flow out.

 Data stored in a system must go through a process.

 All processes in a DFD go to another process or a data store

 Circle: A circle (bubble) shows a process that transforms data
inputs into data outputs.

 Data Flow: A curved line shows the flow of data into or out of
a process or data store.

 Data Store: A set of parallel lines shows a place for the

collection of data items. A data store indicates that the data is
stored which can be used at a later stage or by the other
processes in a different order. The data store can have an
element or group of elements.

 Source or Sink: Source or Sink is an external entity and acts

as a source of system inputs or sink of system outputs.
 Level 0 DFD
context diagram of the result management system
 context diagram represents the entire software
requirement as a single bubble with input and output data
denoted by incoming and outgoing arrows. Then the
system is decomposed and described as a DFD with
multiple bubbles. Parts of the system represented by each
of these bubbles are then decomposed and documented as
more and more detailed DFDs.

  It is essential to preserve the number of inputs and

outputs between levels, this concept is called levelling by
DeMacro.
DFD – Level 0
DFD

 https://www.javatpoint.com/software-engineering-data-flow-diagrams

 https://www.lucidchart.com/pages/data-flow-diagram
 Behavioral Modeling
 Behavioural Model is specially designed to make us understand behaviour and factors that influence behaviour of a
System. 

 Behaviour of a system is explained and represented with the help of a diagram. This diagram is known as State
Transition Diagram. It is a collection of states and events.

 Two types 

 sequence diagrams

 communication diagrams.

 A communication diagram offers the same information as a sequence diagram, but while a sequence
diagram emphasizes the time and order of events, a communication diagram emphasizes the messages
exchanged between objects in an application
 Advantages :

 Behaviour and working of a system can easily be understood without any effort.

 Results are more accurate by using this model.

 This model requires less cost for development as cost of resources can be minimal.

 It focuses on behaviour of a system rather than theories.

 Disadvantages :

o This model does not have any theory, so trainee is not able to fully understand basic principle and major
concept of modelling.

o This modelling cannot be fully automated.

o Sometimes, it’s not easy to understand overall result.

o Does not achieve maximum productivity due to some technical issues or any errors.
Structured Analysis

 “Structured analysis is a set of techniques and graphical tools that allow the analyst to

develop a new kind of system specification that are easily understandable to the user.

Analysts work primarily with their wits, pencil and paper.”

 The availability of CASE tools in the 1990s enabled analysts to develop and modify the
graphical SASD models.
 to develop a useful, high quality information system that will meet the needs of the end
user.
 Philosophy of structured analysis and design

 Analysts attempt to divide large, complex problems into smaller, more easily handled
ones. “Divide and Conquer”

 Top-Down approach (Classical SA), or Middle-Out (Modern SA)

 Functional view of the problem. “Form follows function”

 Analysts use graphics to illustrate their ideas whenever possible.

 Analysts must keep a written record.

Characteristics of a Good Analysis Method

 •Graphical with supporting text.

 •Allow system to be viewed in a top-down and partitioned fashion.

 •Minimum redundancies.

 •Reader should be able to predict system behaviour.

 •Easy to understand by user.

Structured Analysis Tools
 Data Dictionary

 Data Dictionary comprises two words i.e. data which simply means information
being collected through some sources and dictionary means where this information
is available.
 Data Dictionary can be defined as collection of information of all data elements or
contents of databases such as data types, text descriptions of system.
 It makes it easier for user and analyst to use data as well as understand and have
common knowledge about inputs, outputs, components of a database, and
intermediate calculations.
 The data dictionary is an essential component of any relational database.
 Defines data elements to avoid different interpretations.
 Element Name = Card Number
 •Definition = *Uniquely identifies a card*
 Why Data dictionary is essential ?

 There are less information and details provided by data models. So, a data dictionary is very essential and needed to have

proper knowledge and usage of contents.

 Data Dictionary provides all information about names that are used in system models.

 Data Dictionary also provides information about entities, relationships, and attributes that are present in system model.

 As a part of structured analysis and design tool, implementation of a data dictionary is done.
Data Dictionary – Notation

 •= is composed of
 •+ and
 •() element is optional
 •{} iteration
 •[] select one of a list of elements
 •| seperates choices of elements
 •** comments
 •@ identifier for a store (unique id)
 Object Oriented Analysis: Domain Analysis

 Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application,

system, or business

 by applying object-oriented programming, as well as using visual modelling throughout the software development

process

 to guide stakeholder communication and product quality.

 In software engineering, domain analysis, or product line analysis, is the process of analyzing

related software systems in a domain to find their common and variable parts.

 It is a model of wider business context for the system. ... It is a key method for realizing systematic software reuse.
 How to perform domain analysis

 You gather information from whatever sources of information are available:

 these include the domain experts;

 any books about the domain;

 any existing software and its documentation

 any other documents he or she can find.

Outputs

 (semi)formalized concepts 

 domain processes

 standards

 logical architectures

 Subsequent activities produce generic design fragments, frameworks, etc.

 Object Oriented approach Process (Use Case),

 A use-case is a scenario to describe the interaction between user and computer system.

 This model represents the user needs or user view of system.

 It also includes identifying the classes and their relationships to the other classes in the problem domain, that make up
an application.

 The Object-Oriented approach of Building Systems takes the objects as the basis.

 For this, first the system to be developed is observed and analyzed

 and the requirements are defined as in any other method of system development.

 Once this is often done, the objects in the required system are identified.

 For example, in the case of a Banking System, a customer is an object, a chequebook is an object, and even an account is an object.
 Object-Relational Model

 Set of regulations by which objects can be linked and which describes the meaning of the relationships.

 In the object relationship model, you maintain the connections between the different documents on a time and causal

basis.

 An Object relational model is a combination of a Object oriented database model and a Relational database model.

 So, it supports objects, classes, inheritance, polymorphism, encapsulation, data abstraction….. etc.

 just like Object Oriented models and has support for data types, tabular structures etc.
 Object- Behavioral Model
 The behaviour of objects is formally defined as a set of states and events representing the script
of object life cycles.
 The behaviour or operations of an object are its predefined functions. For example, a T.V. can show
picture , change channels, tune for a channel etc.
 simple - performs services on request and keeps no memory of previous services.
 always responds to a given input in exactly the same way regardless of its history
 Ex: Sort operations, mathematical functions, such as cosine or square root, search of a static binary tree
 State- condition that persists for a significant period of time that is distinguishable from other such conditions and is disjoint from them.
 A transition is a response to an event that causes a change in state.
 Ex: process in computer
o Continuous- the current output depend on the previous history in a smooth way.
o An object with continuous behaviour is one with an infinite or unbounded, set of conditions.
o Ex: digital filters
 UML

 UML, short for Unified Modeling Language, is a standardized modeling language consisting of an integrated set of

diagrams, developed to help system and software developers for specifying, visualizing, constructing, and

documenting the artefacts of software systems, as well as for business modeling and other non-software systems. 

 The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software

engineering that is intended to provide a standard way to visualize the design of a system.

 UML is a graphical language for visualizing, specifying, constructing, and documenting information about software-intensive

systems. 

 UML gives a standard way to write a system model, covering conceptual ideas.

 UML diagrams describe the boundary, structure, and the behavior of the system and the objects within it.
Types of UML diagram

Structure Diagrams. Behavioural Diagrams.

 Activity diagram
 Class diagram
 Sequence diagram
 Package diagram
 Use case diagram
 Object diagram  State diagram
 Component diagram  Communication diagram
 Interaction overview diagram
 Composite structure diagram
 Timing diagram
 Deployment diagram
Use Case Diagram

 The purpose of a use case diagram in UML is to demonstrate the different ways that a user might
interact with a system. 
 The system that shows the relationship between the user and the different use cases in which the user
is involved.

 Five symbols used in a use case diagram:

 System Domain Box

 Actor Figure

 Goal Oval

 Actor Initiator Arrow

 Actor Connector Line

Use case diagrams model the functionality of a system using actors and use cases. 

Class diagram
Object diagram
Activity diagram
State chart diagram
Thank you