Hi,
I´m sorry for the intromission on this subject, but I´d like to complement Jean's 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Ruehlin Sent: terça-feira, 22 de maio de 2007 16:52 To: epf-dev@eclipse.org Subject: RE: [epf-dev] No coding in Inception Hi Jean, thanks for your thoughts. We'll 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 we're confident the architectural approach is already proven. This isn't 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 we'll 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 doesn't 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: [EMAIL PROTECTED] phone: 760.505.3232 fax: 949.369.0720 ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Jean Pommier" <[EMAIL PROTECTED]> Sent: Tuesday, May 22, 2007 11:08 AM To: epf-dev@eclipse.org 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, [EMAIL PROTECTED], www.ilog.com --------------------------------------------------------------------- _______________________________________________ epf-dev mailing list epf-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________ epf-dev mailing list epf-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/epf-dev
