I have been away from this forum for some time, doing other things. One of these is to start writing down my concepts for Agile Analysis. These techniques span all phases in the life cycle of an xUP-like development. This is the first of 4 sections of my Web site, it just covers the Inception Phase.
I propose a few fairly radical concepts, which I believe make sense; at least they have worked for me in the past. Now I have to formalise them, I need to check how other people feel about them, and so am seeking feedback, before I rush forward into the next three sections.
The web site is
I cannot copy 14 web pages into this forum, but hope that you guys wont mind having a look at it. I can outline the concepts:
1. Between the business and the developer, you need one layer of description, so that there is something to add changes to etc. Specs are normally used for this. This is the minimum you can work with on any project of size.
2. I propose to use a single layer of precise UML. There will be three sections:
a) Non-functional Spec(Software)- Not UML but essential
b) Use Case Diagrams with descriptions of the diagram contents, but NO (or very little) description of the use cases.
c) Business Class Diagrams, containing the Business Rules. (Global Business Rules go in the Non-functional and each use case is almost an intermediate business rule in its own right. The ones on the classes are the more normal ones, and generally provide the rules for validation.)
I assert that it is possible to write every thing that is in a Spec into such a layer of UML.
3. During 'Inception', Only identify the System Use cases, and group them into 'Services'. A Service is drawn as one UC Diagram. Services are also represented as Packages in a Package Diagram and have strict dependencies, such that it is obvious which order they need to be created in from a technical point of view. The Users can then add additional priorities, but they must NOT conflict with the technical ones. This prioritises the work to be done ready for scoping.
4. The other task during 'Inception' is to get a good estimate of the potential costs. In this system, we estimate not just costs, but also uncertainties. The stats are crude, but the maths is always consistent, making comparisions and changes meaningful.
5. With these two schemes, and very little work, we can derive costings for various combinations of services. This helps us all:
a) The users can see the probability of these sets of services being completed, allowing better decisions on finance etc.
b) The Estimator has more confidence in his own estimates, because in some ways they are 'self checking'.
c) Decisions are explicity made concerning what is costed; 50:50 or near certainty.
d) The costs can be expressed in Agile ways:
"List A of services can be produced with 80%(say) certanty for cost X
If we fail to get List A complete, then List A minus service Z will have a 93% probability of being produced.
There is a 30% probability that we will get the whole list done and an extra service Y."
d) The origins of the elements of the costing are clearly distinguished.
e) If further study is needed to find ways of reducing costs, this system clearly identifies the most profitable paths.
f) I will show, in further sections yet to be written, that this also makes monitoring very much more accurate for virtually no more work.
I'm posting this in two threads, because I believe that the UML people will be interested in the 'Spec' and I believe that the management people will be interested in the 'costing' aspects.
Gil Rooke
I propose a few fairly radical concepts, which I believe make sense; at least they have worked for me in the past. Now I have to formalise them, I need to check how other people feel about them, and so am seeking feedback, before I rush forward into the next three sections.
The web site is
I cannot copy 14 web pages into this forum, but hope that you guys wont mind having a look at it. I can outline the concepts:
1. Between the business and the developer, you need one layer of description, so that there is something to add changes to etc. Specs are normally used for this. This is the minimum you can work with on any project of size.
2. I propose to use a single layer of precise UML. There will be three sections:
a) Non-functional Spec(Software)- Not UML but essential
b) Use Case Diagrams with descriptions of the diagram contents, but NO (or very little) description of the use cases.
c) Business Class Diagrams, containing the Business Rules. (Global Business Rules go in the Non-functional and each use case is almost an intermediate business rule in its own right. The ones on the classes are the more normal ones, and generally provide the rules for validation.)
I assert that it is possible to write every thing that is in a Spec into such a layer of UML.
3. During 'Inception', Only identify the System Use cases, and group them into 'Services'. A Service is drawn as one UC Diagram. Services are also represented as Packages in a Package Diagram and have strict dependencies, such that it is obvious which order they need to be created in from a technical point of view. The Users can then add additional priorities, but they must NOT conflict with the technical ones. This prioritises the work to be done ready for scoping.
4. The other task during 'Inception' is to get a good estimate of the potential costs. In this system, we estimate not just costs, but also uncertainties. The stats are crude, but the maths is always consistent, making comparisions and changes meaningful.
5. With these two schemes, and very little work, we can derive costings for various combinations of services. This helps us all:
a) The users can see the probability of these sets of services being completed, allowing better decisions on finance etc.
b) The Estimator has more confidence in his own estimates, because in some ways they are 'self checking'.
c) Decisions are explicity made concerning what is costed; 50:50 or near certainty.
d) The costs can be expressed in Agile ways:
"List A of services can be produced with 80%(say) certanty for cost X
If we fail to get List A complete, then List A minus service Z will have a 93% probability of being produced.
There is a 30% probability that we will get the whole list done and an extra service Y."
d) The origins of the elements of the costing are clearly distinguished.
e) If further study is needed to find ways of reducing costs, this system clearly identifies the most profitable paths.
f) I will show, in further sections yet to be written, that this also makes monitoring very much more accurate for virtually no more work.
I'm posting this in two threads, because I believe that the UML people will be interested in the 'Spec' and I believe that the management people will be interested in the 'costing' aspects.
Gil Rooke