[projectontwikkeling] Relevante literatuur?

[Verwijderd]

Ola,

Ben op zoek naar een boek dat eigelijk op een vrij generaliserende manier het proces uitlegt , op theoretisch niveau, hoe een project van concept tot site het beste opgezet kan worden.

Een soort 'lijn-fase model' dat omschreven wordt in een 'how-to' boek.

Dit als onderdeel voor me literatuurlijst voor me thesis.

Zijn er mensen die adviezen hebben?

//edit

Hoef geen verhalen van, dit is niet te omvatten in een generaliserend verhaal, elk project op zich etc.

Desnoods meerdere boeken, gaat gewoon om een korte lijst van boeken ( graag met ISBN ) die ik kan bestuderen ...

[Bosmonster]

IAD?

Iterative Application Design. Legt goed uit hoe je iteratief en prototype-based een applicatie-bouwtraject kunt doorlopen, met documentatie als codewoord.

Deze basis wordt veel gebruikt tegenwoordig (je hoeft het niet exact te volgen).

[Verwijderd]

Misschien vind je dit wel interessant:
Extreme Programming

[Pelle]

Boeken van Yourdon (Structured Analysis / Structured Design)
Boeken over SDM (System Development Methodology)

Loop even bij de Donner binnen, daar hebben ze genoeg van dit soort meuk.

SDM-boek heb ik even niet bij de hand, ISBN van Yourdon is 90-6233-559-4

[Bosmonster]

SDM is zeg maar wat mensen 'vroeger' deden tegenover IAD. (Niet dat het fout is overigens, maar het heeft nadelen).

[efan]

linkje met NL info over IAD? lijkt me wel interessant om een te lezen (op school hebben we nu SDM)

[Bosmonster]

Uit mn afstudeerverslag (was ff zoeken):

IAD, het evolutionair ontwikkelen van informatiesystemen
R.J.H Tolido, 1996, ISBN 90-395-0401-6

Waar ik zei prototype-based bedoelde ik trouwens pilot-based.. foutje. URL's weet ik ff niet, maar als je zoekt op de schrijver/IAD moet je wel wat kunnen vinden.

[Pelle]

Op dinsdag 09 april 2002 14:51 schreef Bosmonster het volgende:
SDM is zeg maar wat mensen 'vroeger' deden tegenover IAD. (Niet dat het fout is overigens, maar het heeft nadelen).

Hmm.. SDM heeft zich inmiddels wel bewezen als ontwikkelmethode, en het voordeel ten opzichte van IAD is dat het helemaal is uitontwikkeld, er geen ondoorzichtige kinderziektes meer in zitten, en er ontzettend veel literatuur over te vinden is. En zeker wanneer je in grote teams werkt (20+) is IAD nog niet echt een alternatief voor SDM.

[Yellow|A]

SDM heeft alleen als vrij groot nadeel het een lineaire hiërarchische methode is en daarom helaas vrij inflexibel.

Dit in tengenstelling tot IAD, RAD en DSDM. In onze mooie digitale wereld zijn de woorden iteratief en incrementeel erg belangrijk.


Snel even wat over SDM gevonden voor je, maar ik zelf zou toch een nieuwere methode kiezen. Niks mis met SDM, maarja

Het doel van SDM is het aanreiken van een methode die, voor verschillende situaties en (delen van) organisaties, een evenwichtige ontwikkeling van de organisatie en informatievoorziening mogelijk maakt.

1.1 SDM, een lineaire methode
Dit houdt in dat de resultaten van een fase als het ware bevroren worden en als uitgangspunt dienen voor de volgende fase.
Wanneer een fase is afgerond en de opdrachtgever heeft het eindresultaat van die fase goedgekeurd dan kan de opdrachtgever later niet meer andere eisen toevoegen. Bij een lineaire methode kan dus niet meer worde teruggegaan naar een reeds afgesloten fase. Dit is tevens het nadeel van SDM. Wanneer blijkt dat er in een reeds afgesloten fase een verkeerde keuze is gemaakt, dan zijn de kosten en de moeite die genomen moeten worden om die beslissing terug te draaien enorm hoog.

