Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jaimeglz

Pages: 1 ... 9 10 [11]
151
Uml Process / Re: USE CASE Cookbook
« on: December 24, 2002, 11:07:48 am »
Hi Tim,

Some pious cyber-spirit transformed Alistair C-o-c-k-b-u-r-n's (pronounced Co-burn) name in your posting. The same funny change happened when in this same frorum I recommended a link to one of Alistair's writings.

Hi AltatemTC,

There's a Sept. 19 thread with a quick answer to your question, "What do I do when?". See:

http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=general&action=display&num=1032446412

Be aware that the answer I gave then was very general, and the purpose of this forum is precisely to collectively work out questions on details of the software development process.

For a "light-weight" and very comprehensible view on the software development process, see Martin Fowler's "UML Distilled" (Addison Wesely). And probably the most recognized work is Jacoboson, Buch and Rumbaugh's 450 page "The Unified Software Development Process" (also published by Addison Wesley).

I'm sending a Powerpoint slide to your EMail on the general path I use. (For lack of time, I have not finished setting up a proper web page for this material.)

Everybody,

Have a merry, merry Xmas!

Jaime

152
Uml Process / Re: USE CASE Cookbook
« on: December 15, 2002, 09:12:28 pm »
Hi all!

I agree with Steve, and give me a chance to convince you why I've found use cases to be so useful, and why I consider the technique to be one the greatest contributions on systems analysis, design and construction.

1. Use cases try to depict a sequence a events (either "as is" or "projected system") that produces a useful product or service. So, first of all, you are identifying the "useful product or service" as your project's real objective. During the project, I have to keep repeating to myself: "Listen, burrito, it's the useful service or product that you're after, not the technology or the nice tools you're using".

2. They present the sequence events from the point of view of the user. This is of high value, because they directly point to the need of a good user interface, and good user-friendly design. "Listen... this is for the customer/user, not for the programmer...."

3. They bring the nice and clear side of object reuse to the fore, because they help break-up your system (current or projected) into meaningful sequences. Many of these sequences can be reused by other use cases via <<include>>, <<extend>> or generalization/inheritance relationships. (There are postings on this in the General EA forum: search for "extend".) You can save lots and lots of time by taking advantage of this.

4. They help in project planning, by assigning resources to the different use cases; for instance, "Developer 1, who's strong on user interface, should take care of the portal opening..; Developer 2, who's a real ace in RDBMS, should take care of the transactional use cases", and so forth...

5. The use case model is the best way I know of delineating project scope and helping you break-up a big project into stages.

6. Use cases are the way I've found to drive the next stage of your modeling, because they can be directly mapped to sequence diagrams; and these sequence diagrams are a sure-shot way of detecting the classes for your first-cut class model (which will evolve into both your user interface model and your static class or database model).

7. They are great aides for your technical architecture alternatives discussions. The first-cut answer to the question "Should I use a package or custom development?" can be answered by mapping the proposed package components to use case events.

8. Use cases can easily be derived into test scripts.

And there are many more reasons, but I hope these suffice for the moment.

ComputerWorld Mexico published in 1998 a  somewhat long article I wrote on use cases, and I'll gladly submit a more updated version of it as a contribution to the cook-book (it is my intelectual property, so no problem with copyrights). It develops, step by step, a simple use case model. The only problem is that it is in Spanish, but I'll EMail it to anybody who volunteers to translate it.

Also, I would have no gripes if the article is torn apart and re-made (or whatever) into the core of the cook-book.

