首页  思维导图  详情

软件设计师-项目管理

2023-10-28 09:28:59   0  举报





AI智能生成

软件设计师-项目管理总结

考证

读书笔记

作者其他创作

大纲/内容

软件项目估算

估算策略

自顶向下

以项目经理为核心，先根据用户、决策者的要求，确定一个时间期限，然后根据该期限进行分解，
采用对号入座的方式将开发工作分配给具体的开发人员，以获得一个可以满足这个期限的估算。

自底向上

由核心小组进行头脑风暴，完成工作任务分解，然后由开发人员进行合理估算，然后累计得到总的估算

软件规模估算

LOC

代码行估算法，将项目切分为一个个小模块，通过历史项目经验、开发人员经验，估算每个模块的代码行

FP是指功能点，是一种衡量工作量大小的单位。它的计算方法是功能点=信息处理规模×技术复杂度

技术复杂度=0.65+调节因子

外部输入数（input）

外部输出数（output）

外部查询数（inquire）

内部逻辑文件数（file）

外部接口文件数（interface）

然后再从数据通信、分布式处理、性能、配置项、事务率、在线数据、用户使用效率、在线更新、复杂处理、重用性、安装容易程度、操作容易程度、多个地点、修改容易程度等 14个方面的复杂度，进行微调，每个方面都在0~0.05之间取值，最后累加出调节因子，再加上0.65 得出技术复杂度。

软件工作量估算

工作量的单位通常是人月，计算方法为规模/产能=工作量

IBM模型

是在60多个项目的基础上进行统计得出的静态模型

Putnum模型

是一种动态多变量模型，它通过建立一个"资源需求曲线模型"来导出一系列等式，模型化资源特性

COCOMO模型

是最有代表性的方法。在该模型中使用了源指令条数（DSI）、开发工作量（MM）、开发进度（TDEV）三个基本量，
它将项目分为组织型（相对较小、较简单的项目）、嵌入式（软硬件限制较多的项目）、半独立型（介于两者之间，规模和复杂性中等以上）。
它包括基本（静态模型）、中间、详细三种不同的模型

成本估算

得到工作量、人员需求、项目持续时间后，就可以进一步估算成本，通常包括人员成本、资源成本、其他开支等

进度计划与监控

项目的进度安排与任何一个多重任务工作的进度安排基本差不多。项目的进度计划和工作的实际进展情况，通常表现为各项任务之间的进度依赖关系，因而通常使用图表的方式来说明

甘特图

甘特图（Gantt图）使用水平线段表示任务的工作阶段，线段的起点和终点分别对应着任务的开工时间和完成时间，线段的长度表示完成任务所需的时间。而跟踪甘特图则是在甘特图的基础上，加上一个表示现在时间的纵线，可以直观地看出进度是否延误。甘特图的优点在于标明了各任务的计划进度和当前进度，能动态地反映项目进展；其缺点在于难以反映多个任务之间存在的复杂逻辑关系。

PERT技术和CPM方法

ERT（计划评审技术）和CPM（关键路径法）都是采用网络图来描述一个项目的任务网络的，通常使用两张图来定义网络图。一张图给出某一特定项目的所有任务，另一张图给出应按照什么次序来完成这些任务，给出各个任务之间的衔接

PERT技术和CPM方法都为项目计划人员提供了一些定量的工具

确定关键路径

即决定项目开发时间的任务链

应用统计模型

对每个单独的任务确定最可能的持续时间的估算值

计算边界时间

为具体的任务定义时间窗口

评估项目进度

最常见的方法是挣值分析，它把实际进度和计划进度进行比较，发现项目是否拖期或超前。通过计算实际已花费在项目上的工作量，来预计该项目所需的成本和完成时间日期

质量管理

软件质量是指软件特性的综合，软件满足规定或潜在用户需求的能力

具体地说就是软件质量是软件与明确叙述的功能和性能需求、文档中明确描述的开发标准，
以及任何专业开发的软件产品都应该具有的与隐含特征相一致的程度

具体地说就是软件质量是软件与明确叙述的功能和性能需求、文档中明确描述的开发标准，以及任何专业开发的软件产品
都应该具有的与隐含特征相一致的程度

影响软件质量的因素主要包括

人、软件需求、开发过程的各个环节、测试的局限性、质量管理的困难性、是否对质量管理予以重视、
软件人员的传统习惯、开发规范和支持性的开发工具等

为了能够统一地描述软件质量特性，形成了许多质量特性标准，其中最常用的有国际通用的 ISO/IEC 9126软件质量模型和Mc Call软件质量模型

IEO/IEC 9126模型

McCall质量模型

软件过程改进

软件过程能力成熟度模型（Capability MaturityModel,CMM）

CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准

初始级

软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖极个别人的努力和机遇

初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的

也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，
且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级

可重复级

已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪

对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上

一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一
个按计划执行的且阶段可控的软件开发过程

已定义级

用于管理的和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程

全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作

要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标
准集成到企业软件开发标准过程中去

所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。
过程的剪裁不是随意的，在使用前需经过企业有关人员的批准

已管理级

软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理

所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标

这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动

优化级

通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进

如果一个企业达到了这一级，表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳

在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标

能力成熟度模型集成（Capability Maturity Model Integration,CMMI）

与CMM相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采
购。据美国国防部资料显示，运用CMMI模型管理的项目，不仅降低了项目的成本，而且提高了项
目的质量与按期完成率。

阶段式模型也把组织分为5个不同的级别

初始级

代表了以不可预测结果为特征的过程成熟度，过程处于无序状态，成功主要取决于团队的技能

已管理级

代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管
理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理，以及度量和
分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践

严格定义级

代表了以组织内改进项目执行为特征的过程成熟度。强调级别3的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践

