What does it mean to use a method? Towards a practice theory for software engineering
abstract
Context: Methods and processes, along with the tools to support them, are at the heart of software engineering as a discipline. However, as we all know, that often the use of the same method neither impacts software projects in a comparable manner nor the software they result in. What is lacking is an understanding of how methods affect software development.
Objective: The article develops a set of concepts based on the practice-concept in philosophy of sociology as a base to describe software development as social practice, and develop an understanding of methods and their application that explains the heterogeneity in the outcome. Practice here is not understood as opposed to theory, but as a commonly agreed upon way of acting that is acknowledged by the team.
Method: The article applies concepts from philosophy of sociology and social theory to describe software development and develops the concepts of method and method usage. The results and steps in the philosophical argumentation are exemplified using published empirical research.
Results: The article develops a conceptual base for understanding software development as social and epistemic practices, and defines methods as practice patterns that need to be related to, and integrated in, an existing development practice. The application of a method is conceptualized as a development of practice. This practice is in certain aspects aligned with the description of the method, but a method always under-defines practice. The implication for research, industrial software development and teaching are indicated.
Conclusion: The theoretical/philosophical concepts allow the explaining of heterogeneity in application of software engineering methods in line with empirical research results.
1. Introduction
Methods and processes that rationalize and support the development of quality software are at the heart of software engineering as a discipline. And the process models, modelling approaches, architecture patterns and programming techniques, together with the tools to support them are widely used to improve the practice of software engineering. It is, however, difficult to pinpoint and quantify effects in practice: While effectiveness of specific techniques for isolated tasks can be measured and compared, the comparison of project-level measurements, based even on a population of similar projects, is still not possible.
Qualitative empirical research indicates that software teams balance what is recommended by the method with the specific technical and organizational circumstances of the project. Button and Sharrock, for example, report a specific interpretation of Yourdon development methodology, CASE and C in reaction to the specific contingencies. They argue that lsquo;methods are worked at phenomena, that they are made to work in the circumstances of their deployment and that the details of that work are part and parcel of the development processrsquo;. Early on, software engineers recognized that tools supporting software processes need to support exceptions and adaptations to allow developers to react to situated contingencies. Martin et al. report a software team balancing optimal test design, computer resources and people, and organizational circumstances when testing software. In some cases, the applicability of a method depends on how the business area is organized. The lsquo;work aroundsrsquo; when applying SCRUM have in the agile community gotten an own the name even: lsquo;scrumbutrsquo;. Based on surveys and interviews, Fitzgerald concludes that only 6% of all practitioners apply a formally defined method.
2. Methods and practice in software engineering
The development and dissemination of methods in order to inform and improve practice are at the heart of software engineering. Nevertheless, surprisingly few researchers have discussed the character of methods and how they inform software development. This section begins with a discussion of methods in software engineering and then argues for a concept of software development as social practice in order to inform the development and usage of methods.
2.1. Methods in software engineering
In ordinary language, the term lsquo;methodrsquo; describes a systematic way of addressing an endeavor. For example, Websterrsquo;s dictionary de-fines method as the following
method
1: a procedure or process for attaining an object: as
a (1): a systematic procedure, technique, or mode of inquiry employed by or proper to a particular discipline or art (2): a systematic plan followed in presenting material for instruction
b (1): a way, technique, or process of or for doing something (2): a body of skills or techniques
- a discipline that deals with the principles and techniques of scientific inquiry
- a: orderly arrangement, development, or classification: plan b: the habitual
practice of orderliness and regularity
hellip;
Websterrsquo;s Dictionary
Likewise, SWEBOK defines methods as: “Software engineering methods provide an organized and systematic approach to developing software for a target computer”. The ISO24774 defines a meta-model of methods that is meant to provide a notation for the description and engineering of methods consisting of stages, work units, work products, producers and actions that allow the description of recommended life cycles, processes and actions. In other words, methods comprise both: specification of work products as well as the definition of processes in which they are included.
2.2. Methods and practice
As discussions of the cha
剩余内容已隐藏，支付完成后下载完整资料
使用方法是什么意思呢?一个对软件工程的实践理论
摘要
背景:方法和过程,以及工具的支持,是软件工程作为一门学科的核心。然而,我们都知道,经常使用相同的方法既不会以相似的方式影响软件工程，也不会影响软件的结果。缺少的是一种对方法是如何影响软件开发的理解。
目的:本文提出了一种在哲学和社会学中基于实践的概念来描述软件开发作并作为社会实践的观点,和对开发方法和应用程序的理解,来解释结果的异质性。在这里实践不应该理解为与理论截然相反,但要作为一个被团队所承认的普遍商定的表现方式。
方法:本文应用社会学的概念从哲学和社会理论方面来描述软件开发和发展的概念和使用方法。在哲学论证上结果和步骤是使用公布的实证来研究的例证。
结果:本文提出了一个将理解软件开发作为社会和认知实践的概念,并定义了方法实践模式,需要相关的和集成现有的开发实践。将方法的应用概念化作为实践的发展。这种做法在某些方面与描述的方法一致,但方法总是定义实践。研究、工业软件开发和教学的意义早已被表明了。
结论:理论/哲学概念允许异质性的解释应用于软件工程方法与实证研究结果。
1.介绍
方法和流程合理化，和支持高质量的软件的开发是软件工程作为一门学科的核心。过程模型、建模方法、体系结构模式和编程技术,以及支持他们的工具被广泛用于提高软件工程的实践。然而,在实践中难以确定和量化效应:在特定技术的孤立的任务中可以进行有效性的衡量和比较,但在项目级的比较测量中,甚至在基于人口的类似的项目,仍是不可能的。
定性实证的研究表明,一个软件团队平衡着推荐方法的具体技术和组织项目的情况。比如，Button和Sharrock对尤顿开发方法提出了一个特定的解释,案例和C对具体事件的反应。他们认为的方法工作于现象,它们是由工作环境的部署和工作的细节组成的开发过程的一部分。在早期,软件工程师认识到工具在运用于软件过程中，需要支持异常和适应并允许开发人员应对突发事件。马丁等人认为一个软件团队需要在平衡优化测试设计,计算机资源和个人与组织的情况下进行软件测试。在某些情况下,一个方法的适用性取决于业务领域是如何组织的。一个队伍工作应用SCRUM在敏捷社区中得到一个自己的名字甚至:“scrumbut”（伪scrum）。根据调查和访谈,Fitzgerald得出一个结论，那就是只有6%的从业者运用了一个正式定义的方法。2.软件工程的方法和实践
方法的发展和传播是为了通知和改善实践在软件工程中的核心地位。然而,令人吃惊的是很少有研究者探讨方法的特点以及它们是如何通知软件开发。本节以在软件工程中探讨方法开头,然后提出一种将软件开发比作为社会实践的概念，从而来发展和使用方法。
2.1.软件工程的方法
在日常语言中,用术语“方法”描述解决一个努力的一种系统化的方法。例如,韦氏词典不能自圆其说的方法如下
方法
1:为达到一个目的的一个过程或步骤
a(1):一个系统的过程,技术,调查方式来妥善对待特定学科或艺术 (2):提交材料说明之后的一个系统的计划
b(1):一种方法，技术，或用于做某事的过程(2):身体技能或技术
2:一门学科,涉及科学研究的原则和技术
3:a:有序的安排,发展,或分类:b计划: 惯常的秩序和规律
hellip;
韦氏词典
同样,SWEBOK将方法定义为:“软件工程方法提供一个有组织的和系统化的方式来为目标计算机开发软件”。ISO24774定义了一个方法的元模型,旨在提供一种符号来描述和工程方法组成的阶段,工作单位,工作产品,生产者和行动,并允许用来描述推荐的生命周期,流程和操作。换句话说,方法包括:规范的工作产品，同样过程的定义也包括在内。
2.2.方法与实践
由于关于方法特点的讨论很少,方法描述和实践之间的联系, 总的来说是为了通知和提高软件工程，但又不仅仅桎梏在软件工程。Mathiassen等人观察到，有经验的从业者不参考在日常实践中所得到的方法;他们也不非常密切地4遵循这个方法,但他们总是能胜任并选择和实施相关活动和符号。作者提出,方法是学习汽车而不是通知实践。
与这些发现一致,Fitzgerald主张区分形式化方法和方法的实际应用,在方法的实际应用中描述了在实践中进行开发的结构化的方法。他与个体开发人员主播开发和实施一个“方法的实际应用”:“提出了方法往往不像最初定义的那样可以准确应用。不同开发人员不会以同样的方式解释和应用相同的方法,同样的，同一个开发人员也会在不同的开发情况下以同样的方式应用同样的方法。因此,在任何开发项目,方法的使用是唯一制定或者实例化都由开发人员决定”。
在“信息系统开发:在行动中的方法”这本书中，Fitzgerald和他的同事进一步发展了方法适应剪裁的概念，来开发一种方法的实际应用。然而,他们不定义实践的概念,也不定义方法,允许互动形式化的描述方法,以一个连贯的方式来描述方法的实际应用和实践。如果我们想要理解软件工程方法和实践之间的关系,我们需要了解什么是软件工程实践。正如Kraft和Noslash;rbjerg认为:“软件实践就是社会实践”。3.在社会哲学中的实践理论
在哲学中,实践的概念自从古希腊哲学的时代就开始被人们所探讨。在实践概念的发展历史概述中发现Schmid一篇名为“实践的概念:意义是什么?”的文章。Schmid与现代启蒙运动实践概念的发展:科学的目的不仅是理解宇宙的(神圣)组织也改善人类事务;工艺实践因此成为科学的一个重要对象和改进目标。
这个观点在Kant的俗语中体现的尤为显著:这可能在理论上是正确的,但在实践中并不适用的。诗歌和实践不是描述理论,反而与其恰恰相反,Kant认为实践和理论互为对方构成的基本要素。“如果有关规则被认为是相当一般性原则，如果他们是从众多条件中抽象出来,规则的集合,甚至实际规则就被称为理论,尽管如此,也必然影响他们的实际应用。相反,并不是所有的活动都称为实践,只有那些以特定目的的并且通常被认为符合一定的构思过程的活动才能被称为实践”。换句话说,理论是从(成功的)实践中抽象得来的;反过来,实践使用理论作为指导原则和过程。
Wittgenstein的哲学研究,在社会科学和哲学方面激励了许多当代学校。在他对这些学校的介绍中,Nicolini谈到在复数方面的实践理论。为了在一个连贯的和一致的方式中证明我们理论,我们参考了Schatzki的 “社会实践:在人类活动和社会中的维特根斯坦的方法”，以及Knorr Cetina的文章“有目的的实践”。
Schatzki的雄心壮志是提出一种将社会性作为一个综合和分散实践的关系的基本概念。他写到,“社会性（hellip;)不要求完整的作为社会生活的一个帐户。是依赖社会的基本性质,而不是通过调查社会领域和现象以及发现当地的细节和复杂性来构成的框架。”当前旨在做的是:将软件工程总结为一种社会实践,扩大Schatzki的概念来理解实证观察,证明方法在软件工程的状态。
下一节将提出核心概念。基于Schatzki的概念, 基于共同的理解、规则和teleoaffec-tive结构软件开发被描述为共享社会实践。Knorr Cetina的作品被用来证明软件开发是一种展开其对象的认知练习,有了它,自己的团队就可以开发实践。这个基础后来被用来定义方法实践模式,明确制定组(工具支持)的理解,规则和teleoaffective结构需要集成现有的实践。
4.软件工程实践的概念
本节提出中心思想作为下面的论证的基础。这里介绍的在概念数学证明中具有相同的函数,公理和证明理论。这也是相当长的引用的原因:不是仅仅提供一个自己的解释,作者还引用了原始声音。4.1小节描述了Schatzki关于实践的概念,并将其运用于软件工程。4.2节也基于Schatzki的“社会实践”,工具、设备和设置在社会实践的作用越来越重要。
作为讨论多样性与进化的软件开发实践的起点,比如，4.3节讨论了Schatzki总结实践的变化和灵活性的方法。比较他在软件工程概念的实证研究结果可以发现，这导致了识别需要进一步发展实践概念，这样才能够掌握软件开发实践的异质性和多样性。在4.4节中,Knorr Cetina关于认知实践的概念被用来解释软件工程实践的多样性。软件工程是一个针对设计和开发的迄今未知的软件的实践,与此同时,通过展开它的目标和实践,工具和技术部署来完成它。在第5小节中，这些概念被用来定义方法作为实践模式。
4.1.软件工程作为社会实践
Schatzki使用实践的概念来解释那些，让我们彼此相关的有意义的和在特定上下文中追求相关的目标的日常活动:当在一定情况下发生时,作为实践的一部分,一个人说什么或是做什么能够被他人所理解,共享实践，并为了共同的目标和目的而进行实践。
实践与特别的行为不应被混淆,即使规则和原则的指导作用表达不明确。在特别的情境下，人共享一个练习很容易认识到行动是“有意义的”。特别的行为可以看作当异常发生时,需要通过行动把状态恢复正常。即使在这种情况下,行动也是有意义的,因为对基础实践的理解。一篇名为“当计划不奏效”的文章[26]分析了一种同时显示了工作实践和特别的行为的情况:一个项目指导小组面对废掉的一个项目,导致子项目不得不返工中央文件。他们开发一个未来的行动线,允许项目进展有序地部分违反公司广泛的项目模型。唯一的例外是制定这个项目的模式,使特别的行为对组织的软件开发实践负责，支持项目模型提供的术语和规则。
软件工程作为社会实践是综合实践的分支。分散实践仍然存在,但他们改变了特性;例如,在软件工程中，解释的询问和给出也会被观测到,但它改变了其特性和意义。在长期的项目成员之间的对话框和新来的结对编程会话中可以找到这样的例子。[58],解释都是基于知识共享和改进现有的代码。
然而,正如上面提到的,社会实践的概念在这里不仅涉及工业实践。开源软件开发也可以被视为一种实践。开源软件开发是遵循共同理解的，需要一个开源项目的一员,通过显式规则(如，常见问题的形式),分享teleoaffec-tive,结构层次的目标和结局与个人行为所联系。
4.2.工具,设备和设置
一整套计算机以工具、文档、常见的存储库,以及自动化的构建和测试环境为基础，这是从软件工程得到的例子。像Eclipse这样的工具本质上是与软件工程关联的，在软件工程的实践之外没有任何意义。在具体实践的中设备依赖的意义，当我们在混乱考虑故事卡片的处理方式时，它的支持变得更加明显。虽然其他种类的做法似乎也有类似的设备(如对领域的材料可以使用类似的卡片进行定性分析),在混乱中故事卡片的具体含义无法解，除非团队使用它的方式协调发展。
混乱卡片和董事会作为例子证明了不仅个人设备的意义依赖于实践,而且设置设备的安排和布置本身本质上是与它所支持的实践交织在一起的。相关设备组织的设置作为实践的一部分。
在实践中引入新的方法和工具的整个目的是为了改变这种做法。在下一节，讲Schatzki如何总结改变及其涉及到软件工程实践的变化。这反过来又证明了实践的动机，包括Knorr Cetina的概念基础认知实践。
4.3.灵活性和改变
Schatzki强调实践和与其相关的行为理解,对象和设备是开展一个做事情的新方法。通过隐式的理解和实践的规范性明确规定规则，并不意味着实践是明确定义的。
这种灵活性不仅提供了实践发展的基础,同时也允许联合实践适应发生的突发事件。软件实践仍然可以被认为软件工程师在不同的项目和以不同的方式来组织软件工程。例如:一个问题跟踪器的使用报告,分析,诊断和修正错误，在许多软件组织以及开源社区是众所周知的。如何分类的具体方式所导致的结果会有所不同,然而,从组织到组织,从开源项目的开源项目。换句话说,围绕修复错误的具体实践和问题跟踪器的使用会有所不同,这取决于当地所适应的更通用的实践和理解。
4.4.软件工程作为认知实践
不同的软件工程项目中有不同的对象的设计和认知对象的演变，应提供相应的设计和开发实践和软件工程实践,但是显然可感知的应作为一个类似的实践,即使在同一家公司，有相同的上下文特征,也总是不同的。这意味着当地的软件工程实践不仅是基于不同的设置和不同上下文事件，还需要归因于其认知或设计对象的特异性。
迄今为止讨论的核心概念，是基于Schatzki的社会实践的概念和Knorr Cetina的认知实践的概念。根据Schatzki的概念，软件开发作为社会实践可以被理解为行为和语录的关系保持在一起的共同的理解,共同的明确的规则和原则,和共同的teleoaffective结构。它以设置和一组工具和技术为支撑,呈现出上下文中有意义的这种做法。提出了把软件开发当作认知实践,强调软件开发创造性的一面:teleoaf-fective结构或软件开发的目的是把形成一个尚不存在的软件,但需要能自圆其说,通过实践来设计和开发。这也意味着,为了形成这个认知对象,实践本身也需要时间来培养。
为了支持广泛的异构设计和开发实践, 理解方法仍然是有用的，下一节提出的方法的概念,可以用于掌握方法的适应性，并采用一个具体的实践。
5.实践不断保持和发展
在社会学的话语中,结构化和清晰度的分布式活动是组织内部已经讨论和实证的研究的主题。下面,首先Strauss的清晰度的工作概念和Gerson的琐碎工作的概念被用来进一步探索实践的意识适应性;此后, 实证研究是用来体现不断变化的实践的这种做法。
5.1. 衔接的工作和不断变化的实践做法
lt;
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[152533]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
