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

Here's a first contribution on Phil's Unified Process, the PUP. (Please note that it has also been proposed to be named the EUP, but we can decide on the name later).

This will be an open and free development process for software and general business engineering, with no other obligation for those who use it other than making an explicit reference to the source (and, if applicable, to the authors).

Insofar as the source is concerned, I suggest Sparx should set-up a special section of this «General» forum for this discussion, where we can have threads for diverse aspects and/or issues in methodology and project management.

I hope that volunteers will later compile, translate and copy-edit the contributions and agreements in a general documentation project (probably like The Linux Documentation Project at http://www.tldp.org/ ).

If accepted by other forum participants and by Sparx, we will embark on an ambitious project that requires an honest and sustained collaborative effort. So, in the next paragraphs, I'm suggesting a way to break-up this huge task into a reasonable and practical way of producing useful documentation.

But before we get into the matter, let me propose some rules:

1. All ideas are welcome, and references and short quotations from diverse sources are in order. But forum members should not include in their contributions copyrighted or proprietary material (except, of course, with written permission to do so for a free and open development process).

2. Parts --even substantial parts-- of existing public-domain or free process descriptions and documentation are welcome to be included, because they will make our task easier; but please make at least a summary motivation for it in the forum, and not just sweeping statements.

3. Debate is the best way to advance any issue where disagreement or contradiction arise; but net-etiquette and respect among participants are imperative if we are to gain clarity. Participants who incur in flaming others will be called to order and, if agreed by at least five other participants who have been in the forum for three or more months, postings that break net-etiquette can be branded as «offensive to the purposes of this forum».

First issue to deal with: the software life-cycle

The first thing we have to deal with is a generalized process for the lifecycle of a software product; in other words, with a software analysis, design, building, transition, maintenance and replacement/disposal process.

According to the terminology used in A Guide to the Project Management Body of Knowledge(or PMBOK Guide, by The Project Management Institute, 2000 Edition), what I am proposing to deal with first is called the «product oriented process», which «specifies and creates the project's product». This process is quite specific for each discipline (in our case, software development), and is one the two major categories of project processes. The other major category is the «project management process», which is applicable to most disciplines, and «describes, organizes and completes the work of the project». The latter includes (and this is my terminology) logistics, risk management, inter-personnel relationships, accounting/budget, quality and related issues, and I propose we postpone dealing with it until we have achieved at least a workable «light-weight» product oriented (analysis, design, building and transition) process.

The concrete expression of a product oriented process is that part of a Work Breakdown Structure (WBS) that contains a hierarchy of deliverable-oriented tasks pertaining to the software product's life-cycle.

If there is any enthusiasm out there for this effort, please respond to this thread, and I will begin my contributions to the PUP's WBS.

I am sitting in my brother's study looking out of the window at the pale northern sun, logged on to his expensive internet connection so this will be brief...

I agree with al your comments but would like to float a few suggestions.

1) We only address the <<product oriented process>> leaving people free to use whatever <<project management process>> they choose.

The PMBOK (or Prince2) culd be used as the basis of deciding what is product oriented and what is project oriented.

2) We adopt the SPEM (and RUP) concept of discipline workflows being different to project phases. Project phases are what PMBOK describes. Disciplines workflows are the logical workflows to create a work product.

Activities from a discipline workflow can be allocated to project phases in an unlimited number of ways.

3) We develop a product breakdown structure before we think about a work breakdown structure.

This will allow us to concentrate on what is required rather than what we do.

I see this could work by everyone submitting a rationale for a required workproduct to this forum.

4) We make the process agile by including explicit tailoring guidelines. Initially this would be a rationale for requiring/not requiring the work product.

Ideas?Phil.

PS Sorry about the over use of the word <<Rationale>> must be subliminal.

I don't know what exactly is being said here, but I am interested. I am self taught programmer and I am new to the design and management philosophies of software engineering, but I recognize it as a vital part of the process. I spend about 50+ hours a week developing (very little design) code for the project I am on. Many more hours trying to understand how I can use UML in my designs. No one at my company has any knowledge of UML, and everybody is too busy doing things tha way they have for years to learn. Therefore, our documentation is very sparse and not standard. I am very interested in getting involved in the xUP forum that is being proposed. I have often thought we need a special section just for that purpose. Count me in, even if all I can do is ask the dumb questions. I look forward to understanding that wich I currently don't understand.

Thanks for the interest Kelly. Yes, I am aware of the fact that we sound a bit pedantic on some of the points; but please bear with us, because we are entering into the terrain of methodologists (I guess you all know jokes on these fellows), and we'd rather be rigorous --including the use of what is accepted in academia as precise terminology-- or else we will be discredited from the very start.

In simple words, what Phil and I are advancing here is a proposal to develop a series of logical steps --including guidelines for each step-- that will enable the common developer and programmer to go through a software life-cycle without having to spend a ton of money and an innordinate amount of time. Also, we don't to worry about being legally sued for using some proprietary process without permission.

Very probably, PUP will be at first only recognised as something useful for the members of this forum; but, hopefully, some day it will be taken seriously, and companies like the one you are working on, and yourself, will be able to answer confidently to a prospect's or a customer's question on what formal process you are following.

The Unified Modelling Language (UML) has been a great step forward, because it provides with a widely accepted standard way of diagramming and specifying a software product (equivalent to the standards that dictate how to draw blue-prints and produce specifications in other engineering disciplines); but UML does not provide guidelines on where to begin, and what steps to follow in order to make the best of your development process. And what Phil is referring to by "activities from a discipline workflow" is exactly what we need in order to fulfil this need.

