When the dust settles and I look at all the jobs I have done is the SDLC, I still consider myself primarily a software designer. It is the support that uSDLC provides for software design that is, for me, the most exciting aspect.
I have a problem – and it is one I have not been able to see my way through. It is around communication. I can send a uSDLC driven design page to interested parties (vision holder, owner, architect, BA, etc) and they will file it with the other artifacts. If they ar diligent they may read it and send me comments. But they don’t get it. I can sit down with them for 5 minutes and the light will go on.
A uSDLC document is a living part of the application – through all the development cycles and into production. A sign-off on a uSDLC design document is a sign-off on what will reach production. Any less will automatically raise issues – any more is an unjustified expense.
I am not too worried about projects using uSDLC. The benefits become obvious to all quickly – and the automated task system will make sure that everyone is kept informed of when they need to give advice.
My problem is in how to tell people who don’t use uSDLC why it would help them in their projects. Any explanation I come up with is too complex and the benefits, while huge, are unclear to the uninitiated.
In my next article or two I will walk through a design process using uSDLC. Perhaps with your help I can find a way of simplifying describing the benefits.