软件方法与过程(知识点总结)打印版_第1页
软件方法与过程(知识点总结)打印版_第2页
软件方法与过程(知识点总结)打印版_第3页
软件方法与过程(知识点总结)打印版_第4页
已阅读5页,还剩12页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、高级软件开发过程第1章 绪论1.计算机软件发展的三个阶段 :程序设计阶段 (软件工作:程序设计,软件质量:程序设计=数据结构 +算法,强调编程技巧);软件工程阶段 (总结软件危机的教训,软件工作:代码编写+需求分析、测试、维护等等,软件质量:程序的可读性、可理解性、可测试性和易修改性等工程化的原则);软件过程阶段(软件工作:软件开发过程+软件管理过程,更强调软件开发的效率、软件质量以及与软件开发相关的管理工作)。2.现代软件产业的总体情况 :很多软件项目最终不能交付,或者最终交付的软件项目发生延期、成本超出预算、 而且运行经常不可靠。原因: 不完整、不现实的项目需求描述、对需求变更束手无策、脆

2、弱的框架、采用不成熟的技术、测试的不充分性、拙劣的进度计划和评估、缺乏资源、不具备项目管理的方法、缺少管理层的支持。3. 软件 周期模型 :定义 :软件生命周期模型是软件过程中全部活动的生命周期结构框架的一种形式化描述,也成为软件生存期模型。种类: 瀑布模型、演化(原型)模型、螺旋模型、喷泉模型。总体局限性: 软件过程不仅包括组成过程的各种活动, 而且包括各种活动的相关项, 如活动的执行者、 活动执行时采用的各种方法和工具、 活动执行的结果等等, 软件生命周期模型用于指导软件开发实践时,表现出较差的可操作性。4. 软件 过程模式 :定义: 软件工程模式从成功或失败的软件开发实践中总结而成,是软

3、件过程中生命周期、人员、方法、产品四大要素相互关联的有机整体。典型的过程模式: Rational 统一过程、敏捷过程、微软过程。其他过程模式:个体 / 小组软件过程(PSP/TSP)。5.软件过程模式与软件生命周期模型的关系:软件生命周期模型包含与软件过程模式中。6.软件过程能力评估标准 和改进方案 :CMM(能力成熟度模型) :初始级、可重复级、 已定义级、 已定量管理级、 优化级。 ISO9000;6。第2章 Rational 统一过程1.什么是 RUP:Rational 统一过程( Rational Unified Process )是一种典型的软件过程模式,对软件过程模式的四大要素 生

4、命周期、人员、方法和产品均进行了详尽的论述;是一种软件过程产品Rational 公司开发并维护,与Rational 一系列其他软件开发工具集成。*2. RUP 术语 :用户 代表与所开发的系统进行交互的某个人或某个系统(所开发系统之外的另一个系统)。用例 是能够向用户提供有价值结果的系统中的一种功能。所有的用例合在一起构成用例模型 。, 特点:确定系统需求的工具,传统的系统功能说明:系统应该做什么?用例模型:增加三个词 for each user。驱动软件开发过程,RUP三大特点中第一大特点为“用例驱动”。构架 是系统在其所处环境中最高层次的概念。软件系统的构架是指通过接口交互的重要构件的组织

5、和结构,这些构件又由一些更小的构件和接口组成。RUP三大特点中第二大特点为“以构架为中心”。工作流程 是在业务中执行的活动序列,它对于业务主角个体生成一个可见值结果。迭代 是指带有已建立基线的计划和评估准则的独特活动序列,迭代生成内部或外部的发布版本。增量 是指在后续迭代结束后,两个发布版本之间存在的差异或差值。RUP三大特点中第三大特点为“迭代和增量的过程”。在软件过程组织的环境中,个人或协同工作的小组的行为和职责定义为角色 ,角色代表项目中个人承担的作用,并确定了如何完成工作。活动 是要求角色执行的工作单元。工件 是指一条信息,该信息:由过程生成、修改或使用;定义了职责范围;受到版本控制。

