1、第一讲 软件与软件工程第一节 软件关键的概念:软件、软件角色、软件特点、软件分类、软件危机、软件问题、软件神话、遗留软件与软件进化。软件定义：软件是多种术语和对象的集合，并将这些术语和对象有效地配置在一起。一般包括程序、文档和数据。软件在整个社会体系中一般承担两种角色：软件首先作为一种服务社会的产品，提供计算的能力；产生、管理、获取、修改、显示或传送信息的功能其次软件也可以作为其他产品的承载工具，如支持或直接提供系统功能；控制其他的软件（如操作系统） ；辅助通讯（如网络软件） ；帮助建立其他软件（如软件工具） 。软件的特点：软件是被工程化的逻辑系统；软件一般没有磨损；软件具有不同于一般实物系统
2、的复杂性；软件分类：传统分类：系统软件；应用软件；工程和科学软件；嵌入式软件；专用产品软件；Web应用软件；人工智能软件；现代分类：随处计算软件（Ubiquitous computing, 无线网络 wireless networks 为代表） ；网络源软件（Netsourcing, the web as a computing engine） ；开源软件（免费开放的源代码对于所有感兴趣的人，是希望但也存在许多问题） ；数据挖掘（Data Mining） ；网格计算（Grid computing） ；认知机器（Cognitive machines） ；软件新经济研究；软件危机：软件危机是指在软
3、件发展过程中遇到的一系列严重问题。这些问题不是在解决具体问题时遇到的，而是软件开发过程所面临的具有普适性的问题。主要的典型表现有：1.对软件开发成本和进度的评估常常很不准确。2.用户对“已完成的”软件系统不满意3.软件产品的质量无法保障4.软件难以维护5.相关的开发文档不健全6.软件的重要性在不断提高7.软件开发的工作量的提高8.软件需求越来越复杂软件问题：为什么需要这么长的时间去获取一个可用的软件；为什么软件开发的费用这么高；为什么不能在将软件提交给我们的用户之前，发现所有的软件错误并解决它们；为什么需要花费那么多的时间和努力来维护已经在运行的系统；为什么无论在软件被开发还是在维护阶段我们都
4、那么困难来度量它；软件神话：所谓软件神话主要是针对三类人来说：软件管理者、软件客户和软件开发者。分析人们日常理解中的一些误区。例如：管理者角度有些人认为：对于软件开发有一些通用的能够适应所有需要的准则或程序，可满足所有的开发需求。实际情况是：这种理想是不现实的，即使有这种理想的东西存在，他也是不可用的。因为软件是一种社会性和变化性非常强的产品。有些人认为：如果软件产品的开发周期拖后了，可以通过增加人手来加快软件的开发速度，并尽快完成产品。实际情况是：软件产品的开发不同于普通机器的生产过程。一般来说，直观的感觉通过增加人手可以有效地提高劳动生产效率，但软件的开发，对于新加入的人来说还需要对其进行
5、有效的培训和熟悉需求要求的过程，因此综合考虑各种因素，简单地添加人手是不能很好地解决问题，有时还时工程进一步拖延。有些人认为：通过从第三方采购软件项目，就可以轻松地什么都不用做地完成项目。实际情况是：如果你不能够自己管理和控制软件，那你将永远不能够掌握用户，以及和第三之间的无休止的争吵。用户角度：有些人认为：一般对于需求的描述就足够开始编写程序了，详细的细节将由程序开发人员在开发过程中补充完善。实际情况是：在需求描述中综合且稳定的描述并不总是存在的。用户的需求往往描述的非常模糊，有时甚至充满冲突，只有保证一定的沟通时间才能够将需求正确的理解清楚。有些人认为：项目的需求在不断的改变，但由于软件是
6、灵活的因此这种变化可以轻易地被在软件中进行调整。实际情况是：对于这种变化在软件开发的早期可能比较容易调整，但如果到了软件开发的后期，这种变化有时将是致命的，有可能将导致整个软件的重新开发。开发者角度：有些人认为：一旦我们编写完程序，并使他们上线运行，那么我们的工作就完成了实际情况是：实际的工业数据显示，大约有 60%到 80%的软件产品提交给用户后还需要进行扩展。有句话说的好，你开始编写代码越快，而你将花费越长的时间来结束它。有些人认为：直到程序运行，我多没有办法来评估我的软件的好坏。实际情况是：软件的测试和度量技术都是对软件进行评估的好工具。有些人认为：仅仅可运行的软件产品才是用户需要的东西
7、。实际情况是：一个工作程序仅仅整个软件配置中各类元素之一，文档和相关的一些数据对于软件开发将更加重要。有些人认为：在编写软件过程中，还要编写文档和进行一些与编程无关的活动是浪费时间。实际情况是：编写文档和其他的一些工作将有效地减少重复工作的时间，加快工程的进度。遗留软件与软件进化:所谓遗留软件是指多年之前开发的，能够继续被修改以满足商业需要和计算平台的系统，对于这些系统的增殖处理常常是让一些大的组织头痛的事情，系统的维护费用和风险都将增大。软件的“再工程概念”的原因：软件必须适应新的计算环境和技术；软件必须增强新的功能，满足新商业需求；必须扩展软件，让他们和更加现代的系统和数据库交互；软件必须
8、进行在构造使他适应新的网络环境；软件进化的条件：软件必须被不断的改变；软件的复杂性将增加；维护组织的稳定性；维护相关产品的稳定性；软件的功能必须不断的增加；软件的质量在不断的衰退；多层反馈系统；第二节 软件工程关键的概念:软件工程、软件过程、 CMMI、ISO9001:2000、过程评估、过程框架、过程模板、过程技术、PSP、TSP 、任务集、雨伞行为（ Umbrella Activities） 。1软件工程：基本定义：1968 年 NATO 会议上的定义对于软件工程是软件工程概念的基础：为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理(sound engine
9、ering principles) 。这个定义仅仅是一个模糊的，非常基础的。对于一些问题什么是“完善的工程原理”？怎样“经济地”建造“可靠的”软件？等。1993 年 IEEEIEE93给出了一个综合全面的定义。软件工程是：1.把系统的、规范的、可度量的方法应用于软件开发、运行和维护过程，也就是把工程应用于软件；2.将第一点中提到的方法作为对象的研究活动；PressMan 提出的层次化软件工程概念（我认为这种从技术角度提出的层次化概念更容易理解，也更具有实用价值，比我们书中提出的软件工程的本质特性和软件工程的基本原理等内容更具体）：Pressman 提出软件工程是一种层次技术。作为整个软件工程的
10、基础，软件的品质问题是软件工程的核心问题，因此品质焦点是软件工程的基础技术。其次，软件工程的基础层是“过程层” ，软件工程过程是将各种技术层粘合在一起的胶合汁，从而能够合理、即时的开发软件系统。过程通过定义框架能够有效地运用各类软件工程技术，软件过程形成了管理控制软件项目的基础，并且建立各类技术方法被应用顺序关系。同时在软件过程中将产生一些主要的工作产品（如模型、文档、数据、报告、形式等，核心的里程碑被建立，软件品质被保证，软件的变化也被管理起来。第三层，软件工程的方法提供了多种怎样建立软件的技术。这些方法涉及到最广泛的任务内容，如通讯、需求分析、设计模型、程序构造、测试和维护。同时这些方法并
11、不是一些人意想的结果，他们具有一组坚实的理论背景，这些背景也可能是一些其他领域的研究结果。第四层，软件工程工具为软件工程和软件方法提供自动或半自动支持。统称称其为计算机辅助软件工程。这一节我们重点讲解软件过程的概念，因为通过对软件过程的理解，我们可以从一个较高的层面上更好地理解软件工程的作用和意义。对于软件工程在整个软件项目中的作用也可以有一个较好的分析。2软件过程为了了解软件过程的具体含义，我们首先需要搞清楚几个问题。什么是软件过程：当你建造一个产品或系统时，采用一系列可推断的步骤是非常重要的，这样一个路径表能够帮助你建立一个即时的、高品质的结果。这个所谓的路径表就是我们所说的软件过程。什么
12、人使用软件过程：软件工程师和软件项目管理者根据项目的需要选择使用软件过程，并遵循软件过程的要求进行分析设计。为什么软件过程是重要的：因为软件过程使软件的开发行为成为稳定的、可控制的和有组织的。一旦软件的开发行为变为失控，将造成整个软件开发活动的混乱。软件过程有那些步骤：通常情况下，你采用的软件过程主要依赖你所需要的建立什么样的软件系统。如一种过程可能非常适合建立飞机航空系统软件，而另一个完全不同的过程适合用于建立 Web 系统。应用软件过程会产生什么结果：a “quality” focusprocess modelmethodstools从软件工程的观点来看，软件过程所获得的产品是一系列依据软
13、件过程所定义的行为和任务的而产生的程序、模型、文档和数据等我们怎样能够确定软件过程产生的结果就是正确的哪？当前有多种软件过程的评价组织机制能够来确定各类软件过程的成熟度。无论如何，使用该软件过程建立的软件系统的品质、效率和长期的生存能力是该软件模型有效性的最好证明。2.1 软件过程的框架软件过程的框架通过封装一些阶段性的行为，并将这些行为普遍应用到各类软件项目中，而不需要考虑该项目的大小和复杂性等。这里给出一个具有一般性的通用过程框架：通讯：这个框架行为包括大量的与客户的通讯和协作，对于传统的软件工程来说就是其提出软件生命周期中的“问题定义” 、 “可行性研究”和“需求分析”等环节的过程行为。
14、计划：该行为为后续的软件工程的工作制定一个初步的计划。该计划描述了主要的技术任务、可能遇到的风险、需求的资源、系统完成的目标和完成这些需求的设计等。该部分相对于传统的软件工程来说类似于其中的“总体设计”工作。建模：该行为的主要任务是创建能够让开发者和客户都能够很好理解软件需求的模型，该模型以能够达到设计要求为基础。该部分相对于传统的软件工程来说类似于其中的“详细设计”工作。建模活动通常包括两类软件工程活动（分析和设计） 。其中分析又包括了多种工作任务（如需求的汇集、细化、协商、描述和确认等）来创建一个分析模型。同样，设计也包括了多种工作任务（如数据设计、体系结构设计、接口设计和组件层设计等）来
15、创建设计模型构造：该行为结合了代码设计和软件测试阶段的工作，该部分相对于传统的软件工程来说类似于其中的“编码和单元测试”和“综合测试”工作。部署：整个完成或部分完成的软件被提交给用户，让用户评估一下当前的产品，并提供相关的反馈意见。该部分相对于传统的软件工程来说类似于其中的“综合测试”和“软件维护”工作所有这些过程在具体实施时可能会有一些不同，但过程的框架行为始终保持不变。软件过程中还存在一些始终贯穿整个过程的雨伞行为，一般对这些行为的分类有：软件项目的跟踪和控制：由软件的评估者或管理者随时监控管理软件过程进行的情况，和项目计划进行对比，并有权采取有效的行动来维护开发的进度；风险管理：评估影响
16、项目成果和项目品质的风险；软件品质保障：定义和引导行为保障软件品质；形式化技术分析：评价软件过程产品的有效性，并在其中的错误传播到下一个行为之前修正它；度量分析：通过与其他的雨伞行为行为相结合，度量过程、项目和产品，帮助开发出的软件产品满足用户的需要；软件配置管理：有效地管理软件过程的变化；重用管理：定义中间产品被重用的标准，并建立一种实现重用组件的机制。中间产品的准备和生产：中间产品包括有，模型、文档、标记、表格和图等。软件过程模型在软件工程领域的应用历史已经有 30 年了。使用过程模型的目的是更好地管理项目、更有效地预测时间和花费、指导软件开发队伍执行与建设系统相关的工作。但遗憾的是许多时
17、候并不能达到这些效果，主要原因是教条和官僚的作风。过程模型强调项目的灵活性，因而最近几年在实际应用采用更多的都是一些非形式化的方法。这些敏捷的过程模型强调可操作性和适用性。过程模型的两种观点：严格的形式化描述和敏捷的可操作性描述。软件过程举例：CMMI（Capability Maturity Model Integration）CMMI 是 SEI 开发的一个综合过程元模型，主要描述软件企业规范开发的能力。CMMI 从两个方面表示一个过程元模型（1）作为连续模型；（2）作为阶段模型；连续模型：连续模型采用二维空间来描述一个过程。每个过程面依据特殊的目标和实践被形式化地评估，并相应的分配等级。P
18、P：Project planningREQM: Requirement managementMA: Measurement and analysisCM: Configuration managementPPQA: Process and product QA连续模型的能力层次：0 层（不完全层）：既没有执行也没有达到所有的过程面；1 层（执行层）：CMMI 定义的所有过程面已经被满足；2 层（管理层）：达到 1 层要求的内容。并且，所有和过程面相关的工作在一个有续的组织下进行。所有的工作任务和工作产品是“可监控的、可控制的、可重复的和可评估的”3 层（定义层）：所有 2 层的内容都已经满足，
19、并且根据组织的一些优化原则可以自主地调整标准的软件过程。4 层（量化管理）：3 层的要求已经达到。另外，可以根据度量和量化的评估结果主动地控制和改进过程面。5 层（优化）：所有第四层的能力已经达到，并且过程面可以依据用户的需要而适时的优化和改进什么是特殊的目标和特殊的实践？CMMI 采用特殊的目标和特殊的实践来定义每一个过程面，特殊目标是指当过程面所隐含的行为是有效的，则建立该必须存在的特性。特殊实践是指精化目标成为一组过程相关的行为。543210 PP REQM MA CM PPQA Other阶段模型：阶段模型定义了与连续模型同样的过程面、目标和实践。两者之间的基本不同是阶段模型定义的五个
20、成熟度层次，而连续模型是五个能力层次。成熟度层次 核心工作优化 对过程进行适合用户的改进量化管理 精确地控制、调度活动定义 确定过程标准管理 基本的过程管理执行 没有任何的管理工作2.2 过程模板软件过程可以被定义为一组模板的集合，过程模板：是指在软件开发过程中获取到的一组行为、行动、工作任务、工作产品，以一些相关的行为的集合。更通俗地讲，过程模板为我们提供了一个框架（如一致的用于描述软件过程的重要特性的方法） 。过程模板：提供了一种有效地描述软件过程的机制，从一个较高的抽象层次开始，采用层次式过程描述。过程模板的另一个好处是可以重用过程模板的实例：模板名：意图：类型：初始内容：问题：解决：结
21、果内容：相关模板：2.3 过程评估ISO9001:2000这是一个应用于任何想改进产品质量，系统和服务的企业的一般标准。2.4 个人和团队过程模型PSP 和 TSPPSP 强调记录和分析个人产生的各种错误的类型及其原因是非常重要的，并且你可以自己思考一些策略来消他们。TSP 强调将一些团队因素添加到软件工程和行为中。如建立团队角色、平衡团队中不同成员的工作量，实现最小代价。2.5 过程技术通过提供一些辅助软件过程应用的工具来分配、监视和控制所有软件过程的工作任务。第三节 过程模型什么是过程模型：通过使用模型简洁地描述软件过程中各项活动、任务、中间产品和里程碑的完成过程，如传统软件工程中所定义的
22、生命周期模型就是一类过程模型。整个过程模型被划分为两种类型：说明性过程模型和敏捷过程模型。说明性过程模型之所以被称之为“说明”是因为他描述了一组过程元素（框架行为、软件工程行为、任务、工作产品、品质评估和变换控制机制等） ，并规定了这些元素之间的相互关联关系，即工作流。说明性过程模型强调结构和次序，与当前不断变换的软件世界不太适应。而敏捷过程模型强调自组织、协作、交流、适应性为主导的过程哲学。其虽然克服了说明性软件过程模型的不足，但怎样达到软件工作过程中的协作和一致有成为它的难点。主要的说明性过程模型：Software ProcessSoftware ProcessAssessmentSoft
23、ware ProcessImprovementSoftware ProcessDetermination识别修改被检查导致 导致激发识别能力和风险瀑布模型：增量模型：增量模型中的快速应用开发（RAD）Communicat ion Planning ModelingConst ruct ion Deployment analysis designcode testproject init iat ion requirement gat hering estimating scheduling trackingdelivery support f eedbackCo m m u n i c a t
24、 i o nP l a n n i n gM o d e l i n gCo n s t r u c t i o nDe p l o y m e n t d e l i v e r y f e e d b a c kanalysis design code t estincrement # 1increment # 2delivery of 1st incrementdelivery of 2nd incrementdelivery of nt h incrementincrement # nproject calendar timeCo m m u n i c a t i o nP l a
25、n n i n gM o d e l i n gCo n s t r u c t i o nDe p l o y m e n t d e l i v e r y f e e d b a c kanalysis design code t estCo m m u n i c a t i o nP l a n n i n gM o d e l i n gCo n s t r u c t i o nDe p l o y m e n t d e l i v e r y f e e d b a c kanalysis design code t est进化模型-原型法Co m m u n icat io
26、 nPlan n in gMo d e lin gbusiness modeling dat a modeling process modelingCo n st r u ct io ncomponent reuse aut omat ic codegenerat ion t est ingDe p lo ym e n t6 0 - 9 0 d aysTeam # 1Mo d el i ngbusiness m odeling dat a m odeling process m odelingCo nst r uct i o ncom ponent reuse aut om at ic cod
27、egenerat ion t est ingM o d e lin gbusiness m odeling data m odeling process m odelingCo n s t r u c t io ncom ponent reuse autom atic codegeneration testingTeam # 2Team # nint egrat ion delivery feedback进化模型-螺旋Co m m u n icat io nQu i ck p l anCo n st r u ct io n o f p r o t o t yp eMo d e l i n g
28、Qu i ck d e si g nDe live r y Agile team assesses each story and assigns a cost;Stories are grouped to for a deliverable increment;A commitment is made on delivery date;After the first increment “project velocity” is used to help define subsequent delivery dates for other increments;XP DesignFollows
29、 the KIS principle;Encourage the use of CRC cards;For difficult design problems, suggests the creation of “spike solutions”a design prototype;Encourages “refactoring”an iterative refinement of the internal program design;XP CodingRecommends the construction of a unit test for a store before coding c
30、ommences;Encourages “pair programming”;XP TestingAll unit tests are executed daily;“Acceptance tests” are defined by the customer and executed to assess customer visible functionality;设计计划 编码测试User storiesValuesAcceptance test criteriaIteration planSimple designCRC cardSpike solutionsPrototypesRefactoring软件增量项目速度计算接受测试 单元测试，继续集成Pair programming
