项目管理标准——RUP管理的实现-研发项目管理

>>项目管理标准——RUP管理的实现-研发项目管理

项目管理标准——RUP管理的实现-研发项目管理

引言:当今社会市场竞争激烈,软件开发企业想要占据前列需要在研发管理上下功夫,“向管理要效益”已经成为软件开发企业的共识,研发项目管理在软件企业中的普及也是大势所趋。国内做软件项目管理工具的开发商翼发云近几年发展十分迅速,越来越多的软件开发企业认识到研发项目管理的重要性,能切实有效降低成本,规范软件开发流程,提高软件产品质量。国内研发项目管理系统、敏捷开发管理工具的领导品牌翼发云敏捷项目管理系统采用可视化业务流程技术,支持瀑布模型等传统软件研发项目管理,同时也支持scrum等敏捷开发流程,是理想的敏捷开发管理工具,涵盖软件项目管理工作的整个生命周期。为提高国内软件开发企业的项目管理水平,分享一篇企业管理相关的知识文章。

作者:李杰    本文选自:UMLCHINA  2002年03月28日

第一部分:项目阶段

第二部分:核心工作流程

第三部分:角色划分

第四部分:目前实施项目规范的考虑

总结

软件开发的产品质量水平,是一个由来已久的话题。而提高软件企业的产品质量水平,必须改进软件产品的开发过程。但是这里没有什么百试百灵的灵丹妙药,我们必须根据本企业的实际情况,参考国内外先进企业的经验,总结出一种适合本企业的软件开发模式。

此规范是基于CMM模型规范,以RUP软件工程过程为蓝本,由我本人根据项目实际情况而选择修改,从而使之适应当前应用级系统设计开发的需要。

本文主要以RUP的软件工程框架为主,省略复杂概念部分。着眼点放在控制软件产品开发流程上,由于人员配置与软件分工现行状况的限制,对其中的部分细节进行了合并可省略,从而适应目前国内软件开发所要求。

Rational Unified Process(简称RUP)是一套软件工程过程(在下面介绍)。

在RUP过程中,我们可以看到它非常强调一点:循环。

现在我们做的每一个项目都存在不断变化的问题。用户需求变化、系统设计变化(可能是需求变化也可能是存在了技术问题)、编码变化(由测试与复审等环节引发的)等问题困扰着项目进行。解决这些问题的方法就是不断的循环。

这个规范是我根据自己的观点整理编写而成的,有不足之处请指教。

RUP简介

Rational Unified Process(简称RUP)是一套软件工程过程,主要由Ivar Jacobson的 The Objectory Approch 和 The Rational Approch 发展而来。同时,它又是文档化的软件工程产品,所有RUP 的实施细节及方法导引均以Web文档的方式集成在一张光盘上,由Rational公司开发、维护并销售,当前版本是RUP2000。RUP又是一套软件工程方法的框架,各个组织可根据自身的实际情况,以及项目规模对RUP进行裁剪和修改,以制定出合乎需要的软件工程过程。

RUP 吸收了多种开发模型的优点,具有很好的可操作性和实用性、从它一推出市场,凭借Booch、Ivar Jacobson、以及Rumbaugh 在业界的领导地位、以及与统一建模语言(Unified Model Language , 以下简称UML)的良好集成、多种CASE工具的支持、不断的升级与维护,迅速得到业界广泛的认同,越来越多的组织以它作为软件开发模型框架。

在RUP中,软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。

项目管理规范-RUP管理实施

如上图所示,时间维从组织管理的角度描述整个软件开发生命周期,是RUP的动态组成部分。它可进一步描述为周期(Cycle)、阶段(phase)、迭代(Iteration)。

核心工作流从技术角度描述RUP的静态组成部分,它可进一步描述为行为(activities)、工作流(workflow)、产品(artifact)、工人(worker)。

图中的阴影部分描述了不同的工作流,在不同的时间段内工作量的不同。值得注意的是,几乎所有的工作流,在所有的时间段内均有工作量,只是大小不同而已。这与Waterfall process 有明显的不同。

RUP采用Use Case的概念,把要开发的系统根据各功能使用的情况划分多个Use Case,并采用迭代的思想把系统的风险分布在四个阶段,风险越大的迭代越要放在靠前的阶段做,使软件产品的风险不断降低;而不是像传统软件工程那样越往开发的后期问题越多。所以RUP的思想一推出就受到软件企业的欢迎。按照RUP的开发模式一般可以达到CMM2、3级的水平。当然,理解和掌握RUP需要一个相对较长的过程。

