Software Engineering

- Mukund Thakare
Software Measurement and Metrics
● Software measurement is study of size, quantity, amount, or dimension of a
particular attribute of a software product or software process.
Software Measurement Principles
The software measurement process can be characterized by five activities :
● Formulation: The derivation of software measures and metrics appropriate
for the representation of the software that is being considered.
● Collection: The mechanism used to accumulate data required to derive the
formulated metrics.
● Analysis: The computation of metrics and the application of mathematical
tools.
● Interpretation: The evaluation of metrics resulting in insight into the quality of
the representation.
● Feedback: Recommendation derived from the interpretation of product
metrics transmitted to the software team.
Need for Software Measurement
Software is measured to :

● Create the quality of the current product or process.

● Anticipate future qualities of the product or process.
● Enhance the quality of a product or process.
● Regulate the state of the project in relation to budget and schedule.
Classification of Software Measurement
There are 2 types of software measurement :

● Direct Measurement: In direct measurement, the product, process, or thing is measured

directly using a standard scale.
● Indirect Measurement: In indirect measurement, the quantity or quality to be measured is
measured using related parameters i.e. by use of reference.
Software Metrics
● A software metric is a measure of software characteristics which are
measurable or countable.
● Software metrics are valuable for many reasons, including measuring
software performance, planning work items, measuring productivity, and many
other uses.
● Within the software development process, many metrics are that are all
connected.
● Software metrics are similar to the four functions of management: Planning,
Organization, Control, or Improvement.
Software Metrics
● A software metric is a measure of software
characteristics which are measurable or countable.
● Software metrics are valuable for many reasons,
including measuring software performance, planning
work items, measuring productivity, and many other
uses.
● Within the software development process, many
metrics are that are all connected.
● Software metrics are similar to the four functions of
management: Planning, Organization, Control, or
Improvement.
Classification of Software Metrics
Product Metrics
● Product metrics are used to evaluate the state of the product, tracing risks and undercover prospective
problem areas. The ability of the team to control quality is evaluated.
Process Metrics
● Process metrics pay particular attention to enhancing the long-term process
of the team or organization.
Project Metrics
● The project matrix describes the project characteristic and execution process.
● Number of software developer
● Staffing patterns over the life cycle of software
● Cost and schedule
● Productivity
Fan-in/Fan-out
● Fan-in is a measure of the number of functions that call some other function
(say X).
● Fan-out is the number of functions which are called by function X.
● A high value for fan-in means that X is tightly coupled to the rest of the design
and changes to X will have extensive knock-on effects.
● A high value for fan-out suggests that the overall complexity of the control
logic needed to coordinate the called components.
Length of code
● This is measure of the size of a program. Generally, the large the size of the code of a program
component, the more complex and error-prone that component is likely to be.
● If an element consists of more than 30 subelements, it is highly probable that there is a serious
problem :

a) Methods should not have more than an average of 30 code lines (not counting line spaces and
comments).
b) A class should contain an average of less than 30 methods, resulting in up to 900 lines of code.
c) A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines.
d) Subsystems with more than 30 packages should be avoided. Such a subsystem would count up
to 900 classes with up to 810,000 lines of code.
e) A system with 30 subsystems would thus possess 27,000 classes and 24.3 million code lines.
Cyclomatic complexity
● This is a measure of the
control complexity of a
program. This control
complexity may be related
to program
understandability.
Length of identifiers
● This is a measure of the average length of distinct identifier in a program. The
longer the identifiers, the more understandable the program.
● Java identifiers
Depth of conditional nesting
● This is a measure of the depth of
nesting of if statements in a program.
Deeply nested if statements are hard
to understand and are potentially
error-prone.
Fog index
● This is a measure of the average length of words and sentences in
documents. The higher the value for the Fog index, the more difficult the
document may be to understand.
Advantages of Software Metrics
● Reduction in cost or budget.
● It helps to identify the particular area for improvising.
● It helps to increase the product quality.
● Managing the workloads and teams.
● Reduction in overall time to produce the product,.
● It helps to determine the complexity of the code and to test the code with
resources.
● It helps in providing effective planning, controlling and managing of the entire
product.
Disadvantages of Software Metrics
● It is expensive and difficult to implement the metrics in some cases.
● Performance of the entire team or an individual from the team can’t be
determined. Only the performance of the product is determined.
● Sometimes the quality of the product is not met with the expectation.
● It leads to measure the unwanted data which is wastage of time.
● Measuring the incorrect data leads to make wrong decision making.
Software Requirements
According to IEEE standard 729, a requirement is defined as follows:

● A condition or capability needed by a user to solve a problem or achieve an

objective
● A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification or other
formally imposed documents
● A documented representation of a condition or capability as in 1 and 2.
A software requirement can be of 3 types
● Functional requirements
● Non-functional requirements
● Domain requirements
Functional Requirements
● These are the requirements that the end user specifically demands as basic
facilities that the system should offer.
● It can be a calculation, data manipulation, business process, user interaction,
or any other specific functionality which defines what function a system is
likely to perform.
● All these functionalities need to be necessarily incorporated into the system
as a part of the contract.
● They are basically the requirements stated by the user which one can see
directly in the final product, unlike the non-functional requirements.
● For example, in a hospital management system, a doctor should be able to
retrieve the information of his patients.
Non-functional requirements
● These are basically the quality constraints that the system must satisfy
according to the project contract.
● Nonfunctional requirements, not related to the system functionality, rather
define how the system should perform The priority or extent to which these
factors are implemented varies from one project to other.
● deal with issues like:
○ Portability
○ Security
○ Maintainability
○ Reliability
○ Scalability
○ Performance
○ Reusability
○ Flexibility
Domain requirements
● Domain requirements are the requirements which are characteristic of a
particular category or domain of projects.
● Domain requirements can be functional or nonfunctional.
● Domain requirements engineering is a continuous process of proactively
defining the requirements for all foreseeable applications to be developed in
the software product line.
● The basic functions that a system of a specific domain must necessarily
exhibit come under this category.
● For instance, in an academic software that maintains records of a school or
college, the functionality of being able to access the list of faculty and list of
students of each grade is a domain requirement.
Requirements Engineering Process
● Requirements engineering is the process of identifying, eliciting, analyzing,
specifying, validating, and managing the needs and expectations of
stakeholders for a software system.
● The requirements engineering process is an iterative process that involves
several steps,Including:
○ Requirements elicitation
○ Requirements specification
○ Requirements verification and validation
○ Requirements management
Requirements Elicitation
● Requirements elicitation is the process of
gathering information about the needs and
expectations of stakeholders for a software
system.
● This is the first step in the requirements
engineering process and it is critical to the
success of the software development project.
● The goal of this step is to understand the
problem that the software system is intended
to solve, and the needs and expectations of
the stakeholders who will use the system.
● Interviews: These are one-on-one conversations with stakeholders to gather
information about their needs and expectations.
● Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
● Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
● Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
● Prototyping: This technique involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to validate
requirements.
● It’s important to document, organize and prioritize the requirements obtained from all
these techniques to ensure that they are complete, consistent and accurate.
Requirements specification
● Requirements specification is the process of
documenting the requirements identified in the
analysis step in a clear, consistent, and
unambiguous manner.
● This activity is used to produce formal software
requirement models.
● During specification, more knowledge about the
problem may be required which can again
trigger the elicitation process.
● The models used at this stage include ER
diagrams, data flow diagrams(DFDs), function
decomposition diagrams(FDDs), data
dictionaries, etc.
● Functional Requirements: These describe what the software system should
do. They specify the functionality that the system must provide, such as input
validation, data storage, and user interface.
● Non-Functional Requirements: These describe how well the software
system should do it. They specify the quality attributes of the system, such as
performance, reliability, usability, and security.
● Constraints: These describe any limitations or restrictions that must be
considered when developing the software system.
● Acceptance Criteria: These describe the conditions that must be met for the
software system to be considered complete and ready for release.
Requirements verification and validation
● Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
● Validation: It refers to a different set of tasks that ensures that the software
that has been built is traceable to customer requirements.
● If requirements are not validated, errors in the requirement definitions would
propagate to the successive stages resulting in a lot of modification and
rework.
● The main steps for this process include:
○ The requirements should be consistent with all the other requirements i.e no two requirements
should conflict with each other.
○ The requirements should be complete in every sense.
○ The requirements should be practically achievable.
○ Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
Requirements management
● Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on the
requirement and controlling the communication to relevant stakeholders.
● This stage takes care of the changing nature of requirements.
● Requirements management is the process of managing the requirements throughout the software
development life cycle, including tracking and controlling changes, and ensuring that the requirements
are still valid and relevant.
● Tracking and controlling changes: This involves monitoring and controlling changes to the requirements
throughout the development process, including identifying the source of the change, assessing the impact of
the change, and approving or rejecting the change.
● Version control: This involves keeping track of different versions of the requirements document and other
related artifacts.
● Traceability: This involves linking the requirements to other elements of the development process, such as
design, testing, and validation.
● Communication: This involves ensuring that the requirements are communicated effectively to all stakeholders
and that any changes or issues are addressed in a timely manner.
● Monitoring and reporting: This involves monitoring the progress of the development process and reporting on
the status of the requirements.
Advantages

● Helps ensure that the software being developed meets the needs and
expectations of the stakeholders
● Can help identify potential issues or problems early in the development
process, allowing for adjustments to be made before significant
● Helps ensure that the software is developed in a cost-effective and efficient
manner
● Can improve communication and collaboration between the development
team and stakeholders
Disadvantages
● Can be time-consuming and costly, particularly if the requirements gathering
process is not well-managed
● Can be difficult to ensure that all stakeholders’ needs and expectations are
taken into account
● Can be challenging to ensure that the requirements are clear, consistent, and
complete
● Changes in requirements can lead to delays and increased costs in the
development process.
● As a best practice, Requirements engineering should be flexible, adaptable,
and should be aligned with the overall project goals.
Thank you !!