1.2 SDM, een hiërarchische methode
De hiërarchie die binnen SDM bestaat is als volgt:
1.Omgeving
2.Organisatie
3.Informatiesysteem

Bij de informatieplanning (fase 0) wordt de belangrijk geachte informatie voorzien van een bepaalde prioriteitsvolgorde.

1.3 SDM, een topdown methode
Dit houdt in dat SDM start op een algemeen of globaal niveau en bij iedere fase steeds gedetailleerder wordt.

1.4 Methoden en technieken binnen SDM
SD: System Development: slaat op een elektronisch, geautomatiseerd informatiesysteem.
Methodologie: Verzameling van methode en technieken.
Omdat SDM niet voorschrijft welke methode of techniek gebruikt moet worden bij welke fase, kan er van SDM gezegd worden dat het zelf niet een methode is!

1.5 SDM, een checklist
SDM geeft per fase een reeks activiteiten die gedaan moeten worden om tot een goed resultaat te komen. Deze activiteiten vloeien voort uit ervaringen uit het verleden. Deze activiteiten hoeven niet verplicht uitgevoerd te worden, maar de ontwikkelaar moet wel goed motiveren waarom hij er van af zou wijken.

1.6 SDM, een methode voor projectbeheersing
De fasering is bedacht om de enorme tijd- en budgetoverschrijvingen van systeemontwikkelingsprojecten te voorkomen.

Welke fase(n) van SDM uitbesteden?
Informatieplanning en Invoering verdienen de voorkeur om deze Intern uit te voeren, met evt. een externe begeleider.

Contra-expertise per fase mogelijk
Een gebruikelijke methode om te komen tot de juiste beslissing is contra-expertise: meerdere (concurrerende) bedrijven krijgen, zonder dat ze het van elkaar weten, dezelfde opdracht. De verantwoordelijke manager vergelijkt de eindresultaten en speelt de bevindingen van de concurrenten tegen elkaar uit. !!: De manager moet dan wel verstand hebben van de materie.
Het is dus voor opdrachtnemers erg belangrijk dat zij veel tijd en aandacht aan de vorm en inhoud van rapporten en presentaties schenken.

Samenstelling van het projectteam (per fase)
De manager kan besluiten om per fase de samenstelling van de projectgroep aan te passen. Zo kan in de eerste fasen (informatieplanning, definitiestudie en logisch ontwerp) worden gekomen om overwegend informatiearchitecten te plaatsen, terwijl in de overige fasen de systeemaannemers meer op de voorgrond zullen staan.

Methoden/technieken voorschrijven
Dit kan nuttig zijn, bijvoorbeeld om in geval van contra-expertise de resultaten eenvoudiger te kunnen vergelijken.

Evolutie van SDM
In 1985 is er als het ware een SDM-2 ontstaan, toen Pandata een aanpassing op het origineel maakte. Binnen de SVC wordt ook voor deze tweede versie gekozen. Er wordt hier onder andere gesproken van Logisch ontwerk en Technisch ontwerp (in versie 1 heette het Globaal en detail ontwerp). De nieuwe termen geven duidelijker aan dat de opdrachtgever en de eindgebruiker sterk betrokken moeten zijn en beslissingen moeten nemen bij het logisch ontwerp. Bij het technisch ontwerp is hun rol geminimaliseerd.

Ook nog een mooi lapje over de drie die ik ken en heb gebruikt

System Development Method (SDM)
Richt zich op projectbeheersing bij systeemontwikkeling (1965-1975) bij die projecten werden de budgetten torenhoog en de managers snapten weinig van systeemontwikkeling waardoor er een Black Box situatie ontstond. Hierdoor ontstond veel onzekerheid met een hoog risicogehalte. Om dit tegen te gaan / verminderen gebruikte men een structuur die te controleren was; de klassieke gefaseerde projectschemas. Bij overgangen tussen verschillende fases werd een mijlpaal gedefinieerd daarnaast werden de activiteiten gedocumenteerd. Er was geen weg terug mogelijk op mijlpaal besluit kon je niet terugkomen

