一、企业项目管理的概念

1. 什么是项目管理

这里把“项目管理”关键词拆解为2个词：项目、管理。

项目：为完成某一独特产品或服务所做的一次性努力。

管理：同别人一起，或通过别人使活动完成得更有效的过程。

项目管理：把各种系统、方法、人员结合在一起，在规定的时间、预算和质量目标范围内完成项目的各项工作。

2. 项目管理都管理什么

项目范围管理，项目时间管理，项目成本管理，项目质量管理，其他相关的包括：人力资源管理，沟通管理，风险管理，采购管理，整体管理

 

3. 项目管理的演变

1）针对单个项目的管理

将“一次性任务”作为项目管理的对象，关注于“单个项目”的成功。

当在同一组织背景下开展多个项目时，由于每个项目都只追求自身目标的实现，结果各个项目之间互相牵制，导致“单个项目”的目标无法实现；或者实现了部分“单个项目”的目标，但整个组织的长期性战略目标却未能实现。

2）早期的企业项目管理

早期的企业项目管理是针对项目型公司而提出的，指的是“管理整个企业范围内的项目”（managing projects across an enterprise），即着眼于企业总体战略目标的实现，而对企业中的诸多项目实施管理。

随着经济全球化的深入，各个企业对有限资源的争夺越来越激烈，这要求企业必须能够对有限的资源在时间、成本、质量三个方面进行全方面、全过程的控制，同时以企业战略目标为导向来指导企业的经营管理活动，而项目管理方法正好符合了这种要求。

3）企业传统的作业业务日趋项目化

买方市场出现，顾客需求日趋个性化、多样化，这使得产品生产逐渐具备了项目的独立性特征。
高新技术不断涌现，产品在市场上的生命周期越来越短，一种产品从创意到退市的全过程具备了项目的一次性特征。。
因此，除项目型企业外，传统的生产作业型企业也开始广泛地应用项目管理方法来管理自身的经营活动。这使得企业的管理活动由 “面向过程” ，转变为 “面向对象” 。

4. 企业项目管理

所谓企业项目管理，就是站在企业高层管理者角度对企业中各种各样的任务进行项目管理，其主导思想是将企业的运作当作或者参照项目来进行管理（management by project），这是一种以项目为中心的长期性组织管理方式，其核心是基于项目管理的组织管理体系。

5. 企业项目要求

能干的员工，一个企业的成败，人才还是很重要的。其中的角色可包括：执行董事、IT经理、产品经理、项目经理、团队成员等等。

标准的流程，没有一个合理的标准制约，会使一个企业杂乱无章，无规则可循。

扁平的组织，是指在组织的决策层和操作层之间的中间管理层级越少越好，以便组织尽最大可能将决策权延至最远的底层，从而提高企业的效率。

强大的技术，没有强大的项目管理工具做为支持，项目管理将会非常混乱。参看以下的图：

二、企业项目管理成功要素

1. 确定远景

1）为什么需要确定远景

这个根据项目中的各个角色的分配而不同。

执行董事是为了实现企业战略目标；项目经理是为了更有效的项目管理；IT人员是为了构建安全稳定的系统；资源经理室为了更合理地利用资源，这都需要整个团队良好的协作。

而企业项目管理的成功需要全体成员的共同努力与密切配合。远景为企业员工确立了共同的目标，指明了努力的方向。

2）如何确定远景

确定企业的商业目标

确定项目管理系统在功能与性能方面的需求

充分认识到实施企业项目管理对企业员工、业务流程以及组织结构的影响

明确企业在项目管理成熟度方面的现状与目标

2. 制定计划

1）如何制定计划

列出企业面临的主要挑战

找出产生挑战的原因

明确挑战对企业产生的影响，包括：那些方面会受影响？会受到怎样的影响？

仔细了解决策层的需求

让决策层了解企业项目管理对企业产生的积极影响

规划出决策层所期望的远景

制定衡量成功的指标

量化企业项目管理对企业产生的各种影响

定义企业项目管理成功的标准

明确投资收益率 (ROI) 的变化

明确需要具备的项目管理能力

明确需要具备的技术实施能力，系统管理、数据库管理、工程服务管理、网络管理等等；

制定实施计划，确定范围与目标、确定时间表、风险识别、变更控制等等；

循序渐进，分布实施，方案论证、部门试点、跨部门实施、企业整体实施等等；

三、企业项目管理最佳实践

1. 保持一致性

统一的业务流程、统一的术语、统一的项目管理方法、统一的项目管理系统、统一的数据存储

2. 尽早取得决策层的认可与支持

3. 循序渐进，分布实施

4. 灵活处理变化

总结：企业项目管理是一门很重要的课程，对于企业项目的计划与实施至关重要。

项目管理理论与实践——软件需求分析

本章主要是对于软件需求分析相关的介绍。

一、需求分析的目的

1. 马斯洛的需求层次理论

具体可以参考：（http://baike.baidu.com/view/295140.htm）

2. 需求分析的目的

1）与相关干系人在工作内容方面达成并保持一致

2）使设计、开发、测试人员能够更清楚地了解需求

3）定义系统边界，形成需求基线

4）为估算系统的规模、工作量、成本和进度提供基础

5）为开发计划的形成提供范围（SOW）基础

二、需求工程概述

