First page Back Continue Last page Graphics

Meanwhile something new


Notes:

While I was doing this the rest of the my original team were working on their client project. As a result of the development process discussions we'd had previously – and informal discussions we had during this time - they introduced some innovations:

They performed a risk assessment and followed it through with plans to manage the most serious of them. (They didn't update the risk assessment.)

Rather than producing a large document detailing the appearance of each screen within the system they produced a "requirements overview" identifying the responsibilities of the system and the aspects of the clients organisation (computer systems and various categories of users) that it interacted with. The result of this was that they achieved something that, I'm told, didn't usually happen until much later in the development process (if at all) – the client signed it off.

The sizing exercise was based on a version "function point analysis" (counting use cases and entities). I've worked on systems where this doesn't work (because the complexity is algorithmic) but it suited the problem domain. Despite relying on guesses of productivity levels these estimates proved uncannily accurate.

The detailed specification was followed through by identifying the inputs, outputs and actions of various functions (using word tables to illustrate the content of a screen) – they avoided the "screen shot" style specifications I was encountering. (The trouble with the latter is that commits to a particular screen design too early in the process – even moving a button needs to be approved by the customer.)

(Much of this was possible because the project manager was one of the disciples.)

I rejoined the team just as the project was about to move from high level design (identifying packages) to development (designing the packages and classes, implementing the classes, etc).