MCSEs...

Arse covering 101

--
Catman MIB#14 SKoGA#6 TEAR#4 BOTAFOF#38 Apostle#21 COSOC#3
Tyger, Tyger Burning Bright (Remove rust to reply)
116 Giulietta 3.0l Sprint 1.7 GTV TS GT 3.2 V6
Triumph Sprint ST 1050: It's blue, see.
www.cuore-sportivo.co.uk

 

My view is that as producing it can be up to 75% of my day job, it's a
necessary evil. I then accept the fact that at least another 20% of
the job is going to be me telling people what's already written down,
so those notes are really there to remind me what I decided at the
time.

 

I don't mind knocking out documentation. It's mostly a copy'n'paste job
anyway and compared to the implementation itself, which is usually at
something like stupid o'clock on a Sunday, it's pretty flexible work.

Not to mention that a 92 page system specification helps maintains the
impression that I do something vaguely difficult for a living.

 

Quite. There are three main reasons I churn out documentation. One is so
I can read it and be reminded what I was supposed to be building when
the time comes to build it. Another is so I can pass the documentation
on to someone else to do the building so I can kick back and play
Scrabulous instead. The third is so when we hand it over and it's not
what the customer wanted, at least I can point to the design docs they
signed off before they pay for any remedial work.

 

In case three, perhaps you should have done a better job at the
Information Requirements Analysis stage? "They don't know what they
want", you reply. Shouldn't a proper analysis help them to discover
that?



--
+-------------------------------------------------------------------+
| Pete Fisher at Home: |
| Voxan Roadster Yamaha WR250Z/Supermoto "Old Gimmer's Hillclimber" |
| Gilera GFR * 2 Moto Morini 2C/375 Morini 350 "Forgotten Error" |
+-------------------------------------------------------------------+

 

What's the weather like up on that ivory tower of yours?

 

"On a clear day..."

The advantages of being a hybrid manager/analyst/programmer. We have a
system I first developed ten years ago, still going strong and
fulfilling the original user requirements[1]. It helped a great deal
that I sat literally at the desk next to the manager who needed the
system. It also helped that, at the very earliest stage, we got the call
centre staff who were actually going to have to use it involved.

[1] These have recently expanded as a result of a change in policy and
funding for the service. It could be redesigned relatively easily, but
bowing to the inevitable have recognised that will now have to be done
by our out-sourcers using a Siebel module. I await the outcome with
interest, though I suspect I will be drawing my old age pension before
they deliver a flawed system.

--
+-------------------------------------------------------------------+
| Pete Fisher at Home: |
| Voxan Roadster Yamaha WR250Z/Supermoto "Old Gimmer's Hillclimber" |
| Gilera GFR * 2 Moto Morini 2C/375 Morini 350 "Forgotten Error" |
+-------------------------------------------------------------------+

 

*ding*

 

<googles>

I see.
It was SSM, RAD and proto-typing when I did my formal 'training'. Same
roots really.

I found the Requirements Analysis module one of the most interesting. It
helped that the lecturer was not averse to me using esoteric quotes in
assignment reports.

--
+-------------------------------------------------------------------+
| Pete Fisher at Home: |
| Voxan Roadster Yamaha WR250Z/Supermoto "Old Gimmer's Hillclimber" |
| Gilera GFR * 2 Moto Morini 2C/375 Morini 350 "Forgotten Error" |
+-------------------------------------------------------------------+

 

heh.

The result of my site visit this morning was being asked to draw up a
task list for all the relevant parties and a proposed solution.

This would be the same task list and proposed solution they've been
given 3 times already over the past 4 weeks...

It's only got to be delivered next Friday.

 

Obviously they're having problems reading it... erm... change the
font.

 

took a blunt brush and painted...

"Agile" is just a cop out for bad Requirements Analysis.

"Ooops, sorry, we cocked up, but we can change tack and fix the design flaw
easily, and show you that's what we're doing!"

 

took a blunt brush and painted...

We introduced Agile into a project that is 3/4 of the way though its
development cycle so couldn't get the "early feedback".

It has come in handy to stop the management messing around with schedules
(they can see very easily what else they'll delay), and the customers can see
approximately when the new features they want can be delivered, and also it
allows the customers to shuffle future features implementation dates around.

 

Rubbish. What if you're requirements analysis is perfect, exactly as
the customer has requested it, and spot on given your examination of
existing systems.

And you get to the end of implementation and they say, "but that
wasn't what we _meant_ when we asked for x"?

Agile allows you to spot that and act on it a hell of a lot earlier
that good old waterfall.

 

Ace wrote in uk.rec.motorcycles:

Not quite. I have come across many requirements specs that are simply
incomplete because of *assumptions* that the author makes but doesn't
state. "Obviously there should be a means of backing up the database
without an interruption to the service; I shouldn't have to state it".

Heh.

 

Pete Fisher wrote in uk.rec.motorcycles:

Or even pass it...

 

Heh. "No such thing as exhaustive testing..."

--
+-------------------------------------------------------------------+
| Pete Fisher at Home: |
| Voxan Roadster Yamaha WR250Z/Supermoto "Old Gimmer's Hillclimber" |
| Gilera GFR * 2 Moto Morini 2C/375 Morini 350 "Forgotten Error" |
+-------------------------------------------------------------------+

 

Well I'd call that a poorly, i.e. not at all, communicated
requirement. But your point is valid - assumptions like this are all
too common.

 

As you can tell from my other post, I was being facetious.

A troll it was not.

 

Yes. I. Know.