6、里程碑 是迭代正式结束的时间点,该时间点与发布时间点相对应。阶段 是指项目相邻两个主要里程碑之间的时间段,在此期间要实现一组既定的目标、完成工件并决定是否进入下一阶段。3.RUP二维结构生命周期:横轴 通过时间组织,体现开发过程的动态结构。术语主要包括阶段、里程碑、迭代和增量。纵轴 将内容组织为逻辑活动, 体现开发过程的静态结构, 术语主要包括工作流程、 活动、角色、工件。4.RUP静态结构 :九个核心工作流程。工作流程代表了所有角色、活动与工件的逻辑分组情况,即软件过程模式中的三个要素。九个核心工作流程组成:核心过程工作流程:前6 个,核心支持工作流程:后3 个。1 业务建模 :产生的主要工

7、件为业务模型 ;需求 :用例方法 :对需要的功能和约束进行提取、组织、文档化,理解系统所解决问题的定义和范围。产生的主要工件为用例模型,用户界面模型;分析设计:以构架设计为中心: 产品的适应性、可扩展性。产生的主要工件为一个设计模型 、一个分析模型(可选) 。实现 :产生的主要工件为 实施模型 (模型元素包括实施子系统和构件) 。测试: 产生的主要工件为 测试模型 (模型元素包括测试用例、 测试过程和测试构件) +测试结果。部署 :产生的主要工件为产品的一个版本+文档培训资料。配置和变更管理 :产生的主要工件为配置管理计划、 变更请求、 项目存储库和工作区。项目管理 :产生的主要工件为商业理由

8、、 迭代计划、 风险管理计划、 质量保证计划及相应的评估文档。环境 :产生的主要工件为工作流程指南、工具、工具指南。5.RUP动态结构 :四个阶段 。每个阶段由一次或多次迭代完成,迭代过程是受控的。1 先启阶段:目标:建立业务用例、确定项目的边界,结束里程碑:生命周期目标里程碑 。精化阶段: 目标:建立稳定的构架、编制项目计划、淘汰项目中最高风险的元素,结束里程碑: 生命周期构架里程碑。构建阶段: 目标:所有构件和应用程序功能被开发并集成为产品、所有的功能被详尽的测试,结束里程碑:最初操作性能里程碑。产品化阶段:目标:将软件产品交付给用户群体,结束里程碑:产品发布里程碑。6. RUP 与螺旋模

9、型异同点 :相同点:二维迭代特性。重复一系列组成系统生命周期的循环; 每次循环的结束是向用户交付产品的一个运行版本; 每个循环由若干次迭代组成;每次迭代需要进行风险分析处理;每次迭代结束的标志是交付一个增量。 螺旋模型: 每次迭代历经笛卡儿坐标系中四个象限的四个方面活动,RUP:每次迭代历经九个核心工作流程中的若干个。不同点: 螺旋模型未给出每次迭代过程结束交付的增量原型的具体要求;也未给出不同次迭代在历经的笛卡儿坐标系中四个象限的四个方面活动的内容与重点的不同。RUP将整个生命周期划分为四个阶段, 明确给出了每个阶段内的若干次迭代过程完成后交付的增量的具体要求,即四个阶段的主要里程碑生命周期

10、目标里程碑、生命周期构架里程碑、最初操作性能里程碑和产品发布里程碑;同时详细阐述了不同阶段中的不同迭代过程历经的九大核心工作流程中活动内容的重点和强度的不同;提供了对每次迭代过程中不同核心工作流程活动的并行化支持。RUP 的二维生命周期结构对“迭代”意义的体现比螺旋模型更深刻、具体、详尽、全面,更具可操作性。7. RUP 的优点 :相对瀑布类模型:将成本风险进一步降低为获得一次增量所需费用;进一步降低了产品不能按计划投放市场的风险;使项目开发更能适应项目需求的变化。相对螺旋类模型:用于指导需求不明确、不稳定的项目开发时具有更强的可操作性。8.RUP人员 角色 :分析员、开发人员、测试员、经理、

11、其他角色。角色的意义 :将角色与个体区分开。 某种角色 :一个或多个相互协作的个体完成, 一个个体 担任一种或多种角色。制定迭代计划:确定每个阶段、每个工作流程中需要的角色;制定人员计划: 考虑人员的技能、能力经验, 将一个或多个角色分配给一个适合的人员完成。 有效提高了项目中人力资源的利用率。缺陷: 论述不够深入, 忽略了角色的质量,未给出角色的组织管理方式、角色间的相互地位关系和交互方式。体现过程可操作性的一个重要方面,RUP未给出。9.RUP方法 :( 1)用例及用例驱动。用例 是能够向用户提供有价值结果的系统中的一种功能。所有的用例合在一起构成 用例模型 。 采用用例的两个原因:用例被

12、证明是捕获需求的一种有效方法 。达到需求捕获的第一个目标: 发现多样性的需求(传统的系统功能说明:系统应该做什么?用例模型:增加三个词for each user ),达到需求捕获的第二个目标:以适用于用户和开发人员的方式加以表示;用例驱动整个过程。( 2) 以构架为中心。构架描述: 5 个视图 : 用例模型视图、分析模型视图、设计模型视图、实施模型视图、实现模型视图。每个视图是对应模型的精华与核心部分。意义: 理解系统,组织开发,鼓励重用和进化系统。( 3)在面向对象的分析设计中采用UML 进行可视化建模。( 4)面向对象的设计与构件实现。10. RUP产品 工件 :定义 :项目期间生成的中间

13、或最终产品。工件类型:根据 RUP 的各工作流程 :划分为业务建模工件、需求工件、分析设计工件、实施工件、测试工件、部署工件、配置与变更管理工件、项目管理工件、环境工件;根据物流方向 :划分为输入工件、输出工件和辅助工件;根据存在形式 :划分为模型、模型元素、文档、源代码、可执行文件。11. RUP特点 :优点 :作为一种软件过程 :RUP具有二维迭代性,有利于降低风险、适应需求变化;RUP是可配置的过程,具有通用性;作为一种软件过程模式 :相对传统的软件生命周期模型具有较强的可操作性;作为一种软件过程产品 :具有实用性、可操作性与可实现性。缺陷 :与软件过程模式配置操作相关的因素软件过程模式

14、中生命周期、人员、方法、产品四大要素之间的相互关系和相对优先级;各生命周期元素间的相互关系和相对优先级;人员间的协作关系与协作方式、人员的质量、各种人员的相对优先级;各种方法间的相互关系及相对优先级;各种产品的相对优先级。结论: RUP是一个具有突出优点的软件过程模式;RUP 还很不完整, 在实际应用中仍需进一步吸收其它优秀的软件开发实践经验以对其进行补充和完善。第3章 敏捷过程1.什么是 AP:敏捷软件开发宣言:软件团队具有快速工作、快速响应变化的能力,制订了 4 条基本价值观和 12 条原则。敏捷过程(Agile Process)是一种典型的软件过程模式,对软件过程模式中的四大要素(生命周

15、期、人员、方法、产品)及相互关系均进行了论述。2.AP 流派 :极限编程 XP、SCRUM、动态系统开发方法 DSDM、水晶系列方法、开放式源码、适配性软件开发 ASD、适配性软件开发 ASD。3.AP 的 4 条价值观 :个体和交互胜过过程和工具。人是软件项目获得成功最为重要的因素,当然,不好的过程和工具也可以使最优秀的团队成员失去效用、合作、 沟通以及交互能力要比单纯的软件编程能力更为重要;合适的工具对于成功来说非常重要,工具的作用不可被过份地夸大,建议从使用小的工具开始。结论: 团队的构建 (包括个体、交互等 )要比项目环境 (包括过程、工具 )的构建重要得多;应该首先致力于构建团队,然

16、后再让团队基于需要来配置环境。可以工作的软件胜过面面俱到的文档。软件的重要性: 交付给用户可以工作的软件而不是文档, 否则应该称之为文档开发而不是软件开发。文档的作用:没有文档的软件是一种灾难,过多的面面俱到的文档比过少的文档更糟。准则:软件开发的主要和中心活动是创建可以工作的软件; 直到迫切需要并且意义重大时,才进行文档编制;编制的内部文档应尽量短小并且主题突出。客户合作胜过合同谈判。客户不可能做到一次性地将他们的需求完整清晰地表述在合同当中:客户需求的多样性,客户需求还可能随时发生变化。全方位的满足客户需求的有效途径:开发团队与客户紧密协作,为开发团队和客户的协同工作方式提供指导的合同是最

17、好的合同。响应变化胜过遵循计划。变化是软件开发中存在的现实:商务环境可能会变化,这会引起需求的变动;随着系统逐渐开始运做, 项目关系人(包括开发人员与客户)对系统的理解也会发生变化;技术随着时间也在变化。 响应变化的有效途径之一是制定灵活可塑的计划:制定计划的策略细致度逐渐降低的计划。*4. AP 的12 条原则 : 最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 即使到了开发的后期,也欢迎改变需求,敏捷过程利用变化来为客户创造竞争优势。 经常性交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。 在整个项目开发期间,商务人员和开发人员必须天天都工作在

18、一起。 围绕被激励起来的个体来构建项目,给他们提供所需的环境和支持,并且信任他们能够完成工作。 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面 的交谈。 工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度,责任人、 开发者和用户应该能够保持一个长期的、恒定的开发速度。 不断地关注优秀设计的技能和好的设计会增强敏捷能力。 简单 使未完成的工作最大化的艺术是根本的。? 最好的构架、需求和设计出自于自组织的团队。? 每隔一定时间, 团队会在如何才能更有效地工作方面进行反省, 然后相应地对自己的行为进行调整。* 5.XP实践 : 客户作为团队成员。 用户素材。 短交付周期。

19、 验收测试。结对编程 (由两个开发人员在同一台电脑上共同编写解决同一问题的代码,通常一个人负责编码, 而另一个负责保证代码的正确性与可读性。作用:结对编程是一种非正式的同级评审,它要求成对编程的两个开发人员在性格和技能上应该相互匹配)。测试驱动开发(强调“测试先行” , RUP对测试也是非常的重视,只是RUP 和 XP 两者对于测试在整个项目开发周期内首先出现的位置处理不同)。 集体所有权。持续集成 (提倡在一天中集成系统多次,而且随着需求的改变,要不断的进行回归测试,持续集成不是XP 专有的最佳实践,微软公司 就有每日编译 的成功实践 )。 可持续的开发速度。 开放的工作空间。? 计划游 戏

20、(计划是持续的, 循序渐进的。根据项目的进展来进行项目计划的调整, 一成不变的计划是不存在) 。? 简单 的设计。?重构 (指在不改变系统行为的前提下,重新调整、 优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。重构不是XP所特有的行为) 。? 隐喻(将隐喻看成整个系统联系在一起的全局视图、系统的未来影像,RUP的构架视图)。6.AP 的生命周期 :敏捷过程是一个一维的迭代过程。该过程中的每一个生命周期循环交付一个有价值的软件版本,各循环可持续进行。RUP 的二维双重的迭代过程:RUP 整个过程是若干次生命周期的不断循环;每个循环包括先启、精化、 构建和产品化四个阶段,每个阶段

21、由一次或多次迭代完成,每次迭代可能经历九个核心工作流程中的若干个;项目进度衡量的首要标准是各阶段的主要里程碑,包括生命周期目标里程碑、生命周期构架里程碑、最初操作性能里程碑和产品发布里程碑。AP 相对 RUP:具有对变化和不确定性的“更快速、更敏捷”的反应特性;快速的同时仍保持可持续性; 该特性能较好地适应商业竞争环境下对小型项目 提出的有限开发时间的约束。* 7.AP 的人员 :( 1)客户角色的重要性 :对客户角色重要性进行突出强调;RUP:无。( 2)个体间的相互关系和协作方式 :相互关系:个体相互的地位关系是平等的,职责是共同的。协作方式: 首要协作交互方式为面对面的交谈; 也编写文档

22、, 但文档仅作为辅助交互方式。 RUP:未给出个体间地位关系,协作方式为“形式化的文档 模型”这一书面形式而非口头交谈方式。结合 AP 和 RUP:个体间的职责进行明确分工,同时个体间为平等协作关系;个体间的交互方式首选交谈,但在必要情况下,如交谈的结果将作为设计开发的依据,则有必要编写文档或创建模型,以书面的形式记录交谈的结果。8.AP 的方法 :( 1)动态满足需求从欢迎变化、与客户合作到响应变化。步骤一:欢迎变化;步骤二:与客户合作;步骤三:响应变化。( 2)简单化 。区别: RUP:考虑产品的适应性、可扩展性与可重用性等高性能特性,提倡以构架为中心的设计方法,要求构架必须留有实现现在和

