软件项目开发课件

/实战训练

第一部分软件工程1/实战训练

第一部分软件工程1本讲内容1 软件工程概述2 软件工程过程和活动3 软件过程模型4软件过程成熟度模型CMM2本讲内容1 软件工程概述21软件工程概述1.1软件的概念1.2为什么要软件工程1.3什么是软件工程1.4参考书目31软件工程概述1.1软件的概念31.1软件的概念定义Program+DataStructure+Documents

软件的性质复杂性难以描述性不可见性变化性易于副本的大批量生产强合作性41.1软件的概念定义41.2为什么要软件工程软件危机爆发时间1967年NATO的研究组首次提出1968年NATO软件工程会议首次提出软件工程概念1968-2013,近40多年“危机”一词软件危机依然存在Crisis！51.2为什么要软件工程软件危机Crisis！51.2为什么要软件工程软件危机面对的问题艺术vs.标准化错误的发现软件需求获取软件支持和维护开发速度vs.市场需求开发周期过长、开发成本过高研发风险软件开发中的复杂的协作(人员,问题,过程)不同角色的软件神话(管理者,用户,开发者,大众)61.2为什么要软件工程软件危机面对的问题61.2为什么要软件工程采用什么方法缓解危机硬件?建筑学?拍电影?……软件工程！71.2为什么要软件工程采用什么方法缓解危机71.3什么是软件工程FritzBauer:“建立和应用完善的工程原理以便经济地得到在真实机器上可靠和有效运行的软件。特点：重原理、轻技术、无度量IEEE：(1)应用系统的有规则的定量的方法开发、使用和维护软件；即应用工程于软件。(2)研究(1)中的方法特点：粗糙81.3什么是软件工程FritzBauer:81.3什么是软件工程Definition软件工程是以质量为核心，为了经济地开发满足客户需求的软件而研究、建立和应用的系统化的、有规则的、可度量的和可控制的工程原则、方法，涉及到软件过程、项目管理、开发方法、软件复用、软件度量、开发工具，甚至企业文化等各个方面。

91.3什么是软件工程Definition9

AQualityFocusProcessMethodsCASETools1.3什么是软件工程10CASE1.4软件工程参考书目111.4软件工程参考书目112过程和活动2.1软件过程的概念2.2问题定义活动2.3可行性研究活动2.4需求分析活动2.5设计活动2.6实施活动2.7测试活动2.8部署活动122过程和活动2.1软件过程的概念122.1软件过程的概念软件过程的定义软件过程由开发或维护软件及其相关产品的一系列活动构成，这些活动从不同的方面定义了软件开发中的步骤、交付物、涉众及其职责等流程要素

132.1软件过程的概念软件过程的定义132.1软件过程的概念Buildthe

System控制

预算,计划表,标准输入需求

资源

人员,工具输出代码,文档Process控制/约束输入资源输出142.1软件过程的概念Buildthe

System控制2.1软件过程的概念WhatHowChange152.1软件过程的概念WhatHowChange152.1软件过程的概念162.1软件过程的概念162.1软件过程的概念BasicActivities(基础活动)问题定义，需求，设计，实b现，

软件验证，集成，软件演进/维护，退役UmbrellaActivities(辅助性活动)软件项目跟踪和控制，正式的技术复审，

