[DISC] Object Oriented development*

[Verwijderd]

Het doel van dit topic is om meer inzicht te krijgen in de aanpak die jullie kiezen als er een Object Oriented applicatie ontwikkeld moet worden.

Ik ben nu zo'n 2 jaar bezig met OO design & development zowel voor school als voor mijn werk en ik ben er nogsteeds niet uit wat de ideale methode/aanpak is.

Ik heb op school(HTS)/werk meerdere oplossingen bekeken, zoals :

- Rational Unified Proces
- Booch
- OOA/OOD
- EXPO

Nu lijken de eerste, tweede en derde redelijk op elkaar en is EXPO een totaal andere methode die ik ook verder niet wil bespreken, omdat dit een experimentele methode is die nog in ontwikkeling is. Hij is ontwikkeld door een docent bij mij op school en ik kan me ook voorstellen dat weinig mensen er van hebben gehoord.

De discussie die ik nu met jullie wil voeren is hoe pakken jullie de ontwikkeling aan? Kiezen jullie voor een incrementele aanpak en waarom wel/niet? Wat zijn de uit te voeren stappen en waar zit volgens jullie de meest kritieke fase?

Dit kan een discussie worden waar we allemaal veel van kunnen leren dus kom maar op!

[Verwijderd]

OO is data georienteerd bezig zijn. Ik begin altijd met een hierarchisch datamodel in NIAM en ipv tabellen distilleer ik er de classes uit. Omdat je het NIAM schema hierarchisch hebt opgezet (dus niet alles in detail uitwerken in 1 groot schema, maar in stappen topdown uitwerken) heb je automatisch de classhierarchie al gevonden.

