Designing And Managing A Software Project

Size Metrics
Software size estimation is the process of predicting the size of a software product. Accurate size estimation is critical to effectively manage the software designing process.

Lines of code (LOC)
LOC is one of the earliest and simplest metric for estimating the effort and size for estimating the effort and size of a computer program. However, there is no standard definition of what makes a line of code. Due to this, different workers for the same program may obtain different counts.  
The LOC is often used during the testing and maintenance phases, not only to specify the size of the software product but also it can be used together with other metrics to analyze other aspects of its quality and costs.

 Advantages:
1. Simple to measure

Disadvantages:
1. It is programming language dependent.
2. Does not accommodate non – procedural language.
3. Poor software design may lead to excessive and unnecessary line of code.

Token Metrics
The major drawback in LOC size measure is that it treats all the lines alike. In a program, there are some lines which are more difficult to code than others. One solution to this drawback may be to count the basic symbols used in a line instead of lines themselves. These basic symbols are called tokens, which are classified as either operators or operands. For Example, ‘while’, ‘for’, ‘eof’ etc. are all tokens.
M.H. Halstead, proposed one of the token metric where the size of a program, which consists of the number of unique tokens can be defined in terms of:

            N1 = count of unique operators
N2 = count of unique operands.

The length of the program in terms of total number of tokens used is

            N = N1 + N2

Where 

            N1 = Count of total occurrence of operators
N2 = Count of total occurrence of operands

An Operator, is the symbol or keyword in a program that specifies an action. Operators consist   of arithmetic symbol such as +, -, /, *, command names such as ‘while’, ‘for’ and special symbols such as braces, punctuation marks, etc.

            An operand includes variables, constants and labels.

Function Point (FP)

Function Point (FP) was developed by Allan J.Albrecht in mid 1970’s. It was an attempt to overcome difficulties associated with LOC as a measure of software size, and to assist in developing a mechanism to predict effort associated with software development.
FP basically, is an objective and structured technique to measure software size by quantifying its functionality provided to the user based on the requirements and logical design. This technique breaks the system into smaller components so that they can be better understood and analyzed.
FP analysis, thus divides the system into five basic components namely external inputs, external outputs, queries, logical master files and interface files.

To compute FP, the following relationship is used:
FP = Count Total * [0.65 + 0.01 * Total (Fi)]
The Fi (I = 1 to 14) are complexity adjustment values based on the environment behavior of the software project.
Count Total = The simple, average, complex values based on the five components external inputs, external outputs, queries, logical master files and interface files.

The Bang Metric
Demacro’s Bang Metric is used to predict the application size based on the analysis model. The software engineer first evaluates a set of primitives:

            FuP – Functional Primitives – “Leaf node” bubbles
DE – Data Elements – data dictionary entries
RE – Relationship Links – ERD links
ST – States – nodes on the state transition Diagram
TCi – Token Count – aggregate of data element
REi – Relationship connections – links between objects

With the evolution of these primitives, software can be defined as function-B or data-B.

            If FuP > RE then Software is function B
If RE > FuP then Software is data B

Once the Bang metric is computed from certain algorithms, past history is used to predict software size and effort.

 

Code Complexity Metric
Many a times you have to test and maintain some software code written by some another employee. In such a situation you have to understand the code and style of programming. Code complexity derives directly out of these aspects. It can be defined as a metric that is directly proportional to the amount of effort required to understand the code and modify it correctly, Code complexity is related to maintainability and testability of the code. The more complex a code is, the less maintainable and testable is.

Mccabe Cyclomatic Complexity Metric
            Mccabe Cyclomatic Complexity metric, introduced by Thomas Mccabe in 1976, is the most useful logical metric. It is used to measure the complexity of a program. It directly measures the number of linearly independent paths paths through a source code.
Cyclomatic complexity is calculated by creating a connected graph of the source code. Each line of code is considered a node on the graph and the arrows between the nodes shows the execution path. The Mccabe cyclomatic complexity is defined as:

CC = E – N + P
Where, CC – The Mccabe Cyclomatic Complexity
E – The number of edges of the graph
N – The number of nodes on the graph
P – The number of connected components / The number of exits from a program

Once the Cyclomatic complexity of a code has been computed, it can then be compared to the complexity of other programs and to the standard range given in the table below:

Cyclomatic Complexity Code Complexity

1. A simple program, without much risk
2. More complex, moderate risk
3. Complex. High risk

Greater than 50            Untestable, very high risk

Another alternative way to determine the metric is to count the number of decision points (conditionals) and incrementing that number by 1.

i.e

CC = D + 1
Where,
CC – The cyclomatic complexity
D – The number of decision points in the source code.

 

Information Flow
            Information flow within a program structure is also a metric to measure the complexity of a software module. This metric was first proposed by Katura and Henry, and is also called Henry’s and Katora’s Fan-in and Fan-out complexity metric.
Their method suggests identifying the number of calls from a module ad identifying the number of calls from a module.

            The complexity in information flow metric is determined by
C = (Procedure Length) * (Fan-In * Fan-Out) (Fan-In * Fan-Out)
Where,
C – The complexity of the module
Procedure Length – The length of the module, given in LOC or by using Mccabe’s cyclomatic complexity.

Fan-In – The number of calls to the module
Fan-Out – The number of calls from the module.

 

Quality Metrics
Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project. In general, software quality metrics are more closely associated with process and product metrics than with the projects Metrics.
The goal of the software quality metric is to develop precise measurements for software quality. The software quality is accessed indirectly by estimating some manifestation of quality. The challenge is to determine the precise relationship between the variable that is measured and the quality of software.

Indicators Of Measuring Quality:
Correctness
Maintainability
Integrity
Usability

Some useful resources:

joomla installation - Script installation and custom script development is our specialty. Whatever your needs for application development or specific programming functions we can help. Our professional staff of programmers will work with you one-on-one to identify your exact needs and to come up with a development plan.
internet advertising - Need traffic for your website? Want to generate traffic and don't know how? Need ideas on getting people to visit your website? Find out how at www.website-advertising.org