1. 什么是需求工程？用一张图可以形象的表示

需求也属于一门工程学，需求工程包括需求开发、需求管理两个方面，其中需求开发包括需求开发准备、需求获取、需求分析、需求验证。

2. 需求分析的流程图

三、需求获取

1. 需求获取的基本原则

1）深入浅出

对企业的需求调研的要尽可能的全面、细致调研的需求是个全集，系统真正实现的是个子集。

调研的细致并不等于在分析时都面面俱到地将调研的内容纳入到新系统中, 而有可能实现的很少,但其中在向细处扩充时将会很容易。

2）以流程为主线

应该用流程将所有的内容串起来，如单据、信息、组织结构、处理规则等。

流程的描述既要有宏观，又要有微观。

3）鱼刺图

石川图，鱼骨图， ishikawa图

2. 六边形法则

1）组织结构：企业为进行相应的业务流程所做的人员的组织安排。

2）业务流程：企业开展业务所必须的各个环节及在每个环节中的具体做法。

3）业务数据：企业内部经营信息的存储和流动形式。

4）业务地点分布：反映企业在什么地方开展业务以及业务流程中的各个环节之间的地点关系。

5）业务应用：企业以什么样的应用软件处理业务流程中的各个环节。

6）技术基础设施：企业在信息技术基础设施上的状况。

五、需求分析

1. 绘制关联图

1）用于定义系统与系统外部实体间的界限和接口的简单模型。

2）明确了通过接口的信息流和物流。

2. 创建开发原型

1）使得许多概念和可能发生的事更为直观明了。

2）用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。

3. 确定需求优先级

1）应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。

2）以优先级为基础确定产品版本将包括哪些特性或哪类需求。

3）帕雷托图定理（Pareto，2,8定理）

4. 为需求建立模型

1）是软件需求规格说明极好的补充说明。

2）它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。

3）这样的模型包括用例图、流程图、实体关系图、状态图、时序图、类图、对象类及交互调用图。例如：

并且书写用例情况

用例名称：网站新闻发布 用例标识号：102 角色：后台系统管理员 用例说明：后台系统管理员用来填写和修改物流网站首页的新闻，新闻最终显示在物流网站的首页上。 前置条件：后台系统管理员已经登录物流网站后台管理系统 基本事件流： 1． 选择发布新闻 2． 填写新闻标题，内容以及上传图片 3． 修改标题、内容、图片，也可以完全删除，重填新闻信息 4． 编辑完成，选择提交 5． 用例终止 其他事件流：在提交之前，随时可以返回，任何修改内容都不会影响网站首页的新闻 异常事件流： 1． 提示图片大小超过范围错误信息，重新上传， 2． 返回到后台管理系统主页面 后置条件：网站首页的新闻信息被更新 注释：无

5. 编写数据字典

1）创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。

2）在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。

6. 应用质量功能调配要

1）将产品特性、属性与对客户的重要性联系起来。

2）明确那些是客户最为关注的特性。

3）将需求分为三类：

–期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意

–普通需求

–兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备

六、编写需求规则说明书

1. 采用软件需求规格说明模版

1）为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。

2）其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。

2. 指明需求的来源

1）为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要都能追溯每项需求的来源；

2）可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。

3. 为每项需求注上标号

1）可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。

2）为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。

3）这种惯例应当很健全，允许增加、删除和修改。

4）作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。

5）需求标识方法有序列号;层次化编码;使用"待确定"（to be determined, TBD）符号等。

4. 记录业务规范

1）是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。

2）将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档。

七、需求验证

1. 审查需求文档

1）在需求开发期间进行非正式评审。

2）对需求文档进行正式审查是保证软件质量的很有效的方法。

3）组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。

2. 依据需求编写测试用例

1）根据用户需求所要求的产品特性写出黑盒功能测试用例。

2）客户通过使用测试用例以确认是否达到了期望的要求。

3）从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。

4）要使用测试用例来验证需求模型的正确性，如对话框图和原型等。

3. 确定合格的标准

1）确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。

2）将合格的测试建立在使用情景描述或使用实例的基础之上。

4. 需求确认签字

1）在主要的业务清楚以后即可以进行需求确认

2）目的是确定需求基线

3）不要期望所有的需求在签字后不变

八、需求管理

1. 需求基线

1）软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线；

2）建立需求基准版本和需求控制版本文档确定一个需求基准，这是一致性需求在特定时刻的快照；

3）之后的需求变更就遵循变更控制过程；

4）每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

2. 需求变更控制

1）确定需求变更控制过程，确定一个选择、分析和决策需求变更的过程。

2）需求变更控制流程

3. 建立变更控制委员会

1）组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本；

2）变更控制委员会成员可以是甲方与乙方的人员共同组成；

3）定期进行需求变更评审会议；

4）每次评审要有评审报告。

4. 需求变更影响评估

1）进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。

2）明确与变更相关的任务并评估完成这些任务需要的工作量。

5. 需求变更时，修改需求跟踪能力矩阵

1）跟踪所有受需求变更影响的工作产品当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。

6. 维护需求变更的历史记录

1）记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。

2）在需求基线的基础上记录变更历史记录；

3）针对每一个需求形成一个单独记录；

通过对于软件需求分析的学习，知道需求分析要承担着很多风险，因此做好计划以及风险控制是非常重要的。