Advertisement

The Systems Engineering Approach to Handling Complex Engineering Projects

  • Erik W. Aslaksen

Abstract

In the preceding chapter we identified the main sources of complexity in engineering projects, and in Sec. B2.3 we subdivided projects into a number of stages. We can now relate the two, in the sense of determining which sources determine the complexity in the various stages and thereby determine the complexity of the objects created within each stage. These objects are, as we know from Sec. B2.4, processes and the artefacts and descriptions resulting from them, and while our approach to handling them has a common basis, as was already foreshadowed in Ch. A5 and will be developed in more detail in the next section, there are also significant differences, as we shall discuss later in this chapter.

Keywords

Software Development System Engineering Engineering Project Complex Entity Contracting Strategy 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    The complex contracting arrangements in a number of large infrastructure projects are discussed in section 6.7 of Managing Large Infrastructure Projects, ref. 3 below Google Scholar
  2. 2.
    A well-known assessment of the success of software project is the CHAOS Manifest of the Standish Group, http://standishgroup.com, but it has also been criticised by a number of sources, many of which can be found by simply Google on “standish report”. However, there seems to be no doubt about the fact that large software projects have had a relatively poor rate of completion on time, within budget, and to agreed performance criteria, whatever may be valid reasons for this
  3. 3.
    The book Managing Large Infrastructure Projects, published by A.T. Osborne BV, 2008, is a most interesting and valuable documentation of lessons learned on 15 major infrastructure products in Europe, with the findings clearly organised into eight groups. The study specifically addresses Project Management, but because these are large and very complex projects, many of the problems encountered are those that arise in complex systems in generalGoogle Scholar
  4. 4.
    Failure Modes, Effects, and Criticality Analysis (FMECA) is a well-established process, documented in numerous textbooks and articles, and supported by different many tools. The best introduction is to look it up in Wikipedia, http://en.wikipedia.org/wiki/Failure_mode,_effects,_and_criticality_analysis
  5. 5.
    This text appeared in the Newsletter of the Systems Engineering Society of Australia (SESA), No. 48 (July 2009); under the title Why Software is Different Google Scholar
  6. 6.
    Data Item Descriptions (DIDs) were originally defined as part of MIL-STD-498, which consisted of two parts, Overview and Tailoring Guidebook and Application and Reference Guidebook, and aimed at software development. However, the concept has proved to be of enduring value and applicability, and current defence contracts often require compliance with a large number of DIDs Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2013

Authors and Affiliations

  1. 1.Gumbooya Pty Ltd.Allambie HeightsAustralia

Personalised recommendations