软件项目开发过程

软件项目开发过程 中国科学院软件研究所 高级技术培训中心 中国科学院软件研究所 2 软件项目 什么是软件项目 完成特定目的、符合用户特定需求的软件所需的组织结构和过程、规范的集合 软件项目的实施 需要周密的部署，合理的规章制度，符合项目的路线（软件过程），良好的项目管理和人员安排。 中国科学院软件研究所 3 相关流程 软件管理特点 软件生存期过程 确定需求 开发策划 需求分析 概要设计 详细设计 编码与调试 测试 软件集成、联调 内部确认 复制、交付、安装 试运行、用户验收 运行、维护 退役 软件管理 配置与变更管理 环境、工具和技术 有关软件的法规和标准 周密策划以保证 软件质量管理体系 八项质量管理原则 过程方法 基于过程的质量管理体系模式 实施质量管理体系的意义 实施质量管理体系工作重点 企业发展力量分析 中国科学院软件研究所 4 软件管理特点 软件产品的特点 软件产品的质量，完全取决于其设计和开发水平 软件需求的模糊性、变化性使软件产品难以成熟 任何一个软件产品，或多或少总会存在一些故障 (BUG) 软件人员广泛存在的不规范的开发习惯使开发过程难以管理 软件质量指标难以量化 软件测试理论和技术尚未解决软件产品正确性的验证问题 软件产品质量特性：满足需求能力的一系列特性总和 功能、可靠性、易用性、效率、维护性、可移植性 软件管理必须在市场 (用户 )需求和软件成熟性之间进行权衡 中国科学院软件研究所 5 软件生存期过程 确定需求 开发策划 需求分析 概要设计 详细设计 编码与调试 测试 软件集成、联调 内部确认 复制、交付、安装 试运行、用户验收 运行、维护 退役 中国科学院软件研究所 6 确定需求 确定外部用户需求 上级下达的软件开发课题 本单位根据市场需要确定的开发课题 用户合同要求的软件开发任务 输出 可行性分析报告 技术、经济、社会可行性，风险对策 合同及评审记录 产品要求得到规定和满足 单位有能力满足规定的要求 中国科学院软件研究所 7 开发策划 确定开发目标 确定项目开发的技术路线 (开发的出发基线 、 对现有产品的复用 、 委托开发等 ) 确定应遵循的标准 、 法律和法规 选任开发项目经理 划分开发阶段 确定各阶段的输入和输出文件 确定质量控制点 (评审点 、验证点和确认点 )及其实施的责任人 、 实施方式等 设计项目开发进度 确定开发人员并分配职责 提出开发所需资源 (软件 、硬件开发环境及工具软件 、 设备 、 资金等 )要求并予以落实 制定配置管理计划和质量保证计划 中国科学院软件研究所 8 开发策划 (续 ) 输出 策划报告 开发项目实施计划 配置管理计划 质量保证计划等 中国科学院软件研究所 9 需求分析 确保项目的开发符合用户的需求 (可测试性 ) 确定设计输入 任务委托书 /招标书 前期对用户的需求调研资料 可行性分析报告 /投标书 合同等 编制内部需求规格 (说明 )书 需求变更控制 中国科学院软件研究所 10 需求的层次 -业务需求、用户需求和功能需求 中国科学院软件研究所 11 需求的开发和管理 中国科学院软件研究所 12 需求验证 验证是为了确保需求说明准确、完整地表达必要的质量特点 客户的参与在需求验证中占有重要的位置 审查需求文档 以需求为依据编写测试用例 编写用户手册 确定合格的标准 中国科学院软件研究所 13 测试需求 测试需求有很多分类方法，最普通的一种就是按照商业功能分类 把需求分解成单元的好处： 测试需求是测试用例的基础，分成单元可以更好地进行设计 详细的测试需求是用来衡量测试覆盖率的重要指标 测试需求包括各种测试设计和开发以及所需资源 最好分解到功能点 中国科学院软件研究所 14 概要设计 确保产品的总体结构和模块间的关系与用户需求的一致性 内容 总体方案设计 逻辑框图 接口及通讯协议选用 现有产品软件的选用 边界 (约束 )条件的设计 运行环境设计等 输出 概要设计说明书 中国科学院软件研究所 15 详细设计 详细设计说明书与概要设计说明书是否相一致 内容 算法设计 数据格式设计 实现流程设计 人机界面设计 测试用例设计 操作设计等 输出 详细设计说明书 软件组装计划 测试计划及测试用例 安装手册 (初稿 ) 使用说明书 (初稿 ) 产品标准 (初稿 ) 中国科学院软件研究所 16 编码与调试 内容 编写程序代码：源代码 目标代码 可执行代码 此阶段还包括部分软件模块的局部测试、集成与联调 根据待开发软件的规模、控制点及人员安排，可细分为多个小阶段 输出 软件 (源代码、目标代码、可执行代码及相关数据文件 ) 文档 (帮助文件等 ) 保证编码风格的一致性，易读性；增强软件源码的可维护性 中国科学院软件研究所 17 测试 按测试发生的顺序划分 模块测试：是对单个软件模块的测试 单元测试：是对各个软件功能单元的测试 组装测试：是对各软件单元之间的互联测试 集成测试：是对硬件装置、设备和软件的加入性测试 系统测试：项目组所在部门组织的对完成集成的系统的测试 (是否满足产品规格要 ) 确认测试：单位质量控制部门进行的测试 (是否满足产品规格要求 ) 验收测试：在现场安装、调试结束并经试运行后，与顾客一起，就满足合同情况进行的测试 (是否满足合同要求 ) 中国科学院软件研究所 18 测试 (续 ) 与顺序无关的测试 联合测试：当软、硬件分头开发完成时，对其组合体进行的测试 回归测试：对因排除不符合项而采取的措施是否产生了其他副作用而进行的确认性测试 专项测试：针对某些具体测试项进行的确认性测试。例如：边界条件测试等。 应根据开发规模，尽可能进行独立测试。为了保证测试的可信性，被测试的软件应以源代码的形式提交，同时说明生成可执行代码的环境和方法。由测试人员生成可执行代码，进行测试。 中国科学院软件研究所 19 软件开发的 V字模型 不可能在需求开发阶段真正进行任何测试，因为还没有可执行的软件 可以在开发组编写代码之前，以需求为基础建立概念性测试用例，并使用它们发现软件需求规格说明中的错误、二义性和遗漏，还可以进行模型分析 中国科学院软件研究所 20 对 V模型的质疑 在部分阶段延迟进行单元测试和集成测试 在不同阶段上提前进行测试设计 中国科学院软件研究所 21 X模型 适应现实 单元测试、集成测试不断 迭代 强调 探索性 测试 中国科学院软件研究所 22 统计数字 产生缺陷 的活动 缺陷数 /功能点 消除率（ % ） 提交缺陷需求 1 77 0. 23设计 1. 25 85 0. 19编码 1. 75 95 0. 09文档 0. 6 80 0. 12修复 0. 4 70 0. 12总计 5 85 0. 75美国平均缺陷水平与缺陷消除率C M M级别产生缺陷数缺陷消除率（ % ）提交缺陷数1 5 85 0. 752 4 89 0. 443 3 91 0. 274 2 93 0. 145 1 95 0. 05C M M 不同级别的质量水平活动个人负责范围(FP)生产率（FP/ 月）%需求分析 400 90 3.66初步设计 200 100 3.29详细设计 200 75 4.39编码 150 18 18.29重用与采购 2000 1000 0.33配置管理 1500 250 1.32文档 1000 75 4.39单元测试 150 20 16.46功能测试 150 23 14.32系统测试 150 25 13.17接受测试 400 35 9.47项目管理 1000 30 10.98总计 100平均 180 3.29一个1 0 0 0 个功能点的项目中各种活动的比例每千行源代码所包含的 bug数， cmm1级为 11.95个， cmm2为 5.52个， cmm3为 2.39个， cmm4为 0.92个 ,而 cmm5则只有 0.32个 中国科学院软件研究所 23 软件集成、联调 应按计划对所开发的软件模块进行组装并与硬件一起联调 根据需要 ， 规定应填写的调试记录 中国科学院软件研究所 24 内部确认 在模拟环境下运行 ， 并监视 、 记录运行情况 根据任务书或合同的要求进行比照 ， 检查其是否满足使用要求 对运行情况 、 测试结果及文档的齐套性 、正确性和一致性进行评审 ， 达到确认 中国科学院软件研究所 25 复制、交付、安装 软盘复制 、 光盘刻录 交付时的版本标识和登记 安装 (派技术人员安装或由用户自行安装 ) 记录 软件安装实施计划 软件安装环境最低需求 软件安装记录 中国科学院软件研究所 26 试运行、用户验收 以用户验收的方式进行最终确认 结论 软件设计与需求的一致性 程序编码与软件设计的一致性 文件描述与程序的一致性 文件的成套性 、 完整性 、 准确性和标准化程度 是否通过验收 中国科学院软件研究所 27 运行、维护 收集使用中发现的问题和顾客意见 针对运行中出现的问题 ， 按设计更改程序进行控制 记录 用户服务记录表 中国科学院软件研究所 28 退役 编写软件退役报告 ， 并进行评审 中国科学院软件研究所 29 配置与变更管理 基线的确立 配置项的存取 配置管理实施 配置项的标识 配置项的变更控制 配置项的状态记录 配置项的检查和评审 控制对构成软件产品的各配置项的标识、管理、更改活动，保证软件配置项的完全性和正确性，防止非预期的使用 软件配置项的范围 合同、技术文档、质量记录等 中国科学院软件研究所 30 媒体控制 对软件存放介质 (媒体 )的要求和规定 软件的复制 (软件的生产过程 ) 媒体的标识：规则、执行者 媒体的贮存 (防潮、防火、防磁、防静电、防病毒 ) 媒体的包装、运输 中国科学院软件研究所 31 文档资料控制 各开发阶段应形成的文档，对其拟、审、批的规定 编制文档资料所依据的标准和规范 开发过程中应形成的质量记录 文档与软件之间的一致性检查 文档资料的归档与发放 中国科学院软件研究所 32 版本管理 分类 开发过程中的版本 交付软件产品的版本 管理对象 软件 文档 为该产品开发的工具软件 操作 配置管理人员，配备一台计算机 (或服务器 ) 开设开发库、受控库和产品库 访问权限 对入库和出库软件的控制 中国科学院软件研究所 33 版本管理 (续 ) 开发库存放正在开发 (编写 )或调试 (修改 )、自测的软件和文档 受控库存放开发各阶段测试通过的软件、文档和工具软件的版本并给以标识。转入下一阶段时，从此处发放用作下一阶段开始工作的初始版本 产品库存放可交付及已交付软件、文档及支持文件的版本 各库内所存放的软件和文档，应定期备份，以防止开发成果的意外丢失 (文件重写、介质损坏、意外事故、非法访问 病毒，黑客，故意破坏等 )并保证可追溯性 中国科学院软件研究所 34 环境、工具和技术 开发所需的硬件环境 测试所需的硬件环境 (包括模拟用户环境所必要的输入、输出设备 ) 开发平台软件 (操作系统、编程语言、编译环境、调试工具等 ) 管理软件 诊断软件 测试软件 辅助性软件 (防病毒软件等 ) 中国科学院软件研究所 35 有关软件的法规和标准 软件产品管理办法 计算机信息系统集成资质管理办法 (试行 ) 计算机软件保护条例 ISO IEC 12207 1995信息技术软件生存周期过程 ISO IECTR 15504软件过程评估 GB T19000 3 2001质量管理和质量保证标准第 3部分： GB信息技术软件生存周期过程 GB T19001 1994在软件开发，供应、安装和维护中的使用指南 GB T12504 90计算机软件质量保证计划规范 GB T12505 90计算机软件配置管理计划规范等 中国科学院软件研究所 36 周密策划以保证 开发人员应具备一定的资格或能力 开发环境 (软件和硬件平台 )是适用的 编制足够的控制程序和工作规范 (例如开发过程控制程序、变量命名规则、代码书写规范、注释规范等 ) 编制测试用例并在使用前对用例本身进行验证 编制各阶段测试计划，明确规定测试方法以及测试结果的记录要求、评价方式和接收准则 实施配置管理，控制软件产品 (代码和文档 )版本和更改过程 中国科学院软件研究所 37 软件质量管理体系 质量体系文件 质量手册 文件控制 记录控制 管理职责 质量方针、质量目标 职责、权限与沟通 管理评审 资源管理 人力资源 基础设施和工作环境 产品实现 产品实现的策划 与顾客有关的过程 设计和开发 采购 开发和服务提供 监视和测量装置的控制 测量、分析和改进 监视和测量 不合格品控制 数据分析 改进 中国科学院软件研究所 38 八项质量管理原则 以顾客为关注焦点 领导作用 全员参与 过程方法 管理的系统方法 持续改进 基于事实的决策方法 与供方互利的关系 中国科学院软件研究所 39 过程方法 中国科学院软件研究所 40 基于过程的质量管理体系模式 中国科学院软件研究所 41 实施质量管理体系的意义 管理法治化 职责更分明 接口更明确 监督机制加强 焦点得到控制 竞争能力增强 中国科学院软件研究所 42 实施质量管理体系工作重点 规范管理制度 增进内部沟通 提高服务质量 增强社会信心 中国科学院软件研究所 43 小结 小结 中国科学院软件研究所 44 软件开发中的困境 如何指定符合项目的计划 项目应该如何去完成 如何按期提交项目 如何降低项目的风险 项目中的人员流动很频繁怎么办 如何合理的安排已有人员 项目不断变大，文档和程序不断的增多 用户的需求在不断的变化 项目中的人员在增加，如何管理好 项目的质量如何控制 中国科学院软件研究所 45 软件开发过程的模型 简单式 (构建维护 ) 瀑布式 敏捷开发 统一软件开发过程 中国科学院软件研究所 46 简单式 修改直到用户满意 系统使用 消亡 思路或者客户需求 构建第一个版本 中国科学院软件研究所 47 简单式过程开发特征 系统在没有任何规范和规则的情况下就开发 没有明确的设计，设计思路都在开发者的头脑中 这种开发方法对于使用周期很短的小项目可用 随着时间的推移，系统的维护越来越困难 系统在交付使用时，有可能会出现一系列的错误，前期和后期维护成本都很高 在大型项目和商用项目中极少使用 中国科学院软件研究所 48 瀑布式 设计阶段 实现阶段 集成阶段 需求阶段 细化阶段 使用阶段 消亡 每个阶段做完时进行验证 中国科学院软件研究所 49 瀑布式开发 70年代流行的开发方法 自上而下的开发方法 每个阶段都有软件质量管理组核实后再进行下一阶段的开发 每一阶段都有测试 每个阶段都形成了明确的文档 文档并不总能和系统相符合 细化的文档使得系统的用户和开发人员难于理解和分辨系统的关系 阶段之间的对应和检查变得困难、维护代价高 变更应对能力差 中国科学院软件研究所 50 敏捷开发 快速适应系统需求的变化 提高软件生产率 突出企业自身特点，体现企业核心能力 支持动态联盟和虚拟组织 面向业务目标持续改进和重组 中国科学院软件研究所 51 敏捷开发的特征 轻量级的开发过程 基于时间 Just Enough 并行 基于组件的软件工程 中国科学院软件研究所 52 敏捷开发过程 软件的需求是难以预期的，开发方法必需适应变化的需求，在快速的迭代中不断改进 小组成员并不完全按照完整的方法进行开发，而 根据具体问题和情况，灵活地去除非增值活动 仅仅执行一些必须的活动，使用必须的规则，编 写必须的文档 人的因素被放在第一 适合互联网时代的开发要求 中国科学院软件研究所 53 主要敏捷开发方法 eXtreme Programming (XP) SCRUM DSDM Adaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Family Rational RUP & UML 中国科学院软件研究所 54 统一软件开发过程 用例驱动 用例 :能向用户提供有价值的系统的某种功能 以架构为中心 软件架构：系统的最重要的静态和动态特征 迭代和增量式 迭代：工作流程的重复、每次的活动都以上次的活动为基础 中国科学院软件研究所 55 用例驱动 用户所希望和需要的是什么 系统能为每个用户提供什么功能 用例所描述和代表的是用户与系统交互的一个过程，而这个过程满足了用户的某些需求 所强调的是系统的功能 中国科学院软件研究所 56 以架构为中心 刻画了系统的整体设计，忽略了细节设计，刻画最重要的部分。 什么是最重要的呢？依赖于判断。判断的依据是经验。 构架的设计价值取决于执行该任务的人的素质 受用户需求（用户可能会增加那方面的需求）、软件应用平台（计算机硬件、操作系统、数据库、网络等）、实施问题、遗留系统集成等的影响 中国科学院软件研究所 57 用例和架构 用例是系统的功能和外衣 架构是系统的内在形式 两方面必须并行进化 架构只考虑核心功能 (5-10%) 架构设计原则： 先考虑与用例无关的不会变动的方面考虑 考虑最重要的功能需求子集 中国科学院软件研究所 58 迭代和增量式 控制迭代过程，划分每次迭代的目标 迭代原则： 架构上先实现最粗略的部分 功能上先实现最重要的 每次迭代尽可能的划分的细，迭代数量不能太少 每次迭代要有规范的检查机制 增量式 每次迭代增加一部分设计和实现 中国科学院软件研究所 59 统一软件过程的生命周期 在软件过程中，不断的向用户提供新的版本 每次形成的版本构成了一个循环 中国科学院软件研究所 60 每个版本形成的过程 每次循环由四个阶段构成 初始 想法 产品 系统向用户提供的功能是什么 系统的架构是什么样子的 开发计划、开支如何、人员安排 细化 详细说明产品的功能 设计系统的架构 构造 构造能运行的产品 移交 产品手册、测试手册、用户培训、技术支持 中国科学院软件研究所 61 产品版本形成的迭代过程 中国科学院软件研究所 62 核心工作流程和四个阶段 中国科学院软件研究所 63 产品版本的相关模型 用例模型：系统的功能和用户的关系 分析模型：提炼用例，将用例的实现分配给一组对象 设计模型：静态结构和动态结构 子系统、类、接口 实现模型：类、接口到组件的映射 实施模型：组件到部署物理节点的映射 测试模型：测试用例和用例的映射 中国科学院软件研究所 64 产品版本的相关模型 中国科学院软件研究所 65 模型间的依赖关系 迭代的过程使得每次迭代过程中依赖关系的复杂程度降低 中国科学院软件研究所 66 软件过程具体化 没有通用的软件过程 组织因素：组织结构、文化、管理、能力、经验等 领域因素：应用领域的熟悉、竞争对手的提供产品的影响 生命周期因素：时间、专业技能 技术因素：程序设计语言、开发工具、数据库系统、框架等 中国科学院软件研究所 67 Capability Maturity Model 软件能力成熟度模型 迄今为止学术界和工业界公认的有关软件工程和管理实践的最好的 评价模型 。 为评估软件组织的生产能力提供了标准 。 为提高软件组织的生产过程指明了方向。 中国科学院软件研究所 68 CMM概述 一个成熟软件组织具有在全组织范围内管理软件、开发过程和维护过程的能力 规定的软件过程被正确无误地通知到所有员工 工作活动均按照已规划的过程进行 ，并 通过可控的先导性试验和费效分析使这些过程得到改进 对已定义过程中的所有岗位及其职责都有清楚的描述 通过文档与培训使全组织有关人员对已定义的软件过程都有很好的理解，从而使其软件过程所导致的生产率和质量能随时间的推移得到改进。 中国科学院软件研究所 69 CMM基本概念 软件过程 ：人们用于开发和维护软件及其相关过程的一系列活动，包括软件工程活动和软件管理活动。 软件过程能力 ：描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。 软件过程性能 ：表示（开发组织或项目组）遵循其软件过程所得到的实际结果，软件过程性能描述的是已得到的实际结果，而软件过程能力则描述的是最可能的预期结果，它既可对整个软件开发组织而言，也可对一个特定项目而言。 软件过程成熟 ：一个特定软件过程被明确和有效地定义，管理测量和控制的程度。 中国科学院软件研究所 70 CMM基本概念 软件能力成熟度等级 ：软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台。 关键过程域 ：每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程域，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域，反之有非关键过程域是指对达到相应软件成熟度等级的目标不起关键作用。归纳为：互相关联的若干软件实践活动和有关基础设施的一个集合。 中国科学院软件研究所 71 CMM基本概念 关键实践 ：对关键过程域的实践起关键作用的方针、规程、措施、活动以及相关基础设施的建立。关键实践一般只描述“做什么”而不强制规定“如何做”。整个软件过程的改进是基于许多小的、渐进的步骤，而不是通过一次革命性的创