Home » Resources » SyEN Newsjournal » PPI SyEN 46

PPI SyEN 46

Read monthly Project Performance International's Systems Engineering Newsjournal, named "PPI SyEN". PPI SyEN presents for the engineering professional 30-60 pages of valuable technical articles on topical subjects, shorter technical pieces, in-depth coverage of the month's news in systems engineering and directly related fields, pointers to useful resources and relevant industry events, plus limited information on PPI's activities.

Welcome to PPI SyEN 46

WHAT’S INSIDE:

Quotations to Open On

Read More…(link/anchor to PPI Events)

Quotations to Open On

No man needs sympathy because he has to work. Far and away the best prize that life offers is the chance to work hard at work worth doing.

– Theodore Roosevelt

The things that are measured and tracked and are paid attention to by management are the ones that improve.

– Ralph Young

Feature Articles

Economic Aspects of System-of-Systems Engineering

Massimo Pica

Rome, Italy

massimo.pica@libero.it

Fundamentals of System-of-Systems Engineering

According to the International Council on Systems Engineering (INCOSE), the definition of System-of-Systems (hereinafter referred to as SoS) applies to a system of interest whose system elements are themselves systems; typically these entail large scale inter‐disciplinary problems with multiple, heterogeneous, distributed systems. These interoperating collections of component systems usually produce results unachievable by the individual systems alone.

Every system in a SoS structure is able to operate in a stand-alone mode, and also to contribute to the achievement of higher-level mission requests. The life cycles of individual systems may show some differences, since integrations or replacements of system elements can take place in order to meet system requirements. If these requirements are taken into consideration, then the effects of integration between different SoS elements have to be properly evaluated in each specific case.

In specialized literature, different definitions for SoS can be found, on the basis of the scope of possible SoS applications, basically reflecting three elements: products (i.e., the characteristics of SoS architecture); processes (design/integration/test); and personnel (lead system integrator).

Some specific characteristics of a SoS can be identified in more detail as follows:

Operational independence of the systems- Each of the individual systems within a SoS has a “life of its own” and can function acceptably and provide useful service without necessarily interacting with other systems.

Managerial independence of the systems- The individual systems within a SoS are under different authorities.

Evolutionary development- The different systems within the SoS are developed and upgraded on uncoordinated schedules.

Emergent behavior – Some of the behavior of the SoS as a whole is not embodied in any one of the systems within it. Emergent behavior is a direct consequence of having the systems interact; the difficulty is ensuring that the emergent behavior is desirable.

Geographic distribution- Simply put, the systems within the SoS are not all co-located. While it is highly likely that any significant fielded SoS will have this characteristic, it is by no means obvious that it is a necessary characteristic.

SoS engineering is different from the usual systems engineering. For example, if we consider a SoS as composed of interdependent systems connected to provide a given performance, losing part of the system will cause a significant performance degradation of the entire SoS.

From an economic point of view, the selection of applicable cost models has been found to be influenced by a number of discriminating criteria, a few of which are deemed essential: the SoS stakeholders, the SoS architecture and its lead system integrator(s), and the degree of system component independence in terms of activities required in the life cycle stages for each component. This means that, in order for a cost estimation model to be effectively useful in SoS estimates, it is essential to look first at organizations requiring this sort of information for their strategic goals, especially the system acquirers and the system’s user communities. Secondly, having established a lead system integrator, she/he will be responsible not only for selecting SoS architectures but, thereafter, for supervising integration and test activities representing significant cost elements to be properly evaluated. Furthermore, the degree of independence of Life Cycle Management activities at component level will certainly influence the selection of cost models applicable to system software and to the remaining elements of SoS Cost Breakdown Structure, taking into account possible cost overlaps and double countings.

The realization of every SoS involves trade-offs between different solutions and between individual systems’ performance. An example of a system of systems would be an aircraft. While the aircraft may be developed as a single system, it could incorporate subsystems developed for other aircraft (for example, the radar from an existing aircraft may be incorporated into the aircraft being developed rather than developing a new radar), so that the new aircraft can be considered as a SoS composed of the airframe, engines, radar, avionics and all other elements necessary to meet the aircraft capability requirements.

From a general Systems Engineering (SE) point of view, the implications of a SoS, compared to “elementary” systems, may typically refer to the following specific attributes: broader technical scope; greater complexity of integration efforts; dynamic and challenging design (especially as regards risk/uncertainty issues and to the emphasis on design optimization); re-configurability of system architectures; peculiarity of SoS simulation and modeling; and rigorous interface design and management.

Reverting now to the factors of a more specific economical nature, it is important to emphasize the complex efforts that cost analysts have to undertake to estimate the cost of a SoS, with respect to simpler systems, taking into consideration the full range of options for the overall SoS configuration based on component system selection. Traditional estimation methodologies have to be combined with more advanced methodologies, either analytical or Decision Support methods. Some of these more advanced methodologies will be reviewed.

Bayes Techniques

Henceforth only essential notes will be given on Bayes analytical techniques. They consider an “a priori” hypothesis which is modified by the application of successive information. For a parameter subject to uncertainty constraints, an “a priori” probability distribution will be formulated. For a second value of the parameter, another probability distribution will exist, giving a more refined estimate. Bayesian inference combines these two series of data to obtain an “a posteriori” probability distribution, from which a more likely (or less uncertain value) of the parameter considered can be derived, however such that the actual value will never be the same as the estimated value.

Bayes theorem is used to obtain a subjective probability distribution representing the probability that an event will occur in future trials, taking into account a random variability.

The next figure depicts a series of mutually exclusive events (values) X1, X2, X3,…, Xn, such that X1 X2 X3 … Xn = S

The figure below shows X1, X2, X3… Xn as partitions of the space S, whereas E (being such that E S) is an arbitrary event, which has the following property:

P (E) = P(X1) P (E| X1) + P(X2) P (E| X2) + … + P (Xn) P (E| Xn)

Therefore, if X1, X2, X3… Xn are known, it is possible to determine the probability of event E. While the probability of E cannot be directly observed, it is possible to obtain the conditioned probabilities by applying the Bayes theorem, which also provides inverse probabilities P (Xi|E) from the ratio of P (Xi) P (E| Xi) to P (E).

A vast literature provides more insight into the subject.

Decision Support Methods

The Arrow theorem or “impossibility theorem” is applied whenever it is required to classify in order of importance a series of decision factors, such as lists of technical requirements or of strategic needs. An example will help explain this theorem. Let’s suppose that a company needs to adopt an order of preferences between different options. In the company, each individual has some order of preference, which for example can be expressed by a vote. The problem is to find a procedure (for example a suitable voting system), generally referred to as public selection function, which will be able to convert the set of individual preferences into a global consistent order.

Arrow states that if the group of voting citizens includes at least two individuals and the set of available alternatives includes at least three options, it is impossible to create a choice function that will meet at the same time all reasonable requirements for a fair voting system.

In our case, therefore, we can conclude that no analytical technique exists to simultaneously meet all common impartiality criteria in ranking a series of alternatives. Nevertheless, a great variety of circumstances requires selecting and ranking preferences. As a consequence, statistically robust ranking methods should be used, taking into account the inherent limitations of Arrow theorem.

