it项目管理过程组

it项目管理过程组（精选10篇）

it项目管理过程组 篇1

IT

项目管理的过程－方法工具技术(2006-05-11 19:13:54)

工欲善其事，必先利其器。而对于一个软件开发项目，最重要的器就是方法，工具和技术。而这三要素中重要的又是方法论，方法是基础，工具和技术更多是我们根据方法论选择的实现手段，是辅助要素。知己知彼，百战百胜。一个软件项目也一样，从项目一开始就应该分析清楚项目自身的特点，因地制宜，因时制宜的采用不同的方法论和工具技术来实现。如果这个地方就出现了决策性错误，小一点是影响项目的质量和团队效率，大一点就是直接导致项目的失败。方法论－项目的灯塔。方法论是我们针对一个行业或领域提出的分析和解决问题的方法，是我们在总结和实践过程中高度抽象出来的理论，是经过实践检验和验证的具有科学依据的原理。你的成功是因为你站在前人的肩膀上，我们不应该凭空的去发明和创造，而应该根据项目特点，借鉴前人的经验和教训，选择合适的方法论去指导我们的项目运作。让我们来分析下软件项目管理中常使用到的方法论：软件过程改进－CMM/CMMI，TSP，PSP过程改进方法论是软件项目管理中最宏观的方法论，大中型的组织或机构可以实施CMM，而对于小型组织或个人可以采用小组软件过程或个体软件过程。软件过程成熟度指针对软件过程进行明确定义、管理、度量、控制的程度。它表明软件过程能力的有效性和增长的潜力，表明组织软件过程的丰富性及其应用于项目的一致性。软件过程改进方法论类似于我们在项目中采用PDCA循环的方法，其重点在于分析和实践以及持续的改进。CMM只是告诉你要做哪些事情，但采用何种方法来做并没有明确的定义，所以CMM更像是高屋建瓴的一个东西。生命周期模型－瀑布，原型，增量，迭代，螺旋选择什么样的生命周期模型是根据项目自身特点来确定的。每种生命周期模型都有自身的优缺点。对于大中型的复杂系统，前面的需求和系统分析没有搞清楚，后面的设计和实现根本无法进行，所以这种系统还是适合用瀑布模型按部就班的进行。对于需求多变，项目进度要求紧张，人员配置相对固定，这种情况更适宜于采用增量和迭代的方法进行。分析和实现方法论－结构化分析，面向对象，面向方面，特征驱动分析和实现的方法论归根到底现在常用的就是结构化分析设计和面向对象分析设计，结构化方法强调以实体关系图和数据流图分析为核心，通过数据流图的精华和变换事务映射，进行模块和单元划分，接口分析和设计。而面向对象分析和设计强调是对象和类，关注类的属性和行为和相互协作。通过用例建模，对象的结构建模，对象的行为建模，充分考虑封装，继承等面向对象关键特征进行分析和设计。技术＋过程方法论－RUP，MSF把RUP和MSF提到这么高的地位主要还是这两个方法论是既强调过程，也强调方法的。通过过程去约束方法，同时又根据方法去改进过程。RUP既体现了用例驱动，架构为核心和增量迭代的过程核心，同时又给出了如何结合UML工具进行面向对象分析和设计的基本方法，给出了用例建模，架构建模，结构建模型和行为建模的实践思路。而MSF则是微软多年解决方案的结晶，包括了团队模型，过程模型和应用模型三方面的内容，在每一方面都有很多微软的最佳实践可以借鉴和参考，如风险管理，角色责任矩阵，每日构建等。工具和技术－提升效率的关键所在。如果你不知道去哪里？给你张地图也没有用，所以方法论更多的是让我们走正确的路。但如何在正确的路上走的更快则要借助相关的工具和技术来提高我们的生产率。现在谁用汇编语言去实现MIS系统估计不能尊为天才，而只能尊为傻子了。现在相关的工具和技术很多，主要从软件开发生命周期模型的各个阶段来谈下相关的工具和技术的使用。需求阶段工具：需求阶段主要分为需求收集，需求开发和需求管理三个方面的内容。需求收集主要是如何捕获和描述清楚用户需求，可以用Excel来完成需求的收集；需求开发对于面向对象一般采用使用ROSE工具采用UML用例建模的方式进行，用例建模一般又分为用例建模，行为建模和界面建模三个层次的内容。需求管理一般采用RP工具进行需求的追踪，采用CQ等工具进行需求变更的控制。设计开发阶段工具：设计开发阶段工具主要是前台应用和架构的设计以及后台数据库的设计。数据库设计一般采用PowerDesigner或ERWin进行数据库的建模，采用Rose，Together或XDE等工具进行架构和功能模块的设计。采用相关高效的IDE环境进行编码，或者引入一些第三方的组件或应用程序开发框架提高开发效率。同时项目也可以使用Nunit,Nant,NLog等开源项目借鉴其相关的架构和模式。测试工具：对于测试管理一般可以用TestManager进行，对于性能测试一般采用LoadRunner或WinRunner，WAS等进行。而对于系统测试一定要注意边界和异常条件的测试，相关业务流程分支的分析和覆盖。开发人员可以用Nunit进行单元测试，可以采用PureCoverage检验自己的测试代码覆盖率情况。(简略)辅助工具：项目还要配置管理，变更管理，知识库，即时通讯，MindManager，CMMI过程控制和管理等相关工具进行辅助。保证流程的规范性和可控性。

it项目管理过程组 篇2

关键词:IT服务管理,变更管理,模型,流程

Change Management 是IT 服务管理框架中的重要组成部分。

