Samenvatting_analyse_en_ontwerp

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 creeeren
Generiek aan te configureren of hergebruik v software
Software engineering:
Discipline die bezig is met alle aspecten v software
Soft eng moeten werken volgens systematische benaderingen afhankelijk van:
-op te lossen probleem
-development constraints (beperkingen)
-bescikbare resources
Software proces:
Activiteiten met als doel : software
Generieke 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 sprespectief
Vb 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 engineering
Het 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
-Regels
Beperkingen van toepassing op het systeem
-Aanbevelingen
Samenvatting slides AO
Bram Van den Brande
-Procesbegeleidng
Welke activiteiten zijn nodig?
Uitdagingen v software eginering:
Heterogeneniteit
Vertrouwen(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 activiteiten
Upper-case:ondersteuning van 1e proces activiteiten (analyse of design)
Lower-case : ondersteening van later activitieten (debugging,testen,programmeren)
Activiteiten goede software
Voldoen 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 systemen
Systeem 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 engineering
Speciferen,ontwerpen,implementeren en onderhouden v socio-technische systemen
Samenvatting slides AO
Bram Van den Brande
Systeemengineering proces
Meestal waterfall proces
Vraagt samenwerking verschillende engineers
Vb: waterfall
Interdisciplinaire betrokkenheid
Verschillende groepen v engineers ontwikkelen elk hun deel en moeten dit itegreren in een
groot geheel.
Def vd systeemeisen
3 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
Systeemontwerpproces
Vereisten: veresiten in gerelateerde groepen vastleggen men bekomt sub-sytemen
Sub-systemen definieren
Versisten toekennen aan sub-sytemen
Functionaliteit v sub-systemen specifieren
Interfaces v sub-systemen definieren
Systeem modellering
Architectuurmodel: abstract beeld vd sub-systemen die het systeem vormen
Kan verschillende types v functionele componenten in 1 model identificeren
Systeemintegratie
Bestaande systemen
Kunne cruciaal zijn voor operatie ve bedrijf en kunnen soms niet uit dienst genomen worden
Componenten: hardware,software(support en applicatie),data,bussines processen
Op elk vd componeten kan ene probleem optreden waarmee rekening meot worden gehouden
Hoofdstuk 4 : Software processen
Set van activiteiten nodig om een software systeem te ontwikkelen
Speciferen,ontwerpen,valideren,onderhouden
Het is een abastracte voorstellinge ve proces vanuit een specifiek oogpunt.
Generieke software proces modellen
-Waterval
Duidelijk gescheiden fasen van specificatie en ontwikkeling
Fasen:
-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 ontwikkeling
Specificatie,ontwikkeling en validaite zijn in mekaar geweven
Soorten
-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 systemen
Meesten prototyping nodig
Toepasbaarheid:
Klein of middelgrote interactieve systemen
Delen v grote systemen
Systemen v korte levensduur
-component based
Systeem wordt samengesteld uit bestaande componenten
Processtappen:
Component analyse
Vereisten bijwerken
Systeemontwerp met hergebruik
Ontwikkeling en integratie
Deze manier wordt meer gebruikt naarmate meer en meer standaard componenten opduiken
Proces iteratie
Systeemeisen 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 benaderingen
Progressieve oplevering
Spiraal ontwikkeling
Software specificatie
Vastleggen 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 implementatie
Ombouwen van eisen naar uitvoerbaar systeem
Software ontwerp:
Specificatie realiseren in een softwarestructuur
Implementatie
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 proces
Komt van uml
3 perspecieven
Dynamisch : toont fasen in tijd
Statisch : toont procs activiteiten
Praktisch
Hoofdstuk 6 : Software vereisten
Opstellen vereisten
Tot 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 vereiste
Van een Absctracte beschrijving ve fucntie  gedetailleerde mathematische spcificatie
Types veresiten
User 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 eisen
Functionele:
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 <> ontwerp
Vereisten: 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 spec
Meeste sysmtene moeten met ander kunnen werken, interfaces moeten als deel vd versiten
worden gespecificeerd
3 types interface:
1) procedurele interfaces
2) data structuren die worden uitgewisseld
3) 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 processes
Elicitation & analysis
Technische 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ïnvloeden
Systeemeisen 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 & organisation
Gerelateerde eisen wordne in coherente groepen smane gezet
-requirements documentation
Viewpoint
Veresiten structureren en de perspectieven van verschillende stakeholder weer geven
Deze 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 viewpoint
o domein karakteristieken en beperkingen die de vereisten beïnvloeden
viewpoint identification
identificeer viewpoint met :
- providers en gebruikers
- interagerende systemen met het te specifieren systeem
- afspraken,standaarden
- systeemontwikkelaars
- …
Scenario’s
Geven een beschrijving van:
- actor
- succesvol verloop
- uitbreidingen
- foutsituaties
- beschrijving van einde v scenario
Requirement validation
Aantonen dat de pgestelde eisen de eisen zijn die de klant wil
Technieken:
Requirements reviews(manuele analyse vd vereisten)
Prototyping
Rest 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 model
Toont wat buiten de systeemgrenzen ligt, het architectuur model toont de relatie met ander
systemen.
Proces modellen
Toont totale processen en de processen ondersteunt door het systeem
Data-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
Gedragsmodellen
Om het gedrag v totale systeem te beschrijven
2 types:
*
dataprocessing modellen : tonen hoe data verwerkt wordt doorheen het systeem
*
state machines models toene respons vh systeem op events
Data porcessing modellen
Dfd : om dataprocessing ve systeem te modelleren
Tonen processtappen samen me dataflow en datastores
State machine models
Tonen respons v systeem op een event, dikwijls gebruikt voor real-time sytemen
Systeemteostanden zijn nodes en eents zijn cirkelbogen ertussen. Bij optreding vee ent gaat
het van 1 naar andere toestand
State machine diagrams
Maken mogelijk te decomposeren in sub-systemen
Worden vervolledigd door tabellen die de toestanden en stimuli beschrijven
Semantische data modellen
Beschrijft logische structuur vd data verwerkt door het systeem
Entity relation attribute : toont entiteiten en de realtie vd entiteiten met hun attributen
Samenvatting slides AO
Bram Van den Brande
Data dictionaries
Beschrijving v alle namen die in de systeemmodellen gebruikt worden
Beschrijven data flows,data elementen,datastore en ook specs v primiteiven zijn hierin
opgenomen
Zijn integraal supplement bij diagrammen
Object modellen
Beschrijven systeem dmv object classes en hun associaties
Object claas is een abstracte set van gemeenschappelijke objecten en de services
Soorten:
Inheritance models
Aggregation models
Interaction models
Object gedrags modellen
Interactie tussen objecten om een use case te definieren
Hoofdstuk 12 : distributed systems architecture
Distributed systems
Info verwerking wordt verdeeld over verschillende computers en is daarom zeer bealngrijk op
bedrijfsniveau
Virtueel 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 werken
Embedded sytems:
Lopen op 1 enkele processor of geïntegreerde groep processoren
Distributedsystems:
Systeem software loop of geïntegreerde groep samenwerkende processoren
linked door een netwerk
Characteristics
Resource sharing
Openheid (verschilende hard- en software )
Concurrency (concurrency processen verhogen prestaties)
Nadelen
Complexiteit:
Security:
Gevoeliger voor indringers van buiten
Managebility:
complexer
Onvorspelbaarheid:
Onvoorspelbare rsponses afhankelijk v systeemorganisatie en netwerk
Architectures
 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)
