SEMAT and the definition of software engineering

Tom Gilb proposed a definition of software engineering as “Software engineering is the discipline of making software systems deliver the required value to all stakeholders.” This is a seductive definition but when we start to unpick it, we run into problems.

1. Organisations are incredibly diverse. There will inevitably be conflicts and you probably won’t discover most of them until you deliver a system. Furthermore, organisations change – the ‘value’ of a system is not the same on deployment as when it was initially proposed.

2. Many systems are deliberately disruptive. Management want to change ways of working and do so by introducing new software (often ERP systems). The idea is not to deliver value to all stakeholders but to deliver value to the ‘organisation as a whole’ – whatever that is.

3. In some organisations, stakeholders work in a state of creative tension – e.g. doctors and managers in a hospital. As a matter of principle, they will not agree on value.

4. In my experience, getting key stakeholders to engage in discussions about new systems is really hard – they are far too busy doing their jobs. On the other hand, they complain a lot when a system doesn’t do what they want.

Tom’s definition is good because it recognises that simplistic notions of ‘success’ don’t or shouldn’t apply to complex software. But culture and politics  and normal human cussedness mean that it’s really hard to make it work.

Advertisements

6 Comments

Filed under Uncategorized

6 responses to “SEMAT and the definition of software engineering

  1. I agree that Tom’s definition is a good starting point but that it needs tweaking. Would be nice if a blog like this could be used to work on that as a community. Let me start. I propose the following:
    Software engineering is the discipline of optimizing the value of software systems throughout their lifecycle for their owners.
    Why? Different stakeholders require different value. The one stakeholder for which value should be optimized is the owner. Optimized because it may not be the value that he required at the beginning but the value that is optimal given the context of demands of other stakeholders (whose acceptance is required to make the system valuable at all), technology, changes throughout the project, etc. An owner should understand the risk of a difference between initially required value and delivered value and base a GO decision on that understanding. Throughout the lifecycle because too often the software engineering effort is focused on delivering a first version and ease of extendability and of maintenance which are required for a long and valuable lifecycle are disregarded.

  2. I agree with Ian. And it makes me see that I need to re-craft my definition. Which I have. Here it is

    ——- Begin today’s edit——————-

    Software Engineering Concept *572 March 12, 2003, March 24 2010
    Software engineering is the engineering discipline of enabling and motivating software systems to deliver a balanced set of values, directly or indirectly, to a balanced set stakeholders, throughout their lifecycle*.

    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 value’ (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.

    Related Concepts [Software Engineering *572]:
    • Software *570
    • Engineering *224
    • Systems Engineering *223
    • Stakeholder *233
    • Value *269

    Type [Software Engineering *572]: Engineering Discipline.

    • thanks for Ian Sommerville and Frans Ver Schoor for inspiring this revision
    https://se9book.wordpress.com/2010/03/23/semat-and-the-definition-of-software-engineering/
    ———— end my recent edit —–

    This is updated in the full personal glossary at
    http://www.gilb.com/tiki-download_file.php?fileId=25
    (which has the old version, but you can see other related definitions there)

    an abbreviated glossary is published in Competitive Engineering
    http://homepage.mac.com/tomgilb/filechute/%20%20Gilb%20Competitive%20Engineering%20Book%20copy%201.pdf
    (this URL is NOT for general distribution! But can be downloaded by readers of this post)

    I do not agree with Frans’ comment about the Owner. he Owner is only one of
    many stakeholders, and has their due priority. But his point about ‘life-cycle’ is well
    taken, so I have included it.

    Thanks!

  3. @Tom
    I definitely consider your new definition an improvement. I would like to explain more clearly why I specifically mention the owner.

    I consider the owner the person who has the idea, the need. Who wants to automate a process, update a system, etc. The owner is also the budgetholder. The one paying the SE bill and looking for ROI from the SE system. To optimize ROI (minimal cost, optimal value and length of lifecycle) the system will have to comply with the needs of a diverse group of stakeholders, indeed ranging from government wanting the system to comply to regulation, to IT operations wanting to minimize cost of maintenance, to end users wanting efficient use of the system. Still, the needs of all those stakeholders need to be assessed in the light of the ROI (would that be a better term than value?) the owner requires.

    In my view it is exactly the fact that SE efforts are often not related to ROI for the owner that makes many projects too complicated, too long, too expensive and with suboptimal functionality (more than desired functionality or missing desired functionality).

    I hope this clarifies my point about the owner and am very interested in feedback.

    I have described my (also value-centered) view on software project management elsewhere. I consider that work in progress and would also appreciate feedback on that view: http://fransverschoor.wordpress.com/2010/03/11/on-software-project-management/

  4. you list a lot of good ideas in general, but…..maybe too general and not enough information about the know benefits and costs and application areas for each idea, so they cannot be judged or chosen rationally

    “I have described my (also value-centered) view on software project management elsewhere. I consider that work in progress and would also appreciate feedback on that view: http://fransverschoor.wordpress.com/2010/03/11/on-software-project-management/

  5. I prefer value as more general than ROI, which is one type of value only.

    Not all owners want or need ROI primarily, or at all.

  6. Kenji Hiranabe

    I like the definition with stakeholder value.

    A simple question. Other xEngineering definitions such as civil engineering, do not refer to “stakeholder value”. Of couse other engineering disciplines should deliver value to stakeholders, but not mentioned. What makes software engineering so special ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s