IT 服务管理中所谓变更change,即可能对IT 服务造成影响的对任何事物的增加、更改或移除。其涵盖范围包括所有的IT 服务、配置项、流程、文档等。这些change 可能是IT 内部发起的,也可能来自用户的要求;既可能是主动发起的改进,也可能是incident、problem 所导致的;既可能是服务改变、应用系统开发启动这样高层次变更,也可能是具体的操作,比如办公室搬家、服务器替换。

负责控制所有change 生命周期的流程就是变更管理流程Change Management Process。Change Management 的首要目的是使有益的Change 发生,同时最小化IT 服务的中断。它通过采用标准化的方法和过程快速高效地处理change。实际上,Change Management 的过程就是用可控的方式保证change 被记录、评估、授权、优先级划分、计划、测试、部署、归档和回顾检查的过程。在这个过程中,相关的信息被记录至配置管理系统,整体的业务风险获得优化。

在ITIL v3 中,v2 时原有的10个流程被进一步分化、加强,Service Strategy 阶段以及Transition Planning and Support 等流程的引入,使得对投资和风险的优化可以更加专业的发生在多个层次上,使Change Management 可以更加专注于处理操作层面change 或是对高层次change 进入实践的最后一步控制,从某种程度上为Change Management 减负,也使这套IT 服务管理架构获得了更好的适应性,以应对更大规模的或是业务管理灵活的组织。

1.变更管理中变更请求受理及评估过程的意义

按照change 的定义,所谓“可能对IT 服务造成影响的”“对任何事物的增加、更改或移除”,意味着IT 服务管理中涉及的change 无处不在,新员工账号的创建、离职员工账号的删除、新电脑的加入、会议室网口的增加、新应用系统的上线、老应用系统或是服务器的下线、服务器密码的统一修改、Windows 系统的定期补丁升级或其他应用系统更新、办公室搬迁、新型号打印机的引入、文件服务器上share folder 的调整、服务合同的续签、对某些网站访问的屏蔽、leased line 带宽升级等等,还包括那些难以分类界定的和IT 有关的需求。

实践中的change数量巨大,而Change Management 要求快速高效地处理change 同时还要控制风险, 在某些组织中还希望尽可能优化资源投入,难度可想而知,于是采用标准化的方法和过程成为必然。同时,change 又是多种多样的,为了达到标准化处理的目的,首先就需要采取分类处理的办法。

Normal change 处理的主要过程为,

1. 接受并核查RFC;

2. 评估Change,记录风险和影响;

3. 计划及授权;

4. 准备Change 执行;

5. 执行Change;

6. 检查并结束Change。

此外对于standard change 可以建立单独的处理流程,

7. Standard Change 流程

分类的过程发生在步骤1. 接受并核查RFC。在所需信息基本完整的情况下,尽早进行分类,可以使后续工作的标准化更加容易。例如可以在步骤1 处选择是否进入standard change 流程以及判断属于哪类standard change。信息收集和分类,是所有后续Change Management 活动的基础,应细腻适度。

步骤2. 评估Change,记录风险和影响,这步是change 授权决策及执行的最重要的基础,也是Change Management 实现其价值的重要步骤。Change Management 的价值不仅体现在change 的实施结果、多个change 间的安排和执行中的资源调度优化上,也体现在通过影响和风险的分析,提出良好的实施方案,以及对风险的避免或弱化,这部分的价值是无论change最终是否实施都存在的。

2.方法和模型

步骤1. 接受并核查RFC

鉴于change 的复杂性,Change Management 所接收的RFC (Request for Change) 可能有各种不同的来源,包括发起自IT 组织本身的,也包括源自客户或是最终用户的。由于Service Desk 是最终用户与IT 组之间的主要联络点(Primary Point of Contact),因此绝大部分直接来自最终用户的变更需求都会是经由Service Desk 及其所主要工作在的Incident Management 流程转至Change Management。此外,其他IT 服务管理流程,如Service Design 中的Service Level Management,Service Transition 中的Transition Planning and Support,Service Operation 中的Problem Management 等等,几乎所有流程,只要涉及变更,都需要触发Change Management,即生成RFC 发送至Change Management,并由Change Management 完成相应的授权及管理控制。

步骤1.1 接收和过滤RFC。RFC 的提交不同的组织中可以采取不同的方式,可以通过电子邮件附带特定格式的word 或是excel 文件、可以通过网页或是InfoPath 提交、也可以采用专用的IT 服务管理信息系统如Remedy 等。无论采用何种方式,一般来说,RFC 中都会包含以下内容,申请者信息、变更的描述、原因、相关记录(incident、problem 或其他change 等)、已知的影响和风险、建议的优先级、建议的实施时间、预期的时间和费用消耗等。

除了明确定义为属于service request 或其它流程处理范围的,或是明确定义为不属于change 或IT 服务范围的,其他所有包含变更的请求都有可能会被发送至Change Management。Change Management 小组成员需要根据相关政策、要求确认所接收到的请求是否为Change Management 处理范围,如果不是,则返还给请求的发送者,或是转发给正确的处理者。如果初步判定为在Change Management 处理范围内,则需确认所需信息是否完整齐备。

步骤1.2 核对相关合同。来自用户的对信息、设备、标准变更、或服务使用权等的请求,如要求重置密码、新用户申请邮件账号等,属于合同范围你的标准服务请求,通常归为service request,由Service Desk 在Request Fulfillment 流程中完成,此类请求不会进入Change Management,或是在1.1 接收和过滤RFC 阶段中即被退回。对于没有被当前服务合同所完全涵盖、同时有必要通过合同进行处理的变更请求,一般首先需要进行进行项目的开发、准备,而不是直接进入Change Management 审批。这种类型的变更请求往往意味着含有较大的商业机会、变更规模或影响较大、现有IT 运营层面的操作无法满足。此外其他的请求,通常Change Management 可以直接受理,其中既可以包括IT 服务合同已包含的服务项目,也可以包括合同中没有但也不必需要合同的服务项目。