23、未来需要的所有用例空间。AP:要求在设计阶段尽可能的识别出最简单的构架。联系: 是对产品不同质量要求的不同的应对策略。简单质量要求环境:在可预见的最近几次生命周期内,对产品质量仅为无缺陷要求,而对适应性、可扩展性、可重用性等高性能指标没有要求,采用AP 的简单化设计方法,以达到快速开发的目的。复杂质量要求环境:在可预见的最近几次生命周期内,对产品质量不仅为无缺陷要求,而且对适应性、可扩展性、可重用性等高性能指标可能有若干要求。采用RUP 的以构架为中心设计方法,以避免可能发生的系统整体重构造成最终开发效率的极速下降。( 3)团队持续自我反省。9.AP 的产品 :( 1)各类产品的优先级AP:第

24、 2 条价值观, 可以工作的软件胜过面面俱到的文档,即可以工作的 软件在过程各类产品的重要性方面拥有最高的优先级。 RUP:强调创建和维护形式化的文档模型,而非文字化的文档,但就模型与软件两者的优先级未给出论述。AP&RUP 融合后的各类产品之间优先级的结论: 软件开发的主要和中心活动就是创建可以工作的软件; 直到迫切需要且意义重大时, 才进行文档编制; 编制的内部文档应尽量短小并且主题突出,满足这种要求的最好的文档形式是模型。(2)产品的功能规模和质量要求:尽量简单化。10. AP 四大要素的关系 :第 1 条价值观和第 1、9 条原则中即开宗明义的指出,过程最优先要做的是尽早的、持续的交付

25、有价值的软件产品,在这一交付过程中,个体与交互胜过过程与工具:这四大要素中,前面三种要素的中心目标是服务于第四大要素,即交付可以工作的软件产品;就前面三种要素的重要性而言,个体具有最高的优先级地位。11. AP 特点:优点:针对商业环境下通常具有有限资源和有限时间约束的小型项目提出了一些独具特色的、操作性较强的解决方案;RUP:提供的是理想开发环境下软件过程的一种完整且完美的模式,但对商业环境具有有限资源 和有限时间约束的项目未能给出具体完整的配置方案。缺点: 作为软件过程模式AP 远不及RUP 全面完整。相对RUP, AP 在人员、方法、产品等方面的论述远不及RUP全面详细。结论: AP 可

26、作为对RUP 的一种补充和完善。第4章 微软过程1.什么是 MP:从微软解决方案框架(MSF)中抽取出项目开发准则中的过程模型和组织模型,构成了一套软件过程模式。内容涵盖软件过程中的过程、人员及组织、方法、产品等不同方面。*2. MP 术语 :项目前景 是对项目要解决什么问题的开放性描述,它代表项目的远景目标。项目范围 描述的则是在项目的限制条件内,需要完成哪些具体的目标,这主要是指所有特定的近期目标而言。功能说明书 阐释了软件每一个特性的功能和执行方式, 以及所有特性的组合关系和整体架构,包括单页和详细两种形式。程序经理 的职责是在规定的项目资源、 期限等限制条件下, 确保产品能够如期发布。

