[
Lists Home |
Date Index |
Thread Index
]
We are RFP-driven, and this is reasonably analogous to
use-case driving. Because our resources are always
limited, we do not add modules (think level of QBE-forms)
to the system until we have seen them clearly required
in some number of RFPs and so can establish that the
customer base at large wants this functionality. Then
we have to decide if it is strategic for our system
to have this or if it is better to open an API for
systems of that class so they can buy best-of-breed.
Once the decision is made to build, then we take
the sets of requirements of the active customers
and attempt to generalize these into a single design
that can meet their requirements. This is where
the use cases are both helpful and dangerous. A
customer will have a fixed idea for what they
want to see, and they will vary by customer. The
challenge is to provide functionality that they
instantly recognize as applicable to their problem
and yet which applies to all of their problems.
That is the art of systems design and it isn't
easy and it takes a practiced team to do it well.
No methodology or framework, IMO, are a sufficient
substitute for practice.
Note: if a functionality is deemed strategic, it
is provided free of charge as part of a standard
release. If a customer insists on their own version
or a non-strategic feature, they pay for its development.
This is a workable incentive for convergence and
in most markets, convergence is the process that
leads to commodization and standardization which
works to everyone's advantage.
Again, data objects on the X, operations on the Y,
and users/uses/use cases on the Z. That is a robust
visualization. The marketingHead looks at that
and sees market forces. The developer sees design
tradeoffs. The system manager sees a real time
visualization of the application network.
len
From: Henrik Martensson [mailto:henrik.martensson@bostream.nu]
On Thu, 2004-02-19 at 13:33, Oleg Dulin wrote:
>
> The problem with use-case driven development is that very little focus
> is placed on the architecture of the application, forcing developers to
> deliver functionality and resulting in unmaintainable complex code.
This is wrong. For example, RUP is use-case driven, and places a lot of
emphasis on architecture.
The fact that a methodology is use-case driven does not impair the
architecture of applications in any way. On the contrary, use-cases are
a great help in understanding what an application is supposed to do, and
thus supports the design of a good architecture. Whether you use Design
Patterns, TDD, CRC, UML, DRY, Simple Design, or some other design tools,
use-cases will be an extremely valuable help.
There is a problem that _may_ crop up with use-case driven development:
it does not emphasize testing enough. (My personal opinion, and I don't
expect anyone else to buy it right off the bat. Also, it depends on who
is doing the use-case driven development, of course.)
However, this is not the same thing as saying there is a problem with
use-cases. Use-cases are a great tool and in most cases they capture
requirements much better than traditional requirement specifications.
Personally, I am rather strongly in favour of test driven methodologies,
and i consider use-cases an essential tool in my methodology toolkit.
>
> With Cocoon and XSL I found that most of the architecture is already
> provided by the framework itself, meaning that you can focus on the
> functionality. The problem of refactoring and reuse manifests itself in
> XSLT, though, but it is not nearly as complex to refactor XSLTs as it is
> to maintain reusable component-based Java code.
>
> Anyway, what do you think ? Given XML-pipeline frameworks such as
> Cocoon, can we focus on functionality and pay little attention to the
> architecture (assume that Cocoon does its job well), or is architecture
> still an important part of the methodology ?
With the complexity of the applications we make today, architecture is
more important than ever. Using a framework of some sort does not reduce
the need to pay close attention to the architecture of the code we write
ourselves. Messy code written on top of a good framework will result in
a bad system
|