One of such well-known methods is the Analytical Hierarchy Process (AHP), introduced by Professor Thomas Lorie Saaty at the Pittsburgh University. This method can be used to determine the benefit/cost ratio of a system project whenever it is not possible to use solely monetary terms in assessing the benefits and disadvantages deriving from the project implementation, or when it is impossible or difficult for the majority of costs and benefits to operate simulations to quantify them.

The applicability of this method can be better illustrated by the following example: A firm wishes to buy one new piece of equipment of a certain type and has four aspects in mind which will govern its purchasing choice: expense, operability, reliability, and adaptability for other uses (or flexibility). Let’s suppose that three options, X, Y and Z, have been offered:

X is cheap and easy to operate but is not very reliable and could not easily be adapted to other uses;

Y is somewhat more expensive, is reasonably easy to operate, is very reliable but not very adaptable;

Z is very expensive, not easy to operate, is a little less reliable than Y but is claimed by the manufacturer to have a wide range of alternative uses.

Each of X, Y, and Z will satisfy the firm’s requirements to differing extents so which, overall, best meets this firm’s needs?

AHP methods are appropriate to address this important and common class of problems and other numerous applications, but also with some limitations.

Saaty established a hierarchical ranking to make a pairwise comparison for the relative assessment of the importance of different system attributes A, B… by rating 1 (equal importance) two attributes which contribute equally to the objective, 9 (absolutely more important) an attribute A which is preferable by the greatest evidence and, symmetrically, 1/9 the attribute B.

Intensity of importance

Definition

Explanation

Equal importance

Two factors contribute equally to the objective.

Somewhat more important

Experience and judgment slightly favour one over the other.

Much more important

Experience and judgment strongly favour one over the other.

Very much more important

Experience and judgment very strongly favor one over the other. Its importance is demonstrated in practice.

Absolutely more important

The evidence favouring one over the other is of the highest possible validity.

2,4,6,8

Intermediate values

When compromise is needed.

In a pairwise comparison of n elements, for each pair i – j it is possible to determine numerical values of importance aij, for a total of n2 values, of which n(n-1)/2 have to be determined by the analyst, since by definition each value of i and j yields aii = 1 and aij = 1/ aji.

Subsequently, relative weights are calculated to define the relative importance of elements, namely, for example, the values wi e wj such that aij = wi / wj. Therefore, now the problem is to ascertain whether the weights derived by calculation actually reflect the judgment of the analyst.

For this purpose a Consistency Index (CI) is introduced:

CI =

where

max * wi = j aij * wj

(CI = 0 indicates perfect consistency, a higher CI means decreasing consistency. Another parameter, the Consistency Ratio (CR), is used to measure how consistent the judgments have been relative to large samples of purely random judgments.

AHP is one of the best known methods of MCDA (Multi-Criteria Decision Analysis), of which dozens of applications exist, on the basis of various categories of mathematical approaches. Actual applications of quantitative techniques with multiple criteria show that this sort of analysis suffers from limitations deriving from an imperfect use of quantitative information available, or from lack of this information.

From a purely mathematical standpoint, selection problems based on multiple criteria do not yield a single solution if the analyst has no further indications on the preferences to be adopted. Methods supporting the selection of the best alternatives follow the objective of finding the alternative which complies to the largest extent with the preferences. Further insight on this approach is reported in the relevant literature.

To complete this review, let’s now briefly consider the Delphi method, which can be defined – as generically as possible – as a method for information collection aiming at a consensus between experts on a specific topic.

In particular, Delphi method can be applied to the formulation of judgments, by expert groups, in cost forecasting processes on the basis of preferences between values. In its traditional formulation, Delphi method is based on a questionnaire which is formulated by a restricted control group and completed individually in an anonymous fashion by a larger group of respondents; for example, this questionnaire could relate to an estimate of most likely cost. After reviewing all responses, the control group communicates them to the respondents, so that they can reformulate their own response as a consequence, having regard to divergent views and the reasons for these views. This procedure can be repeated several times, in order to possibly reach a large convergence of views. In a newer formulation, this process can be accelerated by the use of computer support to process the responses.

Neural Network Techniques

In the last decade, careful consideration was given to the need for improvements in the design cycle of products and systems designed for a long-term utilization. Emphasis was given to reduce design changes, cost and time to market and, as a consequence, life cycle engineering approaches were adopted for a greater effectiveness in the highly competitive global market.

Having noted that 70 percent or more of the Life Cycle Cost of systems is committed by early life cycle decisions, appropriate design techniques had to be devised to meet the aforesaid purpose. Now, it is in the initial phase that the system operational requirements have to be streamlined in order to avoid inconsistencies and drawbacks deriving from lack of detailed design information, and to accelerate the decision making processes. Specifically in the case of SoS, the adoption of parametric models for LCC estimation is complicated by the formulation of a large number of design concepts and requirements to be evaluated in terms of cost (LCC) – effectiveness. Therefore, the more traditional LCC models cannot be applied due to the lack of detailed information required in the initial life cycle phase.

Artificial neural network techniques have been found helpful in approximate LCC evaluations during the Concept Stage. In this type of model, the analyst can compare the properties of a new system with a similar existing system for which LCC studies are available, so that the cost estimation process can be executed on the basis of the properties (usually of higher level) of the new system.

Conclusion

A System of Systems (SoS) is a system of interest whose system elements are themselves systems. Every system in a SoS structure is able to operate in a stand-alone mode, and also to contribute to the achievement of higher-level mission requests. SoS have several specific characteristics that were described. The realization of every SoS involves trade-offs between different solutions and between individual systems’ performance. SoS typically have attributes, including broader technical scope, greater complexity of integration efforts, dynamic and challenging design, re-configurability of system architectures, peculiarity of SoS simulation and modeling, and rigorous interface design and management. Concerning the estimated cost of a SoS, traditional estimation methodologies including Bayes Techniques, Decision Support Methods, and Neural Network Techniques were described.

Plans for Future Research

The economic aspects of System-of-Systems Engineering will be discussed in detail in a forthcoming book concerning Systems Lifecycle Economics, which the author of this article is drafting at this time. The SE Community will potentially benefit from this book in a number ways:

1. Traditionally, in the cost management of complex projects, the most attention has been given to the optimization of system acquisition costs; whereas ownership costs (e.g. operating costs and maintenance costs) are not given the same consideration.

2. Technological innovations characterising advanced systems require a careful balance of the whole acquisition, ownership, and retirement costs, in order to avoid unjustified trends in cost growth.

3. The estimation of Life Cycle Cost, representing the system unit cost over its entire lifetime, offers a number of basic elements to support decisions not only during the early life cycle stages, but in all subsequent periods. Specific decisions are required to manage maintenance policies and to carry out trade-offs between different possible alternatives, until the system life comes to its projected (and possibly, to some extent, unpredicted) end.

BIBLIOGRAPHY

B.S. Blanchard, W.J. Fabrycky –”Systems Engineering and Analysis” – Prentice Hall – 2010.

H.A. Linstone, M. Turoff (Eds.) – “The Delphi Method – Techniques and Applications” – New Jersey Institute of Technology – 2002.

G. J. Thuesen, W. J. Fabrycky – “Engineering Economy” –Prentice Hall – 1993.

G. Wang, J.A. Lane, R. Valerdi, B. Boehm – “Towards a Work Breakdown Structure for Net Centric System of Systems Engineering and Management” – 2006.

J.A. Lane, R. Valerdi – “Synthesizing SoS Concepts for Use in Cost Estimation” – 2006.

INCOSE – International Council on Systems Engineering – “Systems Engineering Handbook” – 2007 and further updates.

M. Smit, M. Pica et al. – NATO Publication RTO TR-SAS-054 “Methods and Models for Life Cycle Costing” – June 2007 – http://ftp.rta.nato.int/public//PubFullText/RTO/TR/RTO-TR-SAS-054///$$TR-SAS-054-ALL.pdf.

B.S. Blanchard – “System Engineering Management” – J. Wiley & Sons – 2008

ISO/IEC 15288, “Systems and software engineering – System life cycle processes”, 2008.

B. Flynn, M. Pica et al. – NATO Publication RTO TR-SAS-069 “Code of Practice for Life Cycle Costing” – September 2009 – http://ftp.rta.nato.int/public//PubFullText/RTO/TR/RTO-TR-SAS-069///$$TR-SAS-069-ALL.pdf.

Software Quality Metrics:

Three Harmful Metrics and Two Helpful Metrics

June 2012

Part 1 of 2

(Part 2 will be provided in the next issue of SyEN)

Capers Jones, VP and Chief Technology Officer

Namcook Analytics LLC

Abstract

The cost of finding and fixing bugs or defects is the largest single expense element in the history of software. Bug repairs start with requirements and continue through development. After release, bug repairs and related customer support costs continue until the last user signs off. Over a 25 year life expectancy of a large software system in the 10,000 function point size range, almost 50 cents out of every dollar will go to finding and fixing bugs.

Given the fact that bug repairs are the most expensive element in the history of software, it might be expected that these costs would be measured carefully and accurately. They are not. Most companies do not measure defect repair costs, and when they do, they often use metrics that violate standard economic assumptions.

This article discusses three bad metrics and two good metrics. The three bad metrics are: 1) cost per defect; 2) lines of code; and 3) technical debt.

