Software-Engineering includes determining Stakeholder Requirements, designing new Systems, adapting older Systems, subcontracting for components (including services), interfacing with Systems-Architecture, testing, Measurement, and other disciplines. It needs to control computer programming and other software related Sub-Processes (like Quality-Assurance, Requirements elicitation, Requirement-Specification), but it is not necessary that these sub-disciplines be carried out by the Software-Engineering Process itself. The emphasis should be on control of the outcome – the value delivered to Stakeholders, not of the performance of a craft.
The Concept “balanced set of values” (above) is used to emphasize the obligation of the Software-Engineer to determine the value or results truly needed by the Stakeholders, and not to be fooled by omissions, corruptions and misunderstandings of the real world value. The inevitable Constraints on the Engineering Solutions Means that intelligent prioritization of how much, or which values, will be delivered to which Stakeholders and when – must be intelligently considered, according to a defined Policy for prioritization.
The Concept “a balanced set of Stakeholders” (above) is used to emphasize the broad range of Internal-Stakeholders (like the development project and the producing organization), and External-Stakeholders (such as users, customers, governments, add-on suppliers) that the Software-Engineering Process must be obliged to deal with. We are consciously trying to break away from older, narrower notions that Software-Engineering is all about satisfying users, owners, or customers, alone.
• thanks for Ian Sommerville and Frans Ver Schoor for inspiring this revision
This Concept entered by Diane O'Brien.