Software is a set of instructions, data or programs used to operate computers and

execute specific tasks. It is the opposite of hardware, which describes the physical
aspects of a computer. Software is a generic term used to refer to
applications, scripts and programs that run on a device. It can be thought of as the
variable part of a computer, while hardware is the invariable part.

Challenges of Software Developers:

1. Changing Requirements during the development process brings challenges for the software
developers. Sometimes they won’t be able to deal with changing requirements. 
 
2. Providing complete Security to the software applications is a major challenge for developers
as hackers are trying each moment there to hack the software applications and steal the
data. 
 
3. Sometimes Misinterpreted requirements to give rise to a problem as a result the software
product fails to give the actual result to the end-users. 
 
4. Many times software developers face problems during System and Application
integration leading to the failure of software projects also. 
 
5. Further Maintenance and Upgradation become a problem for software developers for some
software projects. 
 
6. Adapting to the latest Technology becomes a big challenge for software developers when
they don’t have sufficient experience with the latest market trends. 
 
7. Sometimes when the developers don’t get the appropriate Project infrastructure for the
development and deployment of projects they face problems in delivering the product. 
 
8. Getting Defects or Errors in the product during its last stage creates an unwanted challenge
for the software developers. 
 
9. Time limitations play a vital role in software development. When there is not sufficient time
for the development times the product doesn’t meet the quality standards as the developers
work under pressure and output decreases. 
 
10. When a new developer lacks proper Communication and Coordination with the other
developers of the same development team it creates a problem at some point. 
 
11. It feels like a common problem when one developer Works with another developer’s
code .This situation creates a problem for the developer as it takes a lot of time for the new
developer to understand the code. 
 
12. In last, most software developer’s face this problem if they Don’t get the required support
from the Project Manager/Leader, and sometimes it gets difficult to handle the relationship
between colleagues and managers which in terms decreases productivity. 
 

Software developers face a number of challenges in their work. Some of the

most common challenges include:

1. Complexity: Software systems have become increasingly complex, making it difficult for
developers to understand and manage all the components of a system.
2. Maintaining Quality: Ensuring the quality of software systems can be a challenging task,
as developers need to account for various factors such as performance, security, and
usability.
3. Meeting Deadlines: Developers often work under tight deadlines, which can make it
difficult to ensure the quality of the final product.
4. Keeping up with new technologies: Software development is a rapidly evolving field, and
developers must constantly learn new technologies and programming languages to stay
current.
5. Managing changing requirements: Software development projects often involve working
with changing requirements, which can make it difficult for developers to plan and manage
their work effectively.
6. Collaboration: Collaborating with other team members, such as project managers,
designers, and other developers, can be challenging as everyone have different working
styles and goals.
7. Debugging: Debugging software can be time-consuming and complex, particularly for large
and complex systems.
8. Dealing with legacy code: Developers often have to work with legacy code, which can be
difficult to understand and maintain.
9. Managing complexity in distributed development: Developing software in a distributed
environment, where team members are located in different parts of the world, can be
challenging, as it requires effective communication and coordination.
10. Balancing short-term and long-term goals: While developers want to deliver the software
as soon as possible, they also want to ensure that the software is maintainable and
scalable in the long-term.
Software metrics can be classified into three categories −
 Product metrics − Describes the characteristics of the product such as size, complexity,
design features, performance, and quality level.
 Process metrics − These characteristics can be used to improve the development and
maintenance activities of the software.
 Project metrics − This metrics describe the project characteristics and execution. Examples
include the number of software developers, the staffing pattern over the life cycle of the
software, cost, schedule, and productivity.
Some metrics belong to multiple categories. For example, the in-process quality metrics of a project
are both process metrics and project metrics.
Software quality metrics are a subset of software metrics that focus on the quality aspects of the
product, process, and project. These are more closely associated with process and product metrics
than with project metrics.
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 −

 Mean Time to Failure

 Defect Density
 Customer Problems
 Customer Satisfaction
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.
Defect Density
It measures the defects relative to the software size expressed as lines of code or function point, etc.
i.e., it measures code quality per unit. This metric is used in many commercial software systems.

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
Where,
Number of license-month of the software = Number of install license of the software ×
Number of months in the calculation period
PUM is usually calculated for each month after the software is released to the market, and also for
monthly averages by year.

Customer Satisfaction
Customer satisfaction is often measured by customer survey data through the five-point scale −

 Very satisfied
 Satisfied
 Neutral
 Dissatisfied
 Very dissatisfied
Satisfaction with the overall quality of the product and its specific dimensions is usually obtained
through various methods of customer surveys. Based on the five-point-scale data, several metrics
with slight variations can be constructed and used, depending on the purpose of analysis. For
example −

 Percent of completely satisfied customers

 Percent of satisfied customers
 Percent of dis-satisfied customers
 Percent of non-satisfied customers
