[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] No coding in Inception
|
Hi Maciel,
Thanks for you input. One thought I had about your situation is that it
sounds like you may either be done with Inception without acknowledging
it, or significantly increasing the risk that your project will require
a large amount of re-work. The milestone of Inception is to get to a
point where you can make a go/no-go decision on the project. If youve
done enough scoping where you can start building the system with high
confidence that its needed and will be completed, then youve finished
Inception (assuming you have Stakeholder agreement). Scope will continue
to be refined in future iterations as requirements get stabilized and
stakeholders provide feedback. So it may be that your implementation is
actually occurring in Elaboration.
If your team really doesnt understand the scope of the project and is
building the system anyway, then you have a high risk of doing something
wrong, or throwing away part of your system. That may be an acceptable
risk for your project depending on how rapidly you need to deliver the
system. But the purpose of Inception in OpenUP/Basic is to reduce this
kind of risk. So it may not be appropriate for OpenUP/Basic to directly
support the scenario you described. However, you can always modify the
phase in OpenUP/Basic (using EPF Composer) and adapt it to your
particular needs.
Generally, the reason for writing and testing code during Inception
would be to reduce some technical risk in the project so that a go/no-go
decision can be made. This might include prototyping a novel
architecture, assuring that some performance metrics can be achieved, or
testing the viability of a new technology to solve a particular need.
- Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer www.eclipse.org/epf
email: jruehlin@xxxxxxxxxx <mailto:jruehlin@xxxxxxxxxx>
phone: 760.505.3232
fax: 949.369.0720
________________________________
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of "Maciel, Eduardo" <eduardo.maciel@xxxxxx>
Sent: Tuesday, May 22, 2007 2:52 PM
To: Eclipse Process Framework Project Developers List
Subject: RE: [epf-dev] No coding in Inception
Hi,
I´m sorry for the intromission on this subject, but I´d like to
complement Jeans view.
It seems that the need to start coding over a partially approved
scope is everyday more common.
I mean, in order to ensure delivery on expected dates we start by the
part of the scope that is already approved or will be with no doubt.
This may lead projects to start coding before all inception goals are
accomplished, for instance.
Regards,
Maciel
________________________________
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jim Ruehlin
Sent: terça-feira, 22 de maio de 2007 16:52
To: epf-dev@xxxxxxxxxxx
Subject: RE: [epf-dev] No coding in Inception
Hi Jean, thanks for your thoughts. Well take them into consideration at
the Committers Meeting this week.
The concern that Brian raised is, should we explicitly indicate that
coding occurs during Inception, and if so how should we do it. We expect
that many projects that use OpenUP/Basic as-is will not require coding
during Inception. Many small projects are not novel or are adding
features to existing systems. So proving the architecture or other
significant system elements could be as easy as pointing to an existing
system or framework and saying that were confident the architectural
approach is already proven.
This isnt meant to prohibit implementing prototypes and the like during
Inception. But OpenUP/Basic is meant to be minimal, complete, and
extensible. If we want to fulfill the minimal requirement, do we
include implementation during Inception? This is a question well be
asking at the meeting.
One possible approach would be to create a second capability pattern for
Inception. So there could be one Inception CP that doesnt include
implementation, and another one that does. CPs can be replaced and the
process re-published using EPF Composer.
Thanks,
Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer www.eclipse.org/epf
email: jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax: 949.369.0720
________________________________
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of "Jean Pommier" <pommier@xxxxxxxx>
Sent: Tuesday, May 22, 2007 11:08 AM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] No coding in Inception
I've been on the list for a few weeks now, so sorry if my reaction to
this thread his missing enough context and OpenUP knowledge. Yet, since
we leverage OpenUP in our company, I want to make sure we are not
missing something around the Inception concept. We also met with Ricardo
to assess our use of and contribution to OpenUP, hence the access to
this -dev list.
Bryan Lyons wrote:
> We should discuss the absence of actual coding in the Inception phase
of OpenUP
> as demonstrated by the Inception Iteration capability pattern and then
discuss
> the notion that other parts of the process and method characterize the
architecture
> has had its feasibility "confirmed"... with no code. This is an issue
worthy of
> discussion with broad participation by the OpenUP/Basic authors.
- First, in our software business we meet prospects and customers either
before they actually launched their project or after. We characterize
the switch from Inception to Elaboration as the official Go/No Go
decision. Within the Inception phase, project stakeholders may have to
demonstrate some concepts and feasibility to get management buy in and,
in the software context, that usually requires some actual modeling and
coding (especially performance benchmarks).
- Another thing is that, to my knowledge, RUP has some coding involved
during the Inception phase (which again makes most sense to me).
Therefore, following generalization principles, I don't see how OpenUP,
which is more general as a foundation, couldn't include the idea of some
coding during Inception. Doesn't mean that there is necessary coding
involved in all situations, but it makes OpenUP more applicable to all
cases by supporting the idea of some coding.
- If the idea behind the previous statement is that a
formal/theoretical/abstract method/approach (as opposed to pragmatic
coding) should be used in Inception, then I think this reduces the
usability and applicability of OpenUP to quite sophisiticated entities
and companies, maybe not something we wish for.
Again, sorry for the long post, hope I'm not too far off topic. In
particular by overstating the Inception/Elaboration inflection point.
Thanks for letting me know otherwise. As suggested by Bryan, looking
forward to hearing back from the OpenUP/Basic authors anyway.
Jean.
PS: by curiosity, is there any other clear cut such as this one on other
disciplines in the phases? I mean a discipline which would not be
present in a certain phase. I thought there was at least "some" of each
discipline in every iteration, some meaning a lot or a little depending
on the phase. But at least some. Makes the process less directive, but
more flexible and applicable.
---------------------------------------------------------------------
Jean Pommier, Vice President Methodology, Corporate Quality Office
ILOG Inc., 1195 West Fremont Avenue, Sunnyvale, CA 94087-3832, U.S.A.
T:+1 408 991 7132, F:+1 408 991 7003, jpommier@xxxxxxxx, www.ilog.com
---------------------------------------------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
