INF5181: Process Improvement and Agile Methods in Systems ...€¦ · • 10-Sep-2012: Homework 1...

INF5181 / Lecture 11 / © Dietmar Pfahl 2012

INF5181: Process Improvement and Agile Methods in Systems Development

Lecture 11: ● SPI & Empirical Research

Methods

Dr. Dietmar Pfahl

email: [email protected] 2012


Structure of Lecture 11

• Hour 1:– Project Report – Question/Answer– SPI and Empirical Research Methods

• Hour 2:– SPI and Empirical Research Methods (cont'd)

• Hour 3:– Course Review and Oral Exam


Project & Exam Schedule

• 10-Sep-2012: Homework 1 – Process Modeling

– Deliver PDF by email to [email protected] at 15:30

• 20-Sep-2012: Student Presentation (5 min)

– Send slides at the latest 24 hours before presentation by email to [email protected]

• 15-Oct-2012: Homework 2 – Measurement

– Deliver PDF by email to [email protected] at 15:30

• 15-Nov-2012: Project Report

– Deliver PDF by email to [email protected] before 20:00

– Evaluation results ready one week before oral exam

• 13/14-Dec-2012: Oral Exam (15-20 min)


Project Report – Structure

• Cover page (Title, Author, Date, Email, Course ID, ...)

• Table of content

• Content:– Improvement context (Type of company, product, process)

– Improvement Goal(s) (What? How much? When?)

– Suggested changes of SW development process (What? / Scope, Old process vs. New process)

– Implementation of process changes (When? Who is responsible?)

– Monitoring/Control (How to measure success? By whom?)

– Discussion (Why? rationale for changes, risks)

– References


Hints and Tips for Project Report /1

• Improvement Goals: – Define targets (in absolute or relative terms) that can be checked --> Goals must

be measurable!

– Goals must be traceable to Issues/Problems

• Baseline vs. New (Target) Process:– All elements (entities) of the baseline process need to be defined / characterised– The relationships between all elements in the process need to be clarified

• Process Performance/Measurement: – If you don’t have complete data about the performance, complement what you

have with an expert estimate/opinion

– Current performance must relate to goals

– Measurement must relate to goals - but can also be an element of improvement



• Abbreviations / Acronyms: must be explained when used the first time!

• References– Putting a web-page as reference is not enough

– Check out proper referencing styles: ACM, IEEE or follow UiO instructions for Master Theses

– Choose the one you like but use it consistently

• Tables and Figures:– Captions: label + number + brief characterisation

– Legends (for diagrams)

– Referencing from text

– Provide a description

– Hint: Check out the reading materials or the syllabus for examples!



• Tables and Figures – Example:

• Note:

– In this example, legend is not needed because a standard notation (UML activity diagram) is used


Course Evaluation, Marking, and Grades

• Part 1: Project / 80% of grade [32 marks]

– Homework 1: Process Modeling [6 marks]

– Homework 2: Measurement [6 marks]

– Short Presentation [0 marks]

– Project Report [20 marks]

• Evaluation criteria for Project Report:

– Content [14 marks]

– Clarity/Conciseness [4 marks]

– Formality (cover page, captions, referencing, etc.) [2 marks]

Note:

• A mandatory short presentation is required

• Failing to do the oral presentation will result in a penalty of 2 marks!

• Part 2: Oral Exam / 20% of grade [8 marks]

• Duration: approximately 15-20 minutes

• Subject:

– Questions about the course (lecture, materials)

• Evaluation criteria:

– Correctness and completeness [6 marks]

– Clarity and conciseness [1 mark]

– Relevance (i.e., is the answer to the point?) [1 mark]

Total Marks in Course: 40 (100%)


Project Assignment – Evaluation /1

• Content: 14 marks (70% of total project report marks)– Relates to completeness, depth (level of detail), consistency

(correctness), and flow of argumentation (logic)

– Consistency Examples:

• Consistency between past/current problems and improvement goals

• Consistency between improvement goals and measures

• Consistency between baseline process and target process (i.e., the new process)

• Consistency between target process and implementation of target process



• Clarity/Conciseness: 4 marks (20% of total project report marks)– Focus on most important/relevant content

– Refers to the information given (goals, process elements, etc.), the presentation style (language, figures, tables), and the discussion (argumentation)

– Important: don't mix discussion with purely factual elements of the report



• Formality: 2 marks (10% of total project marks)– Correct formatting (cover page with complete information, table of

contents, page numbers, headings, table and figure captions, table and figure referencing, literature referencing, font size, etc.)

– Correct referencing style (in Section 7); also: each document listed in the reference section must be referenced from the text at least once

– Language: no spelling/grammar errors, clarity of expression, appropriateness of expression (no slang!), correct usage of terminology

– Suggested page limit: up to 15 pages (with 1.5 to 2 cm margins)

– Suggested font size: 12 points (single line spacing)


How is Research related to SPI?

• SPI may require the gathering of knowledge through research for:

– Understanding what is going on– Identification of root-causes of

perceived problems

– Decision-support, e.g.,– if there are alternative solutions

to problems (which one is best?)

– if a given solution needs to be adapted (how to adapt?)


The Wallace Model

Theories

Hypotheses(Research Questions)

Empirical Generalizations(Laws)

Observations

Research Methods

Theory ConstructionLogic (induction)

Logical Inference(deduction)

Research DesignData Analysis,Parameter Estimation

Wallace, Walter L. (1971) The Logic of Science in Sociology. New York: Aldine


Research Question – Examples

• How many defects are detected in the field?• How effective is testing?• What skills do our architects need?• What agile practices do our software engineers apply?• What types of defects do our newly hired programmers

typically make? (and why?)• What requirements analysis method works best for us? (and

why?)


Exercise

• Hanna is a young researcher in an industrial research lab. She would like to understand how developers in the business units of her company use (or not) UML diagrams during software development.

• This is because, as a student, her professors recommended UML diagrams be used during software design, but her recent exposure to industrial practices used by the developers in the company to which her lab belongs indicates that UML is rarely used.

• Her goal is to explore how widely UML diagrams are used within her company (and in industry in general), and more specifically how these diagrams are used as collaborative shared artifacts during software development.

• What could be Hanna’s first research questions?


Exercise (cont’d)

Possible Research Questions:• How often are UML diagrams used?• By whom and when are they used?• For what purpose are they used, i.e., are they used as

collaborative shared artifacts during software development?

These questions pre-suppose that:• We know what a ”shared collaborative artifact” is• We can reliably identify ”shared collaborative artifacts”• We can reliably say what ”UML diagrams” are• It is clear what we mean by ”software development”


Research Questions – Taxonomy

Exploratory Question

Design Question

Knowledge Question

Research Question

Existence Question

Description and Classification Question

Descriptive Comparative Question

Base-Rate Question

Relationship Question

Causality Question

Frequency and Distribution Question

Descriptive-Process Question

Simple Causality Question

Causality-Comparative Question

Causality-ComparativeInteraction Question


Exploratory Questions

• Existence questions Does X exist?

– Example: Do collaborative shared artifacts actually exist?

• Description and classification questions What is X like? / What are its properties? / How can it be categorized? / How can we measure it? / What is its purpose? / What are its components? / How do the components relate to each other?

– Example: What are all the types of shared collaborative artifacts?

• Descriptive comparative questions How does X differ from Y?

– Example: How do UML diagrams differ from other representations of, say, design representations?


Other Types of Research Questions

• Knowledge Questions: focusing on the way the world is

– Questions about the normal pattern of occurance of a phenomenon (Base-rate Questions)

– Questions about relationships between two different phenomena (Relationship Questions)

– Questions about causality between two phenomena (Causality Questions)

• Design Questions: concerned with how to do things better


Knowledge Questions

• Base-rate:– Frequency and Distribution Questions How often does X

occur? / What is an average amount of X?

Example: How many distinct UML diagrams are created in software development projects in large software companies?

– Descriptive-Process Questions How does X normally work? / What is the process by which X happens? / In what sequence do the events of X occur?

Example: How do software developers use UML diagrams?


Knowledge Questions (cont’d)

• Relationship:– Relationship Questions Are X and Y related? / Do

occurrences of X correlate with occurrences of Y?

Example: Do project managers’ claims about how often their teams use UML correlate with the actual use of UML?



• Causality:– Simple Causality Questions Does X cause Y? / Does X prevent

Y? / What causes Y? / What are all the factors that cause Y? / What effect does X have on Y?Example: Does the use of UML diagrams improve the quality of the design?

– Causality-Comparative Questions Does X cause more Y than does Z? / Is X better at preventing Y than Z?Example: Does the use of UML diagrams improve the quality of the design more than other graphical design notations?

– Causality-Comparative Interaction Questions



• Causality:– Causality-Comparative Interaction Questions Does X

or Z cause more Y under one condition but not others?

Example: Does the use of UML diagrams improve the quality of the design more than other graphical design notations in large projects, but not otherwise?


Design Questions

”What is an effective way to achieve X?” / What strategies help to achieve X?”

Examples:

What is an effective way for teams to represent design knowledge in order to improve coordination?

or

What is an effective way for teams to represent design knowledge in order to improve design quality?


The Wallace Model

Theories



Observations

Research Methods






Observations, Laws, and Theories

Observation

Theory

confirmed by

repeated

not necessarily repeated

Law

predicts

explained by

Laws explain how things happen, but not why. Theory does.(Source: Endres, Rombach: A Handbook of Software and Systems Engineering)


Definitions

• Observations may be facts or simply subjective impressions; typically they are made through using our senses or instruments

• Laws are generalizations of repeatable observations; they tell us how something occurs, but not why; thus laws can be used for predictions, but not for explanation.

– Example: Kepler’s laws of planet movement

• Theories explain and classify observations; they explain why laws are true.


The Central Role of Observation

• Theories can come “from anywhere” and be based on logical inference (deduction) or singular observations (induction)

• A law is based on repeated observations under similar condition

• In order to test (refute, check) theories, observations must be made in well-designed empirical studies


How to get a Theory?

• Theories can come “from anywhere” and be based on logical inference (deduction) or singular observations (induction)

• Grounded Theory is a technique for developing theory iteratively from qualitative data (e.g., from interviews).

– Initial analysis of the data begins without any preconceived categories.

– As interesting patterns emerge, the researcher repeatedly compares these with existing data, and collects more data to support or emerge the supporting theory.


Theory – Characterisation

• A scientific theory– identifies and defines a set of

phenomena, and makes assumptions about those phenomena and the relationships between them.

– precisely defines the theoretical terms, so that a community of scientists can observe and measure them.

– explains why certain relationships occur.

• Positivists expect their theories to have strong predictive power, and so look for generalised models of cause-and-effect as the basis for theories.

• Constructivists expect theories to strengthen their understanding of complex situations, and so tend to make more use of categorisations and analogies.


Theory – Example

• Hanna might develop a theory around the use of UML diagrams as standardised forms of external memory.

• According to this theory, UML diagrams are used to summarize the results of meetings and discussions, to remind participants of a shared understanding that they have already developed.

• The theory – should precisely define the meanings of terms such as ”diagram”,

”participants”, ”discussions”, in order to identify them in any studies performed.

– should explain why developers chose to use UML diagrams in some circumstances but not in others, and why they include certain things in their diagrams and exclude others.

– should be able to predict qualities of the diagrams that a team produce based on certain factors, and/or predict the quality of the software produced based on the use of UML diagrams.


Theory – Example (cont'd)

Constructs...C6 – Testability (more efficient development of test cases and better quality, i.e., coverage))...

Propositions...P5 – The use of a UML-based development method positively affects testability...

Explanations...E5 – Test cases based on UML models are easier to develop / Can be developed earlier / Are more complete / ......

Scope...


The Wallace Model

Theories



Observations

Research Methods






(Empirical) Research Methods

• Controlled Experiment– Randomized

Experiment– Quasi-Experiment– Time-Series Experiment

• Case Study– Descriptive Case Study– Exploratory Case Study– Confirmatory Case

Study

• Survey– Questionnaire-based

(primary study)– Literature-based

(secondary or tertiary study)

• Ethnography• Action Research


Survey – Characterisation

• A survey is a data collection method or tool used to gather information about individuals in order to identify the characteristics of a broad population

• The defining characteristic is the selection of a representative sample from a well-defined population with the aim to generalise from the sample to the population.

• Usually conducted with questionnaires, but can also involve structured interviews or data logging techniques

• Example:

– Investigate to what extent, for which purpose, by which companies, and by whom within the companies, UML diagrams are used.


Survey – Characterisation (cont'd)

• When to use it?

– Either at start of research to get an understanding of the current situation …

– or at the end of a research phase to see the impact/acceptance/etc. of a new method/technique/tool

• Issues:

– 'Superficial' --> no explanation / no causality --> not suitable for hypothesis testing

– 'Generalisability' of results depends on the choice of population and 'response rate', as well as validityand reliability of the data collection instrument


Survey – Example

What?

Research Questions:

How is Agile practiced at Microsoft?

– i.e. What do engineers do?

How do engineers feel about it?

– i.e. Do they like it?

Who, Where, and When? Microsoft (worldwide, 2006) Anonymous survey sent to 2821

engineers– 10% random sampling of all developers,

testers, program managers at Microsoft in October 2006

487 valid responses– 44% developers, 28% testers, 17%

program managers

Source: Andrew Begel and Nachiappan Nagappan, Usage and Perceptions of Agile Software Development in an Industrial Context: An Exploratory Study, in First International Symposium on Empirical Software Engineering and Metrics, IEEE Computer Society, September 2007

Why?

Many agile approaches exist – what's in it for Microsoft?


Survey – Example (cont'd)

Agile practice penetration at Microsoft


Survey – Example (cont'd)Quantitative Results (Highlights)

33% of respondents (spread across divisions) report their team uses Agile methodologies.

They mainly use Scrum (68%).

Used for many legacy products.

Agile usage does not appear to depend on team co-location.

Test-driven development and pair programming are not very common.

Qualitative Results (Highlights)

MS engineers who have used Agile like it for their local team, but not necessarily for their organization.

They worry about scale, overhead, and management buy-in.

Perceived benefits (687 comments, 44 themes)

Perceived problems (565 comments, 58 themes)






Study






Experiment – Characterisation

Definition:

– A (controlled or laboratory) experiment investigates a testable hypothesis by manipulating one or more independent variables (factor) to measure their effect on one or more dependent variables. Each combination of values (levels) of the independent variables is a treatment. All other variables are kept constant.

In the simplest case, one compares the performance of an experimental group to a control group:

– Experimental group: performs a task exposed to Level_1 of Factor_A.

– Control group: performs the same task exposed to Level_2 of Factor_A.

Example:

Independent Variable: UML diagram usage (yes or no)

Dependent Variable: Design Quality

Treatments: A = use UML / B = don’t use UML


Controlled Experiment – Characterisation

• An investigation of a testable hypothesis where one or more independent variables are manipulated to measure their effect on one or more dependent variables. Each combination of values of the independent variable is a treatment.

• In Software Engineering, typically, experiments require human subjects to perform some task.

… …

Treatments(Interventions)

IndependentVariables

DependentVariables


Controlled Experiment – Simple Example

• Independent Variable: UML diagram usage (yes or no)• Dependent Variable: Design Quality• Treatments: A = use UML / B = don’t use UML

A

Treatments(1 Factor / 2 Levels)

IndependentVariable

DependentVariable

B

NB: Design can be within-subject or between-subject


Experiment – Characterisation (cont'd)

Characteristics:

– When to use? --> When in-depth understanding about causal relationships is requested

– Focus on quantitative data --> allows for use of statistics for hypothesis testing

– Due to control over independent variables (in vitro = 'in glass', i.e. laboratory), helps detect causal relationships (--> tests hypotheses --> theory building)

Issues:

– Expensive, 'narrow' (in-depth)

– 'Generalisability'? ('artificial' lab setting --> test subjects, tasks, artifacts)


Experiment – Example

What?

Research Question:

What is best – Pair Programming or Solo Programming?

Who, Where, and When?

Norway, 2007 295 junior, intermediate and senior

professional Java consultants from 29 companies were paid to participate (one work day)

99 individuals; 98 pairs The pairs and individuals performed the

same Java maintenance tasks on either:– a ”simple” system (centralized control style),

or

– a ”complex” system (delegated control style) They measured:

– duration (elapsed time)

– effort (cost)

– quality (correctness) of their solutions

Source: E. Arisholm, H. Gallis, T. Dybå, and D. Sjøberg, “Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise,” IEEE Transactions on Software Engineering, 2007, 33(2): 65-86.

Why?

Many studies with contradicting results – mostly conducted with students (not with professional developers)


Total Effect of PP

84 %

7 %

-8 %

-40 %

-20 %

0 %

20 %

40 %

60 %

80 %

100 %

120 %

140 %

160 %

Duration Effort Correctness

Dif

fere

nc

e f

rom

ind

ivid

ua

ls

Experiment – Example (cont'd)


Effect of PP for Juniors

5 %

111 %

73 %

-40 %

-20 %

0 %

20 %

40 %

60 %

80 %

100 %

120 %

140 %

160 %


Dif

fere

nc

e f

rom

ind

ivid

ua

lsModerating Effect of System Complexity for Juniors

4 %

109 %

32 %

6 %

112 %

149 %

-40 %

-20 %

0 %

20 %

40 %

60 %

80 %

100 %

120 %

140 %

160 %


Dif

fere

nc

e f

rom

ind

ivid

ua

ls

CC (easy)

DC (complex)

Moderating Effect of System Complexity for Seniors

55 %

-13 %

8 %

115 %

-23 %

-2 %

-40 %

-20 %

0 %

20 %

40 %

60 %

80 %

100 %

120 %

140 %

160 %


Dif

fere

nc

e f

rom

ind

ivid

ua

ls

CC (easy)

DC (complex)

Effect of PP for Seniors

-9 %

83 %

-8 %

-40 %

-20 %

0 %

20 %

40 %

60 %

80 %

100 %

120 %

140 %

160 %


Dif

fere

nc

e f

rom

ind

ivid

ua

ls

Experiment – Example (cont'd)


So, when should we use PP?

The question of whether PP is best, or not, is meaningless!

One should ask: In which situation is PP best to achieve a defined goal?

Importance of Context: Helps construct/refine theory about when and how to do 'Pair Programming'






Study






Case Study – Characterisation

Characteristics:

– When to use? --> When 'rich' information is requested

– 'Rich' (in-vivo=in the living),

– More focus on qualitative data --> allows for better understanding of conditions under which a technique/tool works

Issues:

– Important: Proper case selection / clearly stated research question / clearly defined framework for interpreting the observations

– 'Generalisability' (1 case --> only 1 context')

Definition:

– An empirical enquiry that investigates a contemporary phenomenon within its real-life context (in-vivo=in the living), especially when the boundaries between phenomenon and context are not clearly evident.

Example:

– Experienced practitioners communicate about software design in many different ways (and other than, say, undergraduate students). Thus, one may conduct a case study in a local company.


Case Study – Variants

• Descriptive Case Study– Purely observational / Focus on “What happens?”

• Explorative Case Study– Initial investigation of some phenomena to derive new

hypotheses and build theories / Focus on “What and Why?”• Confirmatory Case Study

– Start out with a given theory and try to refute it, ideally with a series of case studies covering various contexts


Ethnography – Characterisation

• Generally, the goal is to study a community of people to understand how the members of that community make sense of their social interaction. (Robinson, 2007)

• For Software Engineering, ethnography can help to understand how technical communities build a culture of practices and communication strategies that enables them to perform technical work collaboratively.

• Example: – UML users in general, or in a specific company / project / team


Action Research – Characterisation

• Action researchers attempt to solve a real-world problem while simultaneously studying the experience of solving the problem.

Or:

• Action researchers aim to intervene in the studied situation for the explicit purpose of improving the situation.

• NB: This approach requires a lot of discipline and critical reflection about the role of the researcher in the studied situation.

• Example: – A researcher participates in a software project using UML diagrams as

means for cooperation. He/She is an actor and at the same time observes.


Selecting the Research Method

• The choice of method depends among other things on:– Suitable study subject (e.g., do participants have enough experience?)– Possibility to control the environment– The size/scale/cost of the study

– The need for generality in the results– Availability of information/data and other resources– What is the purpose of the study? (exploration, prediction,

understanding of cause-effect relations, applicability of results in industry, ....)

• Difficult to provide general recommendation with respect to choice of method


Experiment or Case Study or Survey?

• Experiments give the researchers freedom to isolate a defined effect and to hold other things constant ( research in-depth)

– Often difficult to avoid that people respond differently than they would have done in a natural environment

– Also, you might have a too restricted setting and omit important influencing factors that play a role in a natural environment

• Case-studies have the advantage that you observe people doing what they are actually doing in their natural environment ( research in-the-typical)

– It is limited what you can control without interfering with natural activity

• Surveys provide researchers with information about what many people (think they) are doing ( research in-breadth)

– No control whatsoever (issues relate to data validity and representativeness)


Validity & Reliability of Empirical Studies

• Construct Validity– Concepts being studied are

operationalised and measured correctly ( do the measures used actually represent the concepts you want to measure?)

• Internal Validity– Establish a causal relationship

and sort out spurious relationships ( exclude confounding variables / by: random sampling, blocking, balancing)

• Conclusion Validity– Do proper statistical inference

• External Validity– Establish the domain to which a

study’s findings can be generalized ( precisely describe the population and experimental conditions)

• Reliability– The study can be repeated (i.e.,

by other researchers) and yields the same results

– The measurement instrument is reliable ( interrater agreement)


Beware of the following ”effects”:

• Hawthorne-effect– The attention given to the workers in "Hawthorne Plant of the Western Electric

Company" is thought to have had greater effect than the process changes that were studied.

• Weinberg-effect– Study showed that system developers who knew that they were being assessed,

decreased their performance on most parameters which were not assessed.• Observer effect

– Refers to changes that the act of observing will make on the phenomenon being observed

• Observer-expectancy effect (theory-loaded observation/cognitive bias)– What you (think you) observe, is influenced by what you think you will observe. (

the man who shot after a tractor while moose hunting)• Subject-expectancy effect (cognitive bias)

– A cognitive bias that occurs when a subject expects a given result and therefore unconsciously manipulates an experiment or reports the expected result.

• The effect of the question’s structure (construction, forming)– “Do you think the lecture today was A: good, B: very good, C: brilliant, D:

exceptional"


Empirical Research Guidelines


This is (almost) the end …

• The lecture is over:

– Thanks for your interest and participation!

• For you still to do:

– Complete and submit project report (final) by email to [email protected] at the latest on 15th November 19:59. Only PDF files will be accepted.

– Prepare for oral exam (13th & 14th December)

– Please fill in online feedback form (managed by IfI)

mailto:[email protected]


Learning Outcomes

At the end of the course you will ...

• have gained a good understanding of modern software development processes, including Lean and Agile methods

• know the characteristics and effects of the different development processes

• be able to contribute to efficient organization, conduct and improvement of software development processes


Detailed Teaching Plan /1

http://www.uio.no/studier/emner/matnat/ifi/INF5181/h12/undervisningsplan.xml

• Lecture 1: Introduction into Process Improvement• Lecture 2: Rich Processes & Principles of Process Modeling

• Lecture 3: Agile Principles and Processes

--------------> Homework 1 hand-in due on Monday, 10-Sep-2012 at 15:30 (PDF, via email)

• Lecture 4: Lean Principles and Processes• Lecture 5: Student Presentations

• Lecture 6: Flow-based Agile Development (KANBAN)

• Lecture 7: SPI & Measurement


Detailed Teaching Plan /2

http://www.uio.no/studier/emner/matnat/ifi/INF5181/h12/undervisningsplan.xml

• Lecture 8: Problem Solving and Improvement (People Aspects)

--------------> Homework 2 hand-in due on Monday, 15-Oct-2012 at 15:30 (PDF, via email)

• Lecture 9: Process Assessment, Process Improvement Frameworks, Course Review

• Lecture 10: Industry Presentation: SPI at Skatteetaten

• Lecture 11: SPI & Empirical Research Methods / Learning from Experience

--------------> Project report due on Thursday, 15-Nov-2012 at 19:59 (PDF, via email)

--------------> Oral exams on 13&14-Dec-2012


Literature (Syllabus)

• PROFES - User Manual, 1999. Profes Consortium.

• Software Process Definition and Management by Jürgen Münch, Ove Armbrust, Martin Kowalczyk and Martín Soto, Springer: the Fraunhofer Series on Software and Systems Engineering, ISBN 978-3-642-24291-5 (eBook), DOI: 10.1007/978-3-642-24291-5

– Chapter 1 (Introduction)

• The Goal/Question/Metric method: A practical guide for quality improvement of software development by Rini van Solingen and Egon Berghout, McGraw-Hill, ISBN 0-07-709553-7, December 1999.

• Additionally, the lecture slides are part of the syllabus.

• Electronic copies of the syllabus are available to students through the course web.

PROFES Manual

PROFES Manual

http://www.springerlink.com/content/978-3-642-24290-8/


Course Evaluation, Marking, and Grades

• Part 1: Project / 80% of grade [32 marks]

– Homework 1: Process Modeling [6 marks]

– Homework 2: Measurement [6 marks]

– Short Presentation [0 marks]

– Project Report [20 marks]

• Evaluation criteria for Project Report:

– Content [14 marks]

– Clarity/Conciseness [4 marks]

– Formality (cover page, captions, referencing, etc.) [2 marks]

Note:

• A mandatory short presentation is required

• Failing to do the oral presentation will result in a penalty of 2 marks!

• Part 2: Oral Exam / 20% of grade [8 marks]

• Duration: approximately 15-20 minutes

• Subject:

– Questions about the course (lecture, materials)

• Evaluation criteria:

– Correctness and completeness [6 marks]

– Clarity and conciseness [1 mark]

– Relevance (i.e., is the answer to the point?) [1 mark]

Total Marks in Course: 40 (100%)


Grade Description General, qualitative description of evaluation criteria

A Excellent An excellent performance, clearly outstanding. The candidate demonstrates excellent judgment and a high degree of independent thinking.

B Very good A very good performance. The candidate demonstrates sound judgment and a very good degree of independent thinking.

C GoodA good performance in most areas. The candidate demonstrates a reasonable degree of judgment and independent thinking in the most important areas.

D SatisfactoryA satisfactory performance, but with significant shortcomings. The candidate demonstrates a limited degree of judgment and independent thinking.

E SufficientA performance that meets the minimum criteria, but no more. The candidate demonstrates a very limited degree of judgment and independent thinking.

F Fail A performance that does not meet the minimum academic criteria. The candidate demonstrates an absence of both judgment and independent thinking.

Mapping of Total Marks to Grades (Tentative!)

≥36

≥32

≥28

≥24

≥20


Letter Grades

• A - An excellent performance, clearly outstanding. The candidate demonstrates excellent judgement and a high degree of independent thinking.

• B - A very good performance. The candidate demonstrates sound judgement and a very good degree of independent thinking.

• C - A good performance in most areas. The candidate demonstrates a reasonable degree of judgement and independent thinking in the most important areas.

• D - A satisfactory performance, but with significant shortcomings. The candidate demonstrates a limited degree of judgement and independent thinking.

• E - A performance that meets the minimum criteria, but no more. The candidate demonstrates a very limited degree of judgement and independent thinking.

• F - A performance that does not meet the minimum academic criteria. The candidate demonstrates an absence of both judgement and independent thinking.


Oral Exam – Logistics

• Dates: 13 & 14 December

• Place: OJD 2164 Room Delta

• Examiners: Dietmar Pfahl & Stein Grimstad

• Notes:

– The following Schedule is tentative!

– The final version will be announced on the course web after Nov 15 (Submission of Project Reports)


Oral Exam – Tentative Schedule

Thursday, 13 Dec:

8.00-8.20: Aasen Nora Svarverud

8.30-8.50: Amundsen Andre Boganskij

9.00-9.20: Barczynski Artur Kamil

9.30-9.50: Beshah Betelhem Teferra (?)

10.00-10.20: Blackman Lamisi Gurah

10.30-10.50: Briseid Kjell

11.00-11.20: Chitrakar Sushil

11.30-11.50: Dahl Aage Andre

12.00-12.20: Datta Arnab Kumar

13.30-13.50: Siddique Lubna

14.00-14.20: Distler Marion Celine

14.30-14.50: Dæhlen Magnus

15.00-15.20: Fredrikson Gunnar

15.30-15.50: Haga Mads Theodor

16.00-16.20: Hilde Thomas Olavsson

16.30-16.50: Humlen Niklas

17.00-17.20: Karamit Shahzad

Friday, 14 Dec:

8.00-8.20: Kvam Frederikke Holthe

8.30-8.50: Le Dan Truong

9.00-9.20: Lew Yaw Fung Yannick

9.30-9.50: Lunder Karoline

10.00-10.20: Malik Haris Asghar

10.30-10.50: Nordby Martin Boasson

11.00-11.20: Poroshina Anastasia

11.30-11.50: Saemi Behnaz

12.00-12.20: Shiraddi Ramesh

13.30-13.50: Skifjeld Henrik

14.00-14.20: Soria Adrian Manuel

14.30-14.50: Strøm Emil

15.00-15.20: Vetter Timo

15.30-15.50: Wang Kristoffer

16.00-16.20: Zhang Xin

INF5181: Process Improvement and Agile Methods in Systems ...€¦ · • 10-Sep-2012: Homework 1...

Documents

Transcript of INF5181: Process Improvement and Agile Methods in Systems ...€¦ · • 10-Sep-2012: Homework 1...