Proposed Product Oriented Nature of This Forum

[PhilR]

Hi everyone,

Here is a proposal for organising this forum.  I suggest that we start a thread for each of the work products that can be produced with EA.

For example,

Process diagram
Class diagram
Use case diagram and use case narrative
Collaboration diagram
etc

Under each thread people post advice on the process followed to create the diagram, reason for the diagram, quaity measures etc etc.

The 'Use Case Cookbook' thread is shaping up as a useful use case thread.

Also think that we will be needing a process FAQ at some point as the wisdom accumulates?

What do people think?
Phil.

[CJ]

Would it be worth having separate threads for work products (artifacts), workflows and phases?  (Yes, I've got "The Unified Software Development Process" book in front of me...)

Something like:
Artifact - Use case diagram; Artifact - Use case narrative; etc.
Workflow - Requirements Capture; Workflow - Analysis; etc.
Phase - Inception; Phase - Elaboration; etc.

Is that a wee bit of overkill?  If so, then I think I'm with Phil's proposal.

I think an FAQ would be needed asap (would be nice if forum was cleaned-up as things get moved to an FAQ).

[Steve_Straley]

Jason,

I like your outline and then break it down into the various sub-parts encompassing what Phil said.   I would also like to see something on "measurement" of those requirements perceived by users.  Also, an "as is" process to show in those cases new systems either replacing existing systems OR integrating into/with existing systems.

Just my .02.

Steve

[PhilR]

How about if we use the diagrams listed in EA's outlook bar as a starting point?

That would give something like the following structure.

Process (Analysis)
Use Case
Activity
State
Sequence
Class (Logical)
Deployment (Physical)
Requirements (Other)

(I don't actually have a copy of EA with me at the moment so I am working from screen shots)

Each of these can be further decomposed by the diagram elements and finally by each of the tabs on the element detail screens.

For example Use Case Diagrams would have.

Use Case (Requirements, Constraints, Scenarios etc)
Actor

If we then follow Jason's suggestion we can describe the work product for each phase of a project.  Inception, Elaboration etc etc.

Phil.

[Tom_Andries]

Modeling :
You have to agree on what those work products are: will you take a UML-view, an EA-view, a RUP-view, ... ?
I'd take the list of official UML-diagrams and add specific diagrams (EA possibilities, profiles) to it.

Process:
UML is a modeling language, not a process. The fine line between the two is not always obvious. As problems are often more process than notation related, one cannot exclude the process part.

Workflow and Phase are orthogonal views on process. Applying both to structure a forum might be overkill. I'd choose one axe to structure a forum (e.g. Workflow).

Tom

[Steve_Straley]

Tom,

You've touched on a good point although RUP is more of a process than a model, although it certainly blends the two.  

Having worked extensively with RUP and Rose and EA and yadda yadda, I've got to say there are areas in the PROCESS where RUP falls apart.   I can't stress this enough: if Six Sigma is modifed to encorporate RUP concepts and in turn modifed to blend in the modeling aspect, then we've got something.   That's what we've done here.   Six Sigma starts us off and gives us something that we can measure and quantify.  It also has some of the project management stuff and "tollgates" that we feel is necessary.   RUP is part of the associated documentation we require and then connects via the UC's into the Model, where the actual development team takes over.

Just a couple of toughts.

Steve

[Tom_Andries]

Steve,

RUP was only mentioned under the modeling header as indication that "work product" can be much more then just diagrams, the typical UML domain.

As for the rest of your reply, I couldn't agree more. In my practice as both methodologist and quality controller, most of the problems originate back to scoping and requirements.

Apart from it's affordable price (yeah, I'm a poor almost lonely consultant), EA's extensions beyond UML were just what convinced me to buy the product.

Oh, by the way: I've started my career ... back in those Clipper days. It's not about getting old, it's about seeing new horizons ...

I'll come back to the structure proposal itself, after some study & questions about the forementioned EA extensions. Just hope it's worth the while (meaning: people will have the selfdiscipline to respect a structure, still applying common sense).

To be continued ...

Tom

[Steve_Straley]

Tom,

Yes, most of the problems stem back to scoping and requirements but there is an added dimension to this that I've had the pain to realize.   One of the things that RUP misses IMO is "weighting" which is stressed in Six Sigma.   Part of the Six Sigma scope involves "MEASURE" which means all stakeholders outline CTQ's or Critical to Quality and they scorecard their "desires" based on the team's set of CTQ's.   You then gather the values and average and mean average them out to get a perspective on what is "important" versus "nice to have".   This ties into the requirements and helps all people in the process evaluate what high-level items are critical, which requirements tie into those critical items, and which are just "nice to have".

The other problem I've found is problematic for both RUP and Six Sigma.   Managers, executives, et cetera love the structure of a square but once they start down the path they tend to cut the corners off the square to save time (and money so they perceive).   The trouble is that by the time you get to the point in testing, you've got now a circle and the gaps between the process you DID take (the circle) and the process you SAID you would take (the square) leaves all the room in the world for software to miss the mark.  So while it is scoping and requirements, it's also sticking with the process to the very end that is so critical.   Again, the thing about Six Sigma that I like are the TollGate Steps involved in the process.  Circles are still built but to a less degree.

As far as Clipper, well... Savannah Brentnall and Dave (I can't remember his last name) introduced me to OOP and Class(y).  From that point on, with VO then Java and the open source stuff, and now .NET, I've been in love with the OO paradigm.  Along the way came UML, then RUP and then Six Sigma and ever since, I've been happier than a pig in a stye (now that I'm in the South!).

Merry Christmas!

Steve

[Tom_Andries]

Steve,

Well, I almost get emotional seeing people with pretty much the same youth: Clipper + Class(y), VO and then on to Java.
I found Class(y) a revelation, while VO had a steap learning curve and proved to be very unstable - both in technical and in market share terms. So much for the past ...

If you continue to go on like this, we want get into a flaming war with each other as, again, I do recognize - and confirm- your story about sticking to the process. Moreover: the people heading method support are the first onces to start shortcutting everything in the name of some self-imposed and thus divine deadline. But there's little one can do about this: I tend to wait for all those numerous cases when they have to rework because of things skipped, and try to improve at that point in a way that aligns with the foundation one would have got when working properly.

I'll have a closer look at the Six Sigma, since this is not a topic I'm familiar with (as opposed to Yourdon/DeMarco, Merise, OMT, RUP, UML, CMM, ITIL) and your enthusiasm makes me curious.

Thanks for your reply, and all of the best for you and your family for this and the coming years.

(Still need to contribute to the forum structure proposal. All this loving-kindness isn't very mindful in that regard!)

Tom

[Steve_Straley]

Tom,

Yeah, VO was unstable and was rushed.   I've found 2.5x to be fun to work with at times.  Take away the initial instability, What is odd in the evolution of VO is what happened to people at that time.  Here, the history of Clipper, people wanted more power, more things.... and yet, unless the IDE made moving intot he OOP/Windows world easier, they didn't like it.  As a result, Delphi and VB got the foothold and VO was doomed.   Now it's just been taken over by Windmill-stabbing zealots that can't let it go.   Eventually, after working at CA and seeing how "corporate thinking" works, I dropped all ideas of books and seminars and things like that.  

Moreover: the people heading method support are the first onces to start shortcutting everything in the name of some self-imposed and thus divine deadline. But there's little one can do about this: I tend to wait for all those numerous cases when they have to rework because of things skipped, and try to improve at that point in a way that aligns with the foundation one would have got when working properly.

Oh so true.  The trouble with waiting is that by the time the rework has to be done, the mucky muck that pushed the schedule to cause the gaps has been promoted and the re-work is on someone else's shoulders.   Ah... yes... the sour cream does rise to the top in most of these places.

Let me know what you think about Six Sigam.   We just released another beta version of EA-Req and went into alpha mode with EA-QA... so I hope this next year will be better than the one leaving.

Again, happy New Year to you and your family...

Steve

[huddie]

Hi Everyone,

I must say I like Phill's idea. Splitting threads by diagram (UseCase, Collaboration etc.) seems the best solution to me as there can be little doubt as to what's to be found where this way.

As Tom states so well, UML is a  language not a process, and I think this is very important discussion. I only recently joined the EA family and I was struck by the fact that the most interesting discussions here are often not so much about the UML as about "How should  we use this?"

I think that if you wanna know what a certain diagram is about there's plenty of material out there. But I find it very interesting to read how other people put their's to work. And specially in relation to EA. So in my opinion the process could proof to be of much more interest then the UML ( in this forum, at least! )

Take my case: this is my first project with EA and I want to generate Functional Specifications Document for the system I am designing. I want this document to show the user/client what he's gonna get at the end of the run. How do we do this?

So I can imagine that next to the threads for each kind of diagram (wich are EA independant) we also have threads for:
- Generating code
- Generating documentation / help
- Generation testscenario's

What do you guys think about this?

Regards,

Huddie

[mbc]

I would rather that the forum is more goal-oriented. After all, I don't start out by saying to myself "I want to make a sequence diagram - now what can I show in a sequence diagram?".
No, my question would be something like: "How can I model the interaction between the different parts of my software?" and the answer would be "You may use a sequence diagram or a collaboration diagram. The advantages and disadvantages are....".
I think this forum should be process-oriented, not notation-oriented. There are many different processes (ways of utilizing the UML notation and EA tool) out there, and this should be a place to discuss them all.

Mikkel