软件工程东北大学信息科学与工程学院课件.ppt

1、1软件工程整 体 概 述THE FIRST PART OF THE OVERALL OVERVIEW,P L E A S E S U M M A R I Z E T H E C O N T E N T第一部分3Chapter 1 软件工程概述 1.1 软件的概念 1.2 为什么学习软件工程 1.3 什么是软件工程 1.4 课程结构 1.5 参考书目 1.6 教材案例-在线宠物商店41.1 软件的概念(1/2)软件:新的驱动力 In the early 1980s,a front page story in Business Week magazineBanking&Finance Govern

2、ment Insurance Manufacturing Media&Publishing Retail Travel Utilities 51.1 软件的概念(2/2)定义Program+Data Structure+Documents Wang Jiahua,软件工程,pp.1 软件的性质复杂性难以描述性不可见性变化性风险性易于副本的大批量生产强合作性61.2 为什么学习软件工程(1/4)软件危机爆发时间 1967年NATO的研究组首次提出 1968年NATO软件工程会议首次提出软件工程概念 1968-2006,近40年“危机”一词软件危机依然存在Crisis！71.2 为什么学习软件工程

3、(2/4)软件危机面对的问题 艺术 vs.标准化 错误的发现 软件需求获取 软件支持和维护 开发速度 vs.市场需求 开发周期过长、开发成本过高 研发风险 软件Trouble 软件开发中的复杂的协作(人员,问题,过程)不同角色的软件神话(管理者,用户,开发者,大众)81.2 为什么学习软件工程(3/4)采用什么方法缓解危机硬件?建筑学?拍电影?软件工程！91.2 为什么学习软件工程(4/4)挑战101.3 什么是软件工程(1/4)Fritz Bauer:“建立和应用完善的工程原理以便经济地得到在真实机器上可靠和有效运行的软件重原理、轻技术、无度量 IEEE：(1)应用系统的有规则的定量的方法开

4、发、使用和维护软件；即应用工程于软件。(2)研究(1)中的方法粗糙111.3 什么是软件工程(2/4)Definition软件工程是以质量为核心，为了经济地开发满足客户需求的软件而研究、建立和应用的系统化的、有规则的、可度量的和可控制的工程原则、方法，涉及到软件过程、项目管理、开发方法、软件复用、软件度量、开发工具，甚至企业文化等各个方面。Guo Jun121.3 什么是软件工程(3/4)发展历程(1)131.3 什么是软件工程(4/4)发展历程(2)141.4 课程结构(1/2)Chapter 1软件工程概述 Chapter 2过程和活动 Chapter 3软件过程模型 Chapter 4问

5、题定义和可行性研究的方法 Chapter 5 需求分析方法 Chapter 6 软件设计方法 Chapter 7软件实施和测试方法 Chapter 8项目管理方法151.4 课程结构(2/2)实验教学主要内容需求采集，角色分配，制定计划(4)系统分析与设计(4)系统分包与集成，配置管理(4)系统测试与交付(4)基于团队合作的项目模拟开发(8)161.5 参考书目(1/2)教材软件工程及应用/东北大学出版社 2007年5月 参考推荐软件工程/东北大学出版社/王家华/中面向对象的软件工程/机械出版社/Timothy C.Lethbridge/加171.5 参考书目(2/2)181.6 教材案例-在

6、线宠物商店(1/3)宠物大战 SUN Vs.Microsoft 主要功能：列举宠物商品类别和提供搜索功能 显示宠物列表和宠物具体信息 提供用户登录验证、注册新用户和维护用户信息等功能 管理购物车 实现结帐处理 查询订货情况 统计销售记录191.6 教材案例-在线宠物商店(2/3)问题(1/2):从何开始？采用什么技术？需要多少时间？需要多少人？哪些角色？能否并行、协作地开发？人力应该如何高效率的投入？开发计划？直接编码？需求？设计方案和模型？人机交互的界面？功能优先级？201.6 教材案例-在线宠物商店(3/3)问题(2/2):开发风险？可扩展性？复用？设计模式？编码规范？需求变更？测试？开发

