第一章

软件过程：需求  设计  实现  发布

软件过程三要素: 过程+方法+工具

瀑布 rup scrum Iconix

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。

Product Owner、 Scrum Master、 Team Product Backlog、 Sprint

Backlog、Burndown Chart、Sprint、 Sprint Planning Meeting、

Daily Standup Meeting、 Review Meeting、 Retrospective Meeting

ICONIX软件开发过程

愿景、业务建模、需求分析、健壮性分析、系统设计……

思想是重点；过程是方式；方法和工具是载体

第二章

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。         敏

捷是一种思想       ?Scrum是一个框架

敏捷开发过程知多少？

?Scrum、

?极限编程（XP）、

?Crystal Methods（水晶方法族）

?特性驱动开发（FDD）

?动态系统开发（DSDM）

?轻量型统一过程（RUP）

调查结果：敏捷开发方法—Scrum最流行！

Scrum的适用场景

?7人，+or-2

?偏小一些会更适合

?最好能坐在一起

?客户参不度高

?快速移动互联网项目

?自主性研发的产品

第三章

 软件项目是为了改善某个组织的某些方面

–老大就是要改善的组织中最有权力的干系人。

用户建模四步曲

1 列出尽可能多的用户

2 识别关键用户（购买决策者/主要使用者）

3 分类，合并次要用户

4添加虚拟和极端用户

第四章

?产品backlog是Scrum的核心

产品功能列表格式

?ID（标示符）

–统一标识符

?Name（标题）

–简短的、描述性的故事名

?Story（故事）

–故事内容描述

?Priority（重要性）

–产品负责人评出一个数值，指示这个故事有多重要

?Initial estimate（初始估计）

–团队的初步估算，表示不其他故事相比，完成该故事所需的工作量

?How to demo（如何做演示）

–它大略描述了这个故事应该如何在sprint 演示上进行示范

?Notes（注解）

–相关信息、解释说明和对其它资料的引用等等

产品功能列表由谁来写？

?思考：由谁来写？

–主要是Product Owner

–Team也有权利，但最终由PO进行取舍。

用户故事是一种敏捷的需求挖掘方式，其侧重点不是将需求书写出来，而是将需求讨论出来。

按“作为一个……，可以……，以便……”样式和思路写成的用户需求，就是用户故事。

用户故事的三个变量

 范围，重要性，估算

好故事的准则

?独立的（Independ）

?可讨论的（Negotiable）

?对用户戒客户有价值的（Valuable）

?可估计的（Estimatable）

?小的（Small）

?可测试的（Testable）

Sprint会议如何迚行

–确定Sprint目标及长度

–讲解Story、估算时间、任务分解

–决定 sprint 要包含的故事

–一些其他问题

第六章

什么是界面原型

?界面原型指使用工具根据客户需求及软件分析人员的理解，将头脑中的界面快速的反映到介质上。

界面原型的目的

?尽早验证需求

?尽早明确不确定性的因素

?方便沟通交流

?为后续界面设计提供基础

第八章

ICONIX过程

?ICONIX过程的规模介于RUP和XP之间

?适合中小型的、需求相对明确的软件项目

?ICONIX核心思想

?开源！节流！

ICONIX软件过程是用例驱动的软件过程。

ICONIX过程中的第一步：明确愿景

?愿景是确保项目成功的第一步；

?愿景必须来自老大；

?愿景必须是可度量。

如何获取软件项目的愿景

?获取软件项目愿景的三步曲：

?第一步：找到软件项目的“老大”；

?第二步：得到“老大”对项目的期望（愿景）；

?第三步：描述出愿景的度量指标；

要点：系统要改善哪个组织的流程？

老大就是要改善的组织中最有权力的干系人

第九章

业务建模的目的：从组织的角度来定位系统的价值。

业务建模

?业务建模的目的是把视角从系统转向组织，站在客户角度看问题。

?业务用例是对组织为外部业务执行者提供的价值的建模。

?现状业务序列图是对组织价值内部实现流程（业务工人与业务实体的协作）的建模

?改迚业务序列图是对新系统为组织提供的改良的建模。

业务建模的步骤：

1.明确我们为谁服务（选定愿景要改进的组织）。

2.要改进的组织是什么现状（业务用例图、现状业务序列图）。

3.我们如何改进（改进业务序列图）。

第十章

域建模的步骤

第一步：提取名词或名词短语

第二步：排除重复、相似

第三步：排除系统范围外

第四步：画出第一版域模型图

第五步：整理第一版域模型

域模型之间的关系

?泛化[Generalization]，一般元素和特殊元素的关系。

?关联[Association]，两个类乊间存在着某种语义上的联系。

系统需求分析的目的是把视角转向新系统，站在最织

用户（及其它干系人）的角度看问题。

? 系统用例是对（新）系统为系统执行者提供的价值的

建模

系统用例建模步骤

1.绘制系统用例图

2.编写系统用例描述

3.更新域模型

绘制系统用例图

1.确定系统边界

2.识别系统执行者

3.识别系统用例

4.确定用例间的关系

用例描述的作用

?用例图描述总体，用例文档描述绅节。

?每个用例必须对应有用例描述。

用例描述的基本组成

?干系人利益

?基本路径

?扩展路径

?业务觃则

软件产品的典型非功能性需求(RUPS)

?可靠性[Reliability]。

?可用性[Usability]。

?性能[Performance]。

?可支持性[Supportability]。

需求获取的方法

?研究文档。

?问卷调查。

?访谈。

?观察。

?研究竞争对手。

需求分析结果复核

?形式：面对面会议。

?参会人：甲乙双方在需求分析阶段的主要参与者。

?被审材料：域模型、用例图、用例描述、非功能性需求；

?过程：需求分析师主持，最终需求分析成果，所有参与者交流讨论，达成统一理解和确认。

?结论：所有参与者签字确认。 （当然， 也有可能是未达成共识，需要返工。）

?注意：后续的工作基本不需要 用户的参不了。

第十一章

健壮性分析的步骤

第一步：创建一个空的健壮性图。

第三步：从基本路径的第一句话开始画健壮性图。

第二步：直接将用例文本粘贴到图上（基本路径和扩展路径）。

第四步：贯串整个用例基本路径，一次一个句子，画执行者、适当的边界对象和实体对象以及控制器，和各元素乊间的连线。

第五步：将每一个扩展路径画在健壮性图上，并以红色标示出。

在用例驱动的开发模式中，用例的准确完整性是关键；

?健壮性分析技术两个主要的价值：其一帮助完善用例分析结果；其二完善域模型，做为需求分析走向系统设计的过度技术；

?丌要花费太多的精力和时间在本阶段，本阶段的成果也仅起到过度作用，不纳入最终文档；

第十二章

关键设计是功能性需求的设计，成果为类图和序列图；

?关键设计还没考虑真实实现的平台相关因素，因此不能基于这个阶段的设计成果开始编码；

?关键设计的方法就是在域 模型、用例描述和健壮性分析的基础上，迭代生成类图和序列图；

关键设计的步骤

?第一步：将现有的域模型直接作为第一版静态类模型；

?第二步：基于用例描述和健壮性分析结果，画出每个用例的序列图；

?健壮性图中的控制类会转化为方法；

?如果也转化为控制类，那么就添加到类图中（注意：边界类丌添加到类图中）；

?第三步：整理静态类图和序列图；

?第四步：关键设计复核，迭代更新用例图、类图和序列图；

高内聚、低耦合。是判断设计好坏的标准。

关键设计复核的指导建议

?确保关键设计的“如何做”和需求阶段的“做什么”匹配。也就是说每个用例都要和序列图匹配，包含了用例的基本流程和分支流程。

?复核设计的品质。应该至少有一个设计与家在场。

?检查消息的连贯性。检查时序图上消息箭头的指向，有时我们会发现对象乊间缺少消息而造成跳跃，我们必须消除这些逻辑跳跃。

?确保方法分配给了适当的类，类视图中的每一个类拥有适当的方法和属性。

第二篇：软件工程重点总结

软件的定义：软件是计算机系统中与硬件相互依存的另一部分，软件包括程序、数据及其相关文档的完整集合。

在结构化程序设计时代，程序的最小单位是向对象程序设计时代，程序的最小单位是类，在类中封装了相关的数据及指令代码。 软件的特性：形态特性、智能特性、开发特特性、维护特性、废弃特性、应用特性。 软件的分类：系统软件、应用软件、支撑软 软件危机的表现：软件开发周期长、成本高、

软件危机发生的原因：（1）缺乏软件开发的工作的计划很难制定。（2）软件人员与用户的交流存在障碍。（3）软件开发过程不规范，缺少方法论和规范的指导，开发人员各自为战，缺少整体的规划和配合，不重视文字资料工作，软件难以维护。（4）随着软件规模的增大，其复杂性往往会呈指数级升高。（5）缺少有效的软件测评手段，提高用户的软件质量差，在运行中暴露出大量的问题，轻者影响系统的正常使用，重者发生事故，甚至造成生命财产的重大损失。

