Author Topic: A first contribution on the PUP/EUP  (Read 4789 times)

Steve_Straley

  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #15 on: December 10, 2002, 10:41:56 am »
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
Steve Straley

kelly_sumrall

  • EA User
  • **
  • Posts: 73
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #16 on: December 10, 2002, 12:20:33 pm »
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.
Kelly Sumrall

Even though curiosity killed the cat, it still had eight lives left.

frank

  • EA User
  • **
  • Posts: 36
  • Karma: +0/-0
  • The very act of seeking sets something in motion to meet us
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #17 on: December 10, 2002, 01:07:02 pm »
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.
The very act of seeking sets something in motion to meet us; something
in the universe, or in the unconscious responds as if to an invitation.

- Jean Shinoda Bolen

Steve_Straley

  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #18 on: December 10, 2002, 01:53:06 pm »
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
Quote
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

PhilR

  • EA User
  • **
  • Posts: 87
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #19 on: December 11, 2002, 02:22:24 am »
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  :o

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

  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #20 on: December 11, 2002, 08:30:01 pm »
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.  ;D

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
« Last Edit: December 11, 2002, 08:33:16 pm by jaimeglz »

PhilR

  • EA User
  • **
  • Posts: 87
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #21 on: December 13, 2002, 12:52:10 am »
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

  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #22 on: December 16, 2002, 04:04:56 pm »
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

  • EA User
  • **
  • Posts: 435
  • Karma: +0/-0
  • We have met the enemy, and he is us.<Pogo, 1970>
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #23 on: December 16, 2002, 04:34:24 pm »
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!!!
Fred Woolsey
Interfleet Technology Inc.

Always be ready to laugh at yourself; that way, you beat everyone else to the punch.


mbc

  • EA User
  • **
  • Posts: 237
  • Karma: +1/-0
  • Embedded software developer
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #24 on: December 17, 2002, 01:29:08 am »
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

  • EA User
  • **
  • Posts: 87
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #25 on: December 17, 2002, 03:43:26 am »

Quote
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

  • EA User
  • **
  • Posts: 87
  • Karma: +0/-0
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #26 on: December 17, 2002, 03:53:45 am »
Quote
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

  • EA User
  • **
  • Posts: 24
  • Karma: +0/-0
  • Hi
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #27 on: December 17, 2002, 05:12:04 pm »
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

  • EA User
  • **
  • Posts: 28
  • Karma: +0/-0
  • Unlearn you must.
    • View Profile
Re: A first contribution on the PUP/EUP
« Reply #28 on: December 24, 2002, 05:52:57 am »
If I'm not mistaken, Scott Ambler uses the name EUP for Enterprise Unified Process.
Tom Andries
     Associate
Method Innovation