软件项目开发

1、1,项目模拟/实战训练第一部分 软件工程,2,本讲内容,1软件工程概述 2软件工程过程和活动 3软件过程模型 4 软件过程成熟度模型CMM,3,1 软件工程概述,1.1 软件的概念 1.2 为什么要软件工程 1.3 什么是软件工程 1.4 参考书目,4,1.1 软件的概念,定义 Program + Data Structure + Documents 软件的性质 复杂性 难以描述性 不可见性 变化性,易于副本的大批量生产 强合作性,5,1.2 为什么要软件工程,软件危机 爆发时间 1967年NATO的研究组首次提出 1968年NATO软件工程会议首次提出软件工程概念 1968-2013, 近4

2、0多年 “危机”一词 软件危机依然存在,Crisis！,6,1.2 为什么要软件工程,软件危机面对的问题 艺术 vs. 标准化 错误的发现 软件需求获取 软件支持和维护 开发速度 vs. 市场需求 开发周期过长、开发成本过高 研发风险 软件开发中的复杂的协作(人员,问题,过程) 不同角色的软件神话(管理者,用户,开发者,大众),7,1.2 为什么要软件工程,采用什么方法缓解危机 硬件 ? 建筑学? 拍电影? 软件工程！,8,1.3 什么是软件工程,Fritz Bauer: “建立和应用完善的工程原理以便经济地得到在真实机器上可靠和有效运行的软件。 特点：重原理、轻技术、无度量 IEEE： (1

3、)应用系统的有规则的定量的方法开发、使用和维护软件；即应用工程于软件。 (2)研究(1)中的方法 特点：粗糙,9,1.3 什么是软件工程,Definition 软件工程是以质量为核心，为了经济地开发满足客户需求的软件而研究、建立和应用的系统化的、有规则的、可度量的和可控制的工程原则、方法，涉及到软件过程、项目管理、开发方法、软件复用、软件度量、开发工具，甚至企业文化等各个方面。,10,1.3 什么是软件工程,11,1.4 软件工程参考书目,12,2 过程和活动,2.1 软件过程的概念 2.2 问题定义活动 2.3 可行性研究活动 2.4 需求分析活动 2.5 设计活动 2.6 实施活动 2.7

4、 测试活动 2.8 部署活动,13,2.1 软件过程的概念,软件过程的定义 软件过程由开发或维护软件及其相关产品的一系列活动构成，这些活动从不同的方面定义了软件开发中的步骤、交付物、涉众及其职责等流程要素,14,2.1 软件过程的概念,Process,控制/约束,输入,资源,输出,15,2.1 软件过程的概念,What,How,Change,16,2.1 软件过程的概念,17,2.1 软件过程的概念,Basic Activities(基础活动) 问题定义，需求，设计，实b现，软件验证，集成，软件演进/维护，退役 Umbrella Activities (辅助性活动) 软件项目跟踪和控制，正式的

5、技术复审，软件质量保证，软件配置管理，文档编制，复用管理，度量，风险管理，,Something that covers or protects. 保护物覆盖或保护的事物,18,2.2 问题定义活动,What 问题定义是软件开发过程当中的一个定义要解决的问题并确定系统范围的活动。 Why 形成一个早期判断，达成一个最初共识 When 项目日程表的最前端 占整个软件开发时间中的比例很小,19,2.2 问题定义活动,Who 系统分析师、出资方领导、出资方技术人员、开发方领导和项目经理 Where 客户现场,20,2.2 问题定义活动,How,21,2.3 可行性研究活动,What 可行性研究是以相对

6、短的时间和相对低的成本来确定给定的问题在其约束条件内是否有解、有几种解以及哪个是最佳解。 Why 必须要先确立满足约束条件的方案是否存在、是否可行、是否最优，然后再在最优方案的基础上进行开发,22,2.3 可行性研究活动,When 项目的早期阶段 占整个软件开发时间中的比例较小，但比问题定义活动所消耗的时间长 Who 系统分析师、出资方领导、出资方技术人员、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，Software Quality Assure）人员等 Where 客户现场。,23,2.3 可行性研究活动,How,How,24,2.4 需求