Middleware
Software die beheer en onderhoud doet van componennten ve distributed systeem
VB:
Data convertors
Communication controllers
Multi-processor architectures
Eenvoudigste distributed system
Het architectuur model van veel real-time systeme
Systeem bestaande uit verschillende processen al dan niet uigeveord door verschillende
processoren
Client-server rchitecturen
Gemodelleerd 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 inputs
o 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 architectures
Elk vd architecture app layers kan worden uitgevoerd op een afzonderlijke processor
Presteert beter dan thin-client en is makkelijker te beheren als fat-client
Samenvatting slides AO
Bram Van den Brande
Distributed object architectures
Geen sever/client onderscheid
Elke gedistributeerde entiteit is een object dat services voorziet voor andere objecten en
services ontvangt dan andere objecten
Object communicatie gebeurd via middleware adhv request broker
Complexer 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 system
Geen services provision logisch model omdat er afzonderlijek datamanagemnt services zijn
Database kunne worden bijgeveogd zonder onderbrekeing vh systeem
Nieuwe relatietypes kunnen worden omschreven door toevoeging van nieuw inegrator objects
CORBA( slide 31-40)
Peer-to-peer architectures
Gedecantraliseerde systemen waar bewerkingen kunnen worden uitgeveod in elke node in het
network
Totaal systeem haalt werkracht uit het grote aantal computers over het netwerk
P2P architectural models
Samenvatting slides AO
Bram Van den Brande
Decantralised arch
Semi-centralised arch
Hoofdstuk 13 : Application architectures
Application types
- Data processing apps:
o Data driven apps die data verwerken in batch
Vb: billing systeem, pay-roll systeem
- Transaction processing apps:
o Data centred apps die user requests verwerken en info updaten in databases
Vb: e-commerce systeem,reservation systeem
- Event processing systems:
o Interpreteert evens en reageert
Vb: word prcessors, real-time systems
- Lanuage processing systems:
o Formele taal wordt geïnterpreteerd en uitgevoerd door het systeem
Vb:Compilers, command interpreters
Samenvatting slides AO
Bram Van den Brande
Data processing systems
Input-proces-ouptu systeem
Voorbeeld dfd payroll
Transaction processing systems
Verwerkt queries qls dml opdrqchten vd gebruiker
Vb: ATM
Samenvatting slides AO
Bram Van den Brande
Transaction management
E-commerce system architecture
Internet based resource management systemen die elektronische orders aanvaarden
Meestal multi tier met app layers geassocieerd met elke tier
Event-processin systems
Geven respons op event
Sleutel karakteristiek: opvangen van onvoorspelbaarheid vd event-timing
Language processing sytems
Aanvaarden natuurlijke of artificiële taal en generen er een ander van
Hoofdstuk 19 : Component based software engineering
CBSE essentials
Onafhankelijek compoenten gespeciefieerd door hun interfaces
Somponent standaards
Samenvatting slides AO
Bram Van den Brande
Middleware voorziet ondersteuning
Hergebruik
CBSE & design principals
Hergebruik:
- onafhankelijke componenten  geen interferentie
- verborgen implementatie
- communicatie via goed gedefineerde interfaces
- shared component platforms
Components
Bieden 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 models
Definietive standard ve implementatie ve component
Het specifieert hoe interfaces moeten worden gespeciefieerd en welken elementen moeten
worden opgenomen inde interface def
Elements of a component model
Middelware support
Component models zijn de basis voor middleware support
Component models implementaties bestaan uit :
-platfrom services:laten componetne communiceren
-horizontale servces:app nahfankelijke services gebruikt door veschillende
componenten
Platfrom en honrizontal:
Samenvatting slides AO
Bram Van den Brande
CBSE proces (info)
Component identification proces (info)
Component composition
Types:
 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 interface
