Those familiar with military aviation training methods and simulators will be aware of a fact which came to my attention just last week. During a meeting with a major UK supplier of military and civilian hardware and software, their representative reminded me that military pilots, once qualified, are most regularly trained in the tasks which they least regularly carry out.

While a pilot will be operating the undercarriage and trimming elevators or the rudder in every flight, he will hopefully never need to eject from the cockpit. However, should he ever need to, he absolutely must know how to go about it, the procedures that need to be carried out and the controls used to ensure his safe ejection from the cockpit and deployment of his parachute. To ensure that this is the case, he will regularly undergo cockpit ejection training in a simulator environment, but will rarely use a simulator to practise trimming procedures.

Whatever role we find ourselves in, most of us quickly internalize those activities which we regularly carry out. How does this relate to training software engineers?

During the last few years I’ve been disappointed to learn of the number of educational establishments which will teach many of the topics we’ve discussed only through a lecture format. Whilst I appreciate that projects are time-consuming to plan and run, my experience tells me that a student who is encouraged to use the techniques they learn in the context of a team project, will not only gain a better understanding of how a project is run and the project management techniques they’ve learned, but also will be more likely remember the likes of UML and SSADM.

Application of taught skills is, in my view, essential to the full learning and further development of those skills, and also gives the opportunity for students to experience them in something closer to a real world environment, rather than just in the sterility of the lecture hall.

Let’s call this ‘aspect-oriented teaching’ and consider how it might work…

In my first post of this series a few weeks back I mentioned the relevance of using conventional techniques such as SSADM to illustrate the concepts of abstraction and iteration. These are ideal illustrations of what I term software engineering aspects. Although these should not to be confused with the specific discipline of aspect-oriented programming (AOP), they are a concept not dissimilar to the crosscutting concerns of AOP.

The usual example of a crosscutting concern is logging – a technique often used to help trace method calls, particularly in distributed systems which may not be easily debugged. Entry and exit points to methods will often be logged with some textual information stored to some file or other storage mechanism. The difficulty is that in most programming languages in order to acheive this the engineer is forced to add appropriate logging method calls in each and every method of the system.

The idea of AOP is that these crosscutting concerns are transformed into single units called aspects which are implemented separately from the rest of the project, then combined into the final executable form using an aspect weaver. This enables a single, self-contained aspect to contribute to the implementation of many methods and classes without the original code having any knowledge of the aspect or its functionality.

So, dragging us back to the point of this post, I consider software engineering aspects to be a means of identifying common concepts across a range of SE disciplines, thereby allowing those disciplines to be better integrated in the curriculum. This means that in addition to the publication of a series of modules on the basics of programming, data structures, object-oriented analysis and design, UML, SSADM, architectures, project management, software testing and so on, one might consider publishing a matrix which shows how aspects such as abstraction and iteration apply to these topics.

An even braver approach might even re-arrange course content so that each semester was aspect-themed, with traditional modules run over a longer period of time in order to allow the student to be led through an exploration of an aspect in different disciplines. The semester is then effectively ‘framed’ by the aspect, providing a common meeting place for the varied topics, and a means of communicating to students the importance and relevance of identifying commonalities in a range of subjects. This exercise in itself might also help students in their own quest to generalise concepts in the systems they create.

I’m sure that this poses a number of questions to those involved in the day-to-day education of software engineers.

• Are examinations aspect-oriented or topic-oriented?
• If a topic is being spread over a longer period to allow all relevant aspect-related subjects to be covered, how can the topic be efficiently assessed?

Fair enough – post them and let’s discuss.

Is this really an attitude we should be passing on to future generations of computer scientists?

At the risk of sounding like a grumpy old man (before my time I hasten to add!), my belief is that we’re better off training software engineers than creating Java programmers (or .Net programmers for that matter). It’s a belief which I appreciate is grounded in my own educational and commercial experiences, but a set of generic engineering techniques is a far more valuable resource for developing a worthwhile career in IT. They enable the recipient to more quickly grasp a wider range of concepts, without having to carry out additional mappings from a particular language they’ve been taught.

I know that students will always want to know when they can build an application, and that is an important aspect of any degree course, particularly if it can be carried out in the context of some group engineering exercise. But if we bow to the pressure to teach just programming, or worse still just the development of glitzy websites, we run the risk of losing a generation or two’s worth of computer science. Perhaps students need to be persuaded a little more of the value of understanding the historical context of the topics they’re studying, and spend a little less time hacking something together.

I fear that technology imbalance is a problem which is also exacerbated by the activities of recruitment agencies. I guess it’s partly down to the way in which the IT job market is now driven, but many of the agencies I’ve worked with seem to place far too much emphasis on keyword searches for ‘Java‘, ‘C#‘, ‘C++‘ and so on. I suppose when the market is so busy, as it seems to be now, and when face-to-face meetings are reserved for the select few, there’s no time for them to assess the wider merits of an applicant. I find it’s often the experiences described in a CV’s prosaic paragraphs which better communicate the real skills of an individual rather than some claim to have 5 years experience of SQL Server. Perhaps this points to a need to do more direct recruitment…

It’s clear to me that the use of the Structured Systems Analysis and Design Method (SSADM) is still an important part of the software engineering educational curriculum in many countries. I discussed this briefly in a recent debate with the author of one of the leading textbooks on software engineering, which in the latest editions has dropped its chapters on such ‘traditional’ techniques. While it’s true that much of the commercial software world has moved onto ‘contemporary’ techniques, I believe there is still some educational value to be gained from understanding SSADM.