Rapid Application Development (RAD)
Rapid Application Development is ontwikkeld door James Martin.
Het is een dynamische methodiek die dwingt om prioriteiten te stellen. Het kenmerkt zich door iteratief ontwikkelen. Hierdoor ontstaat de mogelijkheid van het heroverwegen van beslissingen, wijzigingen kunnen zonder veel moeite worden doorgevoerd. In plaats van mijlpalen wordt hier gebruikt gemaakt van timeboxing dit houdt in dat er Go or No Go wordt ingezet. Men begint met Joint Requirement Planning (JRP) = Nederlandse applicatie afbakening dan gaat men over op Joint Application Design (JAD) hier worden met intensieve workshop-sessies geven gebruikers, managers en projectleden per increment = partitie = deelproject verder invulling van het project.
Parallel aan het ontwerp vindt de bouw plaats van een prototype van het increment. Deze prototypes kunnen doorgroeien naar een afgebouwd systeem. Hierbij zijn geintegreerde CASE-tools wel noodzakelijk. Deze increment kunnen heroverwogen worden zolang men maar binnen de increment blijft. Aan JRP valt dus niet meer te itereren.
Gelaagde timeboxing zoals die bij RAD wordt gebruikt bestaat uit drie lagen:
-Presentatielaag
-Bedrijfslogica/functielaag
-Datalaag
Drie maal worden deze lagen (increment) beoordeeld door een team. Bij iedere iteratie (herhaling) nemen de aanpassingsmogelijkheden van de gebruiker af.
Review sessies datalaag
Refine sessies datalaag wordt bevroren, begonnen met bedrijfslogica/functielaag
Tuning sessies datalaag en de functielaag worden bevroren en begint de presentatielaag

Optimaliseringsparadox kan gebeuren wanneer men te ver gaat in het optimaliseren
Wat bij RAD een steeds belangrijkere rol gaat spelen zijn de verschijnselen knowlegde worker (Drucker) en kennismanagement.

Dynamisch Systeem Ontwikkelings Methode (DSDM)
De 9 principes van DSDM
-DSDM teams moeten bevoegd zijn om beslissingen te nemen
-De werkwijze is gericht op frequente oplevering van producten (bepaling van tijd)
-De aanpak is iteratief en incrementeel
-Toepasbaarheid betreffende het kunnen uitvoeren van de bedrijfsactiviteiten is een criterium voor de acceptatie
-Alle veranderingen zijn omkeerbaar
-Functionaliteit wordt gedefinieerd op een hoog niveau
-Testen vindt plaats gedurende de gehele ontwikkelfase
-Goede samenwerking tussen alle bij het project betrokken partijen is essentieel.
-Actieve gebruikersparticipatie is een voorwaarde

[Bosmonster]

Deze is helemaal HET Die moet je gebruiken!

[topic=463283/1/25]

[oh,when?]

Op dinsdag 09 april 2002 17:08 schreef Bosmonster het volgende:
Deze is helemaal HET Die moet je gebruiken!

[topic=463283/1/25]

[Verwijderd]

Op dinsdag 09 april 2002 17:08 schreef Bosmonster het volgende:
Deze is helemaal HET Die moet je gebruiken!

[topic=463283/1/25]

juist als we zo gaan beginnen, dan kwoot ik hier war ik daar ook al kwoot:

Op dinsdag 09 april 2002 17:00 schreef oh,when? het volgende:

[..]

Opmerkelijk ook is dat de topicstarter vandaag nog een topic heeft gestart. Hierin word gevraagd om geschikte literatuur over procesbeheersing en procesmethodieken. En nog geen paar uur later een post over het 'ultieme' bijbelschema voor application en webdevelopment. Gaat daar niet nog een uitgebreid onderzoek aan vooraf?

