A couple of thoughts to throw into the pot. In the small team context with a project of 3-4 months, I would typically be looking at iterations of around 1 week for Inception and Elaboration; and 2 weeks for Construction & Transition. The motivation for this would be to generate urgency, momentum and confidence over a relatively short time frame. I would almost certainly be expecting to produce some software in Inception to demonstrate the feasibility of the solution. In RUP, this would be represented by the Architecture Proof of Concept, produced in Inception. The thing is that even though RUP identifies this product it is not (as far as I can tell) supported by explicit Implementation discipline tasks. It is a product of an Analysis & Design task performed solely by the Software Architect role. Earlier this year I proposed that we drop the Architecture PoC from OpenUP, reasoning that, as an optional product it didn't fit with OpenUP/Basic's minimal philosophy. Further, it is possible to view the PoC as simply an example of a Build. We can use the existing Development and Test content to produce an Inception phase CP to demonstrate the architecture. This approach would show that we are proving the architecture with working software early in the project.
Cheers Mark Mark Dickson EAS Practice Xansa 0780 1917480 *** sent from my blackberry *** ----- Original Message ----- From: "Nate Oster" [EMAIL PROTECTED] Sent: 05/22/2007 10:53 PM To: "Eclipse Process Framework Project Developers List" <epf-dev@eclipse.org> Subject: RE: [epf-dev] No coding in Inception Jean, One thing that we're focused on articulating better as OpenUP/Basic approaches 1.0 is the "Dev Case" that it addresses "out of the box." I mean, OpenUP/Basic is "minimal, extensible, _complete_," but that doesn't mean it's complete for all cases, or that it never needs tailoring before use. The idea is that OpenUP/Basic should be an executable unified process for small, collocated teams on relatively short engagements. I was hearing 3-5 people, 3-4 months from the original committers, but always had trouble squaring that with the fact that we recommend four week iterations, and there's four phases, so unless we're planning one iteration per phase (!), that's 4 months right there. I'm hoping we'll eventually settle on something like "5-8 people, 5-8 months." The exact numbers don't matter as much as getting the idea across that we're talking small teams applying agile practices, ideally to architecturally significant problems, to quickly deliver working solutions. This needs to be explicit in the /basic process. (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=176199) Per your P.S., there are other disciplines that have *tasks* that are unused in Inception. Test, for example, doesn't perform Implement Test Scripts or Run Tests during Inception, which is a bug that's closely related (https://bugs.eclipse.org/bugs/show_bug.cgi?id=187665). I'd like OpenUP to acknowledge "if you've got code, you've got tests." I'm incline to avoid the "multiple CP" option that Ricardo mentions for a couple reasons, but mostly because it immediately introduces process tailoring into the Inception phase, and I think one of OpenUP/Basic's strengths is that you *can* extend it all you want (easily), but it's executable for small teams without tailoring. Thanks, Nate Oster -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean Pommier Sent: Tuesday, May 22, 2007 2:08 PM 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 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/epf-dev
