From: Markus Elfring on
> You total process zealot! Don't you know that one size doesn't fit all, and
> that many great _heroic_ projects have been delivered, on time and under
> budget, with pure Waterfall??!

There are different impressions about the success statistics. How big is the
probability that requirements will change during the years while it is tried to
finish each project phase sequentially? How stable are any dependencies?

Agile software development contains a continuum from predictive to adaptive
processes. How much would you like to balance agility and disciplined work?
Would you like to consider any of the following approaches to embrace change in
your project management?
- Crystal Clear
- Extreme Programming
- Scrum

Regards,
Markus
From: Alexei Polkhanov on
On Aug 17, 2:34 am, philip_b_tay...(a)yahoo.co.uk wrote:
> I am looking at the architecture and possible framework solutions for
> a system which has the following requirements:
> 1. Distributed, networked control/data handling/analysis system
> 2. Multi-platform (Linux, Windows, + Real-time platforms TBD)
> 3. Multi-language (probably Java, C++, Python)
> 4. Widely distributed development (worldwide), including academic as
> well
> as industrial participants.
> 5. Development time 5-10 years, operational lifetime 20-30 years (yes
> really).
>
> The CORBA solution currently proposed is being criticized (amongst
> other reasons) as
> being "old technology".

Hehehehehe!!! You have not listed even a SINGLE requirement in that
list. All these items are parts for proposed solution for problem that
have not been even articulated. When you see something like "System
should send customer information to server over XML protocol" - first
thing that should ring the bell is that it is not a requirement
because requirements should never suggest solution or have parts of
design embedded in it. "System should be able to submit customer
information to central shared storage and provide feedback to user in
2 seconds". - this is requirement.

Ironically I would excuse someone with little knowledge about Software
Development, but for someone who knows cool words like "CORBA and C++"
you should at least be aware of what User Requirements are and thing
that go in there and things that NOT. It even more amazing that most
people who participated in this thread did not even noticed that :-)

Alexei.






From: Phlip on
Alexei Polkhanov wrote:

> Hehehehehe!!! You have not listed even a SINGLE requirement in that
> list. All these items are parts for proposed solution for problem that
> have not been even articulated. When you see something like "System
> should send customer information to server over XML protocol" - first
> thing that should ring the bell is that it is not a requirement
> because requirements should never suggest solution or have parts of
> design embedded in it. "System should be able to submit customer
> information to central shared storage and provide feedback to user in
> 2 seconds". - this is requirement.
>
> Ironically I would excuse someone with little knowledge about Software
> Development, but for someone who knows cool words like "CORBA and C++"
> you should at least be aware of what User Requirements are and thing
> that go in there and things that NOT. It even more amazing that most
> people who participated in this thread did not even noticed that :-)

Why, that's almost like saying that long-term requirements should not be
planned, up-front, as technical details!

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax


From: Dmitry A. Kazakov on
On Wed, 22 Aug 2007 18:26:14 -0700, Alexei Polkhanov wrote:

> When you see something like "System
> should send customer information to server over XML protocol" - first
> thing that should ring the bell is that it is not a requirement
> because requirements should never suggest solution or have parts of
> design embedded in it.

Yep, the XML hype becomes damaging. Alas, even serious customers start to
place that nonsense into their requirements. There is nothing to do about
it, just hold your breath and wait until the dirty wave passes...

> "System should be able to submit customer
> information to central shared storage and provide feedback to user in
> 2 seconds". - this is requirement.

Well, actually the middleware is also a solution. QoS requirements for the
middleware should be a superset of the application system's requirements.
The difference is that XML fulfils no "physical" system requirements, but
fictional ones.

> Ironically I would excuse someone with little knowledge about Software
> Development, but for someone who knows cool words like "CORBA and C++"
> you should at least be aware of what User Requirements are and thing
> that go in there and things that NOT. It even more amazing that most
> people who participated in this thread did not even noticed that :-)

Huh, that's rather normal nowadays. There is a whole generation of
programmers grown with the idea of "spinal programming."

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: apm35 on
On 18 Aug, 03:37, "Phlip" <phlip...(a)yahoo.com> wrote:
> CORBA's main problem is it grew under a broken "request for proposals"
> model. The stakeholding committees chartered their proposal system to
> discourage and inhibit reference implementations for new feature requests.
> This simple but horrific mistake allowed client companies to compete with
> each other by submitting elaborate requests, allowing the CORBA
> specification to clutter up with endless cruft.

> I predict that CORBA as we know it will not last another few years, and that
> something else will take its spot. Maybe a simplified version of the
> ACE-TAO-CIAO framework(s).

I agree that CORBA is the worst example of committee-itus that the
world has ever seen. The C++ language binding is horrific and IMO will
never ever be fixed. But the binding for java is ok and I think CORBA
works quite well with java. Also despite the poor language bindings in
other languages the fact that there are other language binding makes
CORBA a good way to interface to legacy systems (with java on the
frontend of course). IMO. So I think its got a good for several years
yet.

There is a project called ICE from ZeroC, developed by ex-CORBA and ex-
OMG people which tries to remedy the mistakes made with CORBA. You
might want to take a look at it. This seems like a much cleaner system
to me and shows alot of promise. Time will tell.

Regards,

Andrew Marlow