Juist,

ZOals ik al beschreef in een eerdere post owen, gebruik ik al dit materiaal voor mijn Thesis.

Bedoeling in die thesis is dat ik bepaalde methodieken behandel, analyseer verwerk en probeer toe te passen in theoretische vorm.
Voor en nadelen, dienen hier dus in voor te komen, en een visie uit de praktijk.

Wat de bedoeling is van dit schema, is dat ik dit prolongeer als Het schema, dat alles overbodig maakt.

Wat ik dan vervolgens probeer te bewerkstelligen is dat jullie argumenten voor en tegen posten, en jullie visie uit vanuit de praktijk. Met als gevolg dat ik dus een een 'leuke test' heb uit de praktijk in hoeverre het allemaal wel klopt, dit schema.

Wat dus weer bronmateriaal voor mijn thesis kan zijn, snap je?

[Pelle]

Op dinsdag 09 april 2002 17:06 schreef Yellow het volgende:
SDM heeft alleen als vrij groot nadeel het een lineaire hiërarchische methode is en daarom helaas vrij inflexibel.

Het ligt aan de omvang van het project en de opstelling van de opdrachtgever of je ook daadwerkelijk voordeel kunt halen uit de SDM-methode.

Wanneer je in plaats van lineair parallel gaat werken, heeft de kleinste wijziging tot gevolg dat deze overal doorgevoerd moet worden. Zo loop je een groot risico om constant wijzigingen aan te gaan zitten brengen, en je op het eind een product hebt dat als los zand aan elkaar hangt.
Als je een lineaire methode (zoals SDM) volgt, begin je klein en dat ga je steeds gedetailleerder uitwerken. Na elke fase moet de opdrachtgever z'n fiat geven, waarna je weer verder kunt. Zo kun je alles heel goed en strak in de hand houden; wil de opdrachtgever een wijziging dan kan dat en hoeft er maar in 1 fase een aanpassing gedaan te worden. Na goedkeuring kan je daar dan weer in de volgende fase op doorbouwen.

Het is misschien niet de snelste methode, maar wel een hele betrouwbare en beproefde, iets wat opdrachtgevers zeker graag willen, 't is hun geld namelijk en dat geven ze liever uit aan iets dat wellicht 5 of 10% langer duurt maar gegarandeerd een goed product oplevert, dan dat ze wat besparen en de kans lopen door hun eigen wispelturigheid in de aap gelogeerd te zijn.

Dit in tengenstelling tot IAD, RAD en DSDM. In onze mooie digitale wereld zijn de woorden iteratief en incrementeel erg belangrijk.

Als er iets iteratief en incrementeel is, dan is het wel SDM

[Yellow|A]

doh! ja nu je het zegt ik zat ff niet echt op te letten terwijl ik docjes aan het doorzoeken was en aan het tikken

Anyhoet ligt gewoon aan jezelf waarvoor je kiest ... en ook aan je bedrijf natuurlijk

[Pelle]

Op dinsdag 09 april 2002 17:29 schreef Yellow het volgende:
Anyhoet ligt gewoon aan jezelf waarvoor je kiest ... en ook aan je bedrijf natuurlijk

Inderdaad. Als applicatie/website/systeem-ontwerper/developer heb je het vaak niet voor het kiezen, maar volg je gewoon de in jouw bedrijf gebruikte methode. En die is vaak al zo ingeburgerd, dat het teveel geld en/of tijd kost om al het personeel om te gaan scholen en een nieuwe of andere methode aan te leren.

[Verwijderd]

Op dinsdag 09 april 2002 17:33 schreef Pelle het volgende:

[..]

Inderdaad. Als applicatie/website/systeem-ontwerper/developer heb je het vaak niet voor het kiezen, maar volg je gewoon de in jouw bedrijf gebruikte methode. En die is vaak al zo ingeburgerd, dat het teveel geld en/of tijd kost om al het personeel om te gaan scholen en een nieuwe of andere methode aan te leren.