De fout die veel mensen maken is dat ze functioneel gericht de objecten gaan definieren. (dus: ik maak een class A en daar stop ik zoveel mogelijk functionaliteit in, en dan derive ik daarvan classes waarin ik de specifieke details invul. Maar... OO is datagericht: je hebt data en daarop functionaliteit. Door je DATA hierarchisch in te delen (wat je in NIAM mooi kunt modelleren) krijg je je classstructuur.

Al wat je dan doet is de bij de data behorende functionaliteit in de class definieren waar die data in is gedefinieerd. Dat kan in een andere modelleringstechniek, bv UML, maar eigenlijk is dat triviaal.

(NOTE: ik ben procedureel opgeleid, dus met C, Unix, Pascal, assembler etc. Vandaar de wellicht iewat onconventionele kijk op de zaak).

[farlane]

Op zaterdag 05 januari 2002 13:18 schreef Otis het volgende:
OO is data georienteerd bezig zijn. Ik begin altijd met een hierarchisch datamodel in NIAM en ipv tabellen distilleer ik er de classes uit.

Als je het op die manier doet, is het dan niet zo dat de classes erg groot (qua functionaliteit) worden (afhankelijk van de grootte van het project natuurlijk) ?

Voor bepaalde (uitgebreide) bewerkingen op data zou je een methode van een klasse kunnen maken, maar je zou ook de bewerking als een klasse kunnen opnemen in je ontwerp.

Ik heb zelf weinig ervaring met OO ontwerp (het komt relatief weining voor in technische softwareprojecten volgens mij) en probeer me daarom wat meer te bekwamen daarin. Ik vind het echter relatief moeilijk om via zelfstudie (redelijk wat boeken gelezen over dit onderwerp) echt goed te worden.

Misschien ook wel aardig: Is er een fatsoenlijke opleiding (cursus) die hier echt diep op ingaat?

[Verwijderd]

Je classes worden niet erg groot, want je past dezelfde normalisatietechnieken toe en dezelfde relatie technieken toe als bij databases. een hierarchische class structuur kun je zien als een uitgenormaliseerde relationele database.

[Verwijderd]

De methode die Otis beschrijft heeft enige overeenkomsten met EXPO. Dit is ook een methode die gebaseerd is op datase methoden zoals FCOIM, wat naar mijn weten weer een vorm van NIAM is.

Jammer dat verder weinig mensen reageren. Wat vinden jullie bijvoorbeeld van deze aanpak:

1 Plan & Elaborate
- System functions
- Use Case Diagram
- Expanded Use Cases
2 Analyses
- Conceptual Model
3 Design
- Real Use Cases
- Collaboration Diagram
- Pattern Summary
- Class Diagram
4 Implementatie

[Speedpete]

Vanuit m'n opleiding is het volgens mij OOA&OOD, beetje de opzet zoals hierboven...

Zelf ben ik het totaal niet eens met de vaste indeling, ik vind zelf dat ontwerp en implementatie wat meer moeten overlappen, op die manier vind je veel classes en structuren waarbij je bij het ontwerp niet eens aan gedacht hebt.

Docenten blaten vaak van 'als het ontwerp geheel goed is, kan iemand anders het implementeren.' Da's natuurlijk wel waar, maar hier gaan ze er van uit dat het ontwerp perfect is, en dat is het nooit, tenzij het een liliputter programma is...

Als ik zelf iets ontwikkel thuis ofzo plan ik niks, omdat tijd niet belangrijk is. Ontwerpen doe ik wel op papier, beetje schetsen zeg maar, waarbij de indeling eigenlijk meer NIAM is dan klassediagram. De schets heb ik er bij wanneer ik begin met implementeren en naar mate ik verder kom en dingen wijzig of toevoeg verander ik dat in m'n ontwerp.

Het standaard resultaat van 'een volledig werkend en gedocumenteerd systeem' haal ik dan altijd...

Dit werkt heerlijk, maar is helaas in werkomgevingen amper toe te passen...

[Bobco]

Op maandag 07 januari 2002 13:18 schreef Speedpete het volgende:
Als ik zelf iets ontwikkel thuis ofzo plan ik niks, omdat tijd niet belangrijk is. Ontwerpen doe ik wel op papier, beetje schetsen zeg maar, waarbij de indeling eigenlijk meer NIAM is dan klassediagram. De schets heb ik er bij wanneer ik begin met implementeren en naar mate ik verder kom en dingen wijzig of toevoeg verander ik dat in m'n ontwerp.

Het standaard resultaat van 'een volledig werkend en gedocumenteerd systeem' haal ik dan altijd...

Dit werkt heerlijk, maar is helaas in werkomgevingen amper toe te passen...

Je slaat de spijker op z'n kop. Als je in je eentje bezig bent kun je doen en laten wat je wilt, de meeste professionele software-ontwikkeling doe je in een team. Schema-technieken en ontwikkel-methodes zijn volgens mij dan ook voornamelijk bedoeld als communicatie-middel. Je gebruikt het puur en alleen om informatie over ontwerpen en afspraken vast te leggen en door te geven.

RUP vind ik redelijk complex, eXtreme Programming is weer het andere uiterste.

In mijn beleving blijft het belangrijk om te werken met step-wise refinement. In het begin kijk je naar de grote brokken die te onderkennen zijn, daarna ga je details invullen. Een van de doelstellingen van OO is altijd re-use geweest, iets wat er in de praktijk vaak bitter weinig van komt.

Op JavaWorld staat een artikel dat aangeeft wat volgens Joshua Bloch goed ontwerp is.

[mbravenboer]

Ik hoor hier wel wat aardige dingen...

Het waterval-model is een vrij onbruikbare ontwikkel-methode naar mijn mening. Er wordt teveel vanuit gegaan dat je een applicatie volledig kan opzetten door van fase naar fase te gaan. In theorie klinkt dat misschien aardig, maar in de praktijk werkt dit toch minder. Als je tegenwoordig nog steeds verwacht dat je een applicatie volledig (tot in detail) kunt ontwerpen en daarna pas aan het implementeren gaat, heb je denk ik toch iets gemist. Ontwerpen en implementeren kan heel goed samen opgaan. Dit kan je zeer extreem doen zoals bij eXtreme Programming of minder extreem, waarbij de fasen elkaar slechts gedeeltelijk overlappen.

Ik denk dat het sterk verschilt per ontwikkel-werk welk model handig is: eXtreme programming is per definitie ongeschikt voor library design, maar je kunt er wel wat aardige aspecten uit halen, net als uit het waterval-model. Voor end-user applicaties is eXtreme programming op sommige punten wellicht erg gunstig, maar voor sommige delen kan je wellicht ook best wat meer denk- en ontwerpwerk gebruiken.

Ik krijg sowieso de kriebels van modellen die je precies aan het handje nemen en aangeven wat je waar moet doen. Dit zie je zowel terug bij de modellen waarbij er duidelijke fasen zijn als ook bij eXtreme programming. Ik geloof niet zo erg in een gedetailleerd recept voor software-ontwikkeling .

[Verwijderd]

Schema-technieken en ontwikkel-methodes zijn volgens mij dan ook voornamelijk bedoeld als communicatie-middel. Je gebruikt het puur en alleen om informatie over ontwerpen en afspraken vast te leggen en door te geven.

Deze uitspraak is natuurlijk correct maar dient niet alleen voor dit doel. Het zal er ook voor zorgen dat er duidelijkheid komt over de duur van een project waardoor het beheersbaar wordt (in zekere mate) en dat er een mijlpalen komen die er voor zorgen dat de voortgang meetbaar wordt.

Ik denk dat het sterk verschilt per ontwikkel-werk welk model handig is: eXtreme programming is per definitie ongeschikt voor library design, maar je kunt er wel wat aardige aspecten uit halen, net als uit het waterval-model. Voor end-user applicaties is eXtreme programming op sommige punten wellicht erg gunstig, maar voor sommige delen kan je wellicht ook best wat meer denk- en ontwerpwerk gebruiken.

Dus ik kan hier uit opmaken dat je eXtreme Programming als methode kiest als je een applicatie voor een opdrachtgever moet ontwikkelen? En zo ja, wat zijn dan de mijlpalen? (Mijlpalen: document/producten tijdens het proces)

[Verwijderd]

Extreme programming krijgt (kreeg?) veel publiciteit, maar de storm lijkt enigsinds geluwd. De regel dat je met zn tweeen programmeert lijkt me erg goed, de rest lijkt me niet zo goed, zeker de interactie met de klant gedurende het process is IMHO sterk overdreven, mede omdat je veelal vroeg in projecten beslissingen moet nemen die leidend zijn in het project. Als je daar later vanaf moet wijken kun je opnieuw beginnen, OOK bij extreme programming.

Zoals met zovele methodieken is het van belang dat je de juiste methode toepast in de juiste situatie: omdat men er steeds meer en meer achterkomt dat met een GOEDE methode men wel een project succesvol kan afsluiten, men dus gedreven op zoek is naar die juiste methode, men overspoelt wordt met allerlei methodes die allemaal beloven wat men wil horen: "Gebruik deze methode en je project slaagt wel!".

Beter zou zijn onderzoek te doen naar de huidige situatie en dan te kijken welke methodiek(en) passen bij die situatie en dus wellicht de beste resultaten geven. Methodieken zijn verder nooit zaligmakend: het zijn leidraden, die je kunnen helpen in situaties waarin het complex dreigt te worden.

Wil je dus succesvol methodieken toepassen, leer dan wat een methodiek bijzonder maakt, en gooi de rest overboord. Oh, en vergeet niet de bijpassende methodenaam te onthouden (iets wat ik altijd vergeet... ). (En wat succesvol inhoudt in de context van het project: Cap Gemini of CMG zullen over 'succesvol' praten, wanneer de klant voor veel te veel geld toch een draaiend project krijgt afgeleverd. Echte automatiseerders spreken liever over 'goed draaiend project naar de wensen van de klant voor de laagst mogelijke kosten voor die klant'. Wezenlijk verschil! Want hoe langer een project wordt uitgemolken door consultants, hoe meer het oplevert voor de consultancy firma. (En ja, dit is realiteit, helaas )

[farlane]

Op maandag 07 januari 2002 10:52 schreef Blizz¿ het volgende:
Jammer dat verder weinig mensen reageren.

Misschien kun je daaruit concluderen dat er weining aan ontwerpen wordt gedaan, en veel aan het bekende 'ontwerpen terwijl u tiept'

In de praktijk kom je(ik) dat vaak tegen, en ik moet zeggen dat het me steeds vaker gaat tegenstaan om fouten in het ontwerp van een ander recht te gaan breien.

Nog vervelender vind ik dat je meestal gedwongen wordt in een bepaalde non-methode mee te gaan omdat het anders te veel tijd (en dus geld) zou kosten. Een (fatsoenlijk) ontwerp wordt dus niet gemaakt. (Ik heb de indruk dat dit in de industriele sfeer nog erger is dan de niet technische IT)

Dit mondt vaak uit in software waar kop noch staart aan zit, en die niet te onderhouden valt. (Wat natuurlijk wel altijd moet gebeuren, vroeg of laat)

[Creepy]

Ach ja.. eehh.. al eens naar UML gekeken?

Ontwerpen is niet echt mijn favo bezigheid, maar moet wel gebeuren!

Zelf heb ik veel SDM geleerd (scholen.. ach ja.. ze lopen wel eens "achter" hehe.. nou niet echt iets wat te gebruiken is bij RAD of OO.

[Verwijderd]

Hoewel ik alleen MBO niveau 4 doe en nog niet eens men diploma heb.... (duurt nog 5 maanden).. kan ik hier denk ik een aardig woordtje mee praten..

Ik heb op school geleerd en gewerkt met SDM methode die ik ook met mijn project toegepast heb.
Hiernaast heb ik ook nog wat UML bijgebracht gekregen.

Het probleem waar ik tegen aan liep en dat ook in mijn project is dat zelf de leraren niet met zekerheid kon zeggen hoe het nou precies moest. De meeste mede studenten konden hier dan ook maar weinig van.

Ik denk zelf dat het niet uitmaakt welke methode je gebruikt. Er moeten verschillende punten duidelijk gemaakt worden als je zo'n methode gebruikt.

1. Uit de tekening moet je iedereen duidelijk kunnen maken en vooral je zelf wat je wil.
2. Gebruik verschillende classes en functions (of wat dan ook) die je later ook in je programma kunt realiseren.

Als je dit kunt in welke methode dan ook dan ben je op een goede weg. Je kunt dan ook al in een team werken omdat ieder persoon verschillende delen van een programma kunt maken.

Op zich is dit erg praktisch maar, dan moet je je wel strikt aan de schema houden want, als je dat niet doet dan wordt het al snel een grote chaos.

Nadeel is hiervan is als je schema niet goed is dan is je programma ook niet goed dus heb je niet goed genoeg over een programma nagedacht.

Wat nu het beste of meest gebruiks vriendelijke methode is moet je zelf uitvinden. Ik vind wel als je een methode goed snapt weet je hoe het principe eruit ziet.

Bye Bye...

[johnwoo]

Uhm ja, ik ben het wel met Speedpete eens; het is meestal ondoenlijk om een compleet 100% klaar ontwerp neer te leggen zonder al wat geimplementeerd te hebben.
Waar ik zelf nogal eens tegenaan loop is dat ik tijdens implementatie een betere manier ergens voor bedenk dan in het ontwerp beschreven staat, vooral als dat ontwerp door een ander gemaakt is
Het gebeurt ook wel eens dat een techniek die in het ontwerp staat heel lastig (of niet) te implementeren is met de gegeven implementatiemiddelen, vooral als het ontwerp 'netjes' onafhankelijk van de implementatie is gedaan.
En ja, ik proggel ook het liefste alles zelf

[farlane]

Op maandag 07 januari 2002 21:09 schreef Creepy het volgende:
Ontwerpen is niet echt mijn favo bezigheid, maar moet wel gebeuren!

Echt? Ontwerpen vind ik juist het interessantste onderdeel van software engineering. Zeker als je het zelf ook implementeert; op die manier kun je zelf zien dat het ontwerp werkt (of juist niet ), en dat geeft toch wel een kick.

NB Onder ontwerpen versta ik dus ook het bedenken van constructies/algorithmes en refactoring tijdens de implementatie of het testen.

[Verwijderd]

Op maandag 07 januari 2002 21:09 schreef Creepy het volgende:
Ach ja.. eehh.. al eens naar UML gekeken?

Ontwerpen is niet echt mijn favo bezigheid, maar moet wel gebeuren!

Zelf heb ik veel SDM geleerd (scholen.. ach ja.. ze lopen wel eens "achter" hehe.. nou niet echt iets wat te gebruiken is bij RAD of OO.

UML is een taal om een ontwerp te visualiseren. Het is niet een ontwikkelmethode.

Het probleem waar ik tegen aan liep en dat ook in mijn project is dat zelf de leraren niet met zekerheid kon zeggen hoe het nou precies moest. De meeste mede studenten konden hier dan ook maar weinig van.

Hier kunnen ze bij ons op de HTS ook wat van. Warrige commentaren en onduidelijke resultaten als je eens wat inleverd. Het is dus niet alleen voor studenten moeilijk

[joepP]

Op maandag 07 januari 2002 14:20 schreef mbravenboer het volgende:
Ik hoor hier wel wat aardige dingen...

Het waterval-model is een vrij onbruikbare ontwikkel-methode naar mijn mening. Er wordt teveel vanuit gegaan dat je een applicatie volledig kan opzetten door van fase naar fase te gaan. In theorie klinkt dat misschien aardig, maar in de praktijk werkt dit toch minder. Als je tegenwoordig nog steeds verwacht dat je een applicatie volledig (tot in detail) kunt ontwerpen en daarna pas aan het implementeren gaat, heb je denk ik toch iets gemist. Ontwerpen en implementeren kan heel goed samen opgaan. Dit kan je zeer extreem doen zoals bij eXtreme Programming of minder extreem, waarbij de fasen elkaar slechts gedeeltelijk overlappen.

Wel vreemd dat dat 'watervalmodel' nog steeds voor supergrote projecten bij grote organisaties (ABN bijvoorbeeld) wordt gebruikt. En dat daarmee projecten worden gerealiseerd waarbij 25 man tegelijk aan het programmeren zijn. Voor zover je nog over 'programmeren' kan praten als je alleen maar TO-tjes hoeft uit te typen

Sommige projecten lenen zich uitstekend voor dit model. Voorwaarden zijn wel dat van tevoren exact duidelijk is wat er gemaakt moet worden. Denk bijvoorbeeld aan het koppelen van zeer complexe informatiesystemen.

Verplaats je ook eens in de positie van een grote automatiseerder. Die neemt een groot project aan, maar wanneer is dat project nou eigenlijk precies af? Als de klant tevreden is? Als de automatiseerder tevreden is? Als het jaar voorbij is? Er moet een zeer gedetailleerde omschrijving van het pakket zijn al voordat het af is. Dat is de enige manier om een fatsoenlijke (juridische) afronding van het project te kunnen definieren.

Het watervalmodel is, door het scheiden van de afzonderlijke stappen, uitmate geschikt voor het beheersbaar houden van de kosten, en het inplannen van benodigde resources. Grote projecten in het bedrijfsleven kan je bijna niet op een andere manier inrichten.

[Verwijderd]

De watervalmethode is geschikt voor projecten waarbij je kennis uit fase X gebruikt om fase X+n op te lossen. Sommige projecten zijn echter dermate afhankelijk van input tijdens latere fases, dat je niet puur de resultaten van voorgaande fases kunt gebruiken in je huidige fases.

Overigens ben ik wel van mening dat je t.a.t. een project kunt omvormen naar een project wat geschikt is voor de watervalmethodiek. Men is alleen vaak te bang om dit te doen, want het uitsluiten van externe inputs in latere fases van het project stuit veelal op onwil bij de klant, die zich nuttig denkt te maken door vooral later in het project nieuwe inzichten en eisen te deponeren.

[Speedpete]

... among the problems that are sometimes encountered when the linear sequential model (waterfall) is applied are:

1. Real projects rarely follow the sequential flow that the (linear) model proposes. although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds.

...

Direct gequote uit Roger S. Pressman, Software Engineering a practitioners approach (Blz. 35, Alinea 3).

Ik denk dat het waterval model z'n goede kanten wel heeft, de structuur enzo, maar dat het op het punt van ontwerp en implementatie beter kan. Bijvoorbeeld een watervalmodel waarbij Ontwerp en Implementatie gedeeltelijk iteratief zijn. De iteratie is in dit geval beperkt tot de modellering van methoden en klassen. De functionaliteit van het ontwerp staat dus vast, alleen de manier van implementeren kan door middel van het iteratieve proces gewijzigd worden.

[Verwijderd]

Nou, neem maar van mij aan dat zodra je het pad opgaat waarbij discussies over hetgeen gemaakt is mogelijk zijn en resultaten van die discussies weer worden verwerkt in het project (dus hetgeen gemaakt is), je project grote kans maakt te ontsporen. ZEKER wanneer je opdrachtgevers bij die discussies betrekt. Wat wel vereist is is dat je vooraf goed onderzoek doet en de juiste gegevens weet en de klant / opdrachtgever de juiste informatie hebt onttrokken en bij de opdrachtgever het juiste beeld hebt geschapen.

Iets wat nogal eens wordt vergeten.

[Speedpete]

Op dinsdag 08 januari 2002 15:43 schreef Otis het volgende:
Nou, neem maar van mij aan dat zodra je het pad opgaat waarbij discussies over hetgeen gemaakt is mogelijk zijn en resultaten van die discussies weer worden verwerkt in het project (dus hetgeen gemaakt is), je project grote kans maakt te ontsporen. ZEKER wanneer je opdrachtgevers bij die discussies betrekt. Wat wel vereist is is dat je vooraf goed onderzoek doet en de juiste gegevens weet en de klant / opdrachtgever de juiste informatie hebt onttrokken en bij de opdrachtgever het juiste beeld hebt geschapen.

Iets wat nogal eens wordt vergeten.

Uhm... dat bedoel ik niet met het stukkie. het idee is meer van:

ontwerpers: Klasse A met methoden 1,2,3,4

programmeurs: Hey, een methode 5 zou zeer efficient uitkomen in de code

ontwerpers modelleren functie 5.

Dat principe.. enneh, dat discussieren over gemaakte dingen en die verwerken, en daarbij discussieren met de opdrachtgever, dat heet het Prototyping Model. Evolutionaire software processen hebben ook tussentijdse discussies met o.a. de klant...

edit:

Typo

[Creepy]

Op dinsdag 08 januari 2002 12:35 schreef joepP het volgende:

[..]

Wel vreemd dat dat 'watervalmodel' nog steeds voor supergrote projecten bij grote organisaties (ABN bijvoorbeeld) wordt gebruikt. En dat daarmee projecten worden gerealiseerd waarbij 25 man tegelijk aan het programmeren zijn. Voor zover je nog over 'programmeren' kan praten als je alleen maar TO-tjes hoeft uit te typen

Sommige projecten lenen zich uitstekend voor dit model. Voorwaarden zijn wel dat van tevoren exact duidelijk is wat er gemaakt moet worden. Denk bijvoorbeeld aan het koppelen van zeer complexe informatiesystemen.

Verplaats je ook eens in de positie van een grote automatiseerder. Die neemt een groot project aan, maar wanneer is dat project nou eigenlijk precies af? Als de klant tevreden is? Als de automatiseerder tevreden is? Als het jaar voorbij is? Er moet een zeer gedetailleerde omschrijving van het pakket zijn al voordat het af is. Dat is de enige manier om een fatsoenlijke (juridische) afronding van het project te kunnen definieren.

Het watervalmodel is, door het scheiden van de afzonderlijke stappen, uitmate geschikt voor het beheersbaar houden van de kosten, en het inplannen van benodigde resources. Grote projecten in het bedrijfsleven kan je bijna niet op een andere manier inrichten.

Hmm.. en hoe zat het ook alweer met de statistieken van deze projecten? Iets van 20% dat ook daadwerkelijk werd afgerond, naar tevredenheid van de klant(!!), ofzo? Niet veel in ieder geval.

Op het moment dat de waterval methode goed incrementeel te gebruiken is, wordt ie naar mijn idee een stuk bruikbaarder. Puur SDM levert naar mijn idee TE veel papier werk op, en als je in 1 van de latere fases nog iets wil aanpassen, zul je een redelijk aantal stappen terug moeten en elke stap (voor een deel) weer opnieuw doorlopen. Dit neemt naar mijn idee te veel tijd in beslag.

Wij gaan hier binnenkort een andere "ontwikkel" methode gebruiken, en dan die van een ene Rose (o.a. met behulp van UML). Ken helaas heel dat Rose gebeuren niet. Maar dat zien we dan wel weer.

[Verwijderd]

Op dinsdag 08 januari 2002 15:49 schreef Speedpete het volgende:
[..]
Uhm... dat bedoel ik niet met het stukkie. het idee is meer van:
ontwerpers: Klasse A met methoden 1,2,3,4
programmeurs: Hey, een methode 5 zou zeer efficient uitkomen in de code
ontwerpers modelleren functie 5.
Dat principe..

Dat heet knoeien, niet via een model werken.
Je gaat nl. niet discussieren over een interface en er een method bij plakken, OOKAL modelleer je die in (whatever that may be). De reden hiervoor is dat je dan het traject opgaat waarbij code die afhankelijk is van de oude interface ook moet worden aangepast, en dat kan wel eens een lastige/langdurige klus worden. Als je dit soort acties 2 keer per week herhaalt ben je meer bezig met je code aan het hercoden dan echt productief bezig. Maar iedereen zn methodes om meer geld te verdienen natuurlijk

enneh, dat discussieren over gemaakte dingen en die verwerken, en daarbij discussieren met de opdrachtgever, dat heet het Prototyping Model. Evolutionaire software processen hebben ook tussentijdse discussies met o.a. de klant...

Wat voor termen men bedenkt voor modellen is niet zo interessant. Iedere hoogleraar heeft er wel 1 op zn naam staan. Terwijl ze veelal op hetzelfde neerkomen. Prototyping is niet wat ik bedoelde, Evolutionaire software processen ook niet, want dan ontwikkel je door aan software die klein bij de klant wordt gezet, terwijl ik doelde op interactie bij de bouw van software, die nog niet bij de opdrachtgever is gestald.

[Verwijderd]

Op dinsdag 08 januari 2002 16:16 schreef Creepy het volgende:
Op het moment dat de waterval methode goed incrementeel te gebruiken is, wordt ie naar mijn idee een stuk bruikbaarder. Puur SDM levert naar mijn idee TE veel papier werk op, en als je in 1 van de latere fases nog iets wil aanpassen, zul je een redelijk aantal stappen terug moeten en elke stap (voor een deel) weer opnieuw doorlopen. Dit neemt naar mijn idee te veel tijd in beslag.

SDM is dacht ik bedacht door Volmac, wat opgegaan is in Cap Gemini. In de tijd dat Volmac nog niet door de mand was gevallen, was SDM een geweldige methodiek, maar toen later bleek dat het wel erg veel tijd kostte en wel erg weinig opleverde (Informatiseringsbank anyone?) zoeken veel mensen tegenwoordig hun heil (terecht) in andere methoden. Consultancy firma's zoeken naar methoden waar veel overhead wordt gecreeerd. Deels voor de extra uren die kunnen worden gedeclareerd en deels voor het zichzelf indekken bij calamiteiten later in het traject, zodat ze kunnen aantonen dat het niet aan hen heeft gelegen, ze hebben immers een methode gebruikt die bekend is en veel informatie opgeleverd.

Wij gaan hier binnenkort een andere "ontwikkel" methode gebruiken, en dan die van een ene Rose (o.a. met behulp van UML). Ken helaas heel dat Rose gebeuren niet. Maar dat zien we dan wel weer.

Rational Rose, marktleider in UML en andere modelleringstools . Ook bekend van de Visual Modeler bij visual studio en ze schijnen een Java compiler te maken voor .NET.

[Speedpete]

Op dinsdag 08 januari 2002 19:13 schreef Otis naast flink wat tekst het volgende:

Dat heet knoeien, niet via een model werken.

Het ligt misschien aan mij, maar vrijwel elk project komen we wel eens iets tegen in het model wat gewoonweg niet te implementeren valt. Op zo'n moment is het verschrikkelijk makkelijk om ff lang de ontwerper te gaan en commentaar te geven.

Geen mens is perfect en zolang er wordt ontworpen door mensen blijft de kans op fouten bestaan...

Overigens is dat de reden waarom ik liever niet Lineair Sequentieel werk...

[Creepy]

Op dinsdag 08 januari 2002 19:17 schreef Otis het volgende:
[..]

Rational Rose, marktleider in UML en andere modelleringstools . Ook bekend van de Visual Modeler bij visual studio en ze schijnen een Java compiler te maken voor .NET.

Hey.. das handig.. * Creepy zoekt ff verder op het net

Nou snap ik ook waarom die gozer zo graag alle tools van de visual studio wil gaan gebruiken.

Maaruh..om ff door te gaan op de vraag van de topic starter.. iemand die bekend is met deze techniek/methode? Heeft het nog specifieke voordelen nadelen t.o.v. van eerder genoemde? Waarom zou je toch voor een andere methode gaan? (hmm.. tis toch wel een methode he?)

En 1 hekel punt (ok..en offtopic.. maar toch): is Rational Rose ook te gebruiken bij non OO omgevingen, of een combinatie van een OO en een NON-OO omgeving?

[Bobco]

Op maandag 07 januari 2002 17:02 schreef Blizz¿ het volgende:
Dus ik kan hier uit opmaken dat je eXtreme Programming als methode kiest als je een applicatie voor een opdrachtgever moet ontwikkelen? En zo ja, wat zijn dan de mijlpalen? (Mijlpalen: document/producten tijdens het proces)

Niet perse, maar het is wel een "methode" die een ontwikkelteam veel vrijheid geeft. XP is naar mijn idee alleen geschikt voor kleine projectjes waarbij de klant niet echt goed weet wat 'ie wil als het project start.

Mijlpalen zijn er in de vorm van de releases die gedaan worden, dit kan bijvoorbeeld om de 14 dagen zijn. klant test, geeft commentaar, fouten worden opgelost en de volgende hap functionaliteit wordt weer toegevoegd.

Wat erg goed werkt is: eerst unit tests maken, dan coden en tenslotten unit testen. Je wordt dan vantevoren gedwongen om toch nog enigszins na te denken voor je naar een editor grijpt...

Qua documenten hoeft er niet zoveel aan te pas te komen, maar het is wel makkelijk om vanuit een gezamenlijk model te kunnen werken. Iets als Together ondersteunt deze manier van werken vrij aardig, ook al omdat je indrukwekkende hoeveelheden schema's kunt produceren uit je source.

[Speedpete]

Op m'n opleiding is XP nog niet langs gekomen, maar als ik het zo lees lijkt het interessant... misschien ff naar zoeken.

Het doet mij denken aan meer vrijheid voor de programmeur, waar ik voorstander van ben.

[Verwijderd]

Op dinsdag 08 januari 2002 20:14 schreef Creepy het volgende:
En 1 hekel punt (ok..en offtopic.. maar toch): is Rational Rose ook te gebruiken bij non OO omgevingen, of een combinatie van een OO en een NON-OO omgeving?

Ik geloof het niet, maar download anders 'even' (ik geloof zo'n 240 mb) een evaluatie versie van http://rational.com/rose.

Alle functionaliteit ingebakken, werkt alleen maar gedurende 30 dagen

[Verwijderd]

Toppie, inhoudelijk topic
Is d'r misschien iemand die wat links heeft naar goeie sites over NIAM en andere methodieken ?

[roelio]

mbt. UML:

http://www.uml.org/
http://www.orm.net/
http://www.omg.org/uml/
http://www.rational.com/uml/resources/quick/index.jsp
http://www.jeckle.de/unified.htm
http://cgi.omg.org/uml/

[Verwijderd]

Limoentje: Als ik niet op vrouwen zou vallen zou ik je quoten

Lieffffffffff!

[Verwijderd]

OMG > staat dat voor Oh My God ! ?
Ik heb geloof ik net een nieuwe religie ontdekt, ik ga NU een jaar-voorraad Luckies inkopen en de hele OMG site uitlezen, jullie zien me hier over een paar weken wel weer terug. Saluut !

[roelio]

je hoeft niet meteen van die hele site kennis te nemen

[D2k]

Op donderdag 14 februari 2002 09:59 schreef Segunda@Tweakers het volgende:
Toppie, inhoudelijk topic
Is d'r misschien iemand die wat links heeft naar goeie sites over NIAM en andere methodieken ?

probeer het ajb ook zo te houden

[roelio]

D2k .......

[Verwijderd]

Op dinsdag 08 januari 2002 19:17 schreef Otis het volgende:
Rational Rose, marktleider in UML en andere modelleringstools . Ook bekend van de Visual Modeler bij visual studio en ze schijnen een Java compiler te maken voor .NET.

Rational Software Corporation is de organisatie. Rational Rose is één van de producten van Rational waarmee UML (Unified Modelling Language) diagrammen gemaakt kunnen worden.

Met de ontwikkelmethode RUP (Rational Unified Process) kan een ontwikkelproces in de hand gehouden worden. Binnen dat proces kan UML gebruikt worden als modelleringstechniek.

Het voordeel van UML en RUP is dat beiden (min of meer) uit de Rational stal komen en op elkaar zijn afgestemd. Voor ontwikkelaars heeft RUP een bijkomend voordeel. Binnen RUP zijn er namelijk weinig verplichte onderdelen. De ontwikkelaar kan dus zelf kiezen welke punten uit RUP hij wil gebruiken en welke overbodig zijn.

Op woensdag 09 januari 2002 12:28 schreef KoekenBoes het volgende:
Ik geloof het niet, maar download anders 'even' (ik geloof zo'n 240 mb) een evaluatie versie van http://rational.com/rose.

Alle functionaliteit ingebakken, werkt alleen maar gedurende 30 dagen

Inderdaad alle functionaliteit is beschikbaar, alleen is de evaluatie versie slechts 15 dagen geldig.