Out with the UML (and other stuff too): reimagining introductory courses in software engineering

In the 1980s and 1990s, universities started to introduce software engineering courses into their computer science degree programs. At that time, software engineering was dominated by the problems of creating large custom software systems. These were developed by managed teams working on long-lifetime software projects.

This project-based approach was reflected in software engineering courses and in textbooks developed to support these courses. My own book adopted this approach as did texts by Pressman, Van Vliet and others. These textbooks have evolved to reflect new developments but the most recent editions still reflect this project-oriented view of the discipline.

Of course, software projects are still a major part of the software industry but the modern reality is that most software companies are involved in software product and app development. Understandably, the expectations of many students are that they will learn about software engineering techniques that are relevant to this type of software.

My impression, however, is that most software engineering courses still have a project focus. They are still dominated by the terminology and techniques that are relevant for custom software engineering. Agile methods are often included to some extent but these sometimes sit awkwardly beside discussions of software processes and the UML.

I admit to complicity here. My book on software engineering, which is now in its 10th edition, has been extensively updated. However, these updates have reflected by own interests in large-scale complex systems. I have not really said much about product-oriented software engineering.

The problem with a project-oriented approach is that students find it difficult to relate to the type of software being developed. Consequently, the material sometimes seems irrelevant and uninteresting. This situation is exacerbated by the emphasis in the media on ‘coding’; the impression presented is that programming is all there is to software engineering;; other topics are unnecessary and out of date.

The reality of course is that, whatever some of the more extreme programmers say, there is a lot more to software engineering than coding. There remains a need for introductory software engineering courses that make this clear to students. However, I think we need to relate these courses to both the software experience of students and the technologies used to develop modern software products.

This means discarding the predominant project-oriented approach in the teaching of introductory software engineering. Such courses should focus on software products and how these products are developed. Agile methods are universally used in product engineering and we should teach relevant agile techniques, such as automated testing, but without the evangelism of some agile practitioners.

We also need to cover practical methods, such as scenarios and stories, used by product managers to understand what might appeal to users. People buying software products don’t have ‘requirements’ and conventional requirements engineering is not very relevant. Software architecture is critical and students need an introduction to architectural models and patterns.

A modern introduction to software engineering cannot ignore cloud computing. The cloud is becoming the predominant delivery mode for all desktop and laptop software so we need to talk about cloud software engineering and cloud-based service-oriented architectures. Security should not be an advanced topic – the creation of secure software should be an inherent part of all introductory SE courses.

So, where does this leave me as the author of a software engineering textbook that takes a more traditional approach? Will there be a new edition of my textbook that includes these product-oriented topics? Definitely not! But I’ve been working on a new book (as yet untitled) that takes a completely different approach to software engineering from my current text. I’ll write more about this in a later post.

2 thoughts on “Out with the UML (and other stuff too): reimagining introductory courses in software engineering

  • March 7, 2018 at 3:04 pm
    Permalink

    My personal experience sits on middle ground. I strongly feel that FDD is the proper compromise, it fits very well on both agile-studio-slash-boutique shops and on strongly hierarchical big organizations.
    It utilizes formal UML for communicating common understanding on domain and behavior inside the team, but features also are very familiar to stories for the “cool kids” and non-technical people.
    It allows better estimates, with the more rigid “milestones” model, to please the ( so boring ) bean counters’ mental models; and also report incremental progress to keep management off the developers’ backs.
    This would have the freshly-graduated-students armed with a better toolkit for working on both kind of organizations.

    But, unfortunately FDD seems to be the “ugly duckling” of methodologies, with very little bibliography ( isbn: 9780130115102 and 9780130676153 afaik ) and very limited, yet successful, adoption. Perhaps a new one with the “Sommerville brand” is what is missing for a broader audience….

    Reply
  • Pingback:Engineering Software Products – Systems, software and technology

Leave a Reply

Your email address will not be published. Required fields are marked *