软件质量保证，软件配置管理，文档编制，复用管理，度量，风险管理，…Somethingthatcoversorprotects.保护物覆盖或保护的事物172.1软件过程的概念BasicActivities(基础2.2问题定义活动What问题定义是软件开发过程当中的一个定义要解决的问题并确定系统范围的活动。Why形成一个早期判断，达成一个最初共识

When

项目日程表的最前端占整个软件开发时间中的比例很小

182.2问题定义活动What182.2问题定义活动Who系统分析师、出资方领导、出资方技术人员、开发方领导和项目经理

Where客户现场

192.2问题定义活动Who192.2问题定义活动How202.2问题定义活动How202.3可行性研究活动What可行性研究是以相对短的时间和相对低的成本来确定给定的问题在其约束条件内是否有解、有几种解以及哪个是最佳解。

Why必须要先确立满足约束条件的方案是否存在、是否可行、是否最优，然后再在最优方案的基础上进行开发

212.3可行性研究活动What212.3可行性研究活动When项目的早期阶段占整个软件开发时间中的比例较小，但比问题定义活动所消耗的时间长Who系统分析师、出资方领导、出资方技术人员、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，SoftwareQualityAssure）人员等Where客户现场。222.3可行性研究活动When222.3可行性研究活动HowHow232.3可行性研究活动HowHow232.4需求分析活动What需求：主要是在产品构建之前确定的系统必须符合的条件或具备的功能，它们是关于系统将要完成什么工作的一段描述语句，它们必须经过所有相关人员的认可，其目的是彻底地解决客户的问题。

需求文档一组需求的集合用户需求文档、系统需求文档和软件规约文档242.4需求分析活动What242.4需求分析活动功能性需求和非功能性需求

功能性需求：描述了系统应该做什么，即具备的功能或服务。（输入、输出和计算等）非功能性需求：描述了系统必须遵守的约束条件。（响应时间、吞吐量、可靠性、可移植性、可扩展性、易用性、安全性、资源要求、可复用性、技术要求、文化和政策需求、法律需求、道德要求、隐私要求，等等）

描述需求的标准是完整的、正确的、必要的、无歧义的、可行的、可验证的以及被设置了优先级别的。

What252.4需求分析活动功能性需求和非功能性需求What252.4需求分析活动Why需求不一致、模糊、矛盾需求变更客户忽略领域常识/知识/术语客户集中于现有系统的不足之处，而忽略了系统要实现的关键功能零碎、无组织、不明确、表达不清不分轻重缓急

262.4需求分析活动Why262.4需求分析活动When项目的早期阶段？贯穿于整个软件开发过程的需求活动272.4需求分析活动When贯穿于整个软件开发过程的需求活动2.4需求分析活动Who系统分析师、需求阐释者、客户代表、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，SoftwareQualityAssure）人员、程序员、测试人员、部署人员、技术文档编写人员、培训人员等。Where调研时，在客户现场编写软件需求规约文档时，可以在开发单位复审相关的需求文档时，根据需要来安排282.4需求分析活动Who282.4需求分析活动How292.4需求分析活动How292.5设计活动What设计：是在系统的约束条件下（如预算、时间、人力资源、用户软、硬件环境和用户对系统的操作能力等），为了实现系统的功能性需求和非功能性需求，而找到并描述的一种遵循高质量的通用原则的方法，其交付文档能够指导开发人员实现系统。302.5设计活动What302.5设计活动总体设计根据软件需求规约文档，确定一个合理的软件体系结构。这个体系结构包括合理地划分组成系统的模块、模块间的调用关系以及模块间的接口关系。软件体系结构还从总体方面决定了系统的可扩充性、可维护性，以及系统的性能等。总体设计的设计粒度较大，有时也被称为概要设计、架构设计。312.5设计活动总体设计312.5设计活动详细设计详细设计地任务是在总体设计的基础上进一步确定如何实现目标系统，包括系统的数据对象的设计、人机接口的设计以及模块逻辑的详细设计。设计部件的粒度系统、子系统、框架、构件、组件、模块、类、方法等322.5设计活动详细设计322.5设计活动Why软件架构是软件系统的核心应对复杂多变的情况，同时保持完整性应对系统在扩展功能当中出现的问题大规模复用的有效基础项目管理的基础332.5设计活动Why332.5设计活动When项目的中、早期阶段？工作量早期中期后期项目时间大小贯穿于整个软件开发过程的设计活动342.5设计活动When工作量早期2.5设计活动Who主要包括架构设计师、软件设计员、复用工程师、设计复审员、项目经理、财务人员、软件质量保证（SQA，SoftwareQualityAssure）人员和需求变更者等Where建议在软件企业内部进行设计352.5设计活动Who352.5设计活动How362.5设计活动How362.6实施活动What编码：是将软件设计结果转换成用某种程序设计语言书写的程序。单元测试：是把一个模块作为独立的程序单元进行测试，以保证它能够正确执行规定的功能。集成：是指将单独的软件构件合并成一个整体的软件系统。集成分为集成子系统和集成系统两个级别：372.6实施活动What372.6实施活动Why以实施为中心的软件开发弱化的需求弱化的设计对实施人员的过度依赖382.6实施活动Why382.6实施活动Why将单元测试作为实施的一部分When项目的中、后期阶段

工作量早期中期后期项目时间大小贯穿于整个软件开发过程的实施活动392.6实施活动Why工作量早期2.6实施活动Who包括实施员、代码复审员、集成员、测试工程师、测试员、项目经理、架构设计师、软件设计员、复用工程师、SQA人员和财务人员等Where建议在软件企业内部进行开发

402.6实施活动Who402.6实施活动How412.6实施活动How412.7测试活动What测试：是选择适当的测试用例执行被测程序的过程，其目的在于发现程序错误。

缺陷：是系统任一方面（包括需求、设计或代码）的缺点。该缺点会促成或潜在的促成一个或多个失败发生。错误：是指程序中的缺陷所产生的不正确结果。失败：当一个程序不能运行或者其表现不可被接受时称为失败。失败是系统执行中出现的情况。失败源于代码缺陷。单元测试、集成测试、系统测试、α(alpha)、β(Beta)

验收测试422.7测试活动What422.7测试活动质量维度：描述质量的概念或评测质量的方法的不同视角可靠性维度可用性维度性能维度测试用例：为特定目标开发的测试输入、执行条件和预期结果的集合。

432.7测试活动质量维度：描述质量的概念或评测质量的方法的不2.7测试活动When项目的后期阶段？优点缩短测试时间易于定位缺陷避免错上加错

工作量早期中期后期项目时间大小442.7测试活动When工作量早期2.7测试活动Who主要包括测试工程师、测试员、软件设计员、实施员、项目经理、部署工程师、部署员、SQA人员和财务人员等Where建议单元测试、集成测试和系统测试在实施员所在的开发现场及其附近进行β测试和验收测试则完全在用户现场测试452.7测试活动Who452.7测试活动(5/5)How462.7测试活动(5/5)How462.8部署活动What部署：是为确保最终用户可以正常使用软件产品而进行的活动。根据产品类型，可以将部署分为三种模式:自定义安装模式现场支持模式Internet模式

472.8部署活动What472.8部署活动部署单元：由一个工作版本（可执行构件集）、文档（最终用户支持材料和发布说明）和安装工件组成部署计划：说明如何将产品从开发商转移到用户群兼容、转换和迁移策略部署时间表部署顺序用户培训

482.8部署活动部署单元：由一个工作版本（可执行构件集）、文2.8部署活动When项目的后期阶段？工作量早期中期后期项目时间大小492.8部署活动When工作量早期2.8部署活动Who主要包括部署工程师、部署员、文档编写员、包装员、实施员、项目经理、SQA人员和财务人员等Where一部分工作可以在开发现场进行，如制定部署计划、包装产品、编写相关文档等；另一部分工作必须在用户现场进行，如β测试、验收测试和用户正式使用中的安装、培训工作等。502.8部署活动Who502.8部署活动How512.8部署活动How513软件过程模型3.1过程模型概念3.2线形顺序模型系列3.3演进模型系列3.4其它模型系列3.5过程模型的选择523软件过程模型3.1过程模型概念523.1过程模型概念为什么需要模型?模型帮助我们解释事物

如何工作模型能够拓宽我们的视野

(抽象)软件过程模型一个过程模型是一个过程的抽象表示过程模型帮助我们更好地理解软件开发533.1过程模型概念为什么需要模型?533.1过程模型概念(2/5)543.1过程模型概念(2/5)543.1过程模型概念553.1过程模型概念553.1过程模型概念563.1过程模型概念563.1过程模型概念经典模型LinearSequentialModelWaterfallModelVModelDepartmentofDefense

ModelRADModelPrototypingModelBuild-and-FixModel

IncrementalModelSpiralModelConcurrentDevelopmentModelXPModelRUPModel573.1过程模型概念经典模型PrototypingMode3.2线形顺序模型系列线性顺序模型analysisdesigncodetestSystem/information

engineering583.2线形顺序模型系列线性顺序模型analysisdesi3.2线形顺序模型系列瀑布模型593.2线形顺序模型系列瀑布模型59特征接受上一阶段的结果作为本阶段的输入开发阶段严格按线性方式进行对本阶段的工作进行评审每一阶段具有相关的里程碑和交付产品缺点缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发开发早期存在的问题往往要到交付使用时才发现，维护代价大适用在开发的早期阶段软件需求被完整确定3.2线形顺序模型系列60特征3.2线形顺序模型系列60实际使用的瀑布模型3.2线形顺序模型系列61实际使用的瀑布模型3.2线形顺序模型系列613.2线形顺序模型系列V模型623.2线形顺序模型系列V模型623.2线形顺序模型系列RAD(RapidApplicationDevelopment)模型60~90days633.2线形顺序模型系列RAD(RapidApplica3.3演进模型系列原型模型Listento

customerbuild/revise

mock-upcustomertest

-drivesmock-up643.3演进模型系列原型模型Listento

custo3.3演进模型系列边建边改ModelBuildfirst

versionModifyuntil

clientissatisfiedMaintenance

phaseRetirementDevelopmentMaintenance653.3演进模型系列边建边改ModelBuildfirs3.3演进模型系列边建边改Model(续)663.3演进模型系列边建边改Model(续)663.3演进模型系列增量模型System/InformationengineeringanalysisdesignCodeTest增量一交付1analysisdesignCodetest增量二analysisdesignCodetest增量三analysisdesignCodetest增量四CalendarTime交付2交付3交付5673.3演进模型系列增量模型System/Informati3.3演进模型系列Customer

CommunicationRiskAnalysisEngineeringConstruction&ReleasePlanningCustomer

EvaluationProjectentry

Pointaxis螺旋模型683.3演进模型系列Customer

Communicati3.3演进模型系列XP模型，一种敏捷开发方法693.3演进模型系列XP模型，一种敏捷开发方法693.4其它模型系列构件组装模型与瀑布模型对比703.4其它模型系列构件组装模型703.4其它模型系列应用构件提取车间构件生产车间标准规范与质量保证1基础构件，2功能构件3接口构件，4用户界面构件

应用构件库

构件库组装车间领域

1领域

2应用系统...1234713.4其它模型系列应用构件构件生标准规范各种模型的比较模型优点缺点瀑布模型规范，文档驱动系统可能不满足客户真正的需求快速原型克服了瀑布型的缺点增量模型开发早期回报明确，易于维护要求开放的软件体系结构螺旋模型风险驱动，适用于大型项目开发风险分析人员需要有经验且经过充分训练72各种模型的比较模型优点缺点瀑布模型规范，文档驱动系统可能不满3.5过程模型的选择软件工程过程模型的选择是基于:项目的应用特点采用的方法和工具需要的控制交付的产品733.5过程模型的选择软件工程过程模型的选择是基于:733.5过程模型总结在前期需求明确，尽量采用瀑布模型用户没有信息系统使用经验，需求分析人员技能不足，采用原型不确定因素很多，无法一下子计划，采用增量或螺旋需求不稳定，采用增量资金和成本无法一次到位，采用增量可以各种模型合并使用，但每一次必须要有明确的交付物和出口准则编程人员经验较少，不宜采用快速的方法743.5过程模型总结在前期需求明确，尽量采用瀑布模型744软件过程能力成熟度754软件过程能力成熟度754能力成熟度模型CMM

CMM（CapabilityMaturityModel）即能力成熟度模型，是美国卡耐基梅隆大学软件工程研究所（SEI）建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型建立之初的主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程。764能力成熟度模型CMMCMM（Capability软件组织的成熟与不成熟不成熟的软件组织软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划有时，即使软件过程已计划好，仍不按计划执行没有一个客观的基准来判断产品质量，或解决产品和过程中的问题对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查、测试等经常由于要赶进度而减少或取消4能力成熟度模型CMM77软件组织的成熟与不成熟不成熟的软件组织4能力成熟度模型CM产品在交付前，对客户来说，一切都是不可见的没有长远目标，管理员通常只关注解决任何当前的危机由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度4能力成熟度模型CMM78产品在交付前，对客户来说，一切都是不可见的4能力成熟度模型2.成熟的软件组织具有全面而充分的组织和管理软件开发和维护过程的能力管理员监视软件产品的质量以及生产这些产品的过程。制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题。进度和预算可以按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的。4能力成熟度模型CMM792.成熟的软件组织4能力成熟度模型CMM79能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(前后一致，不互相矛盾)工作凡规定的过程都编成文档软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本-效益分析来改进过程。全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，各守其责，协同工作，有条不紊，甚至能预见和防范问题的发生。4能力成熟度模型CMM80能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(CMM的组成4能力成熟度模型CMM81CMM的组成4能力成熟度模型CMM815.优化级4.已管理级3.已定义级2.可重复级1.初始级标准、一致的过程有纪律的过程可预测的过程持续改进的过程软件过程成熟度的5个等级4能力成熟度模型CMM825.优化级4.已管理级3.已定义级2.可重复级1.初始级标准CMM提供了一个成熟度等级框架：1级-初始级、2级-可重复级、3级-已定义级、4级-已管理级和5级-优化级。

1.初始（initial）级：软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。

2.可重复（repeatable）级：建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。4能力成熟度模型CMM83CMM提供了一个成熟度等级框架：1级-初始级、2级-可重3.已定义（defined）级：己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。

4.已管理（managed）级：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。

5.优化（optimizing）级：整个组织关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进。4能力成熟度模型CMM843.已定义（defined）级：4能力成熟度模型C

成熟度等级表明了一个软件组织的过程能力的水平。除初始级外，每个成熟度等级都包含若干个关键过程域（KeyProcessArea，简称KPA）达到某个成熟度级别，该级别（以及较低级别）的所有关键过程域都必须得到满足，并且过程必须实现制度化。4能力成熟度模型CMM85成熟度等级表明了一个软件组织的过程能力的水平。除初始级外，缺陷预防、技术更新管理、过程更改管理定量过程管理软件质量管理机构过程焦点、机构过程定义、培训大纲、综合软件管理、软件产品工程、组间协调、同行评审需求管理、软件项目计划、软件项目跟踪和监督、软件分包合同管理、软件质量保证、软件配置管理能力成熟度级别中的关键过程域18个优化级已管理级已定义级可重复级初始级4能力成熟度模型CMM6个7个2个3个86缺陷预防、技术更新管理、过程更改管理定量过程管理机构过程焦点能力成熟度模型集成CMMI

CapabilityMaturityModelIntegrationCMM的成功导致了各种模型的衍生，每一种模型都探讨了某一特定领域中的过程改进问题SW-CMM：适用于软件开发SE-CMM：系统工程能力成熟度模型SA-CMM：适用于软件获取SECAM：系统工程能力评估模型PeopleCMM：讨论软件组织吸引、开发、激励、组织和留住人才的能力EIA/IS731：替代SW-CMM和SECAMIPD-CMM：适用于集成化产品开发FAA-CMM：集成了SE-CMM、SA-CMM、SW-CMM87能力成熟度模型集成CMMI

CapabilityMatur相应的国际标准：

ISO/IEC12207（软件生存周期过程）

ISO/IEC15288（系统生存周期过程）

ISO/IEC15504（软件过程评估）模型的繁衍导致模型框架、术语等方面的矛盾和不一致包含在当代工程中各种各样的学科和工程是密切交叉在一起的，应用不同模型时效率低下且容易混淆，常常要付出极其昂贵的代价美国国防部、美国国防工业委员会和SEI/CMU于1998年启动CMMI项目，希望CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的系统的、一致的过程改进框架。4能力成熟度模型CMM88相应的国际标准：4能力成熟度模型CMM882000年发布第一个CMMI模型CMMI-SE/SW/IPPDV1.0：集成了SW-CMM、EIA/IS731、IPDCMMV0.982002年1月发布CMMI-SE/SW/IPPDV1.1，美国国防工业委员会在第一届CMMI国际研讨会上宣布，CMMIV1.1将至少稳定五年不变CMMI模型提供两种表示法：阶段式模型和连续式模型4能力成熟度模型CMM892000年发布第一个CMMI模型CMMI-SE/SW/IPP阶段式模型阶段式模型的结构类同于软件CMM，它关注组织的成熟度，其成熟度等级如下图所示

5．优化的4．定量管理的3．已定义的2．已管理的1．初始的过程不可预测且缺乏控制过程为项目服务过程为组织服务过程已度量和控制集中于过程改进阶段式成熟度等级4能力成熟度模型CMM90阶段式模型阶段式模型的结构类同于软件CMM，它关注组织的成熟CMMIV1.1的24个过程域的分组如下：成熟度等级过程域已管理的（7个）需求管理REQM，项目计划PP，项目监督和控制PMC，供应商合同管理SAM，度量和分析MA，过程和产品质量保证PPQA，配置管理CM已定义的（13个）需求开发RD，技术解决方案TS，产品集成PI，验证VER，确认VAL，组织级过程焦点OPF，组织级过程定义OPD，组织级培训OT，集成化项目管理IPM，风险管理RSKM，集成化建组IT，决策分析和解决方案DAR，组织级集成环境OEI定量管理的（2个）组织级过程性能OPP，项目定量管理QPM

优化的（2个）组织级改革和实施OID，因果分析和解决方案CAR91CMMIV1.1的24个过程域的分组如下：成熟度等级过程域连续式模型连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（Capabilitylevel，CL）。CMMI中包括六个过程域能力等级，等级号为0～5。能力等级表明了单个过程域中组织执行的好坏程度。允许组织对连续式模型的过程域进行剪裁，也允许对不同的过程域采用不同的能力等级下图给出了某组织的过程域能力等级4能力成熟度模型CMM92连续式模型连续式模型关注每个过程域的能力，一个组织对不同的过能力等级特征示意图CL0未完成的CL1已执行的CL2已管理的CL3已定义的CL4定量管理的CL5优化的过程域RSKMIPMSAMPMCPPITQPM4能力成熟度模型CMM93能力等级特征示意图CL0未完成的CL1已执行的CL2已管理的连续式分组过程域过程管理（5个）组织级过程焦点OPF，组织级过程定义OPD，组织级培训OT，组织级过程性能OPP，组织级改革和实施OID项目管理（7个）项目计划PP，项目监督和控制PMC，供应商合同管理SAM，集成化项目管理IPM，风险管理RSKM，集成化建组IT，项目定量管理QPM工程（6个）需求管理REQM，需求开发RD，技术解决方案TS，产品集成PI，验证VER，确认VAL支持（6个）配置管理CM，过程和产品质量保证PPQA，度量和分析MA，决策分析和解决方案DAR，组织级集成环境OEI，因果分析和解决方案CAR4能力成熟度模型CMM94连续式分组过程域过程管理组织级过程焦点OPF，组织级过程定义/实战训练

第一部分软件工程95/实战训练

第一部分软件工程1本讲内容1 软件工程概述2 软件工程过程和活动3 软件过程模型4软件过程成熟度模型CMM96本讲内容1 软件工程概述21软件工程概述1.1软件的概念1.2为什么要软件工程1.3什么是软件工程1.4参考书目971软件工程概述1.1软件的概念31.1软件的概念定义Program+DataStructure+Documents

软件的性质复杂性难以描述性不可见性变化性易于副本的大批量生产强合作性981.1软件的概念定义41.2为什么要软件工程软件危机爆发时间1967年NATO的研究组首次提出1968年NATO软件工程会议首次提出软件工程概念1968-2013,近40多年“危机”一词软件危机依然存在Crisis！991.2为什么要软件工程软件危机Crisis！51.2为什么要软件工程软件危机面对的问题艺术vs.标准化错误的发现软件需求获取软件支持和维护开发速度vs.市场需求开发周期过长、开发成本过高研发风险软件开发中的复杂的协作(人员,问题,过程)不同角色的软件神话(管理者,用户,开发者,大众)1001.2为什么要软件工程软件危机面对的问题61.2为什么要软件工程采用什么方法缓解危机硬件?建筑学?拍电影?……软件工程！1011.2为什么要软件工程采用什么方法缓解危机71.3什么是软件工程FritzBauer:“建立和应用完善的工程原理以便经济地得到在真实机器上可靠和有效运行的软件。特点：重原理、轻技术、无度量IEEE：(1)应用系统的有规则的定量的方法开发、使用和维护软件；即应用工程于软件。(2)研究(1)中的方法特点：粗糙1021.3什么是软件工程FritzBauer:81.3什么是软件工程Definition软件工程是以质量为核心，为了经济地开发满足客户需求的软件而研究、建立和应用的系统化的、有规则的、可度量的和可控制的工程原则、方法，涉及到软件过程、项目管理、开发方法、软件复用、软件度量、开发工具，甚至企业文化等各个方面。

1031.3什么是软件工程Definition9

AQualityFocusProcessMethodsCASETools1.3什么是软件工程104CASE1.4软件工程参考书目1051.4软件工程参考书目112过程和活动2.1软件过程的概念2.2问题定义活动2.3可行性研究活动2.4需求分析活动2.5设计活动2.6实施活动2.7测试活动2.8部署活动1062过程和活动2.1软件过程的概念122.1软件过程的概念软件过程的定义软件过程由开发或维护软件及其相关产品的一系列活动构成，这些活动从不同的方面定义了软件开发中的步骤、交付物、涉众及其职责等流程要素

1072.1软件过程的概念软件过程的定义132.1软件过程的概念Buildthe

System控制

预算,计划表,标准输入需求

资源

人员,工具输出代码,文档Process控制/约束输入资源输出1082.1软件过程的概念Buildthe

System控制2.1软件过程的概念WhatHowChange1092.1软件过程的概念WhatHowChange152.1软件过程的概念1102.1软件过程的概念162.1软件过程的概念BasicActivities(基础活动)问题定义，需求，设计，实b现，

软件验证，集成，软件演进/维护，退役UmbrellaActivities(辅助性活动)软件项目跟踪和控制，正式的技术复审，

软件质量保证，软件配置管理，文档编制，复用管理，度量，风险管理，…Somethingthatcoversorprotects.保护物覆盖或保护的事物1112.1软件过程的概念BasicActivities(基础2.2问题定义活动What问题定义是软件开发过程当中的一个定义要解决的问题并确定系统范围的活动。Why形成一个早期判断，达成一个最初共识

When

项目日程表的最前端占整个软件开发时间中的比例很小

1122.2问题定义活动What182.2问题定义活动Who系统分析师、出资方领导、出资方技术人员、开发方领导和项目经理

Where客户现场

1132.2问题定义活动Who192.2问题定义活动How1142.2问题定义活动How202.3可行性研究活动What可行性研究是以相对短的时间和相对低的成本来确定给定的问题在其约束条件内是否有解、有几种解以及哪个是最佳解。

Why必须要先确立满足约束条件的方案是否存在、是否可行、是否最优，然后再在最优方案的基础上进行开发

1152.3可行性研究活动What212.3可行性研究活动When项目的早期阶段占整个软件开发时间中的比例较小，但比问题定义活动所消耗的时间长Who系统分析师、出资方领导、出资方技术人员、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，SoftwareQualityAssure）人员等Where客户现场。1162.3可行性研究活动When222.3可行性研究活动HowHow1172.3可行性研究活动HowHow232.4需求分析活动What需求：主要是在产品构建之前确定的系统必须符合的条件或具备的功能，它们是关于系统将要完成什么工作的一段描述语句，它们必须经过所有相关人员的认可，其目的是彻底地解决客户的问题。

需求文档一组需求的集合用户需求文档、系统需求文档和软件规约文档1182.4需求分析活动What242.4需求分析活动功能性需求和非功能性需求

功能性需求：描述了系统应该做什么，即具备的功能或服务。（输入、输出和计算等）非功能性需求：描述了系统必须遵守的约束条件。（响应时间、吞吐量、可靠性、可移植性、可扩展性、易用性、安全性、资源要求、可复用性、技术要求、文化和政策需求、法律需求、道德要求、隐私要求，等等）

描述需求的标准是完整的、正确的、必要的、无歧义的、可行的、可验证的以及被设置了优先级别的。

What1192.4需求分析活动功能性需求和非功能性需求What252.4需求分析活动Why需求不一致、模糊、矛盾需求变更客户忽略领域常识/知识/术语客户集中于现有系统的不足之处，而忽略了系统要实现的关键功能零碎、无组织、不明确、表达不清不分轻重缓急

1202.4需求分析活动Why262.4需求分析活动When项目的早期阶段？贯穿于整个软件开发过程的需求活动1212.4需求分析活动When贯穿于整个软件开发过程的需求活动2.4需求分析活动Who系统分析师、需求阐释者、客户代表、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，SoftwareQualityAssure）人员、程序员、测试人员、部署人员、技术文档编写人员、培训人员等。Where调研时，在客户现场编写软件需求规约文档时，可以在开发单位复审相关的需求文档时，根据需要来安排1222.4需求分析活动Who282.4需求分析活动How1232.4需求分析活动How292.5设计活动What设计：是在系统的约束条件下（如预算、时间、人力资源、用户软、硬件环境和用户对系统的操作能力等），为了实现系统的功能性需求和非功能性需求，而找到并描述的一种遵循高质量的通用原则的方法，其交付文档能够指导开发人员实现系统。1242.5设计活动What302.5设计活动总体设计根据软件需求规约文档，确定一个合理的软件体系结构。这个体系结构包括合理地划分组成系统的模块、模块间的调用关系以及模块间的接口关系。软件体系结构还从总体方面决定了系统的可扩充性、可维护性，以及系统的性能等。总体设计的设计粒度较大，有时也被称为概要设计、架构设计。1252.5设计活动总体设计312.5设计活动详细设计详细设计地任务是在总体设计的基础上进一步确定如何实现目标系统，包括系统的数据对象的设计、人机接口的设计以及模块逻辑的详细设计。设计部件的粒度系统、子系统、框架、构件、组件、模块、类、方法等1262.5设计活动详细设计322.5设计活动Why软件架构是软件系统的核心应对复杂多变的情况，同时保持完整性应对系统在扩展功能当中出现的问题大规模复用的有效基础项目管理的基础1272.5设计活动Why332.5设计活动When项目的中、早期阶段？工作量早期中期后期项目时间大小贯穿于整个软件开发过程的设计活动1282.5设计活动When工作量早期2.5设计活动Who主要包括架构设计师、软件设计员、复用工程师、设计复审员、项目经理、财务人员、软件质量保证（SQA，SoftwareQualityAssure）人员和需求变更者等Where建议在软件企业内部进行设计1292.5设计活动Who352.5设计活动How1302.5设计活动How362.6实施活动What编码：是将软件设计结果转换成用某种程序设计语言书写的程序。单元测试：是把一个模块作为独立的程序单元进行测试，以保证它能够正确执行规定的功能。集成：是指将单独的软件构件合并成一个整体的软件系统。集成分为集成子系统和集成系统两个级别：1312.6实施活动What372.6实施活动Why以实施为中心的软件开发弱化的需求弱化的设计对实施人员的过度依赖1322.6实施活动Why382.6实施活动Why将单元测试作为实施的一部分When项目的中、后期阶段

工作量早期中期后期项目时间大小贯穿于整个软件开发过程的实施活动1332.6实施活动Why工作量早期2.6实施活动Who包括实施员、代码复审员、集成员、测试工程师、测试员、项目经理、架构设计师、软件设计员、复用工程师、SQA人员和财务人员等Where建议在软件企业内部进行开发

1342.6实施活动Who402.6实施活动How1352.6实施活动How412.7测试活动What测试：是选择适当的测试用例执行被测程序的过程，其目的在于发现程序错误。

缺陷：是系统任一方面（包括需求、设计或代码）的缺点。该缺点会促成或潜在的促成一个或多个失败发生。错误：是指程序中的缺陷所产生的不正确结果。失败：当一个程序不能运行或者其表现不可被接受时称为失败。失败是系统执行中出现的情况。失败源于代码缺陷。单元测试、集成测试、系统测试、α(alpha)、β(Beta)

验收测试1362.7测试活动What422.7测试活动质量维度：描述质量的概念或评测质量的方法的不同视角可靠性维度可用性维度性能维度测试用例：为特定目标开发的测试输入、执行条件和预期结果的集合。

1372.7测试活动质量维度：描述质量的概念或评测质量的方法的不2.7测试活动When项目的后期阶段？优点缩短测试时间易于定位缺陷避免错上加错

工作量早期中期后期项目时间大小1382.7测试活动When工作量早期2.7测试活动Who主要包括测试工程师、测试员、软件设计员、实施员、项目经理、部署工程师、部署员、SQA人员和财务人员等Where建议单元测试、集成测试和系统测试在实施员所在的开发现场及其附近进行β测试和验收测试则完全在用户现场测试1392.7测试活动Who452.7测试活动(5/5)How1402.7测试活动(5/5)How462.8部署活动What部署：是为确保最终用户可以正常使用软件产品而进行的活动。根据产品类型，可以将部署分为三种模式:自定义安装模式现场支持模式Internet模式

1412.8部署活动What472.8部署活动部署单元：由一个工作版本（可执行构件集）、文档（最终用户支持材料和发布说明）和安装工件组成部署计划：说明如何将产品从开发商转移到用户群兼容、转换和迁移策略部署时间表部署顺序用户培训

1422.8部署活动部署单元：由一个工作版本（可执行构件集）、文2.8部署活动When项目的后期阶段？工作量早期中期后期项目时间大小1432.8部署活动When工作量早期2.8部署活动Who主要包括部署工程师、部署员、文档编写员、包装员、实施员、项目经理、SQA人员和财务人员等Where一部分工作可以在开发现场进行，如制定部署计划、包装产品、编写相关文档等；另一部分工作必须在用户现场进行，如β测试、验收测试和用户正式使用中的安装、培训工作等。1442.8部署活动Who502.8部署活动How1452.8部署活动How513软件过程模型3.1过程模型概念3.2线形顺序模型系列3.3演进模型系列3.4其它模型系列3.5过程模型的选择1463软件过程模型3.1过程模型概念523.1过程模型概念为什么需要模型?模型帮助我们解释事物

如何工作模型能够拓宽我们的视野

(抽象)软件过程模型一个过程模型是一个过程的抽象表示过程模型帮助我们更好地理解软件开发1473.1过程模型概念为什么需要模型?533.1过程模型概念(2/5)1483.1过程模型概念(2/5)543.1过程模型概念1493.1过程模型概念553.1过程模型概念1503.1过程模型概念563.1过程模型概念经典模型LinearSequentialModelWaterfallModelVModelDepartmentofDefense

ModelRADModelPrototypingModelBuild-and-FixModel

IncrementalModelSpiralModelConcurrentDevelopmentModelXPModelRUPModel1513.1过程模型概念经典模型PrototypingMode3.2线形顺序模型系列线性顺序模型analysisdesigncodetestSystem/information

engineering1523.2线形顺序模型系列线性顺序模型analysisdesi3.2线形顺序模型系列瀑布模型1533.2线形顺序模型系列瀑布模型59特征接受上一阶段的结果作为本阶段的输入开发阶段严格按线性方式进行对本阶段的工作进行评审每一阶段具有相关的里程碑和交付产品缺点缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发开发早期存在的问题往往要到交付使用时才发现，维护代价大适用在开发的早期阶段软件需求被完整确定3.2线形顺序模型系列154特征3.2线形顺序模型系列60实际使用的瀑布模型3.2线形顺序模型系列155实际使用的瀑布模型3.2线形顺序模型系列613.2线形顺序模型系列V模型1563.2线形顺序模型系列V模型623.2线形顺序模型系列RAD(RapidApplicationDevelopment)模型60~90days1573.2线形顺序模型系列RAD(RapidApplica3.3演进模型系列原型模型Listento

customerbuild/revise

mock-upcustomertest

-drivesmock-up1583.3演进模型系列原型模型Listento

custo3.3演进模型系列边建边改ModelBuildfirst

versionModifyuntil

clientissatisfiedMaintenance

phaseRetirementDevelopmentMaintenance1593.3演进模型系列边建边改ModelBuildfirs3.3演进模型系列边建边改Model(续)1603.3演进模型系列边建边改Model(续)663.3演进模型系列增量模型System/InformationengineeringanalysisdesignCodeTest增量一交付1analysisdesignCodetest增量二analysisdesignCodetest增量三analysisdesignCodetest增量四CalendarTime交付2交付3交付51613.3演进模型系列增量模型System/Informati3.3演进模型系列Customer

CommunicationRiskAnalysisEngineeringConstruction&ReleasePlanningCustomer

EvaluationProjectentry

Pointaxis螺旋模型1623.3演进模型系列Customer

Communicati3.3演进模型系列XP模型，一种敏捷开发方法1633.3演进模型系列XP模型，一种敏捷开发方法693.4其它模型系列构件组装模型与瀑布模型对比1643.4其它模型系列构件组装模型703.4其它模型系列应用构件提取车间构件生产车间标准规范与质量保证1基础构件，2功能构件3接口构件，4用户界面构件

应用构件库

构件库组装车间领域

1领域

2应用系统...12341653.4其它模型系列应用构件构件生标准规范各种模型的比较模型优点缺点瀑布模型规范，文档驱动系统可能不满足客户真正的需求快速原型克服了瀑布型的缺点增量模型开发早期回报明确，易于维护要求开放的软件体系结构螺旋模型风险驱动，适用于大型项目开发风险分析人员需要有经验且经过充分训练166各种模型的比较模型优点缺点瀑布模型规范，文档驱动系统可能不满3.5过程模型的选择软件工程过程模型的选择是基于:项目的应用特点采用的方法和工具需要的控制交付的产品1673.5过程模型的选择软件工程过程模型的选择是基于:733.5过程模型总结在前期需求明确，尽量采用瀑布模型用户没有信息系统使用经验，需求分析人员技能不足，采用原型不确定因素很多，无法一下子计划，采用增量或螺旋需求不稳定，采用增量资金和成本无法一次到位，采用增量可以各种模型合并使用，但每一次必须要有明确的交付物和出口准则编程人员经验较少，不宜采用快速的方法1683.5过程模型总结在前期需求明确，尽量采用瀑布模型744软件过程能力成熟度1694软件过程能力成熟度754能力成熟度模型CMM

CMM（CapabilityMaturityModel）即能力成熟度模型，是美国卡耐基梅隆大学软件工程研究所（SEI）建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型建立之初的主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程。1704能力成熟度模型CMMCMM（Capability软件组织的成熟与不成熟不成熟的软件组织软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划有时，即使软件过程已计划好，仍不按计划执行没有一个客观的基准来判断产品质量，或解决产品和过程中的问题对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查、测试等经常由于要赶进度而减少或取消4能力成熟度模型CMM171软件组织的成熟与不成熟不成熟的软件组织4能力成熟度模型CM产品在交付前，对客户来说，一切都是不可见的没有长远目标，管理员通常只关注解决任何当前的危机由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度4能力成熟度模型CMM172产品在交付前，对客户来说，一切都是不可见的4能力成熟度模型2.成熟的软件组织具有全面而充分的组织和管理软件开发和维护过程的能力管理员监视软件产品的质量以及生产这些产品的过程。制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题。进度和预算可以按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的。4能力成熟度模型CMM1732.成熟的软件组织4能力成熟度模型CMM79能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(前后一致，不互相矛盾)工作凡规定的过程都编成文档软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本-效益分析来改进过程。全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，各守其责，协同工作，有条不紊，甚至能预见和防范问题的发生。4能力成熟度模型CMM174能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(CMM的组成4能力成熟度模型CMM175CMM的组成4能力成熟度模型CMM815.优化级4.已管理级3.已定义级2.可重复级1.初始级标准、一致的过程有纪律的过程可预测的过程持续改进的过程软件过程成熟度的5个等级4能力成熟度模型CMM1765.优化级4.已管理级3.已定义级2.可重复级1.初始级标准CMM提供了一个成熟度等级框架：1级-初始级、2级-可重复级、3级-已定义级、4级-已管理级和5级-优化级。

1.初始（initial）级：软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力。

2.可重复（repeatable）级：建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功。4能力成熟度模型CMM177CMM提供了一个成熟度等级框架：1级-初始级、2级-可重3.已定义（defined）级：己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。

4.已管理（managed）级：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。

5.优化（optimizing）级：整个组织关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进。4能力成熟度模型CMM1783.已定义（d