Zeg jij dan ook dat in bepaalde gevallen de methodiek veroudert kan zijn? En ook constant verandert?

[Yellow|A]

Ja ... vooral in de internet wereld waar nieuwe speeltjes hip zijn. In den oude tijd was met bijvoorbeeld vol lof over blah di blah di blah maar tegenwoordig wil iedereen graag UML (UML evoleert ook steeds verder, nu versie 1.4 geloof) gebruiken voor modeleren van dynamische systemen.

UML is een k$t taal en het is lastig om te leren, dus veel bedrijven kiezen er nu nog voor om er niet mee te werken.

Niet dat UML specifiek iets is als IAD/SDM/RAD maar toch wel een voorbeeld ongeveer. Je kan in een SDM ontwikkel traject UML gebruiken, maar dan bots je misschien hier en daar met ideeen van SDM en ideeen van UML.

Als een methodiek langer bestaat worden en subtiele wijzigingen aangebracht, ff lekker tweaken, maar op den duur kun je niet verder gaan qua wijzigingen.

* Yellow|A brak voorbeeld, maar yellow heeft haast en gaat nu eventjes snel naar den bus toe

[Pelle]

Op dinsdag 09 april 2002 18:20 schreef drLiter het volgende:
Zeg jij dan ook dat in bepaalde gevallen de methodiek veroudert kan zijn? En ook constant verandert?

Dat kan. Het bedrijfsleven in de jaren 60 en 70 zat anders in elkaar dan nu. 30 jaar geleden begon met met automatiseren, en daar is bijvoorbeeld SDM dan ook voor ontworpen.
Omdat het een methode is die uitgaat van een een nul-situatie naar een volledige technische implementatie, dekt het alle mogelijke scenarios (dus ook het uitbouwen of herbouwen van een bestaand systeem).

Nu zijn alle huidige bedrijven echter de fase van automatisering invoeren voorbij en verschuift de scope naar bijvoorbeeld ERP (het clusteren van al die eiland-automatisering), CRM (klantgerichte automatisering) en workflow management. Voor het invoeren van dat soort zaken worden soms nieuwe methodes ontwikkeld, die specifiek gericht zijn op het ontwikkelen van dat soort toepassingen, en vaak ook efficienter werken.

De methode SDM is dus niet verouderd aangezien het heel generiek is, maar in sommige gevallen kan het toepassen van een nieuwe methodiek efficienter zijn. Omdat dit echter weer omscholing van personeel met zich meebrengt, en tevens vaak nog bewezen moet worden in onbekende situaties, zal men toch liever voor oude beproefde methodes kiezen.

[Verwijderd]

Maar hoe revolutionair kunnen deze nieuwe werkmethodes zijn dan? Ik bedoel in principe wordt je aangestuurd door je projectmananger of hoofd van je eilandje... in die zin doe je wat je gevraagt wordt.

Vaak licht dus enkel de omscholing bij de organisatie, en bij degene die verantwoordelijk zijn voor de aansturing van het project, veelal de organisatie.

Omscholing personeel is dus maar ten dele...

Maar weet jij, uit je hoofd, literatuur die dit behandelt?
Als het gaat dus om het verouderen van werkmethodes aangaanden IT oplossingen voor producties.

En dan ben ik vooral geinteresseerd in het aspect, grote bedrijven en kleine bedrijven, de verschillen... Een indivisueel artiest, zal dus vrij snel overgaan op nieuwe technieken en treatment dan grote bedrijven.

Versnelt dit, vertraagt dit, gewoon een algemene beschouwing cq analyse dus

Damn can't think strait, * burp *.

[Pelle]

Op dinsdag 09 april 2002 21:25 schreef drLiter het volgende:
Maar hoe revolutionair kunnen deze nieuwe werkmethodes zijn dan? Ik bedoel in principe wordt je aangestuurd door je projectmananger of hoofd van je eilandje... in die zin doe je wat je gevraagt wordt.