步骤1.3 分类。根据已有信息进行分类,依据不同的类别,可以采取不同的处理方式的响应级别。例如对于有固定的操作模式、经常发生、成本和风险都在可控范围内的standard change 应用对应的standard change 流程;对于紧急的变更请求,则须加快响应速度并在后续操作中采取应急的处置方式。进入此步同时意味着正式接受该RFC,因此,如果有应用Change Management 的管理信息系统,应此步或此步之前完成change ticket 的录入。

步骤2 评估Change,记录风险和影响

步骤2.1 识别所需的变更。指识别在此change 中要求变更哪些配置项,需要考虑到其他正在执行或已经计划的change。

步骤2.2 识别受影响的服务和潜在收益。根据2.1 所识别出的配置项识别受影响的服务和潜在收益。

步骤2.3 识别所有受影响的配置项。根据2.2 中识别出的受影响的服务进一步挖掘会受影响的所有配置项,需要考虑到其他正在执行或已经计划的change。

步骤2.4 如果涉及多项变更,可创建多个change 记录。

步骤2.5 评估并记录影响和高风险。可以采用组织中已有的风险管理方法来完成此步,seven Rs 的方法可以帮助风险评估者完成此项工作。7个R 对应着7个问题,它们有助于进一步理解此变更的风险和价值。

Who RAISED the change? 谁提交的此项变更?

What is the REASON for the change? 变更的原因是什么?

What is the RETURN required from the change? 希望达成何种结果?

What are the RISKS involved in the change? 牵扯了哪些风险?

What RESOURCES are required to deliver the change? 需要哪些资源来完成此项变更?

Who is RESPONSIBLE for the build, test and implementation of the change? 谁负责构建、测试和实施此项变更?

What is the RELATIONSHIP between this change and other changes? 此项变更与其他变更间有什么关系?

步骤2.6 联系发起者补充信息。

步骤2.7 拒绝该RFC 并告知发起者。

3.总结

Change Management 流程的实现要求通过标准化的方式,其中的每一个步骤也应尽量做到标准化,并考虑到前一步是下一步的准备,同时避免无效的活动、以全局利益的实现为根本。在Change Management 的实施中,应严格禁止未授权变更的出现。同时,ITIL 的核心方法论是PDCA,流程和规则都不是死的,需要不断改进,Change Management流程步骤也需要根据业务发展不断调整。

参考文献:

1.Sharon Taylor, et al. ITIL Service Transition[M]. UK: TSO, 2007.

作者介绍:

it项目管理过程组 篇3

PMP中理论太多，下面我各用一句话概括项目管理知识体系五大过程组和九大知识领域：

五大过程

启动过程组：作用是设定项目目标，让项目团队有事可做； 规划过程组：作用是制定工作路线，让项目团队“有法可依”；执行过程组：作用是“按图索骥”，让项目团队“有法必依”；

监控过程组：作用是测量项目绩效，让项目团队“违法必究”，并且尽量做到“防患于未然”；

收尾过程组：作用是了结项目（阶段）“恩怨”，让一切圆满。九大知识体系：

整合管理：其作用犹如项链中的那根线；

范围管理：做且只做该做的事；

时间管理：让一切按既定的进度进行；

成本管理：算准钱和花好钱；

质量管理：目的是满足需求；

人力资源管理：让团队成员高效率地和你一起干；

沟通管理：和项目干系人搞好关系；

风险管理：“无事找事”，从而让项目“无险事”；

it项目管理过程组 篇4

2．电工必须持证上岗作业，操作证必须有效，严禁无证操作上岗。

3．上班时，必须坚守本职工作岗位，认真操作，不得离岗串岗，不得让非电工人员乱拉乱接电线，严禁带电作业。

4．在施工中一定要按用电安全操作规程施工，线路必须采用三相五线制，经过漏电保护器后，方可按要求接用电设备。

5．按照各设备的容量进行计算，并选择电线的截面积，以及保险丝的安全电流。

6．架空线必须采用绝缘线或绝缘铝线，架空线必须架设在专用电杆上，架空线路挡距不得大于是35m，线间距不得小于0.3m，线路最大弧垂与地面距离不小于4m，导线必须满足机械强度要求。

7．电线杆的埋设深度不小于杆长的1/10再加上0.6m，严禁沿地面明设电线，埋地导线必须套管后方可埋地。

8．电线不得有老化、破皮、漏电，杆上及室内架线必须有横担，要有绝缘子，严禁电线架设脚手架或树上。

9．电缆架空时，严禁用金属裸线作绑线，橡皮电缆的最大弧垂距地面不小于2.5m，过道路埋地电缆必须套上钢管。

10．在施工现场和宿舍内不准乱拉乱接线，严禁使用电炉。

11．上班时，坚守本职工作岗位，认真操作，不准离岗串岗，非电工人员不许操作电器，严禁带电作业。

12、每台用电设备应有各自专用的开关箱，开关箱内严禁用同一个开关电器直接控制二台或二台以上用电设备（含插座）。

13、配电箱内各种电器必须合格且符合使用要求，箱内应设置配电系统图，并标明各分路的用途。

14、机械设备及配电箱外壳要与专用保护零线连接。

15．配电箱要有专人（电工）负责，其它任何人不得擅自打开乱接线。

16．配电箱，开关箱应采用铁板或优质绝缘材料制作，铁板的厚度应大于1.5mm，并能防雨防尘。

17．总配电箱应设在电源的地区，分配电箱应装设在有电设备负荷相对集中的地区，分配电箱与开关箱距离不得超过30m，开关箱与其控制的固定式用电设备的水平距离不宜超过3m。18．总配电箱应装设总隔离开关，总熔断器以及漏电保护器，总开关电器的额定值，动作定值与分路开关电器的额定值，动作定值相适应。

19．动力配电箱与照明配电箱宜分开设置，如合置在同一配电箱内，动力和照明线路应分路设置。

20．配电箱，开关箱应装设端正、牢固，移动式分配电箱，开关箱应装设在固定的支架上，固定式分配电箱，开关箱的下底与地面的垂直距离应大于1.3m，小于1.5m，移动式分配电箱，开关箱的下底与地面的垂直距离不小于0.6m，小大于1.5m。21．配电箱内的电器安装在金属或非木质的绝缘电器安装板上，然后整体坚固的配电箱箱体内，金属板与配电箱箱体应用电线连接，配电箱和开关箱的金属箱体，金属电器安装板以及箱内电器不应带电金属底座。

22．配电箱金属外壳有可靠接地，接零，接地线必须用多股铜芯线及专用接地线，接地电阻不得大于4Ω。保护零线应通过接线端子连接。

23．配电箱引入、出线应加护套分路成束，电缆不得有老化、破皮、漏税电，电缆横穿道路时，应采用保护措施，和开关箱的连接应采有绝缘导线，接头不得松动，不得有外露带电部分。进出线，并做好防水弯，导线束不得与箱体进出口直接接触，移动式配电箱和开关箱的进出线采用橡皮绝缘电缆。

24．配电箱，开关箱内的电器必须可靠完好，不准使用破损，不合格的电器。配电箱，开关箱内不得挂接其它临时用电设备。

25．必须实行“一机一闸一触保”制，严禁用同一开关电器直接控制两台以上用电设备（含插座）。开关箱内必须装设漏电保护器。灵敏度的检查由专职电工负责，按时检查并做好记录及交接班记录。

26．所有配电箱应标明其名称、用途，并作业分路标记。

27．配电箱、开关箱内应配锁，安全标志，箱内无杂物，积灰，接线牢固整齐，移动式配电箱离地有0.6m。

28．漏电开关开闸后，必须检查原因后，方可送电。

IT项目管理重点 篇5

2.项目是在一定的资源约束下完成的既定目标的一次性任务。

项目三关键要素：时间、资源（最终体现是成本）、目标（最终体现是绩效）

3.项目管理的四要素：范围、时间、成本、质量。

 范围，也称工作范围。

 时间，也称为项目进度。

 成本，也称为项目费用。

 质量，指项目满足明确或隐含需求的程度，与绩效和满意度相关。

4.IT项目的一般特征：

项目目标的明确界定性、项目执行任务的相互关联性、项目寿命的有限性、项目需要资源的多样性、项目的一次性、项目具有很强的针对性、项目具有不确定性

5.IT项目的特殊性：

（1）项目目标的不准确性

（2）项目需求的多变性

（3）项目功能的渐进性

（4）项目时间的不准确性

（5）项目风险的不确定性

（6）智力劳动的密集性

6.IT项目管理在这个体系框架中，分为立项、计划、实施、评估、推广和维护六个阶段。

7.IT项目生命周期四个阶段：识别需求、提出解决方案、执行项目、结束项目

8.项目五大过程是指“启动、计划、实施、控制、收尾”。

9.一般将IT项目管理过程分为八个部分，即：协商范围、确定任务、估计任务周期、说明任

务之间的依赖关系、分配资源、指导团队工作、监督和控制进展、评估项目结果和经验

10.项目开发周期估算目的：

估算的任务就是使预计的时间尽可能的接近实际所需要的时间，以便于项目的正常实施，避免项目失去控制而造成延期和迟滞。

11.项目开发周期估算方法：

① 甘特图（Gantt）特点：简单、直观，易于控制。十分普及。

② 网络图即彼特图（PERT）：

箭线式:箭线式箭头代表项目活动，节点代表活动的开始或结束

点线式:点线法节点代表活动，箭头代表顺序。

③ 关键路径方法（CPM）：

关键路径的两种寻找方法：

在一条路径中，每个工作的时间之和等于工程工期，这条路径就是关键路径。

若在一条路径中，每个工作的时差都是零，这条路径就是关键路径。

12.关键路径：从项目开始到项目完成有许多条路径，在整个网络图中最长的路径就叫关键路径。

13.项目开发周期估算方法选择---方法选择考虑的因素分析：

项目的规模大小、项目的复杂程度、项目的紧急性、对项目细节掌握的程度

总进度是否由一两项关键事项所决定、有无相应的技术力量和设备

14.影响项目开发周期内、外因素：

① 参与人员的熟练程度②工作效率③突发事件④误解和错误⑤在大多数项目中，时间管理

是一个软约束，项目晚几天完成只会减少收益，不会是项目完全失败

15.项目利益相关者可以分为五种类型：项目组成员、公司现有业务现有项目的成员、资源提供者、用户、潜在利益相关者

16.市场预测是指以市场调研所获得的信息资料为基础，运用科学的方法对未来一定时期内市场发展的状况和发展趋势做出估计和判断。

17.工作分解结构（Work Breakdown Structure，WBS）是面向提交成果对项目进行结构分解。模拟估算法和参数模型法是两种自顶向下的估算方法。

18.制定项目计划是项目经理的一项重要职责，是项目管理的核心。

19.项目计划的编制主要包括以下内容：项目分解、综合计划编制、范围计划编制、进度计划编制、资源计划编制、成本计划编制等。

20.工作分解结构(Work Breakdown StructureWBS)是一种以结果为导向的任务分析方法，用于分析所涉及的工作。

WBS的三个基本要素：WBS的结构、WBS的代码和WBS的报告

WBS通常是一种面向“成果”的“树”，其最底层是细化后的“可交付成果”

21.工作包是WBS结构底层，它包含了管理所需的最低层次的信息，是项目的最小可控单元。在这一层次，应能够满足用户对交流或监控的需要。工作包是短期任务。

22.工作包的特点：

① 与上一层相应单元关联，与同组其他工作包有关系

② 责任可以落实到具体单位或个人

③ 能够确定工期，时间跨度最短

④ 能够确定实际预算、人员和资源的需要

23.基于可交付成果划分WBS分解类型：上层一般为可交付成果的导向，下层一般为可交付成果的工作内容。

基于工作过程划分WBS分解类型：上层按照工作的流程分解，下层按照工作的内容划分。

WBS的表示形式：分级的树型结构、列表形式

WBS设计原则：功能或技术的原则、组织结构、地理位置、系统或子系统原则

24.WBS设计方法主要有：类比法、自上而下法、自下而上法。

工作分解后的任务应该是可管理的、可定量检查的、可分配任务的和独立的。

25.项目综合计划的交付物可以是文件形式也可以是表格形式。

26.制定项目综合计划内容：项目介绍、管理介绍、组织介绍、预算介绍、技术介绍

27.项目进度计划方法：甘特图法、里程碑法（里程碑法是最简单的一种进度计划方法，仅表示主要可交付成果的计划开始时间和完成时间及关键的外部界面）

28.项目进度计划编制：①项目描述②项目分解③工作描述④制定工作责任分配表⑤确定工作先后关系⑥绘制网络图⑦工作时间估计⑧进度安排

工作代码：用计算机管理工作时间的唯一标志符，可看出工作之间的父子关系。

29.项目资源按用途分：人力资源、原材料设备资源、工具与场地资源。

30.质量计划的内容应以系列标准的要求或组织的质量体系文件为依据，并随项目的进展而随时更新，应经正是评审并得到与项目执行相关的组织同意。

31.项目进度计划的编制过程：①项目描述②项目分解③工作描述④制定工作责任分配表⑤

确定工作先后关系⑥绘制网络图⑦工作时间估计⑧进度安排

32.IT项目是智力密集、劳动密集型项目，受人力资源影响最大

33.项目质量计划包括的内容：①质量计划的目的②领导职能③合同评审④采购⑤设计控制⑥过程控制⑦不合格品处理⑧培训⑨质量审核

34.项目质量计划编制：

① 效益/成本分析：质量成本应是适宜的质量成本包括：预防成本、鉴定成本、内部损失成本、外部损失成本

② 基本水平标准

③ 流程图

④ 因果图

⑤ 试验设计

35.质量计划的输出包括：质量管理计划、操作性定义、检验单

36.项目风险类型7种：信用风险、完工风险、生产风险、市场风险、金融风险、政治风险、环境风险

37.关于软件开发项目，按SEI将风险分类：项目风险、技术风险、过程风险、商业风险、外

部风险

38.范围核实（scopevertification）：指利益相关者对项目范围的正式接收，包括项目最终产

品和评估程序，以及这些产品的满意程度和评估的正确性。

范围核实的实质是验收可交付成果的过程。

39.基线：指已经正式通过复审和批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。

基线是软件生存期各开发阶段末尾的特定点、里程碑。

功能基线、分配基线和产品基线是比较常用的三种基线。

40.配置管理过程---基本活动：配置管理计划、配置项标志、配置项控制、状态状况报告、配置项审核

41.IT项目测试方法：

白盒测试：（结构测试或逻辑驱动测试）主要方法—逻辑驱动、基路测试，主要用于软件测试

黑盒测试：（功能测试或数据驱动测试）主要方法—等价类划分、边值分析、因果图、错误推断等，主要用于软件确认测试

42.测试类型：功能测试、性能测试、算法测试、正向测试、逆向测试、边界测试、配置测

试、负载测试

43.IT项目控制阶段，经理的作用---解决的真正问题是确定偏差的可接受范围。

44.范围变更是必然的、可控的、有益的。

45.项目进度偏差是项目进度控制的重要依据。

46.IT项目成本控制方法：

① 分析表法：利用表格的形式调查、分析、研究实施成本的一种方法。

② 挣钱分析法：

3个基本参数：计划值、实际成本、挣值

it项目管理过程组 篇6

【中图分类号】G633.55 【文献标识码】A 【文章编号】2095-3089（2016）32-0272-01

一、2015年新课标II卷第9-11题：

圣劳伦斯河（图3a）是一条著名的“冰冻之河”。图3 b示意蒙特利尔年内各月气温和降水量。据此完成（1）—（3）题。

（1）蒙特利尔附近河段结冰期大致为：（ ）

A、2个月 B、3个月 C、4个月 D、5个月

（2）据图示信息推测，冬季可能不结冰的河段位于（ ）

A、安大略湖至普雷斯科特河段 B、普雷斯科特至康沃尔河段

C、蒙特利尔至魁北克河段 D、魁北克以下河口段

（3）减少该河凌汛危害的可行措施是（ ）

①加深河道 ②绿化河堤 ③分段拦冰 ④拓宽河道

A、①② B、②③ C、③④ D、①④

答案：（1）-（3）C B C

试题总体评价：1、高考题都是新情境 2、立足于情境答题3、去模板化

4、注重知识的生成过程和思维方法5、知识抽样，能力覆盖

【解题过程】 一般情况下，高考题的答案有如下来源：

教材已经学过的知识；情境新生成的知识；生活中的体验。

第（1）题：问题是蒙特利尔附近河段结冰期，那么首先应该在题干中找关于蒙特利尔的相关信息（即情境新生成的知识），a图提供的是蒙特利尔的位置，b图提供了蒙特利爾年内各月的气温和降水，结合图像，再结合已经学过的水结冰的一般条件：（1）、0°C以下结冰（2）、0°C以上不结冰。可以看出b图中低于0°C的月份，继而得出蒙特利尔附近河段结冰的时间跨度。

思维点：结冰期长短取决于低于0°C持续期的长短

第（2）题：题干中新生成的信息是蒙特利尔附近河段有结冰期，若从气温考虑不结冰条件（高于0°C），那么不结冰的一定在蒙特利尔的上游河段（上游河段纬度低），可以把C先排除掉。我们生活中的体验是：浅水比深水容易结冰，河水比海水容易结冰，流速慢的比流速快的容易结冰，归纳起来，水是否结冰的标准为：是否达到结冰的临界点0°C，（一般情况是水体 0°C以上不结冰，0°C以下结冰）

一般情况：同一水域深水区不结冰表层结冰，说明深水区温度高于表层水温，流速快的水体不易结冰可能是水体的分层流动被打破，在一定范围内产生一些漩涡、湍流，这些漩涡和湍流，有可能使底部较高温度的水向表层附近流动，而表层附近较低温度的水向下流动，这样带上来的热量阻碍表层附近水体的降温和结冰。结合本题，河流接近湖口附近河段和接近入海口附近河段都有可能不结冰，湖口附近因纬度较低，可能气温高于0°C，入海口附近因为盐度较高，可能不结冰，相比较而言， a图图例中标记了“水电站”（水电站建设的条件之一是落差大，落差大决定了水流速快）那么流经水电站前后可能因为水流速度快，打破了水体的分层流动，使得底部高水温水体向表层附近运动，阻碍结冰，故B相对于A、D相对有说服力。

本题有一定难度，大部分学生容易错选低纬度接近湖口附近河段，有相当一部分学生可会能考虑到入海口附近河段可能不易结冰。

本题错选的原因一般是没能提取题干中有效信息，没有深入比较ABD选项哪一个选项相对较合理，属于审题不清晰，同时缺少相关的生活体验

思维点：结不结冰看淡水水温是否低于0°C

方法：把自己置身于情境中，当你面对一个问题时如何解决

第（3）题：要知道凌汛产生的原因，前提是知道什么是凌汛。凌汛是指河冰、冰坝阻塞水流，引起河水上涨的现象。凌汛实际就是冰和冰坝使河水受阻了，解决的方法就是不让冰和冰坝阻塞水流，使得河水流的通畅。就备选项而言，①③④都可以解决河水受阻，使其变得通畅。相对比较，拦冰和在河流两侧拓宽河道比到河道里深挖更容易实施，故可行措施是③④。本题看似简单，实则容易错选①④，错选的原因一般是：不清楚“凌汛” 没注意“分段拦冰” 和“可行”关键字。

方法：措施类习题的解题方法是首先应知道问题产生的原因，然后实施解决措施。

二、对高三备考的启示

1、学生在基础知识没有问题的条件下，教师平时教学中首先要注重培养学生的从题干中快速准确地获取信息，并能按照知识间一定的关系整理出答题思路的能力。做选择题时，引导学生，先排除有最有把握的选项，没有把握的要看哪个更合理和更能说服自己。应立足于情境去思考问题并答题，不是根据自己潜意识中的主观臆断答题。论证和探讨时，要注意知识间的逻辑关系、因果关系以及先后顺序。

2、高考题的新情境下可能会有新名词和新概念，就如英语阅读理解中有生词一样，要试着通过情境的上下文去推测和理解。

3、在教学过程中，问题设置要有思维含量和思维梯度，且符合学生的认知水平。

IT项目管理心得 篇7

本学期新增加了IT项目管理课程，通过学习使我认识到，对于一个项目，我们过程中做的所有工作都是为了要达到项目目标，因此在项目各个阶段所有活动都需要考虑对达成目标的影响，当发现偏差后及时纠正。目标驱动让我们从无目的的事后应急变成了有计划有目的的事前预测。目标驱动不是要抛弃过程，项目的成功涉及到过程，人和方法工具技术。为了达到项目目标，我们要根据项目的实际情况采取一系列项目原来已经总结的最佳实践形成一套过程，高效的过程和积极心态的人是保证项目目标达成的关键。因此作为项目经理要时刻问自己，项目的目标是什么； 项目当前状态和我达成目标的差距是什么；我如何解决和应对。

项目的成功受到多方面的因素的影响，而且各个因素之间还存在正反作用力。系统思维就是要让我们能够清楚的认识到影响项目目标和成功的各个要素，以及它们之间存在的关系。形成一种适合项目的动态系统模型，通过这个动态模型去平衡项目各方干系人的利益，平衡项目四要素之间的关系，平衡项目的短期和长期的利益。项目经理的一个重要能力就是平衡，没有最优解，只有满意解，懂得了平衡就知道当项目出现变更和调整的时候如何更好的应对。从单要素最优的单向思维过渡到关注整个系统的全局思维模式上。

