1、用户代表与所开发的系统进行交互的某个人或某个系统（所开发系统之外的另一个系统）。用例是能够向用户提供有价值结果的系统中的一种功能。所有的用例合在一起构成用例模型。特点：确定系统需求的工具，传统的系统功能说明：系统应该做什么？用例模型 ：增加三个词for each user。驱动软件开发过程，RUP三大特点中第一大特点为“用例驱动”。构架是系统在其所处环境中最高层次的概念。软件系统的构架是指通过接口交互的重要构件的组织和结构，这些构件又由一些更小的构件和接口组成。RUP三大特点中第二大特点为“以构架为中心”。工作流程是在业务中执行的活动序列，它对于业务主角个体生成一个可见值结果。迭代是指带有已建
2、立基线的计划和评估准则的独特活动序列，迭代生成内部或外部的发布版本。增量是指在后续迭代结束后，两个发布版本之间存在的差异或差值。 RUP三大特点中第三大特点为“迭代和增量的过程”。在软件过程组织的环境中，个人或协同工作的小组的行为和职责定义为角色，角色代表项目中个人承担的作用，并确定了如何完成工作。活动是要求角色执行的工作单元。工件是指一条信息，该信息：由过程生成、修改或使用；定义了职责范围；受到版本控制。里程碑是迭代正式结束的时间点，该时间点与发布时间点相对应。阶段是指项目相邻两个主要里程碑之间的时间段，在此期间要实现一组既定的目标、完成工件并决定是否进入下一阶段。3.RUP二维结构生命周期
3、：横轴通过时间组织，体现开发过程的动态结构。术语主要包括阶段、里程碑、迭代和增量。纵轴将内容组织为逻辑活动，体现开发过程的静态结构，术语主要包括工作流程、活动、角色、工件。4.RUP静态结构：九个核心工作流程。工作流程代表了所有角色、活动与工件的逻辑分组情况，即软件过程模式中的三个要素。九个核心工作流程组成：核心过程工作流程：前6个，核心支持工作流程：后3个。业务建模：产生的主要工件为业务模型； 需求：用例方法：对需要的功能和约束进行提取、组织、文档化，理解系统所解决问题的定义和范围。产生的主要工件为用例模型，用户界面模型；分析设计：以构架设计为中心：产品的适应性、可扩展性。产生的主要工件为一
4、个设计模型、一个分析模型（可选）。实现：产生的主要工件为实施模型（模型元素包括实施子系统和构件）。测试：产生的主要工件为测试模型（模型元素包括测试用例、测试过程和测试构件）+测试结果。部署：产生的主要工件为产品的一个版本+文档培训资料。配置和变更管理：产生的主要工件为配置管理计划、变更请求、项目存储库和工作区。项目管理：产生的主要工件为商业理由、迭代计划、风险管理计划、质量保证计划及相应的评估文档。环境：产生的主要工件为工作流程指南、工具、工具指南。5.RUP动态结构：四个阶段。每个阶段由一次或多次迭代完成，迭代过程是受控的。先启阶段：目标：建立业务用例、确定项目的边界，结束里程碑：生命周期目
5、标里程碑。精化阶段：建立稳定的构架、编制项目计划、淘汰项目中最高风险的元素，结束里程碑：生命周期构架里程碑。构建阶段：所有构件和应用程序功能被开发并集成为产品、所有的功能被详尽的测试，结束里程碑：最初操作性能里程碑。产品化阶段：将软件产品交付给用户群体，结束里程碑：产品发布里程碑。6. RUP与螺旋模型异同点：相同点：二维迭代特性。重复一系列组成系统生命周期的循环；每次循环的结束是向用户交付产品的一个运行版本；每个循环由若干次迭代组成；每次迭代需要进行风险分析处理；每次迭代结束的标志是交付一个增量。螺旋模型：每次迭代历经笛卡儿坐标系中四个象限的四个方面活动，RUP：每次迭代历经九个核心工作流程
6、中的若干个。不同点：螺旋模型未给出每次迭代过程结束交付的增量原型的具体要求；也未给出不同次迭代在历经的笛卡儿坐标系中四个象限的四个方面活动的内容与重点的不同。RUP将整个生命周期划分为四个阶段，明确给出了每个阶段内的若干次迭代过程完成后交付的增量的具体要求，即四个阶段的主要里程碑生命周期目标里程碑、生命周期构架里程碑、最初操作性能里程碑和产品发布里程碑；同时详细阐述了不同阶段中的不同迭代过程历经的九大核心工作流程中活动内容的重点和强度的不同；提供了对每次迭代过程中不同核心工作流程活动的并行化支持。RUP的二维生命周期结构对“迭代”意义的体现比螺旋模型更深刻、具体、详尽、全面，更具可操作性。7.
7、 RUP的优点：相对瀑布类模型：将成本风险进一步降低为获得一次增量所需费用；进一步降低了产品不能按计划投放市场的风险；使项目开发更能适应项目需求的变化。相对螺旋类模型：用于指导需求不明确、不稳定的项目开发时具有更强的可操作性。8.RUP人员角色：分析员、开发人员、测试员、经理、其他角色。角色的意义：将角色与个体区分开。某种角色：一个或多个相互协作的个体完成，一个个体担任一种或多种角色。制定迭代计划：确定每个阶段、每个工作流程中需要的角色；制定人员计划：考虑人员的技能、能力经验，将一个或多个角色分配给一个适合的人员完成。有效提高了项目中人力资源的利用率。缺陷：论述不够深入，忽略了角色的质量，未给
8、出角色的组织管理方式、角色间的相互地位关系和交互方式。体现过程可操作性的一个重要方面，RUP未给出。9.RUP方法：（1）用例及用例驱动。采用用例的两个原因：用例被证明是捕获需求的一种有效方法。达到需求捕获的第一个目标：发现多样性的需求（传统的系统功能说明：增加三个词for each user），达到需求捕获的第二个目标：以适用于用户和开发人员的方式加以表示；用例驱动整个过程。（2） 以构架为中心。构架描述：5个视图： 用例模型视图、分析模型视图、设计模型视图、实施模型视图、实现模型视图。每个视图是对应模型的精华与核心部分。意义：理解系统，组织开发，鼓励重用和进化系统。（3）在面向对象的分析设
9、计中采用UML进行可视化建模。（4）面向对象的设计与构件实现。10.RUP产品工件：项目期间生成的中间或最终产品。工件类型：根据RUP的各工作流程：划分为业务建模工件、需求工件、分析设计工件、实施工件、测试工件、部署工件、配置与变更管理工件、项目管理工件、环境工件；根据物流方向：划分为输入工件、输出工件和辅助工件；根据存在形式：划分为模型、模型元素、文档、源代码、可执行文件。11.RUP特点：优点：作为一种软件过程：RUP具有二维迭代性，有利于降低风险、适应需求变化；RUP是可配置的过程，具有通用性；作为一种软件过程模式：相对传统的软件生命周期模型具有较强的可操作性；作为一种软件过程产品：具有
10、实用性、可操作性与可实现性。与软件过程模式配置操作相关的因素1 软件过程模式中生命周期、人员、方法、产品四大要素之间的相互关系和相对优先级；2 各生命周期元素间的相互关系和相对优先级；3 人员间的协作关系与协作方式、人员的质量、各种人员的相对优先级；4 各种方法间的相互关系及相对优先级；5 各种产品的相对优先级。结论：RUP是一个具有突出优点的软件过程模式；RUP还很不完整，在实际应用中仍需进一步吸收其它优秀的软件开发实践经验以对其进行补充和完善。第3章 敏捷过程1.什么是AP：敏捷软件开发宣言：软件团队具有快速工作、快速响应变化的能力，制订了4条基本价值观和12条原则。敏捷过程（Agile
11、Process）是一种典型的软件过程模式，对软件过程模式中的四大要素（生命周期、人员、方法、产品）及相互关系均进行了论述。2.AP流派：极限编程XP、SCRUM、动态系统开发方法DSDM、水晶系列方法、开放式源码、适配性软件开发ASD、适配性软件开发ASD。3.AP的4条价值观：个体和交互胜过过程和工具。人是软件项目获得成功最为重要的因素，当然，不好的过程和工具也可以使最优秀的团队成员失去效用、合作、沟通以及交互能力要比单纯的软件编程能力更为重要；合适的工具对于成功来说非常重要，工具的作用不可被过份地夸大，建议从使用小的工具开始。团队的构建（包括个体、交互等）要比项目环境（包括过程、工具）的构
12、建重要得多；应该首先致力于构建团队，然后再让团队基于需要来配置环境。可以工作的软件胜过面面俱到的文档。软件的重要性：交付给用户可以工作的软件而不是文档，否则应该称之为文档开发而不是软件开发。文档的作用：没有文档的软件是一种灾难，过多的面面俱到的文档比过少的文档更糟。准则：软件开发的主要和中心活动是创建可以工作的软件；直到迫切需要并且意义重大时，才进行文档编制；编制的内部文档应尽量短小并且主题突出。客户合作胜过合同谈判。客户不可能做到一次性地将他们的需求完整清晰地表述在合同当中：客户需求的多样性，客户需求还可能随时发生变化。全方位的满足客户需求的有效途径：开发团队与客户紧密协作，为开发团队和客户
13、的协同工作方式提供指导的合同是最好的合同。响应变化胜过遵循计划。变化是软件开发中存在的现实：商务环境可能会变化，这会引起需求的变动；随着系统逐渐开始运做，项目关系人（包括开发人员与客户）对系统的理解也会发生变化；技术随着时间也在变化。响应变化的有效途径之一是制定灵活可塑的计划：制定计划的策略细致度逐渐降低的计划。*4.AP的12条原则：最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。经常性交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。在整个项目开发期间，商务人员和开发人员必须
14、天天都工作在一起。围绕被激励起来的个体来构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。工作的软件是首要的进度度量标准。敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。不断地关注优秀设计的技能和好的设计会增强敏捷能力。简单使未完成的工作最大化的艺术是根本的。最好的构架、需求和设计出自于自组织的团队。每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。*5.XP实践：客户作为团队成员。用户素材。短交付周期。验收测试。结对编程（由两个开
15、发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人负责编码，而另一个负责保证代码的正确性与可读性。作用：结对编程是一种非正式的同级评审，它要求成对编程的两个开发人员在性格和技能上应该相互匹配）。测试驱动开发（强调“测试先行”，RUP对测试也是非常的重视，只是RUP和XP两者对于测试在整个项目开发周期内首先出现的位置处理不同）。集体所有权。持续集成（提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试，持续集成不是XP专有的最佳实践，微软公司就有每日编译的成功实践）。可持续的开发速度。开放的工作空间。计划游戏（计划是持续的，循序渐进的。根据项目的进展来进行项目计划的调整，一
16、成不变的计划是不存在）。简单的设计。重构（指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。重构不是XP所特有的行为）。隐喻（将隐喻看成整个系统联系在一起的全局视图、系统的未来影像，RUP的构架视图）。6.AP的生命周期：敏捷过程是一个一维的迭代过程。该过程中的每一个生命周期循环交付一个有价值的软件版本，各循环可持续进行。RUP的二维双重的迭代过程：RUP整个过程是若干次生命周期的不断循环；每个循环包括先启、精化、构建和产品化四个阶段，每个阶段由一次或多次迭代完成，每次迭代可能经历九个核心工作流程中的若干个；项目进度衡量的首要标准是各阶段的主
17、要里程碑，包括生命周期目标里程碑、生命周期构架里程碑、最初操作性能里程碑和产品发布里程碑。AP相对RUP：具有对变化和不确定性的“更快速、更敏捷”的反应特性；快速的同时仍保持可持续性；该特性能较好地适应商业竞争环境下对小型项目提出的有限开发时间的约束。*7.AP的人员：（1）客户角色的重要性：对客户角色重要性进行突出强调；RUP：无。（2）个体间的相互关系和协作方式：相互关系：个体相互的地位关系是平等的，职责是共同的。协作方式：首要协作交互方式为面对面的交谈；也编写文档，但文档仅作为辅助交互方式。未给出个体间地位关系，协作方式为“形式化的文档模型”这一书面形式而非口头交谈方式。结合AP和RUP
18、：个体间的职责进行明确分工，同时个体间为平等协作关系；个体间的交互方式首选交谈，但在必要情况下，如交谈的结果将作为设计开发的依据，则有必要编写文档或创建模型，以书面的形式记录交谈的结果。8.AP的方法：（1）动态满足需求从欢迎变化、与客户合作到响应变化。步骤一：欢迎变化；步骤二：与客户合作；步骤三：响应变化。（2）简单化。区别：考虑产品的适应性、可扩展性与可重用性等高性能特性，提倡以构架为中心的设计方法，要求构架必须留有实现现在和未来需要的所有用例空间。AP：要求在设计阶段尽可能的识别出最简单的构架。联系：是对产品不同质量要求的不同的应对策略。简单质量要求环境：在可预见的最近几次生命周期内，对
19、产品质量仅为无缺陷要求，而对适应性、可扩展性、可重用性等高性能指标没有要求，采用AP的简单化设计方法，以达到快速开发的目的。复杂质量要求环境：在可预见的最近几次生命周期内，对产品质量不仅为无缺陷要求，而且对适应性、可扩展性、可重用性等高性能指标可能有若干要求。采用RUP的以构架为中心设计方法，以避免可能发生的系统整体重构造成最终开发效率的极速下降。（3）团队持续自我反省。9.AP的产品：（1）各类产品的优先级AP：第2条价值观，可以工作的软件胜过面面俱到的文档，即可以工作的软件在过程各类产品的重要性方面拥有最高的优先级。强调创建和维护形式化的文档模型，而非文字化的文档，但就模型与软件两者的优先
20、级未给出论述。AP&RUP融合后的各类产品之间优先级的结论：软件开发的主要和中心活动就是创建可以工作的软件；直到迫切需要且意义重大时，才进行文档编制；编制的内部文档应尽量短小并且主题突出，满足这种要求的最好的文档形式是模型。（2）产品的功能规模和质量要求：尽量简单化。10.AP四大要素的关系：第1条价值观和第1、9条原则中即开宗明义的指出，过程最优先要做的是尽早的、持续的交付有价值的软件产品，在这一交付过程中，个体与交互胜过过程与工具：这四大要素中，前面三种要素的中心目标是服务于第四大要素，即交付可以工作的软件产品；就前面三种要素的重要性而言，个体具有最高的优先级地位。11.AP特点：针对商业
21、环境下通常具有有限资源和有限时间约束的小型项目提出了一些独具特色的、操作性较强的解决方案；提供的是理想开发环境下软件过程的一种完整且完美的模式，但对商业环境具有有限资源和有限时间约束的项目未能给出具体完整的配置方案。缺点：作为软件过程模式AP远不及RUP全面完整。相对RUP，AP在人员、方法、产品等方面的论述远不及RUP全面详细。AP可作为对RUP的一种补充和完善。第4章 微软过程1.什么是MP：从微软解决方案框架（MSF）中抽取出项目开发准则中的过程模型和组织模型，构成了一套软件过程模式。内容涵盖软件过程中的过程、人员及组织、方法、产品等不同方面。*2.MP术语：项目前景是对项目要解决什么问
22、题的开放性描述，它代表项目的远景目标。项目范围描述的则是在项目的限制条件内，需要完成哪些具体的目标，这主要是指所有特定的近期目标而言。功能说明书阐释了软件每一个特性的功能和执行方式，以及所有特性的组合关系和整体架构，包括单页和详细两种形式。程序经理的职责是在规定的项目资源、期限等限制条件下，确保产品能够如期发布。程序经理不同于传统的项目经理，微软的团队组织结构中，六个组队角色的地位是相互平行、相辅相成，程序经理只是项目开发过程的组织者、管理者和决策者，不是项目的领导者。*3.MP的过程原则：制定计划时兼顾未来的不确定因素（这一原则与AP第4条价值观“响应变化胜过遵循计划”异曲同工）；通过有效的
23、风险管理减少不确定因素的影响（对照而言，RUP提出的风险管理方法为在每次迭代中都要解决最突出的风险问题，两者互补）；经常生成过渡版本并进行快速测试来提高产品的稳定性及可预测性（每日生成制度：在最大程度上保证整个产品开发过程可管理、可预期，并能增强产品的稳定性，类似AP的持续集成）；快速循环、递进的开发过程（和敏捷过程所强调的不断重复产品的生命周期、以递进的方式推出版本的要求相似）；从产品特性和成本控制出发创造性地工作；创建确定的进度表（在具体制定项目进度表方面，借鉴AP的策略，即制定一种细致度逐渐降低的进度计划以保持足够的灵活性）；使用小型项目组并发完成工作，并设置多个同步点；将大型项目分解成
24、多个可管理的单元，以便更快地发布产品；用产品的前景目标和概要说明指导项目开发工作先基线化，后冻结（冻结思想与AP不同，AP倡导即使到了开发的后期，也欢迎改变需求）；避免产品走形（对照而言，RUP中避免产品走形的方法是用例驱动）；使用原型验证概念，进行开发前的测试；零缺陷观念（零缺陷并不意味着产品中没有Bug，首先按零缺陷这一高标准进行要求，具体实施时，项目组在产品的每一个阶段、在发布产品的每一个版本之前，都对已发现的产品Bug进行了有效的管理和控制，改正了影响产品使用的Bug，对不影响产品使用、且因资源有限无法及时修改的Bug进行跟踪和记录，确保使产品中所有已发现Bug都在项目组的控制范围之内
25、，都可以在适当的时机得到修正）。非责难式的里程碑评审会（MP的里程碑与RUP的里程碑的思想几乎是一致的）。*4.组队原则：小型的、多元化的项目组（AP鼓励的也是一种小型化的项目组）。角色依赖和职责共享（与AP第11条原则中提出的“最好的构架、需求、设计出自于自组织的团队”思想基本吻合）。专深的技术水平和业务技能。以产品发布为中心。明确的目标。客户的主动参与（与AP中强调客户这一角色重要性的目的是一致的；微软设置产品管理角色方法相对AP的与客户天天工作在一起的方法更具可实现性）。分享产品的前景。所有人都参与设计（与AP第11条原则“最好的构架、需求和设计出自于自组织的用户”是一致的）。认真从过去
26、的项目中吸取经验。共同管理、共同决策。项目组成员在同一地点办公。大型项目组也像小型项目组一样运转。5.MP的生命周期：每个生命周期循环分为五个阶段：构想阶段、计划阶段、开发阶段、稳定阶段和发布阶段。相对RUP，MP可视为RUP的一个精简配置版本。整个过程由若干生命周期持续递进循环，每个循环由若干阶段组成，且各阶段之间扩充为具有缓冲时间，各阶段的对应关系为：先启阶段完成构想，精化阶段完成计划，构建阶段完成开发和稳定，产品化阶段完成发布。每个阶段精简为一次迭代，每次迭代经历若干个工作流程，具体为：先启阶段主要经历业务建模、需求、项目管理；精化阶段主要经历业务建模、需求、分析设计、项目管理；构建阶段
27、主要经历需求、分析设计、实现、测试；产品化阶段：主要经历部署、配置变更管理和项目管理。相对AP，MP是前者的一个扩充版本，扩充了其每个生命周期内的各阶段的具体运作流程。6.MP人员：人员分工：职责与任务分配类似按照RUP中的“角色”概念进行。人员组织管理：矩阵结构。横轴按不同的专业技能划分的角色，纵轴是由来自不同角色组中的各个角色组成的项目组。六种角色：产品管理角色、程序管理角色、开发角色、测试角色、用户体验角色、发布管理角色。7.MP最具特色角色程序管理和产品管理。职责设置：将传统项目经理的职责一分为二。对外的用户需求管理职能交与产品经理完成，项目组内部的综合管理职能交与程序经理完成。产品经理的职责：管理用户需求；程序经理的职责：系统设计和项目组内部管理，包括编写并管理产品设计文档、组织项目组成员就开发相关问题进行交流和沟通、协调项目组日常事务。设置意义：以技术为基线进行管理职责划分有利于实现专家式管理；保证两者的独立性和相互制约性，有利于商业需求和技术细节更好的结合。8. MP角色间的关系：对等环行项目结构。相互地位关系是对等，关键协作方式为交流与沟通。9.MP角色合并：原则：项目组内的开发人员不能兼任其它角色，不要试图合并两个有明显利益冲突或制约关系的职能角色。一个最小项目组可以只有三个成员：产品经理、程序经理和开发工程师。其中产品经理兼任测试和用户体验角色，程序经
