Hoofdstuk 1:Inleiding tot software engineering

Waarom?Economie is afhankelijk vsoftware

Wat is software?-Computer programma’s en geassocieerde documentatie- software prodcuten zijn:

-generiek: ontwikkeld voor een waaier van klanten (vb:office)-maatsoftware: voor 1 klant overeenkomstig me zijn specificatie

Nieuwe software kan ontstaan door:Nieuwe software te creeerenGeneriek aan te configureren of hergebruik v software

Software engineering:Discipline die bezig is met alle aspecten v softwareSoft eng moeten werken volgens systematische benaderingen afhankelijk van:-op te lossen probleem-development constraints (beperkingen)-bescikbare resources

Software proces:Activiteiten met als doel : softwareGenerieke activitieten :-specificatie: wat ? welke zijn development constraint?-ontwikkeling:productie v software-validatie: is dit wat de klant wenst?-onderhoud: eventuele wijzigingen aan de software

Software model:Eenvoudige voorstelling v software proces getoodn vanuit een bep sprespectiefVb perspectief:Workflow,Data-flow,Rol/actie…

Generiek process modelle:Waterval,interatief,component based

Kosten bij engineering : afhankelijk van te ontwikkelen system en de gestelde eisen in combinatie met welk ontwikkelingsmodel gebruikt wordt

Methodes software engineeringHet zijn gestructureerde benaderingen voor software ontwikkeling rekening houdende met de systeemmodellen, regels,desgin advies en de procesbegeleiding.

-Beschrijving systeemmodellen:Beschrijving van grafisch te ontwikkelen modellen

-RegelsBeperkingen van toepassing op het systeem

-Aanbevelingen

Samenvatting slides AO Bram Van den Brande

-ProcesbegeleidngWelke activiteiten zijn nodig?

Uitdagingen v software eginering:HeterogeneniteitVertrouwen(bewijs dat software kan vertrouwd worden door gebruikers)Opleveren(die technieken gebruiken die leiden tot een goed te plannen oplevering vd software)

CASE (computer aided software development)Biedt geautomatiseerde ondersteuning voor software process activiteitenUpper-case:ondersteuning van 1e proces activiteiten (analyse of design)Lower-case : ondersteening van later activitieten (debugging,testen,programmeren)

Activiteiten goede softwareVoldoen aan eisen : performantie,functionalitiet,onderhoudsaarheid,betrouwbaarheid

-onderhoudsbaarheid: makkelijke aan te passen-betrouwbaarheid:correct & consisten reageren-efficiëntie:slechts resoucres gebruiken die nodig zijn-gebruiksvriendelijkheid:

Hoofdstuk 2:Socio technische systemenSysteem categoriën:*Technische:

Bevatten HW en SW geen operatoren of operationele processen*Socio-technische:

Eveneens operatoren of operationele processen en mensen die interageren met het systeem.(onderworpen aan regels en afspraken vd organisatie)

Types systeemeigenschappen*Functionele:

Verschijnen tijden samenwerking v (systeem)onderdelen om een objectief te bereiken*Niet functionele:

Betrouwbaarheid,prestaties,veiligheid…. Staan in relatie met gedrag v systeem in zijn omgeving

Vb: Volume,betrouwbaarheid,beveiliging,onderhoudbaarheid,gebruiksvirendelijkheid

*Betrouwbaarheid:-hardware-software-operator(kans dat operator een fout maakt)

Systeem engineeringSpeciferen,ontwerpen,implementeren en onderhouden v socio-technische systemen

Samenvatting slides AO Bram Van den Brande

Systeemengineering procesMeestal waterfall procesVraagt samenwerking verschillende engineers

Vb: waterfall

Interdisciplinaire betrokkenheidVerschillende groepen v engineers ontwikkelen elk hun deel en moeten dit itegreren in een groot geheel.

Def vd systeemeisen3 types

-Abstract functioneel:syteem funcites worden op abastrace manier gedefineieerd-Systeem eigenschappen:non-func systeemeisen worden algemeen gedefinieerd-Ongewenste karakteristieken : ongewenst systeemgedrag wordt ge specifieerd

ook algemene objectieven worden gedefinieerd

Samenvatting slides AO Bram Van den Brande

Systeem objectieven:-functionele:

Omschrijving vd funcite ve systeem in zijn omgeveing