The two good metrics are: 1) function points, for normalization of data; and 2) Defect removal efficiency, for measuring the percentage of bugs found prior to release and afterwards via maintenance.

Introduction

The costs of finding and fixing bugs have been the major cost driver of large software applications since the software industry began. One might think that the software industry would have solid and reliable measurement data on its most expensive activity, but this is not the case.

Many companies do not start to measure bugs or defect repairs costs until testing starts, so all defects and repairs associated with requirements and design are invisible or under-reported.

Even worse, many attempts to measure quality use metrics that violate standard economic assumptions, and conceal or distort the economic value of high quality. There are three very hazardous metrics that all distort quality economics and understate the true value of software quality:

1. Cost per defect;

2. Lines of code for normalization of results; and

3. Technical debt.

All three of these metrics share a common failing. They all ignore fixed costs, which will be dealt with later in this article. Individually, each has other failings too.

There are two helpful and valid metrics that show the economic value of software quality, and also can be used to predict quality and delivered defects, as well as measure:

1. Function points for normalization of results; and

2. Defect removal efficiency.

Let us start by considering the reasons that the three bad metrics are harmful, and then why the two good metrics are useful.

The Errors and Hazards of Cost per Defect

The cost-per-defect metric has been in continuous use since the 1960’s for examining the economic value of software quality. Hundreds of journal articles and scores of books include stock phrases, such as “it costs 100 times as much to fix a defect after release as during early development.”

Typical data for cost per defect varies from study to study but resembles the following pattern circa 2012:

Defects found during requirements = $250

Defects found during design = $500

Defects found during coding and testing = $1,250

Defects found after release = $5,000

While such claims are often true mathematically, there are four hidden problems with cost per defect that are usually not discussed in the software literature and are not well understood:

1. Cost per defect penalizes quality and is always cheapest where the greatest numbers of bugs are found.

2. Cost per defect ignores fixed costs. Even with zero defects there will be costs for inspections, testing, static analysis, and maintenance personnel. These costs are either fixed or inelastic and do not change at the same rate as defect volumes.

3. Because more bugs are found at the beginning of development than at the end, the increase in cost per defect is artificial. Actual time and motion studies of defect repairs show little variance from end to end.

4. Even if calculated correctly, cost per defect does not measure the true economic value of improved software quality. Over and above the costs of finding and fixing bugs, high quality leads to shorter development schedules and overall reductions in development costs. These savings are not included in cost per defect calculations, so the metric understates the true value of quality by several hundred percent.

The cost per defect metric has such serious shortcomings for economic studies of software quality that a case might be made for considering this metric to be a form of professional malpractice for economic analysis of software quality.

Consider a well-known law of manufacturing economics:

“If a manufacturing cycle includes a high proportion of fixed costs and there is a reduction in the number of units produced, the cost per unit will go up.”

As an application moves through a full test cycle that includes unit test, function test, regression test, performance test, system test, and acceptance test, the time required to write test cases and the time required to run test cases stays almost constant; but the number of defects found steadily decreases.

Table 1 shows the approximate costs for the three cost elements of preparation, execution, and repair for the test cycles just cited using a fixed rate $75.75 per hour for all activities:

Writing test cases takes 16.5 hours for every test stage.

Running test cases takes 9.9 hours for every test stage.

Defect repair takes 5.0 hours for every defect found.

Even though every activity is based on fixed and unchanging amounts of time, look at what happens to cost per defect in Table 1:

Writing

Running

Repairing

TOTAL

Number of

$ per

Test Cases

Defects

COSTS

Defects

Defect

Unit test

$1,250.00

$750.00

$18,937.50

$20,937.50

$418.75

Function test

$1,250.00

$750.00

$7,575.00

$9,575.00

$478.75

Regression test

$1,250.00

$750.00

$3,787.50

$5,787.50

$578.75

Performance test

$1,250.00

$750.00

$1,893.75

$3,893.75

$778.75

System test

$1,250.00

$750.00

$1,136.25

$3,136.25

$1,045.42

Acceptance test

$1,250.00

$750.00

$378.75

$2,378.75

Table 1: Cost per Defect for Six Forms of Testing

(Assumes $75.75 per staff hour for costs)

What is most interesting about Table 1 is that cost per defect rises steadily as defect volumes come down, even though Table 1 uses a constant value of 5.0 hours to repair defects for every single test stage!

In other words, every defect identified throughout Table 1 had a constant cost of $378.25 and 5 hours when only repairs are considered.

In fact, all three columns use constant values and the only true variable in the example is the number of defects found!

In real life, of course, preparation, execution, and repairs would all be variables. But by making them constant, it is easier to illustrate the main point: cost per defect rises as numbers of defects decline.

Since the main reason that cost per defect goes up as defects decline is due to the fixed costs associated with preparation and execution, it might be thought that those costs could be backed out and leave only defect repairs. Doing this would change the apparent results and minimize the initial errors, but it would introduce three new problems:

1. Removing quality cost elements that may total more than 50% of total quality costs would make it impossible to study quality economics with precision and accuracy.

