Unified and Holistic Approach

  • Michael Hüttermann


This chapter will discuss a unified and holistic approach to software engineering. We’ll start with a discussion of concepts, particularly nonfunctional requirements. Then we’ll discuss one of the main dangers for collaboration between development and operations in more detail. Called a conceptual deficit, this can cause a discrepancy between business needs, project results, and expectations of operations.


Holistic Approach Moral Hazard Software Architecture Limited Rationality Business Case 


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 2.
    See Dean Leffingwell, Agile Software Requirements (Addison-Wesley, 2011), Chapter 17.Google Scholar
  2. 3.
    See Dean Leffingwell, Agile Software Requirements (Addison-Wesley, 2011), page 342.Google Scholar
  3. 5.
    See Gojko Adzic, Specification by Example (Manning, 2011), page 108.Google Scholar
  4. 6.
    See Mike Cohn, User Stories Applied (Addison-Wesley, 2004), page 178.Google Scholar
  5. 9.
    See Vilfredo Pareto, Manual of Political Economy (A.M. Kelley, 1969).Google Scholar
  6. 10.
    See Niccolo Machiavelli, The Prince, trans. Harvey C. Mansfield (University Of Chicago Press, 1998), Chapter 3.Google Scholar
  7. 12.
    See Taiichi Ohno, Toyota Production System: Beyond Large Scale Production (Productivity Press, 1988), page 17.Google Scholar
  8. 14.
    Len Bass et al., Software Architecture in Practice (Addison-Wesley, 2009).Google Scholar
  9. 16.
    See Michael Hüttermann, Agile ALM (Manning, 2011), Chapter 4.Google Scholar
  10. 17.
    See Alistair Cockburn, Writing Effective Use Cases (Addison-Wesley, 2001), pages 14 and 161.Google Scholar
  11. 18.
    Frank Buschmann et al. describe testability as a nonfunctional property of software architecture. See their Pattern-Oriented Software Architecture, Vol. 1 (Wiley, 1996), page 408.Google Scholar
  12. 19.
    See Lisa Crispin and Janet Gregory, Agile Testing (Addison-Wesley, 2009), page 104.Google Scholar
  13. 20.
    See James Whittaker et al., How Google Tests Software (Addison-Wesley, 2012), page 197.Google Scholar
  14. 22.
    See Jez Humble and David Farley, Continuous Delivery (Addison-Wesley, 2011), Chapter 9.Google Scholar
  15. 23.
    See Michael T. Nygard, Release It! (Pragmatic Bookshelf, 2007).Google Scholar
  16. 24.
    See Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Quality Before Design (Dorset House, 1998), page 274.Google Scholar

Copyright information

© Michael Hüttermann 2012

Authors and Affiliations

  • Michael Hüttermann

There are no affiliations available

Personalised recommendations