首次提出“软件工程”的概念的时间是19xx年。

按工程化的原则和方法组织软件开发工作是 软件工程的定义：软件工程是指导软件开发和维护的工程性学科，它以计算机科学理论和其他相关学科的理论为指导，采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经过时间考验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来，以较少的代价获得高质量的软件并维护它。

软件工程的目标是运用先进的软件开发技术 衡量软件的质量的六个特性：功能性、可靠

软件生存期的三个时期：软件定义、软件开定义时期的主要任务是解决“做什么”的问地满足用户的需要。

开发过程中的典型文档包括：软件需求规格计说明书、用户手册。

各个阶段所要完成的基本任务：问题定义与可行性研究、需求分析、软件设计、程序编码和单元测试、集成测试和系统测试、软件运行和维护。

典型的软件生存期模型包括瀑布模型、原型模型、增量模型、螺旋模型等（喷泉模型）。

瀑布模型的特点：1）阶段间具有顺序性和依赖性。2）推迟实现的观点。3）质量保证的观点。

瀑布模型的优点：①可强迫开发人员采用规范化的方法。②严格地规定了每个阶段必须提交的文档。③要求每个阶段交出的所有产品都必须是经过验证（评审）的。

瀑布模型的缺点：①由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况。②瀑布模型只适用于项目开始时需求已确定的情况。

快速原型模型的优点：①有助于满足用户的互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。③软件产品的开发基本上是按线性顺序进行。④因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。⑤开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。⑥快速原型的本质是“快速”。开发人员应该尽可能快地创造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型可以抛弃，当然也可以在原型的基础上进行开发。

增量模型的优点：①能够在较短的时间内向构件交付之日起，用户就能做一些有用的工作。②逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少全新的软件可能给用户组织带来的冲击。③项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。④优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。一个必然的事实是：最重要的系统服务将接受最多的测试。这意味着系统最重要的部分一般不会遭遇失败。

螺旋模型的优点：①对可选方案和约束条件软件质量作为软件开发的一个重要目标。②减少了过多测试或测试不足所带来的风险。③在螺旋模型中，维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。 螺旋模型的缺点：螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。

方法学：通常把在软件生命周期全过程中使用的一整套技术的集合称为方法学，也称为范型。

软件工程方法学三个要素：方法、工具和过传统方法也称为生命周期方法或结构化范项任务。这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地逐步完成每个阶段的任务。每个阶段的开始和结束都有严格的标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每个阶段结束之前都必须进行正式评审，评审通过之后这个阶段才结束，否则就需要返工，返工之后还要评审。评审的一条主要标准就是每个阶段都应该交出高质量的工作产品，其中，前面阶段的工作产品主要是文档，如需求规格说明书、软件设计说明书等。

面向对象方法的基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法和过程尽可能接近人类认识问题和解决问题的方法与过程，从而使描述问题的问题空间与其解空间在结构上尽可能一致。

封装的定义：封装是一种信息隐蔽技术，就作封装在一起。①清楚的边界②接口③受保护的内部实现

软件需求分析阶段的主要工作产品有“软件需求规格说明书”和“初步的用户手册” 需求获取的主要任务是与客户或用户沟通，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作

需求获取产生困难的原因：系统的目标或范围问题，需求不准确性问题，需求的易变问题

需求获取活动需解决的问题：1.发现和分析问题，并分析问题的原因/结果关系2.与用户进行各种方式的交流，并使用调查研究方法收集信息3.按照三个成分即数据、过程和接口观察问题的不同侧面4.将获取的需求文档化，形式有例图、决策表、决策树等 软件需求分析阶段的工作4个步骤：需求获取，需求分析，需求定义，需求验证

数据字典以词条方式定义在数据模型、功能息的特性，给出它们的准确定义

设计是技术世界和人类的目标世界结合在一

软件设计的原则：(1)分而治之(2)模块独立(4)复用性设计 (5)灵活性设计

模块独立性，是指软件系统中每个模块只涉

