{"title":"Why should they believe us? Determinism, non-determinism and evidence","authors":"D. Budgen","doi":"10.1109/CSEET.2006.41","DOIUrl":null,"url":null,"abstract":"Summary form only given. In software engineering, as in computing science, the topics that we teach to our students can be considered as falling into two broad categories: the deterministic, and the non-deterministic. Deterministic topics are those where a specific scenario or operation leads to outcomes that can be assessed in terms of true/false values, and so this classification encompasses large elements of computer architecture, databases, metrics and testing. However, much of the software engineering body of knowledge is really concerned with much more non-deterministic processes such as requirements elicitation, design, construction, maintenance etc. These are activities in which humans play a central role, making value judgements that result in outcomes that are more appropriately assessed by using some form of better/worse ranking than through a true/false categorisation. How much we recognise the existence of this distinction in our teaching is a moot point. Many of our students, educated in the classical science paradigm, will be familiar with the type of reasoning that leads to the outcomes for the deterministic elements. In my presentation, I examine some of the reasons why this experience may not be adequate when they encounter the non-deterministic elements of our subject, and hence why we may need to inculcate some degree of understanding of the evidence-based paradigm in order to support both our teaching and also their learning. I will discuss the nature of this paradigm, present some experiences of how it may be adapted for use in Software Engineering, and review some of the questions that it raises.","PeriodicalId":250569,"journal":{"name":"Conference on Software Engineering Education and Training","volume":"123 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2006-04-19","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"1","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Conference on Software Engineering Education and Training","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/CSEET.2006.41","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 1
Abstract
Summary form only given. In software engineering, as in computing science, the topics that we teach to our students can be considered as falling into two broad categories: the deterministic, and the non-deterministic. Deterministic topics are those where a specific scenario or operation leads to outcomes that can be assessed in terms of true/false values, and so this classification encompasses large elements of computer architecture, databases, metrics and testing. However, much of the software engineering body of knowledge is really concerned with much more non-deterministic processes such as requirements elicitation, design, construction, maintenance etc. These are activities in which humans play a central role, making value judgements that result in outcomes that are more appropriately assessed by using some form of better/worse ranking than through a true/false categorisation. How much we recognise the existence of this distinction in our teaching is a moot point. Many of our students, educated in the classical science paradigm, will be familiar with the type of reasoning that leads to the outcomes for the deterministic elements. In my presentation, I examine some of the reasons why this experience may not be adequate when they encounter the non-deterministic elements of our subject, and hence why we may need to inculcate some degree of understanding of the evidence-based paradigm in order to support both our teaching and also their learning. I will discuss the nature of this paradigm, present some experiences of how it may be adapted for use in Software Engineering, and review some of the questions that it raises.