Re: [epf-dev] Architect as supporting role to design_solution

[Mark.Dickson@xxxxxxxxx]

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

 

Hi DJ

 

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).

 

cheers

 

Mark

 

Mark Dickson
SAE Practice
m 0780 1917480
w www.xansa.com
e mark.dickson@xxxxxxxxx

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