Usually, this percent satisfaction is used.

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 −

 Defect density during machine testing

 Defect arrival pattern during machine testing
 Phase-based defect removal pattern
 Defect removal effectiveness
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. Higher defect rates found during testing is an indicator that
the software has experienced higher error injection during its development process, unless the higher
testing defect rate is due to an extraordinary testing effort.
This simple metric of defects per KLOC or function point is a good indicator of quality, while the
software is still being tested. It is especially useful to monitor subsequent releases of a product in the
same development organization.

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. It includes the following
−
 The defect arrivals or defects reported during the testing phase by time interval (e.g., week).
Here all of which will not be valid defects.
 The pattern of valid defect arrivals when problem determination is done on the reported
problems. This is the true defect pattern.
 The pattern of defect backlog overtime. This metric is needed because development
organizations cannot investigate and fix all the reported problems immediately. This is a
workload statement as well as a quality statement. If the defect backlog is large at the end of
the development cycle and a lot of fixes have yet to be integrated into the system, the stability
of the system (hence its quality) will be affected. Retesting (regression test) is needed to ensure
that targeted product quality levels are reached.

Phase-based defect removal pattern

This is an extension of the defect density metric during testing. In addition to testing, it tracks the
defects at all phases of the development cycle, including the design reviews, code inspections, and
formal verifications before testing.
Because a large percentage of programming defects is related to design problems, conducting formal
reviews, or functional verifications to enhance the defect removal capability of the process at the front-
end reduces error in the software. The pattern of phase-based defect removal reflects the overall
defect removal ability of the development process.
With regard to the metrics for the design and coding phases, in addition to defect rates, many
development organizations use metrics such as inspection coverage and inspection effort for in-
process quality management.

Defect removal effectiveness

It can be defined as follows −
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. The higher the value of the metric, the more effective
the development process and the fewer the defects passed to the next phase or to the field. This
metric is a key concept of the defect removal model for software development.

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.

 Fix backlog and backlog management index

 Fix response time and fix responsiveness
 Percent delinquent fixes
 Fix quality

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. Using it in the format of a trend chart, this metric can provide meaningful information for
managing the maintenance process.
Backlog Management Index (BMI) is used to manage the backlog of open and unresolved problems.
If BMI is larger than 100, it means the backlog is reduced. If BMI is less than 100, then the backlog
increased.

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.

Percent delinquent fixes

It is calculated as follows −

Fix Quality
Fix quality or the number of defective fixes is another important quality metric for the maintenance
phase. A fix is defective if it did not fix the reported problem, or if it fixed the original problem but
injected a new defect. For mission-critical software, defective fixes are detrimental to customer
satisfaction. The metric of percent defective fixes is the percentage of all fixes in a time interval that is
defective.
A defective fix can be recorded in two ways: Record it in the month it was discovered or record it in
the month the fix was delivered. The first is a customer measure; the second is a process measure.
The difference between the two dates is the latent period of the defective fix.
Usually the longer the latency, the more will be the customers that get affected. If the number of
defects is large, then the small value of the percentage metric will show an optimistic picture. The
quality goal for the maintenance process, of course, is zero defective fixes without delinquency.

Software Measurement and Metrics

Software Measurement: A measurement is a manifestation of the size, quantity, amount, or dimension of
a particular attribute of a product or process. Software measurement is a titrate impute of a characteristic of
a software product or the software process. It is an authority within software engineering. The software
measurement process is defined and governed by ISO Standard. 

Software Measurement Principles: 

The software measurement process can be characterized by five activities-

1. Formulation: The derivation of software measures and metrics appropriate for the representation of
the software that is being considered.
2. Collection: The mechanism used to accumulate data required to derive the formulated metrics.
3. Analysis: The computation of metrics and the application of mathematical tools.
4. Interpretation: The evaluation of metrics resulting in insight into the quality of the representation.
5. 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: 
1. Direct Measurement: In direct measurement, the product, process, or thing is measured directly using
a standard scale.
2. Indirect Measurement: In indirect measurement, the quantity or quality to be measured is measured
using related parameters i.e. by use of reference.

Metrics: 

A metric is a measurement of the level at which any impute belongs to a system product or process. 
Software metrics will be useful only if they are characterized effectively and validated so that their worth
is proven. There are 4 functions related to software metrics: 
1. Planning
2. Organizing
3. Controlling
4. Improving

Characteristics of software Metrics: 

