[工学]大连理工大学软件项目管理大作业

[工学]大连理工大学软件项目管理大作业内容摘要：

己团队开发一个技术架构，需要项目的技术领导者进行探讨，并有必要对这些结构进行一些性能方面的测试。 编码主要是把前面分析的功能点一一进行实现。 质量保证任务： 实现也就是代码的生产过程。 这里不仅包括代码的产生，同时也包括测试用例的产生。 针对上一阶段提供详细设计，程序员开始编码并且调试程序，测试人员则根据设计进行测试用例的设计，设计出来的用例需要得到项目组成员认可由项目经理审核通过才能进入配置库。 同时程序员调试完程序提交测试人员进行程序正确性检测。 基线产品：模块开发卷宗，开发进度报表。 ． 阶段六：测试 管理任务： 一个大型的项目必须经过功能测试和性能测试，两个测试阶段。 功能测试主要针对项目的需求阶段设计出的需求文档进行测试。 性能测试主要是对整个编码完成的项目进行性能方面的测试，测试整个项目是不是经得起高并发，高负载的影响。 质量保证任务： 需要很多轮的测试工作。 需要及时生成测试分析报告，以达到岁项目整体的质量把握。 基线产品：测试分析报告，开发进度报表，项目开发总结报告。 ：运行和维护 管理任务： 其实测试工作和运营可以同时进行，运营主要看这个项目需要什么样的运营方案进行支持。 质量 保证任务： 维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。 所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。 他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。 对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。 如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。 维护小组的人员基本上是按项目跟进的。 当一个项目刚刚交付用户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。 基线产品：用户手册，操作手册，项目开发总结，维护记录。 此外，贯穿于整个项目开发过程之中的至关重要的项目管理对象是： 文档管理。 文档维护主要是配置管理小组的工作。 文档从用途上分主要分为内部文档和外部文档。 内部文档包括： 项目开发计划； 需求分析； 体系结构设计说明； 详细设计说明； 构件索引； 构件成分说明； 构件接口 及调用说明； 组件索引； 组件接口及调用说明； 类索引； 类属性及方法说明； 测试报告； 测试统计报告； 质量监督报告； 源代码； 文档分类版本索引； 软件安装打包文件。 外部文档主要包括： 软件安装手册； 软件操作手册； 在线帮助； 系统性能指标报告； 系统操作索引。 如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。 解决此问题，其核心仍然是个 度 的问题。 在本项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。 当有文档模板后需要书写文档的人员只剩下 填空 的工作，从某种意义上讲，书写文档的速度会加快。 如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。 配置管理小组真正核心的工作是对文档的组织管理。 根据文档的不同，文档的来源也不同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。 文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。 从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。 一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。 10．项目风险管理 、项目风险管理的目的 风险是指在项目进行过程中可能发生的事件，这些事件将会对项目按预期时间，资源和预算完成产生重大影响。 风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划和启用风险处理活动。 、项目风险管理的组成 风 险 管 理风 险 评 估 风 险 控 制风险识别风险优先级风险分析风险管理计划风险化解风险监控 、风险的种类 分清风险的种类有利于更好的对项目进行风险管理。 资源风险 组织 对该项目是否有足够的支持（包 括管理人员、测试员、 QA 和其他外部的相关各方）。 这是否是该组织尝试过的最大项目。 软件工程是否有明确定义的流程。 需求记录和管理。 资金 完成项目所需的资金是否到位。 是否为培训和指导分配了资金。 是否有预算限制使得系统必须以固定的成本交付，否则将被取消。 成本估算是否准确 人员 是否可以获得足够 的项目工作 人员。 他们是否具备合适的技能和经验。 他们以前是否在一起工作过。 他们是否相信项目会成功。 是否可以找到用户代表来担任复审员。 是否可以找到领域专家。 时间 时间表制定得是否现实。 是否可以为了满足时间表而对功能进行规模管理。 对交付日期的要求有多严格。 是否有时间“把工作做好”。 业务风险 如果竞争对手抢先将产品推向市场怎么办。 如何确保有足够的资金。 系统的预计价值是否大于预计成本。 （考虑货币的时间价值和资金的成本）。 如果无法同关键的供应商签定合同怎么办。 技术风险 规模风险 成功是否能够被评测。 是否有关于如何评测成功的协议。 需求是否相当稳定并得到了充分的了解。 项目规 模是固定不变还是在不断扩展。 项目开发的时间范围是否太短、不够灵活。 技术风险 技术是否已经过证明。 重复使用目标是否合理。 工件必须要使用一次后才能被重复使用。 构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。 需求中的事务量是否合理。 事务比率的估计值是否可靠。 这些估计是否过于乐观。 数据量是否合理。 当前可用的框架是否能够保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计的一部分，那么是否能够在这些地方合理地保存数据。 是否有特殊或苛刻的技术需求。 成 功是否依赖于新的或未经试验的产品、服务或技术。 是否依赖于新的或未被证明的硬件、软件或技术。 对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性。 是否存在必需的接口或必须创建它们。 是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不出现故障”）。 系统的用户是否对正在开发的系统类型没有经验。 应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加。 是否存在对国家语言支持的需求。 是否可能设计、实施和运行该系统。 某些系统只由于太大或太复杂而无法正常工作。 外部依 赖性风险 该项目是否依赖于其他（平行的）开发项目。 成功是否依赖于市售产品或外部开发的构件。 成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）的成功集成。 您是否有替代计划，可以在没有这些技术的情况下交付项目。 进度风险 功能是否无限追加。 计划是否过于乐观。 是否缺乏计划。 在压力下是否放弃计划。 是否追赶计划。 、定义风险参数 风险参数可用于评估、分类和划分风险的优先级；该项目将发生的可能性的等级划分为：非常可能发生，可能发生，几乎不可能 发生 3 个级别。 将对项目的影响程度划分为：非常严重影响，严重影响，中等影响，微弱影响 4 个级别。 相应的表格如下： 发生的可能性 对项目的影响程度 名称 等级 名称 等级 非常可能发生 3 非常严重影响 4 可能发生 2 严重影响 3 几乎不可能发生 2 中等影响 2 微弱影响 1 、风险管理策略 有三种主要的策略： *风险规避：使其不再受到该风险的影响。 *风险转移：让其他方（客户、厂商、银行、其他主体等）承担该风险。 *风险接受：决定将该风险当作意外事件来接受。 监测风险征兆，并制 定应急计划，以确定在风险发生时将采取何种行动。 、风险管理角色及职责 （ 1）项目经理 项目经理对风险管理工作负全部责任。 （ 2）项目组开发人员 项目组开发人员将被要求作为项目风险分析组的成员，对项目工作中存在的风险进行分析，并整理成书面材料。 （ 3） SQA SQA 经理将定期对风险管理工作开展情况进行评审，确保所开展的风险管理工作符合组织的要求。 、个人 微薄 项目中风险的识别 根据风险识别的分类标准可以识别出个人 微薄 项目中存在的风险，如下： 资源风险 完成该项目所需的资金受到一定的限制，人员的培 训指导资金不到位，存在一定资金风险；参与项目的部分人员没有一起工作过，也存在着一定的人员风险；此外，交付日期的严格要求导致项目存在时间风险。 业务风险 由于软件行业的飞速发展，竞争对手可能抢先将产品推向市场，故存在着业务风险。 技术风险 客户可能随时提出需求和对项目的改进，需求的不稳定性和项目规模的不断扩展，可能导致项目存在规模风险。 进度风险 功能的无限追加，在强大的压力下放弃计划都造成了项目的进度风险。 、风险的控制 1．控制方法 （ 1）风险管理计划 重点是制定一个计划，以处理在排位靠前的高风险 项。 风险管理计划每阶段 /迭代重新评估一次。 风险监控时选取风险管理计划中没有关闭的前 10 大风险进行监控即可。 每阶段 /迭代启动时，选取“风险管理计划”中处于“监控”状态的前 10 大风险，用于本阶段 /迭代的周例会上进行跟踪和监控（注意：周例会时只监控阶段 /迭代启动时监控的前 10 大风险）。 （ 2）风险的化解 避免风险（即：不要做冒险的活动） 将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生时影响不大） 购买关于风险的信息（例如：做实验性项目，请咨询专家等） 消除风险的根源 接受风险（如 果风险后果较小，而处理它可能代价很大，滚动处理可能是最有效的途径） 发布风险（将风险发布给相关涉众，如：管理者、市场人员、客户 {特别注意策略 }等） 控制风险 制定风险无法化解时的“风险应急计划” 分配额外的资源来处理风险 为处理风险留出额外的时间 记住风险（为将来的项目积累） ． 风险监控 （ 1）周例会检查风险 在周工作例会上，项目经理需要跟踪项目的风险。 根据风险列表，逐一分析前 10 大风险，确认已经风险状态是否“发生”或“关闭”； 如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时 PM请求相关高级管理者解决已发生的风险，并且 PM 负责在风险管理计划中将此条风险标示为“发生”。 如果风险已经消除，则 PM 负责在风险管理计划中将此条风险标示为“关闭”。 统计每项风险的停留时间 (周数 )。 、 微薄 项目的风险管理 个人微薄 项目的主要风险是开发人员对客户需求不是很熟悉，另外，客户要求的进度比较紧，而且具体需求不是很明确，客户可能随时提出需求和对项目的改进，需求的不稳定性和项目规模的不断扩展，可能导致项目存在规模风险。 功能的无限追加，在强大的压力下放弃计划都造成了项目的进度风险。 下面的这个风 险列表就是通过一系列的风险识别、风险评估、风险应对，等到的 微薄 项目的风险列表。 排序 输入 风险事件 可能性 影响 风险值 风险应对措施 1 客户的SOW 需求不明确，增加需求，导致需求蔓延 3 3 9 1．采取加班的方法 2．修改计划去掉一些任务 3．与客户商量延长一些时间 2 WBS 复杂模块的技术难关 2 3 6 对复杂模块进行外包 3 合同 进度要求紧，合同金额有限 2 3 6 可以请一些实习的学生做辅助工作 ,一来成本不高 ,二来可以加快进度 . 4 WBS 供货商、外包商的质量问题 1 3 3 多选择几个可以作为备份的外包商和供应商 5 历史项目信息 开发人员的流动 1 3 3 1．注意项目团队的沟通，及时了解开发人员的动态 2．控制好项目过程中的文档 组借调人员 4．从外部招聘有过此类开发经验人员 6 规模。