| [epf-dev] Review and Strategy for Design, visual and non-visual |
|
hiho, I’d like to try out something of an e-review of a few
design elements in the OpenUP/Basic process. The Development package has
a sub-package visual_modeling so that the process can be published with and
without the notion of visual modeling. These elements to be reviewed exclude
the visual modeling concept. This brings up an interesting mental
exercise as a UML geek tries to answer the question “disregarding
representation, what is involved in designing a system?” The elements I would like to review are: Task: Design Solution Work
Product: Design Guideline: Design I want to make sure we are all reviewing the very latest
version of these and that we are reviewing them without the visual modeling
stuff. I have attached a Word document into which I pasted the three elements
as published. These are the very latest ones in CVS and they were
published with a configuration that excluded the visual_modeling content.
Please provide me feedback on these elements in the next few days. With respect to content location in OpenUP/Basic there is a
notion that the tasks will have a small number of distinct steps that have very
active “do this” descriptions. Extra detail on techniques to “do
this” can be placed in a Guideline. Furthermore neither the steps
nor the guideline should try to convince the reader that something is important
or try to take the place of training. Some things to keep in mind are: visual modeling with
respect to the design is separated out, user-interface design is also separated
out, and Refactoring is currently just a Concept and a Guideline referenced
here and there. Each of these aspects is fodder for the strategy part of
this feedback elicitation. My goal is to get some feedback on this design content
before we move into the visual and UI stuff (Jim Ruehlin and Scott Ambler have also
been providing good content for this package). In addition to reviewing
the actual content, please feel free to remark on the strategy that will be
followed moving ahead (described below). Mixing in Visual Modeling Based on the original donation of content from IBM,
additional steps were added to this task in the package for visual
modeling. Those steps are bold in context below. 1) Understand requirement
details 2) Identify logical classes to provide behavior 3) Identify design
elements 4) Design Components 5) Determine
how elements collaborate to realize the scenario 6) Create Use-Cases Realizations 7) Refine
design decisions 8) Design
internals (for large or complex elements) 9) Communicate
the design Having covered a range of design concepts in the existing
steps, I am tempted to drop these three steps and just add one step before “Communicate
the design”. Possibly just something like “Model the Design” At this moment, there is Guidance in the visual_modeling sub-package
for Design Components and Use-Case Realizations. In the Architecture
package, there is a Concept on Visual Modeling. I am planning to add an
overall Guideline on Designing Visually that will give some detail to how visual
modeling applies to each of the steps of the Design Solution task. Soooo, does anyone have any opinion that we should keep the
three visual modeling steps? Or definitely just do the one step? Is
there anything missing that should be a step? Given that the Guideline
would discuss how modeling applies to the various existing steps, does anyone
have any “don’t forget <this-issue>” thoughts? UI as its own task with both design and
implementation elements Based on the original donation of content, there is a
separate task called “Prototype the User Interface”. That
task involves producing a design and implementation of the user interface. How do people feel about the user interface being excluded
from Design the Solution? How do people feel about the design and
implementation being put in one task? Should the UI be treated like
visual modeling (i.e. an aspect that can be folded into existing tasks and work
products with its own guidelines and in its own easily excludable package)? Refactoring as Guidance or a Task The original donated content had a Concept and a Guideline
for Refactoring. It has been suggested that Refactoring warrants an
explicit task. How do people feel about having a task for
Refactoring? Or should it be a step (amongst already too many steps) in
the Design Solution task? Or should it just stay as a Concept plus a
Guideline? Thanks in advance to anyone that can take some time to look
through this content and provide commentary. And – as always –
the whole team working together on OpenUP/Basic content would be happy with
additional people volunteering to author some material in any area of the
process.
--------------
b |
Attachment:
Review of Design Content.doc
Description: Review of Design Content.doc