![translation](https://cdn.durumis.com/common/trans.png)
Dit is een door AI vertaalde post.
[SI-ontwikkelaarverhaal] 09. De start van de daadwerkelijke ontwikkeling na toewijzing aan het SI-project
- Taal van de tekst: Koreaans
- •
-
Referentieland: Alle landen
- •
- Informatietechnologie
Selecteer taal
Samengevat door durumis AI
- Na toewijzing aan een SI-project wordt de in de RFP gespecificeerde functionaliteit ontwikkeld volgens het WBS-schema. Omdat de klant vaak van gedachten verandert, moet de koppeling tussen modules minimaal zijn en moet de ontwikkeling flexibel zijn.
- De klant is bekend met zijn eigen werkzaamheden, maar kan geen implementatierichtlijnen geven, wat leidt tot extra eisen of wijzigingen na de ontwikkeling, wat resulteert in frequente codewijzigingen en neveneffecten.
- SI-ontwikkeling is daarom gericht op het snel ontwikkelen van software die voldoet aan de eisen van de klant binnen een strak tijdschema, wat betekent dat de nadruk meer ligt op het implementeren van functionaliteit dan op schone code of efficiëntie.
SI-ontwikkelaarverhaal
#9. Na deelname aan het SI-project - De start van de echte ontwikkeling
Na een zekere aanpassingsperiode na deelname aan het project, wordt men echt betrokken bij de ontwikkeling. De ontwikkeling vindt plaats volgens de in de RFP (Requirements Definition Document) beschreven functies, overeenkomstig het WBS-schema. In SI wordt ervan uitgegaan dat de functies tijdens de ontwikkeling op elk moment kunnen worden gewijzigd, en daarom wordt de koppeling met andere modules zo los mogelijk gehouden.
De reden is dat de klant die het project heeft besteld, weliswaar zijn eigen werk kent, maar geen implementatie-richtlijnen kan geven over welke functies nodig zijn en hoe het scherm moet worden geconfigureerd. Daarom worden zodra een ontwikkeld scherm wordt getoond, meestal aanvullende vereisten of wijzigingen aangebracht.
Als de koppeling met andere modules sterk is, moet bij het aanpassen van een module ook een andere module worden aangepast, wat onvoorziene neveneffecten kan veroorzaken. Dit leidt tot een rommelige dubbele code.
Het doel van SI is om het systeem op een of andere manier werkend te krijgen, dus schoonheid en efficiëntie komen op de tweede plaats.
Aanvankelijk is er de wens om het zo goed mogelijk te doen, maar als je constant met een strakke planning te maken hebt en met aanvullende verzoeken van de klant, zul je merken dat je steeds sneller gaat ontwikkelen.
Sommige klanten doen niets meer, omdat ze ervan uitgaan dat je het wel zult maken aangezien ze er voor betalen. Dit is een voorbode van de hel die aan het einde van het project zal losbarsten, dus als je iets niet begrijpt, vraag dan zo snel mogelijk en probeer het te documenteren.
Onthoud de volgende punten bij het ontwikkelen in SI.
- De inhoud kan op elk moment worden gewijzigd.
- De klant weet niets. Laat zo vaak mogelijk feedback zien in de vorm van kleine schermen.
- Wees niet zomaar ja tegen aanvullende verzoeken, tenzij deze echt noodzakelijk zijn.
- Ik ben geen Bill Gates. Klanten vinden een snel gemaakt scherm fijner dan een goed gestructureerd programma.