Based on the 6th edition of ‘Software Engineering’ by Ian Sommerville, published by Addison Wesley. (amazon.com, amazon.co.uk)

This chapter is basically a high level introduction of the rest of this software engineering text, and so I’m not entirely sure it deserves quite the same treatment as the rest. To get myself into the swing of things, however, I’ll just forge ahead regardless and see how things go.

There are a number of interesting points in the introduction to the introduction. Any discussion of software engineering always seems to start out with a mention of the term ‘software crisis‘ which described the collapse of informal software development processes when faced with the demands brought on by the ever increasing power of computer hardware. This idea always seems to be trotted out to explain why we need software engineering, but I’ve never really experienced it. Perhaps it’s just that by the time I was developing any systems of significant size, enough software engineering techniques had become common place that the study of software engineering ceased to be a solution to a crisis so much as a way to improve the acceptable processes already in place. Sommerville ends the introduction on this, more positive note, noting software engineering’s achievements (space travel, the internet, telecommunications systems) and the possibilities for the future.

FAQs about software engineering

I actually find the FAQ style quite odd for a text book, and I’m not a big fan of it in general, but there are some interesting questions dealt with in this section none the less.

What is software?

Sommerville defines software to include both the actual computer program(s) and supporting documentation, which may be a bit of a change for most people. This is done, I’m assuming, to get us into the pattern of thinking about software in a broader context than just a bunch of code, which is one of the key principles of software engineering, so the definition is likely appropriate.

Software is then divided into two types, ‘Generic products’ and ‘Bespoke (or customised) products’. Generic products are those which are designed around generic needs, and are sold to anyone willing to pay for them. This is the kind of software I always wanted to develop when I was growing up, and is the kind of thing most people think of as software although it’s actually the smaller of the two groups. Bespoke products are software systems which are developed for a particular organisation, and to their specific requirements.

The distinction here is quite an important one to keep in mind, as a number of conflicts arise if you confuse the two types. I used to work with a company in the process of rewriting a software platform they considered a generic product as a part of a major customer project focused around the development of what was, in effect, a bespoke system. The conflict here was around the control of the requirements. A a bespoke system, the customer demanded the system be built specifically to match their business requirements while internally, the goals were to develop a generic system to an internal set of requirements without enforcing any business requirements. Being the guy who was onsite most of the time, I ended up as the ‘customisation expert’, which is to say I basically found myself implementing the bespoke system over the generic foundation the rest of the developers were building, and I suspect a good deal of grief could have been avoided if, at least internally, these had been considered two entirely separate projects. I guess the moral of that story is to clearly understand what type of software you are building, who controls the requirements, and try to do only one thing at a time.

What is software engineering?

Everyone loves to have a good job title, and software development activities have quite a few to choose from. Sommerville’s key points to distinguish software engineering are the engineering discipline and the focus on all aspects of production.

Engineering discipline is obviously reflected in the name, and is a key distinguishing factor between software engineering and computer science. Engineers are trained to build things, respecting real world constraints like cost, where as scientists are trained to research and discover things without too much focus on the practical applications. One source of confusion is that traditionally the majority of computer science graduates do not go on to perform research but rather to develop software in a commercial environment, and so computer science courses tend to teach some of the engineering discipline aspects.

The focus on ‘all aspects of software production’ effectively distinguishes software engineering from ‘computer programming’, since is covers fields such as project management and ongoing maintenance in addition to the core development aspects.

What is the difference between software engineering and computer science?

As I mentioned above, the ‘engineering discipline’ verses ‘research’ aspects are the key difference. Ideally computer science would feed into software engineering in the same way chemistry feeds into chemical engineering, but I think both fields have a good deal of maturing to do to reach that goal. Sommerville is more pessimistic than me on this score, and describes computer science theories as elegant, but often unable to be applied to complex, real world problems.

What is the difference between software engineering and system engineering?

Sommerville describes system engineering (specifically computer-based system engineering) as existing at a higher level, covering hardware development, system deployment etc. I would be tempted to think of things like running a telecommunications carrier as ’system engineering’, where you need to concern yourself with a whole bunch of physical infrastructure in addition to software systems. That said, I can’t say I know much about system engineering but it looks like I’ll be reading all about it in chapter 2.

What is a software process?

Basically, a software process is described as some process which results in some software being produced. A common phases which exist in all such processes are specification, development, validation and evolution, but these may be arranged in different ways depending on the specific software process.

I’ve lived through a few different processes in my time, including agile, waterfall and Schlaer Mellor, and in the end, all of them have something to say about each of these phases.

What is a software process model?

Somerville defines a software process model as a high level description of a software process from a particular perspective, such as a workflow, activity or role/action model. Each of these describe some aspect of the process, but I would say that in my experience the activity model is the most used.

Somerville then presents a few general models, including:

  • waterfall
  • evolutionary
    Similar to what I called agile above.
  • formal translation
    Similar to Schlaer Mellor from above, except the focus here is more on mathematical basis, so maybe where thinking something like the formality of Z notation mixed with Schlaer Mellor’s transitive approach.
  • System assembly from reusable components
    Which Sommerville describes as integrating existing ‘parts’ to create a finished system. I find this a little odd, as every software integration project I’ve ever worked on has ended up developing some ‘glue’ code to hold everything together, meaning that I don’t really understand the value of this distinction. In any case, it looks like chapter 14 may provide some more insight into this.
What are the costs of software engineering?

This one is always and interesting discussion, and comes up about as often as the ‘Software crisis’ term in software engineering discussions. Sommerville provides a quick breakdown of the cost distribution through the software process, which is outlines as follows.

