Page 4 of 8 FirstFirst ... 2 3 4 5 6 ... LastLast
Results 46 to 60 of 113

Thread: Eerst denken, dan bouwen?

  1. #46
    Quote Originally Posted by Benno
    In principe is dat natuurlijk ook de aanpak van een groot project. Je splitst het op in beheersbare deelprojecten met een goede interface naar de rest van het project.
    Ja, absoluut belangrijk? Anders ga je een jaar over een systeem nadenken, daar 2 jaar aan bouwen en kom je na 3 jaar met een systeem dat de gebruiker alweer is vergeten en niet meer past bij zijn inmiddels vernieuwde werkwijze.

    Een gebruiker / klant / materiedeskundige kan zijn eigen project ook niet overzien en beschrijven. Logisch, een gebruiker is niet de analist, dat zijn wij. Dus ook voor de 'andere' kant is het lekker om het in brokken op te delen.
    Marcel

  2. #47
    Quote Originally Posted by Marcel
    Als ik een systeem ontwerp dat door meerdere programmeurs gebouwd gaat worden moet ik het best ver uitwerken. Ik weet immers wel dat de uitkomst van de routine van programmeur 1 weer gebruikt gaat worden door programmeur 2, maar voor programmeur 1 en 2 is dat niet altijd even duidelijk. Dus in zo'n geval gaat een technisch ontwerp vrij ver.
    Interessante thread is dit geworden.. Teamwerk maakt uitwerking van het ontwerp op detail-niveau inderdaad noodzakelijk. Daarvoor zou het ook moeten..

    Een geslaagd software-project zal namelijk meestal overgedragen worden van één persoon naar die ene plus meerdere personen. Als er dan geen ontwerp is, ontstaat er een probleem. Dan kun je gaan uitleggen respectievelijk reverse-engineeren, om terug te herleiden hoe het ook alweer structureel in elkaar zat..

    Overigens, een goed FO en technisch ontwerp garandeert nog niet, dat het overgedragen kan worden. Een kennis-gat tussen de betrokken programmeur en het groeiende team kan voor grotere problemen zorgen. Vooral, wanneer er veel nieuwe technologie in een project is gaan zitten. Niet alle problemen in zo'n soort situatie zijn dus te wijten aan overslaan van de detail-ontwerpfase, er spelen ook andere dingen mee. Een technisch ontwerp (waar UML de fiets voor is) helpt wel, maar is m.i. geen totaal-oplossing. Een visualisatie, hoe helder ook, moet wel begrepen worden !

    De enige manier om hieromheen te komen is een blackbox-benadering. En dingen leesbaar houden: afspraken op het gebied van notatie en dergelijke, gedeelde conventies mbt commentaar en foutafhandeling maken het leven in teamverband ook gemakkelijker.


    Lex
    Minstens ?®?®n hobby naast programmeerwerk is echt noodzakelijk

  3. #48
    In mijn ogen is XP meer de cowboy methode en RUP meer voor de mensen die van dicipline houden. Ik heb echter nooit een gulden tussenweg gezien. Meestal als ik een project moet opzetten maak ik gebruik van een iteratief iets (Meestal stukjes van RUP e.d.), zodat we in kleine stukken kunnen ontwerpen en bouwen. Maakt het geheel iets beter te overzien.
    WM.
    What about weapons of mass construction?

  4. #49
    hoi @WMeints,

    Niemand houdt van discipline, programmeurs zeker niet. Om heel eerlijk te zijn, dit hele FO/TO gedoe vind ik vreselijk maar het moet wel, omdat er nu eenmaal managers tussenhangen, die tijdpaden verwachten en ze anders zelf gaan opleggen. Boven is ook genoemd teamverband. Ook in dat geval kom je er niet omheen om te stoppen met XP. Kan ik uit eigen ervaring melden.

    Ik vraag me af, of het zo is wat je zegt, dus dat er geen tussenweg is. Wat je zelf aangeeft (wel segmenteren, niet ontwerpen) is een TO gebruiken zonder FO vooraf, is volgens mij zoiets. Een specificatie op papier is dan wel superbelangrijk ! Het omgekeerde kan volgens mij ook: eerst een FO maken, dan een minimale definitie van de blackbox opstellen (zo klein/smal mogelijke interfaces), het binnenwerk doet de programmeur vervolgens zelfstandig met XP-technieken, eventueel met boxjes en draadjes vooraf (TO) als het binnenwerk nog steeds te complex is.


    Lex

    P.S. @beheer waarom staat deze thread in de koffiehoek ? Gaan de interessante/serieuze rubrieken op dit forum alleen over programmeren in Delphi ?
    Last edited by LxGoodies; 21-Jun-06 at 14:38.
    Minstens ?®?®n hobby naast programmeerwerk is echt noodzakelijk

  5. #50
    Senior Member Thaddy's Avatar
    Join Date
    Dec 2004
    Location
    Amsterdam
    Posts
    2,211
    Ik heb echter nooit een gulden tussenweg gezien.
    Dat is nou juist wat de meer ervaren professionals die in deze hoek rondhangen proberen over te brengen: die is er min of meer noodzakelijkerwijs wel!
    Alleen is een groot deel van de posts beschreven vanuit het perspectief van de programmeur, hetgeen op zijn minst wat kortzichtig is.
    Als je goed (her-)leest schrijven de echt ervaren pro's vanuit het perspectief van het project en juist niet vanuit het perspectief van de programmeur.
    Wat een programmeur een groot project vindt is voor het project helemaal niet relevant, zelfs niet voor het succes er van.

    Wat de projectleider van een project vindt (als rol, dat kan je gewoon zelf zijn!) is veel relevanter, omdat daarbij ook de omgevingsfactoren in acht worden genomen.

    Een gigantisch groot project kan vanwege zijn impact best een team van 20 of meer mensen nodig hebben om vervolgens in drie regels code geschreven te kunnen worden. Daarentegen kan een kleine functionele wijziging best tot gevolg hebben dat er duizenden regels code moeten worden geschreven.
    (Denk aan legacy code die het idee breekt en waar je omheen moet)

    Als dat laatste het geval is (en dat komt vaker voor dan je denkt!) is het maar goed dat je dan een model hebt (hetzij in f.o hetzij in t.o) om je aan vast te houden, anders verzuip je.

    Niets ten nadele van diegenen die denken vanuit de programmeur (zichzelf), maar echt, die moeten beter om zich heen kijken om in te kunnen schatten wat ze nu echt aan het doen zijn. Gelukkig maken diegenen die dat wel kunnen daarom in een ideale wereld de dienst uit. En in het echt in 80% van de gevallen ook.

    Misschien toch iets om over na te denken (hier stond een naam)?
    Werken aan Ansi support voor Windows is verspilde tijd, behalve voor historici.

  6. #51
    Ik had het eerder over de tussenweg tussen XP en RUP. Daarmee bedoelde ik een model waarbij je het ontwerp in stukjes maakt, dus niet alleen de implementatie maar ook de andere zaken die broodnodig zijn.

    Ik ben het dan ook helemaal met jullie eens dat zowel planning als ontwerp belangrijk zijn. Ik weet inmiddels uit eigen ervaring dat het funest is voor je productiviteit is om geen goed plan te hebben. Ik werk er in ieder geval een stuk prettiger met een goed plan.
    WM.
    What about weapons of mass construction?

  7. #52
    Senior Member Thaddy's Avatar
    Join Date
    Dec 2004
    Location
    Amsterdam
    Posts
    2,211
    Ik bedoelde jou dus niet te veel nuance.
    Maar een tussenweg tussen XP en RUPS is er wel: XP voor de kleine exe of dll niveau klusjes RUPS voor de integratie en de echt belangrijke zaken.
    Daarnaast nog veel belangrijker: goed project management.
    Wat ik al schreef:wat voor de programmeur een project lijkt is voor het geheel maar een minor detail.

    *************
    Goed, voor anderen om pedagogische redenen mijn vorige post maar even toelichtend:

    Stel:
    Bank. Paswoord policy bij de inlog op het portal verandert van min. 8 naar min. 12 tekens. (bijvoorbeeld opdracht DNB)

    Programmeur: database conversietje, regeltje aanpassen, veldje in de code groter maken, validatie aanpassen. 20 minuten. Tops. (met mazzel)

    Datamanagement:
    Die mag die conversie migreren in het weekend!

    Customer service:
    Mailing naar 300.000 klanten, servicedeskplan schrijven, call centerscripts aanpassen, belangrijke klanten persoonlijk benaderen. Roll outdate afspreken op RvB - vergader tijgers met een volle agenda- nivo ivm importantie. Reclame/voorlichtingscampagne (real life example)
    Programmeur: 1 man uur
    Tester: 1 man uur

    Uitrol naar productie: 2 dagen, i.v.m. consistency en schaduw.

    Totale programma: 10 man JAAR
    (Ik laat nog wat ingewikkelde parijen die jullie toch niets zeggen weg)

    Budget 2.000.000 euro.

    Let wel: kijk wat de programmeur doet!
    Nogmaals:real life example al lijkt het erg overdreven (ik heb de aard van de wijziging aangepast).
    Last edited by Thaddy; 21-Jun-06 at 20:56.
    Werken aan Ansi support voor Windows is verspilde tijd, behalve voor historici.

  8. #53
    Quote Originally Posted by Thaddy
    Wat ik al schreef:wat voor de programmeur een project lijkt is voor het geheel maar een minor detail.
    .. (om pedagogische redenen) ..
    Stel:
    Bank. Paswoord policy bij de inlog op het portal verandert van min. 8 naar min. 12 tekens. (bijvoorbeeld opdracht DNB)

    Programmeur: database conversietje, regeltje aanpassen, veldje in de code groter maken, validatie aanpassen. 20 minuten. Tops. (met mazzel)

    Totale programma: 10 man JAAR
    (Ik laat nog wat ingewikkelde parijen die jullie toch niets zeggen weg)

    Budget 2.000.000 euro.

    Let wel: kijk wat de programmeur doet!
    Wij letten op, daddy.. Uiteraard hebben programmeurs soms een kleine rol in een totaal project, dat snapt iedereen hier wel.

    Het voorbeeld is onzinnig. Het is 1978 zo'n traject. Voor dit soort ingrepen heb ik in de negentiger jaren uitzendwerk gedaan bij 3-4 bedrijven (consultancy, projectplanning), de software moest op meer dan één plaats worden gewijzigd, maar dat totale programma was heus geen 10 manjaar. Te ontwerpen valt er ook geen fuck aan zoiets, dus wat wil je ons kindertjes nu eigenlijk uitleggen ? Dat "pedagogisch", vind ik arrogant en het voorbeeld off-topic..

    Ik denk erover, te stoppen met deze thread.. het gaat zo nergens naartoe, zonde van de (werk)tijd.

    Het onderwerp was "eerst denken, dan bouwen". Dat moet altijd natuurlijk, het gaat er toch om hoe je dat het beste doet en met welke tools ?


    Lex
    Minstens ?®?®n hobby naast programmeerwerk is echt noodzakelijk

  9. #54
    Senior Member
    Join Date
    Sep 2003
    Location
    Beuningen
    Posts
    1,207
    @Thaddy - die opmerkingen over 'om pedagogische redenen' en '(Ik laat nog wat ingewikkelde parijen die jullie toch niets zeggen weg)' zijn pedagogisch niet verantwoord naar mijn mening. Het voorbeeld voor de rest klopt wel maar we hebben het hier over software-projecten en niet over projecten waarin er per ongeluk nog wat aan software word gedaan.

    @WMeints - dat klopt, geen planning of ontwerp en je loopt alleen maar achter de feiten aan te hobbelen en je hebt geen tijd meer om iets nieuws te schrijven omdat je alleen maar bugs oplost van je vorige werk.
    In theorie werkt alles maar hoe maak je het dan waar, in de praktijk werkt het maar niemand weet waarom.

  10. #55

    Unhappy

    Het voorbeeld voor de rest klopt wel maar we hebben het hier over software-projecten en niet over projecten waarin er per ongeluk nog wat aan software word gedaan.
    Dat is wat ik bedoelde met mijn reactie. Het is off-topic. Bedankt voor de bevestiging..

    Quote Originally Posted by TheMephisto
    @WMeints - dat klopt, geen planning of ontwerp en je loopt alleen maar achter de feiten aan te hobbelen en je hebt geen tijd meer om iets nieuws te schrijven omdat je alleen maar bugs oplost van je vorige werk.
    Inderdaad. Daar zijn alle serieuze deelnemers (professioneel en niet-professioneel) het wel over eens hier. Vraag 2 is dan, hoe doe je dat voorwerk nu op zo'n manier, dat niet alleen de (account)manager, de projectleider en de opdrachtgever er iets mee kunnen, zoals nu vaak gebeurt als de eis wordt gesteld. Hoe kan je zelf, dus tijdens de uitwerking en in een later stadium, bij overdracht van een project bijvoorbeeld, ervoor zorgen, dat FO/TO voor programmeurs nuttig is. Daar heb ik zelf ook wel ideeen over, tevens ben ik altijd bereid om bij te leren. Helaas komen we daar in dit verhaal nauwelijks aan toe, omdat sommige programmeurs XP-aanhangers als kinderen wensen te zien. Als je tegen XP bent, geef dan gewoon argumenten en trap deelnemers niet de grond in met dat "pedagogisch". Het is een fout woord in een inhoudelijke thread, vind ik. Mensen haken af dan.


    Lex
    Minstens ?®?®n hobby naast programmeerwerk is echt noodzakelijk

  11. #56
    Voor dit soort ingrepen heb ik in de negentiger jaren uitzendwerk gedaan bij 3-4 bedrijven (consultancy, projectplanning), de software moest op meer dan één plaats worden gewijzigd, maar dat totale programma was heus geen 10 manjaar.
    Ik denk dat Thaddy heeft proberen aan te geven dat er meer is dan alleen wat code kloppen, vooral in een wat grotere organisatie.

    Als ik zelfstandig een project doe, dan doe ik alles. Je merkt dat dan ook in de doorlooptijd.

    Een project in een grote organisatie kost altijd meer tijd, alleen al vanwege alle formele zaken in zo'n organisatie.

    Ik ben ooit betrokken geweest bij een goedkeuringstraject voor een encryptie device om dataverkeer te versleutelen. Die apparaten hadden al allerlei militaire goedkeuringen. Toen ze bij een bank organisatie ingezet gingen worden werd daar een testtraject ingezet om de hele keten te testen (hun desktop applicatie, onze box, en hun serverfarm). Alleen al dat testtraject heeft enkele manjaren aan uren geeist. Dat terwijl het instellen van die doos niet meer dan een half uur kost.

    De rim ram eromheen kost dus vaak meer tijd dan het eenvoudig even aanpassen van wat code.

  12. #57
    Hoe kan je zelf, dus tijdens de uitwerking en in een later stadium, bij overdracht van een project bijvoorbeeld, ervoor zorgen, dat FO/TO voor programmeurs nuttig is.
    Het ideale recept heb ik nog niet gevonden helaas.

    Ik denk wel dat met name een FO niet geschreven moet worden voor de programmeur. Het moet een duidelijk stuk zijn wat de business eenduidig beschrijft (puur functioneel) en door de klant begrepen kan worden. Het moet ook de basis kunnen zijn voor bv de handleiding of helpfile. Het FO moet zodanig geschreven zijn dat een ontwerper of programmeur ermee aan de gang kan, zonder dat die twijfels krijgen over de functionaliteiten.

    Het moeilijkste (is mijn ervaring na 15 jaar projecten doen) is om te zorgen dat je specificaties sluitend blijven. Je krijgt altijd wijzigingen en mijn ervaring is dat het heel verleidelijk is om onder tijdsdruk maar het informele traject in te slaan (we documenteren de source wel). Problemen ontstaan dan als je support moet gaan geven na een aantal jaren, omdat je spec afwijkt van wat je feitelijk gemaakt hebt. Je moet dan dus voor functionele dingen in de source gaan kijken, wat in een idelae wereld niet zou moeten.

    Maar goed, dat hoef ik de pro's hier natuurlijk niet te vertellen, iedereen zal weleens tegen zoiets aan lopen.

  13. #58
    hoi @Benno, bedankt voor je reactie.

    Onze werkervaring komt overeen.. Ik werk zelf momenteel al 8 jaar aan een vrij groot project nu. Dat was gebaseerd op een eerdere DOS-versie, die is wel (ooit) gespecificeerd geweest, echter een TO of FO voor het geheel is nooit gemaakt. Vanaf het begin van mijn aanstelling is er sprake geweest van haastwerk en ad-hoc planning. Sinds twee jaar zijn er programmeurs bijgekomen hier, maar het lukt tot nu toe niet, om ze in te zetten hiervoor. Het feit, dat er voor dit pakket alleen een specificatie, maar géén FO of TO bestond (of bestaat), heeft tot gevolg gehad, dat er 2-3 maanden moest worden "ingewerkt". Zo'n periode is op zich wel hanteerbaar, maar het probleem is, na die periode blijft een kenniskloof t.a.v. de inhoud en (vooral) het overzicht bestaan. Het is productie-software, dus aan de handleiding heeft een programmeur niet veel.

    Ik vraag me dus af, of je dit soort problemen niet kunt kortsluiten, door de software, liefst in een vroeg stadium maar desnoods achteraf, op te splitsen in (heel veel) afzonderlijke links. Die bouwblokken zijn dan onafhankelijke executables, waarbij ieder alléén verantwoordelijk is voor "zijn/haar deel" van het project. Elke component is een black-box met een zo smal mogelijke interface naar buiten. Dat is ook het voornaamste ontwerp-doel bij het voorbereiden van de splitsing: die componenten zijn niet noodzakelijk functionele eenheden voor de gebruiker, er is alléén een technisch criterium, dwz afgesproken common code en minimale interfaces. Er zijn specificaties, een planning en een testplan voor elk stuk. Met de projectleider en de account-manager praat een programmeur alléén over zijn/haar stuk, een projectleider moet dus wel overzicht hebben en een actieve rol. Als het dan uiteindelijk uitgeleverd wordt, merkt de klant niets van die uitsplitsing, een organiserende toplaag zorgt voor de aansluiting. Bijkomend voordeel is, dat de projectleider (en niet de programmeur) praat met de klant over specificaties. Zou zoiets (als strategie vanaf het begin, of als ingreep achteraf) nuttig kunnen zijn ?


    Lex
    Minstens ?®?®n hobby naast programmeerwerk is echt noodzakelijk

  14. #59
    Quote Originally Posted by WMeints
    In mijn ogen is XP meer de cowboy methode en RUP meer voor de mensen die van dicipline houden. Ik heb echter nooit een gulden tussenweg gezien. Meestal als ik een project moet opzetten maak ik gebruik van een iteratief iets (Meestal stukjes van RUP e.d.), zodat we in kleine stukken kunnen ontwerpen en bouwen. Maakt het geheel iets beter te overzien.
    Ik snap niet hoe je XP voor een cowboy methode kan aanzien. Het bestaat uit een samenhangend geheel van practices die een hoge mate van discipline vereisen.

  15. #60
    Zou zoiets (als strategie vanaf het begin, of als ingreep achteraf) nuttig kunnen zijn ?
    Geen idee.

    Zoals gezegd ik werk meestal alleen aan (deel) projecten. Als ik in een project samen werk met een andere partij leg ik inderdaad de interface tussen de onderdelen goed vast. Deze wijzigt daarna nog zelden.

    Persoonlijk ben ik geen fan van heel veel losse exe of DLL bestanden, omdat je dan denk ik uiteindelijk ook goed moet opletten met beheer e.d.

    Als je functioneel losstaande zaken hebt, die hergebruikt kunnen worden, dan zijn componenten toch een ideale oplossing? Iemand van jullie is dan verantwoordelijk voor component X, de anderen gebruiken die component. Documenteer de interface naar die component goed en je bent al een eind op weg. Bovendien kun je de losse onderdelen goed testen, bv met unit testing.

    Je moet dan denk ik alleen nog een soort van "high level" document maken waarbij mensen snel kunnen zien wat er al is (of zou kunnen zijn). Ik bedoel dus een soort bibliotheek van componenten. Een inwerkperiode hou je altijd, daar kom je niet onderuit.

    Zelf vind ik het altijd het moeilijkste om te zien wat een functie nu eigenlijk doet als ik met code van een ander aan de gang moet. Ik probeer altijd functionele namen te gebruiken en er een header bioven te gooien die kort beschrijft wat een functie doet en wat de parameters zijn. Dat bespaard je een hoop tijd en je hoeft niet alle code in detail te bekijken.

    Marcel heeft het tooltje BDOC gemaakt dat hier in de open source sectie te vinden is. Dat kan die headers automatisch uit de source plukken en in een chm bestand zetten. Dat is soms ook best handig om zaken toegankelijk te maken.

Page 4 of 8 FirstFirst ... 2 3 4 5 6 ... LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •