Advancing the SwE Profession � Measuring Software Entropy� and additional opportunities

Robert Ferguson�rwferguson@gmail.com�(412)512-9585�

Introduction

• The missing Professional Engineering License
• Would allow engineers access to liability insurance.
• Would encourage a better relationship between Systems Engineers and Software Engineers
• Examination was terminated in 2006
• This talk will discuss a research agenda for software engineering.
• It will define a means to measure software entropy.
• Underlying theory extends to requirements engineering.

​

Information Systems Concept

We often call software “information systems”.

Why do we care about information systems and why is information important?

What is the benefit of “information?”

Making Decisions

• We use information to make decisions.
• We make better decisions when we assign a measure to the information.
• Multicriteria methods for design decisions provide the example
• QFD (Quality Function Deployment): also known as the “House of Quality”
• AHP (Analytic Hierarchy Process)

Both these methods apply either a measure or a utility to compare alternatives.

Quality Function Deployment (QFD)

“House of Quality

Analytic Hierarchy Process (AHP)

A Useful Definition for “Information”

We need information whenever we are making a decision.

We have information to support the decision when we have data satisfying these conditions:

1. A structural definition that identifies fields, formats, and a record structure,
2. We have selected a measure (or utility) for that information,
3. So that the measure supports the proposed decision.

​

The software itself probably makes few decisions, �So, we need to see how the information supporting the decisions is created.

​

Finding the “Information” in Software

• COSMIC Function Points are a useful cost estimation tool. We count these:
• Inputs
• Outputs
• Reads
• Writes
• These are mechanisms for moving data.
• It is not obvious what information is carried or how it was created.
• Algorithms of two distinct types provide information.
• - Encoding data to explicitly identify the information, and
• - Making decisions.

Encoding Examples

• Typical algorithms
• Parsing input into commands
• Classification by assigning a group name
• Sorting
• Statistical analyses and signal processing algorithms
• Graphical charts
• Classification by “rough sets”
• Some algorithms provide values for multiple uses (e.g. statistics and graphs).
• A SELECT() statement is also an encoding algorithm. I want to “select” only those elements that are important to me (why still needs to be explicit).

Decision Algorithms

• Requires comparing two sources of data, each based on a single utility or measure.
• The goal is the standard by which the decision will be judged.
• The variable data is the source material we are judging.
• Examples:
• Searching
• Authenticating and authorizing a user profile
• Goal-seeking algorithms for control systems
• Pattern recognition algorithms for tax audits
• The goal may be a variable that is calculated elsewhere separate from the decision algorithm. It may also be a static value that is established by a configuration process.

Research Goal #1�Case Studies: Can we detect all such algorithms in our code?

• Can we identify these two types of algorithms by examining code by hand?
• The author has done two examples: a text editor and a stability control system for a quadcopter.
• What is the count of algorithms in a large program?
• Is it possible to explicitly name the utility or information value for each algorithm?
• How difficult would it be to modify a static code analyzer to perform this task automatically?

​

The Directed Graph of Information

• Each algorithm produces some information (assign a name).
• The information is part of some functional requirement. (Axiomatic Design)
• Information is used elsewhere in the program. Can we trace the usage?
• It is valuable to trace the creation and use of the information as a directed graph.
• This graph provides additional information about program complexity.
• When the information changes, we can use the graph to identify all uses.
• When customer application of the information causes a change to the definition of the information, we can use the graph to identify what other code might need to change.
• Most information graphs will not contain cycles.
• Graphs may contain cycles in dynamic or chaotic systems.

​

Research Goal #2�Case Studies: Graph Notation and Complexity

• Is it obvious which nodes are encoding and which are decisions?
• Which graph complexity measures are useful and why?
• Some portion will be simple threads.
• Some will have many feeds, others many uses. Is there a ratio?

Entropy Background�No machine is perfect. Friction loses energy and creates heat.

• “Software does not wear out,” however, information breakdown results from changes to inputs and product value (usage).
1. Some input changed. The change may affect the information content and value.
2. The customer product usage changed so the customer is losing value.

Any change to information content will require revision to encoding or decision-making algorithms.

The rate of these changes can be anticipated.

External programs and sources of data change on a regular, periodic basis. We can use that frequency to predict the general need for maintenance.

Customer changes to program use and value cannot be perfectly predicted but can be externally observed by watching for changes to their business practices and customer base. We can plan for a rate of change and price our product to satisfy it.

The probability of failure is based on a planned “period of performance” – say one year.

The Measure of Entropy

Research Goal #3�Rich set of questions

• H1: Cost of change is related to the number of affected nodes in the graph.
• Can we estimate costs from only the source and end nodes?
• Does entropy really forecast failures increasing over time?
• Do graph complexity measures help?

​

Additional Benefits from Information

• Access to “Axiomatic Design” methods
• Information content=Design parameter of Suh’s second axiom
• https://www.sciencedirect.com/topics/engineering/axiomatic-design
• Axiomatic Design(AD) has been applied in every engineering discipline. Companies applying AD see significant reductions in design time.
• Toyota: from 7 years to 3 years from 1990 to 2000.
• Requirements stated with the appropriate information value produce better test cases.
• AD exposes potential design conflicts.

Conclusion

• Requirements properly stated with an information parameter improve communications with other engineers and customers.
• This concept is particularly important for larger projects.
• It may be more difficult to explain to small agile teams.
• A draft paper (9 pages) is available with references:
• rwferguson@gmail.com

​

​

​