A first contribution on the PUP/EUP

[Steve_Straley]

Andy,

One common base appeals to me as well.   The RUP process is not heavily in the AS IS process mapping which I feel is a weakness and should be addressed.   In addition, I like some of the concepts outlined in Six Sigma so if there was a process that we came up with, maybe included some AS IS stuff, and some Sig Sigma stuff... I'd be as happy as a Pig in $h!!.   That's Southern for "extremely content"!

Steve

[kelly_sumrall]

Guys, I've got a simple question.  What is the desire here.  It's not to create a whole new process is it?  There are already a ton of well documented processes, UP, Agile, OMG Model Driven Architecture, and others.  I don't understand any of these as well as I understand code.  If I did, I don't think I would be excited about this topic.  I think that instead of defining a new process, we need to relate existing practices into the EA/ReqPro products.  If it turns out to be a process in its own right, then so be it.

[frank]

I find it interesting that all name suggestions so far have included the word "Unified".

This term originated in the unification of previously different/competing processes which were significant in their own right.  I don't think that is what is happening here.

Perhaps it would be wise to start at the beginning and define the goals of and reason for the existence of this project.  With that well understood, a name can be chosen that reflects the project's purpose.

Frank.

[Steve_Straley]

Frank,

I think that's what I was trying to impy with a VISION statement.   Even RUP starts off all projects with the Vision Document; businesses start off with Vision Statements.  I absolutely agree with you that a better place to start would be this type of simple paragraph.

Steve

Perhaps it would be wise to start at the beginning and define the goals of and reason for the existence of this project.  With that well understood, a name can be chosen that reflects the project's purpose.

Frank.

[PhilR]

Wow!  There certainly seems to be a lot of enthusim here.  Not being at home is a bit of a handicap and I deliberately did not bring my laptop cos its a holiday  That means I don't have access to a whole load of useful stuff.  Of course my family thinks thats a good idea  

It seems to me there are several themes in this thread.  Firstly names.  It seems to me that names are not really that important if you are not interested in branding a product.  I like Geoff's 'UML Process'.  No confusion about what it is aye?

Then we have the issue of what we are trying to achive here.  I agree that the world already has more than enough processes.  If you want a comprehensive 'open' process take a look at The OPEN Process at http://www.donald-firesmith.com/

My feeling is that we want to create something specifically to support the use of EA.  This thread has been started in response to a number of posts asking for advice in that area.

One of the problems with RUP and other processes is simply that they that they are processes.  What I find more useful is to start with 'products' rather than 'activities'.

Here's a proposal based on some eXtreme Programming (XP) ideas:

The minimum level of design product required to create a working software application is plain old source code created using a text editor. (By the way this is the way the majority of developers work!)

We have one of the best visual UML modelling tools around in the shape of EA.  Now lets justify the creation of some additional UML work products using EA and THEN describe the process for creating them.

Why do I need a class diagram?  How detailed does it need to be?  Does the level of detail vary according to the type of project/application?  How does the detail evolve/change during each phase of the project? When is it a waste of time to develop a class diagram?  Do I need to keep the class diagram up to date once the application is in use?

It is my belief that these are the real issues of UML Modelling not the 'follow the yellow brick road' process approach.

I like being provocative on holiday  

Phil

[jaimeglz]

Hi Phil:

When you state that "The minimum level of design product required to create a working software application is plain old source code created using a text editor", you are simply following an old myth created by the Xtreme Programming crowd.

Let me give you an example of why this is wrong: I have participated in successful projects where the solution has consisted in using tools that empower the user to create their own reports. The most notorious of these tools are the spreadsheets that many of us use every day, but there have been many others, even in mainframes.  

So, even the code that Xtreme Programmers adore is not that essential!

I think that, in their legitimate and justified hatred of rigoristic "methodologies", the Xtreme Prog crowd did not bother to check what was usefull in the old models. See the discussion (and my small contribution) at http://c2.com/cgi/wiki?WaterFall

What has been wrong with so-called "methodologies" is the rigid belief that a single conventional road covers all projects. But, having said this, we do have a need to systematically take advantage of both theory and practice that have proved to be useful.

