Nutshell of this discussion: Capability Patterns should be the primary focus for expressing collaboration in OpenUP/Basic. They could be the first port of call for users to understand how OpenUP/Basic works in detail.
Here's the story... In the Architecture Content call today, we discussed how to redefine the architecture content to show focus on delivering software, rather than models and documents per-se. We looked at an outline of the architecture work proposed by Jim (see the attachment on https://bugs.eclipse.org/bugs/show_bug.cgi?id=165245 and the previous posting to epf-dev by Jim for the document). This is a very useful outline and is a good illustration of the idea that we are doing architecture to get software. In doing so, we can produce models and document aspects of the architecture if they help - perhaps with the notion in mind that we do "just enough architecture to enable the team to develop software coherently." (I'd like to propose that as a heading under one of the OpenUP/Basic principles, by the way, probably under Balance or Focus). If we examine the activity diagrams Jim produced in his document, it's clear that we are looking at a collaboration across Requirements, Architecture, Development and Test roles and tasks - probably with a dose of Project Management in there for good measure. We got on to discussing the idea of how we show collaboration in the OpenUP/Content, especially with reference to the discussion last week about late role assignment and making the Task content more role-agnostic (around Additional Performers). It seemed to me that Jim's activity diagram was similar to a Capability Pattern. It shows how tasks (and hence roles) combine to achieve a goal - this case identifying and then proving a the architecture. Not all the activities in the diagram map directly to a Task in OpenUP/Basic but that's not really important for the purposes of this discussion. It might be that we have focused too much on Tasks and shoe-horned collaboration into the task descriptions. If I want to change the focus of the architecture content to producing a build rather than an "Architecture" artifact, it is tempting to list "Build" as one of the outputs of "Develop the Architecture." In the overall scheme of things, this doesn't seem right though. It is better to bring in Tasks from the other content packages (like Development and Test) to achieve this goal. Which means defining a capability pattern. "Hang on," I thought, "this sounds very familiar..." This is exactly what RUP does. RUP defines Activities in the reference workflows (which themselves are capability patterns in RMC). These show how Tasks from different disciplines combine. The Tasks themselves are fairly light on Additional Performers (it looks like additional performers are listed where the work done by that role introduces some sort of constraint on the Primary Performer but I'm sure someone from IBM can clarify). So, we can reason that if we want to show collaboration explicitly in the process, we should do it in the Capability Patterns first and be much more sparse with Additional Performers than we have been. This would be an approach that is consistent with RUP, which presumably would help with scaling OpenUP/Basic. As I write this, I am struck by the distinct possibility that this posting is the email equivalent of a large penny dropping for me (and me alone) and the rest of you are thinking "Well done Dickson, do try and keep up..." If so, I apologiset. I can't read everything that get's posted, you know :-) cheers mark Mark Dickson Executive Consultant EAS Practice m 0780 1917480 w www.xansa.com e [EMAIL PROTECTED] 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 [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