2. Removing preparation and execution costs would make it impossible to calculate cost of quality (COQ) because the calculations for COQ demand all quality cost elements.

3. Removing preparation and execution costs would make it impossible to compare testing against formal inspections, because inspections do record preparation and execution as well as defect repairs.

Backing out or removing preparation and execution costs would be like going on a low-carb diet and not counting the carbs in pasta and bread, but only counting the carbs in meats and vegetables. The numbers might look good, but the results in real life would not be good.

The bottom line is that cost per defect penalizes quality and makes buggy applications look better than they are because their cost per defect is lower. Cost per defect also makes early defects look cheaper than late defects and has led to the urban legend that “it costs 100 times as much to fix a bug after release than early in development.”

Even worse, the true value of quality is not merely lowering defect repairs, but getting software out earlier, shortening development schedules, lowering maintenance costs, and having happier customers.

Cost per defect has blinded the software industry to the true economic value of software and led to the false assumption that “high quality is expensive.” High quality for software is not expensive, and in fact is much cheaper and faster to develop high quality software than buggy software.

The Errors and Hazards of Lines of Code (LOC)

The “lines of code” or LOC metric has been in continuous use since the 1960’s. Most users of LOC metrics have never studied the behavior of this metric across multiple languages.

As with the cost per defect metric, the LOC of code metric ignores fixed costs. The mathematical result is that low-level languages such as assembly and C seem to be cheaper and of higher quality than modern high-level languages such as Ruby and MySQL.

Let us consider two different languages to see what happens and why LOC metrics are so harmful to economic studies. We will consider the C language and the Java language as examples in Table 2. We will assume that it takes twice as much C code as Java code for a specific application:

Java

Language

2000

1000

LOV

LOC

(2 KLOC)

(1 KLOC)

Defect Sources

Defects

Requirements

Design

Source code

Documents

Bad fixes

TOTAL

Defects

32.50

50.00

per KLOC

Defects

3.25

2.50

Per Function

Point

Table 2: Quality Distortion caused by KLOC Metrics

Note that when data is normalized using “defects per KLOC” and all defect sources are included, the lower-level C language has fewer defects per KLOC. This true even though the C version had 65 total defects and the Java version had only 50.

Even if only code defects are considered, there is still a distortion of results with LOC metrics. Code defects for both Java and C are exactly 15 per KLOC even though the C version had twice as many bugs.

LOC metrics have some legitimate uses, but they are not valid for software economic analysis and indeed should be considered to be professional malpractice for that purpose. LOC metrics can be used to examine coding speed, cyclomatic complexity, numbers of test cases, test coverage, and a number of ancillary topics. But LOC metrics are not suitable for economic studies.

The more languages that are included the worse LOC metric become. The following table is from an earlier study that compared 10 languages used for versions of a PBX switching system:

Language

Effort

Funct. Pt.

Work Hrs.

LOC per

(Months)

per Staff

per

Staff

Month

Funct. Pt.

Month

Hour

Assembly

781.91

1.92

68.81

480

3.38

460.69

3.26

40.54

414

3.13

CHILL

392.69

3.82

34.56

401

3.04

PASCAL

357.53

4.20

31.46

382

2.89

PL/I

329.91

4.55

29.03

364

2.76

Ada83

304.13

4.93

26.76

350

2.65

C++

293.91

5.10

25.86

281

2.13

Ada95

269.81

5.56

23.74

272

2.06

Objective C

216.12

6.94

19.02

201

1.52

Smalltalk

194.64

7.71

17.13

162

1.23

Average

360.13

4.17

31.69

366

2.77

Table 3: Productivity Rates for 10 Versions of the Same Software Project

(A PBX Switching system of 1,500 Function Points in Size)

As can be seen, LOC metrics totally reverse real economic productivity and makes the most labor-intensive version using assembly language look faster than the most efficient version that used Smalltalk!

This is a textbook example of LOC as professional malpractice. This table comes from an actual consulting study where developers at a telecommunications company wanted to adopt object-oriented languages but management resisted because their internal LOC data made low-level languages look more productive than high-level languages.

The costs of requirements, design, and other non-coding tasks on modern systems are often more expensive than the code itself. Of the five major cost drivers for software, LOC metrics can only be used for one. The five major cost elements are shown in Table 4.

Percent

Activities

of Costs

Finding and fixing bugs

30.00%

Coding or programming

25.00%

Producing paper documents

20.00%

Meetings and communications

15.00%

Project management

10.00%

TOTAL

100.00%

Table 4: Major Software Cost Drivers 2012

LOC metrics have supplemental purposes for software projects, but should never be the primary metric for economic analysis.

The Errors and Hazards of Technical Debt

The concept of technical debt is the newest of the quality metrics, having first been described by Ward Cunningham in a 1992 paper. From that point on, the concept went viral and is now one of the most common quality metrics in the United States and indeed the world.

The essential idea of technical debt is that mistakes and errors made during development that escape into the real world when the software is released will accumulate downstream costs to rectify.

In a sense technical debt tends to piggy back on the “cost per defect” metric with an implied assumption that post-release defects and changes have higher costs than internal defects and changes.

As a metaphor or general concept the idea of technical debt is attractive and appealing. For one thing it makes software quality appear to take on some of the accumulated wisdom of financial operations, although the true financial understanding of the software industry is shockingly naive.

However technical debt suffers from the same problems as cost per defect and lines of code: it ignores fixed costs. It has other and much more serious problems that are not intrinsic, but have come to be unfortunately common.

A major problem with technical debt is that it ignores pre-release defect repairs, which are the major cost driver of almost all software applications. Ignoring pre-release defect repairs is a serious deficiency of technical debt.

Second, what happens after software is released to the outside world is not identical to the way software is developed. You need to support released software with customer support personnel who can handle questions and bug reports. And you also need to have maintenance programmers standing by to fix bugs when they are reported.

This means that even software with zero defects and very happy customers will accumulate post-release maintenance costs that are not accounted for by technical debt. Let us assume you release a commercial software application of 1000 function points or 50,000 lines of Java code.

Prior to release you have trained 2 customer support personnel who are under contract and you have 1 maintenance programmer on your staff assigned to the new application. Thus even with zero defects you will have post-release costs of perhaps $15,000 per month.

After several months you can reassign the maintenance programmer and cut back to 1 customer support person, but the fact remains is that even zero-defect software has post-release costs.

The third and most serious flaw with technical debt concerns the 50% failure rate of large systems > 10,000 function points or 500,000 Java statements in size. If an application of this size is cancelled and not released at all, then technical debt will of course be zero. But your company just wasted $25,000,000 on a project that was terminated due to poor quality!

Yet another omission from the calculations for technical debt are the costs of litigation and punitive damages that might occur if disgruntled clients sue a vendor for poor quality.

Here is an example from an actual case. The shareholders of a major software company sued company management for releasing software of such poor quality that the shareholders claimed that the poor quality was lowering the stock price.

Clearly the defects themselves would accumulate technical debt, but awards and punitive damages based on litigation are not included in technical debt calculations. In some cases, litigation costs might be high enough to bankrupt a software company.

This kind of situation is not included in the normal calculations for technical debt, but it should be. In other words, if technical debt is going to become a serious concept as is financial debt, then it needs to encompass every form of debt and not just post-release changes. It needs to encompass the high costs of cancelled projects and the even higher costs of losing major litigation for poor quality.

