Aantekeningen E-Government (BI-3): Requirements engineering

Dit artikel is onderdeel van mijn openbare aantekeningen die ik heb gemaakt tijdens mijn studie Business IT & Management aan De Haagse Hogeschool.

Arendsen e.a.: Een requirement is een behoefte, doelstelling, eis, wens of beperking aan systeem van belanghebbende om bij te dragen aan bereiken van een doel. De kwwaliteit van de requirements bepaalt in hoge mate:

  • het succes van ICT projecten – 50~70% van fouten in project komt door slechte requirements (Forrester, Standish Group, Wiegers, Carnegie Mellon Uni en Firesmith);
  • de beheerslasten – verhouding van de kosten: project 20% vs beheer 80%.

Continue reading Aantekeningen E-Government (BI-3): Requirements engineering

Aantekeningen E-Government (BI-3): Unified process

Dit artikel is onderdeel van mijn openbare aantekeningen die ik heb gemaakt tijdens mijn studie Business IT & Management aan De Haagse Hogeschool.

Systeemontwikkeling = software afgestemd op business en taken van gebruikers en eisen aan het systeem.

Unified process = universele aanpak om te komen tot software architectuur

NB: Dit blok BI-3 beperkt zich tot enkele rollen, namelijk: business modeling, requiremens en analysis and design.

1. Unified process

De voordelen van unified process zijn:

  • fouten worden vroeg onderkend;
  • stimuleert gebruiker om bij te dragen aan kwaliteit;
  • kritische issues eerst;
  • iteratief testen;
  • inconsistenties worden vroeg ontdekt;
  • werkdruk wordt over het team verspreid;
  • door korte slagen leer je snel;
  • direct kleine resultaten voor belanghebbenden.

Grote valkuilen:

  • het systeem niet goed begrijpen;
  • te snel beginnen met ontwikkelen.

Iteratie doorloopt alle fasen en heeft software als artefact, bijv. nieuwe versie van het systeem, proof of concept of prototype.

Artefacten worden gesteld als baseline en verhogen die bij elke oplevering. Wijziging van de baseline kan alleen formeel via change management.

Artefacten bijwerken gedurende een iteratie:

  1. plan doelen zorgvuldig;
  2. de evaluatiecriteria zijn bij aanvang bekend;
  3. taken en verantwoordelijkheden van de projectmedewerkers zijn bekend.

Discipline scenario’s = Unified process biedt de mogelijkheid om disciplines per fase flexibel in te zetten. Dit is afhankelijk van:

  • de fase;
  • aanwezige materiaal;
  • projectgroep;
  • wijzigingen in wensen/eisen en/of omgeving.

Resultaat van een Unified process project is altijd software en documentatie.

2. Fasen

2.1 Inception

Doelen:

  1. bepaal de scope door:
    1. begrijp wat er gebouwd moet worden;
    2. definieer de kernfunctionaliteit;
    3. achterhaal een architectuur als oplossing;
    4. analyseer de stakeholders.
  2. bepaal de haalbaarheid:
    1. business case;
    2. planning;
    3. kosten;
    4. risico’s.
  3. identificeer de architectuur;
  4. richt het project in en bepaal welke tools gebruikt gaan worden.

2.2 Elaboration

Requirements verduidelijken, architectuur en projectorganisatie vaststellen.

Het basaal definiëren van een systeemarchitectuur door:

  1. beperken technische risico’s;
  2. maken architecure baseline;
  3. begrijpen wat er nodig is om het systeem te bouwen (requirements in groter detail specificeren).

Op te leveren documentatie, o.a.:

  • iteratieplan, bevat:
    • aandachtspunten
    • risicotabel;
    • use case beoordelingstabel;
    • beschikbaarheid resources;
    • globale project planning;
    • detailplanning (resources, activiteiten en deliverables).

2.3 Construction

Ontwikkelen van de gespecificeerde requirements zodat het klaar is voor deployment:

  1. niet-kritieke delen van use cases worden geanalyseerd en ontworpen;
  2. programmeercode schrijven;
  3. use cases ontwikkelen (model, bouw, test), o.b.v. prioriteit;
  4. bèta versie van het systeem opleveren;
  5. schrijf ondersteunende documentatie.

2.4 Transition

Levert 1.0 versie van het systeem op:

  1. testen van beta release;
  2. parallel draaien aan te vervangen systeem;
  3. conversie data;
  4. ondersteuning voor implementatie (handleidingen, opleidingen, etc.);
  5. bug fixing;
  6. overeenstemming over artefact en evaluatie;
  7. daadwerkelijke deployment.