7、分析活动,What 需求：主要是在产品构建之前确定的系统必须符合的条件或具备的功能，它们是关于系统将要完成什么工作的一段描述语句，它们必须经过所有相关人员的认可，其目的是彻底地解决客户的问题。 需求文档 一组需求的集合 用户需求文档、系统需求文档和软件规约文档,25,2.4 需求分析活动,功能性需求和非功能性需求 功能性需求：描述了系统应该做什么，即具备的功能或服务。（输入、输出和计算等） 非功能性需求：描述了系统必须遵守的约束条件。（响应时间、吞吐量 、可靠性、可移植性、可扩展性、易用性、安全性、资源要求、可复用性、技术要求、文化和政策需求、法律需求、道德要求、隐私要求，等等） 描述需求的标

8、准 是完整的、正确的、必要的、无歧义的、可行的、可验证的以及被设置了优先级别的。,What,26,2.4 需求分析活动,Why 需求不一致、模糊、矛盾 需求变更 客户忽略领域常识/知识/术语 客户集中于现有系统的不足之处，而忽略了系统要实现的关键功能 零碎、无组织、不明确、表达不清 不分轻重缓急,27,2.4 需求分析活动,When 项目的早期阶段？,贯穿于整个软件开发过程的需求活动,28,2.4 需求分析活动,Who 系统分析师、需求阐释者、客户代表、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，Software Quality Assure

9、）人员、程序员、测试人员、部署人员、技术文档编写人员、培训人员等。 Where 调研时，在客户现场 编写软件需求规约文档时，可以在开发单位 复审相关的需求文档时，根据需要来安排,29,2.4 需求分析活动,How,30,2.5 设计活动,What 设计： 是在系统的约束条件下（如预算、时间、人力资源、用户软、硬件环境和用户对系统的操作能力等），为了实现系统的功能性需求和非功能性需求，而找到并描述的一种遵循高质量的通用原则的方法，其交付文档能够指导开发人员实现系统。,31,2.5 设计活动,总体设计 根据软件需求规约文档，确定一个合理的软件体系结构。这个体系结构包括合理地划分组成系统的模块、模块

10、间的调用关系以及模块间的接口关系。软件体系结构还从总体方面决定了系统的可扩充性、可维护性，以及系统的性能等。总体设计的设计粒度较大，有时也被称为概要设计、架构设计。,32,2.5 设计活动,详细设计 详细设计地任务是在总体设计的基础上进一步确定如何实现目标系统，包括系统的数据对象的设计、人机接口的设计以及模块逻辑的详细设计。 设计部件的粒度 系统、子系统、框架、构件、组件、模块、类、方法等,33,2.5 设计活动,Why 软件架构是软件系统的核心 应对复杂多变的情况，同时保持完整性 应对系统在扩展功能当中出现的问题 大规模复用的有效基础 项目管理的基础,34,2.5 设计活动,When 项目的

11、中、早期阶段？,工作量,早期 中期 后期,项目时间,大 小,贯穿于整个软件开发过程的设计活动,35,2.5 设计活动,Who 主要包括架构设计师、软件设计员、复用工程师、设计复审员、项目经理、财务人员、软件质量保证（SQA，Software Quality Assure）人员和需求变更者等 Where 建议在软件企业内部进行设计,36,2.5 设计活动,How,37,2.6 实施活动,What 编码：是将软件设计结果转换成用某种程序设计语言书写的程序。 单元测试：是把一个模块作为独立的程序单元进行测试，以保证它能够正确执行规定的功能。 集成：是指将单独的软件构件合并成一个整体的软件系统。集成分

12、为集成子系统和集成系统两个级别：,38,2.6 实施活动,Why 以实施为中心的软件开发 弱化的需求 弱化的设计 对实施人员的过度依赖,39,2.6 实施活动,Why 将单元测试作为实施的一部分 When 项目的中、后期阶段,工作量,早期 中期 后期,项目时间,大 小,贯穿于整个软件开发过程的实施活动,40,2.6 实施活动,Who 包括实施员、代码复审员、集成员、测试工程师、测试员、项目经理、架构设计师、软件设计员、复用工程师、SQA人员和财务人员等 Where 建议在软件企业内部进行开发,41,2.6 实施活动,How,42,2.7 测试活动,What 测试：是选择适当的测试用例执行被测程