7、过程？软件度量？最后期限？21Chapter 2 过程和活动 2.1 软件过程的概念 2.2 问题定义活动 2.3 可行性研究活动 2.4 需求分析活动 2.5 设计活动 2.6 实施活动 2.7 测试活动 2.8 部署活动222.1 软件过程的概念(1/9)软件工程是一种层次化的技术 A Quality FocusProcessMethodsCASE Tools232.1 软件过程的概念(2/9)软件过程的定义软件过程由开发或维护软件及其相关产品的一系列活动构成，这些活动从不同的方面定义了软件开发中的步骤、交付物、涉众及其职责等流程要素 242.1 软件过程的概念(3/9)为什么要引入软件过

8、程？(1/2)软件工作的范围软件的开发风险（规模、周期、复杂度）涉及整个软件生存周期扩展到少，可预知、可控多，不易预知，不易控制发展到只考虑编写程序252.1 软件过程的概念(4/9)为什么要引入软件过程？(2/2)软件开发的角色软件标准团队中更多的角色扩展到软件产品的标准化软件开发过程的标准化扩展到程序员262.1 软件过程的概念(5/9)Build theSystem控制 预算,计划表,标准输入需求资源人员,工具输出代码,文档Process控制/约束输入资源输出272.1 软件过程的概念(6/9)WhatHowChange282.1 软件过程的概念(7/9)292.1 软件过程的概念(8/

9、9)Basic Activities(基础活动)问题定义，需求，规约，设计，实现，软件验证，集成，软件演进/维护，退役 Umbrella Activities(辅助性活动)软件项目跟踪和控制，正式的技术复审，软件质量保证，软件配置管理，文档编制，复用管理，度量，风险管理，Something that covers or protects.保护物覆盖或保护的事物302.1 软件过程的概念(9/9)公共过程框架Common Process FrameworkFramework ActivitiesTask SetsTasksMilestones,deliverablesSQA pointsUmbr

10、ella Activities312.2 问题定义活动(1/3)What问题定义是软件开发过程当中的一个定义要解决的问题并确定系统范围的活动。Why形成一个早期判断，达成一个最初共识 When项目日程表的最前端占整个软件开发时间中的比例很小 322.2 问题定义活动(2/3)Who系统分析师、出资方领导、出资方技术人员、开发方领导和项目经理 Where客户现场 332.2 问题定义活动(3/3)How342.3 可行性研究活动(1/3)What可行性研究是以相对短的时间和相对低的成本来确定给定的问题在其约束条件内是否有解、有几种解以及哪个是最佳解。Why必须要先确立满足约束条件的方案是否存在、

11、是否可行、是否最优，然后再在最优方案的基础上进行开发 352.3 可行性研究活动(2/3)When 项目的早期阶段 占整个软件开发时间中的比例较小，但比问题定义活动所消耗的时间长 Who 系统分析师、出资方领导、出资方技术人员、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，Software Quality Assure）人员等 Where 客户现场。362.3 可行性研究活动(3/3)How How(1/2)372.4 需求分析活动(1/7)What(1/3)需求：主要是在产品构建之前确定的系统必须符合的条件或具备的功能，它们是关于系统将要完成

12、什么工作的一段描述语句，它们必须经过所有相关人员的认可，其目的是彻底地解决客户的问题。需求文档 一组需求的集合 用户需求文档、系统需求文档和软件规约文档 382.4 需求分析活动(2/7)What(2/3)392.4 需求分析活动(3/7)功能性需求和非功能性需求 功能性需求：描述了系统应该做什么，即具备的功能或服务。（输入、输出和计算等）非功能性需求：描述了系统必须遵守的约束条件。（响应时间、吞吐量、可靠性、可移植性、可扩展性、易用性、安全性、资源要求、可复用性、技术要求、文化和政策需求、法律需求、道德要求、隐私要求，等等）描述需求的标准 是完整的、正确的、必要的、无歧义的、可行的、可验证的

13、以及被设置了优先级别的。What(3/3)402.4 需求分析活动(4/7)Why需求不一致、模糊、矛盾需求变更客户忽略领域常识/知识/术语 客户集中于现有系统的不足之处，而忽略了系统要实现的关键功能零碎、无组织、不明确、表达不清不分轻重缓急 412.4 需求分析活动(5/7)When项目的早期阶段？贯穿于整个软件开发过程的需求活动422.4 需求分析活动(6/7)Who 系统分析师、需求阐释者、客户代表、用户代表、开发方领导、项目经理、架构设计师、领域专家、财务人员、市场人员、软件质量保证（SQA，Software Quality Assure）人员、程序员、测试人员、部署人员、技术文档编写

14、人员、培训人员等。Where 调研时，在客户现场 编纂软件需求规约文档时，可以在开发单位 复审相关的需求文档时，根据需要来安排432.4 需求分析活动(7/7)How网罗需求entry/工作上下文范围entry/领域知识和可重用的需求do/获取涉众的原始需求exit/建立原始需求记录定义系统do/分析系统需求exit/制定软件需求文档exit/改进业务词汇表管理系统规模do/分析需求优先级、工作量和风险等属性exit/修订系统开发计划需求变更请求do/问题分析和变更描述exit/提交需求变更申请启动需求do/确定需求的涉众、范围、目标和限制条件do/估算项目费用exit/达成一致意见 更多迭代

15、 未通过复审 需求变更实现do/修改需求文档do/修改设计文档do/修改测试用例do/修改程序exit/评估变更结果 通过复审 who/系统分析师、项目经理、客户代表、开发方领导、财务人员等who/系统分析师、需求阐释者、客户代表、用户等who/系统分析师、需求阐释者等复审do/审查需求文档exit/发布审查结论who/系统分析师、项目经理、客户代表、用户代表、领域专家、SQA人员等who/系统分析师、项目经理、领域专家、SQA人员等who/用户代表、客户代表、系统分析员、需求阐释者等需求变更处理do/评估变更影响do/预算变更成本do/制定变更计划do/审查exit/发布审查结论who/用户

16、代表、客户代表、项目经理、系统分析师、架构设计师、软件设计员、开发方领导、财务人员等who/系统分析师、需求阐释者、项目经理、架构设计师、软件设计员、测试人员、实施员、SQA人员、用户代表、客户代表、财务人员、部署人员等 需求定义完成 未通过复审 通过复审 442.5 设计活动(1/7)What 设计：是在系统的约束条件下（如预算、时间、人力资源、用户软、硬件环境和用户对系统的操作能力等），为了实现系统的功能性需求和非功能性需求，而找到并描述的一种遵循高质量的通用原则的方法，其交付文档能够指导开发人员实现系统。452.5 设计活动(2/7)总体设计 任务是根据软件需求规约文档，确定一个合理的软

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

18、项目管理的基础 482.5 设计活动(5/7)When项目的中、早期阶段？工作量早期 中期 后期项目时间大小贯穿于整个软件开发过程的设计活动492.5 设计活动(6/7)Who主要包括架构设计师、软件设计员、复用工程师、设计复审员、项目经理、财务人员、软件质量保证（SQA，Software Quality Assure）人员和需求变更者等 Where建议在软件企业内部进行设计 502.5 设计活动(7/7)How定义架构草案entry/软件需求规约文档do/定义多个备选架构草案do/选择最优架构草案exit/审查架构草案who/架构设计师、软件设计员、项目经理、SQA人员、财务人员等改进架构d

19、o/考虑设计原则和架构模式do/分析设计元素do/分析元素间的关系和接口exit/修改设计模型设计专用构件设计数据库设计可复用的框架或构件选择可复用的框架或构件entry/软件可复用资产库do/查找符合条件的的框架和构件do/选择适合的框架或构件修订设计说明书do/修订设计说明书exit/复审设计说明书 新的迭代或需求变更 架构设计早期who/架构设计师、复用工程师who/架构设计师、复用工程师、软件设计员who/复用工程师、软件设计员who/构件设计员who/数据库设计员who/架构设计师、复用工程师、软件设计员、项目经理、SQA人员、财务人员等 需要设计新的可复用框架或构件 开发专用构件

20、需要设计数据库 找到合适的框架或构件 未通过复审 通过复审 未通过审查通过审查512.6 实施活动(1/5)What编码：是将软件设计结果转换成用某种程序设计语言书写的程序。单元测试：是把一个模块作为独立的程序单元进行测试，以保证它能够正确执行规定的功能。集成：是指将单独的软件构件合并成一个整体的软件系统。集成分为集成子系统和集成系统两个级别：522.6 实施活动(2/5)Why以实施为中心的软件开发 弱化的需求 弱化的设计 对实施人员的过度依赖 对实施活动的轻视 需要的时间进入工作状态 具有技术含量 水平存在差异 实施质量不易度量 532.6 实施活动(3/5)Why将单元测试作为实施的一部

21、分 When项目的中、后期阶段 工作量早期 中期 后期项目时间大小贯穿于整个软件开发过程的实施活动542.6 实施活动(4/5)Who包括实施员、代码复审员、集成员、测试工程师、测试员、项目经理、架构设计师、软件设计员、复用工程师、SQA人员和财务人员等 Where建议在软件企业内部进行开发 552.6 实施活动(5/5)How制定计划do/修订实施计划/集成测试/测试计划/预算实施成本exit/审核计划和预算who/架构设计师、软件设计员、复用工程师、项目经理、实施员、集成员、测试工程师、测试员、SQA人员、财务人员等实施构件do/开发或改进构件do/制作测试驱动程序和桩模块do/执行单元测

22、试do/修订集成计划/测试计划(方案)exit/复审代码who/实施员、集成员、测试工程师、代码复审员 未通过代码复审 集成每个子系统do/将新建或变更构件集成到相关子系统中do/对集成的子系统进行测试who/集成员、测试员、测试工程师集成系统do/集成出新的工作版本do/集成测试who/集成员、测试员、测试工程师迭代总结(实施)entry/实施的工作版本do/审查计划执行情况/实施质量/实施成本who/项目经理、实施员、集成员、测试工程师、测试人员、架构设计师、软件设计员、复用工程师、SQA人员、财务人员等未通过子系统测试 通过代码复审 通过子系统测试 此次迭代中还有其它子系统未集成 已完成

23、此次迭代中的子系统集成 此次迭代中还有子系统未被集成到工作版本 完成 未通过审核 通过审核 未通过集成测试 通过集成测试 此次迭代中还有其它构件未实施 已完成此次迭代中构件的实施 562.7 测试活动(1/6)What 测试：是选择适当的测试用例执行被测程序的过程，其目的在于发现程序错误。缺陷：是系统任一方面（包括需求、设计或代码）的缺点。该缺点会促成或潜在的促成一个或多个失败发生。错误：是指程序中的缺陷所产生的不正确结果。失败：当一个程序不能运行或者其表现不可被接受时称为失败。失败是系统执行中出现的情况。失败源于代码缺陷。单元测试、集成测试、系统测试、(alpha)、(Beta)、验收测试

24、572.7 测试活动(2/6)质量维度：描述质量的概念或评测质量的方法的不同视角 可靠性维度 可靠性维度 性能维度测试用例：为特定目标开发的测试输入、执行条件和预期结果的集合。582.7 测试活动(3/6)Why及时检查出项目中的缺陷和不足保证所开发的软件能够达到用户满意测试是项目管理的重要内容 592.7 测试活动(4/6)When项目的后期阶段？优点 缩短测试时间 易于定位缺陷 避免错上加错 工作量早期 中期 后期项目时间大小602.7 测试活动(5/6)Who主要包括测试工程师、测试员、软件设计员、实施员、项目经理、部署工程师、部署员、SQA人员和财务人员等 Where建议单元测试、集成

25、测试和系统测试在实施员所在的开发现场及其附近进行测试和验收测试则完全在用户现场测试 612.7 测试活动(6/6)How制定测试计划entry/需求规约文档/设计说明书/集成构建计划do/制定测试计划do/设计测试用例和测试过程do/分析测试工作量，预算测试成本who/测试工程师、项目经理、SQA人员和财务人员实施测试do/设计/实现测试用的驱动程序和桩模块do/测试构件和子系统who/软件设计员、实施员 单元测试失败 或还有其它单元测试未实施 集成测试 完成单元测试 who/测试员 完成集成测试 集成测试失败 或还有其它迭代内集成测试未测 系统测试who/测试员 系统测试未通过 测试 通过

26、需要测试who/客户和用户测试不需要测试需要测试who/客户、用户、部署工程师和部署员 不需要测试 验收测试 需要验收测试 who/客户、用户、项目经理、部署工程师和部署员评估测试do/提出系统变更请求do/制定/修订测试评估报告who测试工程师迭代总结(测试)do/审查测试计划执行情况/测试成本/测试质量who/测试工程师、测试员、软件设计员、实施员、项目经理、SQA人员和财务人员等 不需要验收测试 622.8 部署活动(1/6)What部署：是为确保最终用户可以正常使用软件产品而进行的活动。根据产品类型，可以将部署分为三种模式:自定义安装模式 现场支持模式 Internet模式 632.8

27、 部署活动(2/6)部署单元：由一个工作版本（可执行构件集）、文档（最终用户支持材料和发布说明）和安装工件组成 部署计划：说明如何将产品从开发商转移到用户群 兼容、转换和迁移策略 部署时间表 部署顺序 用户培训 642.8 部署活动(3/6)Why用户的应用环境和项目团队的开发环境往往不同，需要进行调试、“磨合 数据或程序迁移培训服务和使用支持 652.8 部署活动(4/6)When项目的后期阶段？工作量早期 中期 后期项目时间大小662.8 部署活动(5/6)Who主要包括部署工程师、部署员、文档编写员、包装员、实施员、项目经理、SQA人员和财务人员等 Where一部分工作可以在开发现场进行

28、，如制定部署计划、包装产品、编写相关文档等；另一部分工作必须在用户现场进行，如测试、验收测试和用户正式使用中的安装、培训工作等。672.8 部署活动(6/6)How计划部署do/制定部署计划do/定义材料清单who/部署工程师编写支持材料who/文档编写员参与内部测试do/熟悉系统do/部署测试环境who/部署工程师、部署员生成部署单元do/编写发布说明do/开发安装工件who/部署工程师、软件设计员和实施员测试的部署who/部署工程师、部署员验收测试的部署who/部署工程师、部署员包装产品who/包装员用户正式使用的部署who/部署工程师、部署员 测试未通过 通过 需要测试 不需要测试 需要

29、验收测试 不需要验收测试 需要正式部署 不需要正式部署 迭代总结(部署)do/审查部署计划执行情况/部署成本/部署质量who/项目经理、部署工程师、部署员、文档编写员、包装员、实施员、SQA人员和财务人员等68Chapter 3 软件过程模型 3.1 过程模型概念 3.2 线形顺序模型系列 3.3 演进模型系列 3.4 其它模型系列 3.5 过程模型的选择693.1 过程模型概念(1/5)为什么需要模型?模型帮助我们解释事物如何工作模型能够拓宽我们的视野(抽象)软件过程模型一个过程模型是一个过程的抽象表示过程模型帮助我们更好地理解软件开发703.1 过程模型概念(2/5)713.1 过程模型概

30、念(3/5)723.1 过程模型概念(4/5)733.1 过程模型概念(5/5)经典模型 Linear Sequential Model Waterfall Model V Model Department of Defense Model RAD Model The Circular Model Prototyping Model Build-and-Fix Model Incremental Model Spiral Model Concurrent Development Model XP Model RUP Model CBD Assembly Model Formal Methods

31、 Model IDEAL Model743.2 线形顺序模型系列(1/7)线性顺序模型analysisdesigncodetestSystem/informationengineering753.2 线形顺序模型系列(2/7)瀑布模型76773.2 线形顺序模型系列(4/7)V 模型REQUIREMENTSANALYSISSYSTEMDESIGNPROGRAMDESIGNCODINGUNIT&INTE-GRATION TESTINGSYSTEMTESTINGACCEPTANCETESTINGOPERATION&MAINTENANCEVerify designValidate requireme

32、nts783.2 线形顺序模型系列(5/7)国防部模型793.2 线形顺序模型系列(6/7)圆形模型803.2 线形顺序模型系列(7/7)RAD(Rapid Application Development)模型60 90 days813.3 演进模型系列(1/12)原型模型Listen to customerbuild/revisemock-upcustomer test-drives mock-up823.3 演进模型系列(2/12)边建边改 ModelBuild first versionModify until client is satisfiedMaintenancephaseRet

33、irementDevelopmentMaintenance833.3 演进模型系列(3/12)边建边改 Model(续)843.3 演进模型系列(4/12)增量模型System/InformationengineeringanalysisdesignCodetestIncrement 1Delivery of 1st incrementanalysisdesignCodetestIncrement 2Delivery of 2st incrementanalysisdesignCodetestIncrement 3Delivery of 3st incrementanalysisdesignC

34、odetestIncrement 4Delivery of 4st incrementCalendar Time853.3 演进模型系列(5/12)CustomerCommunicationRisk AnalysisEngineeringConstruction&ReleasePlanningCustomerEvaluationProject entryPoint axis 螺旋模型863.3 演进模型系列(6/12)并发模型NoneUnderdevelopmentUnderreviewAwaitingchangesUnderrevisionBaselinedDoneAnalysis acti

35、vity873.3 演进模型系列(7/12)XP 模型883.3 演进模型系列(8/12)RUP Model893.3 演进模型系列(9/12)RUP Model迭代式生命周期903.3 演进模型系列(10/12)RUP Model项目阶段和里程碑913.3 演进模型系列(11/12)RUP ModelRUP各阶段工作量和进度分配（中等规模项目）一个典型的分配方案923.3 演进模型系列(12/12)RUP ModelRUP开发周期和演进周期933.4 其它模型系列(1/5)构件组装模型与瀑布模型对比943.4 其它模型系列(2/5)构件组装模型(螺旋版)Identifycandidateco

36、mponentsLook upcomponents in libraryExtract components if availableConstructnth iterationof systemPut newcomponentsin libraryBuildComponentsif unavailableCustomerCommunicationRisk AnalysisEngineeringConstruction&ReleaseCustomerEvaluationPlanning953.4 其它模型系列(3/5)应用构件提取车间构件生产车间标准规范 与 质量保证1基础构件，2功能构件 3

37、接口构件，4用户界面构件 应用构件库 构件库组装车间领域 1领域 2应用系统.1 12 23 34 4963.4 其它模型系列(4/5)形式化方法模型RequirementsdefinitionFormalspecificationFormaltransformationIntegration andsystem testing973.4 其它模型系列(5/5)EstablishimprovementinfrastructureLearningEstablishingActingStimulusforchangeSetcontextBuildsponsorshipCharacterizecur

38、rent anddesired statesDeveloprecommend-ationsSetprioritiesDevelopapproachPlanactionsCreatesolutionPilot/testsolutionRefinesolutionImplementsolutionAnalyzeandvalidateProposefutureactionsDiagnosingInitiating IDEAL Model983.5 过程模型的选择(1/2)软件工程过程模型的选择是基于:项目的应用特点采用的方法和工具需要的控制交付的产品99100Chapter 4 问题定义和可行性研究

39、的方法 4.1 可行性研究的内容 4.1 成本/效益分析 4.2 相关文档规范1014.1 可行性研究的内容(1/1)1024.2 成本/效益分析(1/6)运营效益启动成本+运营成本 启动成本 指为了建立新系统所支付的一次性开支运营成本 指为了维持这个系统的运行所发生的费用 运营效益 指正式运行系统后能够产生的收益 1034.2 成本/效益分析(2/6)投资回收分析法 缺点：忽略了资金的时间因素 净资金现值法 货币的时间价值1044.2 成本/效益分析(3/6)净资金现值法 资金现值的使用承认了货币的时间价值例：小型机的折旧期限为 8年，某公司的计算机系统总投资400万元，项目计划用2年时间完