本门课程其中我最有感触的是项目管理中的团队合作。本次课程的作业，要求了一个项目由一个团队来完成而不是个人，这样的练习模式使我们更适应了以后企业中的项目开发。更重要的是体会项目团队不仅仅是指被分配到某个项目中工作的一组人员,它是指一组互相依赖的人员齐心协力进行工作,共同实现项目目标,项目成功需要一个有效的项目团队。科学的组织和管理可以放大工程项目团队的工作能力,使工程项目的实施向着有序的方向发展。在所有管理中,人的管理是最为复杂的,对工程项目管理人员来说极具有挑战性。我相信研究优秀团队管理的方法和策略对于每一个工程项目管理人员都是必要的。

it项目管理心得 篇8

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点（用例）。eas项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。

项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师）从eas项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。

项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。

注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。

注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了eas项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)

控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱)

设计

重视架构设计。eas项目的成功，一定程度是源于我们有个优秀的框架开发小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计统一)

善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下，为了项目进度不出现大的偏差，eas项目组并没有过分强调技术，特别是在考虑进度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却能够有效地保证项目的进度。从eas最初的架构设计来看，我们引入了 castle与aop，试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用wcf，利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化，我们果断地放弃了采用wcf的构想，同时又克服了技术困难，坚持了对castle与aop的使用，并为此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。

重视ui原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户，则客户更能够理解系统的实现，促进沟通的有效性与准确性。在eas项目中，我们从一开始就确立了原型设计小组，并在分析需求阶段，就开始了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏专门的ui设计人员，因此，这一工作还存在很大的缺陷，甚至于ui的设计为迭代版本的交付带来了很大的障碍。在项目后期，关于ui的bug是最多。因此，我们认为在开发类似的web应用程序时，应尽早确立ui设计规范，以约束所有的ui设计。同时，必须培养专门的ui设计师，在开始原型设计时，就尽快完成ui交互的设计。并且，必须成立专门的ui 设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段，不一定需要专门的ui设计人员，原型设计可以由需求分析师来完成)

测试

测试成员应了解需求。如果不了解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能因为错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别，测试人员不用想需求分析人员一样分析和开发业务，但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)

测试之初必须确定测试原则，对bug的严重程度进行分级。同时，必须确定修复bug的优先级别。

进度管理

保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 rup或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。

其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。

要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。

政府IT项目管理经验 篇9

明确项目背景

必须了解项目涉及的相关部门，尤其是涉及多部门的项目。政府项目一般都会有一个主管部门，但在政府业务中有一个现象必须注意，不管是多部门还是部门内部，在进行到开会讨论的时候，如果有一个部门或一个主要人员提出异议，那么不会有人出面来压制，因为这涉及到政府的管理体质，没有任何人愿意冒险来承担未知的责任，即便可预期的时间中不会发生任何风险。

项目启动

项目启动很重要，这是项目经理判断项目操作的一个最基本点，由于项目性质是政府，目标客户是官僚机构，一开始没有必要去做调研，而是先通过拉关系，建立兄弟般的友情开始，从聊天中摸清政府对这个项目的一些基本看法，这对我们实施可是有巨大帮助！属于指导性纲领。

项目沟通机制

对于官僚机构，他们最喜欢的就是汇报，有领导的欲望，所以我们制定的沟通，每星期碰面一次，每周以工作报告形式汇报。并制定双方领导通报机制，毕竟政府项目多是领导工程（一把手工程）

项目文档机制

官僚机构最麻烦的就是经常说了忘记，没关系，让他们忘不了，在公司内部，在客户服务器上要建立专门放置沟通文档、过程文档的文件夹，我们所有沟通，重要沟通的工作单全部有记录，对客户来说，他要对他自己说的负责。

内部学习机制

官僚机构最多的是理会上级精神，我们既然做政府项目，自然要知道，我们也和政府人员一样学习！学习！再学习！！最好将他们的文件复印带回来，并将关于信息化方面的精神传达，并针对我们的项目进行分析，让每个人都知道自己应该做什么，如何做。

领导汇报机制

其实这个应该纳入沟通机制，但是太重要了，所以要单独拿出来，项目最后的验收和成功，全靠领导一句话，而领导不知道你实施如何，他是不敢签字画押的，为此我们要提前准备给领导看的项目报告，将项目用最精简的问题，再必要的时候向领导汇报，让我们的政府大爷们知道这个项目是什么，做什么，将来能干什么，目前完成情况（有点向给幼儿园小孩给教案的感觉）

项目实施

调研计划和项目整体计划

调研对于项目实施起铺垫作用，在调研中，采取笨办法，反复确认，直到客户满意，最简单的方法，拿模板给客户看－－直观，也知道以后出来是什么东西

需求分析

将调研的东西上升到理论以文档水平，客户确认，开发阶段

必须的加班一定做，没必要的从来不加，合理的安排计划，加班没多大作用，应为一切按照计划走，验收阶段

采取两条路线，公司高层对政府高层。项目经理对具体实施人员

培训阶段

计划最重要，强调培训的步骤及事先的准备工作。

最后

终于验收了并且客户关系良好，钱也给了，最后还剩10%，合同规定保证金，拿不回来，等一年后，但是对整体项目金额意义不大

《IT项目管理》课程总结 篇10

时间过得很快，不知不觉中《IT项目管理》这一课程已近学完。在这近三个月的《IT项目管理》课程学习中，我收获颇多。

