[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epf-dev] The OpenUP disciplines
|
Hi Peter
This is interesting stuff and I'm really pleased that you've decided to get
involved.
I'm going to attempt a reply of sorts here - a lot of this is "thinking out
loud" which I would normally prefer to do more casually but we don't have
that luxury with email. As long as everyone accepts that I'm not on some
soap-box with a mature thesis here - I'm just mulling over a few things
with the people on this group. Feel free to discuss/disagree. Just don't
flame me! :-)
Looking at your comments, it occurs to me that once we get beyond the
discussion on the specifics you're raising - which I'm going to avoid doing
in this particular note ;-), I think that there is a deeper question at
play. One that has been on my mind for a little while now. Namely - how
much should we be prepared to change from the initial RUP content donation?
Or indeed UP?
>From one perspective, IBM has donated a bunch content from RUP and (AFAIK)
as long as we comply with the SPEM/UMA metamodel, we are free to make
whatever changes we (as a group) think we need to.
On the other hand, there is a strong case in favour of minimising change
and sticking with the basic UP/RUP discipline structure and other
structural elements like Task, Workproduct and Role names.
Balancing these perspectives is not a trivial task. Especially as the whole
of the EPF as a content framework needs to appeal to more than the
committed UP/RUP community. I sense that there is a general desire to make
OpenUP more than "UP deployed via Eclipse Method Composer."
On the OpenUP project we are making individual cases for changes to
instances of all of these types of element - all of which are substantiated
by reasoned argument and I believe a genuine desire to do the right thing.
As discussed at the last F2F meeting, there is a possibility that this
gradual (and discrete) change process will undermine the integrity of the
whole. There are also obvious risks around taking something well known and
proven and morphing it into something new and unproven.
In our project plan we have (if memory serves) a consolidation and review
activity where we will assess the work as a whole and resolve any integrity
problems - but it would seem to be a good idea to try, as early as
possible, to minimise opportunities for problems to arise. It may be that
we need to agree some basic guidelines around this topic. As far as I can
determine, we haven't established anything specific in this area (if I've
missed them, somebody please shout up).
Just to be clear - I am not suggesting that the changes we have made to
date are in themselves bad ones - just whether they are the right decisions
for the in the context of the project at large and at this time.
I think that the decision to change the Disciplines falls squarely into
this discussion and I am pretty sure that there are others.
There are (IMHO) good reasons for each change that has been made BUT each
change, by definition, moves us a little further away from the original UP
model. The question before us is (again IMHO) is this a good thing? Or
should we adopt a guiding policy over the scope and scale of change?
I summarised this issue on the OpenUP author's call today and it sounds
like it's a good candidate for putting on the agenda at the Vancouver
meeting next week.
cheers all,
Mark
Mark Dickson
SAE Practice
m 0780 1917480
w www.xansa.com
e mark.dickson@xxxxxxxxx
Peter Eeles
<peter.eeles@uk.i
bm.com> To
Sent by: epf-dev@xxxxxxxxxxx
epf-dev-bounces@e cc
clipse.org
Subject
[epf-dev] The OpenUP disciplines
6 May 2006 17:55
CET
Please respond to
Eclipse Process
Framework Project
Developers List
<epf-dev@eclipse.
org>
Hi folks,
I know there is a thread (somewhere) already discussing this, but I'm
unable to find it right now. Anyhow, I wanted to give my 2 cents on the
OpenUP disciplines. This is based on my understanding that we have
disciplines of "Architecture" and "Development". I have a number of
concerns about this distinction and have commented below. I'd appreciate
all feedback - especially those that correct my understanding!
1. With regard to "development", surely all of the disciplines contribute
to "development". I understand that many organizations use the term
"developer" to represent the "coder", but this doesn't translate into
"development" as a discipline for me.
2. In addition, it would appear that the development discipline includes
design. This one really stumps me. Design and coding are different sets of
responsibilities to me. Why put them together in the same discipline?
3. This then seems to contradict Mark's assertion that "all architecture is
design, but not all design is architecture". If architecture is design,
then this would place architecture activities in the development
discipline. The net result is we have 1 discipline called "development".
Doesn't sound right to me :)
4. I actually disagree with the statement "all architecture is design ...".
Architectural decisions are made with respect to coding and requirements
(for example), which is one of the reasons (I believe) that RUP has no
architecture discipline since architecture touches a number of disciplines.
5. I think we also need to consider that architects, in some cases, do not
go from requirements to detailed design in one step ("architecture"). They
may, for example, perform some architecting activities that are
technology-independent, that designers then flesh out the details of. This
is called "analysis" in RUP. The architect then identifies the
technology-specific elements, and the designers flesh out the details of
these. There could be even more "levels of refinement" in between
requirements and detailed design. Therefore ... the notion of having an
architecture discipline is a gross simplification that would seems to
assume that architecting is performed once in an iteration. Whereas I think
the architect is involved, for example, to a) prioritize requirements b)
identify technolgy-independent design elements c) identify
technology-specific design elements and d) identify
architecturally-significant implementation elements. In summary -
architecting spans several disciplines.
6. Although I've worked with RUP for some time, I often explain RUP in
terms of the following disciplines: a) Requirements b) Design
(platform-independent) c) Design (platform-specific) d) Implementation e)
Test, where Design (platform-independent) equates to RUP's analysis
discipline, and where architecting spans several disciplines.
I think that will do for now, and welcome feedback :)
Regards,
Pete
================================
Peter Eeles, MBCS CITP
Executive IT Architect, Technical Staff Member
Rational Brand Architect for UK, Ireland, South Africa
Email: peter.eeles@xxxxxxxxxx
Mobile: +44 (0)7796 331061
Mobex: 264305
=================================
The IBM Rational Edge Live! By Developers for Developers.
For more information on this and other events such as the Rational User
Group visit:
www.ibm.com/uk/news/events/softwaretechnicalbriefings/
_______________________________________________
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