-organisatie:Omschrijving van de gevolgen van bovenbeschreven functie op de werking vd

organisatie

SysteemontwerpprocesVereisten: veresiten in gerelateerde groepen vastleggen men bekomt sub-sytemenSub-systemen definierenVersisten toekennen aan sub-sytemenFunctionaliteit v sub-systemen specifierenInterfaces v sub-systemen definieren

Systeem modelleringArchitectuurmodel: abstract beeld vd sub-systemen die het systeem vormenKan verschillende types v functionele componenten in 1 model identificeren

SysteemintegratieBestaande systemenKunne cruciaal zijn voor operatie ve bedrijf en kunnen soms niet uit dienst genomen worden

Componenten: hardware,software(support en applicatie),data,bussines processenOp elk vd componeten kan ene probleem optreden waarmee rekening meot worden gehouden

Hoofdstuk 4 : Software processenSet van activiteiten nodig om een software systeem te ontwikkelenSpeciferen,ontwerpen,valideren,onderhoudenHet is een abastracte voorstellinge ve proces vanuit een specifiek oogpunt.

Generieke software proces modellen-Waterval

Duidelijk gescheiden fasen van specificatie en ontwikkelingFasen:

-analyse en def eisen-systeem en stofware ontwerp-implementatie en testen

Samenvatting slides AO Bram Van den Brande

-integratie-onderhoud-Nadeel:Fouten in het begin zij bijna onherstelbaar

-evolutie ontwikkelingSpecificatie,ontwikkeling en validaite zijn in mekaar gewevenSoorten-verkennend:

In samenwerking met finale systeemgebruikers, men moet de vereisen goed begrijpen en op aanvraag nieuwe kenmerken toevoegen-prototyping:

Als vereisten slecht worden begrepen, hopende dat men tijdens het gebruikt vh prototype beter zal kunne specifieren

Problemen : Dikwijls slecht gestructureerde systemenMeesten prototyping nodig

Toepasbaarheid:Klein of middelgrote interactieve systemenDelen v grote systemenSystemen v korte levensduur

-component basedSysteem wordt samengesteld uit bestaande componenten

Processtappen:Component analyseVereisten bijwerkenSysteemontwerp met hergebruikOntwikkeling en integratie

Deze manier wordt meer gebruikt naarmate meer en meer standaard componenten opduiken

Proces iteratieSysteemeisen veranderen altijd tijdens een project dus iteratie van herwerken van processen zal er ook altijd zijn;Iteratie kan op om het even welk generiek procesmodel worden tegepast

2 benaderingenProgressieve opleveringSpiraal ontwikkeling

Software specificatieVastleggen vereisten diensten rekeninghoudende met de beperkingen op ontwikkeling

Hoe?Opstellen vereisten-haalbaarheisstudie-opzoeken + analyseren vereisten-specifieren vereisten-valideren vereisten

Samenvatting slides AO Bram Van den Brande

Software ontwerp en implementatieOmbouwen van eisen naar uitvoerbaar systeemSoftware ontwerp:

Specificatie realiseren in een softwarestructuurImplementatie

Structuur omzetten in uitvoerbaar programma

Desing proces activitieten-architectuur ontwerp:

Sub-systemen en onderlinge relatie worden gedefinieerd-abscrate specificatie:

Ider sub-syteem krijgt een abstracte spec van zijn operaties en beperkingen-interface ontwerp

Ieder sub-systeem krijgt interface ontwerp met ander sub-systemen en worden gedocumenteerd-component ontwerp

Services aan componenten toekennen en interfaces ontwerpen vd componenten zelf-data(implementatie) structuur ontwerp

Datstructuren vd systeemimplementatie worden uitgewerkt -algorythme ontwerp

Gebruikte algorythmen(voor leveren diesnten) worden ontworpen

Rational unified procesKomt van uml

3 perspecievenDynamisch : toont fasen in tijdStatisch : toont procs activiteitenPraktisch

Hoofdstuk 6 : Software vereisten

Opstellen vereistenTot stand brengen vd services die de klant vraagt ve systeem en de beperkingen waaraan het is onderworpen

De vereisten zelf zijn beschrijvingen vd systeemservices,beperkingen en verplichtingen.

Software vereisteVan een Absctracte beschrijving ve fucntie gedetailleerde mathematische spcificatie

Types veresitenUser Veresiten:

