SE Research Process
•
1 like•1,797 views
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/. http://www.ivanomalavolta.com
Recommended
More Related Content
What's hot
What's hot (20)
Similar to SE Research Process
Similar to SE Research Process (20)
More from Ivano Malavolta
More from Ivano Malavolta (20)
Recently uploaded
Recently uploaded (20)
SE Research Process
- 1. Ivano Malavolta RESEARCH in software engineering
- 3. Roadmap Software engineering research Empirical strategies Writing good research papers
- 4. Software engineering research Some contents of this part of lecture extracted from Ivica Crnkovic’s lecture on software engineering research at Mälardalen University (Sweden)
- 5. What makes good research? is it HARD? is it USEFUL? is it ELEGANT? These are all orthogonal and equally respectful Very little chances that you will excel in all three axes We are young researchers, don’t refuse usefulness, why limit your impact to dusty publications? http://goo.gl/d1YM9v
- 6. My vision about research Research Theory Industrial projectsProgramming Experimentation Ivano Malavolta.Research Statement. November 2013. http://goo.gl/99N5AS
- 7. The basic characteristic of SE Real world practical PROBLEM Real world practical SOLUTION ?
- 8. Research objectives Key objectives • Quality àutility as well as functional correctness • Cost à both of development and of use • Timeliness à good-enough result, when it’s needed Address problems that affect practical software Real world practical PROBLEM Real world practical SOLUTION
- 10. Example
- 11. Research strategy Real world practical PROBLEM Real world practical SOLUTION Research setting IDEALIZED PROBLEM Research setting SOLUTION to IDEALIZED PROBLEM Research product (technique, method, model, system, …)
- 13. Validation of the results Real world practical PROBLEM Real world practical SOLUTION Research setting IDEALIZED PROBLEM Research setting SOLUTION to IDEALIZED PROBLEM Research product (technique, method, model, system, …)
- 14. Validation of the results Real world practical PROBLEM Real world practical SOLUTION Research setting IDEALIZED PROBLEM Research setting SOLUTION to IDEALIZED PROBLEM Research product (technique, method, model, system, …) Validation task 1 Does the product solve the idealized problem?
- 15. Validation of the results Real world practical PROBLEM Real world practical SOLUTION Research setting IDEALIZED PROBLEM Research setting SOLUTION to IDEALIZED PROBLEM Research product (technique, method, model, system, …) Validation task 1 Does the product solve the idealized problem? Validation task 2 Does the product help to solve the practical problem?
- 16. Validation of the results: example
- 18. Types of research questions FEASIBILITY CHARACTERIZATION METHOD/MEANS GENERALIZATION DISCRIMINATION Does X exist, and what is it? Is it possible to do X at all? What are the characteristics of X? What exactly do we mean by X? What are the varieties of X, and how are they related? How can we do X? What is a betterway to do X? How can we automate doing X? Is X always true of Y? Given X, what will Y be? How do I decide whetherX orY?
- 19. Example: software architecture The software architecture of a program or computing system is the structure or structures of the system,which comprise software components, the externallyvisible properties of those components and the relationships among them L. Bass, P. Clements, R. Kazman, Software Architecture In Practise, Addison Wesley, 1998 System subsystem Subsystem component component component
- 20. Example: SA research questions FEASIBILITY CHARACTERIZATION METHOD/MEANS GENERALIZATION DISCRIMINATION Is it possible to automatically generate code from an architecturalspecification? What are the important concepts for modeling software architectures? How can we exploit domain knowledge to improve software development? What patterns capture and explain a significant set of architectural constructs? How can a designer make tradeoff choices among architectural alternatives?
- 21. Example: SA research questions FEASIBILITY CHARACTERIZATION METHOD/MEANS GENERALIZATION DISCRIMINATION Is it possible to automatically generate code from an architecturalspecification? What are the important concepts for modeling software architectures? How can we exploit domain knowledge to improve software development? What patterns capture and explain a significant set of architectural constructs? How can a designer make tradeoff choices among architectural alternatives? Types of research questions FEASIBILITY CHARACTERIZATION METHOD/MEANS GENERALIZATION DISCRIMINATION Does X exist, and what is it? Is it possible to do X at all? What are the characteristics of X? What exactly do we mean by X? What are the varieties of X, and how are they related? How can we do X? What is a betterway to do X? How can we automate doing X? Is X always true of Y? Given X, what will Y be? How do I decide whetherX orY?
- 23. Research results Real world practical PROBLEM Real world practical SOLUTION Research setting IDEALIZED PROBLEM Research product (technique, method, model, system, …)
- 24. Types of research results QUALITATIVE & DESCRIPTIVE MODELS TECHNIQUES SYSTEM EMPIRICAL MODELS ANALYTIC MODELS Report interesting observations Generalize from (real-life) examples Structure a problem area; ask good questions Invent newways to do some tasks, including implementation techniques Develop ways to select from alternatives Embody result in a system, using the system both for insight and as carrier of results Develop empirical predictive models from observed data Develop structuralmodels that permit formal analysis
- 25. Example: SA research results QUALITATIVE & DESCRIPTIVE MODELS TECHNIQUES SYSTEM EMPIRICAL MODELS ANALYTIC MODELS Early architecturalmodels Architecturalpatterns Domain-specific software architectures UML to support object-oriented design Architecturallanguages Communication metrics as indicator of impact on project complexity Formal specification of higher-level architecture for simulation
- 26. Example: SA research results QUALITATIVE & DESCRIPTIVE MODELS TECHNIQUES SYSTEM EMPIRICAL MODELS ANALYTIC MODELS Early architecturalmodels Architecturalpatterns Domain-specific software architectures UML to support object-oriented design Architecturallanguages Communication metrics as indicator of impact on project complexity Formal specification of higher-level architecture for simulation Types of research results QUALITATIVE & DESCRIPTIVE MODELS TECHNIQUES SYSTEM EMPIRICAL MODELS ANALYTIC MODELS Report interesting observations Generalize from (real-life) examples Structure a problem area; ask good questions Invent newways to do some tasks, including implementation techniques Develop ways to select from alternatives Embody result in a system, using the system both for insight and as carrier of results Develop empirical predictive models from observed data Develop structuralmodels that permit formal analysis
- 28. Research validation Real world practical PROBLEM Real world practical SOLUTION Research setting IDEALIZED PROBLEM Research setting SOLUTION to IDEALIZED PROBLEM Research product (technique, method, model, system, …) Validation task 1 Does the product solve the idealized problem? Validation task 2 Does the result help to solve the practical problem?
- 29. Types of research validation PERSUASION IMPLEMENTATION EVALUATION ANALYSIS Formal model Empirical model EXPERIENCE Qualitative model Decision criteria Empirical model I thought hard about this, and I believe… Here is a prototype of a system that… Given these criteria, the object rates as… Given the facts, here are consequences… Rigorous derivation and proof Data on use in controlled situation Report on use in practice Narrative Comparison of systems in actual use Data, usually statistical, on practice
- 30. Example: SA research validation PERSUASION IMPLEMENTATION EVALUATION ANALYSIS Formal model Empirical model EXPERIENCE Qualitative model Decision criteria Empirical model Early architecturalmodels Early architecturallanguages Taxonomies, performance improvement Formal schedulability analysis User interface structure Architecturalpatterns Domain-specific architectures Communication and project complexity
- 31. Example: SA research validation PERSUASION IMPLEMENTATION EVALUATION ANALYSIS Formal model Empirical model EXPERIENCE Qualitative model Decision criteria Empirical model Early architecturalmodels Early architecturallanguages Taxonomies, performance improvement Formal schedulability analysis User interface structure Architecturalpatterns Domain-specific architectures Communication and project complexity Types of research validation PERSUASION IMPLEMENTATION EVALUATION ANALYSIS Formal model Empirical model EXPERIENCE Qualitative model Decision criteria Empirical model I thought hard about this, and I believe… Here is a prototype of a system that… Given these criteria, the object rates as… Given the facts, here are consequences… Rigorous derivation and proof Data on use in controlled situation Report on use in practice Narrative Comparison of systems in actual use Data, usually statistical, on practice
- 32. “NO-NO”s for software engineering research • Assume that a result demonstrated fro a 10K-line system will scale to a 500K-line system • Expect everyone to do things “my way” • Believe functional correctness is sufficient • Assume the existence of a complete, consistent specification • Just build things without extracting enduring lessons • Devise a solution in ignorance of how the world really works
- 33. Building blocks for research Feasibility Characterization Method/means Generalization Selection Qualitative model Technique System Empirical model Analytic model Persuasion Implementation Evaluation Analysis Experience Question Result Validation
- 34. Is this a good plan? Feasibility Characterization Method/means Generalization Selection Qualitative model Technique System Empirical model Analytic model Persuasion Implementation Evaluation Analysis Experience Question Result Validation
- 35. A common good plan Feasibility Characterization Can X be done better? Generalization Selection Qualitative model Technique Build Y Empirical model Analytic model Persuasion Implementation Measure Y, compare to X Analysis Experience Question Result Validation
- 36. Is this a good plan? Feasibility Characterization Method/means Generalization Selection Qualitative model Technique System Empirical model Analytic model Persuasion Implementation Evaluation Analysis Experience Question Result Validation
- 37. A common, but bad, plan Feasibility Characterization Method/means Generalization Selection Qualitative model Technique System Empirical model Analytic model Persuasion Implementation Evaluation Analysis Experience Question Result Validation
- 38. Two other good plans Can X be done at all? Characterization Is X always true of Y? Selection Qualitative model Technique Build a Y that does X Empirical model Formally model Y, prove X “Look it works!” Implementation Check proof Experience Question Result Validation Method/means Evaluation
- 39. Exercise Choose a research paper and try to map it into the building blocks of SE research Feasibility Characterization Method/means Generalization Selection Qualitative model Technique System Empirical model Analytic model Persuasion Implementation Evaluation Analysis Experience Question Result Validation
- 40. How do you trust a research then? 1. What are the problems from the real world? – Are they “real” and widespread? – What are the elements of them? 2. Are the solutions general? What are their limits? Real world practical PROBLEM Real world practical SOLUTION ? EMPIRICAL SOFTWARE ENGINEERING
- 41. Some contents of this part of lecture extracted from Matthias Galster ‘s tutorial titled “Introduction to Empirical Research Methodologies” at ECSA 2014 Empirical strategies* *We will have a dedicated course on this topic
- 42. Empirical software engineering Scientific use of quantitative and qualitative data to – understand and – improve software products and software development processes Data is central to address any research question Issues related to validity addressed continuously [Victor Basili]
- 43. Why empirical studies? Anecdotal evidence or “common-sense” often not good enough – Anecdotes often insufficient to support decisions in the industry – Practitioners need betteradvice on how and when to use methodologies Evidence important for successful technology transfer – systematicgathering of evidence – wide dissemination of evidence
- 44. Example End Users’ Perception of Hybrid Mobile Apps in the Google Play Store Ivano Malavolta, Stefano Ruberto Tommaso Soru, Valerio Terragni Ivano Malavolta Gran Sasso Science Institute (Italy) ivano.malavolta@gssi.infn.it ABSTRACT Recently, companies like IBM and Adobe and a growing community of developers advocate hybrid mobile apps development as a possible solution to mobile platforms fragmentation. Hybrid mobile apps are consistent across platforms and built on web standards. In this study, we present an empirical investigation into mobile hybrid apps. Our goal is to identify and analyse the traits and distinctions of publicly available hybrid mobile apps from end users’ perspective. The study has been conducted by mining 11,917 free apps and 3,041,315 reviews from the Google Play Store, and analyzing them from the end users’ perception perspective. The results of this study build an objective and reproducible snapshot about how hybrid mobile development is performing “in the wild” in real projects, thus establishing a base for future methods and techniques for developing hybrid mobile apps. FINDINGS • hybrid development frameworks are perceived as better suited for data-intensive mobile apps, whereas they perform poorly when dealing with low-level, platform- specific features • end users value hybrid and native apps similarly • in some categories, end users perceive native apps better than hybrid apps with respect to performance and the presence of bugs RESEARCH QUESTIONS What is the difference between hybrid and native mobile apps as perceived by end users? – RQ1: What is the difference in the perceived value between hybrid and native mobile apps? – RQ2: What is the difference in the perceived performance between hybrid and native mobile apps? – RQ3: What is the difference in the perceived bugginess between hybrid and native mobile apps? – RQ4: What is the difference in the initial download overhead between hybrid and native mobile apps?
- 45. Dimensions of empirical studies “In the lab” versus “in the wild” studies Qualitative versus quantitative studies Primary versus secondary studies
- 46. “In the lab” versus “in the wild” studies Common “in the lab” methods – Controlled experiments – Literature reviews – Simulations Common “in the wild” methods – Quasi-experiments – Case studies – Survey research – Ethnographies – Action research
- 47. Examples
- 48. Qualitative versus quantitative studies Qualitative research studying objects in their natural setting and letting the findings emerge from the observations – inductive process – the subject is the person Quantitative research quantifying a relationship or to compare two or more groups with the aim to identify a cause-effect relationship – fixed implied factors – focus on collected quantitative data à promotes comparison and statistical analyses They are complementary
- 50. Primary versus secondary studies Primary studies empirical studies in which we directly make measurements or observations about the objects of interest, whether by surveys, experiments, case studies, etc. Secondary studies empirical studies that do not generate any data from direct measurements, but: – analyze a set of primary studies – usually seek to aggregate the results from these in order to provide strongerforms of evidence about a phenomenon
- 51. Examples
- 52. …and what about this?
- 53. Types of empirical studies • Survey • Case study • Experiment
- 54. Survey Def: a system for collecting information from or about people to describe, compare or explain their knowledge, attitudes and behavior Often an investigation performed in retrospect Interviews and questionnaires are the primary means of gathering qualitative or quantitative data These are done through taking a sample which is representative from the population to be studied
- 55. Example: our survey on arch. languages 1. ALs Identification – Definition of a preliminary set of ALs – Systematic search 2. Planning the Survey 3. Designing the survey 4. Analyzing the Data – vertical analysis (and coding) + horizontalanalysis
- 56. Case study Def: an empirical enquiry to investigate one instance (or a small number of instances) of a contemporary software engineering phenomenon within its real-life context, especially when the boundary between phenomenon and context cannot be clearly specified Observational study Data collected to track a specific attribute or establishing relationships between different attributes Multivariate statistical analysis is often applied
- 57. Example
- 58. Experiment Def: an empirical enquiry that manipulates one factor or variable of the studied setting. 1. Identify and understand the variables that play a role in software development, and the connections between variables 2. Learn cause-effect relationships between the development process and the obtained products 3. Establish laws and theories about software construction that explain development behaviour
- 61. What to choose?
- 62. How to have an impact in reality? This is called technology transfer
- 63. Writing good software engineering papers Contents of this part of lecture extracted from Ivica Crnkovic’s lecture on software engineering research papers writing at Mälardalen University (Sweden)
- 64. Research Papers The basic and most important activity of the research • Visible results, quality stamp • Means for communications with other researchers
- 65. What, precisely, was your contribution? – What questiondid you answer? – Why should the reader care? – What larger question does this address? What is your new result? – What new knowledge have you contributed that the reader can use elsewhere? – What previous work (yours or someone else’s) do you build on? – How is your result different from and better than this prior work? – What, precisely and in detail, is your new result? Why should the reader believe your result? – What standard should be used to evaluate yourclaim? – What concrete evidence shows that your result satisfies your claim? If you answer these questions clearly, you’ll probably communicate your result well A good research paper should answer a number of questions
- 66. Let’s reconsider our SE research process… Research questions Research results Research validation
- 67. What do program committees look for? The program committee looks for – a clear statement of the specific problem you solved – the question about software development you answered – an explanation of how the answerwill help solve an important software engineering problem You'll devote most of your paper to describing your result, but you should begin by explaining what question you're answering and why the answer matters Research questions
- 68. Research results Explain precisely – what you have contributed to the store of software engineering knowledge – how this is useful beyond your own project
- 69. What do program committees look for? The program committee looks for – interesting, novel, exciting results that significantly enhance our ability • to develop and maintain software • to know the quality of the software we develop • to recognize general principles about software • or to analyze properties of software You should explain your result in such a way that someone else could use your ideas
- 70. What do program committees look for? What’s new here? Use verbs that shows RESULTS, not only efforts
- 71. • What existing technology does your research build on? • What existing technology or prior research does your research provide a superior alternative to? • What’s new here compared to your own previouswork? • What alternatives have other researchers pursued? • How is your work different or better? What has been done before? How is your work different or better?
- 72. 72 Explain the relation to other work clearly
- 73. What, precisely, is the result? • Explain what your result is and how it works. Be concrete and specific. Use examples. – Example: system implementation • If the implementation demonstrates an implementation technique, how does it help the reader use the technique in another setting? • If the implementation demonstrates a capability or performance improvement, what concrete evidence does it offer to support the claim? • If the system is itself the result, in what way is it a contribution to knowledge? Does it, for example, show you can do something that no one has done before?
- 74. Why should the reader believe your result? Show evidence that your result is valid—that it actually helps to solve the problem you set out to solve
- 75. What do program committees look for? Why should the reader believe your result? • If you claim to improve on prior art, compare your result objectivelyto the prior art • If you used an analysis technique, follow the rules of that analysis technique • If you offer practical experience as evidence for your result, establish the effect your research has. If at all possible, compare similar situations with and without your result • If you performed a controlled experiment, explain the experimentaldesign.What is the hypothesis? What is the treatment? What is being controlled? • If you performed an empirical study, explainwhat you measured, how you analyzed it, and what you concluded
- 76. A couple of words on the abstract of a paper People judge papers by their abstracts and read the abstract in order to decide whether to read the whole paper. It's important for the abstract to tell the whole story Don't assume, though, that simply adding a sentence about analysis or experience to your abstract is sufficient; the paper must deliver what the abstract promises
- 77. Example of an abstract structure: 1. Two or three sentences about the current state of the art, identifying a particular problem 2. One or two sentences about what this paper contributes to improving the situation 3. One or two sentences about the specific result of the paper and the main idea behind it 4. A sentence about how the result is demonstrated or defended
- 78. Coming back to the initial example… State of the art Overall contribution Specific results Validation ✗ ✓✓✗ ✗
- 79. Second try… State of the art Overall contribution Specific results Validation
- 80. What this lecture means to you? You now know how to carry on research in SE Don’t focus on the “size” of the problem, but on – the relevance (the practical, but also the theoretical!) – the accuracy in the investigation (problem and evaluation research) When conducting empirical research, don’t make claims you cannot eventually measure Finally, don’t think in black and white only – don’t divide the world in methods, analyses, case study, etc. – don’t be afraid to look also at otherdisciplines à we are software engineers in any case J
- 81. Suggested readings 1. Checking App Behavior Against App Descriptions (Alessandra Gorla, Ilaria Tavecchia, Florian Gross, Andreas Zeller), In Proceedings of the 36th InternationalConference on Software Engineering, ACM, 2014. 2. Linares-Vásquez, M., Bavota, G., Bernal-Cárdenas, C., Oliveto, R., Di Penta, M., and Poshyvanyk, D., "Mining Energy-Greedy API Usage Patterns in Android Apps: an Empirical Study", in Proceedings of 11th IEEE Working Conference on Mining Software Repositories (MSR'14), Hyderabad, India, May 31- June 1, 2014, pp. 2-11 3. Shaw, M. (2003), Writing Good Software Engineering Research Paper., in Lori A. Clarke; Laurie Dillon & Walter F. Tichy, ed., 'ICSE' , IEEE Computer Society, , pp. 726-737 . 4. Shaw, M. (2002), 'What makes good research in software engineering?', STTT 4 (1) , 1-7 .
- 83. Contact Ivano Malavolta | Post-doc researcher Gran Sasso Science Institute iivanoo ivano.malavolta@gssi.infn.it www.ivanomalavolta.com