Project onderdelen 12-06-21-v1.0
•Télécharger en tant que PPT, PDF•
0 j'aime•1,244 vues
Recommandé
Contenu connexe
Similaire à Project onderdelen 12-06-21-v1.0
Similaire à Project onderdelen 12-06-21-v1.0 (20)
Project onderdelen 12-06-21-v1.0
- 1. Het project in fasen
- 2. Twee typen faseringen • Managementfasen / PRINCE2 Fasen • Starting UpProjectvoorstel • InitiatiePID met Projectplan • Eén of meer uitvoeringsfasen: Managing Product Delivery • Technische Fasen (algemeen) • Business Requirements • User Requirements • Ontwerpfasen (Software Requirements) • Bouwfase • Testfase
- 3. Projectmandaat • Opdrachtgever en projectleider en evt. beoogde Senior Gebruiker • Gemeenschappelijk begrip over wat (opdracht) en waarom (BC / BR) van het project tussen opdrachtgever en projectleider • Initiële Business case / Requirements op business niveau (globaal) – ‘ontlokken’,identificeren, verzamelen en valideren
- 4. Starting Up / Vooronderzoek • Haalbaarheid: projectleider – Risico’s – Afhankelijkheid van anderen – Grootte van het project – Budget voor het project • Requirements (BRD en/of PPD): ontwikkelaar en projectleider • Toetsing: kwaliteitscontrole van Business Requirements • Wisselwerking tussen beide componenten – Bepaalde requirements kunnen niet haalbaar zijn – Haalbaarheid van het gehele project wordt mede bepaald door de gehele set aan Requirements • Resultaat: projectvoorstel
- 6. Initieerfase / Vooronderzoek • Vooral gericht op inrichting project / oplevering PID. Hoe gaan we om met: – Kwaliteit – Bestandsbeheer / Wijzigingen – Risico’s – Communicatie – Requirements • Eventueel: verfijning Business Requirements
- 7. Initieerfase / Vooronderzoek • Oplevering van globale productbeschrijvingen – Basis: PPD/BRD (en BC) – Mbv: productdecompositiestructuur • Globale planning oplevering producten – Mbv: productstroomschema • Projectorganisatie • Resultaat: PID met Projectplan • Evt. opsplitsing werk in werkpakketten
- 8. Initieerfase: meerdere fasen • Bij meer dan 1 PRINCE2-fase: faseplan – Per product planning in technische fasen – Per product bepaling status productontwikkeling aan het eind van de PRINCE2-fase (time-boxed) – Eventueel aparte PRINCE2-fase voor bepaling User Requirements
- 9. Fasering per product • PRINCE2: in MPD opleveren van producten (op basis van productbeschrijvingen) die in het werkpakket zijn opgenomen • Technische Fasen: – User Requirements – Functioneel Ontwerp – Technische Ontwerp – Bouwen – Testen
- 10. User Requirements Fase • Start van het project voor projectuitvoerders • User Requirements (EASV) (use cases, prototyping e.d.) • Soms kan deel al gedaan zijn in vooronderzoek • Toets van de testbasis (User Requirements) • Kan een aparte PRINCE2-fase zijn (indien go / no go) basis voor gedetailleerde planning verdere fasen
- 11. Ontwerpfase • Functioneel ontwerp – Kan bv. vertaling van Use Cases zijn • Toets van de testbasis (Functioneel ontwerp) • Elicitation, Analysis, Specification, Validation op software niveau • Technisch ontwerp • Toets van de testbasis (Technisch ontwerp)
- 12. Bouwfase / uitvoering • Wordt intern binnen ontwikkelteam georganiseerd • Aandachtspunten: – Infrastructuur (OTAP) – Beheer regelen – Bugs oplossen – Eindigt met ontwikkelaars systeemtest
- 13. (Iteratieve) Testfase • Systeemtest • Bugs oplossen • Acceptatietest • Aanpassingen n.a.v. testen • Herhaal systeem- en acceptatietest zo vaak als nodig
- 14. Afronding / Volgende PRINCE2-fase • Afronding – Implementatie & Overdracht – Eindrapportage, evaluatie en vervolg • Of Volgende PRINCE2-fase – Verder in bepaalde technische fase voor ander product – In (volgende) Faseplan: • Per product faseplanning productontwikkeling • Per product statusbepaling productontwikkeling aan het eind van de fase
Notes de l'éditeur
- Er zijn mogelijkheden om technieken voor management-faseringen en technieken voor technische faserings te combinerne: zo is er iets ontwikkeld om RUP gecombineerd met PRINCE2 te gebruiken! http://www.improvix.com/P2RUP.v1.0.html Managementfasen zijn de fasen voor de interactie tussen projectleider en stuurgroep. Het gaat om go / no go momenten. Technische fasen zijn fasen om de productontwikkeling / software-ontwikkeling in stukjes op te splitsen. In het algemeen kun je de volgende fasen onderscheiden: Business Requirements (in SU en IP-fase) User Requirements (in MPD-fase(n)) Ontwerpfasen (Software Requirements) (in MPD-fase(n)) Bouwfase (in MPD-fase(n)) Testfase (in MPD-fase(n)) We kunnen t.z.t. kiezen voor één of meerdere standaarden en technieken om dit in te richten (bv. RUP: Rational Unified Process)
- Het Projectmandaat is in PRINCE2 termen niet formeel beschreven en kan in principe van alles staan. Het komt vanuit de directie of programmamanagement. Bv. CvB. Bij UBU hebben we een aparte template voor een Projectmandaat, dit kan handig zijn maar is niet noodzakelijk. In het Projectmandaat moeten de Requirements op Business-niveau beschreven zijn. Dit kan heel beknopt zijn, maar bevat in ieder geval: De reden(en) om het project te starten; De bijdrage die de benefits van het project aan de bedrijfsdoeleinden leveren ( toegevoegde waarde(n )! De bepaling van de scope van het project De globale bepaling voor de bijdrage van het project voor de gebruikers . Een nieuw product biedt als het goed is een oplossing voor een probleem. Binnen organisaties komen problemen altijd op hetzelfde neer: de kosten zijn te hoog, de productie te laag, de omzet blijft achter, we hebben te veel werknemers, et cetera. Business requirements zijn ervoor om alles wat je bouwt tegen dat licht te houden. Wat wil je als bedrijf bereiken? Per wanneer? En hoeveel resources zijn ermee gemoeid? En als dat duidelijk is: draagt de nieuwe oplossing genoeg bij? Of zijn de kosten die ermee zijn gemoeid te hoog, afgezet tegen de benefits? De uitkomst is niet per se positief: als de baten niet opwegen tegen de kosten gaat het feest niet door. Business requirements blijven ook van belang als het project al onderweg is. De omstandigheden zullen ook tijdens het proces blijven veranderen. De markt beweegt, wet- en regelgeving verandert, het bedrijf groeit of krimpt, de strategie wordt bijgesteld. Business requirements worden dientengevolge continu bijgesteld, maar kunnen ook volledig omslaan. De eisen die aan het product worden gesteld moeten meeveranderen. Als gevolg van die continue heroverweging kan blijken dat het niet zinvol is om met de ontwikkeling door te gaan. Het voordeel is dat je dat dan in een vroeg stadium kunt signaleren. Het alternatief is bovendien onwenselijk: als je je tijdens de ontwikkeling niet stoort aan wat er in de buitenwereld gebeurt kan het gebeuren dat de uiteindelijke oplossing bij voltooiing volledig obsoleet blijkt te zijn. Daar gaan je geld en je reputatie... Kortom: met business requirements kun je het bestaansrecht van het project doorlopend blijven toetsen. Zie het als een vorm van procesbewaking. Aan requirements van een hoger niveau - business requirements - wordt vaak minder aandacht besteed. Of ze worden genegeerd. Dat, terwijl business requirements nodig zijn om een aantal cruciale vragen te kunnen beantwoorden: ‘Waarom doen we dit?' ‘Wat wil de business hier nu eigenlijk mee bereiken?' ‘Hoe borgen we dat het product aan alle eisen van de business voldoet?' Read more: http://www.computable.nl/artikel/opinie/development/4049046/1277180/nut-en-noodzaak-van-business-requirements.html#ixzz1wo1J0ATY Het komt in de praktijk nogal eens voor dat de business requirements onduidelijk blijven. Een software ontwikkelproject krijgt gewoonlijk de opdracht om een systeem met bepaalde eigenschappen te ontwikkelen. De opdrachtgever meent met dit systeem een procesverbetering te kunnen halen. Op zichzelf is daar niets mis mee. Het gaat mis wanneer de opdrachtgever zijn business requirements niet communiceert aan de belanghebbenden. De business analist speelt hierbij een belangrijke rol. Hij helpt de opdrachtgever om de beoogde procesverbeteringen expliciet te maken. Voorbeelden van opdrachten: Ontwikkel een nieuw klantcontactsysteem voor de afdeling klantenservice Ontwikkel een datawarehouse ten behoeve van de productiestatistieken Ontwikkel ERP-software voor ziekenhuizen Aan de opdrachten in bovenstaand voorbeeld liggen business requirements ten grondslag. Deze geven de achterliggende redenen van de opdrachten ofwel de toegevoegde waarden aan. Voorbeelden van business requirements: De opdrachtgever wil de duur van de telefoongesprekken op het klantcontactcentrum met 20% terugbrengen De opdrachtgever wil sneller aanpassingen in productielijn kunnen doorvoeren De opdrachtgever wil een efficiëntere administratie in ziekenhuizen Read more: http://www.computable.nl/artikel/opinie/development/4049046/1277180/nut-en-noodzaak-van-business-requirements.html#ixzz1wo136Iq1 De fasen die hierbij (in theorie) gelden zijn: De eerste fase voor het vaststellen van de Business Requirements is de Elicitatie-fase. Deze bestaat uit: ‘ontlokken’, identificeren, verzamelen en inventariseren van wat stakeholders willen.. Deze fase eindigt met een Test: een kwaliteitscontrole van de Business Requirements Voorbeelden: We hebben iets nodig om onze BC beter voor het voetlicht te krijgen en subsidiegevers over de streep te trekken. Op dit moment ontbreken hiervoor faciliteiten. We denken hierbij aan een zogenaamde virtuele etalage. Omdat onze klant steeds meer gebruik maakt van mobiele technologie hebben we iets nodig om mobiele klanten beter van onze bibliotheekproducten gebruik te kunnen laten maken. We denken hierbij aan een app.
- Nadat het Projectmandaat ‘klaar‘ is, kunnen de beoogde projectleider en de ‘Business Analist’ / ‘Requirement Engineer’ aan het werk. De projectleider gaat zich focussen op de vraag of het project levensvatbaar, haalbaar is, de requirement engineer gaat zich vooral bezig houden met de vraag of het project lonend is. Tussen beiden is een wisselwerking. Uiteindelijk resulteert dit in een projectvoorstel met als belangijkste ingrediënten: Projectdoelstellingen Projecteindresultaten Projectscope Relaties met andere projecten BC Projectaanpak (In bijlage: PPD of BRD) De BRD heeft een bredere kijk dan de PPD: in de PPD wordt alleen het ‘wat’ beschreven, de BRD schenkt zowel aandacht aan het ‘wat’als het ‘waarom’. Het waarom wordt in PRINCE2 in de BC beschreven. The most common objectives of the BRD are: To gain agreement with stakeholders To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer’s and business’ needs To provide input into the next phase for this project To describe what not how the customer/business needs will be met by the solution
- Globale productbeschrijvingen (met gedetailleerde of minder gedetailleerde requirements): Etalage Bladeraar Viewer App Visieplan
- In de PID komt te staan hoe we het Requirement Management (beheer van Requirements) gaan doen. (bijvoorbeeld in Requirements Management Document) Dit Requirement Management bestaat uit bijvoorbeeld: - Store and update the requirements and their attributes in an appropriate repository, database, or requirements management tool. ( baselines, wijzigingen, versiebeheer ) - Control stakeholder access to the requirements (e.g., based on metadata such as authorization to create/read/update/delete requirements by role, requirement state, requirement ownership, requirement responsibility, date of last change to the requirement, etc.). ( autorisaties ) - Manage the internal and external approval of the requirements. ( goedkeuring ) - Publish the requirements (possibly automatically via a publish and subscribe mechanism) to the appropriate stakeholders at the appropriate time (e.g., upon approval or change). ( communiceren ) - Trace the requirements back to goals and down to the associated architecture, design, implementation, and test work products. ( bewaken van relaties tussen user en software requirements) In de PID komt ook te staan hoe globaal de planning is van de verschillende technische fasen (Requirement-fasen) om een product samen te stellen. Indien er meer dan één managementfase geïdentificeerd wordt, moet er een Faspelan komen waarin opgenomen staat in welke technisce fase een productontwikkeling zich bevindt aan het eind van de managementfase.
- Na de formele start van het project worden de Requirements op gebruikersniveau bepaald (van alle of bepaalde producten). Een hulpmiddel hierbij is het samenstellen van use cases. Als basis kunnen de Business Case, het Business Requirements Document en/of de Project Product Beschrijving gebruikt worden. Afhankelijk van hoe intensief het vooronderzoek is geweest, zal de Project Product Beschrijving meer of minder gedetailleerde informatie bevatten over de Requirements op gebruikersniveau. De Requirements op gebruikersniveau dienen vervolgens getest te worden.
- Binnen de technische fasering voor productontwikkeling krijg je vervolgens de Ontwerpfase. Uitgaande van de opgestelde use-cases, kan een Functioneel ontwerp gemaakt worden. Dit functioneel ontwerp kan vervolgens in requirements op software niveau uitgewerkt worden, waarna een technisch ontwerp kan worden opgeleverd. Het functioneel ontwerp wordt (binnen de Universiteitsbibliotheek Utrecht) vaak overgeslagen. Het is van belang om de Senior Gebruiker (iemand in de stuurgroep of een gemandateerde medewerker binnen bv. I&M) te betrekken bij het Functioneel ontwerp.
- … en vervolgens de Bouwfase. Het is te overwegen om (bij projecten waarbij er slechts één of enkel producten worden gerealiseerd) de technische fasen overeen te laten komen met de managementfasen. Dit zou dan bijvoorbeeld betekenen dat de Bouwfase een tweede Managementfase is. Er zit natuurlijk een relatie tussen een go / no go moment voor de stuurgroep en de uitkomsten van de Requirements analyse. Het technisch ontwerp uit de Ontwerpfase
- Systeemtest is om te zorgen dat het testteam goed kan testen.