Een van de manieren om ons vak te profileren is om 'success stories' te schrijven over projecten waar u trots op bent. Dat is een mooie manier om aanpak en resultaat te presenteren. Uw bijdrage publiceer ik graag, desgewenst onder uw naam. In de tussentijd zal ik een van mijn eigen voorbeelden geven.
Een jaar of wat geleden werd ik betrokken bij een personeelsinformatiesysteem dat tijdens de uitrol steeds trager werd, maar niet voor alle soorten gebruik. De applicatie kende een PC deel, dat over het netwerk met servers communiceerde. Bij het intakegesprek bleek men al verschillende hypotheses voor het probleem te hebben, maar geen daarvan verklaarde alle verschijnselen.
Onze aanpak was toen om systematisch alle bronnen van performance problemen op te sommen: de desktop, het netwerk en de servers. Voor elk van deze hypotheses richtten we een meting in. Dat klinkt trouwens makkelijker dan het is.
Conclusie uiteindelijk: er waren inderdaad twee problemen. Door onhandig programmeren werd steeds een hele tabel over het netwerk naar de PC gestuurd. Dat werd trager naarmate de uitrol vorderde, omdat die tabel steeds groter werd. Verder was de software aan de PC kant gewoon erg veeleisend. Uiteindelijk moest de applicatie flink worden herschreven.
vrijdag 22 januari 2010
Abonneren op:
Reacties posten (Atom)
Posts
Meten geeft vaak meer zekerheid, maar de meeste tijd besteed ik zelf bij dit soort problemen aan het verzamelen van correcte informatie over het probleem zelf, liefst door het zelf te ervaren. In de praktijk blijkt namelijk de aangeboden analyse van het probleem eigenlijk nooit te kloppen. Op het moment dat een diepgaand onderzoek ingesteld wordt is die informatie over zoveel schijven gegaan dat er niet veel meer van over is.
BeantwoordenVerwijderenJanno,
BeantwoordenVerwijderenWat bedoel je precies. Want door te meten analyseer (objectiveer) je het probleem toch juist? Kan me wel voorstellen dat je het probleem eerst dusdanig ervaren wil hebben (begrijpen) dat je weet WAT je moet meten. Bedoel je dat?