第一讲.需求工程导论.ppt

1.2 90年代的软件生产状况调查——需求问题的典型案例[Bray2002] PROMS（演出权益协会）,11M￡,1992,未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周（与客户沟通的问题） RISP（西萨克斯地区信息系统计划）, 43M￡ ,1990,缺少清晰的项目范围定义（需求的边界问题） TAURUS(伦敦股票交易), 75M￡(1.4B￡), 1993,未能协调不一致的需求（不一致需求的管理问题） LASDS(伦敦救护车服务派遣系统), 1992,社会服务领域糟糕的需求分析（需求不清晰） ATC(空中交通控制系统), 1.8B￡,1998-2001,缺乏健壮的需求规格说明（需求没有搞清楚就匆忙开始工作) 近期的软件失效案例 同时访问同一资源的计算机超出预定范围 开放软件面对各种病毒攻击 2008年6月30日，北京奥运门票系统在提交使用的当天即发生瘫痪；原因之一 是对系统用户数的预测不足 2004年4月，东京证交所称其交易系统出现的故障使得某证券公司未能迅速取消 一笔输错指令的交易，导致该公司蒙受了近2.5亿美元的损失；故障原因之一， 对操作人员的错误行为的预期不充分 主要内容 软件的需求问题 需求问题的原因分析 应用软件的模拟特性 需求问题的技术原因分析 需求工程 需求工程师 2.1 应用软件的模拟特性——软件的三种类型 软件类别 纯工具型软件 应用型软件 专业用户 普通用户 评判标准 功能的复杂性 使用的高效性 技术的先进性 功能的有用性 使用的方便性 技术的可行性 功能的“模拟”性 使用的方便性 技术的可行性 关注点 创新性 有效性 模拟性 示例系统 编程环境 DBMS Office 语言翻译 MIS EAI 2.1 应用软件的模拟特性——软件的分析活动 2.1 应用软件的模拟特性——软件模拟性的实践调查 对应用型软件的“模拟”特性理解及应用问题 Capers Jones[Capers1996]在调查了几百个公司之后发现超过75％的企业在需求处理环节存在不足。 2000年Nikula等人在对芬兰的中小型公司进行需求处理实践情况评价时发现[Nikula2000]：在以30分为标准线的情况下，75%的公司竟然在10分以下。 Hofmann等人在欧洲的需求工程实践调查中发现仅有约1/3的项目有明确的需求处理过程[Hofmann2001]。 Juristo 等人在对欧洲的150多名RE实践者进行调查后发现，在需求处理的诸多技术当中，需求获取和冲突协商的技术没有得到充分的应用[Juristo 2002]。 研究也发现当软件生产面临时间、市场等其他压力时，漠视“模拟”特性的情况就更为严重[Lubars1993，Francisco2003] 2.2 需求问题的技术原因分析 非技术性和社会性因素 组织机构文化、社会背景、商业目标、利益协商 关注软件系统和现实之间的互动效应 软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件内部的数据流与状态更应该得到重视 解决方案和具体应用环境相关的 不能忽视具体应用环境中的相关因素，例如组织机构的文化、组织结构的规范、组织的行业规范、组织的社会背景等等 单纯通过技术的运用来建立一个一致、完整的需求模型是不太可能的 面对冲突要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商 2.2 需求问题的技术原因分析 结构化分析和面向对象分析具有一定的先天缺陷 编程 －设计－分析 设计和编程都有构建高质量（健壮性、可维护性、适应性等等）软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡，所以，它们在设计领域的应用也取得了成功 但是需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实 2.2 需求问题的技术原因分析 以“企业”为中心的软件反映了软件规模日益扩大 一方面提高了需求处理中非技术性和社会性因素的影响比重 另一方面也进一步放大了传统技术在需求处理阶段的不适应性 2.2 需求问题的技术原因分析 需求错误的高代价性 课程介绍 课程安排 课程的目的和背景 教学大纲和主要内容 参考书目 课程安排 每周4*50分钟（8周）其中 第一周（9月5号上午）需求工程的基本知识一 第二周（9月12号上午）需求工程的基本知识二 第三周（9月19号上午）需求工程的获取技术 第四周（9月26号上午）需求工程的建模技术一 第五周（10月3号上午可能放假）需求建模技术二，课程设计指导 第六周（10月10号）需求管理技术 第七周（10月17号）主要的需求分析方法介绍 第八周（10月24号）复习考试 课堂作业 随堂练习 课程设计报告一份 考试和评分标准 随堂练习20% 课程设计案例分析报告30% 课程结束考试50%