agile/xp question (formal analysis)

From: AndyW (foo__at_bar_no_email.com)
Date: 11/03/04 

Date: Thu, 04 Nov 2004 10:10:48 +1200

I have a question on some agile/xp process.

[please read the whole thing before replying - in otherwords dont
reply to each para - just to the whole post.- the first part is just
background to the question which is at the end - i dont want a
critique on the background.)

As many would know I'm a proponent of 'adaptive mini-waterfall' to
give its full title - mainly in the large project space.

Was talking with someone about ballpark estimates today which then led
into a chat on problem space analysis - which got me thinking that
i've pretty much never seen a full blown discussion on the subject
from the agile/xp camp.

Talking to another collegue about it we formed the opinion that the
techniques of old dont seem to be taught any more - it seems the newer
developers seem to think that companies have someone - such as a BA or
a manager or even a developer who 'knows' the problem space.

It seems this 'knowlegable' person learns on the job from a 'customer'
telling them how their business works, and then makes educated guesses
as to what the solution may be without having any formal understanding
of what the actual problem may be. (this is an opinion not a fact)

As a bit of a background for what I am getting at:-

'Problem Space Analysis' or more commonly known in the 'old days' as
Analysis was a technique where you formally analysed the existing
'system' to find out how it worked. 'System' applies to the whole
process - manual, functional, non-functional and electronic -
including external factors.

Once you had a model of how the existing system worked (and there is
always an existing system - even for new stuff) - you then 'designed'
improvements to that system (either manual or electronic) to make it
more efficient. The 'design' used here is not presenting a solution
- its just making sure that you have both the original model presented
by the analysis, and a more efficient model that can be used to reduce
the scope of any potential problem.

At the end of this - you had a system that you understood well enough
to be able to ask the customer exactly what the problem was.
Sometimes - taking a system and changing some of the manual process to
make them more efficient was often enough to make the problem 'go
away'.

This is analysis and design of the problem space. The next stage is
analysis and design of the solution space - that is more commonly the
process that is adopted now. Analysis at this stage becomes a more
formal process of defining the requirements presented by the problem
(a formal technique of asking the customer what the problem is) and
design - creating a solution to the problem posed by the requirements.

The important reasons for problem space analysis is that it makes sure
that your domain experts (or 'knowlegable' person) actually knows what
is really happening - rather than relying on a customers perception of
what they think is happening, or even their own most likely 'out of
date' perception of the environment.

It also ensures that you understand and can examine the customers
desciption of the problem to ensure that it is actually a valid
problem - and not just a preception of a problem. Since many
customers do not actually know how their own business operates - you
often have to work it out and explain it to them before they can
articulate what it is they want to achieve.

Its primary benefit is that its a formal process that allows you to
tackle problems you originally know nothing about.

My question is - i'm pretty familiar with Agile/XPs methods for
working in the solution space - but there seems to be no visible
process for working in the problem space.

Can someone explain what formal documented techniques (possible with
links) exist for a formal process of modelling the 'problem space'.

Just to clarify - I want to know how to model the existing system and
not the proposed solution and what the process is for defining the
problem that needs to be solved.

Also, by 'system' I dont mean an electronic program - but the whole
system including manual, functional and non-functional parts and
electronic.

Cheers
Andy

Relevant Pages

  • Re: defining quality of OOA and OOD models
    ... must be done) while an OOA model describes the solution (How it should ... Using the term "analysis" to mean "design" should, if nothing else, not ... bridge the chasm between customer problem spaces and the computing ... the problem space abstraction that dominates OOA is ...
    (comp.object)
  • Re: Why is OO popular?
    ... >> confirm the design and solution, thing works in beta, you roll it out, ... but then the customer finds a need to track ... >enough about the problem space to be confident there would never be ... >so that horse properties are relevant, one doesn't deal with that by ...
    (comp.object)
  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... That's what problem space abstraction provides. ... customer: the one who specifies the requirements for the software ... my planned alterations to the compiler core should be able to ... one configured it with an external BNF description of the language to be ...
    (comp.object)
  • Re: distorted model! do i need patterns or something!?
    ... In the problem space things like Hotel, Section, and Room are important entities and they have well-defined relationships. ... That allows quite generic code to be written for relationship implementation, instantiation, and navigation that is very aspect-like. ... the customer doesn't like change any more that software developers do. ...
    (comp.software.patterns)
  • Re: Creating a "toy" OO/AO language...
    ... That just doesn't seem like a reasonable abstraction of the problem space when the unit, the meter, and the tenant haven't moved and the service was uninterrupted. ... For one thing utilities usually have ridiculously complex classification schemes for the services (residential service to an over-65 customer with veteran status on the wrong side of the tracks in a unit with R45 insulation). ... name one such methodology outside OOA/D/P. ... closures play together well with other FP construction elements. ...
    (comp.object)