BUP Special Interest Groups (SIGs) – meetings minutes
Architecture
- 2/22 8am PST
- Participants: Brian Lyons (Number Six Software), Ricardo Balduino (IBM), Jim Ruehlin (IBM), Chris Doyle (Synergy Plus), Jason Mansell (ESI), Aitor Bediaga (ESI)
Overall:
- I think we need an “Architecture”. I think we need one task for creating it and another for proving feasibility.
- I think we need to revamp the guidelines.
RUP has “Concept: Software Architecture”, BUP has “Concept: Component” and “Concept: Patterns” and the “Practice: Using Patterns”… are patterns part of our minimalist process?
Do we keep this guidance?
I think we can come up with a number of concepts, practices, guidelines that are appropriate for a minimal perspective of architecture. What we have here is not it.
Revisit it.
Why do we have a proof-of-concept, but not an architecture? Shouldn’t some notion of an actual architecture (even if represented on a white board) be in the minimal (i.e. non-MDD) process?
Yes, it should. See action below.
The Architect role is “responsible for the software architecture”… but there is no software architecture if we are not doing MDD. But, I really like this definition. So, I think we need to have the architecture (even if it can be represented as stories around a camp fire).
Action: move artifact and tasks from MDD package to high level package. Move all guidances, but Concept:Visual Modeling and Practice: Using Visualizations. Rename this package from MDD to Visual Modeling. (Bugzilla 132056)
I think Analyze Architecture is a reasonable, minimal process task that would be extended to include steps of “Model <blah>” in the MDD plug-in.
Action: Consider this in an MDD plug-in
Is the word “Analyze” too provocative? Should we say “Define”? We need to investigate if we can demonstrate that we can align with “Serendipitous Architecture”. So perhaps we need to make sure our verb can work with a “found” architecture that one just stumbles on while walking through the woods.
Task: Create Architectural Proof of Concept
- [Though I know this is taken from RUP, ] I hate “Create/Contruct <artifact>” task names. Though that is the resulting artifact, can’t we say you are going to “Prove Architectural Feasibility” (Which combines the RUP “Construct” and “Assess Viability” tasks)?
- Action: propose and vote on a better name
- [Though I know this is taken directly from RUP, ] I don’t like the representation as a list of known technologies unless we state that it is a list that are known to interoperate and known to be appropriate for this solution (if they “seem appropriate”, they hardly represent a proof-of-concept)
Action: review text
Action: during Construction, keep only Task: Refine Architecture. (Bugzilla 132056)
Development
- 2/22 9am PST
- Participants: Brian Lyons (Number Six Software), Ricardo Balduino (IBM), Jim Ruehlin (IBM), Chris Doyle (Synergy Plus)
Implement Tests vs. Run Tests. Is there a way for a Task to straddle another task (so these could be compressed?). It is notable that a step in “Integrate and Create Build” essentially invokes “Run Developer Tests”. Could we include the implementation of the tests as part of the implementation of the solution?
No action: leave as it is.
Guidance: Implementation remarks on “a model representation for implementation.” Is this appropriate in our minimal, non-MDD process?
Action: review text and make sure the minimal process does not necessarily advocate for implementation model
Need UI prototype guidance?
Action: write text for task steps and then decide if extra guidance is needed
Action: rename package MDD to Visual Modeling (Bugzilla 132057)
Action: move Design artifact to upper level package. Have a contributor inside Visual Modeling package to contribute the sub-artifacts. (Bugzilla 132057)
Action: move Task Design Solution to upper level package. Make sure text is not model specific. If needed, add a contributor on VM package. (Bugzilla 132057)
Action: move guideline and checklist for Design to upper level package. (Bugzilla 132057)
Configuration Management
I don’t like the ‘private’ part of the definition of a workspace since there are also integration workspaces.
Action: merge two Concepts: “Workspace” and “Dev_Int_Workspaces” (Bugzilla 132058)
Test
- 2/23 11am PST
- Participants: Brian Lyons (Number Six Software), Ricardo Balduino (IBM), Jim Ruehlin (IBM), Bruce MacIsaac (IBM), Dana Spears (Number Six Software), <?CapGemini?>
Test Ideas
- Actions: (Bugzilla 132060)
- -> Compress two concept items into one. (test idea list and test ideas catalog)
- -> Add step regarding it to Create Test Cases. (before Outline Test Case, consider test ideas)
- -> Combine two guidelines (test idea: Booleans/boundaries and Method Calls)
No testing in Inception.
Agreed.
Action: Add a Brief Outline for Test Script
Action: Test Case to capture if test passed or failed.
Action: Combine Guideline: Types of Test. Delete Guidelines for Usability, Performance Test. (Bugzilla 132060)
Requirements
- 2/23 1pm PST
- Participants: Brian Lyons (Number Six Software), Ricardo Balduino (IBM), Jim Ruehlin (IBM), Steve Adolph (UBC), Kurt Sand (Telelogic)
[Kurt] Concept: What are Good Requirements?
Guideline:
Checklist
= detailed. Double-check. Common errors.
Action: Kurt will provide text for this guideline
[Kurt]
[General]Guidance: Conduct Review/Concurrence?
<collaboration and review meetings…>
Action: consider a General package with tasks of this nature and an Overarching activity on the Delivery Process to cover on-going (not planned) tasks
Specification: Supporting Requirements
Action: add artifact, revisit tasks to update inputs/outputs, assign responsible role (Bugzilla 132061)
A checkpoint for Define Vision
[Achieve Concurrence]
Action: Add as final step to this task (Bugzilla 132061)
Action: Add guideline on Achieving Concurrence and attach to step above (Bugzilla 132061)
Concept: Traceability
[attached to detail requirements ]
“Inherent traceability”
Action: create Concept page, add text and attach to task “detail requirements” or “find and outline requirements”???
Concept: Requirements Gathering Techniques
- will be the summation of Pareto + Fishbone + Brainstorming +
- Action: see below
Do we want to commit to use cases (vs user stories, product backlog items, etc.)? I say yes (though their specific form can vary).
What is up with the Task “Find and Outline Actors and Use Cases” in the WBS?
Action: old element. Clean up Library. (Bugzilla 132052)
What is up with the Scenario as a work product in the Manage Requirements Basic Building Block?
Action: old element. Clean up Library. (Bugzilla 132052)
We need supplementary specs. Are they in the use-case model (I would say no, but it is always interesting to see that RUP training has the use-case model as the complete requirements model).
See action above to include Supporting Requirements
Find and Outline Requirements: Does that cover use cases? If so, we need to revisit the output work products.
It does. Step points out to guideline: Find and Outline Actors and UC.
Action: include UC Model as output of this task (Bugzilla 132061)
I think we can trim out some of the Leffingwell stuff like Pareto and Fishbone.
See below
What is the thought behind the RM plan guideline?
See below
No references to traceability?
See above.
Pareto:Kill
RM Plan: Kill
Fishbone:Kill
Action: delete guidance for Pareto Diagram, Fishbone Diagram and RM plan. Merge Brainstorming, Interviews and Req. Workshop into a new Guideline: Req Gathering Techniques. Delete the individual ones. (Bugzilla 132061)
Project Management
- 2/27 8am PST
- Participants: Brian Lyons (Number Six Software), Per Kroll (IBM), Ricardo Balduino (IBM), Bruce MacIsaac (IBM), Jim Ruehlin (IBM), Kurt Sand (Telelogic), Chris Doyle (Synergy Plus), Kirti Vaidya (Covansys),
[Ricardo]Planning, Conducting, Assess at end. Project and Iteration.
[Chris Doyle] Assess and Plan Next Iteration at end?
- Success vs. Failure…
[Kirti] Two parts of assessing. One is at the end … One is a one-day meeting at the end of an iteration.
[Ricardo] Perhaps we could have different
[Kirti Vaidya] Move some of the content from Assess and Plan Next Iteration to Manage Iteration.
What content to move? Do we need to move if we put those 2 activities in parallel????
We need to just make sure people understand that these are not strict.
[Per] We need guiding principles that explain that this is not meant to be taken strictly.
Action: Add guideline on type/frequency of assessments (Bugzilla 132059)
[Doyle] We just need to point out that some of these have synched “ends” rather than starts. Some sort of mini-tutorial that explains this.
Action: Put “Manage Iteration” and “Assess and Plan for Next Iteration” in parallel (Bugzilla 132059)
Plan the Project needs to reference Risk.
Action: include step on “identifying and managing risks”; put a reference to the appropriate guidance: concept: risk, guideline: risk list, practice: managing risk (Bugzilla 132059)
Discussed Risk List as not having an explicit artifact while Work Items List has its own item.
No action identified.
Plan Project has explicit secondary performers of architect, tester, analyst, etc.
Action: add secondary performers (Bugzilla 132059)
Prioritize Work needs Guideline and then steps in Plan Iteration (low-level planning) and Plan the Project (high-level planning)
Action: add guideline: Prioritize Work; (Bugzilla 132059)
Action: add step to prioritize work in Plan iteration and Plan Project tasks (Bugzilla 132059)
Action: Remove Prioritize Work task (Bugzilla 132059)
Assess results has close-out phase as an optional step.
No action identified.
Bruce: Where does “Practice” fit into the “before=concept, during=guideline, after=checklist”?
Practice = motivation for a conceptual notions that are not necessarily attached to a task. [In the future you could select practices or not at a process definition level]
[Bruce] We should do a lot more with practices. They are like cross-cutting things.
No action identified.
Guideline Time-Boxed iterations…
Action: add guideline: Time-Boxed Iterations (Bugzilla 132059)
Risk List in project/iteration plan…
Work Item List … external vs. in Project Plan
No action identified.
We need milestones (similar to what is in RUP today).
Action: Add milestones to Delivery Process (Bugzilla 132059)
We need Guideline planning this process… something like that.
[Per] Also need to reference milestone since we have an optional step Close-Out Phase in Assess Results. But note that the milestone lives in the Process, so we’ll need to have a guideline on the milestones. Could be considered like “aspects”.
Action: Add a guideline about milestones and reference it from step Close-Out Phase (Bugzilla 132059)
[Kurt]Guidance on how you break a project into iterations… Could be in the Iteration Plan.
There is a guidance on that currently (guideline: iteration_plan)
[Per] Need more collaborative guidelines. Agile things like setup shared rooms, etc. There could be a number of these.
Action: elicit which collaborative guidelines we want to add
Scrum creates plan within iteration?
Plan Iteration does not take in Work Item List?
Action: add Work Items List as output of Task: Plan Iteration (Bugzilla 132059)
Monitor and Control project… manadatory vs. optional outputs?
Optional outputs not supported by the meta-model
Why are there templates in that “templates” content package?
Guideline for Planning a project with this lifecycle? We talk about iterations, but shouldn’t the PM have specific guidance on the goals of each phase?
Action: there is currently a guideline: project_plan. Add text to it to cover these concerns.
When would you prioritize work when it is not part of Plan Project or Plan Iteration? I could see this as a guideline attached to a step in each of those tasks.
Action: Add this guideline and reference from the mentioned tasks
Metric = appropriate for minimal? Referenced in Monitor and Control Project
- [Bruce] Might want to be explicit about a few key metrics. At least measuring targets vs. actuals.
- Monitor and Control Project already has step: Derive Metrics pointing to Concept: Metrics
- Action: add guideline for types of metrics to collect and reference from this step. (Bugzilla 132059)
Overarching
- 2/27 9am PST
- Participants: Brian Lyons (Number Six Software), Ricardo Balduino (IBM), Jim Ruehlin (IBM),
Since we are iterative, can we just assume that each task that has an output has an optional input of the same item? Implement the Solution has an optional input of Implementation and an output of Implementation. Should that always be true? Need this be explicit?
Revisit this.
[Per] Welcome page should have
Action: create a welcome page
Any Role.
[Bruce:]
Generalized task for how you handle any task you are given.
- Estimate how long it will take.
- Collaborate…
- Get high-level review when part way done.
Participate in Review
- Generalized task for participating in any task.
Discussion: add generalized tasks in General package (no need for a new discipline, since this is multi-disciplinary):
- Task: Estimate Work – could it be a guideline on iteration planning???
- Task: Review Work – could be a general, high-level task, pointing to specific guidelines on reviewing specific parts of the project (e.g. requirements, design, architecture, code, etc.)
As in the PSP.
… perhaps not a real task. More like a Concept.
Discussion of phases could go here.
Discussion of Principles here.
No actions identified so far.
We need some descriptive abstract tasks. Perhaps we need a new discipline.
As pointed before, these tasks are multi-disciplinary.
Note templates package. Common “use case” of process engineering is to replace templates, but keep it otherwise the same.
No actions identified.
Standard Categories:<revisit>
Action: revisit and discuss if we have the right set of Standard and Custom Categories
We don’t have a deployment discipline:
[Phillipe] Noted we are producing s/w, but not deploying it.
[Chris] Do we need a handover document?
[Per] We need to have something on Alpha releases and Beta releases. We don’t want to imply we have an ivory tower perspective that does not take into account that people will use the product. We need to include ongoing collaboration with the end-user community. Roll-out.
[Kirti] Deployment can happen at any time. It could be at every iteration in Construction.
No agreement on adding Deployment discipline at this point in time.
Action: add guidance on Alpha and Beta releases. Discuss where to attach those to.
We have Base Concepts Plug-In.
- We need to have a team that cleans out vendor-specific stuff.
- Action: clean up Base Concepts plug-in to be vendor-independent (Bugzilla 132062)
We have Scrum plug-in.
- Leave as alpha for now.
Configuration Management
- 2/27 1pm PST
- Participants: Brian Lyons (Number Six Software), Ricardo Balduino (IBM), Jim Ruehlin (IBM), Kurt Sand (Telelogic)
It is interesting that people Submit Change Requests and Make Changes, but they never “Accept” change requests. Is there some coverage of this in a project management activity?
Yes, there is a step in Plan Iteration to allocate change requests to an iteration
Action: in Task Plan Iteration, change the step name to “Allocate Work Items to Iteration” (Bugzilla 132059)
Action: rename Task “Submit CR” to “Request Change” (Bugzilla 132058)
Combine two guidance items?
Action: combine concepts about workspace (Bugzilla 132058)
Add guidance for “Accept Changes at Iteration Boundaries”: Talk about Scrum notion (and notion from other sources such as Watts Humphrey and Steve McConnell) of avoiding acceptance of changes within an iteration.
Action: add Guideline: Accept Changes at Iteration Boundaries (Bugzilla 132058)
Work Items List is the resulting artifact for Submit Change Request.
Iteration Plan is an input to Make Change.
Yes. No action identified.
Discussion: will we treat Work Items List as a virtual/logical entity, which could be one list of things or various lists/DBs for each type of work item???
Note that the creation of change requests is mentioned as a step in Run Tests and Evaluate Test Results.
Action: Step should be part of Task: Evaluate Test Results (Bugzilla 132058)
Not found in delivery process because it is essentially a procedure rather than a planned task.
Yes. No action required.
Lifecycle of Work Item List items (e.g. defects, enhancements, requirements to be implemented, etc.)
Action: Add Guidance:Work Items List (to explain its lifecycle) (Bugzilla 132059)
RUP CM
= Setting up cm system
= Approving and assigning change requests
= submitting change requests and dealing with them
Assuming that an environment is already setup, what is missing in this discipline:
[Kurt Sand] Where is the work for two developers to integrate their work together?
[Ricardo] Integrate and Create Build in the Development discipline
<Need Guidance: Integration that discusses things like continuous integration>
Action: Add Guideline: Continuous Integration. (Bugzilla 132058)
Attach it to Task: Integrate and Create Build
Do we need something to cover “Promote Build”?
- In the CM discipline? With the test stuff? In the development discipline?
- Attach Concept: Workspace
- Performed by Developer (with note that they are lead dev or something)
Action: Add Guideline: Promoting Builds and attach it to Task: Integrate and Create Build (Bugzilla 132058)
Action: Attach Concept: Workspace to Task: Integrate and Create Build (Bugzilla 132058)
Get rid of Make Changes?
Yes. Action: Remove Task: Make Changes (Bugzilla 132058)
Then get rid of workspace?
No. Attached to another task as defined above.
Concept: Change Requests should move from General to CM… unless we get rid of the CM discipline.
Action: move Concept: Change Requests to CM package (Bugzilla 132058)