Finally, having praised use cases, let me now make a criticism: the user case model is not user-friendly, and you will not communicate your ideas to senior management with a use case model. To communicate with users and senior management, you should use a process model (see EA's document on process modeling).

Jaime

153
Uml Process / Re: Use Case Alternatives
« on: February 17, 2003, 05:32:45 pm »
Hi Lar,

You have made a very valid point. However, let me try to remark on something that can save us all time and avoid redundancy in many (if not all) situations:

If you have no urgency to quickly write and present your scenario in text format, you can make a sequence diagram, from which you can automatically generate the corresponding event list. The latter, in my opinon, is just as clear and probably crisper than the text description. Example: customer contacts salesperson; customer inquires about product; salesperson determines availability of product...

The great advantage of doing things this way is that you have a single point for modifying your scenario in the model (namely, your sequence diagram), and an automatic function (HTML or RTF documentation gen) for generating and regenerating your text description.

Otherwise, if you make a text description, and then make a sequence or activity diagram from that scenario, you have two places where you have to introduce modifications in your model: your text description AND your diagrams.

Of course, lets emphasize once again that this is just an exchange of ideas and experiences, and that the most efficient way to do things in certain circumstances is not the the best or prefferable way of doing them in other places.

Jaime

154
Uml Process / Re: Use Case Alternatives
« on: February 14, 2003, 08:18:48 pm »
Hi all,

What we are dealing with here is the fundamental question of model granularity: Just how detailed do you need/want your model to be?

IMHO, granularity does not matter that much in the use case description as such, though it is critical in the next level, which is detailed in interaction diagrams, activity diagrams, state machines, deployment...

What matters most to me in use cases is:

1. To discover the most general path. Example of a "most general" use case: I pick up the phone, wait for the dialing tone, dial, receive the "ringing" tone, someone answers at the other end of the line... [until] we finish our conversation, and hang up. If I solve that general use case successfully, I have solved a very high percentage of a useful phone system, even though there are tons of exceptions, error conditions, useful add-ons, and so forth, which are not covered by it.

2. To discover re-usable sequences. Examples: log-on, log-off, send update to accounting system...

My experience is that the most efficient way to detail use cases or scenarios is by means of sequence diagrams (though I don't deny the usefulness of other types of UML artifacts). In other words, I derive sequnces directly from use cases. Why go through all those text details for scenarios, when you are going to model them in sequence diagrams (or, if you wish, in activity diagrams or state machines)?

EA can automatically tansform your sequence diagrams into event lists, either by means of "Toggle report view" in the menu bar, or by generating your HTML or RTF documentation. So why bother in writing detailed scenarios? (The only reason that occurs to me is because another modeler is going to do the blow-by-blow interaction modeling, and you want to specify what this other modeler is going to do.)

Then: How much detail should go into interaction diagrams?
In theory, a solid model should go down to the CRUD level (create, read, update, delete data items). In practice, however, you would get yourself bogged down if you try that level of detail, and your project will become prohibitively expensive, or worse...

Of course, there are situations in which you have to plan to go to that kind of level, because that particular piece of the system is just so critical that you want to have a high-precision model before you commit to code. But that is not the usual situation you will have in most commercial systems development.

So, I will go along with Fred in "that you should go down as far as you think you'd have to go for the audience of your use case to be satisfied with the implementation."

Do you have a pretty good communication with the programming staff, or you are doing the programming yourself? Then, you don't need to go to the CRUD level: model just enough so that all requirements and important conditions are covered.

Let me use this opportunity to stress that use cases are not the best way to communicate general models for users: process models should be used for that purpose.

I hope this helps, though I would agree that we have barely scratched the topic.

Jaime Gonzalez

155
Uml Process / Re: Thesis and UML
« on: December 12, 2002, 07:02:08 am »
Hi Fred,

I suggest you submit short postings to this forum on your theses' project roadmap, what techniques you are using, how does it relate to EA (or the CASE tool you are using), issues you encounter, how much time did each one of your tasks take... That way, we will all benefit from your experience.

Academic rules generally do not permit the circulation of a theses, except for those appointed to review it; but there is nothing wrong in discussing the issues (not the theses itself) in a public forum.

Jaime

156
Uml Process / Re: A first contribution on the PUP/EUP
« 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

157
Uml Process / Re: A first contribution on the PUP/EUP
« 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

158
Uml Process / Re: A first contribution on the PUP/EUP
« on: December 09, 2002, 09:32:48 am »
Hi Phil,
Hi Kelly,

I agree on all of Phil's proposals.

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.

Jaime

159
Uml Process / A first contribution on the PUP/EUP
« on: December 07, 2002, 09:28:50 pm »
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

160
Uml Process / Project scope document: Why I have found it useful
« on: December 15, 2002, 10:16:48 pm »
I want to share a technique that I learned from datawarehousing experiences, and have been using successfully for the last two years: the project scope document.

In a nutshell, the idea is to produce, at the very early stages of the project and within a relatively short period of time, a document that will be agreed upon by the sponsor and all other key project participants, and that clearly delineates the scope of the project.

The main value of this document is to mitigate scope-creep.

The project scope document has essentially the same structure as the technical-description section of a project proposal; and, indeed, the technical section of a proposal can be considered as a scoping document. But I would like to stress that "technical section of a proposal" is a limited concept in comparison to the sort of document I'm talking about here.


Components of the project scope document

The scope document I will describe here is based on real proposals and/or scoping documents intended for two to six-month projects; so keep in mind that I'm using "light-weight" examples, which are ideal to explain the main ideas, but that do not cover the needs of either very short or very large projects.  Almost needless to say, not all sections of the example described here are necessary for each and every project.

Executive summary
For "light-weight" projects, I suggest to keep it less than one-page long.

Introduction
"On October 9, 2002, XCo, SA invited TYSG, SA to prepare a proposal for the development of a Sales Analysis Decision-Support System. The document that follows has been prepared in response to the aforementioned invitation. In this proposal, we outline a roadmap intended to fulfill XCo's request."

Scope
"1. The scope of this project is constrained to implementing a Sales Analysis Data Mart (referred to henceforward as «the data mart»).

"2...."

Links to the overall organization strategy
"The system is needed critically for driving revenue and forecasting plan management". It is usually a very short section, but it is one of the most challenging parts of the document.

Project Goals
"Based on the scope outlined, the goals of this project can be stated as follows:

"1. Ensure that existing source data will be usable in a data mart. This will be achieved by conducting a data quality survey of XCo sales information, as it exists in its source systems.

"2. Implement a technical solution for the extraction, transformation and loading (ETL) of..."

Objectives
"1. Project personnel will avoid unnecessary distractions to users and executives by initially examining all relevant, existing material...

Assumptions
"1. Senior management will remain committed to the goals and objectives for the duration of this effort..."

Critical success factors
"1. Strong, visible management support for the project...

Constraints
"1. The project will be developed within estimated cost and time..."

Security Issues and Concerns
"TYSG strongly recommends that worldwide sales data should be encrypted before it is transmission from one subsidiary to another..."

Acceptance Criteria
"The system must prove its capacity to accurately store and retrieve one month of the information needed to answer the business question..."

Processes
If time allows it, present a business process overview. You can use this model to further explain and illustrate the project's scope. For general guidelines on this type of diagrams see Sparx Systems' "The Business Process Model". For an in-depth discussion, see Chapter 3 in Erikssonn-Penker: "Business Modeling with UML".

Business question
This section applies only to datawarehousing projects: "What are the organization's sales, in terms of quantity (in kilograms) and extended price (in local currency, Euros and US Dollars), grouped or broken down according to the following criteria: Customer, Product..."

Domain model
If time allows it, include a small diagram of real-world objects (customer, salesperson, product...) in your target area, and their relationships. The simplest form of a domain model is a non-attributed class diagram.

"Real-world" objects can be discovered by carrying out a quick use-case/scenario modeling session (and I will present a future contribution on this).

Technical architecture (and/or technical architecture alternatives)
Existing and/or alternative technological architecture at the subject area is depicted in a deployment diagram.

Project Roadmap
"The detailed project roadmap can be found in the attached Gantt charts and in the ROUTE01.XLS file provided in ...

Project Roles and Development Team
Actors and/or «workers» (user, manager, subject-matter expert...) are placed in the project org-chart (which can also be used as a project directory).

If there are open issues, include a section with short descriptions of these.

For elegance, and if time allows it, create a section on Glossary and Acronyms

Finally, if needed, create a section on Bibliography and References: "The classical book on data marts is Ralph Kimball's The Datawarehouse Toolkit (Wiley & Sons, New York)."

A good project scope document is never produced during a first iteration; so do plan for a total re-do of your first draft.

If you have not written formal statements of work, or technical proposals, your first try at a project scope document will take about a week (including interviews and/or Joint Application Development sessions) for a "light-weight" project. This time will be substantially reduced in subsequent scoping efforts, once you can use a good previous scope document as a template; but keep in mind that you still have to do the interviews and/or JAD sessions.  

Most components of the scope document map very nicely to tasks and deliverables in the next project stages; for instance, the domain model derives directly into one or several class diagrams.

Also, the scope document is very useful when you find yourself in a situation in which the project is directly assigned, without contract or formal documentation. If this is the case, the first task in the project should be to draft the project scope and have it approved by the project's sponsors.

You're in a real hurry and don't want to loose time drafting a formal document? Then just conduct a session with the project sponsor and get agreement on the main points mentioned above; but I would suggest for someone to tactfully take good notes of the session's agreements.

Jaime Gonzalez

161
Uml Process / Mission/Vision statement
« on: December 11, 2002, 09:39:40 am »
Here's a proposal for a preliminary general mision/vision of this forum, as well as on its relationship to the UML. I hope I have reflected the variety of views that have been expressed on this topic.

Mission:
The open UML Unified Process forum intends first of all to provide a workspace for discussion and orientation on the software product lifecycle; that is to say, on issues pertaining to the general process of analysis, design, construction, transition and replacement/disposal of software products.

(Forum participants with specific questions on the use of  existing software tools are advised to post in the appropriate forums.)

Vision:
In the long run, this forum is intended as a means to orient in the usage of existing open software development processes, and to the development of new ideas and contributions in the field of software product processes.

The forum is considered "open", because it will try to draw from the widest range of both formal and informal experiences in software development. Whenever no legal limitations or liabilities are found, the open Unified Process will highlight and help propagate other software or business engineering processes' best-practices and ideas.

The forum is intended to be independent of any product or tool (though we must gratefully acknowledge Sparx Systems' hosting this discussion in its forum).

The open Unified Process and UML
The Unified Modeling Language (UML) has been a great step forward, because it provides a widely accepted standard for diagramming and specifying a software product; but the UML does not provide guidelines on where to begin, and what steps to follow in a software development process. This forum intends to contribute in bridging this gap.

Jaime Gonzalez

162
Uml Process / Re: General rules for participating in this forum
« on: December 12, 2002, 06:53:27 am »
Guess you're right, Steve: the most important issue right now is making this forum interesting... We certainly hope to get enough participants so as to make it tempting for trollers! ;)

Jaime

163
Uml Process / Re: General rules for participating in this forum
« on: December 11, 2002, 09:54:05 am »
Hi Steve,

There's a misunderstanding: I'm not proposing to banish anything. What I'm proposing is that we have a simple way of expressing ourselves when someone is playing way-off side. I've participated in other forums, and have seen the enormous distraction of resources and attention because of trolling and flaming practices. Instead of loosing our cool, what we should do is simply get the opinion of five participants and make a posting saying that we find the tone or the content offensive to the purposes of this forum.

Geoff's moderation would be great, but he is too busy to have to worry about someone comming in and distrtacting our forum with some silly trolling prases.

If you insist, however, I will simpley remove the posting.

Jaime

164
Uml Process / General rules for participating in this forum
« on: December 11, 2002, 08:06:48 am »
Here's a proposal for general rules for all participants in this forum (drawn form my Dec. 7th proposal in the General Discussion forum).

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».

Needless to say, other ideas and contributions on this topic are welcome.

Jaime Gonzalez

Pages: 1 ... 9 10 [11]