prime-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Prime-dev] RE: PRiMe vision doc


From: Gerry Kirk
Subject: [Prime-dev] RE: PRiMe vision doc
Date: Sun, 10 Mar 2002 12:09:23 +0600 (BDT)

Morley,

Great feeback. Note I am replying on the dev list - time to put it into
action!

Good points about use case vs. services. My approach mirrors that of
Michel's back at EQUIST, when I was helping him with vision docs. He had
described a system with high-level services, and then in the use case
scenarios referred to these services. Note that services do not
necessarily  become software components - they are merely abstractions of
the system.

If I was to do it again, I would take the approach you mention, focusing
on  the primary use cases. In the overall diagram then, would there be a
circle  for each use case, with input arrows from some roles/actors and
output  arrows to some roles/actors? How does one summarize all of the use
cases  into one diagram for clarity?

> 3. You left the Administrator out of the System Overview use case
diagram, and there is no use case for administration. I'm guessing this was
intentional, either because you were running out of real estate in the
diagram, or because you wanted to omit it for the sake of clarity. Is this
correct?
>
You are correct on both accounts. The work of the administrator is more
predictable and less of a priority to flesh out the details at the moment.

> 4. You refer to 'Role's throughout the document. The term I have
typically seen in UML circles is 'Actor'. I personally prefer 'Role', but
in general you have to decide how closely you want to follow standards, ie.
UML in this case. A general rule of thumb I have seen is 'Stick to the
standard unless you have a good reason not to.'
>
In the documentation for Poseidon, they mention Actors are also referred to
as Roles. Actor is certainly more common, and the app itself uses Actor and
not Role. So, there must be some support for it. I've already introduced
the term to people here, so I'll stick with it for now.

> 5. You have a slide that explains what a role is. You define it as types
of people or organizations that interact with the system. In UML, Actors
can also be other systems that will interact with the system being modeled.
Are there any such systems in this case? E.g. will financial information be
pulled from an accounting system? Could this system be integrated with the
MCC main Web site in any way? Food for thought...
>
Presently, I am not aware of any other systems that would interact with
prime. Good question, though.

> 6. The 'Data Entry Typist' is shown as participating in the 'Partner
Profiler' service, but the slide describing the role has a restriction
of 'cannot change partner profile def'n'. If the role has this
> restriction, how does it participate in the use case? Is it likely that
managers themselves will use the system directly to manage the partner
profiles? Or would it be delegated to an analyst, or the admin?
>
Yes, there is a contradiction there. A lot of this are my own suggestions
so far. I've assembled a team, consisting of 2 Managers, 1 Researcher, 1
Data Collector and 1 Data Entry Typist. Together, we'll look at use cases
in more detail, and determine who will do what, and what restrictions need
to be there.

A more general question I have is, what details are required in an
Actor/Role definition? I have a basic description, participation in
tasks/use cases, and in one case I have suggested a security constraint.
There can also be associations between actors. Anything else?

> 7. Related to 1 above, typically instead of having slides that describe
system services and the data managed by each service, you would instead
have slides that describe at a high level the steps involved in each use
case. For example, a high level 'Manage Partners' use case might look
something like:
>
> i) The user defines information that is used to identify a Partner.
ii) The user defines measures that are used to track the status of a
Partner.
> iii) The user defines events and event data that affect the status of a
Partner.
> iv) The user creates a new Partner profile and enters the required
information as defined in steps i) to iii).
> v) The user modifies an existing Partner profile.
> vi) The user disables an existing Partner profile.
>
All this is considered one use case? It looks like a number of use cases to
me. These are all the activities related to managing partner profile data
and status.

Let me clarify one thing that may be confusing you. The first step in
working with partner data is creating a partner definition. Once a
definition is in place, then an actual partner profile can be created.
First, I define what type of info I want to collect. Next, I can create a
new partner, i.e. an instance of a partner and enter that information
immediately, according to the definition I have created.

Perhaps you already understand this. Looking at your list above, the steps
i), ii) and iii) are creating the partner definition. Steps iv), v) and vi)
are for maintaining the profile of a specific partner.

> 8. Your description of the 'Partnership Profiler' service looks more like
a 'Project Profiler' service. You talk about how a project is defined
(identity, profile data to monitor), but you don't talk about managing the
relationship between a partner and a project, ie. a Partnership. You could
either add this in here, or perhaps separate them into 'Manage Projects',
and 'Manage Partnerships' use cases.

I used project as an example, because that is how the majority of work is
done between MCCB and farm families. There are other examples of
partnership activities I did not document. For instance, MCCB workers visit
families and do tests to check the health of the family, especially
children and the mother. I would see that as another activity that would be
recorded, the results of which affect health profile data.

Perhaps 'Partnership Profiler' should read 'Partnership Activity Profiler'.
It facilitates the definition of activities done in partnership, so that
later activities can be recorded and evaluated. An activity could not be
entered into the system that does not yet have a definition. I might define
an activity as a training course, which has a name, number of classes,
pass/fail/incomplete status and so on. I would define the impact on partner
profile data, for example, number of trainings received.

>
> 9. Some of the features that you talk about near the end of the
> presentation could be captured in the use cases. Eg. being able to easily
enter many events for a partnership, etc.
>
So, at this point, would all constraints on the system be captured in the
use cases? What I'm trying to do at this point is to start defining the
scope of the system. Is there a better way to do that?

> Phew! Ok that might look like a lot, but basically I think you have a lot
of the required information. I realize it could be a lot of work to act on
some of my suggestions, and in some cases the benefit may not be worth the
effort, so don't feel as though you have any obligation to do so.
>
Great effort on your part, Morley. The feedback is top notch. Hope your
other work is coming along well. How did those deliveries go?

- Gerry

-- 
IT Specialist
MCC
Bangladesh
-- "When a ball dreams... it dreams it's a Frisbee"






reply via email to

[Prev in Thread] Current Thread [Next in Thread]