项目管理第二版骆珣pdf，软件项目管理第二版pdf
求，机械工业出版社教育服务网，在线课件下载账号！下载项目管理专业所有课程课件！
你想要什么书课件？自己申请下载。
软件项目的管理流程
导语：关于软件项目的管理流程，我们来看看。以下是我收集整理的软件项目管理流程，供您阅读参考。
一.风险评估
软件风险是指整个项目周期所涉及的问题，如成本预算、开发进度、技术难度、经济可行性、安全管理等。以及这些问题对项目的影响。项目的风险和可行性成反比。可行性越高，风险越低。项目的可行性分为四个方面：经济可行性、商业可行性、技术可行性和法律可行性。软件项目风险分为六个方面：产品规模风险、需求风险、相关性风险、管理风险和安全风险。
1.产品规模风险
项目的风险与产品的规模成正比。产品规模越大，问题就越突出。尤其是估算产品规模的方法、复用软件的数量、需求变化的数量等因素都与产品风险密切相关：
(1)估算产品规模的方法
(2)产品规模估计的可信度
(3)产品规模与之前产品规模平均值的偏差
(4)产品的用户数量
(5)有多少软件被复用？
(6)产品需求发生了多大的变化？
2.需求风险
许多项目在确定需求时面临一些不确定性。当这些不确定性在项目前期被容忍，在项目进展中无法解决时，这些问题就会对项目的成功构成极大的威胁。如果不控制与需求相关的风险因素，很可能会生产出错误的产品或者预期的产品构造不佳。每种情况对产品都可能是致命的。这些风险因素是：
(1)对产品缺乏清晰的了解
(2)缺乏对产品需求的认识
(3)需求分析过程中客户参与不足。
(4)没有优先需求
(5)由于需求不确定而产生的新市场。
(6)需求的变化
(7)缺乏有效的需求变更管理流程。
(8)缺乏对需求变化的相关分析等。
3.相关性风险
很多风险是由项目的外部环境或者因素的相关性造成的。为了控制外部相关风险，缓解策略应包括可能性计划，以便从第二资源或协作工作资源中获得必要的组件，并检测潜在的问题。与外部环境相关的因素包括：
(1)顾客提供的物品或信息
(2)互动成员或互动群体的依赖性
(3)内部或外部分包商之间的关系
(4)有经验人员的可用性
(5)项目的可重用性。
4.技术风险
软件技术的快速发展和缺乏有经验的工作人员意味着项目团队可能会因为他们的技能而影响项目的成功。在早期，识别风险并采取适当的预防措施是解决风险领域问题的关键，如培训、聘请顾问和为项目团队招募合适的人才。关于技术，主要有以下风险因素：
(1)缺乏培训
(2)对方法、工具和技术缺乏了解
(3)缺乏应用领域的经验。
(4)不熟悉新技术的应用和开发方法
5.管理风险
虽然管理问题限制了许多项目的成功，但不要对并非所有的管理活动都包含在风险管理计划中感到惊讶。在大多数项目中，项目经理通常是编写项目风险管理计划的人。他们先天不足——，无法检查自己的错误。因此，项目的成功变得更加困难。如果我们不正视这些棘手的问题，它们很可能在项目的某个阶段影响到项目本身。当我们定义项目跟踪过程并阐明项目角色和责任时，我们可以处理这些风险因素：
(1)计划和任务的定义不充分。
(2)不了解实际项目状况。
(3)项目业主和决策者分不清。
(4)不切实际的承诺。
(5)不能与员工充分沟通。
6.安全风险
软件本身就是一个创意产品，对产品的核心技术保密非常重要。但是，一直以来，我们在软件方面的安全意识比较薄弱，软件产品的开发主要集中在技术本身，而忽视了专利的保护。软件行业的技术人员流动是非常普遍的现象。随着技术人员的流失和变动，很可能会导致产品和新技术的泄露，导致我们的软件产品被其他公司盗用，项目失败。而且软件知识产权的认定也没有明确的行业标准，这也是我们软件项目的潜在风险。
7.规避风险的方法
(1)由开发者进行诱导，可以保证需求的完整性，使其与客户的真实期望高度一致。然后，可以方便地以书面形式形成重要文档《用户需求》，避免遗漏在软件系统的后续阶段被逐渐放大而造成的损失。
(2)建立监督体系。项目开发中的任何重大决策都必须有客户的参与。在本项目中，项目监督由项目开发中的质量监督小组进行。
(3)需求变更需由统一负责人提出，并经用户需求审核组长批准。需求变化要定期而不是随时提出，开发方要做好详细记录，让客户了解需求变化的实际情况。
(4)控制系统的复杂性，过于简单的系统结构，会明显降低用户的使用率，甚至造成软件寿命过短。反之，软件结构过于灵活和通用，必然会增加软件实现的难度和系统的复杂性，从而在实现和测试阶段带来风险。适当控制系统的复杂性有利于降低开发风险。
(5)从软件工程的角度来看，软件维护成本约占总成本的55%~70%。系统越大，成本越高。对系统可维护性的轻视是大型软件系统最大的风险。在软件漫长的运营期内，业务规则一定会不断发展。解决这个问题的科学方法是在保证可维护性的前提下，不断升级软件系统，逐步扩展系统。
(6)制定应急预案。每一个开发计划至少要设置一个应急方案，以应对突发情况和未知风险。
二、成本预算
1.成本预算方法
(1)自上而下的预算方法
自顶向下预算法主要是根据中高层项目经理的管理经验对构成项目整体成本的子项目成本进行判断和估算，并将这些判断和估算的结果传递给低层经理。在此基础上，这一级的管理人员对组成项目的子任务和子项目的成本进行估算，然后继续将他们的成本估算传递给下一级，直到达到最低级别。
用这种预算方法，当上层管理者根据经验做出的成本估算分解到下层时，可能会发生下层认为上层估算不足以完成相应任务的情况。此时，下层人员可能不会表达自己的真实观点，也可能不会与上层管理者进行理性的讨论，从而获得更合理的预算分配方案。在实际操作中，他们只能默默等待高层管理者自己发现问题并改正，这样往往会给项目带来很多问题。
自上而下更适合项目启动初期，在真实成本的30%-70%之间。
Scrum采用自上而下的成本预算方法，这种方法并不是立即准确地确定成本，而是最大限度地容纳客户对未来产品要求的变化。
(2)自下而上的预算方法
自下而上的方法要求WBS仔细检查项目所有任务的时间和预算。最初，预算是针对资源的，项目经理加上适当的间接费用和利润目标，形成项目的总预算。自下而上的预算方法要求综合考虑所有涉及的任务，它更适合于项目的初始和中期阶段。它可以有准备地估算项目的成本，与实际成本相差5%~10%。
备注：WBS
WBS是项目对提交结果的分解。从提交的结果列表中，可以确定针对每个提交的结果要执行的活动。Scrum将进一步细化WBS，将一个迭代分解成一个或多个工作包，然后将工作包分解成小的开发任务。
2.确定项目支出
总成本预算是结合以下成本预算方法综合计算的开发成本：
(1)零基预算
在成本预算之初，应采用零基的计算原则，而不是采用类似于：上年总成本加20%的粗略方式来计算项目成本。
(2)硬件和软件成本、商品成本
商品成本是指服务器成本、维护成本、机房租金、光纤通信成本、软件成本等。
在计算成本时，需要考虑很多因素，比如组装硬盘需要多长时间，技术人员需要的质量，产品供应商能否提供有保证的质量，管理时是否需要额外的管理人员等。
(3)软件许可费用
(4)外包成本
使用视频、短信、移动电信业务、门户网站等子项目时。可以考虑外包，降低开发成本。
(5)人力资源成本
在计算人力资源成本时，应通过估算工作效率最高和最低的平均效率来计算人力资源的平均成本。
(6)维护成本
第三，客户沟通的过程
从客户沟通的角度来看，软件项目可以分为需求识别、方案定制、项目实施、项目完成四个不同的阶段，每个阶段有不同的沟通重点。
1.需求识别阶段
(1)文字交流
在需求识别的前期，要通过问卷调查、原型展示、界面展示、逻辑处理展示、标准化文档模板等进行全方位多角度的分析。并随时将歧义反馈给客户，以期待客户的解答。并以文字记录的形式建立需求分析书，请客户审阅需求分析书，以达到需求分析与客户真实期望高度一致的结果。
(2)业务逻辑沟通
在业务交流过程中，你要了解客户的行业语言，从而推动业务分析的进程，弥合应用需求与开发之间的鸿沟。以草图或视觉信息倡导交流，为不同层次的企业用户提供最合适的操作界面。多角度思考，以需求为中心，尤其是客户领导关注的创新性、实用性需求。
(3)需求变更的标准化管理。
需求变更在软件开发项目中是可以理解的，但是必须以标准化的方式进行管理，以避免无休止的需求变更的风险。变更必须由统一负责人提出，并经用户需求审核组长批准。需求变更要定期而不是随时提出，开发人员要做详细的文字记录，让客户了解需求变更的实际情况和开发人员所付出的成本。
2.方案定制阶段
这一阶段项目的主要任务是根据前期明确的需求、双方资源、项目启动阶段、实施时间约定、项目费用限额等，与客户共同制定可操作的项目方案。从这一阶段开始，我们将争取客户全面参与项目管理，以双方的共同利益考虑项目实施和风险规避的具体方案。
3.项目实施阶段
在这个阶段，软件项目团队应该与客户一起领导项目的实施。同时，项目组要实时评估客户满意度，通过持续改进提高客户满意度。还应要求客户参加必要的培训，并在必要时检查项目产品。在客户的需求发生变化之前，应积极与客户沟通，让客户充分了解项目的各个环节以及变化带来的影响，减少需求变化。如果客户需求发生变化，我们应该与客户一起解决由变化引起的成本、进度和质量的变化。
4.结束阶段
在这个阶段，项目成果被提交
5.售前人员的注意事项
以产品为导向的项目作为开发成果时，相关销售人员要注意：对产品的推广不能过度投入。过度承诺会给后续项目实施带来困难；一旦承诺没有兑现，也会降低客户满意度，影响以后的合作。如果有任何额外的承诺，必须以文本的形式记录下来，以便实施项目经理知道并传达给项目团队成员。
注意：在软件项目中，需要定义以下四个客户角色。
A.要明确最终使用部门和用户，了解他们现有的工作方法，让他们知道项目的目标框架，知道项目要解决哪些困难，但肯定不是全部，这样才能更好的控制项目范围。
B.要确定需求的提出者，他或他们应该能够代表最终的客户群。这类提出产品需求的客户，要有一定的技术、业务能力和权限，真实代表最终客户团队的意愿和想法，最好有IT基础，能够用IT语言描述问题和需求，便于双方沟通合作，避免歧义。
C.做一个明确的需要确认的中层领导，要把握方向。软件开发项目是为了解决实际生产或管理问题，也是领先系统建设的具体实现。作为需要确认的客户领导，需要了解高层领导的系统建设重点和方向，熟悉具体的业务和生产管理实践。如果这样的客户领导掌握并做出决策，将对企业软件开发项目的顺利进行起到非同寻常的作用。
D.应该明确谁来对成品发表意见，谁来接受。项目验收环节是项目的最后环节。如果接受项目的人在项目初期不知道需求和目标，从态度上和产品的实际使用效果上都会对验收产生负面影响，这对提供产品的企业关闭项目是非常不利的。根据实践总结，需求方和确认方对项目的验收可以促进项目的顺利完成，避免延误。
四。需求分析
1.需求分析的过程
需求过程包括两个部分：需求开发和需求管理：
(1)需求开发是开发前期的管理。与客房的沟通过程可以分为需求获取、需求分析、需求编制、需求验证四个阶段。
(2)需求管理：指软件项目开发过程中控制和维护需求协议的活动。包括变更控制、版本控制、需求跟踪和需求状态跟踪。
2.需求水平
需求层次包括四个方面：业务需求、用户需求、功能需求和非功能需求。
3.需求开发阶段的重点
(1)提取业务对象
业务对象是指系统使用的真实对象。例如，供应链管理(SCM)业务对象主要包括生产批发商、零售商、交货供应商和客户。
(2)提取业务流程
在理解业务逻辑的过程中，要列出开发的软件模块各自的功能，细化每个工作流程，深入分析业务逻辑。
(3)性能要求
在分析前期，客户应关注所开发软件的技术性能指标，如存储容量限制、运行时间限制、安全保密等。
(4)环境要求
环境是指软件平台运行的环境的要求，如硬件：模型、外部设备、数据通信接口；软件：系统软件，包括操作系统、网络软件和数据库管理系统；用途：从运营商的系统和技术水平来说，使用部门应该具备什么样的条件。
(5)可靠性要求
应根据实际运行环境要求所开发的软件投入运行后出现故障的概率。对于重要的软件，或者故障会造成严重后果的软件，应该提出更高的可靠性要求。
(6)安全和c
软件项目确立后，根据合同的规定，提出软件开发的进度要求和每一步的费用，作为开发管理的依据。
(10)发展目标要求
提前预估系统未来可能的目标，这样更容易对系统进行必要的补充和修改。
4.需求分析的任务
需求分析的主要任务是借助当前系统的逻辑模型导出目标系统的逻辑模型。流程如下：
(1)确定系统的综合需求。
(2)制定产品需求文件
(3)分析系统的数据需求。
(4)导出目标系统的详细逻辑模型。
(5)开发原型系统。
(6)从PRD中提取并编写软件需求规格说明书。
备注：SRS格式
1.简介2系统概述3。术语描述4。系统结构
5.主要功能和业务逻辑。接口要求7。整体网络设计。
8.操作环境
动词（verb的缩写）面向对象编程
1.设计原则
(1)SRP单一责任链
每个班级应该只负责一件事。
(2)OCP开合原则
软件的实体应该是可扩展的，但不可修改的。
(3)LSP替换原则
子类必须能够替换它们的基本类型。
(4)倾角取决于反演原理。
高层模块不应该依赖于低层模块，但两者都应该依赖于接口和抽象类。抽象不应该依赖于细节，细节应该依赖于对象。
(5)ISP接口隔离原理
我们应该分离胖接口，而不是强迫客户依赖未使用的接口。
2.实现UML建模
(1)业务对象的提取
(2)根据SRS、CRC等实现使用建模。
(3)实现业务序列图。
(4)建立类图，根据使用图建立对象之间的关联。
(5)绘制活动图、实现协作图和状态图。
不及物动词发展管理
1.建立项目计划
(1)设计整体架构。
根据系统的实现需求，采用合适的、成熟的框架结构。
(2)控制可扩展性。
过度扩展会增加系统的复杂性，延长开发时间；过低的扩展性会直接影响系统的二次开发和维护。控制系统的可扩展性可以提高开发效率，降低系统维护的难度。
(3)建立基础设施。
合理分配部署软硬件等基础设施所需的时间和成本。
(4)划分开发任务
使用WBS对可交付成果进行分类和划分。每个项目可以分成几个不同的阶段，每个阶段又可以分成几个工作包，这些工作包是WBS中最小的可交付成果。最后，从工作包中解析出几个开发任务列表。
(5)部署和开发进度
一个项目要根据进度分成几个开发阶段，每个阶段的开发周期一般在30~60个工作日内。在这个阶段，我们应该与客户召开咨询会议，制定产品路线图，并在开发过程中邀请客户积极参与并给予反馈。然后，根据开发难度、依赖度、重要性等条件，将该时期的开发任务划分为若干个迭代周期。
在Scrum敏捷软件开发的原则中，每个迭代任务要进一步细分为多个开发任务列表，再开发任务要分配到每个团队成员，开发时间要控制在15个工作小时以内。如果开发时间超过15个工作小时，就要考虑重新细化开发任务。开发任务建议应该由团队成员自主选择，而不是强制分配。
(5)测试项目结果
每个工作包应该同步部署测试工作，以提高项目的质量。有错误的BUG的工作包要由测试人员用文字记录下来，把错误展示给开发人员，以便开发人员及时修改。
2.管理开发团队
(1)组建团队
根据工作任务和项目时间的前提条件建立团队，根据团队职责分配人员。一般团队成员人数应控制在8至12人之间。当团队人数超过15人时，应考虑将团队分成两个独立的团队，分别负责不同的开发任务。
(2)分配开发任务。
在每个迭代周期中，
(3)监督开发进度。
在迭代前期召开会议，让团队成员了解开发进度和过程，以自选的方式分配开发任务。在此期间，可以使用MicrosoftProject等工具来记录开发过程的进度。每个工作包开发完成后，都要进行功能测试，测试结果要有文字记录。
每天开15分钟的常务会，让团队成员说明昨天完成的开发任务，当天要做的任务，开发过程中遇到的问题。并且每周末开一次例会，说明整体流程。
迭代结束时，召开冲刺会议，总结项目进展、交行已完成的任务，回顾迭代周期中遇到的问题，为下一次迭代做准备。
(4)系统测试
及时测试每个完成的工作包，确保系统的质量和性能。用文字记录测试结果，并将测试结果与绩效工资收入挂钩，用真实数据计算团队成员的绩效收入。
(5)解决发展中遇到的问题。
对开发人员进行前期培训，根据工作能力分配任务，指导团队成员的发展。遇到问题要立即在当天的常务会上提出，遇到的问题要在15个工作小时内解决，防止问题进一步扩大。
3.监督产品质量。
(1)质量需要策划、设计而不是评审。在产品建立的初始阶段，我们必须与“质量保证”部门协商，以正式文件的形式决定适当的质量策略和标准。
(2)在开发过程中使用TDD模式，提高开发质量。测试人员要用文字记录bug，和开发人员一起向开发人员演示突出的缺陷，提高修改的效率。
(3)每次迭代结束时，进行产品效果的演示，收集客户、用户和高层领导的反馈信息。在团队内部召开评审会议，分析测试结果，了解产品性能，为下一次迭代所需的改进制定计划。
4.修改项目计划。
(1)在产品标识阶段，产品功能和开发过程应以文件形式记录。当开发计划需要修改时，应与客户讨论，让他们知道计划修改对项目进度的影响。
(2)项目计划的修改应由统一负责人提出，并经用户需求审核组长批准。应该定期而不是随时做出改变。
(3)对计划变更要做详细的文字记录，让客户了解需求变更的实际情况和开发商付出的成本。
七。产品交付
1.项目的事后审计
项目开发最终完成后，对开发者来说可以算是放下工作的沉重负担，但对项目经理来说往往是关键时刻。早期的风险评估、成本预算、需求分析和软件设计都是为了将项目引导到这一时刻，此时所有的目光都将投向项目经理。你可能会发现很多琐碎的工作会在几个小时内完成。此时此刻，项目经理需要保持清醒和冷静，把最后的工作当成一个迷你项目。后期对项目进行认真的审计，对项目结果、项目团队的效率、可交付成果的价值进行分析，审计结果可以作为项目管理经验总结的一部分。
2.质量审查
在项目交付前，应将项目移交给相关“质保”部门进行质量评审，并邀请典型用户感受产品质量。
3.项目的最终交付
一般情况下，项目交付协议会在项目前期订立，项目交付方式可分为非正式验收和正式验收。一般一个项目完成后，会先进行非正式的验收，让客户体会项目的质量，并给予反馈。最后，正式的产品验收将在客户确认产品质量后以书面协议的形式进行。
4.项目的最终报告
在项目结束时，应做出项目的最终报告，该报告可视为项目的记录，但报告不必涵盖pr的所有方面
(2)项目价值评估及支持信息
(3)项目的范围
(4)项目开发过程和WBS
(5)项目会议纪要
(6)项目变更报告及变更原因
(7)与项目相关的沟通过程文件
(8)项目审计报告和客户验收报告
(9)项目成员的业绩报告
(10)项目的最终结果
软件开发项目管理的目录
传统的项目管理软件更多的是对项目的资源、任务、进度、质量进行管理，而忽略了项目管理的终极目标：3354项目成本控制。比如明软件，可以通过项目管理软件综合计算各类项目成本，包括人工、费用、材料、设备、管理共享、外包等项目成本的精细化管理。帮助财务人员轻松完成项目成本核算流程，同时帮助项目经理实时了解项目实际成本。
软件项目管理
意向仓库管理员：这个有很多功能：客户档案，员工档案，项目管理，仓库管理，统计管理………………
即所有关于软件项目管理的内容(软件项目管理第二版秦征pdf)均由全国自学教材服务网共享。更多自考教材、历年真题及答案、自考视频在线课程、自考重点复习资料，可以咨询在线客服！