27、 程序经理不同于传统的项目经理 ,微软的团队组织结构中,六个组队角色的地位是相互平行、相辅相成,程序经理只是项目开发过程的组织者、管理者和决策者,不是项目的领导者。*3. MP 的过程原则 : 制定计划时兼顾未来的不确定因素(这一原则与AP 第 4 条价值观“响应变化胜过遵循计划”异曲同工) ; 通过有效的风险管理减少不确定因素的影响在每次迭代中都要解决最突出的风险问题,两者互补)(对照而言,;RUP提出的风险管理方法为 经常生成过渡版本并进行快速测试来提高产品的稳定性及可预测性(每日生成制度:在最大程度上保证整个产品开发过程可管理、可预期,并能增强产品的稳定性,类似AP 的持续集成); 快速

28、循环、 递进的开发过程 (和敏捷过程所强调的不断重复产品的生命周期、以递进的方式推出版本的要求相似); 从产品特性和成本控制出发创造性地工作; 创建 确定的 进度表(在具体制定项目进度表方面,借鉴 AP 的策略 ,即制定一种 细致度逐渐降低的进度计划以保持足够的灵活性) ; 使用小型项目组并发完成工作,并设置多个同步点; 将大型项目分解成多个可管理的单元,以便更快地发布产品; 用产品的前景目标和概要说明指导项目开发工作先基线化, 后冻结 (冻结思想与AP 不同, AP 倡导即使到了开发的后期,也欢迎改变需求); 避免产品走形(对照而言,RUP中避免产品走形的方法是用例驱动);? 使用原型验证概

29、念,进行开发前的测试;? 零缺陷 观念(零缺陷并 不意味着产品中没有 Bug,首先按零缺陷这一高标准进行要求,具体实施时, 项目组在产品的每一个阶段、 在发布产品的每一个版本之前, 都对已发现的产品 Bug 进行了有效的管理和控制, 改正了影响产品使用的 Bug,对不影响产品使用、 且因资源有限无法及时修改的 Bug 进行跟踪和记录 ,确保使产品中所有已发现 Bug 都在项目组的控制范围之内,都可以在适当的时机得到修正) 。? 非责难式的里程碑评审会( MP 的里程碑与 RUP 的里程碑的思想几乎是一致的) 。*4. 组队原则 : 小型的、多元化的项目组(AP 鼓励的也是一种小型化的项目组)。

30、 角色依赖和职责共享(与 AP 第 11 条原则中提出的“最好的构架、需求、设计出自于自组织的团队”思想基本吻合) 。 专深的技术水平和业务技能。 以产品发布为中心。 明确的目标。 客户的主动参与(与AP 中强调客户这一角色重要性的目的是一致的;微软设置产品管理角色方法相对AP 的与客户天天工作在一起的方法更具可实现性)。 分享产品的前景。 所有人都参与设计(与AP 第 11 条原则“最好的构架、需求和设计出自于自组织的用户”是一致的) 。 认真从过去的项目中吸取经验。 共同管理、共同决策。? 项目组成员在同一地点办公。? 大型项目组也像小型项目组一样运转。5.MP 的生命周期 :每个生命周期

31、循环分为五个阶段 :构想阶段、 计划 阶段、 开发 阶段、 稳定 阶段和 发布 阶段。相对 RUP,MP 可视为 RUP的一个精简配置版本。整个过程由若干生命周期持续递进循环,每个循环由若干阶段组成,且各阶段之间扩充为具有缓冲时间 ,各阶段的对应关系为:先启阶段完成构想,精化阶段完成计划,构建阶段完成开发和稳定,产品化阶段完成发布。每个阶段精简为一次迭代,每次迭代经历若干个工作流程,具体为:先启阶段主要经历业务建模、需求、项目管理;精化阶段主要经历业务建模、需求、分析设计、项目管理;构建阶段主要经历需求、分析设计、实现、测试;产品化阶段:主要经历部署、配置变更管理和项目管理。相对AP, MP

32、是前者的 一个扩充版本,扩充了其每个生命周期内的各阶段的具体运作流程。6.MP人员:人员分工:职责与任务分配类似按照RUP中的“角色”概念进行。人员组织管理:矩阵结构。横轴 按不同的专业技能划分的角色 ,纵轴 是由来自不同角色组中的各个角色组成的项目组。六种角色 :产品管理角色、程序管理角色、开发角色、测试角色、用户体验角色、发布管理角色。7.MP 最具特色角色程序管理和产品管理。职责设置:将传统项目经理的职责一分为二。 对外的用户需求管理职能交与产品经理完成,项目组内部的综合管理职能交与程序经理完成。产品经理的职责:管理用户需求;程序经理的职责:系统设计和项目组内部管理,包括编写并管理产品设

33、计文档、组织项目组成员就开发相关问题进行交流和沟通、协调项目组日常事务。设置意义: 以技术为基线进行管理职责划分 有利于实现专家式管理; 保证两者的独立性和相互制约性,有利于商业需求和技术细节更好的结合。8. MP 角色间的关系 :对等环行项目结构。相互地位关系是对等,关键协作方式为交流与沟通。9.MP 角色合并 :原则:项目组内的开发人员不能兼任其它角色,不要试图合并两个有明显利益冲突或制约关系的职能角色。结论: 一个最小项目组可以只有三个成员:产品经理、 程序经理和开发工程师。其中产品经理兼任测试和用户体验角色,程序经理兼任发布管理角色。* 10.MP 产品部门 :“ 1+3”的结构 :

34、“1即”一个产品部门总经理, “3即”三个部门经理,分别是程序经理部经理、开发部经理和测试部经理,这三个部门经理平级,都直接向产品部门总经理报告。垂直式的专家管理模式 :每个部门经理管理几个组长, 每个组长管理三到五个具体工作人员。构成微软的“三架马车”:对项目成功起关键性支撑作用。三个部门的设置对应每个项目组中最重要的三种角色程序管理、 开发和测试; 这三类角色是每个项目组无论怎样精简也必须的。11. MP 人员特点 :RUP:给出了人员角色种类划分,但未指出各角色间地位和工作关系。AP:给出了人员间相互关系和交流协作关系,但未能给人员职责的划分准则。MP:以上两种过程优点的结合和进一步深化

35、发展。角色划分方面:产品管理和程序经理两权分立;角色相互地位和交互关系:相互平等,交流和沟通;角色分配方面:提出了针对有限人员限制条件下的角色合并原则;项目组的规模和人员配备与管理方式上 :指出提出了由专家式行政管理和小型化、多元化项目组组队方式构成的矩阵结构。MP 特色及意义 :项目组由专业职责划分清晰地各对等角色组成,各角色相互配合、同时又是相互制约; 人员的行政管理是专家式管理; 专业人才地培养发展遵循不同的业务 (职务头衔与行政级别并不能直接挂钩) 。12. MP 的方法 :( 1)构想阶段:确定项目前景和项目范围两个项目目标。项目范围 :是项目 近期的具体目标 ,即第一次生命周期内的

36、目标;项目前景 :是项目的远景目标 ,即第二次及以后若干次生命周期内的目标。动态满足需求先基线化、后冻结。在开发过程的前期欢迎变化;在开发过程的后期阶段(稳定阶段及以后),对所有配置项进行冻结,一般不再允许修改。与 AP 比较: 对需求变化的态度:欢迎变化;AP:在第 2 条原则中指出, “即使到了开发的后期也欢迎改变需求”MP :对变化在后期进行冻结的策略应该更是现实性,因为到开发的后期还要响应变化,其成本代价和风险代价均太高,明智的策略不如将这一需求变化留至下一个版本的开发中实现。( 2)计划阶段:以产品特性及其优先级指导整个项目。 提高了产品的竞争力; 降低了产品开发各阶段的风险。( 3

37、)开发阶段: 代码优化 :代码的性能包括运行效率、安全性、稳定性、可理解性、可维护性等多个方面。 高信度计算。 源代码管理。建立源代码的管理库,每日Check-in 进行持续更新和集成。 每日编译生成。 类同 AP 的持续集成(提倡在一天中集成系统多次,而且随着需求的改变,要不断的进行回归测试) 。 手工测试与自动测试结合。 内部测试与外部测试结合。13. MP 产品: 各类文档:如前景 / 范围说明书、功能说明书、项目计划、总结报告等。 源代码; 可执行文件; 相应的文档代码库。各类产品的优先级未进行专门阐述。产品的功能与性能:以产品特性及优先级指导整个项目。14. MP 特点:过程的生命周

38、期进度、人员及方法工具等项目资源、产品的功能和性能之间存在一种相互制约的 均衡三角形关系。 任何对三角形一边的改变都将导致三角形另外一边或两边的变化,因为只有这样才能保持三角形关系的均衡。发布一个符合客户需求的产品,其关键在于项目组必须在进度、资源、产品功能&性能之间的三角型寻求最佳的平衡点。项目均衡矩阵:有效的项目均衡三角形管理工具,定义了资源、进度和功能& 性能三者在需要做出折中时的优先级关系。功能 & 性能:能接受(不可改变的或是最低要求的)。进度:最佳 (必须优先考虑、作出最好选择的)。资源: 可调整(既不是最佳也不是仅能接受,必须根据情况做出相应的调整,以保持三角形的均衡)。四要素相互关系特点:相对 AP 提出的“个体交互胜过过程和工具”这一绝对的观念,MP 四要素之间的均衡关系总结: 更全面、更具普适性; 不同的项目可根据项目的具体环境需要对这四要素做出合适的优先级安排、寻求各要素之间的最佳平衡点。第5章 最佳软件过程模式*MP 与 AP、 RUP 三者之间关系 :RUP:一个大而全的过程框架,可适应于各种具有不同项目环境类型的项目开发,包括理想的项目开发环境和具有有限资源与时间约束的项目环境。AP:针对商业环境中具有有限资源和时间进度限制的小型项目提出的一种软件过程模式,对 RUP的进行了多方面的有益补充和完善。MP:另一种针对商业环境中

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论