Register  |  Login

 

At the software developers conference in Sydney in 2007 we received the comment that this method is “agile specification followed by incremental development”. That’s exactly how it is intended.

Design reduces cost

Since most applications can be conceived on the drawing board, the SmartMethod has an upfront focussed design and plan approach, to minimise wasting capital expenditure. This approach is similar to what is used in any engineering project – design and specification is cheaper than just starting to build and muddle your way through. Of course you can build a dog house without planning, but a house, or a Hotel complex? The same applies to building software, a small web-site needs little to no planning, but build a million dollar system and you better do quite a bit of planning (to see it won’t be 1.5 or 2 million).

Traditional IT documentation increases cost

Remember the functional specs of 300+ pages? Unworkable, never right, impossible to change, and how to test?!  Seen those UseCases expand to 20-30 pages?  “Words, words, words” – ever seen an architect using words rather than their drawings?  Too many words stall progress and as the project direction changes (inevitable in projects) it’s too time consuming to change the words.

 

This gave rise to the Agile community who ditched “the many words”, in favour of “just start building” in order to show stakeholders what they were going to get. Good stuff, the only problem is, the more code you write the harder it is to change… And with no documentation how does a new person on the block get overview and insight in the system’s purpose and intent, or how it hangs together? If it is a few thousand lines, no problem, but if it is a few 100,000 lines?

The best of both worlds: agile specification

The SmartMethod implements agile design through much improved higher level UseCases, and by providing UI and report Interface specification artefacts. In addition there are excellent guides for each to keep the information content lean (and thus maintainable). The SmartMethod focus is on “pair-white boarding” and capturing snapshots of what’s drawn on the board and include it in the documentation. This is much faster than pair-programming, much easier to change, and much better than trying to imagine it from a UseCase or creating a wordy document.

 

Thus, with the right artefacts and guidance to avoid bloating, before long you have a small set of 3-10, may 15 page artefacts that can be validated with each other and the WBS. A bit like this:

 

Here is an example of SmartMethod’s agility

The SmartLibrary is designed and specified using the SmartMethod. It took 4 increments over a period of 3 months in collaboration with the vendor’s software designer, to reach a stable spec-set totalling 97 pages. All screen navigation and form information content were sketched and validated in workshops. There were some 35 UseCases identified, but only 3 were deemed necessary to expand and describe (who says you must do them all?!). The design of the data-model was a bit undercooked (lesson: always have a full data model), so it should have been about 120 pages. That’s 120 pages for a 709 function point system (indeed, we function-point counted it). If built in DotNet or Java/J2EE, 709 function points equates to about 700 person days of effort. That’s a system of roughly $700-800K.

 

Best of all after the first iteration (start of the project) of 4 weeks duration (14 person day effort) we could do a rough function point count on the basis of the UseCase list, and knew if it would fit the budget. Thus the SmartMethod absolutely minimized cost exposure - if the costs hadn’t stacked up, we could have killed the project right there and then; and it would have been “Opex” only, so fully tax-deductable in the current financial year.

 

Because we only have 120 pages, mostly code changes don’t affect the design specs, and only the comprehensive requirements list needs updating. But anyone new on the team can get an immediate insight into the vision and structure, and can know where to start in the code bucket.

The case when you do need to start with some coding

Of course there are situations where you need to build proof-of-concepts, for example when it is hard to imagine the user interface and usability factors / usage efficiency. This is exactly the approach we applied for creating the SmartLibrary copy protection concept, and our ScopeTracker requirements management tool. When to apply which approach is of course provided in the SmartMethod.

 

So be agile, i.e. flexible/nimble; if it warrants to code to show it can work, do so; But mostly we can design, specify and plan in an agile way.

 

Think, plan, build incrementally – is cheaper that just starting to build

 

 mail to colleague

 

Rate:
Your Rating: 0.0   Average Rating: 0   Ratings: 0
Site Software v2.2.0, 26 Oct 2016