From: Andrew Gabb (agabb@tpgi.com.au)
Date: Tue May 11 2004 - 12:03:18 EST
Oh what a gloomy picture you paint, Don, but so true. It shows why
these large projects need super-talented and experienced managers
and good processes to succeed. And good engineers of course. It also
shows why smaller developers tend to run into big trouble when they
take on a big project.
But again, I stress the need to get the up-front RE as good as you can. The problems that Don illustrates are real, but they'll be much worse if your requirements are bad at the start.
Andrew
Uksi, Don wrote:
> Having worked on a number of such large projects there are some
> difficulties with the concept of getting the up-front RE right.
>
> i. Such projects extend over years to decades, over which time
> the requirements will change. To use a combat system as an
> example, twenty years ago the threats were different, the
> platforms that it was intended for have completely been
> rethought, the way in which people perform computer mediated work
> has revolutionised, and the performance growth in compute power
> has changed our expectations of what the computer should do for
> us. This leads us into say Gilb's work on analysis by
> objectives, where the actual requirements are only fully detailed
> in a just in time method. [Annecdote: In the early 1990's a
> company "delivered" to the Swedish navy the trees for the masts
> that had been ordered nearly 100 years previous - the project
> merrily kept being funded and ran through to delivery even though
> the requirement had fundamentally changed only a few years after
> it had started.]
>
> ii. For a large system there will be many stakeholders, and
> stakeholders change over time and will never agree on specific
> ontologies or taxonomies. This leads us to polymorphic views on
> requirements, and then dealing with complexity in requirements
> trace, verification, and validation. When it gets to
> implementation meetings are often dominated by the lawyers, not
> the engineers.
>
> iii. The procurement and acquisitions processes are not
> RE-friendly, and the chances of influencing contractual
> provisions to simplify or ease the RE process is very unlikely.
> (e.g. on one system the RE's identified 16k of comments on one
> sub-system - which were largely abandoned by the contracts staff
> as they could not cope with this input).
>
> iv. Large projects will have many contractors, and complex
> interrelationships between these contractors (e.g. in one part of
> a contract Contractor A has the lead while Contractor B is a sub,
> while in another part of the contract this relationship is
> reversed). Whatever clauses you might have with your prime, and
> however hard you seek to tie these down, these are all
> re-interpreted (Chineese whispers) through these layers of
> sub-contracts. It then becomes an issue of who is accepting the
> risk - if you pass this all to your Prime they will hit you with
> a very large bill, while if you accept the risk you have an
> undetermined liability. This is why very large projects are
> often followed by a "get well" program which is actually the end
> customer risk liability cost being met.
>
> Regards Don Uksi ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Don Uksi
> Russell Offices R7-5-47 Ph: +61-2-626-57968 Fx: +61-2-626-53041
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon May 24 2004 - 09:00:19 EST