定量管理级

代表了以改进组织性能为特征的过程成熟度。4级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预测的

优化级

代表了以可快速进行重新配置的组织性能和定量、持续的过程改进为特征的过程成熟度

CMMI的具体目标是

改进组织的过程，提高对产品开发和维护的管理能力

给出能支持将来集成其他科目CMM的公共框架

确保所开发的全部有关产品符合将要发布的关于软件过程改进的国际标准ISO/IEC15504 对软件过程评估的要求

使用在CMMI框架内开发的模型具有下列优点

过程改进能扩展到整个企业级

先前各模型之间的不一致和矛盾将得到解决

既有分级的模型表示，也有连续的模型表示，任你选用

原先单科目过程改进的工作可与其他科目的过程改进工作结合起来

基于CMMI的评估将与组织原先评估得分相协调，从而保护当前的投资，并与 ISO/IEC15504评估结果相一致

节省费用，特别是当要运用多科目改进时，以及进行相关的培训和评估时

鼓励组织内各科目之间进行沟通和交流

配置管理

软件配置管理（Software Configuration Management,SCM）是一种标识、组织和控制修改的技术

SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更

从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率

4 项最基本的活动

配置项标识

软件过程的输出信息可以分为三个主要类别

计算机程序，包括源代码和可执行程序

描述计算机程序的文档，分别针对技术开发者、管理人员和用户

数据，包含在程序内部或外部

变更控制

变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制

CVS（Concurrent Versions System）是一种广泛应用的、开源的、透明于网络的版本控制系统。它只保存一份源码并记录所有对它的改动。当开发者需要文件的某个特定版本时，CVS 会根据那些记录重建出需要的版本。

置状态报告

配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况

这样的报告应该是定期进行的，并尽量通过CASE（Computer Aided Software Engineering,计算机辅助软件工程）工具自动生成，用数据库中的客观数据来真实地反映各配置项的情况

配置状态报告应根据报告着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系做一定的分析。

配置状态报告应该包括下列主要内容

配置库结构和相关说明

开发起始基线的构成

当前基线位置及状态

各基线配置项集成分支的情况。

各私有开发分支类型的分布情况。

关键元素的版本演进记录

其他应该报告的事项

配置审核

配置审核的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。

在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由
SQA人员单独执行

风险管理

风险是指可能给项目的成功带来威胁或损失的情况，而风险管理是指在风险给项目带来损失之前，就指明、评估并对风险加以控制，使用工具和方法把项目风险限制在一个可接受的范围内

风险的类型

项目风险

指潜在的预算、进度、人力（工作人员及组织）、资源、客户和需求等方面的问题以及它们对软件项目的影响。例如：项目复杂性、规模和结构不确定性等都是项目风险

项目风险威胁到项目计划，也就是说，如果项目风险变成现实，有可能会拖延项目的进度，增加项目的
成本

技术风险

指潜在的设计、实现、接口、验证和维护等方面的问题

此外，规约的二义性、技术的不确定性、陈旧的技术和"先进的"技术也是技术风险因素

技术风险威胁到要开发软件的质量及交付时间，如果技术风险变成现实，则开发工作可能变得很困难或根本不可能

商业风险

在信息系统项目中，商业风险威胁到要开发系统的生存能力。一般主要有5类商业风险

开发了一个没有人真正需要的优秀产品或系统（市场风险）

开发的产品不再符合公司的整体商业策略（策略风险）

开发了一个销售部门不知道如何去卖的产品（销售风险）

由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）

没有得到预算或人力上的保证（预算风险）

风险评估

可分为定量评估和定性评估。通过对各种风险发生的可能性和破坏性这两个方
面进行评估，并将它们按优先级进行排列

在进行软件工程分析时，项目管理人员要进行四种风险评估活动，包括建立表示风险概率的尺度，
描述风险引起的后果，估计风险影响的大小，确定风险估计的正确性

风险驾驭

利用某种技术，如原型化、软件自动化、软件心理学、可靠性工程学等方法设法避开风险

风险防范策略

规避策略

规避策略指的是想方设法阻止风险的发生或消除风险发生的危害。避免策略如果成功则可以消除风险对项目的影响。例如：针对技术风险可以采取聘请技术专家、针对项目进度风险可以采取延长项目时间或缩减项目范围的办法

转移策略

转移策略指的是将风险转嫁给其他的组织或个体，通过这种方式来降低风险发生后的损失。例如：在固定成本的项目中，进行需求签字确认，对于超出签字范围的需求变更需要客户增加费用。这种方式就是一种将需求风险转移的策略。经过转移的风险并没有消失，其发生的可能性也没有变化，但对于项目组而言，风险发生后的损失降低了。

减轻策略

当风险很难避免或转移时，可以考虑采取减轻策略来降低风险发生的概率或减轻风险带来的损失。
风险是一种不确定因素，可以通过前期的一些工作来降低风险发生的可能性；或者也可以通过一些准备来降低风险发生的损失

软件文档

文档是信息系统产品的重要组成部分，对于开发人员、管理人员以及用户都是十分重要的辅助文件

定义清晰、维护及时的文档能够帮助开发人员理解需求、顺畅沟通；帮助管理人员了解进度、加强管理；帮助用户更好地使用和维护软件

因此，对于信息系统监理师而言，必须掌握系统文档编制的技能

文档的分类

开发文档

为开发工作提供支持的各种文档，其读者群主要针对开发人员。其中主要包括需求规格说明书、数据要求规格说明书、概要设计说明书、详细设计说明书、项目开发计划等

管理文档

为项目的开发管理提供支持的各种文档，其读者群主要针对管理人员，其中主
要包括可行性研究报告、项目开发计划、测试计划、技术报告、开发进度记录、项目开发总结报告等

用户文档