To illustrate that technical debt is only a partial measure of quality costs, Table 5 compares technical debt with cost of quality (COQ). As can be seen, technical debt only encompasses about 13% of the total costs of eliminating defects.

Note also that, while technical debt is shown as $86,141, right above this cost is the much higher cost of $428,625 for pre-release quality and defect repairs. These pre-release costs are not included in technical debt!

Just below technical debt are costs of $138,833 for fixed overhead costs of having support and maintenance people available. These overhead costs will accrue whether maintenance and support personnel are dealing with customer calls, fixing bugs, or just waiting for something to happen. Even with zero-defect software with zero technical debt there will still be overhead costs. These overhead costs are not included in technical debt, but are included in cost of quality (COQ).

Defects

Code defect potential

1,904

Req. & design def. pot.

1,869

Total Defect Potential

3,773

Per function point

3.77

Per KLOC

70.75

Defect Prevention

Efficiency

Remainder

Costs

JAD

23%

2,924

$37,154

QFD

2,924

Prototype

20%

2,340

$14,941

Models

2,339

Subtotal

38%

2,339

$52,095

Pre-Test Removal

Efficiency

Remainder

Costs

Desk check

25%

1,755

$19,764

Static analysis

55%

790

$20,391

Inspections

790

Subtotal

66%

790

$40,155

Test Removal

Efficiency

Remainder

Costs

Unit

30%

553

$35,249

Function

33%

370

$57,717

Regression

12%

326

$52,794

Component

30%

228

$65,744

Performance

10%

205

$32,569

System

34%

135

$69,523

Acceptance

15%

115

$22,808

Subtotal

85%

115

$336,405

Costs

PRE-RELEASE COSTS

$428,655

POST-RELEASE REPAIRS

(TECHNICAL DEBT)

$86,141

MAINTENANCE OVERHEAD

$138,833

COST OF QUALITY

(COQ)

$653,629

Defects delivered

115

High severity

Security flaws

High severity %

18.94%

Table 5: Technical Debt Compared to Cost of Quality (COQ)

(1000 function points and 50,000 Java statements)

Even worse, if a software application is cancelled before release due to poor quality, it will have zero technical debt costs but a huge cost of quality.

An “average” project of 10,000 function points in size will cost about $20,000,000 to develop and about $5,000,000 to maintain for 5 years. About $3,000,000 of the maintenance costs will be technical debt.

But if a project of the same size is cancelled, they are usually late and over budget at the point of termination, so they might cost $26,000,000 that is totally wasted as a result of poor quality. Yet technical debt would be zero since the application was never released.

The bottom line is that the use of technical debt is an embarrassing revelation that the software industry does not understand basic economics. Cost of quality (COQ) is a better tool for quality economic study than technical debt.

Editor’s Note: Part 2 of this article by renowned quality expert Capers Jones will appear in the next issue of the Systems Engineering Newsletter (SyEN).

Systems Engineering News

INCOSE Systems Engineering Certification Discussions

The Board of Directors of the International Council on Systems Engineering (INCOSE) considered at its meeting in Rome earlier this month a number of options for the way forward regarding its systems engineering certification program (Associate Systems Engineering Professional [ASEP]/Certified Systems Engineering Professional [CSEP]/Expert Systems Engineering Professional [ESEP]) that recently delivered the 1000th CSEP. Although there was considerable discussion concerning alternatives, the conclusion reached was that no change to the program should be made at this time.

For more information on the INCOSE Certification Program: http://www.incose.org/educationcareers/certification/

For information on ASEP/CSEP training: {link to the CTI home page}

ASME Conducts Large Scale Verification and Validation Symposium

ASME (founded as the American Society for Mechanical Engineers) held over May 2 – 4, 2012, in Las Vegas, NV, USA, what it believes to be the first large-scale symposium dedicated entirely to Verification, Validation, and Uncertainty Quantification of computer simulations.

The purpose of this symposium was to bring together engineers and scientists from all disciplines that use computational modeling and simulation to discuss and exchange ideas and methods for verification of codes and solutions, simulation validation, and assessment of uncertainties in mathematical models, computational solutions, and experimental data. The conference included plenary sessions and paper presentation sessions, some of which were oriented by an application field, and some focused by technical goal and approach. The intent was to create an environment where scientists and engineers in various fields, who do not normally have an opportunity to interact, were able to share verification and validation methods, approaches, successes and failures, and ideas for the future.

Preconference activities included ASME V&V standards development committee meetings. ASME V&V Subcommittees currently include: Computational Solid Mechanics, Computational Fluid Dynamics and Heat Transfer, Nuclear Power Thermal/Fluids Systems, and Medical Devices.

The format for this first conference was presentations only, with no requirement for a formal paper submission. A volume of final abstracts is available for registered symposium attendees.

More information: http://www.asmeconferences.org/VVS2012/index.cfm

Update to BABOK® Guide Version 3

The International Institute of Business Analysis (IIBA) received over 200 applications in response to its call for volunteers to work on the update of A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3.

More information: www.iiba.org

Singapore Hosts the First Business Analysis Congress Asia

For the first time, the Business Analysis community in Asia gathered to discuss the issues, competencies and challenges they are facing today. BAs, Senior BAs and others from Singapore, Malaysia and Indonesia attended the inaugural Business Analysis Congress Asia on May 29 and 30, 2012 in Singapore.

More information: www.iiba.org

Online Survey on Requirements Engineering for Variability-intensive Systems

The Software Engineering and Architecture Group of the University of Groningen (the Netherlands) is conducting a variability requirements engineering survey with the goal of understanding the needs of practitioners when dealing with variability in the real world.

The group defines variability as the ability of a software system or artifact to be adapted (e.g., extended, customized or configured) for use in a specific context. Examples of variability-intensive systems include software product lines or families like MS Office, self-adaptive systems, or open platforms like JEE.

To participate in this survey, the participant should:

have RE experience (industry, research):

have experience with industrial software projects (including industry-research collaborations): and

have an understanding of variability (e.g., from product lines, self-adaptive systems, open platforms, anticipating change during RE, or planning different product versions or releases).

To take the survey, which is anonymous and takes only a few minutes: http://www.reviss.org

Featured Society

Design and Technology Teachers’ Association Victoria (DATTA Vic.)

DATTA Vic. is a non-profit organization formed in October 1987. From humble beginnings as a group of like minded teachers of technology, DATTA Vic. has grown to a membership of over 650. The DATTA Vic. represents technology teachers in education throughout the State of Victoria, Australia.

You might ask, what does this have to do with systems engineering?

Well, actually, quite a lot. To their huge credit, DATTA Vic. has recognized the significance of systems engineering as an overarching discipline of problem solving applied to technical problems, and has for some time embraced systems engineering within its mantra. Its members teach the Victorian Certificate of Education (VCE) subject “Systems Engineering” to secondary students in their university entrance qualification year. Systems engineering figures predominantly on the Association’s home page.

More information: http://www.datta.vic.edu.au/aboutus/index.html

Course accreditation: http://www.vcaa.vic.edu.au/vce/studies/futuresd.html

