Sign in / up

back to article Analysis, design, and never the twain shall meet

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 …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Ian

    A little rum...

    It seems a little rum to complain about 'Agilists' and then promote ideas recommended by arch-agilist Scott Ambler in his book:The Object Primer : Agile Model Driven Development..., where he recommends robustness diagrams and detailed use cases; and from what I've read Ivar Jacobson is now an 'Agilist'. Agile shouldn't be an excuse not to properly gather requirements, but rather provide tools for dealing with changing/evolving requirements.

    0 0
  2. Brett Weaver

    Maybe you are correcting the wrong paradigm

    I have a problem with this article on a fairly fundamental level. The model you suggest is the same old tired "The developer shouldn't deal with the users" approach.

    If you don't have developers that can deal with users and perform well as Systems Analysts (To use an old, but accurate term) then you shouldn't be doing the project.

    Having BA's or Project Managers making any type of technical assesment or decision is a sure recipe for disaster.

    The developers themselves should be completing the detailed Use Cases alongside appropriately selected users.

    Agile methods can be used or not, depending on preference, but final requirements gathering and detailed design belong to people that understand both the business impact and the technical impact of design decisions.

    The more layers between the developers and the day to day business users, the more a project is doomed to fail.

    0 0
This topic is closed for new posts.