Vaak licht dus enkel de omscholing bij de organisatie, en bij degene die verantwoordelijk zijn voor de aansturing van het project, veelal de organisatie.

Omscholing personeel is dus maar ten dele...

Nee, dat is dus niet waar. Er een projectleider, die het overzicht bewaart, en communiceert tussen klant, accountmanager en ontwikkelaars/ontwerpers. De projectleider heeft nergens kaas van gegeten, behalve van communicatie en het halen van deadlines.

De projectleider zegt tegen degenen die het systeem gaan bouwen: Dan en dan is het af. Wanneer leveren jullie je eerste deelproduct op?
Het zijn de developers die de methode bepalen waarmee ze ontwikkelen, en dus moet iedereen die methode kennen.

Maar weet jij, uit je hoofd, literatuur die dit behandelt?
Als het gaat dus om het verouderen van werkmethodes aangaanden IT oplossingen voor producties.

Nee, niet uit m'n hoofd. Duik eens een dag universiteitsbieb in ofzo, daar staat alle vakliteratuur die je zoekt.

[Verwijderd]

Juist projectleider en projectmanager, zijn dus in jouw eigelijk een en dezelfde persoon?

[Verwijderd]

Ik moet heel eerlijk bekennen dat wij helemaal geen standaard methodiek gebruiken voor projecten. Wij hebben tijdens een vergadering een analyse gemaakt van wat er fout gaat tijdens projecten en wat bottlenecks zijn, en wat daar een eventuele oplossing voor kan zijn.

Hierop hebben wij vervolgens gezegd, in het vervolg doen wij het zo en zo, en anders niet anders kost het ons teveel geld.

[Verwijderd]

Op woensdag 10 april 2002 12:22 schreef Gordijnstok het volgende:
Ik moet heel eerlijk bekennen dat wij helemaal geen standaard methodiek gebruiken voor projecten. Wij hebben tijdens een vergadering een analyse gemaakt van wat er fout gaat tijdens projecten en wat bottlenecks zijn, en wat daar een eventuele oplossing voor kan zijn.

Hierop hebben wij vervolgens gezegd, in het vervolg doen wij het zo en zo, en anders niet anders kost het ons teveel geld.

Jullie vallen dus terug op de ervaringen binnen een team, zonder een vast stramien van deliverables erop na te houden bijvoorbeeld.

[Verwijderd]

Op woensdag 10 april 2002 12:28 schreef drLiter het volgende:

[..]

Jullie vallen dus terug op de ervaringen binnen een team, zonder een vast stramien van deliverables erop na te houden bijvoorbeeld.

Ja dat klopt. We hebben het eigenlijk nog nooit gehad over of we een methodiek moeten gebruiken. We konden aan onze ervaringen gewoon direct een aantal bottlenecks vaststellen zoals:

1) Te vaak wijziging in content of grafisch materiaal
2) Te korte planning ivm test periode
3) Te veel zaken toezeggen zonder technisch overleg

Allemaal zaken die er wel eens voor wilden zorgen dat een project uit liep. Vervolgens hebben we contracten en overeenkomsten scherp aangepast zodat de consequenties voor de client zijn.

[Verwijderd]

Op woensdag 10 april 2002 12:31 schreef Gordijnstok het volgende:

[..]

Maar dan hebben we het over grote projecten?
In de zin van echt groot? Laten we zeggen 4 - 5 maanden productie tijd... Waarbij er lineair gewerkt wordt.

Deze methodieken, ik vraag me af hoe zij toepasbaar zijn.
grootte van het bedrijf, grootte van de opdracht, etc

[Verwijderd]

Op woensdag 10 april 2002 12:57 schreef drLiter het volgende:

[..]

Maar dan hebben we het over grote projecten?
In de zin van echt groot? Laten we zeggen 4 - 5 maanden productie tijd... Waarbij er lineair gewerkt wordt.