13、序的过程，其目的在于发现程序错误。 缺陷：是系统任一方面（包括需求、设计或代码）的缺点。该缺点会促成或潜在的促成一个或多个失败发生。 错误：是指程序中的缺陷所产生的不正确结果。 失败：当一个程序不能运行或者其表现不可被接受时称为失败。失败是系统执行中出现的情况。失败源于代码缺陷。 单元测试、集成测试、系统测试、(alpha)、(Beta) 验收测试,43,2.7 测试活动,质量维度：描述质量的概念或评测质量的方法的不同视角 可靠性维度 可用性维度 性能维度 测试用例：为特定目标开发的测试输入、执行条件和预期结果的集合。,44,2.7 测试活动,When 项目的后期阶段？ 优点 缩短测试时间 易

14、于定位缺陷 避免错上加错,工作量,早期 中期 后期,项目时间,大 小,45,2.7 测试活动,Who 主要包括测试工程师、测试员、软件设计员、实施员、项目经理、部署工程师、部署员、SQA人员和财务人员等 Where 建议单元测试、集成测试和系统测试在实施员所在的开发现场及其附近进行 测试和验收测试则完全在用户现场测试,46,2.7 测试活动 (5/5),How,47,2.8 部署活动,What 部署：是为确保最终用户可以正常使用软件产品而进行的活动。 根据产品类型，可以将部署分为三种模式: 自定义安装模式 现场支持模式 Internet模式,48,2.8 部署活动,部署单元：由一个工作版本（可

15、执行构件集）、文档（最终用户支持材料和发布说明）和安装工件组成 部署计划：说明如何将产品从开发商转移到用户群 兼容、转换和迁移策略 部署时间表 部署顺序 用户培训,49,2.8 部署活动,When 项目的后期阶段？,工作量,早期 中期 后期,项目时间,大 小,50,2.8 部署活动,Who 主要包括部署工程师、部署员、文档编写员、包装员、实施员、项目经理、SQA人员和财务人员等 Where 一部分工作可以在开发现场进行，如制定部署计划、包装产品、编写相关文档等； 另一部分工作必须在用户现场进行，如测试、验收测试和用户正式使用中的安装、培训工作等。,51,2.8 部署活动,How,52,3 软件

16、过程模型,3.1 过程模型概念 3.2 线形顺序模型系列 3.3 演进模型系列 3.4 其它模型系列 3.5 过程模型的选择,53,3.1 过程模型概念,为什么需要模型? 模型帮助我们解释事物如何工作 模型能够拓宽我们的视野(抽象) 软件过程模型 一个过程模型是一个过程的抽象表示 过程模型帮助我们更好地理解软件开发,54,3.1 过程模型概念(2/5),55,3.1 过程模型概念,56,3.1 过程模型概念,57,3.1 过程模型概念,经典模型 Linear Sequential Model Waterfall Model V Model Department of Defense Model

17、 RAD Model,Prototyping Model Build-and-Fix Model Incremental Model Spiral Model Concurrent Development Model XP Model RUP Model,58,3.2 线形顺序模型系列,线性顺序模型,59,3.2 线形顺序模型系列,瀑布模型,60,特征 接受上一阶段的结果作为本阶段的输入 开发阶段严格按线性方式进行 对本阶段的工作进行评审 每一阶段具有相关的里程碑和交付产品 缺点 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发 开发早期存在的问题往往要到交付使用时才发现，维护代价大 适

18、用 在开发的早期阶段软件需求被完整确定,3.2 线形顺序模型系列,61,实际使用的瀑布模型,3.2 线形顺序模型系列,62,3.2 线形顺序模型系列,V 模型,63,3.2 线形顺序模型系列,RAD (Rapid Application Development)模型,60 90 days,64,3.3 演进模型系列,原型模型,Listen to customer,build/revisemock-up,customer test-drives mock-up,65,3.3 演进模型系列,边建边改 Model,66,3.3 演进模型系列,边建边改 Model(续),67,3.3 演进模型系列,增