Initial development of a bespoke software product tends to break down as about 15% specification, 25% design, 20% development and 40% integration and testing. In an evolutionary process model there is no rigourous upfront specification so the phases are harder to break down. Sommerville breaks this down as about 10% specification, 60% evolutionary development and 30% system testing. Finally, for generic software products, the identification of different phases is even less distinct, with new versions of software being a mix of evolving new functionality and revision of old functionality, so Somerville pulls this out as about %5 specification, 35% development and 60% system testing.

New developers tend to be shocked at the big numbers thrown at testing there, and it’s also interesting to note that as the ‘formality’ of the process decreases, the required level of testing increases. This does not mean more formal approaches are necessarily better, as we haven’t specified the total time for each approach, but it does highlight the required focus on testing in software engineering.

The one other key point to note is the system evolution component, which is difficult to define for generic software products, but tends to be about 3 time (i.e 75% vs 25%) of the initial development costs for bespoke software.

Sommerville finishes off with a mention of e-commerce web-based systems, and that their heavy use of ‘off-the-shelf’ components and high user interface costs might mean they have a different profile to that presented here. Personally I don’t believe web software is any different from other software at this level, and is likely to fit more of less into the breakdowns presented, though I have no figures to back that up.

What are software engineering methods?

Sommerville defines software engineering methods as something which provides a structured approach to software development, and then expands on this, requiring that it facilitate this in a high-quality and cost-effective way. Personally I’d be tempted to remove the high-quality and cost-effective requirements and just say that any method which doesn’t live up to those goals it likely to be a bad one, but a method none the less.

The most famous method is going to be object oriented design, but a few others I’m not really familiar with the details of (Structure analysis and JSD) are also mentioned. UML (unified modelling language) is also mentioned, but not discussed in any depth here.

The key components of a software engineering method are given as :

  • System model descriptions
    Some structure way of modeling the system to be developed, as in state machine models, object models etc.
  • Rules
    Constraints which must be enforced within the models. (Sommerville suggests unique entity names)
  • Recommendations
    Suggestions for applying the model effectively. In my experience problems often arise when some method is mandated for the development of a system where is it is not really appropriate. These sort of recommendations are useful for identifying these cases, since though it might be possible to twist a model into some remote case, it is hopefully not recommended.
  • Process guidance
    Guidance about how to apply the model, including things like the order in which components of the system should be modelled.
What is CASE?

CASE is short for Computer-aided Software Engineering, and is used as a generic term for a bunch of software engineering tools to assist with analysis, modelling, debugging and any other software engineering tasks. I’ve not really worked extensively with the sort of tools people tend to put into these categories, preferring to control documentation structure etc. myself using generic tools, but I can certainly see the value of specific tools when following an associated method.

I have not previously heard the distinction, but Sommerville mentions that analysis and design tools are generally called upper-CASE and those supporting implementation and tests (which I have worked more extensively with) are called lower-CASE tools. With that in mind then, I guess I will say that it’s hard to overestimate the usefulness of good debugging and profiling tools. My most recent job had me working on a rather immature platform, and there’s no doubt that debugging with printf and hand profiling code is far more time consuming than it would be with good tool support.

What are the attributes of good software?

This is a rather broad question, but Somerville presents the software engineering perspective that the key attributes are maintainability, dependability, efficiency and usability, then makes it clear that this text deals only with the first two, and the others are quite technical and domain specific areas.

Maintainability is a very difficult goal to achieve without time allocated to it specifically, as in every projects I’ve ever worked on, there is always a tendency to go for the ‘quick win’, which tends to increase complexity over time. Even in software which is well designed up front, changing requirements tend to introduce design changes which disrupt things. Anyway, I’m sure this will be covered in a lot more depth through the text, so I’ll save my anecdotes.

Dependability is interesting in that it can mean a lot of different things. Reliability, security and safety all come in different degrees, and deciding just how reliable a piece of software needs to be can be quite tricky. Customers will always tend to demand perfection, and in matters of life and death perfection should be the goal, but in certain cases, less reliability might be an appropriate choice given the costs involved.

What are the key challenges facing software engineering?

Sommerville identifies three key challenges, specifically maintaining legacy software (the legacy challenge), building software to work across a broad range of platforms in a networked environment (the heterogeneity challenge) and improving the turn around time to meat business requirements with/in complex systems without compromising quality (the delivery challenge).

The heterogeneity challenge is an interesting one from my point of view, because I don’t really believe things are getting worse in this regard. There may be areas of greater complexity, but I can’t help but think of things like web platforms, Java’s JVM (or .Net’s CLR) which provide a single bridging platform for further development (arguments about the quality of that platform notwithstanding). I believe the majority of development will continue to be on these bridging platforms (I guess how much of a legacy nightmare this creates remains to be seen).

Professional and ethical responsibility

Ethics is a key aspect of engineering, and Somerville mentions both the codes of conduct produced by professional societies and what he sees as the key aspects, specifically, confidentiality, competence, intellectual property rights and computer misuse. This is an interesting area, but thankfully I’ve never been faced with a serious dilemma of this nature. There is often a conflict in the interests of an employer and a customer, but my work has never been of a critical enough nature to require breaking ranks and publicly siding with a customer (although I’ve done so internally on many occasions).

Sommerville also makes brief mention of military and weapons systems as key ethical areas software engineers are likely to face. Personally I think I would have a hard time accepting a job working on weapons systems simply because I am weary of my work being used to support causes I don’t personally support.

There is a very brief description provided of some attempt to look at ethics in software engineering from a philosophical standpoint, which is something I would be interested in researching further, but Sommerville states that this sort of discussion is difficult to apply to everyday experience.ef