Deze methodieken, ik vraag me af hoe zij toepasbaar zijn.
grootte van het bedrijf, grootte van de opdracht, etc

Ja dan hebben we het over projecten welke 2 a 3 mnd lopen, en waar dag in dag uit aan gesleuteld wordt. 4 a 5 mnd is wel erg extreem voor een internet project, dan doe je iets heel goed fout.

[Bosmonster]

Op woensdag 10 april 2002 17:06 schreef Gordijnstok het volgende:

[..]

Ja dan hebben we het over projecten welke 2 a 3 mnd lopen, en waar dag in dag uit aan gesleuteld wordt. 4 a 5 mnd is wel erg extreem voor een internet project, dan doe je iets heel goed fout.

Uh oh.. zal het ff doorgeven

Hehe.. we hebben projecten die 1 jaar+ lopen. Zijn dan wel merendeel intranet projecten of applicaties.. das waar..

[Pelle]

Op woensdag 10 april 2002 17:08 schreef Bosmonster het volgende:
Hehe.. we hebben projecten die 1 jaar+ lopen. Zijn dan wel merendeel intranet projecten of applicaties.. das waar..

Een ontwikkeltijd van 1 jaar? Of bedoel je een doorlooptijd van 1 jaar?

Het eerste geval klinkt erg onwaarschijnlijk (of jullie hebben gewoon trage, slechte programmeurs en rijke, makkelijke klanten ).

[Bosmonster]

KPN? Need I say more.. al gaan ze er binnenkort wel in snijden geloof ik.. zo'n open contract werkt niet echt zijn ze nu ook achter.

Maar ook ontwikkeltijd van een site voor een jaar is niet heel vreemd als het een grote site betreft. 2 a 3 maanden is onwerkbaar. Dan is in zo'n geval net een funcioneel ontwerp af en een maand later hopelijk goed gekeurd..

Maar goed.. dat komt eigenlijk altijd door traagheid van de klant. We zijn ook de internetsite/extranet-applicaties voor Coca Cola Enterprises (B2B) aan het ontwikkelen. Maar daar wacht je gewoon iedere ker een maand op een reactie of goedkeuring.

[Verwijderd]

Al deze technieken die jullie hanteren, en waar vaak ook problemen mee zijn komen niet zomaar uit de lucht vallen.

Dit is dus enkel gebaseerd op de ervaring van een bedrijf, door zelf om hun bek te gaan.

Is het zo dat de huidige literatuur hierover niet recent genoeg is, teveel theorie ipv praktijk ervaringen.

Zijn er trouwens boeken op de markt, die echt werkmethodieken behandelen aan de hand van toegepaste producties in de praktijk?
Of is het allemaal vanaf de zijlijn, natte vinger in de lucht, en een proces aan te geven?

[Yellow|A]

Er zullen vast wel boeken zijn die werken met "goede" case beschrijvingen, maar ik kan er niet 1 2 3 een opnoemen.

Veel bedrijven werken ook met een beetje "hybride" methodes die zelf zijn afgeleid van een of meer andere methodes.

[Verwijderd]

Op donderdag 11 april 2002 10:56 schreef drLiter het volgende:
Al deze technieken die jullie hanteren, en waar vaak ook problemen mee zijn komen niet zomaar uit de lucht vallen.

Dit is dus enkel gebaseerd op de ervaring van een bedrijf, door zelf om hun bek te gaan.

Is het zo dat de huidige literatuur hierover niet recent genoeg is, teveel theorie ipv praktijk ervaringen.

Zijn er trouwens boeken op de markt, die echt werkmethodieken behandelen aan de hand van toegepaste producties in de praktijk?
Of is het allemaal vanaf de zijlijn, natte vinger in de lucht, en een proces aan te geven?

Het probleem is dat die methodes in de praktijk helemaal niet zo effecient blijken te werken, of niet aansluiten op wat het bedrijf/ontwikkelteam wil.