1。项目阶段

从管理的观点来说,软件生命周期随着时间分为四个依次进行的阶段,每个阶段的结束都有一个主要里程碑;实质上,每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结束时进行评估,以确定是否实现了此阶段的目标。良好的评估可使项目顺利进入下一阶段。

1.1。规划阶段

在进度和工作量方面,所有阶段都各不相同。尽管不同的项目有很大的不同,但一个中等规模项目的典型初始开发周期应该预先考虑到工作量和进度间的分配:

起点 细化 结构 商业化
工作量 ~ 5% 20% 65% 10%
进步速度 10% 30% 50% 10%

可表示为下图

项目管理规范-RUP管理实施

对于演进周期,先启和精化阶段就小得多了。能够自动完成某些构建工作的工具将会缓解此现象,并使得构建阶段比先启阶段和精化阶段的总和还要小很多。

通过这四个阶段就是一个开发周期;每次经过这四个阶段就会产生一代软件。除非项目“死亡”,否则通过重复同样的先启阶段、精化阶段、构建阶段和产品化阶段的顺序,产品将演进为下一代产品,但每一次的侧重点都将放在不同的阶段上。这些随后的周期称为演进周期。 随着产品经历了几个周期,新一代产品随之产生。

1.2。开始阶段

1.2.1。目标

先启阶段的基本目标是实现项目的生命周期目标中所有相关因素(如客户等)之间的并行。 先启阶段主要对新的开发工作具有重大意义,新工作中的重要业务风险和需求风险问题必须在项目继续进行之前得到解决。对于重点是扩展现有系统的项目来说,先启阶段较短,但重点仍然是确保项目值得进行而且可以进行。

先启阶段的主要目标包括:

· 建立项目的软件规模和边界条件,包括运作前景、验收标准以及希望软件中包括和不包括的内容。

· 识别系统的关键用例(也就是将造成重要设计折衷操作的主要部分)。

· 评估整个项目的总体成本和进度(以及对即将进行的精化阶段进行更详细的评估)

· 评估潜在风险(不可预测性的来源)

· 准备项目的支持环境。

1.2.2。核心活动

· 明确地说明项目规模。这涉及了解环境以及最重要的需求和约束,以便于可以得出最终产品的验收标准。

· 计划和准备商业理由。评估风险管理、人员配备、项目计划和成本/进度/收益率折衷的备选方案。

· 综合考虑备选构架,评估设计和自制/外购/复用方面的折衷,从而估算出成本、进度和资源。此处的目标在于通过对一些概念的证实来证明可行性。该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。先启阶段的原型设计工作应该限制在确信解决方案可行就可以了。该解决方案在精化和构建阶段实现。

· 准备项目的环境,评估项目和组织,选择工具,决定流程中要改进的部分。

1.2.3。里程碑:生命周期目标

生命周期目标里程碑评估项目的基本可行性。

先启阶段末是第一个重要的项目里程碑,即生命周期目标里程碑。此时,检查项目的生命周期目标,并决定继续进行项目还是取消项目。

1.2.3.1评价标准

· 规模定义和成本/进度估算中,所有相关因素(如客户等)可并行

· 对是否已经获得正确的需求集达成一致意见,并且对这些需求的理解是共同的。

· 对成本/进度估算、优先级、风险和开发流程是否合适达成一致意见。

· 已经确定所有风险并且有针对每个风险的减轻风险策略。

如果项目无法达到该里程碑,则它可能中途失败或需要进行相当多的重新考虑。

文档和模型由1.2.3.2

核心文档和模型(按重要性排序) 里程碑
展望 记录了核心项目的要求、关键职能和主要制约因素。
企业的原因 它已被证实与批准。
风险清单 初步的项目风险已经确定。
软件开发计划 已经确定了初始阶段及其持续时间和目标。软件开发计划中的资源估计(特别是时间、人员和开发环境成本)必须与业务原因相一致。资源估计可以覆盖整个项目,直到交付所需的资源,并且只包含细化阶段所需的资源。在这一点上,资源估计整个项目需要的应该是粗糙和# 8220;与# 8221粗略估计;估计是在每一个阶段,在每一次迭代更新,它变得更精确,在每一次迭代。根据项目的需要,一个或更多的偶然与# 8220在一定条件下可以完成;计划和# 8221;工件。此外,伴随与# 8220;指导和# 8221;工件通常至少完成了# 8220;汇票和# 8221;
迭代计划 迭代计划的第一次迭代已经完成并进行了评审。
软件验收计划 完成评审并确定基线;随着其他需求的发现,它将在以后的迭代中得到改进。
具体项目模板 已使用文档模板生成文档工件。
用例建模指南 基线被确定。
工具 支持项目的所有工具都被选中。已经安装了第一阶段的必要工具。
词汇表 已经定义了重要的术语;词汇的重新检查完成了。
用例模型(主角、用例) 已经确定了重要的主角和用例,并对最关键的用例简要地描述了事件流。
域模型(也称业务对象模型) 系统中使用的核心概念已被记录和审查。在核心概念之间的特定关系的情况下,它被用来作为词汇的补充。
原型 一个或多个概念原型的证据来支持前景和业务原因,并解决非常具体的风险。

1.3。细化阶段

1.3.1。目标

精化阶段的目标是建立系统构架的基线,以便为构建阶段的主要设计和实施工作提供一个稳定的基础。构架是基于对大多数重要需求(对系统构架有很大影响的需求)的考虑和风险评估发展而来的。构架的稳定性是通过一个或多个构架原型进行评估的。

精化阶段的主要目标包括:

  • 确保框架、需求和计划足够稳定,足以减少风险,从而可以预见完成开发所需的成本和进度。对于大多数项目来说,这一里程碑也相当于从简单、快速、低风险的操作向高成本、高风险的操作转变,在组织结构方面面临诸多不利因素。
  • 处理所有在建筑中重要的项目风险
  • 建立基线的框架,由框架中的重要场景处理,通常显示项目的最大技术风险。
  • 产品组件的演化原型质量,也可能产生一个或多个可以放弃探索性的原型,以减少特定的风险,如设计/组件重用的可行性或产品需求对客户和终端用户的妥协。
  • 已证明已建立基线的框架将在合理的时间和合理的成本下支持系统需求。
  • 建立支持环境。

为了实现这个主要目标,建立项目的支持环境也同等重要。这包括创建开发案例、创建模板和指南、安装工具。

1.3.2。核心活动

· 快速确定构架、确认构架并为构架建立基线。

· 根据此阶段获得的新信息改进前景,对推动构架和计划决策的最关键用例建立可靠的了解。

· 为构建阶段创建详细的迭代计划并为其建立基线。

· 改进开发案例,定位开发环境,包括流程和支持构建团队所需的工具和自动化支持。

· 改进构架并选择构件。 评估潜在构件,充分了解自制/外购/复用决策,以便有把握地确定构建阶段的成本和进度。集成了所选构架构件,并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架、考虑替代设计或重新考虑需求。

1.3.3。里程碑:生命周期架构

生命周期构架里程碑为系统构架建立管理基线,并使项目团队能够在构建阶段调整规模。

精化阶段末是第二个重要的项目里程碑,即生命周期构架里程碑。此时,您检查详细的系统目标和规模、选择的构架以及主要风险的解决方案。

1.3.3.1评价标准

· 产品前景和需求是稳定的。

· 构架是稳定的。

· 可执行原型表明已经找到了主要的风险元素,并且得到妥善解决。

· 构建阶段的迭代计划足够详细和真实,可以保证工作继续进行。

· 构建阶段的迭代计划由可靠的估算支持。

· 所有客户方人员一致认为,如果在当前构架环境中执行当前计划来开发完整的系统,则当前的前景可以实现。

· 实际的资源耗费与计划的耗费相比是可以接受的。

如果项目无法达到该里程碑,则它可能中途失败或需要进行相当多的重新考虑。

文档和模型所提供的1.3.3.2

核心文档和模型(按重要性排序) 里程碑
原型 已经创建了一个或多个可执行体系结构原型来探索关键功能和重要的架构场景。
风险清单 它已被更新和回顾。新的风险可能是结构性的,主要与处理非功能性需求有关。
具体项目模板 已使用文档模板生成文档工件。
工具 已经安装了用于支持精化阶段工作的工具。
软件架构文档 完成并确定基线,如果系统是分布式的或并行处理的问题必须包括对重要情况的详细描述、(用例视图)的结构、徽标的关键机制和设计元素(逻辑视图)和(部署模型)定义流程视图和部署视图。
设计模式(所有部件) 生产完成并确定了基线。定义了重要的架构场景的用例实现,并将所需的行为分配给适当的设计元素。已确定组件,并充分了解国产/购买/再利用决策,以确定施工阶段的成本和进度。根据主要场景对选定的体系结构组件进行集成和评估。通过这些活动获得的经验可以导致重新设计体系结构、考虑替代设计或重新考虑需求。
数据模型 生产完成并确定了基线。已确定和审查了主要的数据模型元素(如重要实体、关系和表)。
实现模型(以及所有组件,包括组件) 对原结构进行了设计,确定了主要部件,设计了样机。
展望 在这一阶段的基础上改进了新的信息,并对推动框架和规划决策的最关键的用例进行了可靠的理解。
软件开发计划 它已更新和扩展,以涵盖建设阶段和产品阶段。
指导方针,如设计指南和编程指南。 指南的使用得到了工作的支持。
迭代计划 施工阶段的迭代计划已经完成并进行了评审。
用例模型 用例模型(大约80%)已经被用来识别用例,识别所有的用例,并编译用例模型调查中的大多数用例(需求分析)。
补充说明 补充需求,包括非功能性需求,已记录和审查。
可选 里程碑
企业的原因 如果框架调查不包括改变基本项目假设的问题,则业务原因已经更新。
分析模型 它可以作为正式工作开发;常规的但非正式的维护正在作为设计模型的早期版本开发。
培训材料 用户手册和其他培训材料。根据使用情况进行初步起草。如果系统有复杂的用户界面,可能需要培训材料。

1.4。施工阶段

1.4.1。目标

构建阶段的目标是阐明剩余的需求,并基于已建立基线的构架完成系统开发。构建阶段从某种意义上来说是一个制造过程,在此过程中,重点在于管理资源和控制操作,以便优化成本、进度和质量。从这种意义上说,从先启和精化阶段到构建和产品化阶段,管理上的思维定势经历了从知识产权开发到可部署产品开发的转变。

构建阶段的主要目标包括:

· 通过优化资源和避免不必要的报废和返工,使开发成本降到最低。

· 快速达到足够好的质量

· 快速完成有用的版本(Alpha 版、Beta 版和其他测试发布版)

· 完成所有所需功能的分析、开发和测试。

· 迭代式、递增式地开发随时可以发布到用户群的完整产品。这意味着描述剩余的用例和其他需求,充实设计,完成实施,并测试软件。

· 确定软件、场地和用户是否已经为部署应用程序作好准备。

· 开发团队的工作实现某种程度的并行。 即使是较小的项目,也通常包括可以相互独立开发的构件,从而使各团队之间实现自然的并行(资源允许)。这种并行性可较大幅度地加速开发活动;但同时也增加了资源管理和工作流程同步的复杂程度。如果要实现任何重要的并行,强壮的构架至关重要。

1.4.2。核心活动

· 资源管理,控制和流程优化

· 完成构件开发并根据已定义的评估标准进行测试

· 根据前景的验收标准对产品发布版进行评估。

1.4.3。里程碑:初步运营业绩

最初操作性能里程碑确定产品是否已经可以部署到 Beta 测试环境。

在最初操作性能里程碑,产品随时可以移交给产品化团队。此时,已开发了所有功能,并完成了所有 Alpha 测试(如果有测试)。除了软件之外,用户手册也已经完成,而且有对当前发布版的说明。

1.4.3.1评价标准

构建阶段的评估标准涉及到对以下问题的回答:

· 该产品发布版是否足够稳定和成熟,可部署在用户群中?

· 是否已准备好将产品发布到用户群?

· 实际的资源耗费与计划的相比是否仍可以接受?

如果项目无法达到该里程碑,产品化可能要推迟一个发布版。

1.4.3.2提供的文档和模型

