软件工程师项目开发过程标准技术文档模版大全(编辑修改稿)

软件工程师项目开发过程标准技术文档模版大全(编辑修改稿)内容摘要：

的方式、将采用的风险管理策略、对最严重的风险所计划的降低 /规避或预防的策略、监测风险状态的方式、风险复审的时间表。 ] 风险管理的组织和职责 [列出与风险管理相关的个人或小组，并对其职责进行描述。 ] 工具与技术 [列出与风险管理将采用的工具软件或技术。 ] 纳入管理的风险项 [列出主要的风险项，并描述其影响以及应急措施。 具体可以参考后面的《风险条目跟踪表模板》。 ] 收尾计划 [列出在项目后期将要做的事，包括材料存档、汇报总结等。 ] 5. 相关技术 开发案例 [给出本项目将采用的软件生命周期模型、过程规范等，从而对开发过程给予明确的指导。 该部分可以视需要将其单列 为一个专题文件。 ] 方法、工具和技术 [列出本项目中将运用的方法、工具和技术，并给出适当的工作指南和说明。 ] 产品验收计划 [列出本项目验收工作的一些细节计划，本部分内容可以视需要将其单列为一个专题计划。 ] 6．其它支持过程管理 配置管理计划 [在此列出该项目所采用的配置管理过程，通常是单列为一个专题。 ] 评估计划 [列出本项目评估时所使用的技术、标准、指标和过程。 这里的评估包括走查、检查和复审。 ] 文档计划 质量保证计划 分包商管理计划 风险条目跟踪表模板 编者说明： 对于中型以上的项目，风险控制的意义就犹为突出。 要控制风险，就应该找到风险，并将风险记录下来，确定相关责任人，对于风险性高的、可能性大的还需要制订相关的应对措施。 而最 好的方法就是整理成为本模板中的表格，为每个潜在风险备个案。 序列号 顺序号 确定日期 风险被识别出的日期 撤消日期 撤消风险确定日期 描述 以 条件 结果 的形式描述风险 可能性 风险转变为问题的可能性 注：可用 (极不可能 )~(肯定发生 )来表示 影响 如果风险变成了事实奖造成的损失 注：可用 1(无甚么影响 )~10(有很深、很大的影响 )来表示 危害值 可能性＊影响 降低风险计划 一种或多种用来控制、避免、最小化及降低风险的方法 负责人 解决风险的责任承担者 截止日期 完成降低风险措施的截止日期 进度计划风险列 表 编者说明： 准确来说，本列表不是一个文档模板，而是一个参考文章。 由于风险识 别许多人都觉得无从入手，下面就是列出了与进度相关的风险条目，对于风险识别有很大的参考价值。 计划风险 1） 功能无限蔓延； 2） 需求镀金或开发人员镀金； 3） 质量不定 4） 计划过于乐观 5） 设计欠佳 6） 银弹综合症 7） 研发导向开发 8） 人员薄弱 9） 签约商失败； 10）研发人员与客户的磨擦。 计划编制风险 1） 计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致； 2） 计划是优化的，是“最佳状态”； 3） 计划忽略了必要的任务； 4） 计划基于使用特定的小组成员，而那个小组成员其实指望不上。 5） 在限定的时间内无法建成已定规模大小的产品； 6） 产品规模比估计的要大一些； 7） 工作量大于估算数； 8） 进度已经拖延的项目在重新评 估时过于优化或忽视项目历史； 9） 过度的进度压力造成生产率下降； 10）目标日期提前，但没有相应地调整产品范围或可用资源； 11）一个任务的延迟导致相关任务的连锁反应； 12）涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。 组织和管理 1） 项目缺乏一个有凝聚力的最高领导人； 2） 由于前期乏力，项目长时间被搁置； 3） 解雇和削减开支导致项目小组能力下降； 4） 仅由管理层或市场人员进行技术决策，导致计划进度延长； 5） 低效的项目组结构降低生产率； 6） 管理层审查 /决策的周期比预期时间长； 7） 预算削减打乱项目计划； 8） 管理 层做出了打击项目组织积极性的决定； 9） 非技术的第三方的工作比预期延长（如审批，采购等）； 10）计划性太差，无法适应期望的开发速度； 11）项目计划由于压力而放弃，导致开发混乱、低效； 12）管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。 开发环境 1） 设施没有及时到位； 2） 设施到位，但不配套； 3） 设施拥挤、杂乱或者破损； 4） 开发工具未能及时到位； 5） 开发工具不如期望那样有效，开发人员需要时间创建工作环境或切换新的工具； 6） 开发工具的选择不是基于技术需求，不能提供计划要求的性能； 7） 新开 发工具的学习期比预期的长，内容繁多。 最终用户 1） 最终用户坚持新的需求； 2） 最终用户对于最后交付的产品不满意，要求重新设计和重做； 3） 最终用户不买进项目产品，无法提供后续支持； 4） 最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。 客户 1） 客户坚持新的需求； 2） 客户对规划、原型和规格的审核 /决策周期比预期长； 3） 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的重复； 4） 客户答复的时间比预期长（如回答需求中需澄清的问题）； 5） 客户坚持技术决策而导致进度计划延长； 6） 客户对开发进 度管理过细，导致实际进展变慢； 7） 客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作； 8） 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作； 9） 客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低； 10）客户不接受交付的软件，尽管它满足了所有的规格； 11）客户期望的开发速度是开发人员无法达到的。 承包商 1） 承包商没有按承诺交付组件； 2） 承包商递交的组件质量低下无法接收，必须花时间改进质量； 3） 承包商没有买进项目开发需要的工具，进而无法提供需要的性能 水平。 需求 1） 需求已经成为项目基准，但变化还在继续； 2） 需求定义欠佳，而进一步的定义会扩展项目范畴； 3） 添加额外的需求； 4） 产品定义含混的部分比预期需要更多的时间。 产品 1） 错误发生率高的模块需要比预期更多的测试、设计和实现工作； 2） 校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作。 3） 在一个或多上新兴领域推广计算机技术使得计划进度的延长不可预期； 4） 由于软件功能的错误，需要重新设计和实现； 5） 开发额外不需要的功能（镀金）延长了计划进度； 6） 要满足产品规格与速度要求，需比预期更多时间，包括重新 设计和实现的时间； 7） 严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作； 8） 要求与其他系统、复杂系统或不受本项目控制的系统相连，导致无法预料的设计、实现和测试工作。 9） 要求在不同操作系统下运行将花费比预期更长的时间； 10）在不熟悉或未经检验的软（硬）件环境中运行产生未预料的问题； 11）开发一种对组织全新的模块将比预期花费更长的时间； 12）依赖正在开发中的技术将延长计划进度。 外部环境 1） 产品依赖政府规章，而规章的改变将是不可预期的； 2） 产品依赖草拟中的技术标准，而最后的标准将是不可预期的。 人员 1） 招聘人员所花时间比预期的长； 2） 作为先决条件的任务不能按时完成（如培训、其它项目）； 3） 开发人员和管理层之间关系不佳导致决策缓慢，影响全局； 4） 项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平； 5） 缺乏激励措施，士气低下，降低了生产能力； 6） 缺乏必要的规范，增加了工作失误与重复工作； 7） 某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言； 8） 项目结束前，合同制人员离开团队，或雇员辞职； 9） 项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率； 10）项目组成员不能有效地 一起工作； 11）由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作； 12）有问题的成员没有调离项目组，损害了项目组其他成员的积极性； 13）项目的最佳人选未加入项目组； 14）项目的最佳人选已加入项目组，但因其他原因未能合理使用； 15）没有找到项目急需的具有特定技能的人； 16）关键人物只能兼职参与； 17）项目人员不足； 18）任务的分配与人员技能不匹配； 19）人员工作的进展比预期的慢； 20）项目管理人员怠工导致计划和进度失效； 21）技术人员怠工导致工作遗漏或质量低下，工 作需要重做。 设计与实现 1） 设计过于简单，无法确定主要事件，并导致重新设计和实现； 2） 设计过于复杂，导致一些不必要的工作，影响实现效率； 3） 设计质量低下，导致重复设计和实现 4） 使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误； 5） 产品采用低级语言来实施，导致生产率比预期的低； 6） 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新库或自选开发所要的功能； 7） 代码和库质量低下，导致需要额外的测试、错误修正或重做； 8） 过高估计了增强型工具对计划进度的节省量； 9） 分别开发的模块无法有效集成 ，需要重新设计或重做。 过程 1） 大量的纸面工作导致进程比预期的慢； 2） 进程跟踪不准确，导致无法预知项目是否已落后于计划进度； 3） 前期的质量保证行为不真实，导致后期的重复工作； 4） 质量跟踪不准确，导致无法得知影响进度的质量问题； 5） 太不正规，导致沟通不足，质量问题和工作重做； 6） 过于正规，导致过多耗时无用的工作； 7） 向管理层撰写进度报告占用的开发人员的时间比预期的多； 8） 风险管理粗心，导致没有发现重大的项目风险； 9） 软件项目风险管理花费的时间比预期的多。 开发进度月报 (ISO 标准 ) 编者说明： 计划需要跟踪 进度来进行适当的调整，因此在开发组织内应该形成良好的进度汇报机制， ISO 标准模板也对这一块提供了参考。 这一文档格式十分全面， 不过也略显繁琐，适合于中型以上项目。 l．标题 2．工程进度与状态 进度 [列出本月内进行的各项主要活动，并且说明本月内遇到的重要事件，这里所说的重要事件是指一个开发阶段（即软件生存周期内各个阶段中的某一个，例如需求分析阶段）的开始或结束，要说明阶段名称及开始（或结束）的日期。 ] 状态 [说明本月的实际工作进度与计划相比，是提前了、按期完成了、或是推 迟了。 如果与计划不一致，说明原因及准备采取的措施。 ] 3．资额耗用与状态 资额耗用 [主要说明本月份内耗用的工时与机时。 ] 工时 [分为三类： ] [a. 管理用工时 包括在项目管理（制订计划、布置工作、收集数据、检查汇报工作等）方面耗用的工时； ] [b. 服务用工时 包括为支持项目开发所必须的服务工作及非直接的开发工作所耗用的工时； ] [c. 开发用工时 要分各个开发阶段填写。 ] 机时 [说明本月内耗用的机时，以小时为单位，说明计算 机系统的型号。 ] 状态 [说明本月内实际耗用的资源与计划相比，是超出了、相一致、还是不到计划数。 如果与计划不一致，说明原因及准备采取的措施。 ] 4 经费支出与状态 经费支出 支持性费用 [列出本月内支出的支持性费用，一般可按如下七类列出，并给出本月支持费用的总和： ] [ a. 房租或房屋折旧费； ] [b. 员工工资、奖金、补贴； ] 开发中的软件系统的名称和标识符 分项目名称和标识符 分项目负责人签名 本期月报编写人签名 本期月报的编号及所报告的年月 [c. 培训费包括给教师的酬金及教室租金； ] [d. 资料费包括复印及购买参考资料的费用； ] [e. 会议费召集有关业务会议的费用； ] [f. 旅差费； ] [g. 其他费用。 ] 设备购置费 [列出本月内支出的设备购置费，一般可分如下三类： ] [[a. 购买软件的名称与金额； ] [b. 购买硬设备的名称、型号、数量及金额； ] [c. 已有硬设备的折旧费。 ] 状态 [说明本月内实际支出的经费与计划相比较，是超过了。 相符合、还是不到。