Size Oriented, Function Oriented

Size-oriented Metrics

Attempt to quantify software projects by using the size of the project to normalize other quality measures

• Possible data to collect:
• number of lines of code
• number of person-months to complete
• cost of the project
• number of pages of documentation
• number of errors corrected before release
• number of bugs found post release
• Size oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced.
• If a software organization maintains simple records, a table of size-oriented measures, such as shown in below fig.
• The table lists each software develop project that has been completed over past few years and corresponding measure for that project referring to the table entry for project alpha: 12,100 lines of code were developed with 24 person-months of effort at a cost 0f $$168,000.
• It should be noted that the effort and cost recorded in the table represents all software engineering activities (analysis, design, code and test) not just coding. Further information for project alpha indicates that 365 pages of documentation were developed, 134 error were recorded before the software was released and 29 defects were encountered after release to the customer within the first year of the operation.

Three people worked on the development of software for project alpha.

• To develop metrics that can be assimilated with similar metrics from other projects, we choose Line of Code as our normalization value.
• So, from information given in table , a set of simple size-oriented metrics can be developed for each projects:

Errors per KLOC (Thousands line of code)

Defects per KLOC,

$ Per KLOC,

Pages of documentation per KLOC

• Size-oriented metrics are not universally accepted as the best way to measure the software process but most of the controversy swirls around the use line of code as key measure.
• Proponent of line of code measure claims that LOC is an “artefact” of all software development projects that can be easily counted, that many existing software estimation
• models use LOC or KLOC as a key input, and that a large body of literature and data predicated on LOC is already exists.
• On the other hand, opponent argue that LOC measures are programming language dependent, that when productivity is considered, they are short programs, cannot easily accommodate nonprocedural language, and that their use in estimation requires a level of detail that may be difficult to achieve.

Function-Oriented Metrics

• Attempt to measure the functionality of a software system
• Use a unit of measure called function point
• Some possible function points:
• Internal data structures
• External data structures
• User inputs
• User outputs
• Transformations
• Transitions

Issues with Using Function-Oriented Metrics

• Requires that analysis and design of a project are completed before workload estimation can occur
• Validity of the workload estimation is limited to the accuracy of the analysis and design
• Complexity determination of function points is subjective

In function-oriented design, the system is comprised of many smaller sub-systems known as functions. These functions are capable of performing significant task in the system. The system is considered as top view of all functions.

Function oriented design inherits some properties of structured design where divide and conquer methodology is used.

This design mechanism divides the whole system into smaller functions, which provides means of abstraction by concealing the information and their operation.. These functional modules can share information among themselves by means of information passing and using information available globally.

Another characteristic of functions is that when a program calls a function, the function changes the state of the program, which sometimes is not acceptable by other modules. Function oriented design works well where the system state does not matter and program/functions work on input rather than on a state.

Design Process

• The whole system is seen as how data flows in the system by means of data flow diagram.
• DFD depicts how functions changes data and state of entire system.
• The entire system is logically broken down into smaller units known as functions on the basis of their operation in the system.
• Each function is then described at large.