40、成，第1年投资300万元，第2年投资100万元。系统投入运行后每年运行费用为20万元，经和财务人员共同估算每年可得效益376万元。假定以后每年的费用与效益都相同。假定银行利率为9%。1054.2 成本/效益分析(4/6)例：获得总经济效益为1073.5万元。投资回收期=2+1+92.1/274.9=3.3（年）1064.2 成本/效益分析(5/6)成本/效益比较净资金现值系数 例：假定方案A和方案B都可行。方案A的开发成本为10000元，在5年期限内每年可得效益4000；方案B开发成本为100000万元，在5年期限内每年可得效益30000元。假定最小可接受的折扣率为121074.2 成本/效益

41、分析(6/6)例：方案A的净资金现值系数4416/10000=0.44 方案B的净资金现值系数8150/1000000.08。1084.3 相关文档规范(1/3)问题定义报告范围与目标叙述：XXXX年XXXX月XXXX日 项目：储蓄系统 问题：手工处理，顾客等待时间长，经常失去客户 项目目标：加快处理速度，减少客户等待时间，吸引更多客户 项目范围：(叙述新系统的功能、行为及有关约束条件）初步设想：建立一个计算机系统 可行性研究：（指出可行性研究所需时间与费用）1094.3 相关文档规范(2/3)词汇表不必说明众所周知的术语完整的词汇表“版本号”和“修订历史纪录”“目录”系统分析师负责词汇表的完

42、整性1104.3 相关文档规范(3/3)可行性研究报告大纲1)软件工程实践者的研究方法2)RUP：前景3)国家标准：可行性研究报告的编写内容4)企业标准111Chapter 5 需求分析方法 5.1 需求分析的原则 5.2 需求收集方法 5.3 传统需求分析建模方法 5.4 面向对象的需求分析建模方法 5.5 相关文档规范1125.1 需求分析的原则(1/12)1)循序渐进理由 系统的规模越大且复杂-难以一下子理解完整 急于求成-“边建边改”or 错误 or 功能不完善步骤 采集原始需求 整理需求 建立需求分析模型 编写需求规约文档 复审1135.1 需求分析的原则(2/12)1)循序渐进11

43、45.1 需求分析的原则(3/12)2)自顶向下，逐层分解理由 庞大的、复杂的系统很难一下子被完全理解 小鸟视角分解 分解还是分割？怎样分解？分解多少/多深为宜？1155.1 需求分析的原则(4/12)2)自顶向下，逐层分解1165.1 需求分析的原则(5/12)3)与实现分离 理由 避免记录一些因为当前的技术才存在的需求，或者使用一些可能不适合新产品的技术 避免对实现的方式做出束缚。除非已经严格的做出要求，否则一般不应使用属于实现的描述 各尽其责解决办法 职业化、专业化的需求分析人员 复审1175.1 需求分析的原则(6/12)4)定义需求属性理由每个需求仅仅是几行描述语句吗？评估测试故障对

44、需求的影响 评估用户对系统的满意程度 估算开发成本 管理项目的规模 分配开发资源 安排调度计划 管理需求变更 管理项目风险 1185.1 需求分析的原则(7/12)4)定义需求属性属性包括 每个需求并不仅仅是一行描述语句。每个需求都有类型、原因、开发优先级、风险、客户满意度、客户不满意度、依赖关系、冲突关系，以及来源等属性 随着开发的深入，还可以继续丰富需求的属性，如开发难度、开发工作量等1195.1 需求分析的原则(8/12)5)可验证性 理由 证明所开发的系统符客户和用户的要求的依据 不可验证的需求，仅仅是对需求的一种主观愿望，对于设计和测试等活动而言都是缺乏意义的 度量出系统实现的质量

