MG>questions/comments ______________________________________________ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Martin, > > On Sat, Mar 21, 2009 at 9:50 PM, Martin Gainty <mgai...@hotmail.com> wrote: > > > > test driven means if I create a component as a developer I need to install > > a JUnit testcase that will test the requisite function > > > > Actually there's a bit more behind it. > Usually, you start to design an application starting with some > UseCases, Sequenz-Diagrams, Action-Diagrams, Class-Diagrams etc. So > basically you have a MDA (Modell Driven Architecture) reflecting / > incooperating *all* business-requirements (hopefully...) MG>agreed but unless you have the business requirement clearly stated beforehand MG>Sequence,Action and Class Diagrams would not reflect true customer need > > When Using TDD, all of that is left behind. The flow of activity is like > - analyse the problem / requirement > - write a test reflecting the requirement > - code something on which the test will not fail > > As you can see, TDD is more something being used for small projects. > I'd even say that what we understand as a project is already too big > for pure TDD. > TDD is great if you have a small problem, need ti implement a new > requirement or just fix a bug / unwanted behaviour. IMHO it's useless > for real-world projects having a certain complexity and size. MG>6 years ago we faced this very dilemma where a massively monolithic MG>webapp was released to user base and accomplished everything it was supposed to MG>do we had not developed any testcases..after all the main objective was that 'it MG>worked' MG>the user found that when the webapp was deployed in their locale and their MG>environment that the webapp 'did not work' with their specific environment MG>we simply did not accomodate 'their environmental requirements' into the code > Besides, if you are using something like MDA, you start up like > outlined above, however, one you start to implement, you don't start > to code but you start to write some tests for the smallest parts aka > classes. MG>could you provide an real-life scenario where MDA is applicable? MG>are there advantages of using MDA over TDD? MG>are there disadvantages of using TDD over MDA? > IMHO tests should mirror the requirements aka modells, however, I do > not think that the process should start with tests but tests should > come after the design is roughly set. > > > Rapid Iterative Development means make as small a piece of functionality > > such as a >>component > > and then add ancillary functions such as this project requirement > > The thing is, that we all want the requirements to be complete once we > start with the development (which, in my understanding, consists of > analyses, design, test, implementation). However, most of us know that > requirements almost never are complete. > Therefore, one tries to accept the fact and uses something like RID > (being developed from RAD). MG>could you explain RID? MG>could you explain RID's advantages over RAD? > The lifecycle is: > > - Requirements capture MG>agree..this is important.. > - Analysis MG>i take it this means prioritisation? MG>where is resource allocation? > - Design MG>i assume conforming your webapp's architecture to real world test scenarios? > - Implementation MG>this is where TDD tests would either fail/succeed..yes/no? > - Testing MG>if you spent more than 6 months coding in the wrong direction than I hope MG>the projects funding source is infinite MG>the notion of a bunch of folks in one country coding and tossing a webapp MG>over the wall to another country to test is not cost-feasible and would fail MG>because the coders environment never accomodated real-world scenarios > After that again starting with requirements capture. MG>this should've been the first step.. > This seems to be perfect - but hold it: > > As you can imagine, it's almost impossible to estimate the effort for > a project, since you don't know all requirements beforehand. MG>i once worked for someone that would automatically cut your estimate in half MG>so if you need a min 1 week your estimate to this P/L would task at 2 weeks.. MG>the developer needs to grasp 75% of the code requirements before they start MG>in other words your core functions need to be in the first 75% of your deliverables MG>if the remaining 25% takes more time than 75% already completed that means MG>your process methodology is not robust > So the big challange will be to convince your customer that this will > not be a fixed-price / fixed-time-project, however, he (the customer) > will definately benefit since this approach is most flexiable, you are > able to shortly implement new requirements (i.e. market-conditions, > new legal requirements etc.). MG>impossible.. unless you work for a State government or AIG.. MG>(even federal agencies in DC are demanding fixed-price bids now) > The problem still is: Most customers don't actually know their own > requirements, they don't know what they want / need, but still they > want a statement on what the project costs and how long it will > take... MG>get it on paper MG>6 years ago if we had bothered to implement Agile Processing and capture the MG>requirements on paper and get firm deliverables schedule we would'nt have to rewrite MG>a 'working webapp' into a 'a webapp that delivers what the customer signed off on' > > Rgds MG>Vielen Danke, > > Gregor MG>Martin > -- > just because your paranoid, doesn't mean they're not after you... > gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 > gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > _________________________________________________________________ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009
