Add an "assumptions" element

[bknoth2]

It would be nice to have an assumptions element, used to track project assumptions.

[«Midnight»]

Bruce,

You could likely do this via something like a stereotyped Issue element. Perhaps you could do this through a profile.

[On that latter thought, I keep thinking that EA does not allow you to use things like the Issue element as base metaclasses. If so, perhaps that would be the basis for a future suggestion. I'm not in a position to check this just now.]

David

[bknoth2]

I am using a stereotyped issues class. It's a bit awkward, but works. Assumptions are such an important part of a project (at least around here) that I think they warrant their own element.

Thanks for the quick response.

- Bruce

[«Midnight»]

Bruce,

Yes, I can certainly see your point.

At the risk of oversimplifying things, ssumptions appear quite often at the beginning of the life cycle of things (projects, systems, whatever). Issues tend to appear in later phases. They are certainly different.

As mentioned above, assumptions also show up in several domains. Multiple domains may be applicable in any given (EA) project.

Thus, add my vote!

David

[sargasso]

Strange as it may seem   I'm going to disagree here.

Assumptions are issues, they need to be managed, owned, monitored and actioned through a project until they are resolved.  There may be assumptions that live on through a dev/deployment project. However, after deployment they are no longer assumptions they are L.A.W. constraints of the solution.

Code: [Select]

ASSUMPTION001: The maximum number of concurrent online users will be three.

Maintenance of the truth of this throughout the project could well be the responsibility of the "Assumption Management Committee"  but strangely enough I've never seen one of these committees convened.  

Keeping it in the issues log, though, and getting it raised at each and every PMC meeting tends to get its truth verified fairly quickly in my experience (and then the designers can get on with a design based in truth rather than assumed constraints).

ymmv  

bruce

p.s. Oops, I forgot...
Minutes of PMC meeting #4

Code: [Select]

ASSUMPTION001: The maximum number of concurrent online users will be three, except when its 300.

[Paolo F Cantoni]

Strange as it may seem   I'm going to disagree here.

Hi bruce,

It's not clear to me what you're disagreeing with...  

Now to be clear, I agree with the content of your post.  But, I'm comfortable with using a stereotyped issue to distinguish an assumption (issue) from a non-assumption issue.  If an assumption imposes (generates) a constraint then, as you say, once deployed the constraint is what matters and should be traceable to the original assumption.

Can you clarify please?
Paolo

[sargasso]

I disagree with the necessity to create a new element, stereotyped - or even categorised issue elements should give enough clarity to the nature of the issue ... that it is an assumption, which unless resolved to be false, given enough focus on it, remains <<default>> true.
And thus, the designers and developers will accept the assumption and design and develop accordingly.

Over thirty years in this game has given me enough (Oh how I hope) insight into the minds of the beasts that I react violently to the "silent acceptance of assumptions".

(YELLS) There is actually no such thing as an assumption! (/YELLS)

All "they" are, are an admission that some aspect of the requirement or environment hasn't been resolved.  They are at best, a question raised by the implementor of a system back towards the requirements, without (god forbid) another iteration of write/query/modify/confuse/assume/query ... at worst they are a pre-prepared limp wristed "excuse" that the  "project could not have possibly known that, and besides which, we told you we didn't know that, and we are so clever that having told you that we didn't know that we went on and spent 95% of the development budget grinning all the way that we have a pre-prepared excuse."  

I'M SORRY. THERE IS NO EXCUSE.

If an aspect of a project is recognised as being an "assumption" then it is behoven on the project management to  resolve it one way or the other. i.e. it is an ISSUE.

(Down and dirty)  "Assumptions" have only crept into reality as excuses - pre-prepared by lazy analysts, designers and project managers who can will not get out of their comfy blue chairs and FIND OUT THE ANSWER!!!  

Now if OTOH there is no answer, then perhaps the project should consider proceding to spend the shareholders money and the stakeholders interests under the ASSUMPTION that they are "Gods" and the customers/users/shareholders need not know the ways of gods      ........


There are no assumptions.  There are only unresolved issues.

bah!
bruce

[sargasso]

If an assumption imposes (generates) a constraint then, as you say, once deployed the constraint is what matters and should be traceable to the original assumption.

and on that I agree. If possible.  But then again ....
its just another excuse, not a solution.

bruce

[sargasso]

About 4 decades ago (seriously, this true) I was programminig the dreaded Olivetti teller machines.  I asked the client ( a building society ), "What is the MAXIMUM $value deposit you need to accept over the counter?".

The reply was, and I can probably remember the quote...

"Oh, most of them are pay packets and they are about $300"...

...

...

"Unless, of course, someone comes in and presents a property  settlement cheque and then it could be, oh, anywhere up to 3 million dollars"



AAAAAAAAAAAAAAAAAAARRRRRRRRRRRGGGGGGGGGGHHHHHHHH!!!!


bruce

[Graham_Moir]

So, Bruce - are you back?

[Paolo F Cantoni]

So, Bruce - are you back?

NO! bruce is back!

I've had to change my spell checker to make sure I accommodate him!

Paolo

[Paolo F Cantoni]

OK bruce...

I believe I now understand the exact nature of your objection...

(And again, I agree wholeheartedly with the thrust of your postings herein)

Your view is that by "naming" an unresolved issue as an assumption, you create too much risk of mismanagement.  Yes?

However, if as part of the project management process there is an explicit mechanism to identify, and resolve "assumptions" - would that be acceptable?

The reason I'm taking this route is that as human, we all make assumptions.  Sometimes, getting some people's head around "an assumptions IS an unresolved issue" is too much of a conceptual leap.  It's often easier to say (as we have done to some new teams that have just been created):  "If you find yourself making an assumption, turn it into a non-assumption!  Find out the facts!  If you can't find out the facts, document the assumption and that you can't resolve it.  If you do find out the facts, and they aren't already documented; document the resolution."

There's an implication, not expressed, that if the facts could have been found out by the assumption documenter then they DON'T get a gold star and a koala stamp!

...

However, having got this far, I think we've taken the easier route and the "road less travelled" is actually the better one.  I'll propose to my fellow architect that we refactor our direction to the teams along the lines you suggest!

Thanks for your clarification, it's certainly helped me!
Paolo

[bknoth2]

In my business, assumptions help define the scope of a project and are often stated explicitly in the contract between my company (a contract R&D organization) and the client. If an assumption turns out to be incorrect, then the scope of the project is affected and the contract may be re-written or canceled. Those are the assumptions I want to identify.

These assumptions are not issues, in that the assumptions are dormant. They don't get revisited or resolved or even monitored.

[Paolo F Cantoni]

These assumptions are not issues, in that the assumptions are dormant. They don't get revisited or resolved or even monitored.

Bruce,

Just for interest, how do you therefore determine that the assumption turned out to be incorrect?  What you've described sounds like a "Catch-22"...

Paolo

[bknoth2]

Answering the question about how we learn if an assumption isn't correct gets us pretty far away from UML. I'll bring this discussion back to the UML with the example that led to my original request.

We're defining requirements for a simulated radio transmitter/receiver system. We are assuming that weather and terrain are not part of the simulation; to do otherwise would introduce a litany of requirements we aren't prepared to handle.

I suppose we could treat the assumption as a requirement: "The simulation will not model weather or terrain." That requirement doesn't really lend itself to tracing or verification, and there is probably a law against negative requirements.

We could call it an issue: "Does the system model weather or terrain?", answer "no", and resolve it. In that case, the issue goes into the list of resolved issues, which means it is out of sight.

I want a list of assumptions, such as this one, that define scope. We can discuss them with the client, refer to them in the future, and revise project scope if we need to change the assumptions.

Putting assumptions in the UML model seems like a convenient place to store them, although I could maintain a separate document.

- Bruce

PS. I'm now handling assumptions by creating an "Assumptions" view and putting stereotyped issues into that view. It would be cleaner to have an "assumptions" element.