如何做好全生命期项目管理

《如何做好全生命期项目管理》由会员分享，可在线阅读，更多相关《如何做好全生命期项目管理（8页珍藏版）》请在金锄头文库上搜索。

1、如何做好全生命期开发类项目管理项目涵盖的范畴比较广泛，本文在此主要依据于多年的项目管理经验，针对于全生命 期的开发类项目的管理方式和方法进行论述，文中的观点都是本人自己总结的一些经验和 方法，在此与大家分享，认识中肯定会有一定偏差，希望能与大家广泛交流。 本文描述的项目管理期间不包含售前和商务交流阶段，是合同签署后的涵盖需求调研 至系统上线运行。前期的商务阶段和后期的维护阶段具有不同于工程阶段的项目管理模式， 在此暂不论述。 不论何种工程类项目都是计划先行，制定项目计划是项目的第一步骤，为了更好的跟 踪和管理项目，要给项目划分若干个管理区间，这个就是大家所熟知的初始阶段、精化阶 段、编码阶段、

2、测试阶段、实施阶段，这种阶段划分纯粹是为了项目的跟踪和管理服务的， 划分的原则是描述这个阶段的主要工作内容。但实际上开发上的工程阶段和管理阶段是不 完全一致的，工程上的阶段是和任务的属性相关联的，而且一个管理阶段可以同时进行多 个工程阶段的任务，而且越到开发后期，这种现象越多。所以在此要明确管理上的阶段和 工程上的阶段，在项目完成后，项目的过程数据是按照工程阶段来统计的，而不是按管理 阶段。 计划完成之后要确定项目管理过程中使用的管理工具和工程工具，管理工具能够方便 进行项目过程管理和跟踪，管理项目过程数据，工程工具能够方便进行分析和设计上的描 述，但对于管理方式方法和分析设计过程是没有任何工

3、具可以依赖的，系统的分析和设计 是需要具有丰富业务经验和技术经验的人来承担，如果某天我们形成基于特定行业的设计 规范，那么意味着我们的工程水平上了一个更高的台阶，以下按照项目工作的次序进行描 述项目过程的执行。 1需求调研 1.1调研目标： 明确合同约定范围内客户需要实现的管理功能，调研过程中不要启发客户造成范 围扩大。 1.2调研内容： 客户需要管理的业务领域 客户对管理系统的实现目标 客户的组织机构及职责划分 软件使用者(角色)及工作职能 通过回答下列问题，可以帮助建模者发现角色: 使用系统主要功能的人是谁？ 需要借助于系统完成日常工作的人是谁？ 谁来维护、管理系统，保证系统正常工作 系统

4、控制的硬件设备有哪些？ 系统需要与哪些其它系统交互？ 对系统产生的结果感兴趣的人或事是哪些？ 细化的业务体系 业务定义 业务动作 业务流程 业务规则 非功能需求：稳定性、安全性、易用性、扩展性等等，不要忽略非功能性需求，很多时候对项目的设计有很大影响。 1.3调研原则 业务为主，技术支撑 1.4调研准备 1.4.1 了解本项目的主要目标、项目范围和重点工作，避免在需求调研过程中业 务人员所提需求超出范围，抓不住重点。 1.4.2 技术人员预先了解相关业务知识，包括业务的基础术语、基本概念、基本 业务的操作和处理等，积累业务知识，要做什么就要先了解什么。要知道 那些是自己能做到的，那些是自己不能

5、做的。 1.4.3 确定调研表格和座谈提纲。 1.4.4 确定调研的基调，对于调研过程中客户可能出现的问题，确定处理方法。 如需求扩散等。 1.5调研进行 主要内容就是和客户聊聊他的工作，通常有以下内容： 您的日常工作范围 进行哪些业务处理（业务动作） 完成这个业务，需要协调哪些岗位的人员 日常工作中处理的数据有哪些项，这些数据向通常的默认值是什么。 哪些数据需要与其他岗位人员交换。 日常用的表格有哪些 业务涉及到的编码标准 需要软件提供哪些功能？每个功能实现到什么程度 对功能界面的要求 在调研过程中一定要明确哪些是用户真正想要的，也就是核心需求，不要在 小问题或小功能上纠缠不休，合理的引导用