INCOSE Technical Operations

AFIS Technical Committees (TCs)

AFIS, Association Française d’Ingénierie Système, acts as the French chapter of the International Council on Systems Engineering (INCOSE). AFIS is a non-profit organization that was founded in 1998. A Memorandum of Agreement defines the terms of an affiliation agreement between AFIS and INCOSE. AFIS is comprised of corporate members (companies, public organizations, Subject Matter Experts (SMEs), Education and Research organizations), and individual members. As of 2012, AFIS included 40 corporate members (22 companies and public organizations, 5 SMEs, and 13 academia), and 450 individual members (including 300 free members from the corporate members). AFIS operates a number of Technical Committees.

Each AFIS Technical Committee (TC) is created by a decision of the AFIS Steering Board. The projects proposed by each Technical Committee are approved and can be funded by the AFIS Steering Board.

A set of two linked books: “INCOSE SE Hdbk 3.2” and “Découvrir et Comprendre

l’Ingénierie Système” are the common reference system for all TCs.

Two books have been developed by an AFIS global effort:

“Découvrir et Comprendre l’Ingénierie Système” (390p). This book is in publication by CEPADUES;

AFIS White Book called “Ingénierie Système: La vision AFIS pour les années

2020-2025”. This book will be published by CEPADUES. An English language version is available in PowerPoint format.

All the AFIS documents are written in French. English versions are made when necessary (e.g. for international co-operation).

TC SEM (Systems Engineering Management)

Technical area:

For all the systems life cycle phases, from the bid and proposal until disposal:

methodologies, models, and practices, tools used to drive the systems engineering activities in the project management environment. Systems engineering team organization in a multi-enterprise approach.

Leadership:

Chair: Roland Mazzella, Thales

Co-Chair: Gilles Meuriot, Areva TA

Accomplishments / Products:

Top ten practices to be applied to succeed a long term relationship between SMEs and industrial companies

“A practical method to reach consensus and take informed decisions amidst diverse, heterogeneous and conflicting goals”

Current Projects:

Global owning cost structuring through the system life cycle plans and phases.

Interface control: Take care for the Product and for the Project

SE management guidebook for SMEs (in connection with the ISO project: SE for VSMEs)

SE scoreboard for the technical activities management.

TC SE Global Processes

Technical area:

Improvement of systems engineering processes taking place in all the lifecycle phases:

SE customization to specific environments

SE application in specific domains

Application of crossing-cutting approaches.

Leadership:

Chair: Alain Le Put, MALP Conseil

Co-Chair: TBD

Accomplishments / Products:

Good practices for requirements engineering

Good practices for customer needs elicitation

Engineering requirements and architecture for a product line approach

SE survey for VSMEs

Guide to implement a product line approach

System Requirements in a product line approach

System Architecture in a product line approach

Current Projects:

System Modeling approach in a product line approach

Guidebook to implement LEfSE

SE for VSMEs : ISO Project based on ISO29110

Using CMMI to implement Lean systems engineering

TC Research and Innovation in Systems Engineering (new)

Technical area:

This TC is devoted to academic research with a given level of maturity (TRL 3-5): underpinning theoretical principles, number of technical papers, number of involved researchers or institutions. The technologies well known in other disciplines but whose innovation is to use it in Systems Engineering are also in the technical area for this TC.

Leadership:

Chair: Catherine Devic, EDF

Co-Chair: Bruno Vallespir, University of Bordeaux

TC Human Factors

Technical area:

This TC encompass the scientific understanding of the properties of human capability, the application of this understanding to the design, development, deployment and use of systems and services, and the art of ensuring successful application of Human Factors Engineering on a project.

Leadership:

Chair: Regis Mollard, University of Paris Descartes

Co-Chair: Marion Wolff, University of Paris Descartes

Accomplishments / Products:

Human Factors seminar, July 2011

HF chapter in the AFIS White Book SE 2025 Vision

Current Projects:

Human Factors integration in the SE Life Cycle (why, when, how) leaflet `

Guidebook: “The role of HF inside systems engineering: towards an integrative approach”.

TC Dependability, Maintainability, and Validation of Systems.

Technical area:

All the activities and “ilities” used to build trusted systems: dependability and sustainability, integration, verification and validation, technical and social risks control, all kinds of maintenance: preventive, curative, adaptive and evolutionary are in the scope all of this TC.

Leadership:

Chair: Tony Hutinet Dassault Systems

Co-chair: Eric Levrat, University of Nancy-Lorraine

Co-chair: François Peres, ENI Tarbes

Current Projects:

I V&V training curricula for SE

Guidebook: “Good practices to control integration activities”

TC MBSE

Technical area:

Formalized application of modeling to support system requirements, design, analysis, verification and validation activities (beginning in the conceptual design phase and continuing throughout development and later life cycle phases).

This TC is starting up a new orientation with two tracks:

MBSE with SysML as modeling language. In this case, the objective will be to provide the best enabling means for a better SE with SysML. These activities will reuse and will be complementary to those of the INCOSE MBSE Initiative.

MBSE with more formal approaches, already successfully applied but underestimated; for instance: DSM (Design Structure Matrix), System Dynamics (Forrester MIT), MATE (Multi Attribute Trade space Exploration). In this case, the objective will be to popularize, make operational, the formal approaches which will have been selected.

Leadership:

Co-chair: Alain Kerbrat, Collesys

Co-chair: Jean Luc Wippler, EADS Cassidian

Current Projects:

Which modeling techniques to model what?

Dissemination: MBSE explained to my boss

Basic constructions catalogue in modeling

Oldies but goodies: reuse of System Dynamics models

TC Training and Skills

Technical area:

Systems Engineering skills: how to identify and characterize them (universities, enterprises)

Systems Engineering Practices training: students and engineers (continuing training

or on the job training)

Leadership:

Chair: Eric Bonjour, University of Nancy Lorraine

Co-chair: Patricia Pancher, Thales University

Accomplishments / Products:

SE Student’s competition (RobAFIS) Guide

AFIS Academia/Industry Forum Guide

RobAFIS 2011 in Nancy event (Dec 8th 2011)

BKCASE & GRCSE contribution

Current Projects:

SE skills reference basement

RobAFIS 2012 and AFIS Forum 2012

SE minimum curriculum

SE training for high schools

TC Systems of Systems and Services, Architecture and Engineering

Technical area:

Best practices dissemination and concept development regarding:

Systems of Systems engineering

Services engineering

Architecture and architecture frameworks

Complex systems

Organizations and systems interoperability

Leadership:

Chair: Jean Luc Garnier, Thales

Co-chair: Claude Pourcel, LGPIM

Accomplishments / Products:

SoS glossary and data model.

Definitions of services for the benefit of SoS,

Organizational interoperability (paper)

Current Projects:

Service Engineering Life Cycles

System engineering and sustainability

Systems Engineering Tools News

Helping Enterprise Architects Better Relate to TOGAF and DoDAF

Governments in particular are using various frameworks to improve their architectural planning and IT implementation. At the upcoming The Open Group Conference in Washington, D.C., July 16-18, Chris Armstrong, President of Armstrong Process Group, will examine the use of TOGAF 9 to deliver Department of Defense (DoD) Architecture Framework or DoDAF 2 capabilities. He will discuss how to use TOGAF architecture development methods to drive the development and use of DoDAF 2 architectures for delivering new mission and program capabilities. His presentation will also be live-streamed free from The Open Group Conference. The discussion now is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

More Information http://www.zdnet.com/blog/gardner/learn-how-enterprise-architects-can-better-relate-togaf-and-dodaf-to-bring-best-it-practices-to-defense-contracts/4671

Applying Test Driven Development for Embedded and Real-time Development Using Model Based Testing

Increasing complexity and the need for ever-shorter development cycles are pushing embedded development teams to the limit. To gain a competitive edge, companies are looking toward agile methods, such as Test Driven Development, to help prevent defects by ensuring requirements are understood at the earliest stage and that the right solution is developed. Model-driven development approaches can help teams raise the level of abstraction to improve collaboration and better manage complexity. Linking model-based testing and test driven development offers an opportunity to add real agility to the development process. This webcast looks at how a test-driven development approach can utilize model based testing with the IBM Rational solution for systems and software engineering to deliver complex solutions faster with less risk.

More Information http://spectrum.ieee.org/webinar/2087585

Gartner Adds No Magic, Inc. to Business Process Analysis

Magic Quadrant 2011

No Magic, Inc., a leading global provider of integrated modeling, simulation and analysis solutions and services, announced that it has been positioned by Gartner, Inc. in the Magic Quadrant for Business Process Analysis Tools.

No Magic’s MagicDraw is known in the industry as a leading object-oriented analysis and design tool. MagicDraw’s active validation feature helps ensure enterprise-wide consistency across teams and checks the model against business rules and meta-model constraints, notifying users of any violation.

No Magic was evaluated for the Magic Quadrant for Business Process Analysis Tools based on its ability to execute and completeness of vision. MagicDraw provides strong BPMN, UML, SysML, UPDM, DoDAF, MODAF and SoaML modeling support with simulations using activity execution (OMG UML standard), State Diagram (WC3 SCXML), and full SysML bidirectional parametric execution.

More Information https://mail.google.com/mail/u/0/?tab=wm#inbox/13832d3c559d3540

arKItect™ – Seamless Representation of Multi-Scale Systems

arKItect™ provides collaborative graphical modeling of complex systems. A unique model combining different point of views is kept in sync. arKItect™ helps making architecture choices by providing a clear, coherent and structured view of the system.

arKItect™ has been used to define functional software and hardware architecture and to produce specifications and safety documentation.

More Information http://www.k-inside.com/web/en/

IBM and NI Plug Systems Engineering Gap

NI and IBM are building an integration between IBM Rational Quality Manager test management and quality management tool, and NI’s VeriStand and TestStand real-time testing and test-automation environment. The integration is designed to plug the gap and provide full traceability of what’s defined on the test floor back to design and development, enabling more iterative testing throughout the lifecycle and uncovering errors earlier in the process, well before building costly prototypes. The ability to break down the quality management silos and facilitate earlier collaboration provides an opportunity to reduce costs if you look at the numbers IBM Rational is touting. It is said that a bug that costs $1 to fix on a programmer’s desktop costs $100 to fix once it makes its way into a complete program and many thousands of dollars once identified after the software has been deployed in the field. While the integration isn’t yet commercialized (it is expected at the end of the third quarter), there is a proof of concept being tested with a half dozen NI/IBM customers.

More Information http://www.designnews.com/author.asp?section_id=1394&doc_id=245510&f_src=designnews_gnews

Latest Version of Siemens PLM Software’s Teamcenter Platform Zeros in on Systems Engineering

Stuart Johnson, Siemens PLM Software’s Director of Product Marketing for Teamcenter, advises that Siemens has offered requirement management and other systems engineering functionality as part of the Teamcenter portfolio for some time, but only in standalone modules and components that were not integrated into the core platform’s unified data architecture. With Teamcenter 9’s release, systems engineering functionality has been brought into the fold — all the systems definitions of the product and the resulting interconnecting relationships are managed as part of the core product model.

More Information http://www.designnews.com/author.asp?section_id=1394&doc_id=243085

eXpress for Diagnostic Modeling and Analysis from DSI International

eXpress from DSI International, Inc. facilities a diagnostic development process for Life Cycle Cost (LCC) with the aim of optimizing “Design for Testability” and “Design for Diagnosability”, to increase maintenance efficiency, safety and operational availability, while reducing cost of ownership.

eXpress, presently in Version 5.12.0, is a fully-featured, off-the-shelf software application providing an environment for the design, capture, integration, evaluation and optimization of system diagnostics, prognostics health management (PHM), and holistic systems testability engineering. Some features include:

design capture, for both up-front and legacy designs

diagnostics and testability analysis

prognostics design influence

reliability engineering support

maintainability engineering support

validation and verification

sensor optimization and trade-off studies

1553 Bus Modeling

“FMECA Plus”.

More information: http://www.dsiintl.com/WebLogic/Products.aspx?Page=eXpress/WhatIsExpress.ascx

STAGE Simulation-based Diagnostic and Prognostic Analysis Tool from DSI International

STAGE from DSI International, Inc. is a simulation-based diagnostic and prognostic analysis tool that provides directly traceability of the simulation to a fully integrated systems diagnostic and prognostics design. STAGE, presently in Version 4, simulates the impact of diagnostic, PHM and ISHM engineering decisions upon the support capabilities of a system during its useful lifetime.

STAGE can be used to evaluate the impact and conduct trade-off analyses upon:

Operational support

Condition-Based Maintenance

Reliability-Centered Maintenance (RCM)

Mission success

Remaining useful life

Diagnostic false alarms

Costs and sparing.

More information: http://www.dsiintl.com/WebLogic/Products.aspx

eDev Technologies, Inc. Announces inteGREAT Smart Docs

eDev Technologies (www.edevtech.com) announced the initial availability of its requirements authoring technology inteGREAT Smart Docs, a Microsoft Office Word 2010 or 2007 plugin for requirements authoring and collaboration.

“A key challenge faced by organizations today is that business and IT use different tools; businesspeople tend to use tools like Microsoft Word, while IT staff use other technical tools for requirements engineering. This leads to broken communication, rekeying data, redundancy, lack of traceability, and fragmentation of information,” says Asif Sharif, Chief Technologist, eDev Technologies.

inteGREAT Smart Docs allows business users, managers and analysts to author requirements with the familiar, yet structured, Microsoft Word 2010 or 2007 interface. Information from Smart Docs is automatically saved in the requirements repository, Team Foundation Server, as: goals, risks, market potential, requirements, user stories, actors, events, processes and data; along with their properties, attachments and traceability. “This provides TFS users with a very familiar user interface, will enhance its speed of adoption, while broadening its use throughout the enterprise,” says Brian Harry, Product Unit Manager for Team Foundation, Microsoft Corporation.

More Information

http://www.marketwatch.com/story/edev-technologies-inc-announces-integreat-smart-docs-2012-06-20

Systems Engineering Books, Reports, Articles and Papers

Agent-Directed Simulation and Systems Engineering

Levent Yilmaz and Tuncer Oren

Published by: Wiley Series in Systems Engineering and Management

ISBN: 3527407812, 9783527407811

Format: PDF

Abstract: The authors provide an overview of the simulation and systems engineering areas; describe principles, methods, tools, and environments; and discuss applications in such areas as testing and evaluation, process performance analysis, decision support, and organization and work system engineering.

“It is probably the only book to date, to present the synergy between modeling and simulation, systems engineering, and agent technologies and to also deal with agent simulation and agent-supported simulation.” (Inside OR, November 2009)

More Information http://goboqona.multiply.com/journal/item/83/Agent-Directed-Simulation-and-Systems-Engineering-Wiley-Series-in-Systems-Engineering-and-Management-download-ebook

Discovering Real Business Requirements for Software Project Success

Robin F. Goldsmith

Published by: Artech House

ISBN-13: 978-1580537704

Format: Hardcover

The following review is provided by Johanna Rothman on Amazon.com:

If you ever wanted to know if your requirements were accurate and complete, this book will help. As the author says on p. 13, “…we’re going to intermix discovery methods with techniques for testing the adequacy of requirements.” Using his problem pyramid, which includes a way to measure the problem and the solution, the author discusses several techniques to elicit and define requirements. He defines 64 techniques to test requirements throughout a project. For example, test method #17, “identify assumptions” is common sense that too few people remember. Test method #53 is “Defining acceptance criteria,” a technique useful for any project if you want to know you’ve built what the customer wanted. Between the problem pyramid emphasis on measurement and the various tests, the book can help you meet its promise of preventing too much requirements change throughout a project.

New Whitepaper from Vitech Corporation Guides Systems Engineers Seeking Most Effective Design

Vitech Corporation is now offering free access to its new 19-page whitepaper entitled 9 Laws of Effective Systems Engineering, authored by Zane Scott, Vitech’s vice president of professional services and author of the recently released book, A Primer for Model-Based Systems Engineering. Vitech is making the whitepaper available to systems engineers, project designers and managers, engineering students, or anyone interested in learning more about model-based systems engineering.

More Information http://www.marketwatch.com/story/new-whitepaper-from-vitech-corporation-guides-systems-engineers-seeking-most-effective-design-2012-06-13

Systems Journals

The following is a list of journals on systems in general (as distinct from journals specifically on systems engineering):

Acta Cybernetica

http://www.inf.u-szeged.hu/actacybernetica/starten.xml

Complex Systems

http://www.complex-systems.com/

Constructivist Foundations (e-journal)

http://www.univie.ac.at/constructivism/journal/

Cybernetics and Systems: An International Journal

Taylor & Francis: http://www.tandfonline.com/toc/ucbs20/current

Cybernetics and Human Knowing

Imprint Academic: http://www.imprint-academic.com/C&HK

Dynamical Systems: An international journal

Taylor & Francis: http://www.tandfonline.com/toc/cdss20/current

Emergence: Complexity and Organization [E:CO]

http://www.emergence.org/

Entropy

MPDI: http://www.mdpi.com/journal/entropy

European Journal of Control

Hermes Science: http://journals.dei.polimi.it/ejc/

European Journal of Economic and Social Systems (in French)

Lavoisier: http://www.lavoisier.fr/gb/e-revues/index.asp?texte=0947-3580&select=issn&exact=on&from=RevuesOnline

European Journal of Information Systems

The OR Society/Palgrave Macmillan: http://www.palgrave-journals.com/ejis/index.html

European Journal of Operational Research

Elsevier: http://www.journals.elsevier.com/european-journal-of-operational-research/#description

IEEE Transactions on Systems, Man, and Cybernetics

IEEE: http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=3477

Interdisciplinary Description of Complex Systems

http://www.indecs.eu/

International Journal of Control

Taylor & Francis: http://www.tandfonline.com/toc/tcon20/current

International Journal of Human-Computer Studies

Elsevier: http://www.sciencedirect.com/science/journal/10715819

International Journal of Man-Machine Studies (now renamed)

Elsevier: http://www.sciencedirect.com/science/journal/00207373

International Journal of General Systems

Taylor & Francis: http://www.tandfonline.com/toc/ggen20/current

International Journal of Information Technologies and Systems Approach

IRMA/IGI Global: http://www.igi-global.com/journal/international-journal-information-technologies-systems/1098

International Journal of Systems Science

Taylor & Francis: http://www.tandfonline.com/toc/tsys20/current

Journal of Applied Systems Analysis (Now published as the European Journal of Information Systems)

Back copies: http://www.periodicals.com/html/ihp_e.html?ej50581

Journal of Applied Systems Studies

Cambridge: http://www.unipi.gr/jass/

Journal of Organisational Transformation and Social Change

Intellect: http://www.intellectbooks.co.uk/journals/view-journal,id=128/

Journal of the Operational Research Society

The OR Society/Palgrave: http://www.palgrave-journals.com/jors/index.html

Journal of Complexity

Elsevier: http://www.journals.elsevier.com/journal-of-complexity/

Journal of Social and Evolutionary Systems (until 1999 known as Journal of Social and Biological Systems)

Elsevier: http://www.sciencedirect.com/science/journal/10617361?oldURL=y

Journal of Systems Management (no longer published)

Back issues: http://www.accessmylibrary.com/archive/412190-journal-of-systems-management.html

Journal of Systems Science and Complexity

Springer: http://www.springer.com/mathematics/applications/journal/11424

Journal of Information Science

Sage: http://jis.sagepub.com/

Kybernetes

Emerald: http://www.emeraldinsight.com/products/journals/journals.htm?id=k

Open Systems and Information Dynamics

Springer: http://www.springer.com/physics/complexity/journal/11080

SIAM Journal on Applied Dynamical Systems

SIAM: http://www.siam.org/journals/siads.php

Simulation

SCS/Sage: http://www.sagepub.com/journalsProdDesc.nav?prodId=Journal201571

Systemist

UKSS: http://www.first-pages.com/ukss/publications/systemist

Systems Dynamics Review

SDS/Wiley: http://onlinelibrary.wiley.com/journal/10.1002/%28ISSN%291099-1727

Systems Research and Behavioral Science

IFSR/Wiley: http://onlinelibrary.wiley.com/journal/10.1002/%28ISSN%291099-1743a

Systemic Practice and Action Research

Springer: http://www.springer.com/business+%26+management/journal/11213

Conferences and Meetings

International Conference of the System Dynamics Society, 2012

July 22 – 26, 2012, St. Gallen, Switzerland

More Information

ASME 2012 International Design Engineering Technical Conferences (IDETC) and Computers and Information in Engineering Conference (CIE)

August 12-15, 2012, Chicago, IL, USA

The Conference incorporates constituent conferences which include:

1st Biennial International Conference on Dynamics for Design (DFD)

32nd Computers and Information in Engineering Conference (CIE)

38th Design Automation Conference (DAC)

9th International Conference on Design Education (DEC)

24th International Conference on Design Theory and Methodology (DTM)

17th Design for Manufacturing and the Life Cycle Conference (DFMLC)

PPI SyEN 46

Subscribe to PPI SyEN

PPI SyEN 141

PPI SyEN 140

PPI SyEN 139

PPI SyEN 138

FREE Original SE Articles and Industry News?

Subscribe to PPI

MORE About Us