Prev: Design by Contract vs Law of Demeter : Preconditions
Next: New England Patriot jerseys for men,worldwide express, paypal payment
From: Markus Elfring on 22 Aug 2007 06:36 > 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 22 Aug 2007 21:26 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 22 Aug 2007 22:38 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 23 Aug 2007 04:38 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 23 Aug 2007 05:38
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 |