Wordt geschreven door de klanten. Uiteenzetting in natuurlijketaal met diagrammen vd services die het systeem moet voorzien en de daarbijhorende beperkingen

Systeem vereisten:Definieert wat moet geïmplementeerd worden. Document met gedetailleerde

beschrijvingen van systeemfuncties,services en beperkingen

Samenvatting slides AO Bram Van den Brande

Funcitonele <> niet-functionele eisenFunctionele:

Omschrijving v service die het systeem meot voorzien en hoe te reageren op bep invoer en in specifieke situaties

Vb:-ieder order een uniek order id-systeem zal geschikte viewers voorzien…

Niet-functionele:Beperkingen op diensten of functies vb: tijdsbeperkingen,wettelijke

verplichtingen,standaarden…

Vb:-verplichtingen zoals: betrouwbaarheid,responstijd,…-beperkingen ivm i/o devices …

Domein:Vereisten afkomstig vh toepassingsdomein ivm karakteristieken vh domein

Vb:

Dan heeft men nog onderverdeling in de vereisten afhankelijk van het systeem-Meetbare eisen-Librare systeem domein eisen-Vereisten geschreven door de gebruiker ( kan probleem oplevren ivm natuurlijke taal : gebrek aan duidelijkheid,functionele en non-functionele eisen door elkaar ….)

Vb van problemen met taal:-ambigiteit(niet altidj zelfde interpretatie ve woord)-over-flexibiliteit (verschillende manier om iets te zeggen)-geen modularisatie (niet geschikt om systeem vereisten te structureren)

-LIBSYS requirement-Systeem vereisten

-meer specifiek over systeem zelf-basis voor systeemontwerp

Versiseten <> ontwerpVereisten: Wat moet het systeem zou moeten doen

Ontwerp: hoe dit moet gebeuren

Fomr base specs- def v funcite of entitiet- inputs + oorpsrong- outputs+bestemming- andere veresite entiteiten- pre/post doncities( indien aanwezig)- neven effecten v functie

Samenvatting slides AO Bram Van den Brande

Spec met tabellen zie vb

Interface specMeeste sysmtene moeten met ander kunnen werken, interfaces moeten als deel vd versiten worden gespecificeerd3 types interface:

1) procedurele interfaces2) data structuren die worden uitgewisseld3) voorstellingen v data

Vereisten document Geen ontwerp doc, het is officiële rapport vd systeemontwikkelaars en bevat de def vd gebruikersvereisten en specs vh systeem

Key points Alle vereisten opstellen

Hoofdstuk 7 : Requirement engineering processesElicitation & analysisTechnische staf werkt samen met de klant om in het domein volgende te zoeken-services die het systeem meot voorzien-beperkingen vh systeem

De betrokkenen zijn: gebruikers,managers,engineers,domain experts… stakeholders geneoemd

Problemen:Ze weten nei wat ze perfect willen. Stakeholders gebruiken eigne terminologie of hebben tegenstrijdige eisen.Organisatorische factoren kunnen eisen beïnvloedenSysteemeisen wijzingen tijdesn analyse proces

Proces activiteiten -requirements discovery:

Interactie tussen stakeholder om eisen te ontdekken (users als systeem requirements)Info bronnen : doc,systeem stakeholders,specs v gelijkaardige systemen

-requirement classificqtion & organisationGerelateerde eisen wordne in coherente groepen smane gezet

-requirements documentation

ViewpointVeresiten structureren en de perspectieven van verschillende stakeholder weer gevenDeze multi-perspectieve analyse is nodig als er geen eenduidige majeir bestaat om de systeemvereisten te analyseren

Types: interactor :

Samenvatting slides AO Bram Van den Brande

o mensen of andere systemen die met het systeem willen interageren indeirect viewpoint

o stakeholders die de eisen wel beïnvloeden maar het systeem nie rechtstreeks beïnvloeden

domein viewpointo domein karakteristieken en beperkingen die de vereisten beïnvloeden

viewpoint identificationidentificeer viewpoint met :

- providers en gebruikers- interagerende systemen met het te specifieren systeem- afspraken,standaarden- systeemontwikkelaars- …

Scenario’sGeven een beschrijving van:

- actor- succesvol verloop- uitbreidingen- foutsituaties- beschrijving van einde v scenario

Requirement validationAantonen dat de pgestelde eisen de eisen zijn die de klant wil