3. Disciplines

  • primair:
    1. business modeling – begrijp de business van de organisatie:
      • huidige staat van de organisatie;
      • processen, rollen en verantwoordelijkheden;
      • strategie om processen te herontwerpen;
      • bepaal het domein.
    2. requirements – eliciteer, documenteer en consensus over scope:
      • nauw samenwerken met belanghebbenden;
      • scope bepalen;
      • requirements achterhalen;
      • identificeren en prioriteren van nieuwe requirements.
    3. analysis & design – analyseer de requirements en ontwerp een oplossing:
      • formuleer en specificeer een kandidaat architectuur;
      • maak een proof-of-concept van de architectuur;
      • begrijp de requirements aan het systeem;
      • ontwerp de componenten, services en/of modules;
      • techniek (netwerk, user interface en database).
    4. implementation – van ontwerp naar uitvoerbaar programma, klaar om te testen:
      • begrijpen en uitbreiden van het ontworpen model;
      • programmacode schrijven;
      • onderdelen implementeren;
      • testen van code;
      • code omzetten naar beta.
    5. test – objectieve evaluatie om artefact te toetsen aan ontwerp en kwaliteit te garanderen:
      • definiëren en plannen van testwerkzaamheden;
      • test cases maken;
      • testen organisaeren;
      • uitvoeren;
      • rapporteren over fouten.
    6. deployment – uitrol plannen en uitvoeren:
      • plan de uitrol strategie;
      • ondersteunend materiaal ontwikkelen;
      • deployment pakketten maken;
      • tests organiseren;
      • uitrollen;
      • training geven;
      • testen managen.
  • Ondsersteunend:
    1. configuration & change management – bewaakt structuur van artefacten, ontwerp en software:
      • verzoeken tot wijzigingen bijhouden;
      • configurties plannen;
      • configuratie management opzetten;
      • monitoren en rapporteren over configuraties;
      • wijzigingen doorvoeren;
      • iteraties beheren.
    2. project management – monitoren van voortgang en kwaliteit:
      • project starten;
      • projectorganisatie inrichten;
      • relaties met externe (buiten project) factoren;
      • risico management;
      • ramen, indelen en plannen;
      • artefacten begeleiden;
      • fases en project afsluiten.
    3. environment – ondersteuning voor het project:
      • benodigde materialen;
      • ondersteuning identificeren en evalueren;
      • tools in gebruik nemen;
      • tools ondersteunen.

3.1 Business modeling

Business modeling workflow = model van omgeving waarin het informatiesysteem gebruikt gaat worden. Bepalen welke bedrijfsonderdelen ondersteund worden.

Disciplineactiviteiten:

  • onderzoek de bedrijfsstatus;
  • beschrijf de huidige onderneming;
  • verfijn de bedrijfspeocesdefinities;
  • ontwerp de huidige bedrijfsprocessen;
  • verfijn rollen en verantwoordelijkheden;
  • verken bedrijfsprocesautomatisering;
  • ontwikkel domain model.

3.2 Requirements

Zie het artikel Requirements engineering.

Disciplineactiviteiten:

  • analyseer het probleem;
  • begrijp de behoeften van stakeholders;
  • definieer het systeem;
  • manage de scope van het systeem;
  • verfijn systeemdefinities;
  • manage veranderingen in requirements.

3.3 Analysis & Design

Doel = ontwikkel robuste systeemarchitectuur. Requirements → ontwerp

Disciplineactiviteiten:

  • definieer kandidaat architectuur;
  • maak samenhangende architectuur;
  • verfijn de architectuur;
  • analyseer gedrag van het systeem;
  • ontwerp systeemcomponenten;
  • ontwerp database.

3.4 Implementation

Doel = bouwen van het ontwerp.

3.5 Project management

Controletechnieken:

  • time boxing;
  • prioriteren.

Omvang van project inschatten door:

  • functiepuntenanalyse NESMA;
  • COSMIC functiepunten;
  • Use case points.

Time box

  • vooral toepassen in een iteratie
  • werken in teams
  • obv requirements ipv use cases

Agile modeling

  • menden en interactie
  • werkende software
  • samenwerken met klant
  • inspelen op verandering

Disciplineactiviteiten:

  • begrijp het project;
  • evalueer de omvang en risico’s;
  • plan het project;
  • manage de iteratie;
  • sluit het project;
  • sluit de fase;
  • monitor en controleer het project.

3.6 Environment

Ondersteuning van het project dmv templates, standaarden, guidelines en tools.

3.7 Configuration & change management

Bijhouden van projectdocumentatie.

3.8 Deployment

Ingebruikname systeem en plan beschikbaar stellen.

Ondersteuning (handleidingen, training, pilots)

Aantekeningen Business consultancy (BI-1): Business views

Business views geven inzicht in:

  1. processen: business process view;
  2. structuur en noodzakelijke objecten: business structure view;
  3. individuele en onderlinge gedrag van objecten: business behaviour view;
  4. wat te bereiken (doel) en hoe dit te bereiken (strategie): business vision view.

Continue reading Aantekeningen Business consultancy (BI-1): Business views