Vb:
Adapter components:
Interfaces v samen te stellen componenten,bij incomptabiliteit, wordt met een ADAPTOR
compatble gemaakt
Zodat types kunne verschillend zijn.
Hoofdstuk 22 : Verificatie & validatie
Verificatie <> validatie
Verificatie: software conform aan specificatie?
Validatie:doet software wat gevraagd is ?
V&C proces
In volledige life-cycle toepassen
Fouten ontdekken
Evaluatie vh systeem
Vertrouwen wekken dat het systeem doelgeschikt is
Hoeft 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
Testing
Types
- Defect testing:
o Systeem fouten ontdekken
o Succesvol als men fout heeft gevonden
- Validatie testing:
o Aantonen dat software voldoet aan eisen
o Succesvol als blijkt dat vereisten goed zijn geïmplementeerd
Debugging
Locaiseren en corrieren van de bij test gevonden fouten
Proces:
V& V planning
Moet worden gestart met ontwikkelingsproces
Evenwicht zoeken tussen testen en verificatie
Testplanning: 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 inspections
Nagaan vd source met mensen ,zonder uitvoering van iets, om fouten op te sporen
Succes: meerder fouten bij 1 inspection
Inspecties 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 analysis
Software tools voor het verwerken v source tekst
Parsen 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