I think we can all agree that it is possible to finish many (not all) projects without systematic analysis and design. Oftentimes, the solution space is so close to the problem space that you can forego all kinds of formal steps; and then, there all sorts of corners you can cut... But the problem is: just how much are you affecting issues such as future maintenance, or the overall cost of not having done enough testing?

You cannot solve systematic software testing or the need for documentation just by "using the force" (even if your last name is Skywalker).

Jaime

[PhilR]

Jaime,

I am replying here as this thread will eventually get moved to the new forum.

Don't get me wrong.  I am deeply suspicious of some aspects of the XP philosophy.  However, they also make some good points at the same time.  My suggestion was more along the lines of taking a minimalist starting position (point taken about non procedural tools) and then justifying adding more products.

Phil.

[jaimeglz]

Hi Phil,

I also enjoy reading XP stuff, and have learned a good deal from it. That is the reason why I follow the Portland Patterns wiki-wiki pages (http://c2.com/cgi/wiki).

Your points have also been well taken. This is just a friendly (if a bit provocative) discussion!

Jaime

[fwoolz]

All,

Mebbe the XP M.O. of banging out source code using a text editor is one reason there is so much bad code out there!  Kinda like building a circuit without first developing a schematic...

(Just being provocative!)

Cheers,
FCW

PS: If you write code for the public or defense sectors, you simply don't (normally) have that option!!!

[mbc]

I did a google search, and somebody has already named something the "Enterprise Unified Process - EUP". I am not quite sure what it is - at the first glance it seems like he scissored all his graphics from the RUP, but I don't know. Take a look for yourself at:
http://www.ronin-intl.com/publications/unifiedProcess.html

Mikkel

[PhilR]

Your points have also been well taken. This is just a friendly (if a bit provocative) discussion!

Actualy I realise that that is one of the attractions of XP.  It is provocative and forces one to justify doing more analysis, modelling etc.

Remember the old Structured Analysis days when a 'small miracle' was required to get from DFDs to Structure Charts and thus to COBOL?  So many blindly following and achieving so little.

XP brashly says 'prove you need it'

Phil.

[PhilR]

Mebbe the XP M.O. of banging out source code using a text editor is one reason there is so much bad code out there!  Kinda like building a circuit without first developing a schematic...

I agree but there is a lot of foolish modelling as well.

Some things I have observed.

I once saw the same diagram consisting of three boxes being photocopied over and over again.  The boxes were then given different labels.

'What are you up to?' I enquired.  'Oh! The methodology says we have to do a Structured-Twiggle-Module-View for each Fooble and Feeble.  Since they are all identical this seemed the best way to do it'.

Another popular approach.

Spend half a year dumping 'stuff' into a CASE tool.  Look at the project schedule and panic.  Start coding and never look at the CASE tool stuff again.

And finally.

Spend a week debating whether the milk() operation belongs on the Cow class or the MilkingMachine class.  Best if you let the debate get so heated that people then have trouble working together constructively.

Phil.

[andyd]

Hi All,
I've read some of the text from the book by Kent Beck "XP Embrace change".
I found it quite interesting and think it is always good to come up with new ways of thinking.  
I may have mis-understood, but as I recall the idea was that the code was considered the documentation until the project got to the point that it was no-longer changing.  At that point the approach seemed to be quickly document everything so that its not forgotten.  As I said, that was my impression and I'm not trying to upset anyone with my statement.  I do believe that XP has some good points, particularly its focus on automated testing, and I seem pair programming a benefit.  However, design documentation IMHO can assist with other areas such as project estimation and impact analysis.  I also feel that it is easier to document something as you go along.
IMHO the ideal is somewhere in between XP and RUP, where artifacts are generated because they add direct value, in some way, to the project.  This may change according to the size and complexity of project.  Arguably RUP supports this in the fact that it is itself configurable.

Some examples of where I see value, particularly at analysis

EA Requirements (not UML but I still find it useful)
* provide tracability to use cases.
* Can generate a document for the customer for "sign off" to baseline requirments in the model.

Use cases
* hi level, help show customer scope of system
* detailed, assist with planning acceptance testing and estimation of effort
* Planning development iterations

Activity Diagrams
* elaboration of processes involved - still understood by customer

etc


Andy.
Andy.

[Tom_Andries]

If I'm not mistaken, Scott Ambler uses the name EUP for Enterprise Unified Process.