uSDLC and Software Design – an example

A practical starting point is authorisation and authentication – as most systems rely on knowledge of the operator.

The same technique of divide and conquer works inside the page. First I create a bullet point list from what I have learnt that I will need:

• Development Users
• Authentication and Authorisation Method
• Authorisation Check
• Authorise Administrator
• Authorise Operator
• Test Instrumentation
• Auditing

uSDLC allows me to split a list into separate sections with the text as the heading and linked to an instrument block. It is a good idea to edit each section and document the reason for the section. Instrumentation, like code, tells us how but rarely why. For example:

Auditing

The audit log includes logging in and all page views, successful or unsuccessful.

Now to filling in the instrumentation block. These are a list of simple statements that fully define the section while remaining readable to domain specialists as well as the computer:

set audit log checkpoint
login oper
check audit log oper 'log in'
browse '/oper'
check audit log oper 'view /oper'
browse '/admin'
check audit log oper 'FAILED: view /admin'
logout oper
check audit log oper 'log out'

Train your domain specialists to not ignore instrumentation as ‘code’. If they can’t understand it, then it is still not good enough. What they sign off on here is what will work in production. It will grow – either in the instrumentation block or as new sections or pages – as more information becomes available. With luck this will happen with the domain specialist reviews, but it may happen later when testing working system pages. Get each change signed off so expectations meet actuality.

Next blog I will discuss activating the instrumentation.

uSDLC and Software Design – Finer Detail

Iterative divide-and-conquer will eventually leave the designer with pages defining single, possibly indivisible, pieces of functionality. It doesn’t matter if the subject is a user interface, business functionality or anything else – the approach is similar.

I will often use a bullet point list to outline the functionality provided. Once I am happy that I have covered all aspects, I use a uSDLC command to split the list into separate sections. The list becomes the title pointing to an instrumentation addendum.

Add only a small amount of text to each section. Just say enough to explain the functionality, just as if you were discussing it with the project visionary or business analyst. Most of the description, detail and restrictions are in the instrumentation section – information that is readable to both the business representatives and the computer.

An example may make it clearer. The first page we are likely to tackle on a web-based system would be for authorisation and authentication. On that page, the first section is likely to describe each type of user the system will cater for. On a large system, this would be a page in its own right.

Development Users

For development to go ahead we need a set of users – for both manual and automatic testing. The groups are the same as for production use. A user in the test group can do special actions, but cannot, by design, change production data.

create group 'administrator'
create group 'operator'
create group 'test' create user admin, groups: 'test', 'administrator', 'operator'
create user oper, groups: 'test', 'operator'
create user test, groups: 'test', 'administrator', 'operator'

As you can see above, the prose is to help the reader understand what we are trying to do. The instrumentation is human readable. It not only clearly defines the system, but understood by anyone with domain knowledge. A business owner may look at it and note that we need an operations manager.

Once the interested parties give iterative feedback, have them sign – in blood preferably. The instrumentation will drive the newly created system. It should describe functionality, restrictions and edge cases where they are known. Whatever it says, the system will do – feedback is king. When the customer comes back later and complains that the system doesn’t do Y, it is easy to prove whether Y was ever accounted for – and if it was it works or the instrumentation will fail.

The next article will extend the above example, while the one after that will discuss how to turn instrumentation into something your application will understand.

uSDLC and Software Design – The Framework

I have talked about the rules of three (http://en.wikipedia.org/wiki/Rule_of_three) before. For my last few projects I have used it as a template when starting the design. It is more of a guide than a rule…

1. The vision
   1. Vision details
   2. Clarifications
   3. Correspondence
2. The design
   1. User interface
   2. Business logic
   3. Interface tier
3. Environments
   1. Hardware
   2. Frameworks
   3. Libraries

One of the outstanding tasks for uSDLC is to able to create a project with a choice of template – one of which will be this one.

uSDLC and Software Design

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.