核心文档和模型(按重要性排序) 里程碑
与# 8220;系统与# 8221; 系统的可执行文件本身可以在任何时间# 8220;β和# 8221;试验。
部署计划 开发了原始版本,进行了审查,并建立了基线。
实现模型(以及所有组件,包括组件) 在精化阶段中创建的模型的扩展;在构建阶段结束时创建所有组件。
测试模型(以及所有组件) 为验证构建阶段创建的可执行版本而设计和开发的测试。
培训材料 用户手册和其他培训材料。根据使用情况进行初步起草。如果系统有复杂的用户界面,可能需要培训材料。
迭代计划 产品阶段的迭代计划已经完成并进行了评审。
设计模型(及所有组件) 新的设计元素已经更新,并且这些设计元素是在完成所有需求时确定的。
具体项目模板 已使用文档模板制作文档模板。
工具 已经安装了用于支持施工阶段工作的工具。
数据模型 它与支持连续实现所需元素的所有元素(如表、索引、对象关系映射等)进行了更新。
可选 里程碑
补充说明 新的需求(如果有的话)已经在建设阶段更新了。
用例模型(主角,用例) 新的用例(如果有的话)已经在构建阶段更新了。

1.5。产品阶段

1.5.1。目标

产品化阶段的重点是确保最终用户可以使用软件。产品化阶段可跨越几个迭代,包括测试处于发布准备中的产品和基于用户反馈进行较小的调整。在生命周期中的该点处,用户反馈应主要侧重于调整产品、配置、安装和可用性问题,所有较大的结构上的问题应该在项目生命周期的早期阶段就已得到解决。

在产品化阶段生命周期结束时,目标应该已经实现,项目应处于将结束的状态。某些情况下,当前生命周期的结束可能是同一产品另一生命周期的开始,从而导致产生产品的下一代或下一版本。对于其他项目,产品化阶段结束时可能就将文档与模型完全交付给第三方,第三方负责已交付系统的操作、维护和扩展。

根据产品的种类,产品化阶段可能非常简单,也可能非常复杂。例如,发布现有桌面产品的新发布版可能十分简单,而替换一个国家的航空交通管制系统可能就非常复杂。

产品化阶段的迭代期间所进行的活动取决于目标。例如,在进行调试时,实施和测试通常就足够了。 但是,如果要添加新功能,迭代类似于构建阶段中的迭代,需要进行分析设计。

当基线已经足够完善,可以部署到最终用户领域中时,则进入产品化阶段。通常,这要求系统的某个可用部分已经达到了可接受的质量级别并完成用户文档,从而向用户的转移可以为所有方面都带来积极的结果。

产品化阶段的主要目标是:

· 进行 Beta 测试,按用户的期望确认新系统

· Beta 测试和相对于正在替换的遗留系统的并行操作

· 转换操作数据库

· 培训用户和维护人员

· 市场营销、进行分发和向销售人员进行新产品介绍

· 与部署相关的工程,例如接入、商业包装和生产、销售介绍、现场人员培训

· 调整活动,如进行调试、性能或可用性的增强

· 根据产品的完整前景和验收标准,对部署基线进行的评估

· 实现用户的自我支持能力

· 在用户之间达成共识,即部署基线已完成

· 在用户之间达成共识,即部署基线与前景的评估标准一致

1.5.2。核心活动

· 执行部署计划

· 对最终用户支持材料定稿

· 在开发现场测试可交付产品

· 制作产品发布版

· 获得用户反馈

· 基于反馈调整产品

· 使最终用户可以使用产品

1.5.3。里程碑:产品发布

产品化阶段末是第四个重要的项目里程碑,即产品发布里程碑。此时,您确定是否达到目标,以及是否应该开始另一个开发周期。有时候,该里程碑可能与下一周期的先启阶段末重合。产品发布里程碑是项目验收复审成功完成的结果。

1.5.3.1 评估标准

产品化阶段的主要评估标准涉及到对以下问题的回答:

· 用户是否满意?

· 实际的资源耗费与计划的耗费相比是否可以接受?

在产品发布里程碑处,发布后的维护周期同时开始。这涉及开始一个新的周期,或某个其他的维护发布版。

1.5.3.2 提供的文档及模型

核心文档和模型(按重要性排序) 里程碑
产品版本 按产品要求完成。客户应该能够使用最终产品。
发行说明 完成。
安装产品和模型 完成。
培训材料 确保客户能够使用和维护自己的产品。
终端用户支持材料 确保客户能够使用和维护自己的产品。
可选 里程碑
测试模型 当客户需要进行现场测试时,可以提供测试模型。

第二部分:核心工作流

第三部分:角色划分

第四部分:目前实施项目规范的考虑

总结

软件开发的产品质量水平,是一个由来已久的话题。而提高软件企业的产品质量水平,必须改进软件产品的开发过程。但是这里没有什么百试百灵的灵丹妙药,我们必须根据本企业的实际情况,参考国内外先进企业的经验,总结出一种适合本企业的软件开发模式。

