参考资料:软考高级信息系统项目管理师教材
10大知识领域
一:项目整合管理
二:项目范围管理
三:项目时间管理
四:项目成本管理
五:项目质量管理
进成质范【进城吃饭】是核心知识领域,将形成具体的项目目标。
六:项目人力资源管理
七:项目沟通管理
八:项目风险管理
九:项目采购管理
十:项目干系人管理
风沟采人【疯狗踩人】是辅助知识领域,项目目标是通过他们的辅助而实现的。
整体形成整合管理。
优秀项目经理应该具备的素质(广博的知识、丰富的经历、良好的协调、职业道德、沟通表达、领导)项目经理必须承担管理者和领导者的双重角色。真正理解项目经理的角色、重视项目团队的管理,惩罚分明、计划、计划、再计划、真正理解软件工程,注重用户参与。
项目的概念
1、项目是为提供一项独特产品、服务或成果所做的临时性努力。
项目目标包括成果性目标(满足客户要求的产品、系统、服务或者成功)和约束性目标(时间、成本质量)。
2、项目的目标特性:1)项目的目标有不同的优先级2)项目目标有层次性
3、项目的特点
特点 | 说明 |
---|---|
临时性(一次性 | 每一个项目都有确定的开始和结束日期 |
独特的产品、服务或成果 | 创造独特的可交付成果,如产品、服务或成果 |
逐步完善 | 分步、连续的积累。例如,在项目的早期,项目范围的说明是粗略的,随着项目团队对目标和可交付成果的理解更完整和深入时,项目的范围也就更具体和详细 |
资源约束 | 每一个项目都需要具备各种资源来作为实施的保证,而资源是有限的。所以,资源成本是项目成功实施的一个约束条件。 |
目的性 | 项目工作的目的在于得到特定的结果,即项目是面向目标的 |
4、日常运作和项目也有许多共同之处:由人来做,受制于有限的资源,需要规划、执行和控制。区分:
①日常运作是持续不断和重复进行的,而项目是临时性的、独特的
②项目和日常运作的目标有本质的不同。项目的目标是实现其目标,然后结束项目,而持续进行的日常运作的目标一般是为了维持经营。
③项目的实现机制与日常运作大相径庭,因为当宣布的目标实现时,项目就结束了。相比之下,日常运作是确定一组新目标,然后持续进行。
不同 | 项目 | 日常运作 |
---|---|---|
目的 | 独特的 | 常规的 |
责任人 | 项目经理 | 部门经理 |
持续时间 | 有限 | 相对无限 |
持续性 | 一次 | 重复 |
组织结构 | 项目组织 | 职能部门 |
考核指标 | 目标为导向 | 效率和有效性 |
资源需求 | 多变 | 稳定 |
5、项目经理经常提到在管理互不相让的要求时遇到的项目范围、时间和成本的“三重制约”。项目的质量受这三个因素权衡的不利影响。高质量的项目在预算内按时提交满足要求的产品、服务或成果。
6、企业战略是层出不穷的,虽然有多种,但基本属性是相同的,都是对企业的谋略,都是对企业整体性长期性、基本性问题的计谋。战略管理包括三个过程:①战略制定②战略实施③战略评价;项目经常被当作实现组织战略计划的一种手段使用。
7、典型的信息系统项目的特点:①目标不明确②需求变化频繁③智力密集型④设计队伍庞大⑤设计人员高度专业化⑥涉及的承包商多⑦各级承包商分布在各地,相互联系复杂⑥系统集成项目中需研制开发大量的软硬件系统项目生命期通常较短⑩通常要采用大量的新技术⑪使用与维护的要求非常复杂。
8、项目管理就是把各种知识、技能、手段和技术应用于项目活动之中,以达到项目的要求。项目管理是通过应用和综合诸如启动、计划、实施、监控和收尾等项目管理过程来进行的。管理一个项目包括:识别要求确定清楚而又能够实现的目标;权衡质量、范围、时间和成本方面互不相让的要求;使技术规格说明书、计划和方法适合于各种各样项目干系人的不同需求与期望等内容。
9、理解项目管理
①项目管理是一种已被公认的管理模式,而不是任意的一次管理过程
②项目管理的对象是项目,即一系列的临时任务
③项目管理的职能与其他管理的职能是完全一致的
④项目管理职能主要是由项目经理执行的。在一般规模的项目中,项目管理由项目经理带领少量专职项目管理人员完成,项目组织中的其他人员,包括技术与非技术人员负责完成项目任务,并接受管理。如果项目规模很小,那么项目组织内可以只有一个专职管理人员,即项目经理。
项目组织结构
说明 | 优点 | 缺点 | |
---|---|---|---|
职能型 | 项目经理无权无资源,所有项目人员还在所属部门里面供职,仅仅花费小部分的时间来处理项目的事情。还有相应的职能经理,这样的双重管理对于项目来说是最可怕的了。当然好处,对公司来说。为这个项目消耗的资源不是很多;对个人来说,还在自己的 | 1、可以充分发挥职能部门的资源集中优势 2、部门的专家可以同时为部门内不同项目使用 3、便于相互交流,相互支援,可以随时增派人员4、可以将项目和本部门的职能工作融为一体 | 1、项目和部门利益发生冲突,职能部门更重视本部门的目标,会忽视项目目标 2、资源平衡会出现问题 3、权利分割不利于各个职能部门的交流和团结协作 4、行政隶属关系使得项目经理没有充分的权利 |
项目型 | 将所有的能兵强将集结在一起,财务部、业务部IT管理部等的精英们脱离原有的岗位,形成一个正式的部门,并由项目经理领导。这样的优势是项目经理的权利很强、资源充足。对公司而言,单独团队对公司整体资源的浪费;对被抽调的个人而言,脱离了原有的岗位。待项目结束之后,精英们将无家可归。 | 1、项目经理对项目可以负全责 2、项目目标单一,可以以项目为中心有利于项目顺利进行 3、避免多重领导 4、组织结构简单,交流简单,快速 | 1、资源不能共享 2、各个独立的项目处于相对封闭状态不利于公司政策的贯彻 3、对项目组织的成员缺少一种事业上的连续性和安全感 4、项目组织之间处于分割状态,缺少信息交流 |
矩阵型 | 兼具项目型和矩阵型的特点;分为弱矩阵,平衡矩阵,强矩阵 项目经理>职能经理=强矩阵 项目经理=职能经理=平衡矩阵 项目经理〈职能经理=弱矩阵 | 1、专职的项目经理负责整个项目,以项目为中心 2、公司的多个项目可以共享各个职能部门的资源 3、即利于项目目标的实现,又利于公司目标方针的贯彻 4、项目成员的顾虑减少了 | 1、容易引起职能经理和项目经理权力的冲突 2、资源共享也能引起项目之间的冲突 3、项目成员有多头领导 |
职能型 | 弱矩阵 | 平衡矩阵 | 强矩阵 | 项目型 | |
---|---|---|---|---|---|
项目经理权力 | 小or没有 | 小 | 小or中 | 中or高 | 高or全权 |
项目经理角色 | 联络员兼 | 协调员兼 | 全职 | 全职 | 全职 |
项目管理行政人员 | 兼职 | 兼职 | 兼职 | 全职 | 全职 |
预算控制人 | 职能经理 | 职能经理 | 混合 | 项目经理 | 项目经理 |
优点 | 职业路径清晰、便于知识交流,有利于重复性工作为主的过程管理 | 资源利用率高,有利于部门协调 | 同左 | 同左 | 项目经理控制度高,利于统一指挥,沟通简洁方便 |
缺点 | 横向联系薄弱,部门间沟通协难度大,项目管理发展方向不明确 | 多头领导,管理难度大,资源争夺 | 同左 | 同左 | 重复配置,管理成本高,不利于知识共享 |
图源见水印
职能型
矩阵型
项目型
信息系统项目生命周期
1、项目生命周期(产品导向过程)–项目从启动到收尾所经历的一系列阶段,阶段通常按顺序排列,有时也会交叠,阶段名称和数量视具体项目而定。(技术工作维度)
例如:建筑项目-可行性硏究、初步设计、详细设计、施工、移交
软件项目-需求分析、框架设计、详细设计、编程、测试、部署、移交
项目通用生命周期-启动项目;组织与准备;执行项目工作;结束项目
项目管理生命周期(项目管理过程组)-启动、规划、执行、监控、收尾(管理工作维度)
产品生命周期-从项目开始到项目结束再到项目产品运行生命终止(退出市场)的全过程。
注意:产品生命周期>项目管理生命周期=项目通用生命周期
2、生命周期结构具有以下特征:
①成本与人力投入在开始时较低,在工作执行期间达到最高,并在项目快要结束时迅速回落。
②风险与不确定性在项目开始时最大,并在项目的整个生命周期中随着决策的制定与可交付成果的验收而逐步降低。
③在不显著影响成本前提下,改变项目产品最终特性的能力在项目开始时最大
3、项目阶段都具有以下类似特征:
①各阶段的工作重点不同,通常涉及不同的组织,处于不同的地理位置,需要不同的技能组合
②为了成功实现各阶段的主要可交付成果或目标,需要对各阶段及其活动进行独特的控制或采用独特的过程。重复执行全部五大过程组中的过程,可以提供所需的额外控制,并定义阶段的边界。
③阶段的结束以作为阶段性可交付成果的工作估项目活动,并变更或终止项目(如果必要)的一个当然时点。这个时点可称为阶段关口、里程碑、阶段审查、阶段门或关键决策点。
4、阶段与阶段的关系有两种基本类型:①顺序关系②交叠关系
瀑布模型
1、瀑布模型是一个经典的软件生命周期模型,一般将软件开发分为:可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段
2、瀑布模型中每项开发活动具有以下特点:–对应结构化开发
①从上一项开发活动接受该项活动的工作对象作为输入
②利用这一输入,实施该项活动应完成的工作内容。
③给出该项活动的工作成果,作为输出传给下一项开发活动。
④对该项活动的实施工作成果进行评审。
3、适用:需求明确或很少变更的项目;开发团队比较弱的情况;有厚实的行业实践基础;整批一次性交付有利于干系人。
图来自蓝皮书,下同
螺旋模型
螺旋模型是一个演化软件过程模型将原型实现的迭代特征与线性顺序(瀑布)
模型中控制的和系统化的方面结合起来。
使得软件的增量版本的快速开发成为可能。
①在螺旋模型中,软件开发是一系列的增量发布。在早期的迭代中,发布的增量可能是一个纸上的模型或原型;在以后的迭代中,被开发系统的更加完善的版本逐步产生;
②四阶段(四个象限):制订计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析,特别适用于庞大而复杂的、高风险的系统。
迭代模型
4、迭代式开发模型水平方向为时间维,分四个阶段:初始、细化、构造、移交,核心工作流从技术角度描述迭代模型的静态组成部分,包括:业务建模、需求获取、分析与设计、实现、测试、部署。图中的阴影部分描述了不同的工作流,在不同的时间段内工作量的不同,几乎所有的工作流在所有的时间段内均有工作量,只是大小不同而已。
各阶段的主要任务如下。
①初始阶段:系统地阐述项目的范围,选择可行的系统构架,计划和准备业务案例。
②细化阶段:细化构想,细化过程和基础设施,细化构架并选择构件。
③构造阶段:资源管理、控制和过程最优化,完成构件的开发并依评价标准进行测试,依构想的验收标准评估产品的发布。
④移交阶段:同步并使并发的构造增量集成到一致的实施基线中,与实施有关的工程活动根据完整的构想和需求集的验收标准评估实施基线。
在迭代式的过程中,每个阶段都包括不同比例的所有活动重复的循环,属于“完善型迭代”
适用于:不能完整定义产品的所有需求、计划多期开发的、在开发早期需求可能有所变化、需要降低项目复杂性的、部分交付有利于千系人的项目。
Ⅴ模型
Ⅴ模型左边的分别代表了需求分析、概要设计、详细设计、编码。右边的代表单元测试、集成测试、系统测试与验收测试
①单元测试:验证软件单元是否按照单元规格说明(详细设计说明)正确执行,即保证每个最小的单元能够正常运行。单元测试一般由开发人员来执行,首先设定最小的测试单元,然后通过设计相应的测试用例来验证各个单元功能的正确性。
②集成测试:检査多个单元是否按照系统概要设计描述的方式协同工作主要关注点是系统能够成功编译,实现了主要的业务功能,系统各个模块之间数据能够正常通信等。
③系统测试:验证整个系统是否满足需求规格说明。
④验收测试:从用户的角度检查系统是否满足合同中定义的需求或者用户需求。
V模型的特点:
1.Ⅴ模型体现的主要思想是开发和测试同等重要,左侧代表的是开发活动,而右侧代表的是测试活动。
2.V模型针对毎个开发阶段,都有一个测试级别与之相对应。
3.测试依旧是开发生命周期中的阶段,与瀑布模型不同的是,有多个测试级别与开发阶段对应。
4.Ⅴ模型适用于需求明确和需求变更不频繁的情形。
原型法
原型法认为在很难一下子全面准确地提岀用户需求的情况下,首先不要求一定要对系统做全面、详细的调查、分析,而是本着开发人员对用户需求的初步理解,先快速开发一个原型系统,然后通过反复修改来实现用户的最终系统需求。
原型的特点:①实际可行②具有最终系统的基本特征③构造方便、快速,造价低。
原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的,系统分析、设计与实现都是随着对一个工作模型的不断修改而同时完成的,相互之间并无明显界限,也没有明确分工。系统开发计划就是一个反复修改的过程。适于用户需求开始时定义不清、管理决策方法结构化程度不高的系统开发,开发方法更易被用户接受;但如果用户配合不好,盲目修改,就会拖延开发过程。
可以将原型分类:①抛弃型原型②进化型原型
敏捷开发模型
1.是一种以人为核心、迭代、循序渐进的开发方法,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。
2. Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发(三个角色、三个物件、四个会议)
3.特点:较小增量、快速迭代(2~4周)、变更驱动、每次交付最有价值成果。
4.适用:小型或中型软件开发团队并且客户的需求模糊或多变。
小结
模型 | 适用范围 |
---|---|
瀑布模型 | 面向过程的结构化方法;需求明确、很少变更、行业基础厚实、低风险、计划驱动 |
螺旋型 | 需求不明确的新开发;大型复杂项目;高风险、风险驱动 |
迭代模型 | 不能完整定义所有需求;计划多期开发需要降低项目复杂性的; |
增量模型 | 已有产品升级或新版本开发;对所开发的领域熟悉且已有原型; |
敏捷开发 | 小型或中型软件开发团队,井且客的需求模糊或多变。变更驱动 |
原型化模型 | 需求不清;结构化要求不高; |
统一过程模型 | 大型软件项目和开发团队;用例驱动 |
喷泉模型 | 面向对象;对象驱动; |
V模型 | 需求明确和需求变更不频繁的传统信息系统 |