6、户，表述自己的需求，对于不能明确 以 IT 语言表述的需求，调研人员要求有临场变通能力，标准调研用语是：“就刚 才您的表述，您是不是这个意思，按照你这个意思，你看我们功能或界面这 样设计是否可以” ；有业务积累的领域，可以采用先入为主的方法，主导用户 的思路，合理的引导用户，标准调研用语“我已记下您的功能要求，我们完成过 类似功能，我们是这样实现的，您看是否满足您的要求” 。调研过程中态度非常重 要，良好的语言表达技巧和合理的退让能给客户非常好的印象，对于不好实现的 功能也能获得客户的理解，没有什么标准约定哪些工作要软件来实现，哪些工作 由人来做，所以，调研中良好的职业素养和调研技巧，通常能合

7、理的减少软件实 现上的复杂度。 1.6调研方法 主要有表格调查法、座谈调查法、查阅资料法和现场观察法 4 种 记笔记，准确地记录：谁、什么时候、做什么、怎么做。挖掘出用户为什么 这么做？即：目的。如果有旧系统，首先熟悉旧系统功能。寻根究底，反复 与客户确认其意思，避免误解和遗漏业务。 整理问题细化问询表： 问询人：问题、业务不清问题列表（业务描述不清） 、.是什么含义？ .与 XX 是什么关系？多种选择可以列表（请用户进行选择） 、有多个 可能，那么现在我们使用 AB.C.D，确认使用哪种？等等。1.7调研整理 需求列表与详细描述，并由提出人确认。 1.8调研报告描述内容 调研部门：部门组织架

8、构，人员角色，权限要求。 调研人员 调研的业务内容 客户日常工作流程 客户的业务规范 业务数据 数据的约束限制（可改写/可显示/相关数据关联约束等） 报表的要求、查询的要求。 业务规则：对业务处理逻辑上的要求，不包含对数据处理的规则。 算法：对业务数据处理的规则。 外部交互：与其它部门或者其它业务的交互。 默认值 1.9其他注意问题 用户倒是不经常提及他需要的东西，而这些东西对业务问题来说都是很基本 的，细化检查一定有注意这个问题。 客户是业务专家。 规划需求中相对变与不变的业务范围。 你认为的也许是不对的，系统分析员对需求分析的自以为是的情况要加以注 意，对于一个行业来说，有些规则可以不是最

9、合理，但它就是那样存在和使 用，所以对于每一个非明确确定的需求，要由专业人员来审定，除非你就是 专家。 由用户来评价，由最终用户来评价你所列的需求是否达到了用户要求（用户 人数 1-3 人，再多也没有什么益处） ，重复调研过程，最终通过审核完成需求 说明书。 2需求分析 依据需求列表和需求描述，整理以下方面： 业务体系 A.业务是完成一项工作的相关工作环节序列的集合。 B.是客户对外提供的服务项目。 C.具有完整独立的数据流。 D.数据流向是单向的。 E.具有一个或多个工作环节。 F.客户通常有比较完整和详尽的业务模型。 G.对服务性企业业务就是其服务，对生产类企业业务就是其产品 业务对象：关

10、注于需求调研报告中的名词 业务动作：关注与需求调研报告中的动词 业务流程即工作流程 软件功能规划，业务系统、业务子系统、业务组件(功能菜单) 主题数据 业务规则 外部接口页面示例 对以上数据分三个纬度进行组织： A.业务维度分析：由此推导出软件功能业业务务流流程程流流程程节节点点软软件件功功能能结结合合工工作作权权 限限业业务务规规则则客客户户工工作作职职能能 结结构构/管管理理流流程程通常有以下原则： 客户的每个工作岗位对应至少一个软件功能。 B.设计纬度分析：由此推导出类图/功能图非流程需 求描述业务对象业业务务流流程程流流程程节节点点客客户户工工作作职职能能 结结构构/管管理理流流程程类

11、类图图/功功 能能图图业务数据由此形成组件图和包图。 C.数据纬度分析：由此推导出业务主题数据业务数据业务对象业务编码体系业务单据/报表主题数据此阶段完成后要与客户作确认，按照需求分析的结果能否满足客户的管理要求， 有变动立即调整。 以上需求调研、需求分析的过程统称为需求开发。 3需求管理：进行需求的变更控制和跟踪。 横向跟踪 纵向跟踪需求编号需求描述依赖需求当前状态子系统设计组件接口元素代码文件测试用例R1C1R2,R3TestingS1CM1I1Cf1tc1R2C2R8CodingS1CM2I2Cf2tc2R3C3R7,R2DesigningS2CM3I3Cf3，cf4tc3R4C4R9C