There is also a need for project management processes, but --for the moment, at least-- everyone will be free to use whatever management techniques that they feel suits them better.

Phill: I hope I have interpreted you correctly on «logical workflows to create a work product», and here is my rough proposal for the first (only the first) phase of a generalised workflow for our product oriented process:

1. Subject area processes and scope analysis

A business process overview is achieved by means of modelling a wide-angle view of the processes involved and their respective inputted and outputted products and/or services. These are represented in a process diagram.

Actors and/or «workers» (user, manager, subject-matter expert...) discovered during this phase are placed in the subject area and project org-chart (which can also be used as a project directory).

Real-world objects (customer, salesperson, product...) discovered during this phase are placed in a context diagram.

Existing technological architecture at the subject area is depicted in a deployment diagram.

Main goals and requirements discovered during this phase are depicted either in text, in matrix and/or requirement diagram form.

The main deliverable of this phase is the project scope document, that explains the scope of the project and presents the main results of the aforementioned tasks. This scope document also presents a rough project plan (or, if the project plan is provided separately, should point to documents where the plan is presented), with just enough detail to be able to proceed to the next stage.

If this phase is agreed, I will proceed to enumerate the next phases (analysis proper, design, building, transition...). After that, we can begin to describe tasks, deliverables, techniques, skills required and participants for each phase.

The start of this conversation is obviously of high interest to us and we will if others want, add whatever process is agreed upon into our EA-ReqPro project.

Having said that, a while ago I asked if anyone used Six Sigma. A quick reference to this (there are tons of it) can be seen at https://www.rathstrong.com/rs/pbuild/linkbuilder.cfm?selection=dn9.9.12. In that there are 5 tollgates or steps: Define, Measure, Analyze, Improve, and Control. The UP process fits nicely in this and is implemented as such here at GE. This may be of some interest depending on how broad of a scope this effort takes.

In addition, I would be more than happy to contribute to the formal document writing and/or white papers on whatever is discussed and agreed upon.

I agree Jamie that I think a new forum or section should be opened up for this effort complete, if possible, with upload section and the like.

Hi Guys,I'm certainly interested!I have a couple of suggestions, though not directly aimed at the process itself, at this time.1) RFC's seem to be standard for many Internet technologies, though I'm not sure that they must be confined to such. Maybe it could be a good launching platform for such an open process, as RFC's are review by many developers.

2) I'll assume that this is the case, but for completeness I'll suggest that an EA project be a good place to describe some of the workflows in the process. EAReqPro could, of course, generate the appropriate documents.

3) I feel that the process should easily scale according to the complexity (in terms of effort) of the project at hand.

I think what is now needed is to form a group that is willing to put in the effort to come up with this effort. And as a group we should start mulling around all of these concepts and put together a Vision / Mission statement so we can focus in on what the purpose is all about. Then we set an agenda and set out to define what it is we've stated in the Vision/Mission statement.

Im more than happy to organise a special forum section for this activity. I will try and get it set up in the next day or two for you - probably under the name "UML Process" in the General section of our board - (the name was the first that came to mind - let me know if there are other preferences).

I will also look at setting up some kind of upload area - or public FTP capability. There will have to be some quotas applied, but in general this should not be a problem.

Thanks for looking into setting that up. If your site can't do it, I'll be more than happy to set one up as well.

Jason, thanks for the kind words on the Tutorial. I think once we get the forum set up and the special upload section, we can start to see who wants to participate, set up concrete Vision/Mission statements, and begin to publish a TON of White Papers. I'll do whatever you guys want to help this process.

I hope to turn my attention back to the Tutorial once the current project is out and the next one is initiated. I'd be more than happy to do the writing, formatting, whatever... Just let me know..

Personally, if we're going to do this to have an outcome that benefits EA, and we're talking more of a Unified Process, let's use something like EA-UP or SUP for Sparx. I think "UML Process" is limited in scope and concept compared to UP or up to now, PUP... just a thought. If we're fighting the RUP battle, let's use something similar that managers can relate to and we can piggy back on the RUP marketing efforts. Just a thought...

Steve

Quote

Hello everyone,

Im more than happy to organise a special forum section for this activity. I will try and get it set up in the next day or two for you - probably under the name "UML Process" in the General section of our board - (the name was the first that came to mind - let me know if there are other preferences).

Guys,Don't get me wrong, I have nothing bad to say about EA or Sparx, but IMHO it is better to name the process in its own right without associating it directly with a product or company. There is a possible danger that the process could be seen as a way of marketing a particular tool, which could impact on its credibility. Of course the EA tools can leverage from its existence in supporting development with that process.I guess we could always nominate names and e-vote for one. I don't really mind (the main thing is to have the process, whatever it is called), but here are a couple more suggestions.

Hi Steve,It was a general statement and wasn't directed at RUP, as such.

However, it could be that they can get away with it as the guys that started all this unified stuff work there.

We actually looked at using RUP, completed the training etc, but considered it too much to invest in, as we could see the probability that an updated process would be released each year, requiring further investment higher than we were willing to pay at the time.

However, the ideal that many companies could use a common development process is something that does appeal to me. It could potentially make life easier for contractors, customers and others if everyone talks the same language(UML) and develops in the same way (*UP). Though it would be good to be able to select elements of the process according to the size of the project under development, cutting down overhead on smaller projects, but making sure there is enough on larger and more risky projects (IMHO).