《结构化开发方法》PPT课件

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

3. 建模(Modeling)
系统建立模型的目的 主要是说明系统必须做什么,而不是怎么做
建模的方法 问题域划分-必须把大且复杂的问题划分为小且较简单的问 题 划分的方法-可以按垂直方向对功能逐层细化或按水平方向 对功能进行分解,也可两者兼有 软件需求是给出要完成的功能和处理信息上,而不应该把 实现观点作为给出要完成功能和要处理数据的出发点
软件需求规格说明
软件需求规格说明
是在对用户需求分析的基础上,把用户的需求规范化、形式化而写成的, 其目的: 为软件开发提出总体要求 作为用户和开发人员之间相互了解和共同开发的基础 具有合同的性质
初步用户手册
初步用户手册作为软件需求规格说明的附件 这是为了使开发人员与用户之间更好的沟通必须开发
的。其重点放在用户的功能和I/O上,主要用来发现系统 功能和人-机界面上存在的各种问题 一
软件需求规格说明(GB 8567-88)
1. 引言
1.1编写说明 1.2背景 1.3定义 1.4参考资料
2.任务概述
2.1目标 2.2用户的特点 2.3假定与约束
3.需求规定
3.1对功能的规定 3.2对性能的规定
研究系统规格说明和软件项目计划 必须为分析建立各种沟通(communication)关系 目标是弄清用户已经理解的基本问题元素
2. 评价和综合
评价和综合(Evaluation and Synthesis)
必须评价信息流和信息内容 定义和详细描述全部软件功能 熟悉影响系统事件前后关系的软件行为 建立系统界面的特征 揭示设计限制 综合出一个或多个解
有“从树木见森林”的能力。这是区分一位真 正杰出的分析员与一般分析员的标准。只有懂 得软件工程的分析员才做一能做到这一点
结构化分析(structured analysis, SA)
是一种信息流内容和结构的建模技术 是基于计算机系统的一种信息变换
DFD基本符号
实例:一个简化的机票销售系统
第3章 结构化开发方法
结构化开发方法
20世纪70年代发展起来的最早的开发方法 典型的结构化开发方法
美国的Coad/Yourdon的面向数据流的开发方 法
欧洲的Jackson/Warnier-Orr的面向数据结构的 开发方法
日本小村良彦的PAD(问题分析图)开发方法
本章内容安排
机票基本信息
有/无
旅客基本信息
需求
售票员根据旅客需要的航班,首先查询有无该 航班机票。若有,则负责录入旅客的基本信息 (姓名、身份证号码、航班号、票价和到达港); 保险公司的服务员负责录入保险金额;售票部经 理可随时查询每一个航班的售票情况(航班号、 售出机票的数量及营业额),并在当日结算时能 计算出日营业额
给出该系统的DFD和DD
需求分析的产品 为软件设计提供可用的数据、体系结构、人-机界面和 过程设计模型 为开发者和用户提供对软件质量Hale Waihona Puke Baidu行最后验收的准则
分析过程
软件需求分析过程
1.问题识别 2.评价和综合 3.建模 4.规格说明 5.评审
1. 问题识别
问题识别(Problem Recognition)
需求与需求分析 结构化分析 软件设计 面向数据流的设计 面向数据结构的设计 PAD图的设计 原型开发
需求与需求分析
需求分析的意义 完全弄清用户软件需求是任何一项软件开发工作成功 的前提和基础
需求分析的作用 是系统层软件配置与软件设计之间的桥梁 能够刻画软件的功能和性能 确定软件与其他系统元素(硬/软件和人)的接口 建立软件必须满足的约束
DFD(Data Flow Diagram)
本系统DFD(一种方案)
顶层DFD(0层) 二层DFD(1层) 三层DFD-1(2层-1) 三层DFD-2(2层-2)
顶层DFD(0层)
售票员 服务员
有/无 旅客基本信息
保险级别
0
各航班售票信息
机票销售系 日营业额

经理
二层DFD(1层)
分析员
有许多叫法 系统分析员、系统工程师、程序员、分析员
分析员必须具备的条件
有掌握抽象概念,并能把其整理为逻辑划分和 根据每一个逻辑划分综合为解的能力
有从冲突或混惑中吸取恰当事实的能力 有弄清用户环境的能力 有把硬件和软件系统用于用户环境的能力 有较好的用书面和口头形式进行沟通的能力
在详细低层上
为了得到对上述各种问题的回答。评审者可以集中 在规格说明的用词上,这样做能够发现隐藏在规格 说明内容中的问题。详细评审建议大纲可以从10个 方面的用词考虑(教材37页)
评审一旦完成,用户和开发者要双方签字,成为软件 开发的合同
原型开发是解决软件需求规格说明确定中各种问题的可选 方法
3.2.1精度 3.2.2时间特性要求 3.2.3灵活性
3.3 I/O需求 3.4数据管理能力要求 3.5故障处理要求 3.6其它专门需求
4. 运行环境规定
5.评审
软件需求规格说明的评审 是由软件开发者和用户共同完成
在宏观高层上
评审者要保证规格说明的完整、一致和准确,评审 时需要考虑14个方面的问题(教材36~37页)
4. 规格说明(Specification)
Balyer和Goldman提出了获得良好的规格说明的8条 原则
(1) 从现实中抽象功能性 (2) 要求一个面向过程的系统规格说明的语言 (3) 必须围绕整个系统,而软件只是它的一个部分 (4) 必须围绕系统的操作环境 (5) 必须是一个可以认知的模型 (6) 必须是可操作的 (7) 必须允许它是不完整的和可扩展的 (8) 必须是局部化和松散耦合的
模型的表达式(representation) 图形 表格 专用语言和自然语言
模型的重要作用
用辅助分析员更好地了解系统的信息、功能和行 为,从而使分析更容易和更系统化
是评审系统完整性、一致性和规格说明准确性的 关键元素
是设计的基础,能给设计人员提供一种软件的基 本表达式,它可以影射为实现文档
相关文档
最新文档