Software Engineering Tutorial

Introduction SDLC

SDLC Models

Agile Model Big-bang Model Incremental Model Iterative Model Prototype Model RAD Model Spiral Model V-Model Waterfall Model Open Source Development Model

Software Management

Project Management Project Management Activities Project Management Tools

Software Metrics

Software Quality Metrics Halstead's Software Metrics Object Oriented Metrices Data Structure Metrics Overall Equipment Effectiveness Some Important Quality Metrics

Project Planning

Software project planning Cost Estimation Model

Software Configuration

Software Configuration Management Project Monitoring and Control

System Design

Strategies for System Design Caching in System Design Load Balancer – System Design Dropbox - System Design Netflix - System Design Twitter - System Design

Misc

Routing Requests through Load Balancers Object Oriented Analysis and Design in Software Engineering Online Library Management System ER Diagram in Software Engineering Umbrella Activities in Software Engineering Jelianska Moranda Software Relability Model RAD Model vs SDLC Model Software Myths in Software Engineering What is Capability Maturity Model Characteristics of Software Engineering Characteristics of Good Design in Software Engineering Program Analysis Tools in Software Engineering Reactive and Proactive Software Risk Management in Software Engineering Size-Oriented Metrics in Software Engineering Software Requirements and their Types in Software Engineering Structured Programming in Software Engineering System Development Life Cycle in MIS Difference between V Model and Waterfall Model Overview of Fish SDLC Model

Size-Oriented Metrics in Software Engineering
2023-06-30 19:03:46

Size-Oriented Metrics in Software Engineering

Size-oriented metrices act as an index between the direct evaluation of software and the software development cycle. Examples of these metrics include effort (time), expenditure (money), KLOC (thousands of lines of code), documentation pages written, mistakes, and team members.

There are several size-oriented metrices used in software engineering:

  • Lines of Code (LOC)
  • Function Points (FP)
  • Object Points (OP)
  • Source Lines of Code (SLOC)
  • Cyclomatic Complexity (CC)
  • Halstead Metrics
  • Code Coverage

To give a complete picture of the size, complexity, and functionality of a software system, these metrics can be utilized singly or in combination. We mainly use the LOC as the normalization value.

Lines of Code (LOC):

A simple and fundamental method for gauging the size of a computer programme is the Lines of Code (LOC) measure. This statistic is widely employed to gauge and assess programmers' productivity. LOC metrics are created by normalising quality and productivity statistics based on the size of the software product. By using the program's size as a statistic, the LOC metric provides a way to evaluate, track, and identify potential areas for improvement in the software development process. This approach has been widely used in software engineering to assess the size and complexity of software systems and to direct decision-making on software development.

Key points on the LOC Measures:

  • When using size-oriented metrics to determine the size and complexity of software systems, LOC is a frequent normalisation parameter.
  • Although this approach was created back when FORTRAN and COBOL programming were at their peak, it is still useful today.
  • Due to its increased reliance on KLOC, assembly language code often has a better productivity. The ratio of KLOC (thousands of lines of code) to EFFORT (measured in person-months) is the standard way to define productivity.
  • Size-oriented measurements like LOC can be helpful or useless depending on the programming language used, but precise LOC assessment requires a level of detail that, in some cases, may be impracticable.
  • Standardized way for calculating LOC is required because many organisations may employ different counting techniques, ensuring reliable comparisons across organisations.
  • Although size-oriented metrics, such as LOC, are frequently used in software engineering, their acceptance varies, and their efficacy can change depending on the situation and the unique requirements of a given project.
  • The LOC metric cannot be used for GUI-based projects that use forms rather than executable instructions.
  • Programming language productivity is inversely correlated with expressiveness, therefore extremely expressive languages may not be as productive.

The LOC/KLOC count can be used to derive numerous other software metrics, such as:

  • Errors/KLOC: The number of software errors per 1,000 lines of code is known as errors/KLOC.
  • $/ KLOC: The price per 1,000 lines of code is $/KLOC.
  • Defects/KLOC: The quantity of software flaws per 1,000 lines of code is known as defects/KLOC.
  • Pages of documentation/KLOC: The ratio of documentation pages per 1,000 lines of code is known as pages of documentation/KLOC.
  • Errors/PM: Errors/PM is the ratio of software errors per person-month of work.
  • Productivity = KLOC/PM (effort is measured in person-months): Productivity is defined as the number of lines of code produced per person per month of work (KLOC/PM).
  • $/ Page of documentation: The cost of creating one page of documentation is expressed as $/Page.

To assess the effectiveness and quality of the software development process, these metrics are frequently employed in software engineering. Developers can pinpoint areas for improvement and raise the calibre and productivity of their software systems by tracking and examining these indicators.

Size-Oriented Metrics Advantages and Disadvantages:

Advantages of LOC Metrics

  • Simplicity - One of the simplest methods for estimating the size of a software project is LOC. It only requires counting the number of lines of code in the programme, which is easy to do.
  • Standradization - LOC gives a consistent way to assess the amount of a software programme, making it possible to compare the efficiency of various programming languages or the output of various programmers.
  • Ease of calculation - Because LOC is a simple measure, it is quick and simple to calculate, making it a handy tool for project estimation and planning.
  • Scalability - LOC scales well for large software projects, giving a precise assessment of the program's size, complexity, and potential maintainability problems.
  • Reliability - LOC offers a reliable method to estimate the size of a piece of software because it is an objective statistic. This measurement can be used to estimate project costs, completion dates, and other resources.
  • Base for other metrics - As previously mentioned, LOC can be used as the basis for a number of other software metrics, such as errors/KLOC, productivity, and documentation/page, which can provide extra information about the program's effectiveness.
  • Data from the past - LOC gives a history of software development, enabling programmers to follow trends and track changes over time.

Disadvantages of LOC Metrics

  • Limited scope - LOC merely counts the size of the program's code and ignores other crucial elements like requirements, design, testing, or documentation of the software development process.
  • Misleading information - LOC can provide inaccurate information when contrasting several programming languages. For instance, a programme written in a language with greater expressiveness may need fewer lines of code than a programme written in a language with decreased expressiveness, but it may not always be more effective.

• Limited viewpoint - LOC only characterises one aspect of size, namely length, and ignores complexity or functionality. Therefore, maintaining a programme with a lower LOC may be more challenging and difficult than maintaining a programme with a larger LOC.

• Quality worries - Using LOC as the sole criterion to assess a programmer's output may promote bad programming practises such code duplication or excessive use of comments, which can result in bloated and less maintainable code.

• Language dependence - Because LOC metrics are language-dependent, they cannot be used to compare programmes created in various programming languages.

• Lack of user-friendliness: Because LOC is a technical statistic that non-technical users could find challenging to comprehend, it can be challenging to communicate the scope and complexity of the programme to stakeholders outside of the development team.