Feeds

Analysis, design, and never the twain shall meet

Jumping the chasm

Internet Security Threat Report 2014

We bring you a new Reg Developer author, a specialist in crossing the chasm between analysis and design

Not many people know how to get from analysis to design. Software agilists “solve” the problem by blurring the distinction between the two. There has to be a better way...

It’s a familiar scenario to many. Deep in the basement where coders dwell, Hero Programmer #1138 stops at an apparent impasse and thinks: “Oh hang on, we didn’t agree on what happens if the user cancels at this point. In fact, we didn’t even talk about it. Well, I’ll just roll back the whole transaction and pop up a warning dialog taunting the user. But we also didn’t talk about transactions for this part of the system, so they’re not factored into the design. Well, here goes, let’s start coding!”

The programmer, bless his cotton socks, makes project-shaking decisions then and there, without a customer or analyst in sight, to retro-design new functionality into the system. Programmers are great for making technical decisions, but they’re not the right people to be defining and signing-off on new requirements. Yet this scenario happens, a lot. It’s the way in which many projects wobble and stumble towards eventual completion. Then the bug hunt begins.

The project’s development process (if there is a defined process at all) must have some serious shortcomings if great swathes of functionality can be missed. In the agile world, where flexibility is sometimes taken to extremes, these shortcomings are addressed by putting safety nets in place: have an on-site customer (or team of analysts) to be at the programmers’ beck and call . Incidentally, this arrangement was partly why the infamous Chrysler “C3” project failed, because such available paragons seldom represent the real paying users well. And rethinking the design as new functions are added is dressed up as “evolutionary design”, with safety nets such as copious unit tests and pair programming.

Evolutionary design does have its place: but using it as a “process hack” to catch forgotten requirements just isn’t it. It’s much better to explore the requirements in-depth first, looking at all the “rainy day scenarios”, i.e. things that can go wrong, or events where the end-user steps off the trail and does unexpected things. It’s not as difficult, or as time-consuming, as it sounds to get it right: but software agilists wouldn’t sell nearly as many books, or get to speak in public as often, if they admitted this.

The reason why software agility appears to be such a saviour is that it skirts around the need to get from requirements to source code, by blurring the distinction between them. But – and here’s the thing – getting from requirements to working, maintainable source code really isn’t that difficult, if you do it right. And if you get it right, then you don’t need those process hacks. I’ll have a go at explaining how to do this in this article.

If it isn’t too disingenuous to plug my own book, the process that I describe here is illustrated in more detail, with oodles of examples and exercises, in Use Case Driven Object Modeling with UML: Theory and Practice (co-written with Doug Rosenberg, and published later this month). The process is adapted and refined from Ivar Jacobson’s approach to OO analysis and design (with use cases, robustness diagrams and sequence diagrams).

Intelligent flash storage arrays

More from The Register

next story
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
NSA SOURCE CODE LEAK: Information slurp tools to appear online
Now you can run your own intelligence agency
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Microsoft adds video offering to Office 365. Oh NOES, you'll need Adobe Flash
Lovely presentations... but not on your Flash-hating mobe
You stupid BRICK! PCs running Avast AV can't handle Windows fixes
Fix issued, fingers pointed, forums in flames
HTML5 vs native: Harry Coder and the mudblood mobile app princes
Developers just want their ideas to generate money
prev story

Whitepapers

Designing and building an open ITOA architecture
Learn about a new IT data taxonomy defined by the four data sources of IT visibility: wire, machine, agent, and synthetic data sets.
5 critical considerations for enterprise cloud backup
Key considerations when evaluating cloud backup solutions to ensure adequate protection security and availability of enterprise data.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Business security measures using SSL
Examines the major types of threats to information security that businesses face today and the techniques for mitigating those threats.