Je kunt alles altijd wel uitschrijven, flowcharts maken, structuren aanbrengen, maar vaak blijkt halverwege het project dat er geen flikker meer van klopt.

[oh,when?]

Op woensdag 10 april 2002 17:26 schreef Bosmonster het volgende:
Maar ook ontwikkeltijd van een site voor een jaar is niet heel vreemd als het een grote site betreft. 2 a 3 maanden is onwerkbaar. Dan is in zo'n geval net een funcioneel ontwerp af en een maand later hopelijk goed gekeurd..

Ontwikkeltijd van een jaar?

Dan hebben jullie:

- of hele langzame programmeurs ( regeltje per dag ongeveer )
- slechte planningen

Ook een functioneel ontwerp wat 3 maanden duurt is nogal sterk overdreven. Volgens mij haal je echt de ontwikkeltijd en doorlooptijd door elkaar. Zitten jullie echt een heel jaar te programmeren aan een website?

[DeFeCt]

Op donderdag 11 april 2002 15:02 schreef Gordijnstok het volgende:
Je kunt alles altijd wel uitschrijven, flowcharts maken, structuren aanbrengen, maar vaak blijkt halverwege het project dat er geen flikker meer van klopt.

En volgens mij komt dat doordat methodieken halverwege projecten door tijdsdruk nog wel eens heel los geinterpreteerd worden en niet strak nageleefd.

Met gevolg dat er indd halverwege geen flikker meer van klopt.

Maar als je bij elke wijziging aan de hand van change requests van de klant ook weer netjes je flowcharts, interactie diagrammen etc etc bijwerkt is er niks aan het handje. Dit gebeurd echter 9 van de 10 keer niet en dus lijkt de methodiek te falen. Echter de methodiek faalt niet, de mensen die hem zouden moeten toepassen falen.

* DeFeCt heeft ook projecten met een productie tijd van >4 maanden en zal ook doorgeven dat ze iets heel goed fout doen.

[Bosmonster]

Op donderdag 11 april 2002 15:40 schreef DeFeCt het volgende:

[..]

Maar als je bij elke wijziging aan de hand van change requests van de klant ook weer netjes je flowcharts, interactie diagrammen etc etc bijwerkt is er niks aan het handje. Dit gebeurd echter 9 van de 10 keer niet en dus lijkt de methodiek te falen. Echter de methodiek faalt niet, de mensen die hem zouden moeten toepassen falen.

Hmm.. de klant heeft als het goed is een handtekening gezet onder het functioneel ontwerp met daarin al die diagrammen etc. Daar is (wederom als het goed is) de offerte ook op gebaseerd. Worden daar nadien (dus na zijn handtekening) wijzigingen in aangebracht dan kost dat de klant geld en gebeurt dus niet zo snel.

[DeFeCt]

Op donderdag 11 april 2002 15:45 schreef Bosmonster het volgende:
[..]
Hmm.. de klant heeft als het goed is een handtekening gezet onder het functioneel ontwerp met daarin al die diagrammen etc. Daar is (wederom als het goed is) de offerte ook op gebaseerd. Worden daar nadien (dus na zijn handtekening) wijzigingen in aangebracht dan kost dat de klant geld en gebeurt dus niet zo snel.

Als je iteratief ontwikkelt maak je verschillende iteratie slagen voordat een functioneel ontwerp stabiel is, alle bijbehorende document moeten in dit iteratief proces na elke iteratie ook weer worden bijgewerkt en dat wil men wel eens vergeten worden.

[Verwijderd]

Op donderdag 11 april 2002 15:40 schreef DeFeCt het volgende:
* DeFeCt heeft ook projecten met een productie tijd van >4 maanden en zal ook doorgeven dat ze iets heel goed fout doen.

Maar is dit inclusief overleg, conceptvorming, wachttijd op materiaal, etc.etc. ?

Wij doen ook projecten die in totaal meer als 4 maanden duren. Maar effectief zijn wij er niet 4 maanden continue mee bezig