The Spiral Model (Boehm, 1988) Repeat until end of project (successful completion or failure): (i) determine the set R of risks threatening the project; Barry W. Boehm if R = ∅ , the project is successfully completed (ii) assign each risk r ∈ R a risk value v ( r ) (iii) for the risk r 0 with the highest risk value , r 0 = max { v ( r ) | r ∈ R } , find a way to eliminate this risk, and go this way; if there is no way to eliminate the risk, stop with project failure Advantages : • we know early if the project goal is unreachable, • knowing that the biggest risks are eliminated gives a good feeling. – 04 – 2015-05-04 – Sspiral – 8 /91
The Spiral Model (Boehm, 1988) Repeat until end of project (successful completion or failure): (i) determine the set R of risks threatening the project; Barry W. Boehm if R = ∅ , the project is successfully completed (ii) assign each risk r ∈ R a risk value v ( r ) (iii) for the risk r 0 with the highest risk value , r 0 = max { v ( r ) | r ∈ R } , find a way to eliminate this risk, and go this way; if there is no way to eliminate the risk, stop with project failure Advantages : • we know early if the project goal is unreachable, • knowing that the biggest risks are eliminated gives a good feeling. – 04 – 2015-05-04 – Sspiral – Note: risk can by anything; e.g. open technical questions ( → prototype?), but also lead developer leaving the company ( → invest in documentation), changed market situation ( → adapt appropriate features), . . . 8 /91
Wait, Where’s the Spiral? – 04 – 2015-05-04 – Sspiral – 9 /91
Wait, Where’s the Spiral? A concrete process using the Spiral Model could look as follows: t 0 t 1 t 2 t 3 t (cost, project progress) - fix goals, conditions, - risk analysis, - develop and test, - plan next phase, – 04 – 2015-05-04 – Sspiral – 9 /91
Wait, Where’s the Spiral? A concrete process using the Spiral Model could look as follows: t 0 t 1 t 2 t 3 t (cost, project progress) - fix goals, conditions, - risk analysis, - develop and test, - plan next phase, – 04 – 2015-05-04 – Sspiral – 9 /91
– 04 – 2015-05-04 – main – Process Models 10 /91
From Procedure to Process Model A process model may describe: • organisation, responsibilities, roles; • structure and properties of documents; • methods to be used, e.g. to gather requirements or to check intermediate results • steps to be conducted during development, their sequential arrangement, their dependencies (the procedure model ); • project phases, milestones, testing criteria; • notations and languages; • tools to be used (in particular for project management). Process models typically come with their own terminology (to maximise – 04 – 2015-05-04 – Sprocesses – confusion?), e.g. what we call artefact is called product in V-Model terminology. 11 /91
From Procedure to Process Model A process model may describe: • organisation, responsibilities, roles; • structure and properties of documents; • methods to be used, e.g. to gather requirements or to check intermediate results • steps to be conducted during development, their sequential arrangement, their dependencies (the procedure model ); • project phases, milestones, testing criteria; • notations and languages; • tools to be used (in particular for project management). Process models typically come with their own terminology (to maximise – 04 – 2015-05-04 – Sprocesses – confusion?), e.g. what we call artefact is called product in V-Model terminology. Process models are legion; we will take a closer look onto: • V-Model XT , (Rational) Unified Process , Cleanroom , Agile ( XP , Scrum ) 11 /91
Light vs. Heavyweight Process Models • You may hear about “light” and “heavyweight” process models. • Sometimes, “heaviness” seems to be measured in number of rules. . . • Sometimes, “heaviness” seems to be related to flexibility, adaptability during a process. . . • “Light” sounds better than “heavy”, so advocates of a certain process model tend to tag theirs “light” and all others “heavy”. • In the end, • a process model is too “light” if it doesn’t support you in doing things which are useful and necessary for your project; • a process model is too “heavy” if it forces you to do things which are neither necessary nor useful for your project. – 04 – 2015-05-04 – Sprocesses – • Thus following (Ludewig and Lichter, 2013), we will not try to assign the following process models to a “weight class”. 12 /91
– 04 – 2015-05-04 – Sprocesses – Phase Models 13 /91
The Phase Model • The project is planned by phases , delimited by well-defined milestones . • Each phase is assigned a time/cost budget. • Phases and milestones may be part of the development contract; partial payment when reaching milestones. • Roles, responsibilities, artefacts defined as needed . • By definition, there is no iteration of phases . • But activities may span multiple phases . • Not uncommon for small projects (few software people, small product size), small companies. – 04 – 2015-05-04 – Sprocesses – 14 /91
– 04 – 2015-05-04 – main – V-Modell XT 15 /91
�������������������������������� �������� � ��� – 04 – 2015-05-04 – Svxt – 16 /91
V-Modell XT • There are different V-shaped (in a minute) process models , we discuss the (German) “V-Modell”. • “V-Modell” : developed by company IABG in cooperation with the Federal Office for Defence Technology and Procurement (‘Bundesministerium f¨ ur Verteidigung’), released 1998 • (German) government as customer often requires usage of the V-Modell • 2012: “ V-Modell XT ” Version 1.4 (Extreme Tailoring) (V-Modell XT, 2006) – 04 – 2015-05-04 – Svxt – 17 /91
V-Modell XT: Project Types project customer developer customer/developer customer/developer ‘Auftraggeber’ ‘Auftragnehmer’ ‘Auftragg.’/‘Auftragn.’ ‘Auftragg.’/‘Auftragn.’ role introduction and system development system development system development project maintenance of project (AG) project (AN) project (AG/AN) type specific process model introduction and HW system SW system HW-SW System project maintenance of system/embedded integration subject specific process model V-Modell XT offers support for four different project types : – 04 – 2015-05-04 – Svxt – 18 /91
V-Modell XT: Project Types project customer developer customer/developer customer/developer ‘Auftraggeber’ ‘Auftragnehmer’ ‘Auftragg.’/‘Auftragn.’ ‘Auftragg.’/‘Auftragn.’ role introduction and system development system development system development project maintenance of project (AG) project (AN) project (AG/AN) type specific process model introduction and HW system SW system HW-SW System project maintenance of system/embedded integration subject specific process model V-Modell XT offers support for four different project types : • AG : project from the perspective of the customer (create call for bids, choose developer, accept product) – 04 – 2015-05-04 – Svxt – 18 /91
V-Modell XT: Project Types project customer developer customer/developer customer/developer ‘Auftraggeber’ ‘Auftragnehmer’ ‘Auftragg.’/‘Auftragn.’ ‘Auftragg.’/‘Auftragn.’ role introduction and system development system development system development project maintenance of project (AG) project (AN) project (AG/AN) type specific process model introduction and HW system SW system HW-SW System project maintenance of system/embedded integration subject specific process model V-Modell XT offers support for four different project types : • AG : project from the perspective of the customer (create call for bids, choose developer, accept product) • AN : project from the perspective of the developer – 04 – 2015-05-04 – Svxt – (create offer, develop system, hand over system to customer) 18 /91
V-Modell XT: Project Types project customer developer customer/developer customer/developer ‘Auftraggeber’ ‘Auftragnehmer’ ‘Auftragg.’/‘Auftragn.’ ‘Auftragg.’/‘Auftragn.’ role introduction and system development system development system development project maintenance of project (AG) project (AN) project (AG/AN) type specific process model introduction and HW system SW system HW-SW System project maintenance of system/embedded integration subject specific process model V-Modell XT offers support for four different project types : • AG : project from the perspective of the customer (create call for bids, choose developer, accept product) • AN : project from the perspective of the developer – 04 – 2015-05-04 – Svxt – (create offer, develop system, hand over system to customer) • AG/AN : customer and developer from same organisation 18 /91
V-Modell XT: Project Types project customer developer customer/developer customer/developer ‘Auftraggeber’ ‘Auftragnehmer’ ‘Auftragg.’/‘Auftragn.’ ‘Auftragg.’/‘Auftragn.’ role introduction and system development system development system development project maintenance of project (AG) project (AN) project (AG/AN) type specific process model introduction and HW system SW system HW-SW System project maintenance of system/embedded integration subject specific process model V-Modell XT offers support for four different project types : • AG : project from the perspective of the customer (create call for bids, choose developer, accept product) • AN : project from the perspective of the developer – 04 – 2015-05-04 – Svxt – (create offer, develop system, hand over system to customer) • AG/AN : customer and developer from same organisation • PM : introduction or improvement of a process model 18 /91
V-Modell XT: Project Types project customer developer customer/developer customer/developer ‘Auftraggeber’ ‘Auftragnehmer’ ‘Auftragg.’/‘Auftragn.’ ‘Auftragg.’/‘Auftragn.’ role introduction and system development system development system development project maintenance of project (AG) project (AN) project (AG/AN) type specific process model introduction and HW system SW system HW-SW System project maintenance of system/embedded integration subject specific process model V-Modell XT offers support for four different project types : • AG : project from the perspective of the customer (create call for bids, choose developer, accept product) • AN : project from the perspective of the developer – 04 – 2015-05-04 – Svxt – (create offer, develop system, hand over system to customer) • AG/AN : customer and developer from same organisation • PM : introduction or improvement of a process model • project type variants : one/more customer; development/improvement/migration; maintenance 18 /91
V-Modell XT: Terminology our course V-Modell XT explanation role role (‘Rolle’) activity activity (‘Aktivit¨ at’) - step (‘Arbeitsschritt’) parts of activities artefact product (‘Produkt’) - topic (‘Thema’) parts of products - discipline (‘Disziplin’) a set of related products and activities phase project segment (?) (‘Projektabschnitt’) – 04 – 2015-05-04 – Svxt – 19 /91
V-Modell XT: Decision Points – 04 – 2015-05-04 – Svxt – 20 /91
21 /91 V-Modell XT: The V-World (naja. . . ) %''�������"�������.���'���������������� – 04 – 2015-05-04 – Svxt –
V-Modell XT: Tailoring Instance Model Instance – 04 – 2015-05-04 – Svxt – 22 /91
V-Modell XT: Customer/Developer Interface – 04 – 2015-05-04 – Svxt – 23 /91
V-Modell XT: Roles (a lot!) Project Roles : Anwender Projektleiter Pr¨ ufer SW-Entwickler Organisation Roles : – 04 – 2015-05-04 – Svxt – 24 /91
V-Modell XT: Roles (a lot!) Project Roles : Anderungssteuerungsgruppe (Change Control Board) , ¨ ¨ Anderungsverantwortlicher , Anforderungsanalytiker (AG) , Anforderungsanalytiker (AN) , Anwender , Assessor , Ausschreibungsverantwortlicher , Datenschutzverantwortlicher , Ergonomieverantwortlicher , Funktionssicherheitsverantwortlicher , HW-Architekt , HW-Entwickler , Informationssicherheitsverantwortlicher , KM-Administrator , KM-Verantwortlicher , Lenkungsausschuss , Logistikentwickler , Logistikverantwortlicher , Projektkaufmann , Projektleiter , Projektmanager , Prozessingenieur , Pr¨ ufer , QS-Verantwortlicher , SW-Architekt , SW-Entwickler , Systemarchitekt , Systemintegrator , Technischer Autor , Trainer Organisation Roles : Akquisiteur , Datenschutzbeauftragter (Organisation) , Eink¨ aufer , – 04 – 2015-05-04 – Svxt – IT-Sicherheitsbeauftragter (Organisation) , Qualit¨ atsmanager 24 /91
V-Modell XT: Disciplines and Products (even more!) – 04 – 2015-05-04 – Svxt – 5������L����������� 25 /91
V-Modell XT: Disciplines and Products (even more!) – 04 – 2015-05-04 – Svxt – 5������L����������� 25 /91
V-Modell XT: Activities (as many?!) – 04 – 2015-05-04 – Svxt – 26 /91
V-Modell XT: Activities (as many?!) – 04 – 2015-05-04 – Svxt – 26 /91
V-Modell XT: Procedure Building Blocks • a discipline comprises one or more product • a product may be external (‘E’) or initial (‘I’), i.e. created always and exactly once (e.g. project plan) • a product may consist of topics • a product may depend on other products – 04 – 2015-05-04 – Svxt – • an activity creates a product and belongs to a discipline • an activity may consist of steps • a step works on a topic • a role may be responsible for a product or contribute • each product has at most one responsible role 27 /91
V-Modell XT: Example Building Block – 04 – 2015-05-04 – Svxt – SW-Development (‘SW-Entwicklung’) 28 /91
V-Modell XT: Example Building Block spec. of . . . vs. coding . . . programmer – 04 – 2015-05-04 – Svxt – SW-Development (‘SW-Entwicklung’) 28 /91
V-Modell XT: Development Strategies Recall the idea of the “V shape” : verification & validation acceptance acceptance requirements requirements fixed fixed system system system system specified specified delivered delivered architecture architecture system system integrated integrated designed designed modules modules system system designed designed realised realised – 04 – 2015-05-04 – Svxt – 29 /91
V-Modell XT: Development Strategies Recall the idea of the “V shape” : verification & validation acceptance acceptance requirements requirements fixed fixed system system system system specified specified delivered delivered architecture architecture system system integrated integrated designed designed modules modules system system designed designed realised realised V-Modell XT mainly supports three strategies to develop a system, i.e. principal sequences between decision points : – 04 – 2015-05-04 – Svxt – • incremental, • component based, • prototypical. 29 /91
V-Modell XT: Development Strategies verification & validation requirements requirements acceptance acceptance fixed fixed system system system system specified specified delivered delivered system system architecture architecture integrated integrated designed designed modules modules system system designed designed realised realised – 04 – 2015-05-04 – Svxt – incremental component based prototypical 30 /91
V-Modell XT: Discussion Advantages : • certain management related building block are part of each project, thus they may receive increased attention of management and developers • publicly available , can be used free of license costs • very generic , support for tailoring • comprehensive , low risk of forgetting things Disadvantages : • comprehensive , tries to cover everything; tailoring is supported, but may need high effort • tailoring is necessary , otherwise a huge amount of useless documents is created • description/presentation leaves room for improvement – 04 – 2015-05-04 – Svxt – Needs to prove in practice, in particular in small/medium sized enterprises (SME). 31 /91
Rational Unified Process – 04 – 2015-05-04 – main – 32 /91
Rational Unified Process (RUP) Exists. • in contrast to “V-Modell XT”, a commercial product – 04 – 2015-05-04 – Srup – 33 /91
Agile Process Models – 04 – 2015-05-04 – main – 34 /91
The Agile Manifesto “Agile denoting ‘the quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion’ software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment.” (Abrahamsson et al., 2002) – 04 – 2015-05-04 – Sagile – 35 /91
The Agile Manifesto “Agile denoting ‘the quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion’ software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment.” (Abrahamsson et al., 2002) The Agile Manifesto (2001): We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation – 04 – 2015-05-04 – Sagile – Customer collaboration over contract negotiation Responding to change over following a plan that is, while there is value in the items on the right , we value the items on the left more. 35 /91
Agile Principles • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements , even late in development. Agile processes harness change for the customers competitive advantage. • Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale. – 04 – 2015-05-04 – Sagile – 36 /91
Agile Principles • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements , even late in development. Agile processes harness change for the customers competitive advantage. • Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals . Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation . – 04 – 2015-05-04 – Sagile – 36 /91
Agile Principles • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements , even late in development. Agile processes harness change for the customers competitive advantage. • Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals . Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation . • Working software is the primary measure of progress. • Agile processes promote sustainable development . The sponsors, developers, and users should be able to maintain a constant pace indefinitely. – 04 – 2015-05-04 – Sagile – • Continuous attention to technical excellence and good design enhances agility. 36 /91
Agile Principles • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements , even late in development. Agile processes harness change for the customers competitive advantage. • Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals . Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation . • Working software is the primary measure of progress. • Agile processes promote sustainable development . The sponsors, developers, and users should be able to maintain a constant pace indefinitely. – 04 – 2015-05-04 – Sagile – • Continuous attention to technical excellence and good design enhances agility. • Simplicity the art of maximizing the amount of work not done is essential. • The best architectures, requirements, and designs emerge from self-organizing teams . • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly . 36 /91
Similarities of Agiles Process Models • iterative; cycles of a few weeks, at most three months, • require work in small groups (6–8 people), • dislike the idea of large, comprehensive documentation (radical or with restrictions), • consider the customer important; recommend or request customer’s presence in the project, • dislike dogmatic rules. (Ludewig and Lichter, 2013) – 04 – 2015-05-04 – Sagile – 37 /91
Extreme Programming (XP) – 04 – 2015-05-04 – Sagile – 38 /91
Extreme Programming (XP) (Beck, 1999) XP values : • simplicity , feedback , communication , courage , respect . XP practices : • management • team : • programming • integral team • joint responsibility for • test driven development (including customer) the code • refactoring • planning game • coding conventions • simple design ( → Delphi method) • acceptable workload • pair programming • short release cycles • central metaphor • stand-up meetings • continuous integration • assess in hindsight – 04 – 2015-05-04 – Sagile – 39 /91
Extreme Programming (XP) (Beck, 1999) XP values : • simplicity , feedback , communication , courage , respect . XP practices : • management • team : • programming • integral team • joint responsibility for • test driven development (including customer) the code • refactoring • planning game • coding conventions • simple design ( → Delphi method) • acceptable workload • pair programming • short release cycles • central metaphor • stand-up meetings • continuous integration • assess in hindsight – 04 – 2015-05-04 – Sagile – spec. of . . . tests for . . . coding . . . . . . ✘ programmer programmer 39 /91
– 04 – 2015-05-04 – Sagile – Scrum 40 /91
Scrum • first published 1995 (Schwaber, 1995), based on ideas of Takeuchi and Nonaka • inspired by Rugby: get the ball in a scrum , then sprint to score • role-based; iterative and incremental; in contrast to XP no techniques proposed/required – 04 – 2015-05-04 – Sagile – 41 /91
Scrum • first published 1995 (Schwaber, 1995), based on ideas of Takeuchi and Nonaka • inspired by Rugby: get the ball in a scrum , then sprint to score • role-based; iterative and incremental; in contrast to XP no techniques proposed/required Three roles : • scrum team : • scrum master : • product owner : – 04 – 2015-05-04 – Sagile – 41 /91
Scrum • first published 1995 (Schwaber, 1995), based on ideas of Takeuchi and Nonaka • inspired by Rugby: get the ball in a scrum , then sprint to score • role-based; iterative and incremental; in contrast to XP no techniques proposed/required Three roles : • scrum team : • scrum master : • product owner : • representative of customer, • maintains requirements in the product backlog , • plans and decides which requirement(s) to realise – 04 – 2015-05-04 – Sagile – in next sprint, • (passive) participant of daily scrum , • assesses results of sprints 41 /91
Scrum • first published 1995 (Schwaber, 1995), based on ideas of Takeuchi and Nonaka • inspired by Rugby: get the ball in a scrum , then sprint to score • role-based; iterative and incremental; in contrast to XP no techniques proposed/required Three roles : • scrum team : • scrum master : • product owner : • members capable of • representative of developing autonomously, customer, • decides how and how • maintains requirements many requirements to in the product backlog , realise in next sprint, • plans and decides which • distribution of tasks requirement(s) to realise – 04 – 2015-05-04 – Sagile – self-organised, team in next sprint, decides who does what • (passive) participant of when, daily scrum , • environment needs to • assesses results of support communication sprints and cooperation, e.g. by spatial locality 41 /91
Scrum • first published 1995 (Schwaber, 1995), based on ideas of Takeuchi and Nonaka • inspired by Rugby: get the ball in a scrum , then sprint to score • role-based; iterative and incremental; in contrast to XP no techniques proposed/required Three roles : • scrum team : • scrum master : • product owner : • members capable of • helps to conduct scrum the • representative of developing autonomously, right way, customer, • decides how and how • looks for adherence to • maintains requirements many requirements to process and rules, in the product backlog , realise in next sprint, • ensures that the team is • plans and decides which • distribution of tasks not disturbed from requirement(s) to realise – 04 – 2015-05-04 – Sagile – self-organised, team outside, in next sprint, decides who does what • moderates daily scrum , • (passive) participant of when, responsible for keeping daily scrum , • environment needs to product backlog • assesses results of support communication up-to-date, sprints and cooperation, e.g. by • should be able to assess spatial locality techniques and approaches 41 /91
Scrum Documents • product backlog • sprint backlog • comprises all requirements to be realised, • requirements to be realised in next spring, taken from product backlog, • priority and effort estimation for requirements, • more precise estimations, • collects tasks to be conducted, • daily update (tasks done, new tasks, new estimations) • maintained by product owner • sprint-burndown report • release plan • completed/open tasks from sprint • based on initial version of product backlog, backlog, • should decrease linearly, otherwise • how many sprints, which major remove tasks from sprint backlog, requirements in which sprint, • sprint report • release-burndown report – 04 – 2015-05-04 – Sagile – • which requirements have (not) been • see sprint-burndown report realised in last sprint, • description of obstacles/problems during sprint 42 /91
Scrum Process requirements workshop sprint Sprint Backlog sprint Product Backlog planning realisation Sprint daily scrum Burndown release Release Plan planning review Release Burn. retrospective Sprint Report Product Increment • daily scrum : • daily meeting, 15 min. • discuss progress, synchronise day plan, discuss and document new obstacles • team members, scrum master, product owner (if possible) – 04 – 2015-05-04 – Sagile – • sprint : at most 30 days, usually shorter (initially longer) • sprint review : assess amount and quality of realisations; product owner accepts results • sprint retrospective : assess how well the scrum process was implemented; identify actions for improvement (if necessary) 43 /91
Scrum: Discussion • has been used in many projects, experience in majority positive • team size bigger 7–10 may need scrum of scrums • competent product owner necessary for success • success depends on motivation, competence, and communication skills of team members • team members responsible for planning, and for adhering to process and rules, thus intensive learning and experience necessary • can (as other process models) be combined with techniques from XP – 04 – 2015-05-04 – Sagile – 44 /91
Software and Process Metrics – 04 – 2015-05-04 – main – 45 /91
Software and Process Metrics • To systematically compare and improve industrial products, we need to precisely describe and assess the products and the process of creation . • This common practice for many material good, e.g. cars • fuel consumption, • size of trunk, • fixed costs per year, • time needed to change headlight’s light bulb, • clearance (accuracy of fit and gaps of, e.g., doors) • . . . Note : all these key figures are models of products — they reduce everything but the aspect they are interested in. – 04 – 2015-05-04 – Smetricintro – • Less common practice for immaterial goods like Software. • It should be — (objective) measures are central to engineering approaches. • Yet: it’s not that easy for software. 46 /91
Excursion: Scales – 04 – 2015-05-04 – main – 47 /91
Scales and Types of Scales • measuring maps elements from a set A to a scale M : m : A → M • we distinguish (i) nominal scale • operations: = (and � = ) (ii) ordinal scale • operations: = , < / > (with transitivity), min / max , percentiles (e.g. median) (iii) interval scale (with units) • operations: = , < , > , min / max , percentiles, ∆ – 04 – 2015-05-04 – Sscales – (iv) rational scale (with units) • operations: = , < , > , min / max , percentiles, ∆ , proportion, 0 (v) absolute scale • a rational scale where M comprises the key figures itself 48 /91
Nominal Scale m : A → M • operations: = (and � = ) • that is, there is no (natural) order between elements of M , • the lexicographic order can be imposed, but is not related to measured information (thus not natural). • general example : • nationality, gender, car manufacturer, geographic direction, . . . • Autobahn number, train number, . . . • software engineering example : • programming laguage – 04 – 2015-05-04 – Sscales – • 49 /91
Ordinal Scale m : A → M • operations: = , < , > , min / max , percentiles (e.g. median) • there is a (natural) order between elements of M , but no (natural) notion of distance or average • general example : • strongly agree > agree > disagree > strongly disagree • administrative ranks: Chancellor > Minister • ranking list, leaderboard: finishing number tells us who was, e.g. faster, than who; but nothing about how much faster 1st was than 2nd • types of scales, . . . – 04 – 2015-05-04 – Sscales – • software engineering example : • CMMI scale (maturity levels 1 to 5) • 50 /91
Interval Scale m : A → M • operations: = , < , > , min / max , percentiles, ∆ • there’s a (natural) notion of difference ∆ : M × M → R , • but no (natural) 0 • • general example : • temperature in Celsius (no zero), • year dates, two persons, born B 1 , B 2 , died D 1 , D 2 (all dates beyond, say, 1900) — if ∆( B 1 , D 1 ) = ∆( B 2 , D 2 ) , they reached the same age – 04 – 2015-05-04 – Sscales – • software engineering example : • time of check-in in revision control system, • 51 /91
Rational Scale m : A → M • operations: = , < , > , min / max , percentiles, ∆ , proportion, 0 • the (natural) zero induces a meaning for proportion m 1 /m 2 • general example : • age (“twice as old”), finishing time, weight, pressure, . . . • price, speed, distance from Freiburg, . . . • software engineering example : • runtime of a program for certain inputs, • – 04 – 2015-05-04 – Sscales – 52 /91
Absolute Scale m : A → M • M = N 0 , • a rational scale where M comprises the key figures itself • absolute scale has median , but in general not an average in the scale. • general example : • seats in a bus, number of public holidays, number of inhabitants of a country, . . . • “average number of children per family: 1.203” – what is a 0.203-child? the absolute scale has been viewed as a rational scale, makes sense for certain purposes • software engineering example : – 04 – 2015-05-04 – Sscales – • number of known errors, • 53 /91
Communicating Figures – 04 – 2015-05-04 – Sscales – 54 /91
Median and Box-Plots M 1 M 2 M 3 M 4 M 5 LOC 127 213 152 139 13297 • arithmetic average : 2785 . 6 • median : 127, 139, 152 , 213, 13297 – 04 – 2015-05-04 – Sscales – 55 /91
Median and Box-Plots M 1 M 2 M 3 M 4 M 5 LOC 127 213 152 139 13297 • arithmetic average : 2785 . 6 • median : 127, 139, 152 , 213, 13297 • a boxplot visualises 5 aspects of data at once (whiskers sometimes defined differently, with “outliers”): 100 % (maximum) – 04 – 2015-05-04 – Sscales – 75 % (3rd quartile) 50 % (median) 25 % (1st quartile) 0 % (minimum) 55 /91
Median and Box-Plots M 1 M 2 M 3 M 4 M 5 LOC 127 213 152 139 13297 • arithmetic average : 2785 . 6 • median : 127, 139, 152 , 213, 13297 • a boxplot visualises 5 aspects of data at once (whiskers sometimes defined differently, with “outliers”): 40.000 100 % (maximum) 30.000 – 04 – 2015-05-04 – Sscales – 75 % (3rd quartile) 20.000 50 % (median) average: 7,033.027 10.000 25 % (1st quartile) median: 2,078 0 % (minimum) LOC lecture’s *.tex files 55 /91
Software Metrics – 04 – 2015-05-04 – main – 56 /91
Software Metrics metric — A quantitative measure of the degree to which a system, compo- nent, or process posesses a given attribute. See: quality metric. IEEE 610.12 (1990) – 04 – 2015-05-04 – Smetrics – 57 /91
Software Metrics metric — A quantitative measure of the degree to which a system, compo- nent, or process posesses a given attribute. See: quality metric. IEEE 610.12 (1990) quality metric — (1) A quantitative measure of the degree to which an item possesses a given quality attribute. (2) A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the software possesses a given quality attribute. IEEE 610.12 (1990) – 04 – 2015-05-04 – Smetrics – 57 /91
Software Metrics metric — A quantitative measure of the degree to which a system, compo- nent, or process posesses a given attribute. See: quality metric. IEEE 610.12 (1990) quality metric — (1) A quantitative measure of the degree to which an item possesses a given quality attribute. (2) A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the software possesses a given quality attribute. IEEE 610.12 (1990) – 04 – 2015-05-04 – Smetrics – 57 /91
Recall: Metric Space [math.] Definition. [ Metric Space ] Let X be a set. A function d : X × X → R is called metric on X if and only if, for each x, y, x ∈ X , (i) d ( x, y ) ≥ 0 (non-negative) (ii) d ( x, y ) = 0 ⇐ ⇒ x = y (identity of indiscernibles) (iii) d ( x, y ) = d ( y, x ) (symmetry) (iv) d ( x, z ) ≤ d ( x, y ) + d ( y, z ) (triangle inequality) ( X, d ) is called metric space . – 04 – 2015-05-04 – Smetrics – 58 /91
Software Metrics: Motivation and Goals Important motivations and goals for using software metrics: • Support decisions • Quantify experience, progress, etc. • Assess the quality of products and processes • Predict cost/effort, etc. – 04 – 2015-05-04 – Smetrics – 59 /91
Software Metrics: Motivation and Goals Important motivations and goals for using software metrics: • Support decisions • Quantify experience, progress, etc. • Assess the quality of products and processes • Predict cost/effort, etc. Metrics can be used: • descriptive or prescriptive : • “the current average LOC per module is N ” vs. “a prodecure must not have more then N parameters” • a descriptive metric can be diagnostic or prognostic : • “the current average LOC per module is N ” vs. “the expected test effort is N hours” – 04 – 2015-05-04 – Smetrics – • Note : prescriptive and prognostic are different things. 59 /91
Software Metrics: Motivation and Goals Important motivations and goals for using software metrics: • Support decisions • Quantify experience, progress, etc. • Assess the quality of products and processes • Predict cost/effort, etc. Metrics can be used: • descriptive or prescriptive : • “the current average LOC per module is N ” vs. “a prodecure must not have more then N parameters” • a descriptive metric can be diagnostic or prognostic : • “the current average LOC per module is N ” vs. “the expected test effort is N hours” – 04 – 2015-05-04 – Smetrics – • Note : prescriptive and prognostic are different things. • Examples for diagnostic / guiding use: • measure time spent per procedure before starting “optimisations”, • focus testing effort accordingly, e.g. guided cyclomatic complexity, • develop measures indicating architecture problems, (analyse,) then focus re-factoring 59 /91
Requirements on Useful Metrics Definition. A thing which is subject to the application of a metric is called proband . The value m ( P ) yielded by a given metric m on a proband P is called valuation yield (‘Bewertung’) of P . – 04 – 2015-05-04 – Smetrics – 60 /91
Requirements on Useful Metrics Definition. A thing which is subject to the application of a metric is called proband . The value m ( P ) yielded by a given metric m on a proband P is called valuation yield (‘Bewertung’) of P . In order to be useful, a (software) metric should be: • differentiated • comparable • reproducible • available • relevant – 04 – 2015-05-04 – Smetrics – • economical • plausible • robust 60 /91
Requirements on Useful Metrics Definition. A thing which is subject to the application of a metric is called proband . The value m ( P ) yielded by a given metric m on a proband P is called valuation yield (‘Bewertung’) of P . In order to be useful, a (software) metric should be: • differentiated – worst case: same valuation for all probands • comparable • reproducible • available • relevant – 04 – 2015-05-04 – Smetrics – • economical • plausible • robust 60 /91
Requirements on Useful Metrics Definition. A thing which is subject to the application of a metric is called proband . The value m ( P ) yielded by a given metric m on a proband P is called valuation yield (‘Bewertung’) of P . In order to be useful, a (software) metric should be: • differentiated – worst case: same valuation for all probands • comparable – ordinal scale, better: rational (or absolute) scale • reproducible • available • relevant – 04 – 2015-05-04 – Smetrics – • economical • plausible • robust 60 /91
Recommend
More recommend