45、1205.1 需求分析的原则(9/12)5)可验证性 非功能性需求的可验证性 易用性 性能 可靠性 安全性1215.1 需求分析的原则(10/12)6)可追踪性 需求的追踪路径1225.1 需求分析的原则(11/12)6)可追踪性理由 跟踪问题：在工件的转换过程中，可能会出现很多问题，而问题存在传递性开发成员误解需求 错误地使用需求 变更需求 分析潜在变更的影响 核实通过实施系统所有的需求都已经被实现 1235.1 需求分析的原则(12/12)7)其它原则使用术语尊重客户的意见重视复用需求对变更进行管理要求“确认需求”1245.2 需求收集方法 与用户交流的方式用户访谈做学徒讨论会头脑风暴 交

46、流手段 使用思维图，使用鱼骨图，使用需求卡片1255.3 传统需求分析建模方法 功能建模数据流程图(Data Flow Diagram,DFD)行为建模状态变迁图(State-Transition Diagram,STD)Petri网 数据字典 判定表和判定树1265.3 传统数据流程图(1/16)什么是数据流程图是一个分层的概念模型，分为三个层次：总体图、零级图、细节图，分别描述系统的不同特征。4种符号：方，圆，开口矩（平行线），箭头 3个层次：总体图，零级图，细节图 优点容易理解，容易在开发方和用户方之间进行交流，以及在开发组织内部交流1275.3 传统数据流程图(2/16)表示符号外部实

47、体数据处理 数据存储数据流 1285.3 传统数据流程图(3/16)数据变换1295.3 传统数据流程图(4/16)分层表示的数据处理1305.3 传统数据流程图(5/16)分层表示的数据处理总体图：描述了系统和周围环境的关系 零级图：表示一个系统的主要功能或者是一个大型系统的主要组成子系统细节图：表示一个复杂的处理的详细内部表示1315.3 传统数据流程图(6/16)分层表示的数据处理总体图1325.3 传统数据流程图(7/16)分层表示的数据处理零级图1335.3 传统数据流程图(8/16)分层表示的数据处理细节图1345.3 传统数据流程图(9/16)数据流程图绘制的有关规定(1/2)外

48、部实体只能出现在总体图和零级图中 数据存储只能出现在零级图和细节图中 数据存储在分层的DFD图中只能出现一次数据存储必须既有读操作，也有写操作 数据流要有名字 数据流必须开始或结束在处理圆圈上数据流不表示有关的控制逻辑 1355.3 传统数据流程图(10/16)数据流程图绘制的有关规定(2/2)每个处理要有编号，但不表示先后顺序每个图中处理的数不应超过9个 每个处理应该既有输入的数据流，也有输出的数据流 子图与父图中对应的处理必须执行相同的功能，并且子图与对应的处理流入和流出的数据流相同 输入/输出命令不能作为DFD图中的处理 1365.3 传统数据流程图(11/16)规定举例11375.3

49、传统数据流程图(12/16)规定举例2138 数据流程图(DFD)规定举例3 规定举例31395.3 传统数据流程图(12/16)规定举例4E1-DS1数据流未与处理相连DS1-DS2数据流无处理处理P1无输出数据流 处理P2无输入数据流数据存储DS2无读操作 所有数据流没有名字21405.3 传统数据流程图(12/16)规定举例5DS1无写操作141阿DS2无写操作DS2读操作的数据流无名称相对于零级图中的过程P1，少数据流A4DS1与零级图中的数据存储重复142AB2应指向一个处理，而不应直接指向数据存储，我们规定数据流至少有一端必须和处理相联。相对于其父图中过程P1.2,此处多了数据流A

50、4过程P1.2.3无输入1435.3 传统数据流程图(14/16)例子144Data Flow Diagrams Example1455.3 传统数据流程图(16/16)例子1465.3 传统状态变迁图(1/3)表示符号状态：是可以被观察到的系统的行为模式 圆圈或矩形表示，并在圆圈或矩形中标明状态的名字 变迁 表示一种状态向另一种状态的迁移 带箭头的线来表示，在线上要标注出事件的名称，需要时也可以和把DFD图中相关的处理标注进来1475.3 传统状态变迁图(2/3)例子1：进程1485.3 传统状态变迁图(3/3)例子2：复印机1495.3 传统Petri网(1/2)表示符号位置（Place）