软件设计师-项目管理
2023-10-28 09:28:59 0 举报AI智能生成
软件设计师-项目管理总结
作者其他创作
大纲/内容
以项目经理为核心，先根据用户、决策者的要求，确定一个时间期限，然后根据该期限进行分解，采用对号入座的方式将开发工作分配给具体的开发人员，以获得一个可以满足这个期限的估算。
自顶向下
由核心小组进行头脑风暴，完成工作任务分解，然后由开发人员进行合理估算，然后累计得到总的估算
自底向上
估算策略
代码行估算法，将项目切分为一个个小模块，通过历史项目经验、开发人员经验，估算每个模块的代码行
LOC
外部输入数（input）
外部输出数（output）
外部查询数（inquire）
内部逻辑文件数（file）
外部接口文件数（interface）
然后再从数据通信、分布式处理、性能、配置项、事务率、在线数据、用户使用效率、在线更新、复杂处理、重用性、安装容易程度、操作容易程度、多个地点、修改容易程度等14个方面的复杂度，进行微调，每个方面都在0~0.05之间取值，最后累加出调节因子，再加上0.65得出技术复杂度。
技术复杂度=0.65+调节因子
FP是指功能点，是一种衡量工作量大小的单位。它的计算方法是功能点=信息处理规模×技术复杂度
FP
软件规模估算
工作量的单位通常是人月，计算方法为规模/产能=工作量
是在60多个项目的基础上进行统计得出的静态模型
IBM模型
是一种动态多变量模型，它通过建立一个\"资源需求曲线模型\"来导出一系列等式，模型化资源特性
Putnum模型
是最有代表性的方法。在该模型中使用了源指令条数（DSI）、开发工作量（MM）、开发进度（TDEV）三个基本量，它将项目分为组织型（相对较小、较简单的项目）、嵌入式（软硬件限制较多的项目）、半独立型（介于两者之间，规模和复杂性中等以上）。它包括基本（静态模型）、中间、详细三种不同的模型
COCOMO模型
软件工作量估算
得到工作量、人员需求、项目持续时间后，就可以进一步估算成本，通常包括人员成本、资源成本、其他开支等
成本估算
软件项目估算
项目的进度安排与任何一个多重任务工作的进度安排基本差不多。项目的进度计划和工作的实际进展情况，通常表现为各项任务之间的进度依赖关系，因而通常使用图表的方式来说明
甘特图（Gantt图）使用水平线段表示任务的工作阶段，线段的起点和终点分别对应着任务的开工时间和完成时间，线段的长度表示完成任务所需的时间。而跟踪甘特图则是在甘特图的基础上，加上一个表示现在时间的纵线，可以直观地看出进度是否延误。甘特图的优点在于标明了各任务的计划进度和当前进度，能动态地反映项目进展；其缺点在于难以反映多个任务之间存在的复杂逻辑关系。
甘特图
ERT（计划评审技术）和CPM（关键路径法）都是采用网络图来描述一个项目的任务网络的，通常使用两张图来定义网络图。一张图给出某一特定项目的所有任务，另一张图给出应按照什么次序来完成这些任务，给出各个任务之间的衔接
即决定项目开发时间的任务链
确定关键路径
对每个单独的任务确定最可能的持续时间的估算值
应用统计模型
为具体的任务定义时间窗口
计算边界时间
PERT技术和CPM方法都为项目计划人员提供了一些定量的工具
PERT技术和CPM方法
最常见的方法是挣值分析，它把实际进度和计划进度进行比较，发现项目是否拖期或超前。通过计算实际已花费在项目上的工作量，来预计该项目所需的成本和完成时间日期
评估项目进度
进度计划与监控
软件质量是指软件特性的综合，软件满足规定或潜在用户需求的能力
具体地说就是软件质量是软件与明确叙述的功能和性能需求、文档中明确描述的开发标准，以及任何专业开发的软件产品都应该具有的与隐含特征相一致的程度
人、软件需求、开发过程的各个环节、测试的局限性、质量管理的困难性、是否对质量管理予以重视、软件人员的传统习惯、开发规范和支持性的开发工具等
影响软件质量的因素主要包括
为了能够统一地描述软件质量特性，形成了许多质量特性标准，其中最常用的有国际通用的ISO/IEC 9126软件质量模型和Mc Call软件质量模型
IEO/IEC 9126模型
McCall质量模型
质量管理
软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖极个别人的努力和机遇
初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的
也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级
初始级
已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪
对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上
一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程
可重复级
用于管理的和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程
全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作
要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去
所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准
已定义级
软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理
所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标
这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动
已管理级
通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进
如果一个企业达到了这一级，表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳
优化级
CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准
在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标
与CMM相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。据美国国防部资料显示，运用CMMI模型管理的项目，不仅降低了项目的成本，而且提高了项目的质量与按期完成率。
代表了以不可预测结果为特征的过程成熟度，过程处于无序状态，成功主要取决于团队的技能
代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理，以及度量和分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践
代表了以组织内改进项目执行为特征的过程成熟度。强调级别3的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践
严格定义级
代表了以改进组织性能为特征的过程成熟度。4级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预测的
定量管理级
代表了以可快速进行重新配置的组织性能和定量、持续的过程改进为特征的过程成熟度
阶段式模型也把组织分为5个不同的级别
改进组织的过程，提高对产品开发和维护的管理能力
给出能支持将来集成其他科目CMM的公共框架
确保所开发的全部有关产品符合将要发布的关于软件过程改进的国际标准ISO/IEC15504对软件过程评估的要求
CMMI的具体目标是
过程改进能扩展到整个企业级
先前各模型之间的不一致和矛盾将得到解决
既有分级的模型表示，也有连续的模型表示，任你选用
原先单科目过程改进的工作可与其他科目的过程改进工作结合起来
基于CMMI的评估将与组织原先评估得分相协调，从而保护当前的投资，并与ISO/IEC15504评估结果相一致
节省费用，特别是当要运用多科目改进时，以及进行相关的培训和评估时
鼓励组织内各科目之间进行沟通和交流
使用在CMMI框架内开发的模型具有下列优点
软件过程改进
SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更
从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率
计算机程序，包括源代码和可执行程序
描述计算机程序的文档，分别针对技术开发者、管理人员和用户
数据，包含在程序内部或外部
软件过程的输出信息可以分为三个主要类别
配置项标识
CVS（Concurrent Versions System）是一种广泛应用的、开源的、透明于网络的版本控制系统。它只保存一份源码并记录所有对它的改动。当开发者需要文件的某个特定版本时，CVS会根据那些记录重建出需要的版本。
变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的机制
变更控制
配置状态报告就是根据配置项操作数据库中的记录来向管理者报告软件开发活动的进展情况
配置状态报告应根据报告着重反映当前基线配置项的状态，以作为对开发进度报告的参照。同时也能从中根据开发人员对配置项的操作记录来对开发团队的工作关系做一定的分析。
配置库结构和相关说明
开发起始基线的构成
当前基线位置及状态
各基线配置项集成分支的情况。
各私有开发分支类型的分布情况。
关键元素的版本演进记录
其他应该报告的事项
配置状态报告应该包括下列主要内容
置状态报告
配置审核的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。
在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行
配置审核
4 项最基本的活动
配置管理
风险是指可能给项目的成功带来威胁或损失的情况，而风险管理是指在风险给项目带来损失之前，就指明、评估并对风险加以控制，使用工具和方法把项目风险限制在一个可接受的范围内
指潜在的预算、进度、人力（工作人员及组织）、资源、客户和需求等方面的问题以及它们对软件项目的影响。例如：项目复杂性、规模和结构不确定性等都是项目风险
项目风险威胁到项目计划，也就是说，如果项目风险变成现实，有可能会拖延项目的进度，增加项目的成本
项目风险
指潜在的设计、实现、接口、验证和维护等方面的问题
此外，规约的二义性、技术的不确定性、陈旧的技术和\"先进的\"技术也是技术风险因素
技术风险威胁到要开发软件的质量及交付时间，如果技术风险变成现实，则开发工作可能变得很困难或根本不可能
技术风险
开发了一个没有人真正需要的优秀产品或系统（市场风险）
开发的产品不再符合公司的整体商业策略（策略风险）
开发了一个销售部门不知道如何去卖的产品（销售风险）
由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）
没有得到预算或人力上的保证（预算风险）
在信息系统项目中，商业风险威胁到要开发系统的生存能力。一般主要有5类商业风险
商业风险
风险的类型
可分为定量评估和定性评估。通过对各种风险发生的可能性和破坏性这两个方面进行评估，并将它们按优先级进行排列
在进行软件工程分析时，项目管理人员要进行四种风险评估活动，包括建立表示风险概率的尺度，描述风险引起的后果，估计风险影响的大小，确定风险估计的正确性
风险评估
利用某种技术，如原型化、软件自动化、软件心理学、可靠性工程学等方法设法避开风险
风险驾驭
规避策略指的是想方设法阻止风险的发生或消除风险发生的危害。避免策略如果成功则可以消除风险对项目的影响。例如：针对技术风险可以采取聘请技术专家、针对项目进度风险可以采取延长项目时间或缩减项目范围的办法
规避策略
转移策略指的是将风险转嫁给其他的组织或个体，通过这种方式来降低风险发生后的损失。例如：在固定成本的项目中，进行需求签字确认，对于超出签字范围的需求变更需要客户增加费用。这种方式就是一种将需求风险转移的策略。经过转移的风险并没有消失，其发生的可能性也没有变化，但对于项目组而言，风险发生后的损失降低了。
转移策略
当风险很难避免或转移时，可以考虑采取减轻策略来降低风险发生的概率或减轻风险带来的损失。风险是一种不确定因素，可以通过前期的一些工作来降低风险发生的可能性；或者也可以通过一些准备来降低风险发生的损失
减轻策略
风险防范策略
风险管理
文档是信息系统产品的重要组成部分，对于开发人员、管理人员以及用户都是十分重要的辅助文件
定义清晰、维护及时的文档能够帮助开发人员理解需求、顺畅沟通；帮助管理人员了解进度、加强管理；帮助用户更好地使用和维护软件
因此，对于信息系统监理师而言，必须掌握系统文档编制的技能
为开发工作提供支持的各种文档，其读者群主要针对开发人员。其中主要包括需求规格说明书、数据要求规格说明书、概要设计说明书、详细设计说明书、项目开发计划等
开发文档
为项目的开发管理提供支持的各种文档，其读者群主要针对管理人员，其中主要包括可行性研究报告、项目开发计划、测试计划、技术报告、开发进度记录、项目开发总结报告等
管理文档
向用户传达各种与开发相关、与产品相关的信息，其读者群主要针对最终用户。其中主要包括用户手册、操作手册、维护修改建议书、软件需求说明书等。
用户文档
文档的分类
可性行研究阶段：可行性研究报告
项目计划阶段：项目开发计划
需求分析阶段：软件需求说明书，数据要求规格说明书、系统测试计划、确认测试计划、用户手册。
概要设计阶段：概要设计说明书，集成测试计划。
详细设计阶段：详细设计说明书，单元测试计划。
编码与单元测试阶段：用户手册、操作手册。
集成测试阶段：测试分析报告，项目开发总结。
运行维护阶段：维护修改建议书
一般来说，用瀑布模型进行系统开发的过程中，每个阶段产生的文档为
在编写文档时，可以采用自然语言直接编写，也可以采用形式化语言来编写，还可以借助各种图表提高可读性，例如UML、DFD、E-R图等
文档产生的阶段
说明该软件项目的实现在技术上、经济上和社会因素上的可行性，评述为合理地达到开发目标可供选择的各种可能的实现方案，说明并论证所选定实施方案的理由
可行性研究报告
为软件项目实施方案制定出的具体计划。它应包括各部分工作的负责人员、开发的进度、开发经费的概算、所需的硬件和软件资源等。项目开发计划应提供给管理部门，并作为开发阶段评审的基础
项目开发计划
对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是用户与开发人员双方对软件需求取得共同理解基础上达成的协议，也是实施开发工作的基础
软件需求规格说明
给出数据逻辑描述和数据采集的各项要求，为生成和维护系统的数据文件做好准备
数据要求规格说明
是概要设计工作阶段的成果。它说明系统的功能分配、模块划分、程序的总体结构、输入输出及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计奠定基础
概要设计规格说明
着重描述每个模块如何实现，包括实现算法、逻辑流程等
详细设计规格说明
详细描述软件的功能、性能和用户界面，使用户了解如何使用该软件
用户手册
为操作人员提供该软件各种运行情况的有关知识，特别是操作方法细节
操作手册
针对组装测试和确认测试，需要为组织测试制定计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等
测试计划
测试工作完成以后，应当提交测试计划执行情况的说明。对测试结果加以分析，并提出测试的结论性意见
测试分析报告
该月报是软件人员按月向管理部门提交的项目进展情况的报告。报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等
开发进度月报
软件项目开发完成之后，应当与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力。此外，还需对开发工作作出评价，总结经验和教训
项目开发总结报告
软件产品投入运行之后，可能有修正、更改等问题，应当对存在的问题、修改的考虑以及修改的影响估计等做详细的描述，写成维护修改建议，提交审批
维护修改建议
文档的主要内容
软件文档
软件设计师-项目管理
0 条评论
回复 删除
下一页