12、anceledS3CM4I44架构设计 组件：是软件功能的单元，它的使用是通过一个或多个接口达到的。 子系统：任何一种在 IT 系统里组件的组合。 组件协同使用：使用场景的代表，它是通过多个组件按一定顺序使用来达到的。 组件互动：代表两个组件之间的交互，通过接口来执行的。 组件模型：描述系统高层的结构，描述每个架构组件准确的责任，责任范围以及与其 它组件的关系，作为系统部署的依据。 组件设计方法：规划组件职责，确定其工作范围；定义组件规范，对外接口，确定使 用方法，组件的对外接口是组件对外的合约，用来把组件内部的能力向外部提供出来，特 别是对外提供如何使用组件所提供的内部数据和属性。 4.1组

13、件模型 4.1.1 组件关系图 展现组件之间的关系以及依赖性，通常使用改良的 UML Class Diagram 来 表示。 4.1.2 组件协作图 展现组件之间的协同工作关系，以来完成整体系统功能，通常使用改良的 UML Sequence Diagram 来表示。 4.2运营模型 提供宏观的系统逻辑运行架构，用来展示整个系统是如何满足业务需求的。 用来考虑系统主要是基础架构是如何部署的以及系统组件应该如何部署。 用来确认客户对系统实施的倾向和限制因素。 用来考虑系统的非功能性需求应该如何满足。 用来估算相关系统硬件和基础建设的成本。 作为选择系统软件和硬件的基础。 描述整体系统的软硬件配置情

14、况，描述运行模型的每个节点的软硬件配置情 况。 是对网络拓扑图更细化的描述。 4.3系统关系图 用来描述整体系统与其它外部系统的交互情况。 4.4系统业务架构图 描述整体系统业务实现状况以及业务之间的相互关系。 4.5技术架构图 4.6网络拓扑图 4.7组件模型、运营模型与需求的关系 运营模型并不仅仅涉及到满足非功能性需求；同样组件模型也并不仅仅涉及到 满足功能性需求。功功能能性性需需求求非非功功能能性性需需求求组组件件模模型型运运营营模模型型部部署署 单单元元5精化设计 5.1原则: 尽可能容忍需求上的变化。 业务编码体系参数化 业务规则体系转化系统的运行参数定制。 组件化。 纬度的划分面向

15、于解决具体的问题 有良好的独立性 耦合性要少 复用性要好 结构清晰，层次清楚 尽量简化处理环节 良好执行效率 数据处理与业务处理分开 确定设计方法 A.面向过程设计 面向系统功能的设计思想，核心思想就是功能函数，规划出系统所要完成的功能 集，按功能进行开发。需要确定公共业务功能，需要定义业务公共功能抽取规则，规 范业务最小功能划分原则。面向流程设计与数据结构是紧耦合关系，如果数据表结构 发生变化很难清楚哪些代码访问这个数据表，导致系统变更升级维护的困难，无法走 产品化路线。 B.面向对象设计 需要确定业务对象，需要对象抽取规则，规范最小粒度对象划分原则。不要以为 使用 java 等面向对象化语

16、言开发出的程序就是面向对象的系统，只有用面向对象化的 思想进行分析和设计的系统才可能是真正的面向对象化的系统，面向对象思想是由面 向流程设计思想发展而来，可以说是对面向流程基于功能分析的更高一层次的封装， 对数据进行封装，使 UI 与代码分离开来，消除面向流程设计中的重复代码冗余，使 系统的软件架构更容易变更和升级，花费的代价更少。 这些是纯工程方面的规范，现在都是依靠设计人员的经验来做，没有形成规范性 的设计指导标准，这是需要积累完善的地方，对于不同业务领域应该形成指导性的设 计规范，这需要我们几代人不断积累总结才能形成。 模式化流程具有通用的数据结构 对象与业务数据表定义的关系，强相关。对于数据的访问通过数据对象提供的方法实现，有一些业务动作具有标准的数据结构，比如审核设计数据结构时候必要有审 核状态，审核人，审核时间。 组织管理结构具有通用的类 平台对象、岗位对象：业务动作方法、角色