此规范是基于CMM模型规范,以RUP软件工程过程为蓝本,由我本人根据项目实际情况而选择修改,从而使之适应当前应用级系统设计开发的需要。

本文主要以RUP的软件工程框架为主,省略复杂概念部分。着眼点放在控制软件产品开发流程上,由于人员配置与软件分工现行状况的限制,对其中的部分细节进行了合并可省略,从而适应目前国内软件开发所要求。

Rational Unified Process(简称RUP)是一套软件工程过程(在下面介绍)。

在RUP过程中,我们可以看到它非常强调一点:循环。

现在我们做的每一个项目都存在不断变化的问题。用户需求变化、系统设计变化(可能是需求变化也可能是存在了技术问题)、编码变化(由测试与复审等环节引发的)等问题困扰着项目进行。解决这些问题的方法就是不断的循环。

这个规范是我根据自己的观点整理编写而成的,有不足之处请指教。

RUP简介

Rational Unified Process(简称RUP)是一套软件工程过程,主要由Ivar Jacobson的 The Objectory Approch 和 The Rational Approch 发展而来。同时,它又是文档化的软件工程产品,所有RUP 的实施细节及方法导引均以Web文档的方式集成在一张光盘上,由Rational公司开发、维护并销售,当前版本是RUP2000。RUP又是一套软件工程方法的框架,各个组织可根据自身的实际情况,以及项目规模对RUP进行裁剪和修改,以制定出合乎需要的软件工程过程。

RUP 吸收了多种开发模型的优点,具有很好的可操作性和实用性、从它一推出市场,凭借Booch、Ivar Jacobson、以及Rumbaugh 在业界的领导地位、以及与统一建模语言(Unified Model Language , 以下简称UML)的良好集成、多种CASE工具的支持、不断的升级与维护,迅速得到业界广泛的认同,越来越多的组织以它作为软件开发模型框架。

在RUP中,软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。

项目管理规范-RUP管理实施

如上图所示,时间维从组织管理的角度描述整个软件开发生命周期,是RUP的动态组成部分。它可进一步描述为周期(Cycle)、阶段(phase)、迭代(Iteration)。

核心工作流从技术角度描述RUP的静态组成部分,它可进一步描述为行为(activities)、工作流(workflow)、产品(artifact)、工人(worker)。

图中的阴影部分描述了不同的工作流,在不同的时间段内工作量的不同。值得注意的是,几乎所有的工作流,在所有的时间段内均有工作量,只是大小不同而已。这与Waterfall process 有明显的不同。

RUP采用Use Case的概念,把要开发的系统根据各功能使用的情况划分多个Use Case,并采用迭代的思想把系统的风险分布在四个阶段,风险越大的迭代越要放在靠前的阶段做,使软件产品的风险不断降低;而不是像传统软件工程那样越往开发的后期问题越多。所以RUP的思想一推出就受到软件企业的欢迎。按照RUP的开发模式一般可以达到CMM2、3级的水平。当然,理解和掌握RUP需要一个相对较长的过程。

2. 核心工作流程

软件工程中的工作流程分为两部分:核心工作流程与核心支持工作流程

核心工作流程(在项目中的流程)

  • 业务需求建模
  • 分析与设计
  • 实施
  • 测试
  • 部署

核心支持工作流程(在组织中的流程)

  • 环境
  • 项目管理
  • 配置和变更管理

2.1。业务需求建模

2.1.1. 目的

业务建模的目的在于:

  • 理解目标组织(将部署在其中的组织)的结构和机制。
  • 了解目标组织目前存在的问题并确定改进的可能性。
  • 确保客户、最终用户和开发人员在目标组织上达成一致。
  • 导出支持目标组织的系统需求。

为实现这些目标,业务建模工作流程说明了如何拟定新目标组织的前景,并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。

作为对这些模型的补充,还编写了以下文档:

  • 补充业务监管
  • 词汇表

2.1.2。商业建模工作流

项目管理规范-RUP管理实施

文档和模型由2.1.3。

  • 业务逻辑建模(用例)(Rose)
  • 业务需求规范(MS Word)
  • 专业词汇(英汉对比)
  • 风险描述(MS Word)
  • 复习指导

2.1.4。文档模板

参见项目管理规范目录下业务需求文档模板子目录