Technieken:Requirements reviews(manuele analyse vd vereisten)PrototypingRest case scenario

Requirements checking- validity: systeem voldoet aan eisen vd klant?- Consistency: tegenstrijdigheden?- Completeness: alles functies aanwezig?- Realism: eisen te realiseren binne budget?- Verifiabilty: kunne eisen geferifieerd?

Traceability- source traceability- requirements traceability

o link tussen onderling afhankelijke eisen- Desgin tracebility

Link tussen vereisten en design

Samenvatting slides AO Bram Van den Brande

Hoofdstuk 8 : Systeem modellen (zie vb’n slides)Syteemmodellng helpt de analyst de functionaliteit vh systeem te begrijpen Modellen worden gebruikt om met de gebruikers te communiceren

Model types- dataprocessing model:

o toont hoe date verwerkt wordt in verschillende niveau’s- compositie model:

o toont hoe entiteiten samengesteld zijn uit andere entiteiten- architectuur model:

o toont belangrijkste sub-systemen- classificatie model:

o toont gemeenschappelijke eigenschappen vh systeem- stimulus/responsmodel:

o toont reactie v systeem op events

Cintext modelToont wat buiten de systeemgrenzen ligt, het architectuur model toont de relatie met ander systemen.

Proces modellenToont totale processen en de processen ondersteunt door het systeemData-flow modellen worden ook gebruikt om transformaties van activiteiten te tonen die , binne een set activiteiten en op een bep niveau, uitgevoerd worden op data flows

GedragsmodellenOm het gedrag v totale systeem te beschrijven2 types:

* dataprocessing modellen : tonen hoe data verwerkt wordt doorheen het systeem* state machines models toene respons vh systeem op events

Data porcessing modellenDfd : om dataprocessing ve systeem te modellerenTonen processtappen samen me dataflow en datastores

State machine modelsTonen respons v systeem op een event, dikwijls gebruikt voor real-time sytemenSysteemteostanden zijn nodes en eents zijn cirkelbogen ertussen. Bij optreding vee ent gaat het van 1 naar andere toestand

State machine diagramsMaken mogelijk te decomposeren in sub-systemenWorden vervolledigd door tabellen die de toestanden en stimuli beschrijven

Semantische data modellenBeschrijft logische structuur vd data verwerkt door het systeemEntity relation attribute : toont entiteiten en de realtie vd entiteiten met hun attributen

Samenvatting slides AO Bram Van den Brande

Data dictionariesBeschrijving v alle namen die in de systeemmodellen gebruikt wordenBeschrijven data flows,data elementen,datastore en ook specs v primiteiven zijn hierin opgenomenZijn integraal supplement bij diagrammen

Object modellenBeschrijven systeem dmv object classes en hun associatiesObject claas is een abstracte set van gemeenschappelijke objecten en de servicesSoorten:

Inheritance modelsAggregation modelsInteraction models

Object gedrags modellenInteractie tussen objecten om een use case te definieren

Hoofdstuk 12 : distributed systems architecture

Distributed systemsInfo verwerking wordt verdeeld over verschillende computers en is daarom zeer bealngrijk op bedrijfsniveauVirtueel zijn alle grote computer-based systemen zijn gekend als distributed systems

Types:PErsonal systems:

Niet distributes en werden ontwikkeld om op PC of Workstation te werkenEmbedded sytems:

Lopen op 1 enkele processor of geïntegreerde groep processorenDistributedsystems:

Systeem software loop of geïntegreerde groep samenwerkende processoren linked door een netwerk

CharacteristicsResource sharingOpenheid (verschilende hard- en software )Concurrency (concurrency processen verhogen prestaties)

NadelenComplexiteit: Security:

Gevoeliger voor indringers van buitenManagebility:

complexerOnvorspelbaarheid:

Onvoorspelbare rsponses afhankelijk v systeemorganisatie en netwerkArchitectures

Client-server:

Samenvatting slides AO Bram Van den Brande

Clients gebruiken services van servers.Distributes services worden opgeroepen dor clients

Distributed object: Elke object kan services leveren aan of gebruiken van andere objecten (geen client/server onderscheid)

MiddlewareSoftware die beheer en onderhoud doet van componennten ve distributed systeemVB:

Data convertorsCommunication controllers

