软件项目管理第一章---项目管理概念

Dashesand

已于 2022-10-29 10:52:46 修改

阅读量1.3k

点赞数

文章标签：软件工程

于 2022-10-29 10:52:45 首次发布

本文链接：https://blog.csdn.net/weixin_42907150/article/details/127584252

版权

软件项目管理复习专用

项目管理概念

软件人员的职业规划

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

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

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

典型的例子

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

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

A.上课

B.社区保安

C.野餐活动

D.每天的卫生保洁

项目，由一组有起止日期的、相互协调的受控活动所组成的独特过程，该过程要达到符合包括时间、成本和资源的约束条件在内的规定要求的目标

实现项目目标的制约因素

工作范围、成本、进度计划、客户满意度

项目的三重约束

时间功能费用

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rPjgpChq-1667011895468)(C:\Users\xiaozhao\AppData\Roaming\Typora\typora-user-images\image-20221029093511511.png]

软件项目管理定义：软件项目管理是为了使软件能够按照预定的成本、进度、质量顺利完成而对成本、人员、进度、质量、风险等进行分析和管理的活动

项目管理三要素：时间成本质量

下列( )不属于项目管理的三维约束。

A.达到范围目标

B.达到时间目标

C.达到沟通目标

D.达到成本目标

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

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

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

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

5个标准化过程组

项目管理五要素

技术
方法
团队建设
信息
沟通

战术上的范围：三角形

质量、进度、成本

战略上的范围：人员问题过程

人是项目管理最宝贵的财富，软件行业更是这样。软件工程研究所专门开发了人员管理能力成熟度模型PM-CMM关键实践域

使用人必须下信任人，培养人，给他发展空间，让他看到希望，实现自身价值建立祥和、友善、互助、向上的文化氛围，技术保密、嫉妒是软件公司的大忌。

问题：项目经理的一个主要任务是发现并解决问题，明确项目的目的和范围，选择合适的解决方案，进行成本估算和进度安排，评估风险。

在项目实施过程中会出现新问题，需要及时发现和解决

过程：过程管理是项目管理的任务

不关注过程

关注过程

所谓过程做事情的一种固有方式，有经验的人对完成某件事的过程会很了解，他们知道会经历哪些步骤，每一个步骤完成什么事，需要什么样的资源，技术和工具。没有经验的人就会无从下手

上图可以形象说明过程在软件开发中的地位比如装修

关注产品上，不关注过程，不同的人采用不同过程，导致开发的产品质量不同，完全依赖个人的素质和能力

如果关注过程

不管谁来做，不管什么需求，采用统一开发过程，产品质量是一样的，可以不断提高过程质量来提供产品质量

产品的质量依赖过程能力而不是个人能力

软件过程和软件开发流程不同
软件过程不能只简单理解为软件开发流程，而是软件开发的最佳实践（流程、技术、产品、工具、角色、活动关系）是软件开发过程各方面的有机结合
软件过程包括过程定义和过程改进

软件项目管理过程

软件项目管理过程组

商品采购项目管理

软件项目管理活动

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

软件项目管理过程

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

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

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

管理涉及的范围

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

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

产品—建立的软件

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

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

顺序不是任意的

人员

（1）利益相关者

参与软件过程的利益相关者可分为五类

高级管理者：负责定义业务问题，这些问题往往对项目产生很大影响

技术管理者：必须计划、激励、组织和控制开发技术人员

开发人员：拥有开发产品或应用软件所需技能的人员

客户：产品打开发软件需求的人员以及关心项目成败的其他利益相关者

最终用户：一旦软件发布成为产品，最终用户就是直接与软件进行交互的人

再来背诵一次：高级管理者、技术管理者、开发人员、客户、最终用户

为了获得高效率，软件团队必须最大限度发挥每个人的技术和能力，这就是团队负责人地任务

（2）团队负责人

THE MOL MODEL领导能力

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

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

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

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

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

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

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

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

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

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

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

你会选择哪种团队结构？为什么？

你会选择哪种（些）软件过程模型?为什么?

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

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

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

你会选择哪种团队结构？为什么？

你会选择哪种（些）软件过程模型?为什么?

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

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

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

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

你会选择哪种团队结构？为什么？

你会选择哪种（些）软件过程模型?为什么?

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

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

避免团队毒性

狂乱的工作氛围使团队成员浪费精力，同时也使他们在工作中表现出毫无目的性。
由个人、商业和技术因素引起的重大挫折导致团队成员间产生摩擦。
“碎片式的或协调很差”的软件过程、缺乏定义的或选择不合适的过程模型都会成为成功路上的路障。
不清晰的角色定义导致缺乏责任，并相互指责。
“接连不断地重蹈覆辙” 使团队成员失去信心并降低斗志。

敏捷团队

团队成员必须相互信任。
团队成员的技能分布必须适合于要解决的问题。
如果要保持团队的凝聚力，必须将坚持个人己见的人员排除于团队之外。
团队是 “自组织的”
自适应团队结构
使用Constantine 提出的随机、开放和同步式的范型
相当大的自主权

产品

产品范围

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

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

重要例题

希赛信息技术有限公司(CSAI原本是一家专注于企业信息化的公司，在电子政务如火如茶的时候，开始进军电子政务行业。在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。

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

【问题1】

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

【问题2】

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

【问题3】

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

【问题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

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

软件人员不了解客户的需求。
产品范围定义很糟糕。
没有很好地管理变更。
所选的技术发生了变化。
业务需求发生了变化 [或未能很好地定义]。
截止日期是不切实际的。
客户抵制。
失去赞助 [或从来没有真正得到过赞助]。
项目团队缺乏具有合适技能的人员。
管理者 [和开发人员] 没有很好地利用已学到的最佳实践和经验。

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

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

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

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

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