| |
NewswireTODAY - /newswire/ -
Melbourne, Victoria, Australia, 2008/11/13 - Intended for general readership in the worldwide engineering community, the newsletter (SyEN) presents an in-depth coverage of the month’s news in systems engineering and directly related fields, plus relevant industry events.
|
| |
Systems Engineering is an interdisciplinary approach to engineering, encompassing the technical and management efforts to evolve and verify an integrated, holistic and life-cycle balanced system solution that satisfies requirements and maximises effectiveness according to the values of the stakeholders.
The first newsletter features, amongst much other content, an article on Agile Systems Engineering by Mr. Robert Halligan.
The newsletter will be useful for anyone working in a project environment, or wishing to better their understanding of systems engineering.
Subscription to SyEN is available at PPI’s website.
Example Feature Article
Agile Systems Engineering – Some Views
An interesting paper: “Toward Agile Systems Engineering Processes” by Dr. Richard Turner, of the Systems and Software Consortium, appears in the April 2007 edition of Crosstalk, The Journal of Defense Software Engineering.
There is much in the paper that I agree with, and some content that I cannot embrace. In the latter respect, most of my disagreements relate to the author’s extreme characterizations of systems engineering – nobody in their right mind would do systems engineering the way the author describes. Certainly, none of PPI’s clients do systems engineering that way!
My other major criticism of the paper is that it fails to acknowledge the (presently) high degree of avoidable rework in most implementations of agile development. The paper stresses the merits of early and frequent delivery of capability usable by the customer/user. In reality, this is sometimes possible, and sometimes valuable. For software, and software-intensive systems, we could replace “sometimes” with “usually”. Conversely, early delivery of capability is sometimes impossible, or sometimes totally without value. A replacement for the bridge that collapsed in Minneapolis is an example of the latter; a control system for a nuclear reactor is another example.
The paper fails to acknowledge that proceeding in ignorance of what is already known about “the problem” is rarely a part of the formula for producing the best outcomes. When the cost of discovering this known information is less that the cost of rework from failing to do so (almost always the case), we waste money and time. In essence, the paper reflects an unawareness of the existence of very effective, low cost techniques for requirements capture and validation – techniques that typically cost only 0.1%-2% of total project cost.
None of the above comment negates the value of agile as one of the primary strategies for system development. When we “engineer the engineering”, agile falls out as the process solution of choice, where it should do so. Similarly, waterfall, iterative, some form of evolutionary development other than agile, or spiral development, falls out, where that alternative will produce the best outcomes, on the balance of probabilities. For larger projects, all of these strategies may well be in effect – hopefully in the right places!
In summary, agile development has emerged as a respectable and entirely proper approach for some types of problem. However, present implementations often involve considerable rework which costs more than avoidance of the rework. I predict that agile will mature over the next decade towards an optimum balance of requirements capture through exposure of product, and requirements capture and validation through skilful problem analysis and dialogue.
Robert Halligan, FIE Aust
Managing Director, Project Performance International
|
contact[.]ppi-int.com 
