下载文档原格式
软件工程-实践者的研究方法在软件工程领域，实践者经常面临着各种各样的问题，需要进行研究来解决这些问题。
研究方法在实践者的工作中起到了至关重要的作用，帮助他们系统地获取、分析和应用相关信息。
本文将介绍几种常见的软件工程实践者的研究方法，包括案例研究、调查研究、实验研究和文献综述。
一、案例研究案例研究是软件工程实践者常用的一种研究方法。
它通过详细地调查和分析实际的软件项目或实践案例，来获取关于软件开发和维护过程的有用信息。
案例研究可以帮助实践者深入了解实际工作中的问题、挑战和解决方法，从而提高他们的技术水平和工作效率。
二、调查研究调查研究是另一种常用的软件工程实践者的研究方法。
它通过问卷调查、访谈或观察等方式收集数据，以了解实践者在软件开发和维护过程中的实际行为、经验和观点。
调查研究可以帮助实践者了解目标用户的需求和期望，从而指导他们进行需求分析和设计工作。
三、实验研究实验研究是一种系统的、科学的研究方法，广泛应用于软件工程领域。
实践者可以设计和进行实验，以验证和评估不同的软件开发方法、工具和技术。
实验研究可以帮助实践者比较不同的解决方案，评估其性能和效果，从而帮助他们做出更为科学和合理的决策。
四、文献综述文献综述是软件工程实践者常用的一种研究方法。
它通过查阅和分析已有的文献和相关资料，来了解和总结某个特定主题的研究进展、方法和结果。
文献综述可以帮助实践者了解目前领域内的最新进展和成果，从而指导他们的实际工作和研究方向。
除了上述几种常见的研究方法，实践者还可以结合不同的方法进行混合研究。
例如，可以通过案例研究和调查研究相结合，来获取更全面和准确的信息；或者可以通过实验研究和文献综述相结合，来验证和支持已有的理论和方法。
总之，软件工程实践者在进行研究时可以选择多种方法，根据实际情况来确定最合适的方法。
无论选择哪种方法，都应该注重数据的收集和分析，严谨地进行研究，以获取有价值的结果，并将其应用到实际工作中，不断提高软件开发和维护的质量和效率。
《软件工程——实践者的研究方法》计算机软件作为非传统产业的制成品，有着许多独特的性质。
它具有不可见性、易变更性，对于这样一种智力劳动的成果人们难于把握它的质量，也难于组织好它的开发和生产过程。
我们对它的分析和研究，绝不可忽视其与传统产品及其开发过程相异的特殊性。
然而，从另一方面看，软件工程也是工程，虽然它是一门年轻的工程学课，仍然可以借鉴人们千百年来所积累的，在传统工程领域行之有效的规律和经验，例如规范化、标准化和模块化等等。
显然，软件工程需要统合与兼顾上述两个方面的特征。
任何过分强调某一方面，或是忽略某一方面的思维方式和行为都是错误的，并且这种综合与兼顾需要在不断探索中前进和发展。
Roger Pressman博士这本书很好地把握这些特征，对于软件工程学课的发展起了重要的推动作用。
本书在国际软件工程界产生了巨大的影响。
从而树立了它无可置疑的权威地位。
一本优秀的著作，特别是一本成功的教学用书可以影响一代人，甚至几代人的业务成长。
本书从1982年第1版开始，就受到我国软件工程界的重视，成为高等学校计算机专业软件工程课的重要教学参考书。
20多年来，它的各个后续版本一直都是我国软件专业人士喜爱和熟悉的读物。
它在全面而系统、概括而清晰地介绍软件工程有关的概念、原则、方法和工具方面都获得了国内广大读者的好评。
如前所述，本书在给出对学科发展具有深刻影响的传统方法时，又适当地引入了当前正在发展着、且有着生命力的新技术。
这里介绍的第六版具有几个特点：(1) 在第5版的基础上做了大量的充实和更新，以适应软件工程新技术的发展，例如，突出了软件过程，增加了敏捷开发方法。
(2) 除各章后面提供了大量进一步阅读的参考文献信息外，还针对不同的读者群（例如，学生、教师和专业人员等）提供了多种形式的材料，范围广泛、内容丰富，且使用方便。
(3) 为了方便阅读和理解，除在各章开头给出全章内容简介和关键词外，在文中穿插了许多形式不同的解释框。
软件工程实践者的研究方法_背诵知识点20141224软件的定义：软件是：1）指令的集合，通过执行这些指令可以满足预期的特征、功能和性能需求；2）数据结构，使得程序可以充分利用信息；3）软件描述信息，以硬拷贝和虚拟形式存在，描述程序操作和使用。
软件与硬件的区别：软件是设计开发的；软件不会磨损；大多数软件是按需求定制的。
IEEE定义：(1)将系统化、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件；(2) 在(1)中所述方法的研究。
软件工程的层次：软件工程的根基在于质量关注点。
软件工程的基础是过程层。
过程将各个技术层次结合在一起，使得合理地、及时地开发计算机软件成为可能。
方法为构建软件提供技术上的解决方法（"如何做"）。
工具为过程和方法提供自动化或半自动化的支持。
通用过程模型的5种框架活动:沟通、策划、建模、构建、部署8个典型的普适性活动：软件项目跟踪与控制；风险管理；软件质量保证；技术评审；测量；软件配置管理；可复用管理；工作产品的准备和生产软件神化：关于软件及其开发过程被人们盲目相信的一些说法，它实际上误导了人们对软件开发的态度。
螺旋模型：一种风险驱动型的过程模型，一种演进式软件过程模型。
它结合了原型的迭代性质和瀑布模型的系统性和可控性特点。
具有快速开发越来越完善软件版本的潜力。
统一过程（UP）：以用例为驱动、以系统架构为核心，迭代式增量式开发过程。
RUP包括起始、细化、构建、转换和生产5个阶段。
五个UP阶段并不是顺序地进行，而是阶段性地并发进行。
成熟度级别：第0级：不完全级、1已执行级、2已管理级、3已定义级、4已定量管理级、5优化级软件生命周期：软件计划与可行性研究、需求分析、软件设计、编码、软件测试、运行与维护瀑布模型：一个系统的、顺序的软件开发方法。
缺点：实际项目开发中很少遵守瀑布模型提出的顺序；客户难以清楚的描述所有的需求；客户要等到开发周期的晚期才能得到可执行的程序；在线性过程的开始和结束，容易发生“阻塞状态”。
For personal use only in study and research; not for commercial use软件工程复习总结第1章软件工程介绍1．软件的定义软件是包括程序、数据及其相关文档的完整集合。
其中，程序是按照事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操作信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。
For personal use only in study and research; not for commercial use软件的定义：1、指令的集合，通过执行这些指令可以满足预期的特征、功能和性能需求2、数据结构，它使得程序可以充分利用信息3描述程序操作和使用的文档2．软件的特征a) 软件是设计开发的，而不是传统意义上的生产制造的b) 软件不会磨损c) 虽然整个工业向着基于构件的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制的3．软件与硬件的区别a) 软件是一种逻辑实体，而不是具体的物理实体b) 软件的生产与硬件不同，软件开发过程中没有明显的制造过程c) 软件在运行、使用期间没有磨损、老化问题d) 软件的开发、运行受到计算机系统的限制，不同程度地依赖于硬件和环境，导致了软件升级和移植地问题e) 软件复杂性越来越高f) 软件开发成本相当昂贵g) 大多数软件是新开发的，而不是通过已有的构件组装而来的h) 软件工程涉及诸多的社会因素4．遗留软件与软件的演化系统演化的原因:a) 系统需要修改其适应性，从而满足新的计算环境或者技术的需求b) 软件必须根据新的业务需求进行升级c) 软件必须扩展以具有与更多现代系统和数据库的协作能力d) 软件架构必须进行改建以适应多样化的网络环境30年来软件发展的规律：1、持续变化规律，2、复杂性增长规律，3、自我调控规律，4、组织稳定性守恒规律，5、保证通晓性规律，6、持续增长规律，质量衰减规律，7、反馈系统规律。
软件工程实践者的研究方法（中文第七版）复习知识点总结统一过程模型的图、撰写用例规约、UML用例图、UML活动图、UML泳道图、UML状态图(P140)、UML顺序图(P141)、UML类图、第一章定义:软件工程是(1)将系统化、规范化、可量化的方法应用于软件的开1.IEEE 发、运行和维护，即将工程化方法应用于软件;(2) 在(1)中所述方法的研究。
2. 软件与硬件的区别:本质逻辑与物理;软件是设计开发的，并非传统意义上生产制造的;软件不会磨损;大部分软件是按需定制的。
3.遗留软件的特点:生命周期长、业务关键性、质量差第二章1.软件工程与软件过程的区别:软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。
软件过程定义了软件工程化中采用的方法，但软件工程还包括该过程中应用的技术—技术方法和自动化工具。
2.软件工程的三个要素:过程、方法和工具。
软件工程的目标(根基):质量关注点。
3.软件工程的通用过程框架定义了5个框架活动和8个普适性活动:五种框架活动:沟通、策划、建模、构建、部署。
8个普适性活动:项目跟踪控制、风险管理、质量保证、配置管理、技术评审、测量、可复用管理、工作产品的准备和生产。
4.课本21页软件过程框架图每个框架活动由一系列软件工程动作构成;每个软件工程动作由任务集合来定义，这个任务集合明确了工作任务、工作产品、质量保证点、项目里程碑。
(任务集的例子P22、P23)5.过程流(P22图)描述了在执行顺序和执行时间上，如何组织框架中的活动、动作和任务。
主要类型有:线性过程流、迭代过程流、演化过程流、并行过程流。
6.过程模式模板(非重点)P247.过程评估与改进:以改进为目标，评估力求理解软件的当前状态。
用于过程改进的CMMI标准评估方法提供了五部的过程评估模型:启动、诊断、建立、执行、学习。
用于组织内部过程改进的CMM评估8. 瀑布模型(经典生命周期):特点—文档驱动优点:消除非结构化软件;降低软件的复杂度，促进软件开发工程化缺点:实际项目开发中很少遵守瀑布模型提出的顺序;客户难以清楚的描述真正的需求;客户要等到开发周期的晚期才能看到程序运行的测试版本 ;在线性过程的开始和结束，容易发生“阻塞状态”适用于:需求确定、采用线性方式完成的工作中。
附录Software Engineering-A PRACTITIONER’S APPROACHWritten by Roger S. Pressman, Ph.D. （P.340-P.343）13.3DESIGN PRINCIPLESSoftware design is both a process and a model. The design process is a sequence ofsteps that enable the designer to describe all aspects of the software to be built. It is important to note, however, that the design process is not simply a cookbook. Creative skill, past experience, a sense of what makes “good” software, and an overallcommitment to quality are critical success factors for a competent design.The design model is the equivalent of an architect’s plans for a house. It begins by representing the totality of the thing to be built (e.g., a three-dimensional renderingof the house) and slowly refines the thing to provide guidance for constructing eachdetail (e.g., the plumbing layout). Similarly, the design model that is created for softwareprovides a variety of different views of the computer software.Basic design principles enable the software engineer to navigate the design process.Davis suggests a setof principles for software design, which have beenadapted and extended in the following list:• The design process should not suffer from “tunnel vision.” A gooddesigner should consider alternative approaches, judging each based on therequirements of the the resources available to do the job, and thedesign concepts presented in Section • The design should be traceable to the analysis model. Because a singleelement of the design model often traces to multiple requirements, it is necessaryto have a means for tracking how requirements have been satisfied bythe design model.• The design should not reinvent the wheel. Systems are constructed usinga set of design patterns, many of which have likely been encountered before.These patterns should always be chosen as an alternative to reinvention.Time is short and resources are limited! Design time should be invested inrepresenting truly new ideas and integrating those patterns that already exist.• The design should “minimize the intellectual distance”between the software and the problem as it exists in the real world.That is, the structure of the software design should (whenever possible)mimic the structure of the problem domain.• The design should exhibit uniformity and integration. A design is uniformif it appears that one person developed the entire thing. Rules of styleand format should be defined for a design team before design work begins. Adesign is integrated if care is taken in defining interfaces between designComponents.• The design should be structured to accommodate change. The designconcepts discussed in the next section enable a design to achieve this principle.• The design should be structured to degrade gently, even when aberrantdata, events, or operating conditions are encountered. Welldesignedsoftware should never “bomb.” It should be designed toaccommodate unusual circumstances, and if it must terminate processing, doso in a graceful manner.• Design is not coding, coding is not design. Even when detailed proceduraldesigns are created for program components, the level of abstraction ofthe design model is higher than source code. The only design decisions madeat the coding level address the small implementation details that enable theprocedural design to be coded.• The design should be assessed for quality as it is being created, notafter the fact.A variety of design concepts (Section 13.4) and design measures(Chapters 19 and 24) are available to assist the designer in assessing quality.• The design should be reviewed to minimize conceptual (semantic)errors. There is sometimes a tendency to focus on minutiae when the design isreviewed, missing the forest for the trees. A design team should ensure thatmajor conceptual elements of the design (omissions, ambiguity, inconsistency)have been addressed before worrying about the syntax of the design model.When these design principles are properly applied, the software engineer creates a designthat exhibits both external and internal quality factors . External quality factors are those properties of the software that can be readily observed by users (e.g., speed,reliability, correctness, usability).Internal quality factors are of importance to softwareengineers. They lead to a high-quality design from the technical perspective. To achieveinternal quality factors, the designer must understand basic design concepts.13.4 DESIGN CONCEPTSA set of fundamental software design concepts has evolved over the past four decades.Although the degree of interest in each concept has varied over the years, each hasstood the test of time. Each provides the software designer with a foundation fromwhich more sophisticated design methods can be applied. Each helps the softwareengineer to answer the following questions:• What criteria can be used to partition software into individual components?• How is function or data structure detail separated from a conceptual representationof the software?• What uniform criteria define the technical quality of a software design?M. A. Jackson once said: "The beginning of wisdom for a [software engineer] is torecognize the difference between getting a program to work, and getting it right". Fundamental software design concepts provide the necessary frameworkfor "getting it right."13.4.1 AbstractionWhen we consider a modular solution to any problem, many levels of abstraction canbe posed. At the highest level of abstraction, a solution is stated in broad terms usingthe language of the problem environment. At lower levels of abstraction, a more proceduralorientation is taken. Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution. Finally, at the lowestlevel of abstraction, the solution is stated in a manner that can be directly implemented.Wasserman provides a useful definition:The psychological notion of "abstraction" permits one to concentrate on a problem atsome level of generalization without regard to irrelevant low level details; use of abstractionalso permits one to work with concepts and terms that are familiar in the problem environmentwithout having to transform them to an unfamiliar structure . . .Each step in the software process is a refinement in the level of abstraction of the software solution. During system engineering, software is allocated as an element ofa computer-based system. During software requirements analysis, the software solutionis stated in terms "that are familiar in the problem environment." As we movethrough the design process, the level of abstraction is reduced. Finally, the lowestlevel of abstraction is reached when source code is generated.As we move through different levels of abstraction, we work to create proceduraland data abstractions. A procedural abstraction is a named sequence of instructionsthat has a specific and limited function. An example of a procedural abstraction wouldbe the word open for a door. Open implies a long sequence of procedural steps (e.g.,walk to the door, reach out and grasp knob, turn knob and pull door, step away frommoving door, etc.).A data abstraction is a named collection of data that describes a data objectChapter12). In the context of the procedural abstraction open, we can define a data abstractioncalled door. Like any data object, the data abstraction for door would encompassa set of attributes that describe the door (e.g., door type, swing direction, peningmechanism, weight, dimensions). It follows that the procedural abstraction open wouldmake use of information contained in the attributes of the data abstraction door.Many modern programming languages provide mechanisms for creating abstractdata types. For example, the Ada package is a programming language mechanismthat provides support for both data and procedural abstraction. The original abstractdata type is used as a template or generic data structure from which other data structurescan be instantiated.Control abstraction is the third form of abstraction used in software design. Likeprocedural and data abstraction, control abstraction implies a program control mechanismwithout specifying internal details. An example of a control abstraction is the synchronization semaphore used to coordinate activities in an operating system.The concept of the control abstraction is discussed briefly in Chapter 14.13.4.2 RefinementStepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth. A program is developed by successively refining levels of procedural detail.A hierarchy is developed by decomposing a macroscopic statement of function (aprocedural abstraction) in a stepwise fashion until programming language statementsare reached. An overview of the concept is provided by Wirth: In each step (of the refinement), one or several instructions of the given program are decomposedinto more detailed instructions. This successive decomposition or refinement of specificationsterminates when all instructions are expressed in terms of any underlying computeror programming language . . . As tasks are refined, so the data may have to be refined,decomposed, or structured, and it is natural to refine the program and the data specificationsin parallel.Every refinement step implies some design decisions. It is important that . . . the programmerbe aware of the underlying criteria (for design decisions) and of the existence ofalternative solutions . . .The process of program refinement proposed by Wirth is analogous to the process of refinement and partitioning that is used during requirements analysis. The differenceis in the level of implementation detail that is considered, not the approach.Refinement is actually a process of elaboration.We begin with a statement offunction(or description of information) that is defined at a high level of abstraction. Thatis, the statement describes function or information conceptually but provides no informationabout the internal workings of the function or the internal structure of theinformation. Refinement causes the designer to elaborate on the original statement,providing more and more detail as each successive refinement (elaboration) occurs.Abstraction and refinement are complementary concepts. Abstraction enables adesigner to specify procedure and data and yet suppress low-level details. Refinementhelps the designer to reveal low-level details as design progresses. Both conceptsaid the designer in creating a complete design model as the design evolves.《软件工程-实践者的研究方法》Roger S. Pressman博士(340页-343页)13.3 设计原则软件设计是一个过程也是一个模型。
