软件项目管理知识点整理好.pdf
第1章、1、什么是项目 项目（Project）,是指一系列独特的，复杂的并相互关联的活动。这些活动有着一个明确的目标或目的,必须在特左的时间、预算、资源限左内，依据规范完成。项目参 数包括项目范围、质量、成本、时间、资源。2、软件项目的特征（1）复杂性：了解软件产品中每一美元、没一英镑、每一欧元是如何花费的,要比其它工程制品更复杂。2）一致性:通常，传统的工程师会用物理系统，以及水泥、钢铁这样的物理材料来工作，这些物理系统有一沱的复杂性,但都服从一左的物理定律。而软件开发者，必须 与客户需求保持一致。不仅因为从事该工作的人员可能不是同一个人，而且对于组织来说，由于集体记忆会有差错、内部交流不够通畅，决策也会有失误。（3）可变性：软件可以方便的修改，这是软件的长处之一。然而。软件系统一旦与物理系统相连，一有必要，就要改变软件来适应其它组件,而不是改变其他组件来适应 软件。所以，相对于其他组件,软件系统可能要经常变更。（4）不可见性：有形制品（比如桥）的建造过程,可以立即看到，而软件的进展不能立即可见。3、课本第八页的重要概念（1）检查点：指在规左的时间间隔内对项目进行检査，比较实际现状与计划之间的差异，并根据差异进行调整。可将检査点视作一个固左采样的时间点，时间间隔，根据 项目周期长短不同而变化，频率过小失去意义，频率过大增减管理成本。常见的间隔，每周一次，项目经理需要召开例会并上交周报。（2）里程碑：是完成阶段性工作的标志，不同类型的项目里程碑不同。在软件项目的生命周期里，重要的里程碑节点是相同的,如项目立项、项目启动、需求分析、系 统设计、软件编码、系统试运行、项目验收这些阶段完成时间均可作为里程碑。3）基线：指一个、一组配宜项在项目生命周期的不同时间点上，通过正式评审进入正式受控的一种状态。软件项目中，需要的基线、配置基线等都是一些重要的项目 阶段里程碑，但相关交付物要通过正式评审并作为后续工作的基准和出发点。基线一旦建立，变化要受到控制。4、SMART 原则（1）绩效指标必须是具体的（Specific）（2）绩效指标必须是可以衡量的（Measurable）（3）绩效指标必须是可以达到的（Attainable）（4）绩效指标是实实在在的，可以证明和观察（Realistic）（5）绩效指标必须具有明确的截I匕期限（Time-bound）5、PMBOK 项目管理知识体系,指项目管理知识体系的意思，具体是美国项目管理协会（PMI）对项目管理所需的知识、技能和工具进行的概括性描述 PMB0K的5个阶段：项目启动、项目规划、项目执行、项目监控与项目收尾 PMB0K的九大知识领域：项目集成管理、项目范囤管理、项目时间管理、项目成本管理、项目人力资源管理、项目交流管理、项目风险管理、项目质量管理、项目采 购管理 6、软件项目经理扮演的角色 第2章 1、什么是需求工程 需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求,帮助分析人员理解问题并左义目标系统的所有外部特征的一门学科。需求工程通过合适的 工具和记号系统地描述待开发系统及其行为特征和相关约朿，形成需求文档,并对用户不断变化的需求演进给予支持。2、需求工程的类型（1）业务需求：表示组织或客户高层次目标（2）用户需求：描述的是用户的目标，或用户要求系统必须能完成的任务。（3）效用需求：规定开发人员必须在产品中实现的软件效用，用户利用这些效用来完成任务,满足业务需求（4）非效用需求 3、什么是需求分析 需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的效用、性能、可靠性等具体要求，将用 户非形式的需求表述转化为完整的需求能义,从而确定系统必须做什么的过程。4、需求分析的任务是什么 问题识别：双方确立对问题的综合需求，这些需求包括效用需求，性能需求，环境需求，用户界而需求。分析与综合，导岀软件的逻辑模型 编写文档：包括编写需求规格说明书，初步用户使用手册，确认测试计划，修改完善软件开发计划 5、用户需求说明书与需求规格说明书的主要区别（1）前者主要采用自然语言（和应用领域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。（2）后者是前者的细化。更多的采用计算机语言和图形符号来刻画需求，是即将开发的软件产品的需求，产品需求是软件系统设计的宜接依据。6、如何进行需求变更 7、需求变更的管理流程（1）提出变更申请（2）审批（3）修改需求文档（4）重新进行需求确认（5）变更结朿 8、需求获取的方法（1）用户访谈（2）用户调査（3）现场观摩（4）文档考古（5）建立联合分析小组（6）原型法（7）模型驱动（8）基于上下文的方法 第3章 1/1 1、徳尔菲方法 徳尔菲法也称专家调查法，是一种采用通讯方式分别将所需解决的问题单独发送到各个专家手中，征询意见，然后回收汇总全部专家的意见，并整理岀综合意见。随后将 该综合意见和预测问题再分别反馈给专家，再次征询意见，各专家依据综合意见修改自己原有的意见,然后再汇总。这样多次反复，逐步取得比较一致的预测结果的决策 方法。2、软件项目成本估算 成本估算，是指对完成项目各项活动所必须的各种资源的成本做出的估算。估算计划活动的成本，涉及估算完成每项计划活动所需的资源，包括人力资源，设备，材料，服 务，设施和特殊条目，如通货膨胀准备金和应急准备金等的近似费用 3、软件项目的规模估算 软件项目的规模是影响软件项目成本和工作量的主要因素。在基于代码行（loc,line of code）和效用点（function point）的估算方法中，利用代码行和效用点来表 示软件系统的规模，并通过对软件项目规模的估算进而来估算软件项目的成本和工作量 4、软件项目的费用构成（1）咨询费，指软件项目立项前期，请专业机构或者专家进行技术咨询、可行性分析、需求分析，造价评估、方案设计、项目招标代理等方面工作所发生的费用（2）建设费包括支付给软件开发商的进行软件开发、实施、维护等方而工作的费用。主要依据工作量（完成该项目需要投入的人力，以人月度量）和人月成本进行估 算（3服务费：验收测试费工程监理费数据处理费附加费需求变更估算 第4章 1、软件项目管理的三要素及其之间的关系 成本、质量和进度 进度是三要素之一，它与成本、质量二要素有着辨证的有机联系 2、WBS基本要素（1）层次结构 WBS结构的总体设汁对于一个有效的工作系统来说，是个关键。结构应以等级状或“树状”来构成，使底层代表详细的信息，而且其范用很大，逐层向上。（2）编码设计 工作分解结构中的每一项工作或者称为单元都要编上号码，用来唯一确定项目工作分解结构的每一个单元，这些号码的全体称为编码系统。（3）报告设计 设计报告的基本要求，是以项目活动为基础产生所需的实用管理信息，而不是为职能部门产生英所需的职能管理信息或组织的职能报告。3、甘特图的画法（1）明确项目牵涉到的项活动、项目。内容包括项目名称（包括顺序）、开始时间、工期，任务类型（依物决圮性）和依赖于哪一项任务。（2）创建甘特图草图。将所有的项目按照开始时间、工期标注到甘特图上。（3）确定项目活动依赖关系及时序进度。使用草图，并且按照项目的类型将项目联系起来，并且安排。此步骤将保证在未来计划有所调整的情况下，各项活动仍然能够按照正确的时序进行，也就是确保所有依赖性活动能并且只能在决左性活动完成之后按计划展开，同时 避免关键性路径过长。（4）计算单项活动任务的工时量。5）确左活动任务的执行人员及适时按需调整工时。（6）计算整个项目时间。4、计划评审及技术 计划评审技术（Program Evaluation and Review Technique,PERT）是50年代末美国海军部在研制北极星潜艇系统时为协调3000多个承包商和研究机构而开发的,其理论基础是假设软件项目持续时问以及整个项目完成时间是随机的，且服从某种概率分布。PERT可以预计整个项目在某个时间内完成的概率。5、关键路径发 关键路径法（Critical Path Method,CPM）是一项用于确定软件项目的起始时间和完工时间的方法。CPM是一种最常用的数学分析技术，即根据指左的网络顺序逻辑关 系和单一的历时估算，计算每一个活动的单一的、确定的最早和最迟开始和完成日期。6、网络图法 网络图是以箭线和节点来表示各项工作及流程的有向、有序的网状图形。网络图按其表示方法的不同，又分为双代号（Active On the Arrow,AOA）网络图和单代号（Activity On Node,AON）网络图（又称前导图法（Precedence Diagramming Method,PDM）。双代号网络图中的工作由带有两个节点的箭线来表示，单代号网络图中的工作用节点表示。7、里程碑法 里程碑法（M订estone）亦称可交付成果法，是在横道法上或网络图上标示出一些关键事项。第5章 1、什么是软件项目的风险 软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。分为（1）软件项目风险、（2）软件过程风险和（3）软件产品风险 2、什么是软件项目的风险管理 软件风险管理是对影响软件项目、过程或产品的风险进行预计和控制的实践过程。从目标逆向思维可发现软件风险。首先，左义目标。然后根据不确定性、损失和时间 来描述风险。3、什么是CMMI 软件能力成熟度模型集成（Capability Maturity Model Integration,CMMI）是由美国卡内基梅隆大学软件工程研究所（Software Engineering Institute,SEI）在 CMM基础上发展而来。4、软件风险的两个特征 不确龙性：刻划风险的事件可能发生也可能不发生，没有100%发生的风险。损失：如果风险变成了现实，就会产生恶性后果或损失 5、识别风险 风险识别，就是企图采用系统化的方法,识別某特立项目已知的和可预测的风险。6、定性风险分析，左量风险分析（1）定性风险分析是评估已识别风险的影响和可能性的过程。这一过程用来确怎风险对项目目标可能的影响，对风险进行排序。利用数据精度排队、项目假设检验等 四种方法进行分析。它在明确特定风险和指导风险应对方而十分重要。（2）定量风险分析是对通过左性风险分析排出优先顺序的风险进行量化分析。尽管有经验的风险经理有时在风险识别之后直接进行左量分析，但左量风险分析一般在 定性风险分析之后进行。重复进行定量风险分析反映出来的趋势可以指岀需要增加还是减少风险管理措施，它是风险应对计划的一项依据,并作为风险监测和控制的组 成部分 7、应对风险的基本措施 1/1 1风险规避 风险规避是改变项目计划来消除特泄风险事件的威胁。通常情况下我们可以采用多种方法来规避风险。例如,对于软件项目开发过程中存在的技术风险，我们可以 采用成熟的技术，团队成员熟悉的技术或迭代式的开发过程等方法来规避风险;对于项目管理风险我们可以采用成熟的项目管理方法和策略来规避不成熟的项目行理带 来的风险;对于进度风险我们可以采用增量式的开发来规避项目或产品延迟上市的风险。对于软件项目需求不确泄的风险我们可以采用的原型法来规避风险。2、风险转移 风险转移是转移风险的后果给第三方，通过合同的约垃，由保证策略或者供应商担保。软件项目通常可以采用外包的形式来转移软件开发的风险，例如发包方面对一 个完全陌生领域的项目可以采用外包来完成，发包方必须有明确的合同约立来保证承包方对软件的质量，进度以及维护的保证。否则风险转移很难取得成功。3、风险减轻 风险减轻是减少不利的风险事件的后果和可能性到一个可以接受的范国。通常在项目的早期采取风险减轻策略可以收到更好的效果。例如，软件开发过程中人员流 失对于软件项目的影响非常严重，我们可以通过完善工件，配备后备人员等方法来减轻人员流失带来的影响。4、风险接受 准备应对风险事件，包括积极的开发应急计划，或者消极的接受风险的后果。对于不可预见的风险，例如不可抗力;或者在风险规避，风险转移或者风险减轻不可行,或者上述活动执行成本超过接受风险的情况下采用。第6章 1、什么是配置管理 软件配宜管理（Software Configuration Management,SCM）就是在软件开发过程中管理软件的配世。这里的配置，是指构成软件产品的各种原始部件,包括源程序、数 据文件、设计文档、用户文档,及其组织关系（如目录结构）。相应的管理包括管理这些部件的产生、修改、提取与发布，以保证整个产品的正确性、完整性，产品部件 的一致性 2、什么是配垃 意为多个部件集合在一起形成一个整体 3、配置管理解决的问题（1）完善的软件配置管理系统有助于规范开发人员的工作流程,明确角色分工，晴楚记录代码的任何修改，同时又能加强代码修改时的交流协作（2）完善的配宜关联系统也有助于项目经理更好地了解项目的进度、开发人员的负荷、工作效率与产品质捲状况、交付日期等关键信息 4、软件和配這项 软件的脆弱性和易变性的根源在于软件的复杂性，大型软件通常由数以千万个文件组成，这些文件包括以下内容：（1）建义产品效用、描述设计实现细节的设计文档。（2）规定产品开发过程、进度计划和交付合同等项目管理文档。（3）各种语言的源程序文件，这是数量最多、最关键的文件。（4）各种格式的数据文件，包括数字、文字、图片、视频等。（5）构造生成的中间文件、可执行文件和可安装文件。（6）实现源程序文件到可执行文件和可安装文件转换的构造、包装脚本。（7）该软件所依赖的其他文件：包括开发运行工具、硬件环境说明或相关软件说明。配置项：软件系统中所有这些类型的文件，都可称为软件配宜管理的管理对象,而且是基本管理单元，即配置项（Configuration Item,CI）,5、配置管理中的角色有哪些，各自的职责是什么（1）配置管理负责人 配置管理负责人的工作，包括以下内容：为组织机构规划配宜管理方案，将机构或组织对配宜管理的需求转换为实际的生产过程、工具和操作规范。部署和更新配置管理工具。跟踪机构或组织的配程管理执行情况，确保所定的流程被严格地执行。为管理层提供配垃管理状态报告、数据分析结果和相关改进建议。（2）配置库管理员 配豊库管理员负责建立产品配程库，并维护每个配宜库的内部完整性与存储空间的安全性。配置库管理员的工作范用,主要有以下几方面：建立配宜库。创建并维护组成配宜库的元数据（非配置项数据）。对配置库的使用者进行日常支持。从配這库中提取配宜项状态信息与其他过程度量信息，以供配置报告和审计（3）配置控制委员会 配置控制委员会全而负责配置项的变更控制,因此又称为变更控制委员会。配巻控制委员会有一位专职的主席，负责协调和决策，委员会的成员则由项目经理、产品经理、客户代表、以及质量保证负责人等项目中的重要人员担当。配置控制委员会的主要工作，有以下几点：评估变更请求,批准或否决所请求的变更。协调变更谙求的执行过程，安排合理的优先级。跟踪变更请求的执行状况，并向变更请求的提岀者及相关人员提供反馈。决泄产品基线的创建和使用策略，确定对外发布的基线。第7章 1、合同的概念 合同（Contract）又称契约,有广义与狭义之分。广义上的合同，是两个以上当事人之间变动民事权利义务的双方民事法律行为。狭义上的合同，专指债权合同，即当事人之间以设左、变更或消火债权关系为目的的双方民事法律行为。2、什么是技术合同 技术合同是法人之间、法人和公民之间、公民之间以技术开发、技术转让、技术咨询和技术服务为内容，明确相互权利义务关系所达成的契约。3、签订合同时应注意的问题（1）规泄项目实施的有效范围（2）合同的付款方式（3）合同变更索赔带来的风险（4）系统验收的方式（5）维护期问题 1/1 4、软件项目合同条款分析 1与软件产品有关的合法性条款（1）软件的合法性条款 软件的合法性，主要表现在软件著作权上。2）软件产品的合法性 软件产品的合法性，主要是指该产品的生产、进口、销售己获得国家颁布的相应的登记证书。2 与软件系统有关的技术条款 1）与软件系统匹配的硬件环境（2）软件匹配的数据库等软件系统（3）软件的安全性、容错性、稳泄性的保证 3 软件适用的标准体系方而的条款 软件肯定会涉及国家、行业的部分标准，或者国际质量认证标准。软件是否符合相关的标准规范，对客户单位是非常重要的，特别是对一些特殊行业的生产性企业，是能否进行生产的必要条件。4 软件实施方而的条款 项目实施方而的条款是合同的主体部分，通常包括项目实施定义、项目实施目标、项目实施计划、双方在项目实施中的权利与义务、项目实施小组及其工作任务、工作 原则与工作方式、项目实施的具体工作与实施步骤、实施的修改与变更、项目实施时限、验收等主要内容。5 技术培训条款 技术培训，是软件项目实施成功的重要保障和关键的一步。签约双方都享有权利，并承担义务。6 支持和服务 售后技术支持和售后服务，是软件提供商的法眾义务，同时也是企业提高产品市场竞争力的重要手段。软件产品的免费服务的项目。免费维修的实现。可以约定的收费服务项目。软件提供商采用的售后技术支持与服务的方式。技术支持与服务的及时性条款。7 管理咨询条款 如果在项目实施中，软件提供商还承担了管理咨询的业务,则在合同中还应有关于管理咨询的条款。管理咨询条款包括了诊断、交流、分析、提供方案和规章制度、培 训、指导和咨询等各个环节。5、合同收尾注意的问题 项目合同当事双方在依照合同规定履行了全部义务之后，项目合同就可以终结了。项目合同的收尾需要伴随一系列的项目合同终结管理工作。项目合同收尾阶段的管理活动包括产品或劳务的检査与验收，项目合同及其管理的终ih（这包括更新项目合 同管理工作记录，并将有用的信息存入档案），等等。需要说明的是，提前终止合同是合同收尾的特殊情况 第8章 1、谷歌认为最优秀的项目经理具有的八个特征（1）是一个好的指导者。（2）富有生产力，以结果为导向。（3）帮助员工在事业上取得进步。（4）关注团队成员的成功和个人生活状况。（5）具有淸晰的眼光，并能够为团队制左明确的战略。（6）具有重要的技能，能够帮助本人为团队提供意见。7）是一个好的交流者，可以倾听他人的意见,并与他人共享信息。8 能够赋予工作团队权力，而不是事无巨细地参与各种微观管理。2、马斯洛人类需求5层次模型 3、如何组建团队 4、交流管理 第10章 1、敏捷软件开发宣言 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观:个体和互动高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 响应变化高于遵循计划 也就是说,尽管右项有其价值，我们更重视左项的价值。敏捷宣言强调的敏捷软件开发的四个核心价值是:个体和互动高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 1/1 响应变化高于遵循计划1 敏捷选择提出的12条原则已经应用于管理大量的业务以及与IT相关项目中,包括商业智能（BI）。12原则包括:（1）通过早期和连续型的髙价值工作交付满足“客户”o（2）大工作分成可以迅速完成的较小组成部门。乍I我实 当低层需求 求就会出现/枕会石求 全需求 生理需求（3）识别最好的工作是从自我组织的团队中出现的，（4）为枳极员工提供他们需要的环境和支持,并相信他们可以完成工作。（5）创建可以改善可持续工作的流程。（6）维持完整工作的不变的步调。（7）欢迎改变的需求,即使是在项目后期。（8）在项目期间每天与项目团队和业务所有者开会。（9）在泄期修正期，让团队反映如何能髙效,然后进行相应地行为调整。（10）通过完车的工作量计量工作进度。（11）不断地追求完善。（12）利用调整获得竞争优势。2、敏捷方法的核心思想（1）敏捷方法是适应型,而非可预测型（2）敏捷方法是以人为本，而非以过程为本（3）迭代增量式的开发过程 1/1
