[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [epf-dev] Architect as supporting role to design_solution
|
I agree that architecture is an input workproduct. I don' think that we should be recommending that design is done without reference to the architecture - surely that's bad practice?
So I don't think it's optional.
I have updated the bugzilla entry 135679 (hmmm. Now that I am typing this, I am wondering if this should be a seperate bugzilla entry?) Mark Mark Dickson Principal Architect 0780 1917480
----- Original Message ----- From: epf-dev-bounces Sent: 04/08/2006 01:07 AM To: Mark Dickson; dj@xxxxxxxxxxxxxxxx; epf-dev@xxxxxxxxxxx Subject: RE: [epf-dev] Architect as supporting role to design_solution
It also seems like the Architecture itself
should be a required input to this task (it’s currently identified as
optional). Is there a time when a developer will design a solution without
referencing the architecture? It doesn’t seem like that would be the
case. But if the artifact is truly optional we may want to indicate under what
circumstances the architecture can be ignored when designing the solution.
- Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer
email: jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax:
949.369.0720
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark.Dickson@xxxxxxxxx
Sent: Friday, April 07, 2006 4:35
PM
To: dj@xxxxxxxxxxxxxxxx; epf-dev@xxxxxxxxxxx
Subject: [epf-dev] Architect as
supporting role to design_solution
I'd like to add the Architect role as an additional
performer on the Developer Task design_solution. What do you think?
My justification is that the Architect role (as opposed to
an architect playing the Designer role) is interested in a distinct aspect of
this task. For example;
- the design of architecturally significant use case
scenarios
- the identification/specification of significant
interfaces
- the design of key mechanisms
- the allocation of responsibilities to components
I'm going to raise a bugzilla and assign it to you. You
can always reject it if you don't agree (I'd like a chance to discuss it first
though, if you're veering in that direction).
Whilst this email has been checked for all known viruses, recipients should
undertake their own virus checking as Xansa will not accept any liability
whatsoever.
This email and any files transmitted with it are confidential and protected by
client privilege. It is solely for the use of the intended recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.
Any opinions expressed in this email are those of the individual and not
necessarily the organisation.
Xansa, Registered Office: 420
Thames Valley Park Drive,
Thames Valley
Park, Reading, RG6 1PU,
UK.
Registered in England
No.1000954.
t +44 (0)8702 416181
w www.xansa.com
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
Whilst this email has been checked for all known viruses, recipients should undertake their own virus checking as Xansa will not accept any liability whatsoever.
This email and any files transmitted with it are confidential and protected by client privilege. It is solely for the use of the intended recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.
Any opinions expressed in this email are those of the individual and not
necessarily the organisation.
Xansa, Registered Office: 420 Thames Valley Park Drive,
Thames Valley Park, Reading, RG6 1PU, UK.
Registered in England No.1000954.
t +44 (0)8702 416181
w www.xansa.com
|
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev