高级软件工程

高级软件工程 AdvancedSoftwareEngineering 2 主要内容 一 软件工程概述二 软件需求三 软件设计四 检验和有效性验证方法五 软件进化六 软件项目管理七 AdvancedTopicsinSoftwareEngineering 3 一 软件工程概述 软件工程的基本概念基于计算机的系统工程软件过程软件项目管理的基本内容 4 1 什么是软件 Software program data documentCustomsoftwareGenericsoftware Shrink wrappedsoftwareEmbeddedsoftwareSafety criticalsoftwareCOTS CommercialOff the shelf Iwillcreateasoftwaretoupdatethedatabase somesoftware apieceofsoftware asoftwaresystem 5 软件的分类 可以按功能 规模 工作方式 可靠性高低等进行划分有关软件的词汇CustomsoftwareGenericsoftwareEmbeddedsoftwareSafety criticalsoftwareCOTS CommercialOff the shelf Iwillcreateasoftwaretoupdatethedatabase somesoftware apieceofsoftware asoftwaresystem 6 2 什么是软件工程 1968年秋季 NATO 北约 的科技委员会召集了近50名一流的编程人员 计算机科学家和工业界巨头 讨论和制定摆脱 软件危机 的对策 FritzBauer在会议上首次提出 软件工程 概念 软件工程是一门研究如何用系统化 规范化 数量化等工程原则和方法进行软件开发和维护的学科 7 FritzBauer 软件工程是为了经济地获得可靠的 能在实际的机器上高效运行的软件而建立和使用的科学的工程原则 IEEE 软件工程是 1 将系统化的 规范的 可度量的方法应用于软件的开发 运行和维护的过程 即将工程化思想应用于软件开发过程中 2 上述方法的研究 软件工程的目标 低成本 高质量 按时交付 8 软件工程的本质特性 关注大型程序的构造软件工程的中心课题是控制复杂性软件需求不断变化旨在提高软件开发的效率团队合作是软件工程顺利实施的关键软件必须有效支持它的用户由一种文化背景的人替另一种文化背景的人创造产品 9 3 软件工程与计算机科学的区别 计算机科学研究的是构成计算机和软件系统基础的有关理论和方法 而软件工程则研究软件制作中的实际问题 理论上 所有软件工程都应该以计算机科学理论作为坚实的基础 但对付实际的 复杂的问题时需要用软件工程的方法来解决 10 4 软件工程与系统工程的区别 系统工程的产生比软件工程早 基于计算机的系统工程 研究由软件起主导作用的 有关负责系统的开发和进化的方方面面 包括硬件开发 系统决策 过程设计 系统实施和软件过程等 11 5 什么是软件过程 软件过程是指开发软件产品的一组活动及其结果 所有的软件过程都包含4项基本的活动 软件描述 软件开发 软件有效性验证和软件进化 不同的软件过程以不同的方式组织这4项活动 活动的结果会影响活动的进度 不同的机构可能用不同的过程来制作同一类产品 12 过程定义的作用 一个过程定义了为达到确定的目标 需要什么人在什么时间以何种方式做何种工作 Goal Who When How What ProcessvsMusicscore对于Customer User Developer Manager 一个广泛适用的过程使得所有涉众更好地理解自己所扮演的角色 更清楚地知道自己及他人在什么时间做什么 促使过程的有机结合和改善 以获得 最好过程 可以使公司内部的培训标准化 由于过程的可重复性 利于开发进度的安排 利于成本估算 13 6 什么是软件过程模型 模型与建模软件过程模型是从一特定的角度对软件过程的本质描述 软件过程模型包括构成软件过程的各种活动 软件产品以及所有涉众 stakeholder 14 从不同的角度对软件过程的描述 就得到不同的过程模型种类 如工作流模型 数据流或活动模型 角色 动作模型等 工作流模型 描述软件过程中各种活动的序列及其输入 输出和相互依赖型 其中的活动皆为人的活动 数据流或活动模型 把软件过程描述成一组活动 其中每个活动都完成一定的数据转换 该模型中的活动层次低于工作流模型 角色 动作模型 描述参与软件过程的不同角色及其所负责的活动 15 通用模型或范型 Paradigm Methodology WaterfallModelTheWaterfallModelWithMaintenanceCircleTheWaterfallModelWithPrototypingTheSpiralModel 瀑布模型 原型模型 TheVModelThePhasedDevelopmentModelTheIncrementalandIterativeModelRUP 16 7 软件工程的成本及分布 软件成本分布取决于所采用的软件过程和所开发的软件类型 一般的成本分布 描述 设计 开发 集成与测试 15 25 20 40 需求极高的软件系统的集成与测试成本50 软件进化的成本软件维护的成本基于WEB的电子商务系统的成本模型 17 8 软件工程方法 结构化分析方法 DeMarco 1978 YourdonE 和ConstantineL 等 JSD方法 Jackson 1983 OO方法 Booch 1994 Rumbaugh等 1991 18 UML UnifiedModelingLanguage 1994 OO思想已经贯穿整个软件生存期 具有影响的OOA D方法达50余种 UML是一种对软件密集型系统进行可视化 详述 构造和文档化的建模语言 主要用于分析和设计阶段的系统建模 19 UML2 0 1994Booch方法RumbaughOMTCoad YourdonFireSmith方法JacobsonOOSE 1995 10发布UnifiedMethod0 8 1996 6发布UML0 9不包含过程指导 Rational联合12家公司成立UML组织 形成UML1 0 1997 1提交给OMG 1997 11 4 OMG采纳UML1 1 2002发布UML2 0 20 统一过程 RUP RUP的突出特点用况驱动 系统功能 以构架为中心 表现形式 迭代和增量开发 过程实施 21 TendencyforChangewhenUsingOOParadigm Jacobsonetal 1995 22 9 什么是CASE Computer AidedSoftwareEngineeringCASE是支持软件工程实施的一系列工具的集合 低端CASE工具支持实现和测试的工具高端CASE工具支持分析和设计的工具 23 10 优良软件的属性 功能属性非功能属性 24 11 软件工程所面临的主要问题 遗留系统的挑战多样性的挑战交付上的挑战 25 软件工程总体面临的困难与风险 复杂性与大量的细节 火星探测器的失败 技术的不确定性 技术的发展与开发人员对技术的理解程度都不同 由于交流障碍而引起的需求不确定性需求是持续变化的不断的修改所带来的错误使得软件退化人为和市场的风险软件费用 可靠性 生产率 重用问题难以解决 26 12 职业和道德上的责任 软件工程是应该具有良好的职业道德无论是否签署了保密协议都严格保守雇主或客户的机密 实事求是地表述自己的工作能力 不接受超出自己能力的工作 应知晓控制专利权 著作权等知识产权使用的法律 避免计算机滥用 ACM IEEE 英国计算机协会等组织颁布了职业行为准则和职业道德准则 只涉及基本的道德行为 27 软件工程人员应当遵守的原则 IEEE ACM 1999 节选 公众感 软件工程人员应始终与公众利益保持一致 客户和雇主 软件工程人员应当在与公众利益保持一致的前提下 满足客户和雇主的最大利益 产品 应保证其产品及其附件达到尽可能高的行业标准 判断力 软件工程人员应具有公正和独立的职业判断力 管理 软件工程管理者和领导者应拥护并倡导合乎道德的适合软件开发和维护的管理办法 职业感 应弘扬职业正义感和荣誉感 尊重社会公众利益 同事 软件工程人员应公平对待和协助每位同事 自己 软件工程人员应毕生学习专业知识 倡导合乎职业道德的职业活动方式 28 一 软件工程概述 软件工程的基本概念基于计算机的系统工程软件过程软件项目管理的基本内容 29 1 系统总体特性 功能特性非功能特性 如可靠性 安全性 保密性等 与系统总体可靠性紧密关联的3个方面 硬件可靠性软件可靠性 在第16 17章讨论 操作可靠性 30 2 系统及其环境 系统都是在一定的环境中存在的 系统环境必将影响系统的功能和性能 环境包含一系列相互作用的其它系统 有时 环境可能被看作是一个独立的系统 系统工程师一定要了解系统环境在许多情况下 系统的目的就是要改变环境 一个系统的功能要受到环境变化的影响 这种影响可能很难估计 31 3 系统建模 系统建模作为系统需求和设计活动的一部分 描述组成系统的组件以及组件之间的关系 系统体系结构 系统体系结构通常以方块图来描述 一个系统体系结构可以以功能为单位划分成子系统或功能组件 而不必关心由硬件还是软件实现 32 功能组件可以分为六类 传感器组件 收集来自系统环境的信息 执行机构组件 引起一些系统环境的变化 计算组件 给定输入 执行计算并产生输出 通信组件 实现系统组件之间的彼此通信 调度组件 协调组件间的操作 接口组件 将一个组件中的表示转换成另一个组件中的表示 33 4 系统工程过程 需求定义 系统设计 组件开发 系统集成 系统安装 系统进化 系统退役 34 系统需求定义注重三种类型的需求 抽象的功能需求系统特性系统一定不能具有的性质系统设计所包括的活动有 分割需求 通常有多种分割方法 可以产生不同的方案 识别子系统为子系统分配需求 通常由于外购COTS子系统带来的限制而需要修改需求 描述子系统的功能定义子系统的接口 35 子系统开发所常见的问题 通常可以并行开发不同的子系统一些超出子系统范围的修改经常发生 但是对已经实现的硬件工程的修改往往带来非常昂贵的代价 这时修改往往落在软件上 软件的固有柔性 flexible 说明软件需求的变化更大更频繁 系统集成最好采取增量式过程 其理由是 子系统的开发时间通常无法预计增量式集成可以减少错误定位的成本 错误定位可能引起不同子系统的承包商之间的争论 解决问题的谈判须花费时日 36 5 系统采购 系统获得的过程包括选择最好的购买方式和最佳的供货商 在做出采购决策之前 一些相关的系统描述和体系结构设计必须完成 以便确定哪些子系统可以通过直接购买 而不必或避免重新开发 通常单个机构无法完成大型复杂系统所有组件的设计 制造和测试 此时 客户必须选择和确定主承包商和子承包商 37 承包商与子承包商模型 38 一 软件工程概述 软件工程的基本概念基于计算机的系统工程软件过程软件项目管理的基本内容 39 1 软件过程模型 一个软件过程模型是软件过程的一个抽象表示 一般使用过程模型区分或解释不同的软件开发方法 在实际的软件开发中 很少单独使用单一的过程模型 4类软件过程模型生命周期模型 瀑布模型 进化式开发模型形式化系统开发模型面向复用的开发模型 瀑布模型 瀑布模型 WaterfallModel 软件生存周期模型 ClassicLifeCycleModel 线性顺序模型 LinearSequentialModel 41 瀑布模型的三个特点 阶段间具有顺序性和依赖性推迟实现的观点质量保证的观点 42 瀑布模型的优点 开发过程基本上是线性顺序的 便于管理基于 明确 完备的需求 可以获得好的开发效果 Costtochange Afterrelease Theimpactofchange Definition Development 1 5 6x 1x 60 100 x TheWaterfallModelWithMaintenanceCircle 45 进化式开发模型 进化式开发的思想 基于最初的需求 先开发一个原型系统给用户使用 然后 根据用户的反馈意见不断地修改这个系统 直到形成最后成熟的软件产品 所强调的是 需求可以不断地被补充和完善 进化式开发有两类探索式开发 其目标式与用户一起工作 共同探索需求 直到最后交付系统 抛弃式原型 开发原型的目标是理解用户需求 46 从工程学和管理学角度看 进化式开发有三方面的问题 过程不可见系统结构通常较差快速原型工具和技术往往与主流的工具和技术不相容实际使用的过程模型通常是混合模型TheWaterfallModelWithPrototypingTheVModelThePhasedDevelopmentModelTheIncrementalandIterativeModelTheSpiralModel TheWaterfallModelWithPrototyping 运行 维护 需求分析 概要设计 详细设计 编码 单元集成测试 验收测试 系统测试 ValidateRequirements VerifyDesign TheVModel ThePhasedDevelopmentModel BuildRelease2 BuildRelease1 BuildRelease3 Time Productionsystem Developmentsystem Developers Users TheIncrementalandIterativeModel IncrementalDevelopment IterativeDevelopment 51 增量开发的优点 能在较短的时间内向用户提交可以完成主要功能的产品逐步增加产品的功能 使用户有充裕的时间学习和适应新产品 减少一个全新的产品给客户组织带来的冲击 TheSpiralModel 53 螺旋模型的优点 有利于已有软件的重用有助于把软件质量作为软件开发的一个重要目标减少了过多测试或测试不足所带来的风险软件维护与软件开发没有本质区别 54 形式化系统开发 形式化开发模型类似于瀑布模型 但是软件需求描述被精练成一个用数学符号表达的详细的精确的形式化描述 需求描述经过一系列的变换过程 最终形成可执行程序 净室过程 Cleanroom 最初有IBM开发 增量式形式化开发和验证 一个形式化开发成功应用的例子 OperationalSpecificationModel TransformationalModel 57 面向复用的开发 面向复用的开发依赖于可以存取的可复用组件集成这些组件的框架面向复用的开发过程需求描述组件分析需求修改使用复用的系统设计开发和集成系统有效性验证 58 2 软件描述 可行性研究需求导出和分析需求描述需求有效性验证 59 3 软件设计与实现 体系结构设计子系统的抽象描述 如包图 接口设计组件设计数据结构设计算法设计 60 4 软件有效性验证 单元测试功能模块测试子系统测试系统测试验收测试 如 测试 测试 61 5 软件进化 软件进化 即软件在其生命周期内不断地随着需求的变更而变更的过程 软件系统的柔性决定了软件进化的现实避免昂贵的硬件修改软件进化亦存在一些问题软件进化可以看作是软件开发过程和软件维护过程的统一 62 6 自动化的过程支持 计算机辅助软件工程 CASE 有两个因素限制了CASE工具的使用软件工程本质上是一个富有创造力的设计活动 已经存在的CASE能使一些常规活动自动化 但尝试用人工智能技术代替人的创造性活动远未成功 软件过程强调的是团队活动以及涉众者之间的交流 在此 CASE也不能提高更多的支持 63 CASE分类 Fuggetta 1993 64 CASE工具的功能分类 65 一 软件工程概述 软件工程的基本概念基于计算机的系统工程软件过程软件项目管理 66 软件项目管理要点 软件项目管理是必要的 软件项目管理与其它的工程管理有明显的区别 软件项目管理者需要承担多种不同的任务 其中最重要的活动是项目规划 估算和进度控制 项目里程碑是一个项目活动可以预期的结果 到达一个里程碑就要把项目进展报告提交到管理层 为了有效控制项目进度 可以借助于各种各样的图表跟踪 表示项目进度 应识别和评估重大的项目风险 判断这些风险发生的可能性和后果 67 1 管理活动 管理活动包括 人员管理软件成本估算质量管理过程改善软件配置管理 68 2 项目规划 项目规划的实质是项目管理者必须预测可能出现的问题 并准备有效的解决办法 项目规划的主要内容是制定项目计划 质量计划 有效性验证计划 配置管理计划 维护计划 人员培训计划等 69 3 项目调度 项目管理者要估算完成各项活动所需的时间和资源 并按照一定的顺序把它们严密地组织起来 具体活动包括 识别活动 任务 识别活动依赖关系估算活动的资源为活动分配人员创建项目图表 条形图和活动网络图 70 4 风险管理 识别风险并制定计划 以最大限度地降低风险对项目的影响 这种活动叫做风险管理 Hall 1998 三类风险产品风险 影响所开发软件产品的质量和性能的风险 项目风险 影响项目进度或项目资源的风险 业务风险 影响软件开发机构或产品购买机构的风险 风险管理过程风险识别风险分析风险规划风险监控 71 可能出现的软件风险 72 风险分析 73 风险因素分析 74 风险管理策略 75 高级软件工程 一 软件工程概述二 软件需求工程三 软件设计四 检验和有效性验证方法五 软件进化六 软件项目管理七 AdvancedTopicsinSoftwareEngineering 76 需求工程 软件需求 第5章 需求工程过程 第6章 需求建模 第7章 软件原型系统开发 第8章 形式化描述 第9章 77 本章要回答的主要问题 什么是用户需求 系统需求 这些需求应使用不同的方法表示 功能需求和非功能需求之间的不同 描述系统需求的两种技术 在需求文档中如何组织需求内容 78 1 用户需求 系统需求与软件设计描述 需求是对系统应该提供的服务和所受约束的描述 由于需求要向不同类型的涉众 读者 传达不同层次的信息 可以将需求分为 用户需求 目标需求 用用户所熟悉的表达形式所给出的需求描述 系统需求 产品需求 详细地给出系统将提供的服务以及系统所受到的约束 比用户需求更具体 更形式化 软件设计描述 设计层需求 在系统需求描述的基础上再加入更加详细的需求细节 79 用户需求与系统需求示例 80 不同层次的需求示例 R1 预算误差应在5 之内R2 产品应支持费用注册 以及根据经验数据报价R3 产品应具有记录 检索经验数据的功能R4 系统的屏幕图像应如附件xx所示 目标层需求 域层需求 产品层需求 目标需求 81 用自然语言描述的用户需求可能描述不够清楚 二义性 含糊不清 自相矛盾等 需求混乱 功能需求 非功能需求 系统目标和设计信息无法清晰地区分 需求混合 多个不同的需求交织在一起 以一个需求的形式给出 系统需求描述可能包括许多不同的模型 如对象模型 数据流模型等 82 原则上讲 系统需求仅仅描述做什么 而不应该描述如何实现 然而 要给出细节上的需求而不提到任何设计信息 事实上也是不可能的 通常系统需求依照构成系统的各个子系统结构来给出 即由初始的系统体系结构来构造需求描述 通常目标系统和现存系统户操作 这就约束了目标系统的设计 同时这些约束又构成了新系统的需求 某些特别的设计 如N 版本设计 是系统的一个外部需求 83 系统需求描述工具 84 2 功能需求与非功能需求 另一种需求层次的划分领域需求 业务需求 用户需求功能需求非功能需求业务需求 BusinessRequirement 反映了组织机构或客户对系统 产品高层次的目标要求反映目标系统所处领域的特点在项目视图与范围文档中予以说明 85 用户需求 UserRequirement 用户使用产品必须要完成的任务在使用用例文档或方案脚本说明中予以说明功能需求 Function BehavioralRequirement 定义了开发人员必须实现的软件功能 使得用户能完成他们的任务 从而满足了业务需求对系统应该提供的服务 如何对输入做出发应以及系统在特定条件下的行为的描述 涉及与本系统有接口的其他系统的所有事情 可能需要明确声明系统不应该做什么 86 非功能需求 Non Requirement 对系统提供的服务或功能给出的约束 包括性能指标 对质量属性 qualityattribute 的描述 外部接口以及设计与实现的约束 constraint 时间约束 标准等 非功能需求最好是可以验证的 但实际上对需求量化通常很难 非功能需求与功能需求有时会发生冲突 非功能需求之间会发生冲突 87 非功能需求分类 88 业务需求 用户需求 质量属性 外部接口 系统要求 约束 功能需求 项目视图和范围文档 使用实例文档 需求规格说明 业务需求 软件需求各组成部分之间的关系 89 功能需求示例 大学图书馆系统 功能需求以不同的详细程度重写 需求1和3 含糊的表达 适当的浏览器 90 容易忽略的非琐碎要求 示例 R1 根据客房类型而不是客房号进行预订R2 考虑到预订客房的客户有可能不入住 可以接受超过空闲客房数量的预订R3 授权的系统管理员可以自己定义电费的分类单价R4 91 3 软件需求文档 SRS SoftwareRequirementspecification Heninger对软件需求文档提出的6点要求 应该只描述系统外部行为应该定义实现上的约束应该是容易变更的应该成为系统维护人员的参考工具应该记录系统的整个说明周期应该对未料到的事件给出可接受的反应 92 需求文档结构 IEEE标准见第78页 引言 问题定义所确定的目标和范围术语 定义文档中的技术术语数据描述 数据流图 数据字典等等功能描述 功能要求文档 可形式化描述 性能描述 性能要求文档质量保证 描述交付前需要进行的各种测试和验收标准其它 运行要求 将来可能的要求附件索引 93 需求工程 软件需求 第5章 需求工程过程 第6章 需求建模 第7章 软件原型系统开发 第8章 形式化描述 第9章 94 本章要回答的主要问题 需求工程活动及其之间的关系需求导出和分析的一些技术需求有效性验证和需求评审为什么说需求管理是必须的 它如何支持其它的需求工程活动 95 1 基本概念 需求工程是对服务和约束的发现 分析 描述和检验的过程 需求工程的4个高层通用过程 可行性研究需求导出和分析需求描述和文档编写需求有效性验证 96 需求分析的涉众 合同监督人员 提出里程碑 Milestones 和约束系统开发进度的计划需求者 客户 Customer 和使用者 User 开发者项目管理者 必须理解建立和使用目标系统所可能产生的后果 系统分析员 分析阶段活动的主体 设计员 依据需求提出可接受的解决方案 测试员 确保软件系统满足每一需求 97 系统分析员应具有的素质 综合能力总体规划 抽象和分解 本质确认的能力过程能力保证整个过程的善始善终的能力交流能力理解和表达能力技术水平了解问题域和描述解空间的能力 98 应该足够重视需求分析 软件项目中40 60 的缺陷都是由需求分析阶段的过失所致 Daivs1993 Leffingwell1997 对欧洲软件行业的大规模调查显示 确定和管理用户需求是问题最多的两个环节 ESPITI1995 许多软件问题都源于收集 记录 协商和修改产品需求过程中的方式不当信息收集方式不正规没有明确提出想要的功能常常存在未经沟通的错误假设需求的定义不够充分未经仔细考虑进行需求变更 99 2 可行性研究 可行性研究的焦点问题包括系统是否符合机构的总体目标 系统是否能在现有条件和预算内按时完成 目标系统能与已经存在的其它系统集成 软件可行性研究的任务技术可行性经济可行性社会可行性操作可行性 100 可行性研究是高层的分析和设计 101 可行性研究报告 1 引言 2 可行性研究前提 3 对现有系统的分析 4 所建议系统的技术可行性分析 5 所建议系统的经济可行性分析 6 社会因素可行性分析 7 其它可供选择方案 8 结论意见 102 3 需求导出和分析 通过对现实环境的研究 获得系统具体模型 去掉具体模型的非本质因素 抽取出当前系统的逻辑模型分析当前系统和目标系统的差别 建立目标系统的逻辑模型 对目标系统进行完善和补充 写出完整的需求分析 a b c d 103 104 学生在学校教材科购买教材的系统的例子 一 通过对现实环境的研究 获得系统具体物理模型 购书发票 购书单 书 购书证明 购书申请 学生 学生 李保管 孙出纳 钱会计 赵秘书 105 学生在学校教材科购买教材的系统的例子 二 去掉具体模型的非本质因素 抽取出当前系统的逻辑模型 发票 购书单 书 有效单 购书单 学生 学生 发书 开领书单 开发票 有效性 106 学生在学校教材科购买教材的系统的例子 三 分析当前系统和目标系统的差别 建立目标系统的逻辑模型 发票 购书单 书 购书单 学生 学生 发书 开领书单 审查并开发票 107 学生在学校教材科购买教材的系统的例子 四 对目标系统进行完善和补充 写出完整的需求说明 五 对需求说明进行复审 直到确认文档齐全并符合用户的全部需求为止 无效书单 发票 购书单 购书单 学生 学生 开领书单 审查并开发票 108 需求阶段所要获取的主要内容 物理环境 PhysicalEnvironment 接口 Interfaces 用户或人的因素 Factors 功能 Functionality 文档 Documentation 数据 Data 资源 Resources 安全性 Security 质量保证 QualityAssurance 109 设备的主要用途 在哪里发挥什么作用 所须设置的设备的多少 环境限制等 如温度 湿度或磁声干扰 1 物理环境描述 PhysicalEnvironment 110 来自一个或多个其他系统的输入 对一个或多个其它系统的输出 数据是否必须预先进行规定的格式化处理 数据是否需要预先存放的介质 2 接口描述 InterfaceDescription 111 谁使用系统 有几种类型的用户 每种类型用户的技术水平怎样 对每型用户需要什么样的培训 用户理解 使用系统的难易度怎样 用户误用系统的困难程度怎样 3 用户和人为因素 112 系统将做什么 系统将在何时做 有几种操作方式 系统能在何时 怎样被改变或增强 对执行速度 响应时间或数据流量有何限制和约束 4 功能描述 FunctionDescription 113 5 文档 Documents 需要多少文档 是联机文档还是静态文档或者二者皆可 文档所面向的对象 读者 114 6 数据 Data I O数据格式应该是什么样的 数据收或发的频度 数据的精确度系统流经的数据流量 数据必须在何时予以保存 保存多久 115 7 资源描述 ResourceDescription 建立和维护系统都要什么材料 人员或其他资源 开发者必须具有哪些技术 系统占用多少物理空间 对开发规定了时间表了 对用于开发或软硬件上的资金有限制 116 对系统或信息的存取必须在我们的控制之下 不同用户的数据之间将如何实现隔离 不同用户程序之间 以及和操作系统间怎样隔离 系统如何备份 备份副本必须被存于一个不同的位置 应采取措施防火 防水防盗等安全措施 8 安全描述 Security 117 系统必须有效检测并隔离故障 平均无故障时间规定为多少 对一次失败后重启系统有一个最大时间 系统如何将变化合并到设计 维护仅仅是纠正错误 还是包括改进系统 对资源和响应时间使用什么样的有效度量 系统移植性 可维护性等要求 如何向别人示范系统的特征 9 质量保证 QualityAssurance 118 对需求说明书的要求 正确性无二义性 需求确实是用户所需吗 完整性 完备性 包括用户需要的每一功能或性能 一致性 需求之间不能互相矛盾 可检验性 非计算机人员可以理解 可实现性 有效性 需求是能够现实的吗 硬件系统的支持力度怎样 可修改性可跟踪性注释 119 4 需求规约的验证 1 验证是为了确保需求说明准确 完整地表达必要的质量特点审查需求文档以需求为依据编写测试用例写出黑盒功能测试用例编写用户手册要用浅显易懂的语言描述出所有对用户可见的功能确定合格的标准 120 需求规约的验证 2 验证的方法复审和进一步需求分析实现原型系统支持需求分析工具验证的主要内容一致性验证现实性验证 需求是现实的吗 完整性 完备性 和有效性验证 121 5 需求管理 需求管理是对需求变更了解和控制的过程 需求管理的任务是 与客户就软件需求达成并保持一致 Paulk1995 持久的需求与易变的需求一个变更管理过程由三个阶段问题分析和变更描述变更分析和成本计算变更实现 122 需求管理活动 需求管理活动包括 定义需求基线审查变更请求 评估可能产生的影响以决定是否批准以可控的方式将批准的变更融入项目中保持项目计划与需求的同步基于对需求变更影响的估计协商新的需求约定跟踪每项需求 找到对应的设计 代码和测试用例 在项目的开发过程中始终跟踪需求的状态和变更 123 需求变更 需求开发与需求管理的分界 分析 记录审阅 协商 需求变更过程 市场营销客户管理层 需求开发 需求管理 市场营销客户管理层 项目变更 项目环境 124 对项目需求状况作出快速评估 1 项目前景 vision 和范围 scope 未曾明确定义客户太忙 没时间与需求分析和开发人员一起讨论需求用户代理 如开发经理 用户负责人 营销人员等 自诩可以代表用户 其实不能准确说出用户的要求需求只存在于那些所谓专家的脑子里 没有被记录下来客户坚持所有需求都很重要 不愿排出它们的优先次序开发人员在编码过程中发现需求有歧义 缺少足够的信息 只能去猜测 125 对项目需求状况作出快速评估 2 开发人员与客户沟通时只关心用户界面 忽略了用户需要用软件做什么客户签字确认了需求却又一直提出修改要求项目范围因接受需求变更而扩大 却没有相应地增加投入或剪裁功能 进度因而被延误需求变更的请求被弄丢 开发人员和客户都不了解所有变更请求的状态开发人员按照客户要求实现的功能无人问津需求规格说明中的要求都实现了客户却不满意 126 需求工程 软件需求 第5章 需求工程过程 第6章 需求建模 第7章 软件原型系统开发 第8章 形式化描述 第9章 127 本章要回答的主要问题 系统上下文建模的重要性行为建模 数据建模和对象建模UML用于不同类型的系统模型CASE工作平台是如何支持系统建模的 128 3 系统模型 模型是系统的抽象视图 它忽略了系统中的所有细节 从不同的角度 外部 行为或结构 表达系统 形成不同类型的模型 上下文模型 行为模型 结构模型 上下文模型 系统环境模型 表达系统在整个环境中与其它系统和过程的位置关系 如用例图模型是一种上下文模型 状态机模型用来描述系统的行为 以响应内部和外部的事件 它是一种行为模型 结构模型包括体系结构模型和数据结构模型 129 数据流模型用来描述数据是怎样一步步在处理序列中流动的 它不仅可以描述系统内的处理过程 行为 也能够有效地描述系统的上下文 E R模型是一种最广泛使用的数据结构模型 对象建模在一定程度上是结构建模和行为建模的结合 UML已经被OMG认定为对象建模标准 130 HowtoExpressRequirements StaticdescriptionsDynamicdescriptionsObject orientedspecificationFormalMethods 131 1 StaticDescriptions 数据流图 数据字典 加工说明等判定表 DecisionTables 判定树E R模型层次方框图 Warnier图 IPO图UML中类图 包图 132 WarnierDiagrams Softwareproducts System Application OS n1 Compiler n2 SoftwareTool Editor n3 Testdriver n4 CADtool n5 133 IPODiagrams 134 E R模型 Entity Relationship 概念模型 E R图 逻辑模型 二维表的定义 物理模型 存储空间的定义 如定义各个字段的大小 数据库的设计一般应经过由概念模型到逻辑模型 再到物理模型的映射过程 135 数据结构的规范化 1970年 IBM的E F Godd提出关系模型 由二维表表示 按照属性间的依赖程度区分关系规范化的程度 由范式 NormalForm 来表示 1NF 表中不能有表 每个信息项必须是一个不可分割的数据项 2NF 非主属性由关键字唯一确定3NF 任何非主属性间不存在函数依赖 即非主属性相互独立 136 DecisionTables 137 2 DynamicDescriptions FunctionalDescriptionsandTransitionDiagramsEventTablesPetriNets 138 FunctionalDescriptions Statei Statek Conditionj 139 TransitionDiagrams Si Sk EventorConditionX 状态迁移图是描述系统的状态如何响应外部的信号进行推移的一种图形表示 圆圈 表示可得到的系统状态箭头 表示从一种状态向另一种状态的迁移 140 t1 中断事件t2 中断已处理t3 分配CPUt4 用完CPU时间 当有多个申请占用CPU运行的进程时 有关CPU分配的进程的状态迁移 141 可得到的状态 就绪 运行 等待生成的事件 t1 t2 t3 t4t1 中断事件 t2 中断已处理t3 分配CPU t4 用完CPU时间 142 状态迁移图的优点 状态之间的关系能够直观地捕捉到由于状态迁移图的单纯性 能够机械地分析许多情况 可很容易地建立分析工具 143 FenceDiagramshowingStateTransitions Hotelreservations Null Requested Onwaitinglist Confirmed Used Canceled Archive 144 UseUMLtoRepresentOO OMG ObjectManagementGroup haveadoptedUMLastheOOnotationalstandard UMLcanbeusedtovisualize specify ordocumentaproblem UMLcanbeusedthroughoutthesoftwaredevelopmentprocess 145 UML由两大部分的组成 UML语义描述基于UML的精确元模型定义 元模型为UML的所有元素在语法和语义上提供简单 一致和通用的定义性说明 使开发者在语义上取得一致 消除了因人而异的表达方法所造成的影响 UML还支持对元模型的扩展定义 146 UML表示法定义UML符号 为开发者或开发工具使用这些图形符号和文本语法进行系统建模提供标准 这些图形符号和文字所表达的是应用级的模型 在语法上它是UML元模型的实例 147 UML的具体组成 视图 View 是表达系统的某一方面特征的UML建模元素的子集 视图由多个图构成 是在某一个抽象层上对系统的抽象表示 图 Diagram 模型元素集的图形表示模型元素 ModelElement 代表OO中的类 对象 消息和关系等概念 是构成图的最基本的常用概念 148 通用与扩展机制 GeneralandExtensionMechanism 通用机制用于表示其他信息 比如注释 模型元素的语义等 扩展机制使UML能够适应某种特殊的方法 或扩充至一个组织或用户 149 不同视角建模形成系统的不同视图 用例视图 UseCaseView 强调从用户的角度看到的或需要的系统功能 逻辑视图 LogicalView 展现系统的静态或结构组成及特征 故又称为StructuralModelView和StaticView 150 并发视图 ConcurrentView 体现系统的动态或行为特征 故又称为BehavioralModelView和DynamicView 组件视图 ComponentView 体现系统的结构或行为特征 故又称为ImplementationModelView 配置视图 DeploymentView 体现系统的实现环境的结构或行为特征 故又称为EnvironmentModelView和PhysicalView 151 UMLdiagrams StaticviewisdepictedwithUsecases 用例图 Classdiagrams 类图 Packagediagrams 包图 Deploymentdiagrams 配置图 152 DynamicviewisdepictedwithStatediagrams 状态图 Activitydiagrams 活动图 Sequencediagrams 顺序图 Collaborationdiagrams 合作图 RestrictionsandformalizationBeexpressedwithOCL objectconstraintlanguage 153 UMLdiagrams UsecasesDiagramStaticDiagramClassdiagramsPackagediagramsBehaviorDiagramStatediagramsActivitydiagrams 154 UMLdiagrams InteractiveDiagramSequencediagramsCollaborationdiagramsImplementationDiagramComponentdiagramsDeploymentdiagrams 155 需求工程 需求及需求工程概念 第5章 需求工程过程 第6章 需求建模 第7章 软件原型系统开发 第8章 形式化描述 第9章 156 4 软件原型系统开发 157 需求工程 需求及需求工程概念 第5章 需求工程过程 第6章 需求建模 第7章 软件原型系统开发 第8章 形式化描述 第9章 158 5 形式化描述 159 高级软件工程 一 软件工程概述二 软件需求三 软件设计四 检验和有效性验证方法五 软件进化六 软件项目管理七 AdvancedTopicsinSoftwareEngineering 160 软件设计 体系结构设计 第10章 分布式系统体系结构 第11章 面向对象的设计 第12章 实时软件的设计 第13章 使用复用的设计 第14章 用户界面设计 第15章 161 本章要回答的主要问题 软件体系结构设计的重要性可能用于系统体系结构的不同模型一系列不同类型的软件体系结构领域相关的体系结构怎样作为产品线体系结构的基础 162 软件体系结构研究的主要内容 软件体系结构建模软件体系结构风格软件体系结构描述动态软件体系结构Web服务体系结构基于体系结构的软件开发软件体系结构的分析与测试软件体系结构评估软件产品线体系结构 163 软件体系结构的研究背景 1 随着软件系统规模越来越大 越来越复杂 整个系统的结构和规格说明显得越来越重要 对于大规模的复杂软件系统来说 对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已经变得明显重要得多 对软件体系结构的系统 深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径 164 软件体系结构的研究背景 2 事实上 软件总是有体系结构的 不存在没有体系结构的软件 软件体系结构虽脱胎于软件工程 但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法 最近几年软件体系结构研究已完全独立于软件工程的研究 成为计算机科学的一个最新的研究方向和独立学科分支 系统体系结构影响性能 鲁棒性 分布能力 可维护行等非功能需求 反之 系统的结构和风格依赖于系统的非功能需求 165 软件体系结构的研究背景 3 性能 如果性能是关键性需求 那么体系结构的设计就要定位在少数几个子系统上的一些关键性操作上 这可能意味着系统使用较大粒度的组件 保密性 如果保密性是关键性需求 那么体系结构的分层设计 把重要资源放在内层 并且在每层采用严格的安全验证 安全性 如果安全性是关键性需求 那么体系结构的设计就要将与安全相关的操作集中子一个或少数几个子系统中 以减少安全有效性验证方面的问题 降低成本 便于系统的保护 166 软件体系结构的研究背景 4 可用性 如果可用性是关键性需求 那么体系结构的设计就要采用冗余性组件 以便组件的更新和替换 可能在不停止运行的情况下 可维护性 如果可维护性是关键性需求 那么体系结构的设计就要使用小粒度的自包含组件 以便于更换 这里 数据的共享方式以及松耦合结构尤为重要 实际应用中 经常存在冲突 只能采用折中方案 167 体系结构设计的一般过程 系统结构化 将系统分解成一系列基本子系统 是一个独立的软件单元 并识别它们之间的通信 控制建模 建立系统各部分之间控制关系的一般模型 模块分解 将子系统进一步分解成模块 并确定模块之间的关联 168 子系统 模块与构件 首先 子系统和模块之间没有明确的界线 一个子系统独立构成系统 不依赖其它子系统提供的服务 子系统由模块组成 要定义与其它子系统的接口 模块通常是一个能够提供一个或多个服务的系统组件 一般不被看成一个独立的系统 模块通常由许多其它更简单的组件组成 169 构件 组件 构件是指语义完整 语法正确和有可重用价值的单位软件 是软件重用过程中可以明确辨识的系统 结构上 它是语义描述 通讯接口和实现代码的复合体 170 构件模型的三个主要流派 OMG ObjectManagementGroup 对象管理集团 的CORBA CommonObjectRequestBrokerArchitecture 通用对象请求代理结构 Sun的EJB EnterpriseJavaBean Microsoft的DCOM DistributedComponentObjectModel 分布式构件对象模型 171 青鸟构件模型 172 软件体系结构的定义 1 DewaynePerry和A1exanderWo1f软件体系结构是具有一定形式的结构化元素 即构件的集合 包括处理构件 数据构件和连接构件 处理构件负责对数据进行加工 数据构件是被加工的信息 连接构件把体系结构的不同部分组合连接起来 这一定义注重区分处理构件 数据构件和连接构件 这一方法在其他的定义和方法中基本上得到保持 173 软件体系结构的定义 2 MaryShaw和DavidGarlan软件体系结构是软件设计过程中的一个层次 这一层次超越计算过程中的算法设计和数据结构设计 体系结构问题包括总体组织和全局控制 通讯协议 同步 数据存取 给设计元素分配特定功能 设计元素的组织 规模和性能 在各设计方案间进行选择等 软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些