需求工程讲稿-第二讲需求工程的基本原理.pptVIP

需求工程的基本原理 软件工程的本质 什么是需求工程 需求工程在生命周期中的作用 有效性的问题 问题领域的类型 软件开发的本质 软件要解决的问题具有： 复杂性 不一致性 可变性 不可见性 软件开发的不变量 软件是开发出来的，不是制造出来的（充满了各种不确定性） 软件工程的进展为开发实践带来了很多确定的因素，但然不象传统工程那样成功，软件项目的成功仍然无法保证。 算法、代码库、可复用类、软件构件：模块重用 商用成品软件：从零开始变成客户化软件 各种概念结构：支持从零开始的软件开发 但是任何组织不可能找到一个软件包使它的核心业务活动可以自动生成 项目成败的因素：投入者 客户： 客户的需要被误解或没有被完全捕捉 客户需求变化得过于频繁 客户没有准备为项目提供足够的资源 客户不想与开发者合作 客户具有不现实的期望 系统不再对客户有利 开发人员： 不能胜任本项任务 开发者的技能和知识非常关键 杰出的设计来自杰出的设计者 项目成败的因素：过程 软件开发过程确定以促进开发小组内部合作的活动和组织的程序，使得能交给客户一个性能优良的产品 过程模型包括： 说明执行活动的次序 说明需要交出什么样的制品，以及什么时候交出 将活动和制品交给开发者 提供监控项目进程、评估产出和计划未来项目的准则 每个组织都有自己的过程，或客户化一个通用过程模板 几种典型的过程改进模型 迭代增量式开发： 迭代涉及管理可执行的版本流的过程； 增量涉及系统结构连续继承以产生这些版本的过程； 关键：系统划分的规模和模块间的偶合度 几种典型的过程改进模型 几种典型的过程改进模型 ISO9000标准 主要承诺：如果过程正确，则该过程的产出也将是令人满意的 没有强制性的或规定的过程 组织要记录和整理其所有活动，并为每个过程规定成文的步骤 项目成败的因素：建模 需求工程的作用是捕获系统需求，为系统建模，并用一种语言表达系统模型 语言：支持在描述性语句中捕获过程性含义，说出什么需要做，而不是怎样去做 CASE工具：支持模型的协同存取和开发者之间的合作 目前，UML及其工具： 支持面向对象风格 支持静态结构建模和动态行为建模 总结 问题 社会系统对软件的依赖越来越强 软件成为任务关键系统的最大的开销点 目前的情况：失败的项目造成巨大的浪费。比如，1997年GAO报告，6年浪费$145billion 失败的后果花费很高的代价。比如，Intel Pentium Bug： $475million 没有“银弹” 软件在规模上越来越复杂 软件是不可见的和抽象的 没有构造性的步骤：软件是可修改的！ 但，早期的建模和分析非常重要 缺陷发现的越早消除它就越便宜 需求缺陷很可能是安全相关的 早期的建模和分析还不够 需要向每个人传递需求 需要得到所有投入者的同意 需要理解系统的所处的环境 需要理解开发过程所处的环境 需要随需求的进化保持不断的更新 解决方案？ 什么是需求 需求的重要性 工程的观点 工程是关于开发针对问题的解决方案的 只有当工程师对问题有了充分的理解后，一个好的解决方案才能被开发出来 经济的观点 对错误，越长时间没有被检测出来，开销就会越大 在维护阶段修正一个需求时的错误，比在需求阶段修正它，代价会增加100倍 经验的观点 未能理解和管理需求是过度开销和不能按时完成等的最大的原因 安全性的观点 安全相关软件中的错误最经常出自不适当或错误理解的需求 与需求相关的困难是在系统测试中发现的安全相关错误的关键根源 什么是需求工程 需求工程：软件工程还是系统工程 窄义地说 软件的存在只是为了让硬件更有用 硬件的存在只是为了让软件可运行 软件是混合系统的一个组件 广义地说 混合系统的存在是为了实现用户的某个（某些）现实的目的 是一个更大的社会系统的一部分 需求工程：软件工程还是系统工程 如果现实系统已经存在 软件需求要从用户的需要、硬件的能力中导出，是一种应用工程 如果现实系统要同时被开发 软件需求要从现实系统的规格说明中导出 现实系统和软件需求必须同步进化 现实系统被认为总是可变的 是一种系统工程 需求工程还是系统分析 系统分析的方法，抽象要点： 系统有一定的目标 系统与外界之间有边界，并通过边界进行物质或信息的交换 系统可以分成若干相互联系的部分，称之为子系统 在各个子系统之间存在各种物质或信息的交换关系 系统是分层次的 系统是动态的，含自我调节的机制和功能 需求工程还是系统分析 需求工程从信息系统分析中成长出来，但是 系统分析关注于一个组织中的信息系统 已经开发或被采用了的大多数是非形式化的表示法、工具和方法学，如DFD、E-R、OO范例 经历了广泛的实践，大量通过管理咨询公司 教学主要是在管理学、并逐步地在工业工程和计算机程序设计领域的本科和研究生层次上进行 需求工程还是系统分析 需求工程超出了系统