Multi-processor architecturesEenvoudigste distributed systemHet architectuur model van veel real-time systemeSysteem bestaande uit verschillende processen al dan niet uigeveord door verschillende processoren

Client-server rchitecturenGemodelleerd als een set v services geleverd door servers en een set clients die deze gebruiken/Clients kennen servers, omgekeerd niet

Layerd application architecture Presentation layer:

o Verzamelen user inputso Betrokken bij voorstellen resultaten ve bewerking aan users

Application processing layer: o Toepassingen ve specifieke functionaliteit

Datamanagement layer: o Beheer systeem databases

Thin- fat clients- Thin clients:

o Server doet datamanagement en volledige uitwerking vd toepassing , client presenteert

Gebruikt waneer bestaande systemen naar client/server emergen Bestaand systeem is server met gui op clients

Zware druk op servers en netwerk- Fat clients:

o Server doet alleen datamanagement, client doet uitwerking en presentatie Verwerking gebeurd lokaal Meest toepasbaar als mogelijkheden v client vooraf gekend zijn Complexer dan thin client : nieuwe versies v toepassingen moetne op

clients gezet worden

Three tier architecturesElk vd architecture app layers kan worden uitgevoerd op een afzonderlijke processorPresteert beter dan thin-client en is makkelijker te beheren als fat-client

Samenvatting slides AO Bram Van den Brande

Distributed object architecturesGeen sever/client onderscheidElke gedistributeerde entiteit is een object dat services voorziet voor andere objecten en services ontvangt dan andere objectenObject communicatie gebeurd via middleware adhv request brokerComplexer in ontwikkeling dan Client/servers systemen

Voordelen:- System designer kunnen de beslissing waar en hoe services te voorzien,

uitstellen- Opensysteem : nieuwe resources makkelijk te te voegen- Flexibel en uitbreidbaar- Dynamisch herconfigureerd worden met object die migreren over netwerk ,

waar nodig

Data mining systemGeen services provision logisch model omdat er afzonderlijek datamanagemnt services zijnDatabase kunne worden bijgeveogd zonder onderbrekeing vh systeemNieuwe relatietypes kunnen worden omschreven door toevoeging van nieuw inegrator objects

CORBA( slide 31-40)Peer-to-peer architecturesGedecantraliseerde systemen waar bewerkingen kunnen worden uitgeveod in elke node in het networkTotaal systeem haalt werkracht uit het grote aantal computers over het netwerkP2P architectural models

Samenvatting slides AO Bram Van den Brande

Decantralised arch

Semi-centralised arch

Hoofdstuk 13 : Application architecturesApplication types- Data processing apps:

o Data driven apps die data verwerken in batchVb: billing systeem, pay-roll systeem

- Transaction processing apps: o Data centred apps die user requests verwerken en info updaten in databasesVb: e-commerce systeem,reservation systeem

- Event processing systems: o Interpreteert evens en reageertVb: word prcessors, real-time systems

- Lanuage processing systems: o Formele taal wordt geïnterpreteerd en uitgevoerd door het systeemVb:Compilers, command interpreters

Samenvatting slides AO Bram Van den Brande

Data processing systemsInput-proces-ouptu systeem

Voorbeeld dfd payroll

Transaction processing systemsVerwerkt queries qls dml opdrqchten vd gebruiker

Vb: ATM

Samenvatting slides AO Bram Van den Brande

Transaction management

E-commerce system architectureInternet based resource management systemen die elektronische orders aanvaardenMeestal multi tier met app layers geassocieerd met elke tier

Event-processin systemsGeven respons op eventSleutel karakteristiek: opvangen van onvoorspelbaarheid vd event-timing

Language processing sytemsAanvaarden natuurlijke of artificiële taal en generen er een ander van

Hoofdstuk 19 : Component based software engineeringCBSE essentialsOnafhankelijek compoenten gespeciefieerd door hun interfacesSomponent standaards

Samenvatting slides AO Bram Van den Brande

Middleware voorziet ondersteuningHergebruik

CBSE & design principalsHergebruik:

- onafhankelijke componenten geen interferentie- verborgen implementatie- communicatie via goed gedefineerde interfaces- shared component platforms

ComponentsBieden een services aan

-onafhankelijk uitvoerbare entiteit(soms bestaande uit meer entiteiten)-publieke interface waarlangs alls interacteis gaan

Component interfaces Provides interface:

o Definieert service die worden aangeboden Requires interface:

o Definieert services die speciferen welke services moeten worden beschikbaar gesteld voor goede werking

Vb:

Data collector comp

Components & objects Componenten zijn:

- enteiteiten - definierne geen type- ondoorzichtige implemantaties

Samenvatting slides AO Bram Van den Brande

- taal-onafhankelijk- gestandariseerd

Component modelsDefinietive standard ve implementatie ve componentHet specifieert hoe interfaces moeten worden gespeciefieerd en welken elementen moeten worden opgenomen inde interface defElements of a component model

Middelware supportComponent models zijn de basis voor middleware supportComponent models implementaties bestaan uit :

-platfrom services:laten componetne communiceren-horizontale servces:app nahfankelijke services gebruikt door veschillende

componentenPlatfrom en honrizontal:

Samenvatting slides AO Bram Van den Brande

CBSE proces (info)

Component identification proces (info)

Component compositionTypes:

Sequential composition: samengestelde componenten worden uitgevoerd in sequentiële vologorde

Hierarcical composition: component doet beroep op service ve ander. Provide en require interfaces v beiden zijn samengevoegd

Additive composition: interfaces van 2 componenten worden samengevoegd tot een nieuw

Samenvatting slides AO Bram Van den Brande

Interface incompatibility Parameter incompatibility: zelfde naam v operatie, ander type Operation incompatibility: namen v operaties in de provide & require interface zijn

verschillend Operation incompletness: provide interface van ene is een subset vd ander zijn

require interfaceVb:

Adapter components:Interfaces v samen te stellen componenten,bij incomptabiliteit, wordt met een ADAPTOR compatble gemaaktZodat types kunne verschillend zijn.

Hoofdstuk 22 : Verificatie & validatieVerificatie <> validatieVerificatie: software conform aan specificatie?Validatie:doet software wat gevraagd is ?

V&C procesIn volledige life-cycle toepassenFouten ontdekkenEvaluatie vh systeemVertrouwen wekken dat het systeem doelgeschikt isHoeft NIET volledig foutvrij te zijn eerder goed genoeg voor voorbestemd gebruik

Statische en dynamische verificatie- Software inspection- Software testing

Samenvatting slides AO Bram Van den Brande

TestingTypes

- Defect testing: o Systeem fouten ontdekkeno Succesvol als men fout heeft gevonden

- Validatie testing: o Aantonen dat software voldoet aan eiseno Succesvol als blijkt dat vereisten goed zijn geïmplementeerd

DebuggingLocaiseren en corrieren van de bij test gevonden fouten

Proces:

V& V planningMoet worden gestart met ontwikkelingsprocesEvenwicht zoeken tussen testen en verificatieTestplanning: afspreken v standaarden voor het test proces( niet de test beschrijven)

v-model (info)

Samenvatting slides AO Bram Van den Brande

Structuur ve software test plan- Test proces : beschrijving vd grootste fasen - Opvolging requirements: in welke mate is voldaan aan de eisen vd gebruiker- Geteste items : specificieren welke onderdelen getest worden- Test volgorde schedule en resource allocation - Test recording procedures :uitkomste ve test moten opgeslagen worden zodat men

kan nagaan op iets correct verlopen is tijdesn de test- Hardware en software requirements : - Constrants : rekening houden met eventuele beperkingen (te weinig personeel)

Software inspectionsNagaan vd source met mensen ,zonder uitvoering van iets, om fouten op te sporenSucces: meerder fouten bij 1 inspectionInspecties en testen gaan dus nauw samen. Wat men bij inspecites vindt zal men bij testen proberen oplossen.Er bestaan inspectionlist om het allemaal iets makkelijker te maken

Inspection proces

Automated static analysisSoftware tools voor het verwerken v source tekstParsen het prog en zoeken naar fouten (gebruiken V & V)Zeer effectief, maar vervangt inspections niet

Samenvatting slides AO Bram Van den Brande

Stages- Control flow analysis:

o Test op loops, zoekt onbereikbare code…- Data use analysis:

o Ontdekt niet geinitaliseerde of ongebruikte variabelen,- Interface analysis:

o Test consistentie v routine en procedure declaraties en hun gebruik- Infrmation flow:

o Identificeert afhankelijkheden v output vars- Path analysis:

o Identificeert maden doorheen het programma

Samenvatting slides AO Bram Van den Brande