复用是指同一事物不做修改或稍加修改就可质量及生产率的重要方法，软件复用已不再局限于软件代码的复用，复用范围已经扩展到软件开发的各个阶段，包括需求模型和规格说明、设计模型、文档、测试用例等复用。 模块间的耦合和内聚两个准则来度量模块独的紧密程度）的度量，内聚是模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量。模块独立性比较强的模块应是高度内聚、松散耦合的模块。

在最高的抽象层次上，可以使用问题所处环境的语言概括地描述问题的解决方法：在较低的抽象层次上，采用更过程化的方法，将面向问题的术语和面向实现的术语结合起来描述问题的解法；在最低的抽象层次，则用某种程序设计语言来描述问题的解法。 从工商管理的角度，可以将软件设计分为两个阶段：概念设计阶段和详细设计阶段。 结构图是精确模块结构的图形表示工具。清联系。(1)模块的条用关系和接口(2)模块间的信息传递(3)辅助符号(4)结构图的形态特征(结构图的深度、宽度、扇入和扇出) 过程描述工具有：图形工具、表格工具、语

自顶向下、逐步求精方法的优点：1)自顶向遍规律，，可提高软件开发的成功率和生产率2)用先全局后局部、先整体后细节、先抽象后具体的逐步求精的过程开发出来的程序具有清晰地层次结构，因此程序更容易阅读和理解3)程序自顶向下，逐步细化，分解成树形结构4)程序清晰和模块化，使得在修改和重新设计一个软件时，可复用的代码量最大5)程序的逻辑结构清晰，有利于程序正确性证明6)每一步工作尽在上层结点的基础上做不多的设计扩展，便于检查7)有利于设计的分工和组织工作

软件测试：在软件投入生产性运行之前，对复审，是软件质量控制的关键步骤。软件测试是为了发现错误而执行程序的过程。

软件测试的目的：①测试是程序的执行过程，目的在于发现错误；②一个好的测试用例在于能发现至今未发现的错误；③一个成功的测试是发现了至今未发现的错误的测试。 软件测试的目标是想以最少的时间和人力系 软件测试的原则：1、尽早地和不断地进行软之对应的预期输出结果这两部分组成；3、程序员应避免检查自己的程序。

测试过程需要三类输入：软件配置、测试配控制流图是描述程序的控制流的一种图示方

环路复杂性V（G）的计算方法：1、环路复2、设E为控制流图的边数，N为图中的结点数，则V（G）=E-N+2；3、设P为控制流图中的判定结点数，则V(G)=P+1.

独立路径：是指包括一组以前有没有处理的语句或条件的一条路径。

等价类划分是一种典型的黑盒测试方法。 有效等价类：是指对于软件的规格说明来说，合理的、有意义的输入数据构成的集合。利用它可以检查程序是否实现了规格说明预先规定的功能和性能。 无效等价类：是指对于软件的规格说明来说， 软件测试过程的4步骤：单元测试、组装测试、确认测试和系统测试。

驱动模式：相当于被测模块的主程序。它接受测试数据，把这些数据传送给被测模块，最后再输出实测结果。

桩模块：也叫存根模块。用以代替被测模块

把模块组装为系统的方式通常有：一次性组确认测试又称有效性测试。它的任务是验证软件的有效性，即验证软件的功能和性能及其他特征是否与用户的要求一直。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。

面向对象分析模型由3个独立的模型构成：用类和对象表示的静态模型（对象模型）；有状态图和顺序图表示的动态模型（交互模型）。

以上3个模型的重要程度是不同的。用例模型是整个后续工作的基础，也是测试与验收的依据。由于面向对象系统中，类、接口、及对象是软件的基本组成单元，因此对象模型是必须建立的，也是核心模型，几乎解决任何一个问题都需要从客观世界实体及实体间的相互关系抽象出极有价值的对象模型；当问题涉及交互作用和时序是，动态模型是重要的。

复杂的大型系统的对象模型由5个层次组

在系统分析阶段，对象建模的主要任务是建世界中的类与对象以及它们之间的关系，而非实际的软件类或实际构件。

软件维护类型：改正性维护，适应性维护，

影响维护工作量的因素：1.系统规模；2.系4.数据库技术的应用水平；5.所采用的软件开发技术及软件开发工程化的程度；6.其他。 针对三种典型的维护，提出策略以控制维护成本。改正性维护的策略方法：数据库管理高级（第四代）语言。

软件维护性定义：指当对软件实施各种类型能力。

软件维护性子特性：易分析性，易变更性，

提高软件维护性的开发技术和工具：1.使用2.实施开发阶段产品的维护性审查；3.改进文档。