19、量模型,System/Information engineering,analysis,design,Code,Test,增量一,交付1,analysis,design,Code,test,增量二,analysis,design,Code,test,增量三,analysis,design,Code,test,增量四,Calendar Time,交付2,交付3,交付5,68,3.3 演进模型系列,CustomerCommunication,Risk Analysis,Engineering,Construction & Release,Planning,CustomerEvaluation,Pr

20、oject entryPoint axis,螺旋模型,69,3.3 演进模型系列,XP 模型，一种敏捷开发方法,70,3.4 其它模型系列,构件组装模型 与瀑布模型对比,71,3.4 其它模型系列,72,各种模型的比较,73,3.5 过程模型的选择,软件工程过程模型的选择是基于: 项目的应用特点 采用的方法和工具 需要的控制 交付的产品,74,3.5 过程模型总结,在前期需求明确，尽量采用瀑布模型 用户没有信息系统使用经验，需求分析人员技能不足，采用原型 不确定因素很多，无法一下子计划，采用增量或螺旋 需求不稳定，采用增量 资金和成本无法一次到位，采用增量 可以各种模型合并使用，但每一次必须要

21、有明确的交付物和出口准则 编程人员经验较少，不宜采用快速的方法,75,4 软件过程能力成熟度,76,4 能力成熟度模型CMM,CMM（Capability Maturity Model）即能力成熟度模型，是美国卡耐基梅隆大学软件工程研究所（SEI）建立的，用于评价软件机构的软件过程能力成熟度的模型。 此模型建立之初的主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程。,77,软件组织的成熟与不成熟,不成熟的软件组织 软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划 有时，

22、即使软件过程已计划好，仍不按计划执行 没有一个客观的基准来判断产品质量，或解决产品和过程中的问题 对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查、测试等经常由于要赶进度而减少或取消,4 能力成熟度模型CMM,78,产品在交付前，对客户来说，一切都是不可见的 没有长远目标，管理员通常只关注解决任何当前的危机 由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度,4 能力成熟度模型CMM,79,2.成熟的软件组织 具有全面而充分的组织和管理软件开发和维护过程的能力 管理员监视软

23、件产品的质量以及生产这些产品的过程。 制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题。 进度和预算可以按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的。,4 能力成熟度模型CMM,80,能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(前后一致，不互相矛盾)工作 凡规定的过程都编成文档 软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本-效益分析来改进过程。 全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，各守其责，协同工作，有条不紊，甚至

24、能预见和防范问题的发生。,4 能力成熟度模型CMM,81,CMM的组成,4 能力成熟度模型CMM,82,4 能力成熟度模型CMM,83,CMM提供了一个成熟度等级框架：1级-初始级、2级-可重复级、3级-已定义级、4级-已管理级和5级-优化级。 1.初始（initial）级： 软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。 2.可重复（repeatable）级： 建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。,4 能力成熟度模型CMM,84,3.已定义（defined）级：

25、 己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。 4.已管理（managed）级： 收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。 5.优化（optimizing）级： 整个组织关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进。,4 能力成熟度模型CMM,85,成熟度等级表明了一个软件组织的过程能力的水平。除初始级外，每个成熟度等级都包含若干个关键过程域（Key Process Area，简称KPA） 达到

26、某个成熟度级别，该级别（以及较低级别）的所有关键过程域都必须得到满足，并且过程必须实现制度化。,4 能力成熟度模型CMM,86,能力成熟度级别中的关键过程域18个,优化级,已管理级,已定义级,可重复级,初始级,4 能力成熟度模型CMM,6个,7个,2个,3个,87,能力成熟度模型集成CMMICapability Maturity Model Integration,CMM的成功导致了各种模型的衍生，每一种模型都探讨了某一特定领域中的过程改进问题 SW-CMM：适用于软件开发 SE-CMM：系统工程能力成熟度模型 SA-CMM：适用于软件获取 SECAM：系统工程能力评估模型 People CMM：讨论