软件项目管理复习专用

一类是连续不断的、周而复始的活动，人们称之为运作，如企业日常的生产产品的活动。

另一类是临时性、一次性的活动，人们称之为项目。如企业的技术改造活动，一项环保工程的实施。

项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。

典型的例子

• 建造一座大楼、一座工厂或一座水库
• 举办各种类型的活动，如一次会议、一次旅行、一次晚宴、一次庆典和体育传播等
• 新企业，新产品，新工程的建设和开发
• 城市道路设施建设—厦门翔安隧道BRT
• 某 区领导选举
• 博导带领研究生解决某个研究课题
• 新建 络系统或开发一套管理软件
• 实施一种全新的经营程序或流程

下列选项中属于项目的是（ ）

A.上课

B. 区保安

C.野餐活动

D.每天的卫生保洁

项目的三重约束

时间功能费用

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rPjgpChq-1667011895468)(C:UsersxiaozhaoAppDataRoamingTyporatypora-user-imagesimage-20221029093511511.png

可以這樣描述，为了实现项目的目标，首先需要设定的项目工作和管理范围，即项目范围管理what to do

为了正确实施项目，需要对目标进行分解，对项目的时间、质量成本三大目标分解，即时间管理（when目成本管理（how much项目质量管理（how good/p>

项目会过程中，需要投入足够的人力、物力资源，即项目的人力资源管理、项目采购管理

为了对项目团队中人员进行管理，让大家目标一致地完成项目，需要沟通，即沟通管理，集成管理协调各方面

5个标准化过程组

关注过程

软件项目管理过程组

软件项目管理活动

• 定义项目范围
• 分析风险
• 确定资源
• 资金和工作量预算
• 制定时间计划

软件项目管理过程

项目初始—项目计划—项目执行控制—项目结束

项目初始：项目确立-》生存期

项目计划：范围计划–》成本计划–》进度计划–》质量计划–》配置管理计划–》人员与沟通计划–》风险计划–》合同计划–》集成计划

管理涉及的范围

高效的软件项目管理集中于4个p上：人员、产品、过程和项目

人员—一个成功项目最重要的因素

产品—建立的软件

过程—框架活动集合完成工作的软件工程任务

项目—所有需要做的工作，以使一个产品变成现实

顺序不是任意的

THE MOL MODEL领导能力

• Motivation：激励，通过奖惩（恩威并施）孤立技术人员发挥其最大才能的一种能力
• Organizition：组织，形成能够将最初概念转换成最终产品的现有过程的能力
• Ideas or Innovation：思想或创新，必须在特定软件产品或应用系统的岳素霞工作，也能鼓励人们去创造并让人感到有创造新的一种能力

项目负责人的四个关键品质

• 解决问题
• 管理品质
• 成就
• 影响和团队建设

项目经理可使用的九条影响和能力

1. 权利：发命令的正当登记权利
2. 任务：感知到的项目经理影响员工后来工作分配的能力
3. 预算：感知到的项目经理授权他人使用自由支配资金能力
4. 提升：提拔员工的权利
5. 资金：给员工涨工资和增加福利的权利
6. 处罚：感知到的项目经理实施处罚的能力
7. 工作挑战：根据员工完成一项特定任务的喜好来安排工作的能力
8. 专门技术
9. 友谊

选择软件项目团队时应该考虑以下7个因素

• 待解决问题的难度
• 开发程序的规模，以代码行或者功能点来度量
• 团队成员需要共同工作的实践
• 能够对问题做模块化划分的程度
• 待开发系统的质量要求和可靠性要求
• 交付日期的严格程度
• 项目所需要的友好交流的程度

定义软件组织结构时，我们有哪些选择mark>

• 开放式范性：试图以一种具有封闭式范性的控制性，又包含随机式范性的创新型的方式来组织团队
  • 集控制性和创新性于一体
  • 协调工作
  • 良好沟通
  • 根据团队整体意见决策
  • 适用于
    • 解决复杂问题
    • 效率相对其他方式较低

你被指派为大型软件产品公司项目经理。你的工作是管理该公司已被广泛使用的字处理软件的新版本开发。

因为必须获得新的收益，已经规定了紧迫的最后期限，并对外公布。

你会选择哪种团队结构么p>

你会选择哪种（些）软件过程模型么p>

考虑到时间压力和对工作的熟悉程度，开放式的团队结构可能是最好的（然后，封闭式的团队也可能很好地工作）这项工作的期限驱动性表明了增量过程模型

• 同步式范式：依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流
• 封闭式范性：
  • 主程序团队，最早的软件团队组织
  • 适用范围：开发的软件与过去做过的产品相似，难以进行创新型工作

在一个信息系统组织中，你被指派为项目经理。你的工作是开发一个应用程序，该程序类似于你团队以前已经做过的项目，只是规模更大更复杂一些，需求已经由用户写成文档。

你会选择哪种团队结构么p>

你会选择哪种（些）软件过程模型么p>

封闭示范性很好，由于需求定义的很好，因此可以将需求划分并分配给子团队。项目的规模也有利于CD团队，由于没有讨论时间表，我们认为交货日期是合理的，因此可以使用线性顺序过程模型（以前做过的工作）然后，迭代模型（例如螺旋）也是一种很好的可能性

• 随机性范式
  • 松散组织团队
  • 团队工作以来个人的主动性
  • 工作方式：创新的无政府状态
  • 适用范围
    • 当需要创新和技术突破时，有优势
    • 当需要有序执行才能完成工作，该结构陷入困境

你被指派为小型软件产品公司项目经理。你的工作是开发一个有突破性的产品，该产品结合虚拟现实的硬件和高超的软件。

因为家庭娱乐市场竞争激烈，完成这项工作的压力很大。

你会选择哪种团队结构么p>

你会选择哪种（些）软件过程模型么p>

考虑到模糊的需求和工作的实验性质，随机范式团队结构可能是唯一可行的选择。应该使用原型方法或进化过程模型

软件团队有哪4种组织结构，每种结构适用的场景

避免团队毒性

• 狂乱的工作氛围使团队成员浪费精力，同时也使他们在工作中表现出毫无目的性。

• 由个人、商业和技术因素引起的重大挫折导致团队成员间产生摩擦。

• “碎片式的或协调很差”的软件过程、缺乏定义的或选择不合适的过程模型都会成为成功路上的路障。

• 不清晰的角色定义导致缺乏责任，并相互指责。

• “接连不断地重蹈覆辙” 使团队成员失去信心并降低斗志。

敏捷团队

• 团队成员必须相互信任。

• 团队成员的技能分布必须适合于要解决的问题。

• 如果要保持团队的凝聚力，必须将坚持个人己见的人员排除于团队之外。

• 团队是 “自组织的”

• 自适应团队结构

• 使用Constantine 提出的随机、开放和同步式的范型

• 相当大的自主权

产品

产品范围

• 项目环境：要开发的突然间如何适应于大型的系统、产品或业务环境，该环境下要施加什么约束
• 信息目标：软件要产生那些客户可见的数据对象作为输出，需要什么数据对象作为输入li>
• 功能和性能：软件要执行什么功能才能将输入数据变换成输出数据需要满足什么特殊的性能需求

软件项目范围在管理层和技术层都必须是无歧义的和可理解的

重要例题

张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型，并专门招聘了熟悉 络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写的部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100％。

【问题1】

对张工的行为进行点评点和不足）

【问题2】

请从项目范围管理的角度找出该项目实施过程中的主要管理问题p>

【问题3】

请结合你本人实际项目经验，指出应如何避免类似问题p>

【问题1】(10分)

(1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2分)

(2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付时的重大变更。(2分)

(3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。(2分)

(4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。(2分)

(5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。(2分)

【问题2】(9分)

(1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。(3分)

(2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。(3分)

(3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。(3分)

【问题3】(6分)

有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是重要的。对于本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方法来辅助需求的定义，避免范围定义不清晰的问题。

在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范围，坚决避免需求的再次变更。

问题分解过程：

拼写检查

语句文法检查

大型文档引用检查

大型文档中章节引用确认

如果继续分解对于指定计划更有利，则每个子功能还可继续分解。

过程Process

在项目计划建立前，必须选择一个过程模型以适合待开发的软件项目

过程分解举例采用通用过程框架

在communication沟通阶段

对于小的、简单地项目可以分解为如下工作任务

• 列出需澄清的问题列表
• 与客户见面说明需要澄清的问题
• 共同制定范围陈述
• 和所有人一起评审范围陈诉
• 根据需要修改范围陈述

项目Project

项目正处于危险状态的信 ，当……

• 软件人员不了解客户的需求。

• 产品范围定义很糟糕。

• 没有很好地管理变更。

• 所选的技术发生了变化。

• 业务需求发生了变化 [或未能很好地定义]。

• 截止日期是不切实际的。

• 客户抵制。

• 失去赞助 [或从来没有真正得到过赞助]。

• 项目团队缺乏具有合适技能的人员。

• 管理者 [和开发人员] 没有很好地利用已学到的最佳实践和经验。

• 在正确的基础上开始工作。首先努力(非常努力) 地正确理解要解决的问题，然后为每个参与项目的人员设置现实的目标和期望。

• 保持动力。为了维持动力，项目经理必须采取激励措施使人员变动量保持绝对最小，团队应该重视它完成的每项任务的质量，而高层管理应该尽可能不干涉团队的工作。

• 跟踪进展。对于软件项目而言，当工作产品 (如模型、源代码、测试用例集) 正在产生或被认可 (通过技术评审) 时，跟踪项目进展要作为质量保证活动的一部分。

• 做出英明的决策。 总体上，项目经理和软件团队的决策应该 “保持项目的简单性”。

• 进行事后分析。 建立统一的机制，从每个项目中获取可学习的经验。

W5HH原則

• 为什么要开发这个系统p>

• 将要做什么p>

• 什么时候做p>

• 由谁W来负责p>

• 他们的机构组织位于何处p>

• 如何完成技术工作和管理工作p>

• 每种资源需要多少 (例如，人、软件、工具、数据库)p>

总结

四个P对软件项目管理有重大影响。

必须将人员组织成有效的团队

产品要求必须划分为其组成部分

该流程必须适合人员和产品

项目的组织方式必须使软件团队能够成功。