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

如何做好全生命期开发类项目管理项目涵盖的范畴比较广泛，本文在此主要依据于多年的项目管理经验，针对于全生命期的开发类项目的管理方式和方法进行论述，文中的观点都是本人自己总结的一些经验和方法，在此与大家分享，认识中肯定会有一定偏差，希望能与大家广泛交流。本文描述的项目管理期间不包含售前和商务交流阶段，是合同签署后的涵盖需求调研至系统上线运行。前期的商务阶段和后期的维护阶段具有不同于工程阶段的项目管理模式，在此暂不论述。不论何种工程类项目都是计划先行，制定项目计划是项目的第一步骤，为了更好的跟踪和管理项目，要给项目划分若干个管理区间，这个就是大家所熟知的初始阶段、精化阶段、编码阶段、测试阶段、实施阶段，这种阶段划分纯粹是为了项目的跟踪和管理服务的，划分的原则是描述这个阶段的主要工作内容。但实际上开发上的工程阶段和管理阶段是不完全一致的，工程上的阶段是和任务的属性相关联的，而且一个管理阶段可以同时进行多个工程阶段的任务，而且越到开发后期，这种现象越多。所以在此要明确管理上的阶段和工程上的阶段，在项目完成后，项目的过程数据是按照工程阶段来统计的，而不是按管理阶段。计划完成之后要确定项目管理过程中使用的管理工具和工程工具，管理工具能够方便进行项目过程管理和跟踪，管理项目过程数据，工程工具能够方便进行分析和设计上的描述，但对于管理方式方法和分析设计过程是没有任何工具可以依赖的，系统的分析和设计是需要具有丰富业务经验和技术经验的人来承担，如果某天我们形成基于特定行业的设计规范，那么意味着我们的工程水平上了一个更高的台阶，以下按照项目工作的次序进行描述项目过程的执行。1 需求调研1.1 调研目标：明确合同约定范围内客户需要实现的管理功能，调研过程中不要启发客户造成范围扩大。1.2 调研内容：l 客户需要管理的业务领域l 客户对管理系统的实现目标l 客户的组织机构及职责划分l 软件使用者(角色)及工作职能通过回答下列问题，可以帮助建模者发现角色:n 使用系统主要功能的人是谁？n 需要借助于系统完成日常工作的人是谁？n 谁来维护、管理系统，保证系统正常工作n 系统控制的硬件设备有哪些？n 系统需要与哪些其它系统交互？n 对系统产生的结果感兴趣的人或事是哪些？l 细化的业务体系n 业务定义n 业务动作n 业务流程n 业务规则l 非功能需求：稳定性、安全性、易用性、扩展性等等，不要忽略非功能性需求，很多时候对项目的设计有很大影响。1.3 调研原则业务为主，技术支撑1.4 调研准备1.4.1 了解本项目的主要目标、项目范围和重点工作，避免在需求调研过程中业务人员所提需求超出范围，抓不住重点。1.4.2 技术人员预先了解相关业务知识，包括业务的基础术语、基本概念、基本业务的操作和处理等，积累业务知识，要做什么就要先了解什么。要知道那些是自己能做到的，那些是自己不能做的。1.4.3 确定调研表格和座谈提纲。1.4.4 确定调研的基调，对于调研过程中客户可能出现的问题，确定处理方法。如需求扩散等。1.5 调研进行主要内容就是和客户聊聊他的工作，通常有以下内容：l 您的日常工作范围l 进行哪些业务处理（业务动作）l 完成这个业务，需要协调哪些岗位的人员l 日常工作中处理的数据有哪些项，这些数据向通常的默认值是什么。l 哪些数据需要与其他岗位人员交换。l 日常用的表格有哪些l 业务涉及到的编码标准l 需要软件提供哪些功能？每个功能实现到什么程度l 对功能界面的要求在调研过程中一定要明确哪些是用户真正想要的，也就是核心需求，不要在小问题或小功能上纠缠不休，合理的引导用户，表述自己的需求，对于不能明确以IT语言表述的需求，调研人员要求有临场变通能力，标准调研用语是：“就刚才您的表述，您是不是这个意思，按照你这个意思，你看我们功能或界面这样设计是否可以”；有业务积累的领域，可以采用先入为主的方法，主导用户的思路，合理的引导用户，标准调研用语“我已记下您的功能要求，我们完成过类似功能，我们是这样实现的，您看是否满足您的要求”。调研过程中态度非常重要，良好的语言表达技巧和合理的退让能给客户非常好的印象，对于不好实现的功能也能获得客户的理解，没有什么标准约定哪些工作要软件来实现，哪些工作由人来做，所以，调研中良好的职业素养和调研技巧，通常能合理的减少软件实现上的复杂度。1.6 调研方法l 主要有表格调查法、座谈调查法、查阅资料法和现场观察法4种l 记笔记，准确地记录：谁、什么时候、做什么、怎么做。挖掘出用户为什么这么做？即：目的。如果有旧系统，首先熟悉旧系统功能。寻根究底，反复与客户确认其意思，避免误解和遗漏业务。l 整理问题细化问询表：问询人：问题、业务不清问题列表（业务描述不清）、.是什么含义？.与XX是什么关系？多种选择可以列表（请用户进行选择）、有多个可能，那么现在我们使用AB.C.D，确认使用哪种？等等。1.7 调研整理需求列表与详细描述，并由提出人确认。1.8 调研报告描述内容 调研部门：部门组织架构，人员角色，权限要求。 调研人员 调研的业务内容 客户日常工作流程 客户的业务规范 业务数据 数据的约束限制（可改写/可显示/相关数据关联约束等） 报表的要求、查询的要求。 业务规则：对业务处理逻辑上的要求，不包含对数据处理的规则。 算法：对业务数据处理的规则。 外部交互：与其它部门或者其它业务的交互。 默认值1.9 其他注意问题l 用户倒是不经常提及他需要的东西，而这些东西对业务问题来说都是很基本的，细化检查一定有注意这个问题。l 客户是业务专家。l 规划需求中相对变与不变的业务范围。l 你认为的也许是不对的，系统分析员对需求分析的自以为是的情况要加以注意，对于一个行业来说，有些规则可以不是最合理，但它就是那样存在和使用，所以对于每一个非明确确定的需求，要由专业人员来审定，除非你就是专家。l 由用户来评价，由最终用户来评价你所列的需求是否达到了用户要求（用户人数1-3人，再多也没有什么益处），重复调研过程，最终通过审核完成需求说明书。2 需求分析依据需求列表和需求描述，整理以下方面：l 业务体系A. 业务是完成一项工作的相关工作环节序列的集合。B. 是客户对外提供的服务项目。C. 具有完整独立的数据流。D. 数据流向是单向的。E. 具有一个或多个工作环节。F. 客户通常有比较完整和详尽的业务模型。G. 对服务性企业业务就是其服务，对生产类企业业务就是其产品l 业务对象：关注于需求调研报告中的名词l 业务动作：关注与需求调研报告中的动词l 业务流程即工作流程l 软件功能规划，业务系统、业务子系统、业务组件(功能菜单)l 主题数据l 业务规则l 外部接口l 页面示例对以上数据分三个纬度进行组织：A. 业务维度分析：由此推导出软件功能通常有以下原则： 客户的每个工作岗位对应至少一个软件功能。B. 设计纬度分析：由此推导出类图/功能图由此形成组件图和包图。C. 数据纬度分析：由此推导出业务主题数据此阶段完成后要与客户作确认，按照需求分析的结果能否满足客户的管理要求，有变动立即调整。以上需求调研、需求分析的过程统称为需求开发。3 需求管理：进行需求的变更控制和跟踪。 横向跟踪 纵向跟踪需求编号需求描述依赖需求当前状态子系统设计组件接口元素代码文件测试用例R1C1R2,R3TestingS1CM1I1Cf1tc1R2C2R8CodingS1CM2I2Cf2tc2R3C3R7,R2DesigningS2CM3I3Cf3，cf4tc3R4C4R9CanceledS3CM4I44 架构设计组件：是软件功能的单元，它的使用是通过一个或多个接口达到的。子系统：任何一种在IT系统里组件的组合。组件协同使用：使用场景的代表，它是通过多个组件按一定顺序使用来达到的。组件互动：代表两个组件之间的交互，通过接口来执行的。组件模型：描述系统高层的结构，描述每个架构组件准确的责任，责任范围以及与其它组件的关系，作为系统部署的依据。组件设计方法：规划组件职责，确定其工作范围；定义组件规范，对外接口，确定使用方法，组件的对外接口是组件对外的合约，用来把组件内部的能力向外部提供出来，特别是对外提供如何使用组件所提供的内部数据和属性。4.1 组件模型4.1.1 组件关系图展现组件之间的关系以及依赖性，通常使用改良的UML Class Diagram来表示。4.1.2 组件协作图展现组件之间的协同工作关系，以来完成整体系统功能，通常使用改良的UML Sequence Diagram 来表示。4.2 运营模型 提供宏观的系统逻辑运行架构，用来展示整个系统是如何满足业务需求的。 用来考虑系统主要是基础架构是如何部署的以及系统组件应该如何部署。 用来确认客户对系统实施的倾向和限制因素。 用来考虑系统的非功能性需求应该如何满足。 用来估算相关系统硬件和基础建设的成本。 作为选择系统软件和硬件的基础。 描述整体系统的软硬件配置情况，描述运行模型的每个节点的软硬件配置情况。 是对网络拓扑图更细化的描述。4.3 系统关系图用来描述整体系统与其它外部系统的交互情况。4.4 系统业务架构图描述整体系统业务实现状况以及业务之间的相互关系。4.5 技术架构图4.6 网络拓扑图4.7 组件模型、运营模型与需求的关系运营模型并不仅仅涉及到满足非功能性需求；同样组件模型也并不仅仅涉及到满足功能性需求。5 精化设计5.1 原则: 尽可能容忍需求上的变化。 业务编码体系参数化 业务规则体系转化系统的运行参数定制。 组件化。 纬度的划分面向于解决具体的问题 有良好的独立性 耦合性要少 复用性要好 结构清晰，层次清楚 尽量简化处理环节 良好执行效率 数据处理与业务处理分开 确定设计方法A. 面向过程设计面向系统功能的设计思想，核心思想就是功能函数，规划出系统所要完成的功能集，按功能进行开发。需要确定公共业务功能，需要定义业务公共功能抽取规则，规范业务最小功能划分原则。面向流程设计与数据结构是紧耦合关系，如果数据表结构发生变化很难清楚哪些代码访问这个数据表，导致系统变更升级维护的困难，无法走产品化路线。B. 面向对象设计需要确定业务对象，需要对象抽取规则，规范最小粒度对象划分原则。不要以为使用java等面向对象化语言开发出的程序就是面向对象的系统，只有用面向对象化的思想进行分析和设计的系统才可能是真正的面向对象化的系统，面向对象思想是由面向流程设计思想发展而来，可以说是对面向流程基于功能分析的更高一层次的封装，对数据进行封装，使UI与代码分离开来，消除面向流程设计中的重复代码冗余，使系统的软件架构更容易变更和升级，花费的代价更少。这些是纯工程方面的规范，现在都是依靠设计人员的经验来做，没有形成规范性的设计指导标准，这是需要积累完善的地方，对于不同业务领域应该形成指导性的设计规范，这需要我们几代人不断积累总结才能形成。 模式化流程具有通用的数据结构对象与业务数据表定义的关系，强相关。对于数据的访问通过数据对象提供的方法实现，有一些业务动作具有标准的数据结构，比如审核设计数据结构时候必要有审核状态，审核人，审核时间。 组织管理结构具有通用的类平台对象、岗位对象：业务动作方法、角色、实体对象、业务流程的完成由多个岗位对象的业务动作方法完成。 相同技术架构系统具有通用的系统类。 业务规则转化为系统运营参数。5.2 设计内容此阶段主要针对需求分析阶段产生的软件功能、类图/功能图、数据字典进行细化设计，同时对系统架构进行设计，此阶段要确定采用面向对象化设计还是面向过程(功能)设计，如果是SOA架构同时还要进行Webservice规划和WebService契约设计。A. 软件功能精化设计a) 完成页面元素设计b) 完成界面操作流程设计：易用性良好体现。B. 软件类图/功能图精化设计a) 面向对象原则： 每一个抽象对象设计至少一个对象数据处理类，进行对象信息的数据库交互工作，一个对象数据处理类对应处理数据库中一个或多个表。 每一个业务对象设计至少一个对象业务处理类，进行对象的行为处理。 每一个业务界面设计一个对象UI处理类，进行业务界面的展现数据处理。 业务规则单独设计规则处理类。建模分析过程主要包括静态建模和动态建模,静态建模主要描述系统内部对象结构，包括对象本身的定义、对象的属性、操作，以及对象与其它对象之间的关系，也成为对象建模，对象图由类构成；动态建模用来描述系统与时间相关的动态行为即系统的控制逻辑，表现对象彼此间经过相互作用后，随时间改变的不同运算顺序。动态模型以“事件”（Events）和“状态”（States）为其模型的主要概念。动态模型以状态图和时序图形式呈现。按以下过程完成类建静态建模（1）了解基本的用户需求；（2）标识类(定义属性和方法)；（3）刻划类层次；（4）表示对象对象关系（对象连接）；（5）建模对象行为；（6）任务(1)到(5)递进地反复使用，直至完成建模。通过状态图、时序图完成动态建模，建立动态模型的第一步，是编写典型交互行为的脚本。虽然脚本中不可能包括每个偶然事件，但是，至少必须保证不遗漏常见的交互行为。接下来从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。b) 面向流程C. 数据字典精化设计依据需求规格说明书主题数据描述，完成应用系统的数据字典具体设计，增加非业务数据结构保证应用系统的运行监控（日志、备份等）。通过数据逻辑处理图描述数据处理逻辑