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.
Jaime Gonzalez