The key point is that many of the contemporary techniques are simply that: techniques. Many of the standards from the Object Management Group do not advocate a particular method of invoking techniques such as the Unified Modeling Language (UML), although of course a number of methodologies such as RUP and Select Perspective incorporate UML techniques in their delivery. Therefore students may be taught how to model a system using use cases, classes, state models and components, but the context for that modeling activity is often less clearly communicated to them. The application of SSADM in an educational environment can really help students to understand the value of the common concepts behind all these techniques.

In particular, the concepts of abstraction and iteration can be very effectively taught using SSADM tools. The several levels of dataflow diagram advocated by both SSADM and Yourdon approaches are an ideal way to communicate to students how a high-level abstract view, which is simple and quick to understand, can be of real value to those trying to comprehend a complex system. Of course this high-level view is then iteratively decomposed (the reverse of abstraction) gradually increasing the level of detail of each process, until sufficient information is identified about the system.

Of course, the all-to-familiar occurrence of technology favouritism plays a part in how software engineering is taught. In my next post, I’ll consider the pitfalls of allowing personal preference to influence curriculum content too greatly, and the importance of providing a balanced viewpoint.

The five key challenges I examined were:

• Keeping business processes and the solutions that support them closely aligned
• Maintaining investment in intellectual property within, or accessible to, the organization
• Understanding the hand-over points between client and supplier organizations
• Preserving interoperability of long-lived IT system assets
• Minimizing client risk through adherence to standards for development practices

Of course, these challenges are in addition to the risks that are associated with the management of outsourced activities themselves.

In times where standards-based process improvement is de rigueur, seen in the continued push towards CMMI levels 4 & 5, it seems strange to me that so often these activities don’t include the use of standards-based analysis & design methods. Even stranger is that the software assets which are being developed offshore are so rarely subject to formal asset management techniques which can help to not only control the assets, but also to widen their use within a component- or service-based approach.

It’s a topic which has had much coverage in the last year, following the publication of a research paper on BPMN usage by Michael zur Muehlen and Jan Recker. The paper analysed over 120 examples of BPMN diagrams from a number of sources, to identify the most commonly used BPMN elements, and its findings certainly back-up the experiences of our consultants with a range of users of Select Architect. Further blogged debate by Bruce Silver and Sandy Kemsley, appears to have reached a broad consensus.

Because Select Architect supports an older, simpler notation for workflow modelling, the Process Thread Diagram, in addition to BPMN, we’re often asked which should be used. In general we find that the two notations are used by different groups of user, broadly similar to the groups identified in the paper by zur Muehlen and Recker.

Those who are interested in modeling business processes in order to understand organizational boundaries and responsibilities, or as part of a process improvement exercise, seem to prefer a simpler notation, which they often perceive cannot be achieved with BPMN. They see the multitude of options available on BPMN events (a start event has six trigger types – including undefined, intermediate has nine, end has eight result types) and on tasks themselves (nine task types in Select Architect) and decide, instead, to use the process thread notation which is not universally standardised.

BPMN event trigger and result types

The other group of business process modelers are the analysts who want to precisely model the conditions of the workflow, for whom the range of gateway and event types is essential.

You could say that Select has been implicit in propagating this split in BPM notations; the pragmatic reality is, however, that while we have customers who want to use the process thread diagram rather than BPMN diagram, it would be unwise to force adoption of BPMN.

Rather, I would like to see all of us involved with business process modeling promoting BPMN as a technique which may be adopted by both groups, using the level of detail required for their purposes.

Let modeling with BPMN be seen as an iterative process. Why shouldn’t the process analysts use a validated subset of BPMN to construct ’simpler’ diagrams where the events can be simply start, intermediate and end events. They have no need to worry about the detailed trigger types, and should not feel pressured to do so. Similarly for simple decision points, they need not even use gateways, let alone worry about the gateway type or detail, instead using conditional flows. If the project requires more detailed modeling, those details can be applied as the processes are further analysed and decomposed.

Perhaps we, and other BPMN vendors, should consider BPMN profiles, based on the role of the user, which provide cut-down toolbars of elements and property details?

Identifying the business motivation behind a project is perhaps even more vital at this time of economic restraint than previously was the case. For decades we’ve striven to raise the bar when it comes to matching the system to the business needs, and when funds are tight we need to work harder to ensure that what we deliver in software will enable our client or employer to pay our wages at the end of the month.

‘Why?’ is perhaps a question which has been insufficiently asked. An interesting thread on the International Institute of Business Analysts blog, provides viewpoints from a range of contributors, and some great graphics highlighting the importance of that question which seems to come so regularly from the lips of toddlers, but which so often we fail to ask once we think we’ve learnt everything and reached the heady wisdom of adulthood.

Claudio Bartolini points out the importance of being able to clearly identify the link between IT systems and the strategic impact they may have. We can model the What and How and When and Where and Who for all we like in our business process or UML models, but without understanding the Why of the major aspects of those systems, and, one might argue, even the detail of those systems, we run the risk of developing systems for the sake of developing systems alone. And surely we won’t be allowed to do that more than once, or maybe twice…

One such example is an independent consultant who also happens to be a motivational coach. Working on a BPM project for a UK-based automative company, he was keen to explore a variety of different notations for business process modeling, but on hearing of BMM was interested to learn more. He has quickly identified the benefit of modeling Ends and Means, and reduced the difference between goal and objective to simply this:

Is it an enduring goal or a targetted objective?

Another group of business analysts at a UK retailer find themselves regularly questioning why certain business processes are required, and equally regularly fail to get a meaningful motivation from their sponsors. They hope to be able to extract this motivation from the business more easily now that they have a model which can link the processes they identify with business strategy, even if they have to come up with the implied strategy themselves in the first instance.

It will be intriguing to see the level of uptake of the business motivation model in the coming months, and whether it will provide that missing link between business sponsor and systems development that so many previous modeling techniques have aimed to create.