Process Re-Engineering for Software Development

“Re-engineering the software development process – how ridiculous! There are no end of perfectly good development methods and tools out there to do the job. Who needs another?”

Yes, we can see where you are coming from, and in your context, we agree. But CREATIV isn’t a run of the mill software development toolkit. It has re-engineered the development cycle.

And you’ve heard that before, haven’t you? Wonder tools you’ve had enough of, but stick with me here…

Consider this scenario to set the scene.

Software is usually developed from a specification, and the tools used to develop may be sophisticated integrated development environments (IDE) or they may be a simple language compiler. The IDE has reached a level of sophistication that provides a host of assistance tools, debugging tools, tracing tools and so on. The developer is able to build and debug very efficiently. The IDE incorporates a compiler, which checks the source code for syntactic errors and then generates object code to run on the target machine.

OK so far? This is all standard stuff. Any new IT graduate would recognise this situation and, given the correct language, would be productive in a matter of hours. Now, there are a few problems with this scenario, namely:

  • The developer incorporates bugs into the source code. Some are detectable by the compiler and some are not.
  • Bugs that are not detected by the compiler will remain in the code until detected either by testing or during the live running of the system.
  • No one knows the effect of each bug in advance, thus the only way of detection is by noting a malfunction in the running system.
  • But the system never exactly matches the original business requirement, so an apparent malfunction may be the result of a requirement not delivered or differently interpreted.
  • All this post-coding work costs time, money and may cost the business itself dearly depending upon the exact effect of the bug.

Still with me? Again, this is all known and accepted. Not wanted or liked, but accepted, because there is apparently no other route to software development. Much time and money is spent testing software systems in an attempt to find all the bugs. But no one can prove that a system has no more bugs. It’s not possible.
So what’s new here? So far, nothing. This is just the status quo.

Now consider some of the relevant properties of the average specification:

  • A specification is written, usually in English, and may use a set of diagrams and other devices to express some of the features of the system being specified.
  • Such a document is usually of a considerable size and complexity for all but a trivial system.
  • The team creating the specification is unlikely to understand fully what is embodies in the specification or to what degree ambiguity exists or how it affects the perceived operation of the system.
  • The business user who wants the system will read the specification and have a different understanding of the system operation from that intended by the specification team.
  • The business user may well not be able to understand a proportion of the specification because of lack of knowledge of the language, diagrams or other devices in the document.
  • There is no way that the specification as written [ambiguously] can be compared with what the business user actually wanted in a clear and concise way.

We have reached the part where traditionally the blame starts being spread around! The costs are escalating. The system is late. It has an unknown number of bugs hiding in it and no idea of what their effect may be on the business. Maintenance is looking like a nightmare in the making…

Now here’s the interesting bit.

What PDT have done to develop the CREATIV toolkit is to dismantle the existing software development cycle and re-erect it in a different form. The people at PDT took the view that if a language compiler could check source code in that language for syntactic errors and then generate object code using a code generator, why not apply that thinking to the specification itself?

What can this CREATIV do for this situation, then? Well, to be honest, for this current problem, not a lot. But things can be different for the next development.

Consider this:

The system specification is developed in the CREATIV toolkit using a simple textual format and a single overview diagram, both of which are easily understood by both the developer and the business user. At any time, the specification may be compiled – yes, compiled – in the same way that a source language is compiled, and syntactic errors in the specification identified. Once any errors have been corrected, the internally consistent specification may be used in a number of ways. Firstly, test data may be used to perform a User Acceptance Test on the specification. Secondly, properties of the required system may be expressed by the business user and the specification may be proved to exhibit the properties; more about these two a little later. And thirdly, a code generator may be used to generate source code in a choice of languages that exactly implements the specification.

Sorry. Are you telling me that you can go straight from specification to code without having to hand code at all?

Well – yes actually! We use rule-based code generation, exactly like a compiler.

PDT have re-engineered the software development cycle by cutting out the implementation stage. And a lot of the testing as well. Oh, and maintenance is a lot easier too, as there are no bugs to fix, just changes to the specification to comply with changes in the business requirement. And it all costs a lot less than the traditional process.

Not to mention collapsing the time scales considerably. Take the time to deliver the system from sign off of the specification. Using the traditional process – months or even years; using CREATIV – minutes or even hours. Yes, the specification takes longer to complete, because all the decisions that are avoided or fudged or just not perceived have to be resolved before the specification will compile and meet the business user’s expectations. Now that’s process re-engineering taken to a new level. CREATIV can deliver this.

 Recent News
Good things come in threes
Printer trade in bonanza
PDT News: Winter 2007
1st class Zebra Maintenance
PDT News: Autumn 2005
PDT News: Spring 2005
PDT News: New Year 2005
Education: asset tracking
PDT's 20th Anniversary
Conference Speaker
SCS Presentation
PDT launch label bureau
PDT joins Symbol Select
PDT/Psion partnership
PDT joins e-center
Venture with Autotrakker
Jon Critoph joins PDT
 Recent Content
Process Re-Engineering
Getting a new IT system
What does this mean?
Buy it or build it : Part 1
Buy it or build it : Part 2
Let a child drive your Ferrari?
Complaints Management
Is this the End of Barcodes
Barcodes on the move
The best from your company
Info at the point of activity
See your business
Money in the stock room?
To Consult or not Consult
Barcodes for Success
We Need to Cut Costs!
Simply the best
Barcodes Explained
The Specification Debate
The PDT Maze Analogy
A New Perspective


Bookmark
this page


Send this page
to a friend


Copyright (c) 2006 Precision Design Technology Ltd. and its licensors. All rights reserved.