通过在课堂上的学习，我对IT项目管理有了一个大概的了解和综合的认识。再从刚刚通读的“从泰坦尼克号”这篇文章中，我对IT项目管理有了进一步的学习和认识，我真正认识到IT项目管理在现实生活中的运用。现将我对IT项目管理的理解总结如下。

IT项目管理是项目管理在IT领域的应用。它结合了IT行业特点并且运用了项目管理技术、理念和方法，包含着多个知识领域（如时间管理、成本管理、质量管理、风险管理、人力资源管理、沟通交流管理及采购管理等）。

由于IT项目管理是项目管理在IT领域的应用，因此它有着在信息技术行业的许多特征：任务的明确性、管理工具的先进性、信息沟通的及时性、资源提供的必要性、测试的完善和严谨性、度量的准确性及项目管理的贯穿性等。

首先我们来分析一下泰坦尼克号的悲剧。

在泰坦尼克号的设计阶段，该项目设计小组就投资的支出重点引发了一次争论，最后经营战略战胜了其它的考虑因素，即新兴技术上总的投资额就没有包括诸如安全系统这种非功能需求的支出。它注重的是“功能需求”这个目标，而忽视了“非功能需求”，使得大多数安全性能都没有得到重视，这就为后面的悲剧埋下了隐患。

在项目结束的时候，该项目小组认为船的安全性能仍然维持在最初设想的较高水平，泰坦尼克的项目小组还深信着最初的设计所具有的功能，因此在项目测试阶段并没有对泰坦尼克号进行逐一测试，这也就进一步埋下了隐患。

其实，泰坦尼克号的设计及制造诸多方面可以与现代IT项目进行比较。它与现代IT项目有许多极其相似之处。

与泰坦尼克号相比，对IT项目来说，非功能需求包括了有效性（类似于保险设置）、安全和基于系统运行性质的系统管理。其它基于非运行性质的非功能需求包括可量测性、轻便性、可维护性、环境因素和改进性。与此类似的，非功能需求确保系统具备应有的基本职能。要描述非功能需求有很多种依靠计算机仿真辅助的模拟技巧。

今天一些IT项目也在设计和建造阶段有过严重的妥协，一般倒也无伤大雅。但是这些妥协可能引发的问题当时看起来不明显，却可能在项目完工后以及方案投入生产后的一些天、一些月甚至几年后爆发出来。项目经理需要确保对功能需求和非功能需求投入同样程度的关注。

今天许多IT项目都没有制定充分的测试计划，并且在将解决方案转化成产品时，没有制止非功能需求上的严重让步。这就好比白星公司拿奥林匹克当试验，就认为泰坦尼克号的首次航行是低风险的。毕竟，这两艘船几乎是一样的，而且船主以及工作人员都对泰坦尼克号比较信任。然而，没有哪两艘船有完全一样的操纵性能。白星公司在不制定测试计划上豪赌了一把，并且还令横穿大西洋的泰坦尼克人手不足。当泰坦尼克号项目进入下一阶段，人们关于它不会沉没的观念仍然没有改变。

因为泰坦尼克号与今天的IT项目管理有许多相似之处，因此我们有许多经验教训可获取。IT项目可能会犯的错误是过份依赖以前与之类似的项目，从而减少了测试的次数。项目执行过程中要根据以前拟好的计划执行，这样组织及更多的运作小组才能有很好的准备。在没有经过一些风险评估时，关键的操作程序不能因业务上的压力而有所让步。测试目标是为了揭发在需求、设计及建造阶段主要存在的漏洞问题。许多IT项目在测试中作出了让步，没有把测试看得足够重要，并且在将解决方案迅速投入生产的业务压力下屈服了，这是不可取的。所有工作人员尤其是操作人员，他们所重视的工作，他们的工作动机都是来源于服务级别协议，因此项目应该重视到这一点，尤其是当项目牵涉到第三方或外来资源时。一个业务主管在没有得到操作人员的同意下，没有权力下任何操作决策。在一个关键情形下，任何异常都来源于操作者（诸如守望员）与技术支持人员（诸如船桥官员）之间的传递过程；一次顺利的传递必须在项目实验阶段通过运转及操作测试来实现。在解决问题时，必须在搜集好所有数据信息的前提下，分析每个解决方案所带来的风险性，再考虑选择最合适的解决方案。要不然就得靠最后第四象限的修复阶段了。在这个阶段里，操作小组会根据服务级别协议（SLAs）即时撤回IT解决方案，并让服务再重新开始。

由于在解决方案的运作及修复阶段没有遵循事先制定好的方法，许多IT项目在关键情况中遭受了不幸。专业化的平均修复时间程序可以帮助我们从不同的决策中选择出最好的一个，然后将其运用在泰坦尼克号上。因此支持人员应该对解决方案的细节了如指掌。今天，许多IT项目没有为最坏的情况有所准备就在操作上作出了让步。在今天的世界里，光有平均修复时间程序是远远不够的。除了一个灾难修复计划外，还必须要有一个合适且周全的交流计划。

总的来说，IT项目管理要做好如下过程：计划过程、计划过程、执行过程、控制过程以及收尾过程。

以上是学习《IT项目管理》后，我对IT项目管理的认识。

感觉在这门课程的学习过程当中，老师给我们提供了许多可以提高锻炼自己的机会。比如说上课前让学生到讲台上去自由演说这一活动，很是能提高学生的能力，尤其是语言表达能力方面；上次去公司面试实习单位的时候，我注意到了不仅专业知识重要，语言表达能力同样很重要。只是，对于老师提供的这一舞台我没有好好把握和珍惜。再比如说，老师让学生们分组完成相应的任务，制作课件去讲课，同样能提高学生们的组织能力、沟通能力及团队合作能力等。