Hoorcollege SDM1 7 Maart 2006 Mario van Vliet - 1 -

Presentatie over: "Hoorcollege SDM1 7 Maart 2006 Mario van Vliet - 1 -"— Transcript van de presentatie:

1 Hoorcollege SDM1 7 Maart 2006 Mario van Vliet - 1 -

2 Data Colleges worden gegeven op de volgende data: - 7 Februari - 7 Maart - 21 Maart - 4 April - 18 April - 9 Mei - 23 Mei - 6 Juni Één college zal in de vorm van een gastcollege worden gegeven - 2 -

3 Onderwerpen die in SDM1 aan bod komen Projectmanagement Metrics: Vandaag Projectplanning Business Planning Technical Planning Rollen van Projectmanager Qualitymanager Contract Owner Public Relations Manager Director Planningsmethodieken PERT CPM Work Breakdown structure Gantt-charts Quality Management Risk Management Component Based Development - 6 -

4 Metrics How to measure and assess software engineering?

5 Contents Wat zijn software metrics Waarom is measurement belangrijk? Software Quality Qualitative measures Quantitative measures Slotopmerkingen

6 Metrics Wat is een metric? – “A quantitative measure of the degree to which a system, component or process pocesses a given attribute” (IEEE Software Engineering Standards 1993) : Software Quality Anders dan – Measure (size of a system, component e.d) – Measurement (act of determining a measures) Metrics – Quantitative Metrics – Qualitative Metrics

7 Metrics Waarom zijn metrics belangrijk? – To characterize – To evaluate – To predict – To improve – Requirements are the foundation to measure software quality – Standards define the development criteria for software engineering – Software quality should conform to both explicit requirements as well as implicit requirements Waarom is meten moeilijk? –Geen exacte wetenschap (‘measure the unmeasurable’) –Afhankelijk van technische omgeving –Afhankelijk van organisatorische omgeving –Afhankelijk van toepassing en ‘fitness for use’

8 Software Quality: de attributen Software Quality Factors (McCall): Product Revision Product Transition Maintainability Flexibility Testability Portability Reusability Interoperability Correctness Usability Efficiency Reliability Integrity Product Operation

9 Software Quality: Qualitative Measures Drie modellen: McCall (1977), FURPS, ISO 9126 McCall: Metrics that affect cq influence software quality factors: – Software Quality factor is de afhankelijke variabele, de metric is de onafhankelijke variabele – Metrics: audibility, accuracy, communication commonality, completeness, consistency, data commonality, error tolerance, execution efficiency, expandability, generality, hardware independence, instrumentation, modularity, operability, security, self- documentation, simplicity, software system independence, traceability, training. – Formula: Software quality factor= c 1 x m 1 + c 2 x m 2 + … + c n x m n – C n is a regression coefficient based on empirical data – Software quality factor gives an indication of the quality of the software

10 McCall Matrix CorrectnessReliabilityEfficiencyIntegrityMaintainabilityFlexibilityTestabilityPortabilityReusabilityInteroperabilityUsability AudibilityXX Accuracyx Communication Comm.x Completenessx Complexityxxx Concisenessxxx Consistencyxxxx Data Commonalityx Error Tolerancex Execution Efficiencyx Expandabilityx GeneralityXxxx Hardware Independ.xx Instrumentationxxx ModularityxxxxxxX Operabilityxx Securityxx Self Documentationxxxxx Simplicityx System Independancexx Traceabilityx Trainingx Quality Factor Software Quality Metric

11 FURPS Functionality: – Feature set and capability of the system – Generality of the functions – Security of the overall system Usability: – Human factors (aesthetics, consistency and documentation) Reliability: – Frequency and severity of failure – Accuracy of output – MTTF – Failure recovery and predictability Performance: – Speed, response time, resource consumption, throughput and efficiency Supportability: – Extensibility – Maintainability – Configurability – Etc.

12 ISO 9126 Quality Factors Functionality Reliablity Usability Efficiency Maintainability Portability

13 Software Quality: Quantitative Metrics Eigenschappen van Metrics – Simpel en berekenbaar – Empirisch en intuitief overtuigend – Consistent en objectief – Consistent in het gebruik van units en dimensies – Onafhankelijk van programmeertaal en technische omgeving – Effectief mechanisme voor quality review en feedback Type Metrics – Size-Oriented Sterk gefocussed op de omvang van de software (LOC, Errors, Defects, size of documentation) – Function-oriented Gefocused op de realisatie van een functie van een systeem (zie eerdere definitie van metric)

14 Function Oriented Metrics Functie Punt Analyse (FPA) ‘een techniek voor het meten van de op te leveren functies van een informatie systeem vanuit het perspectief van de eindgebruiker’ – Techniek voor het bepalen van de omvang van een systeem op basis van een functionele specificatie – Gericht op het bepalen van de omvang van een systeem met als doel het realiseren van de op te leveren functies – In principe onafhankelijk van programmeertaal en technische omgeving – Te gebruiken voor het bepalen van de hoeveelheid werk dat nodig is om een systeem op te leveren (aandacht in het vervolg) Het bepalen van een ‘productivity measure’ in benchmarking na oplevering van het systeem of in vergelijk met andere systemen cq. omgevingen

15 Function Point Analysis Basis is de Functie Punt Index (FPI) van een te bouwen informatiesysteem. Voor het bepalen van de hoeveelheid werk dat moet worden verricht voor het bouwen van een systeem wordt de volgende formule gehanteerd: Functie Punt Index *Resource factor 1 = Hoeveelheid werk 1 Resource factor hangt af van de ontwikkelomgeving, de ervaringsfactor die professionals hebben met de omgeving en tools en de omvang van het projectteam. Om een inschatting te krijgen van de resource factor zijn benchmarks en ervaringscijfers beschikbaar.

16 Functie Punt Index Hoe bereken je een FPI van een te bouwen systeem? Hiervoor doorlopen we de volgende drie stappen: Bepalen Functie Punt Index Bepalen System Attributes Bepalen ‘Value Adjustment”

17 System Attributes Functie Punt analyse begint met het bepalen van de ‘system attributes’ van een systeem. Dit betekent dat het aantal system attributes waar het systeem uit is opgebouwd wordt geidentificeerd. FPA onderscheidt de volgende attributes: 1.User External Inputs (EI) 2.User External Outputs (EO) 3.User External Inquiries (IQ) 4.User Logical Master Files (MF) 5.Interfaces to other systems (IF) Systeem Omgeving Andere Systemen Transacties Externe Gebruiker Transacties Interface MFs EI EO IQ IF

18 System Attributes Nadat de system attributes in kaart zijn gebracht wordt per system attribute bepaald hoe ‘zwaar’ de system attributes is: – Low – Medium – High Voor de bepaling van de ‘waarde’ van de system attribute wordt de volgende matrix gehanteerd: Totale gewogen som van de system attributes is de ‘Unadjusted Function Point Index’ (UF) System AttributeLowMediumHigh User External Input 346 User External Output 457 User Exteral Inquiry 346 User Logical Master File 71015 Interfaces 5710

19 Value Adjustment In de tweede stap wordt de functie punt waarde aangepast voor de omgeving waarin het systeem zal gaan opereren. Hiertoe wordt de ‘degree of influence’ bepaald voor de volgende 14 ‘values adjustment ‘ factoren. – Data Communications – Distributed Processing – Performance Objectives – Tight Configuration – Transaction Volume – On-line Data Entry – End User Efficiency – Logical File Updates – Complex Processing – Design for Re-usability – Conversion and Installation Ease – Multiple Site Implementation – Ease of Change and Use Waarde tussen 0 en 5

20 Bepalen Functie Punt Index 1.Totale sum van de ‘degree of influence’ (DI) 2.Bepaal Value Adjustment : VA= 0,65+ (0,01*DI) 3.Functie Punt Index = VA*UF

21 Voorbeeld Alarm Gebruiker’s Interactie Module Functie: Gebruiker Password Sensor opvragen Panic button Zone opvragen Aan/Uit Systeem Configuratie Data Sensors Gebruiker Externe Monitoring Test Sensor Zone instellen Berichten Sensor Status Aan/Uit Alarm AlertPassword, sensors etc.

22 Oefening Bepaal het aantal system attributes: 1.User External Inputs (EI) 2.User External Outputs (EO) 3.User External Inquiries (IQ) 4.User Logical Master Files (MF) 5.Interfaces to other systems (IF)

23 Bepalen UF System AttributeAantalLowMediumHighTotaal User External Input 33469 User External Output 24578 User External Inquiry 23466 User Logical Master File 1710157 Interfaces 4571020 Totaal 50

24 Slotopmerkingen Metrics zijn te gebruiken om een relatief inzicht te krijgen in de meetbaarheid van een systeem, het geeft geen absoluut inzicht! Metrics hebben altijd kwantitatieve elementen in zich èn kwalitatieve elementen Besef dat je ‘onmeetbare’ elementen probeert te meten Gebruik metrics voor het bepalen van de functionaliteit van een systeem op basis van de wensen van de eindgebruiker Gebruik metrics voor: – To characterize – To evaluate – To predict – To improve