2.2。分析与设计

2.2.1。目的

分析设计的目的在于:

  • 将业务需求转换为未来系统的设计。
  • 开发健壮的系统架构。
  • 该设计适合于实现环境,以提高性能。

2.2.2。分析设计工作流程

项目管理规范-RUP管理实施

文档和模型由2.2.3。

  • 系统总体设计报告(MS Word)
  • 系统设计模型域模型(Rose)
  • 系统设计模型设计模型(Rose)
  • 数据库设计模型(Power Designer)
  • 数据字典(MS Word)
  • 系统详细设计报告(MS Word)
  • 工作量化图书(MS Word)

2.2.4。文档模板

参见项目管理规范目录下分析设计文档模板子目录

2.3。实施

2.3.1。目的

实施的目的包括:

  • 代码结构被定义为子系统实现的层次结构。
  • 类和对象以组件的方式实现,如源文件、二进制文件、可执行文件和其他文件等。
  • 开发的组件由单元测试,
  • 将每个执行者(或团队)的结果集成到一个可执行系统中。

实施工作流程的范围仅限于如何对各个类进行单元测试。系统测试和集成测试将在测试工作流程中进行说明。

测试的目的在于:

  • 验证对象之间的交互。
  • 验证软件的所有组件是否正确集成。
  • 确认所有需求都得到了适当的执行。
  • 确定缺陷并确保缺陷在软件部署之前得到解决。

2.3.2。实施过程

项目管理规范-RUP管理实施

文档和模型由2.3.3。

  • 摘要书(MS Word)的实现
  • 实现模型(Rose)
  • 系统集成书(MS Word)
  • 代码评审意见(MS Word)
  • 源代码(MS Word)
  • 用户使用手册(MS Word)
  • 错误解析手册(MS Word)
  • 组件及其描述

2.3.4。文档模板

参见项目管理规范目录下实施文档模板子目录

2.4。项目管理

2.4.1。目的

本部分的目标是,通过提供一些项目管理的环境,使这个任务更加容易完成。它虽然不是成功的秘诀,但它介绍了可以显著提高成功交付软件可能性的项目管理方法。

项目管理的目的是:

  • 提供一个管理软件密集型项目的框架。
  • 为项目规划、人员配备、执行和监测提供实际指导方针。
  • 提供管理风险的框架。

该工作流程主要侧重于迭代式开发流程的以下重要方面:

  • 风险管理
  • 在整个生命周期内计划迭代项目并针对特定的迭代
  • 监控迭代项目的进度和指标

2.4.2。项目管理工作流程

项目管理规范-RUP管理实施

2.4.3提供的文档和模板。

  • 风险管理计划(MS Excel)
  • 工作计划(Excel)
  • 风险清单(微软Excel)
  • 迭代计划(Excel Excel)
  • 问题解决计划(微软Excel)
  • 测试计划(Excel Excel)
  • 系统集成计划(MS Excel)
  • 子系统集成计划(MS Excel)
  • 工作表(excel)
  • 产品验收计划(MS Excel)
  • 评估计划(Excel Excel)
  • 项目计划评审意见(MS Word)
  • 发展摘要(MS Word)

2.4.4。文档模板

参见项目管理规范目录下项目管理文档模板子目录

2.5。部署

2.5.1。目的

部署工作流程用来描述那些为确保最终用户可以正常使用软件产品而进行的活动。

项目管理规范-RUP管理实施

部署工作流程描述了两种产品部署的模式:

  • 定制安装
  • 利用网络软件

在每个实例中,都强调要在开发场所对产品进行测试,并在产品最终发布之前进行 Beta 测试。

尽管部署活动主要集中于产品化阶段,但在较早的一些阶段中也会有一些为部署进行计划和准备的活动。

2.5.2提供的文档和模板。

  • 部署计划
  • 安装文件
  • 发行说明

『引自 umlchina。

文章从互联网整理而来,旨在传播scrum、软件项目管理、研发项目管理、敏捷开发管理工具的知识与应用,帮助软件开发企业真正了解研发项目管理的价值和意义,如果本文侵犯了您的权益或者您需要具体了解更多国内做研发项目管理系统的公司翼发云敏捷项目管理系统的相关信息,欢迎和我们联络:

【网址】www.effapp.com

2018-02-21T03:27:22+08:002018-02-21 03:27:22|Categories: scrum项目管理|