1. Quantitative: Metrics must possess quantitative nature. It means metrics can be expressed in values.
2. Understandable: Metric computation should be easily understood, and the method of computing
metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the development of the software.
4. Repeatable: The metric values should be the same when measured repeatedly and consistent in nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any programming language.

Classification of Software Metrics: 

There are 3 types of software metrics:  

1. 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.
2. Process Metrics: Process metrics pay particular attention to enhancing the long-term process of the
team or organization.
3. 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

Advantages of Software Metrics :

1. Reduction in cost or budget.

2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product,.
6. It helps to determine the complexity of the code and to test the code with resources.
7. It helps in providing effective planning, controlling and managing of the entire product.

Disadvantages of Software Metrics :

1. It is expensive and difficult to implement the metrics in some cases.

2. Performance of the entire team or an individual from the team can’t be determined. Only the
performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measure the unwanted data which is wastage of time.
5. Measuring the incorrect data leads to make wrong decision making.

Software Reliability
Software Reliability means Operational reliability. It is described as the ability of a system or
component to perform its required functions under static conditions for a specific period.
Software reliability is also defined as the probability that a software system fulfills its assigned task in a
given environment for a predefined number of input cases, assuming that the hardware and the input
are free of error.
Software Reliability is an essential connect of software quality, composed with functionality, usability,
performance, serviceability, capability, installability, maintainability, and documentation. Software
Reliability is hard to achieve because the complexity of software turn to be high. While any system
with a high degree of complexity, containing software, will be hard to reach a certain level of
reliability, system developers tend to push complexity into the software layer, with the speedy growth
of system size and ease of doing so by upgrading the software.

For example, large next-generation aircraft will have over 1 million source lines of software on-board;
next-generation air traffic control systems will contain between one and two million lines; the
upcoming International Space Station will have over two million lines on-board and over 10 million
lines of ground support software; several significant life-critical defense systems will have over 5
million source lines of software. While the complexity of software is inversely associated with software
reliability, it is directly related to other vital factors in software quality, especially functionality,
capability, etc.

Estimation is the process of finding an estimate, or approximation, which is a value that can be used
for some purpose even if input data may be incomplete, uncertain, or unstable.
Estimation determines how much money, effort, resources, and time it will take to build a specific
system or product. Estimation is based on −

 Past Data/Past Experience

 Available Documents/Knowledge
 Assumptions
 Identified Risks
The four basic steps in Software Project Estimation are −

 Estimate the size of the development product.

 Estimate the effort in person-months or person-hours.
 Estimate the schedule in calendar months.
 Estimate the project cost in agreed currency.

Observations on Estimation
 Estimation need not be a one-time task in a project. It can take place during −
o Acquiring a Project.
o Planning the Project.
o Execution of the Project as the need arises.
 Project scope must be understood before the estimation process begins. It will be helpful to
have historical Project Data.
 Project metrics can provide a historical perspective and valuable input for generation of
quantitative estimates.
  Planning requires technical managers and the software team to make an initial commitment as
it leads to responsibility and accountability.
 Past experience can aid greatly.
 Use at least two estimation techniques to arrive at the estimates and reconcile the resulting
values. Refer Decomposition Techniques in the next section to learn about reconciling
estimates.
 Plans should be iterative and allow adjustments as time passes and more details are known.

Software Estimation Approach:-

The Project Estimation Approach that is widely used is Decomposition Technique. Decomposition
techniques take a divide and conquer approach. Size, Effort and Cost estimation are performed in a
stepwise manner by breaking down a Project into major Functions or related Software Engineering
Activities.
Step 1 − Understand the scope of the software to be built.
Step 2 − Generate an estimate of the software size.
 Start with the statement of scope.
 Decompose the software into functions that can each be estimated individually.
 Calculate the size of each function.
 Derive effort and cost estimates by applying the size values to your baseline productivity
metrics.
 Combine function estimates to produce an overall estimate for the entire project.
Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost estimates
by breaking down a project into related software engineering activities.
 Identify the sequence of activities that need to be performed for the project to be completed.
 Divide activities into tasks that can be measured.
 Estimate the effort (in person hours/days) required to complete each task.
 Combine effort estimates of tasks of activity to produce an estimate for the activity.
 Obtain cost units (i.e., cost/unit effort) for each activity from the database.
 Compute the total effort and cost for each activity.
 Combine effort and cost estimates for each activity to produce an overall effort and cost
estimate for the entire project.
Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from Step
2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if widely divergent
estimates occur conduct further investigation concerning whether −
 The scope of the project is not adequately understood or has been misinterpreted.
 The function and/or activity breakdown is not accurate.
 Historical data used for the estimation techniques is inappropriate for the application, or
obsolete, or has been misapplied.
Step 5 − Determine the cause of divergence and then reconcile the estimates.