From: Majordomo (owner-re-online@it.uts.edu.au)
Date: Thu Jun 03 2004 - 11:56:32 EST
[66.163.170.83])
by filter.it.uts.edu.au (Postfix) with SMTP id 279A31D6370 for <re-online@it.uts.edu.au>; Wed, 2 Jun 2004 22:11:54 +1000 (EST)Received: from unknown (HELO dualpro)
by smtp813.mail.sc5.yahoo.com with SMTP; 2 Jun 2004 12:11:38 -0000
Message-ID: <002b01c4489b$450961b0$8596e504@dualpro>
From: "David Lightstone" <david.lightstone@prodigy.net>
To: <re-online@it.uts.edu.au>
References: <000801c445c6$25983630$fe00a8c0@goud>
<40B98ED9.4090806@tpgi.com.au> <004401c44700$03895340$f796e504@dualpro>
<40BBCA9D.7090805@tpgi.com.au>
Subject: Re: [re-online] request for suggestions for a Masters Thesis -
Sweden
Date: Wed, 2 Jun 2004 08:15:16 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Status: No, hits=0.7 tagged_above=0.0 required=6.3 tests=RISK_FREE X-Spam-Level:
> David Lightstone wrote:
> > This is closest to the opinion that I hold. There is always uncertainty
in
> > need of resolution. The uncertainty is attributable to the a priori
need
for
> > knowledge that can only be obtained a posteriori to the completion
of an
> > implementation task. At best one structures the implementation
effort so
as
> > to provide that knowledge when it is needed (ie delay decisions until
you
> > are sufficiently informed). It is an accross the board type situation.
It
> > affects requirements, design and implementation efforts.
>
> Well said.
>
> Your example about 'delaying decisions' is actually one of the not
> so subtle factors working against RE that you mentioned, ie the
> impression that RE takes too much time - when we could be doing
> *real* work - and "we can't afford to wait forever".
I agree this phenomena is present to a very!!!! large degree.
I was thinking more so about simple things like establishing a current draw budget for an application before one actually knows the current draw of each of the individual components. Or as was reciently discovered by my current employer - what we thought was the minimal power mode of a particular microprocessor was not actually the minimal power mode (ie what we thought we were doing, and what we actually were doing were just different things). Having used a MPU manufacturer provided number (theoretical calculation) we just couldn't figure out how we were drawing so much current. In the particular situation someone started integration testing without a rigerous unit test
You could also interprete the situation as - a valid feasibility study was not performed for purposes of verifying the manufacturer's current draw number. The term feasibility is appropriate as the MPU was a bit custom (variation on a widely used MPU) and the code needed to place the mpu in and out of minimal power mode needed to be developed (by virtue of the variation). Plain and simply we got it wrong
The general characteristic about which I express concern is the coupling of 2 (or more) problems each of which must be separately solved before there is adequate knowledge to make an informed decision. This a posteriori knowledge just can't be known a priori, yet the risk associated with it is not necessarily managed properly.
The task of concern is learning enough about the requirements so as to partition a problem into quasi independent sub-problems each of which serves to more properly clarify the requirements of the problem. One either waits for the solution to present itself or implements risk management strategies. The obvious risk management strategies entail establishing contingent requirements (ie temporarily assume requirements to be needed and be prepared to drop them at any time). It is amusing to observe that firms often neglect to consider establishing a contingency plan (ie in addition to establishing contingent requirements, they assume that the contingent requirements are valid and feasible).
>
> One way we offset/minimise these delays is to include risk reduction
> activities in our planning to ensure that the information *is* ready
> when we need it.
>
> When it comes down to the wire, I think the single most important
> factor in bad RE is bad risk management. As the old saying goes,
> "Anyone who can get this far into the swamp and not see any
> alligators deserves to get eaten."
I definitely like that saying - it most certainly would be applicable in the particular situation described above (but for the grace of a really sharp microprocessor designer who lost his memorial day weekend) as our customer is somewhat eager to take delivery
> So those who ignore or undermine RE:
>
> # See little or no risk in avoiding the RE activities, and/or
> # See some risk, but trade it off against time pressure, and/or
> # Don't even think about risk, let alone plan for risk (very common
> unfortunately).
>
> For the same reasons, these folks often ignore other fundamentals of
> systems engineering, including interface management, integration
> planning, test planning, life cycle considerations, performance
> modelling, etc., etc.
>
> Andrew
> --
> Andrew Gabb
> email: agabb@tpgi.com.au Adelaide, South Australia
> phone: +61 8 8342-1021, fax: +61 8 8269-3280
> -----
>
-- ------------------------------------------------------------------------ Associate Professor Didar Zowghi Director of Requirements Engineering Research Group Department of Software Engineering Email: didar@it.uts.edu.au Faculty of Information Technology Phone: +61 (02) 9514 1860 University of Technology, Sydney Fax: +61 (02) 9514 4535 P O Box 123, Broadway, NSW 2007 www-staff.it.uts.edu.au/~didar Australia CRICOS Provider Code - 00099F ------------------------------------------------------------------------ ------------------------------------------------------------------------------- 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 Jun 07 2004 - 09:00:19 EST