[Setools] Gjallar let's go

[goran at krampe.se]

Hi!

Hans N Beck <hnbeck at t-online.de> wrote:
> Hi Göran,
> 
> reading the "Gjallar Original Requirement and Desig" document, it  
> seems you have really seen commercial tools :-) Which ones ? (I've  
> worked 3 years with MKS Source Inegrity Server)

Well, in fact I am not an "expert" in this area, I have worked with
Jitterbug and Mantis. Then before we started Gjallar we read up on the
internet about perhaps 30 products, then looked closer at TrackStudio,
TeamTrack and JIRA.
 
> But I have also some questions :
> 
> >
> >> About Design
> >>
> >> 3/"Case linking" :  This mechanism is a manual decision (like  
> >> moving a ca=
> >> se in a new stage)  or we can define some rules ?
> >
> > Typically manual. At least today. One could imagine "auto linking" for
> > example based on keyword analysis like "this might be a similar case"
> > etc. I have seen at least one system with that functionality on the
> > market, can't recall which one it was right now.
> >
> > If you have ideas about rules - feel free to suggest. One thing we  
> > want
> > to add is of course to make it much easier to create "sub cases" -  
> > when
> > you are viewing an existing case it would be nice with a simple way of
> > creating a new case linked to the one you are viewing etc.
> 
> In this context, I would ask if this was a requirement of customer  
> that cases can not change type. Of course, that makes things easier.   

Well, it is not a requirement, rather a decision from me that avoiding
type changing makes things MUCH simpler and less error prone.
The current system suffers from undefined sitiuations due to type
changes.

> But it may happen, that  the result of walking through a process can  
> be a case which has another nature. Example: it often happens, that  
> someone has a idea how to improve a software. This is not more than a  
> notice. Later, the ideas get more concrete, algorithms or GUI details  
> are specified, and some day, you have even detailed requirements with  
> acceptence criteria (=test descriptions). So whats started as a  
> simple notice is a full fledged requirement at the end. At my work, I  
> always have modeled that with "level of detail" property, which was  
> changed by a special process (=workflow, from level 1 to 2 to 3  
> etc.), but the problem always was, that the result is really somthing  
> other.

I agree but I think that the best approach is to use linking and make it
simple to create new "sub" cases.

> In other words: Cases (also Bugs) can change, they have history, and  
> they can result in other type of case.
> 
> Another thing is splitting/merging of cases. For us, it occurs often  
> that Cases must be split, because a detailed analysis shows that a  
> bug concerns to completly different parts of a software, or that a  
> requirement is to trivial an must merged with others. Is there any  
> support ?

Not really - I again think that linking is a much better mechanism. A
very common scenario at the customer is support cases that literally
spawns a flurry of sub cases in the form of development. But that does
not mean that the support case disappears or changes type.

Merging of cases could be used when there are duplicate cases - but
linking seems to be just as easy and causes less confusion IMHO.

What we want to do is make linking very easy (currently it is slightly
awkward) and also add viewing mechanisms so that you for example can
view a case with all its linked cases in an "interweaved" manner showing
all events and notes in a chronological merged view.

> >> In your document you write "a case can !!!normally!!! not move  
> >> between pr=
> >> ocesses"
> >> Why "normally" ;-)?
> >
> > Because different Processes will have different Forms and different
> > workflows and validation etc. So if Process A has a Form X, which has
> > been added to case 12 - then if you move that case to Process B which
> > does not have that Form - then... well. :)
> 
> Is there exact one process for one case (1:1) ? Thats not full clear  
> to me. In the document, it is mentioned that different user groups  
> has different processes, but that this means necessarily 1:1 mapping  
> is not clear ;-)

A case belongs in one and one Process only. Currently you can't move
them at all, but as I said - moving could be allowed in the initial
phase when not much has happened to the case. Each Process is accessible
by a subset of the users. Each Process also "imports" a subset of users,
which typically is the same (the imported subset is the subset visible
by the Process). So if Process X only imports 10 users and those ten
have access to it (being imported and not have access would be quite
uncommon I think) and one of those users only has access to Process X
(and no other Processes) - then that user will not be aware that there
are other users in the system.

So each Process is highly isolated from the others. One scenario would
be having users from another organization that only are given access to
a single Process used by the company to interoperate with that
organization. Then those users should not see *anything* else than the
stuff imported in that Process.

So to summarize:

- A case belongs in one and one Process only.
- A user has access to n Processes. Each Process then decides internally
what permissions that user has in that Process.
- A Process imports "visible subsets" of all global objects, which
inclused users but also other things.

One fantasy scenario with having an imported user that does not have
access would be for example a Process that deals with personnel - the
managers have access to it and can for example assign users in roles or
a field in a case, without that user having access to the Process.
 
> Then a last question ? What about templates (for processes, for  
> reports, or for export - so for example make a open office document  
> from a set of Cases - very cool if available for the work with  
> customers :-))

Yes, in fact we have investigated how to be able to use the open
document format of open office in order to produce nice looking reports
etc. It is definitely doable.
 
> But anyway, can't wait to play with it :-)

I am working right now on "vacuuming" the sources and writing a guide
for the code. Might be able to publish later today/tonight.

regards, Göran