第二章 、可行性研究
可行性研究概述
可行性研究分析过程:
首先,进一步分析和澄清问题定义
然后,分析员应该导出系统的逻辑模型
最后,探索若干种可供选择的主要解法
可行性研究方法
系统流程图
系统流程图: 实质上是物理流程图,它描绘组成系统的主要物理元素以及信息在这些元素间流动和处理的情况。
系统流程图表达的是数据在系统各部件之间流动的情况,而不是对数据进行加工处理的控制过程,因此尽管系统流程图的某些符 和程序流程图的符 形式相同,但是它却是物理数据流图而不是程序流程图。
数据流图
数据流图: 是一种图形化技术,它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
通常用数据流图建立软件系统的功能模型。
数据字典
数据字典 :是关于数据信息的集合,也就是对数据流图中包含的所有元素的定义的集合。
数据字典的作用: 在软件分析和设计的过程中给人提供关于数据的描述信息。
系统的逻辑模型: 由数据流图和数据字典共同构成,没有数据字典,数据流图就不严格,然而没有数据流图,数据字典也难于发挥作用。
数据字典最主要的用途: 就是作为分析阶段的工具。
成本效益分析
第三章、需求分析
需求分析的任务是: 准确地回答“系统必须做什么”这个问题。
通常对软件系统有以下几方面的综合要求:
- 功能需求
- 性能需求
- 可靠性和可用性需求
- 出错处理需求
- 接口需求
- 约束
- 逆向需求
- 将来可能提出的要求
可以概括为功能需求和非功能需求。
结构化分析方法
结构化分析方法就是面向数据流,自顶向下逐步求精进行需求分析的方法。
通过可行性研究已经得出了目标系统的高层数据流图,需求分析的目标之一就是把数据流和数据存储定义到元素级。
快速建立软件原型是最准确、最有效、最强大的需求分析技术。
快速原型 就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。
快速原型应该具备的特性: 1.快速 2.容易修改
需求分析阶段的成果一:系统详细的逻辑模型
系统详细的逻辑模型,通常用数据流图、实体联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
需求分析过程应该建立三种模型: 数据模型(实体 -联系图)、功能模型(数据流图)和行为模型(状态转换图)。
实体联系图,描绘数据对象及数据对象之间的关系,是用于建立数据模型的图形。
数据流图是建立功能模型的基础。
状态转换图描绘了系统的各种行为模式和在不同状态间转换的方式。
需求分析阶段的成果二:软件需求规格说明书
软件需求规格说明是需求分析阶段得出的最主要的文档。
通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
第五章、总体设计
描绘软件结构的图形工具:
- 层次图
- 结构图
面向数据流的设计方法的目标: 是给出设计软件结构的一个系统化的途径。
信息流有下述两种类型 :变换流和事务流。
第六章、详细设计
详细设计的根本目标: 是确定应该怎样具体地实现所要求的系统,也就是说,经过这个阶段的设计工作,应该得出对目标系统的精确描述,从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。
详细设计阶段的任务还不是具体地编写程序,而是要设计出程序的“蓝图”,以后程序员将根据这个“蓝图”写出实际的程序代码。
程序的三种基本控制结构: 顺序、选择和循环。
结构程序设计的经典定义如下所述: “如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连接,并且每个代码块只有一个入口和一个出口,则称这个程序是结构化的。”
【人机交互页面】
在设计人机界面的过程中,几乎总会遇到下述 4 个问题: 系统响应时间、用户帮助设施、出错信息处理和命令交互。
系统响应时间是指: 从用户完成某个控制动作,到软件给出预期响应之间的这段时间。
系统响应时间有两个重要属性: 长度和易变。
3 类人际界面设计指南: 一般交互指南、信息显示指南和数据输入指南。
描绘程序处理过程的工具称为过程设计的工具,它们可以分为图形、表格和语言 3 类。
图形:程序流程图、盒图、 PAD 图。
表格:判定表、判定树。
语言:过程设计语言PDL。
- 程序流程图。又称程序框图。
- 盒图。结构程序设计。
- PAD图。问题分析图,它用二维树形结构的图来表示程序的控制流,将这种图翻译成代码很容易。
- 判定表。
- 判定树。
- 过程设计语言(PDL)。伪码。
面向数据结构的设计方法的最终目标是: 得出对程序处理过程的描述。
最著名的两个面向数据结构的设计方法: Jockson 和 Warnier 方法。
Jockson方法的逻辑关系包括: 顺序、选择和重复。
程序复杂度的定量度量: McCabe 方法和 Halstead 方法
McCabe 方法: 根据程序控制流的复杂程度定量度量程序的复杂程度,这样度量出的结果称为程序的环形复杂度。
Halstead 方法: 是一个著名的方法,它根据程序中运算符和操作数的总数来度量程序的复杂程度。
第七章、实现
通常把编码和测试统称为实现。
7.1 编码
源程序代码的逻辑简明清晰,易读易懂是好程序的一个重要标准。
7.5 测试步骤
大型软件系统的测试过程基本上由下述几个步骤组成:
- 模块测试 :模块测试的目的是保证每个模块作为一个单元能正确运行,所以模块测试通常又称为单元测试。
- 子系统测试: 子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。 模块相互间的协调和通信是这个测试过程中的主要问题,因此,这个步骤着重测试模块的接口。
- 系统测试: 是把经过测试的子系统装配成一个完整的系统来测试。
- 验收测试: 把软件系统作为单一的实体进行测试,测试内容与系统测试基本类似,但是它是用户积极参与下进行的,而且可能主要使用实际数据进行测试。验收测试的目的是验证系统确实能够满足用户的需要,在这个测试步骤中发现的往往是系统需求说明书的错误。验收测试也称为确认测试。
- 平行运行: 就是同时运行新开发出来的系统和将被它取代的旧系统,以便比较新旧两个系统的处理结果。
7.6 测试准则
软件测试的准则:
1)所有测试都应该能追溯到用户需求。
2)应该远在测试开始之前就制定出测试计划。
3)把 Pareto 原理应用到软件测试中。
4)应该从“小规模”测试开始,并逐步进行“大规模”测试。
5)穷举测试是不可能的。
6)为了达到最佳的测试效果,应该由独立的第三方从事测试工作。
7.7 其他
单元测试集中检测软件设计的最小单元—— 模块 。
可以应用人工测试 和计算机测试 这样两种不同类型的测试方法,完成单元测试工作。
通常,单元测试主要使用 白盒测试技术 ,而且对多个模块的测试可以并行地进行。
在单元测试期间着重从下述 5 个方面对模块进行测试:
1)模块接口 2)局部数据结构 3)重要的执行通路 4)出错处理通路 5)边界条件
集成测试: 是测试和组装软件的系统化技术 ,主要目标是发现与接口有关的问题。
由模块组装成程序时有两种方法:
1)非渐增式测试方法: 先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序。
2)渐增式测试: 把下一个要测试的模块同已经测试好的那些模块结合起来进行测试, 测试完以后再把下一个应该测试的模块结合进来测试。
当使用渐增方式把模块结合到程序中去时 ,有自顶向下和自底向上两种集成策略。
回归测试: 是指重新执行已经做过的测试的某个子集,以保证上述这些变化没有带来非预期的副作用。
回归测试就是用于保证由于调试或其他原因引起的变化,不会导致非预期的软件行为或额外错误的测试活动。
确认测试也称为验收测试,它的目标是验证软件的有效性。
通常, 验证指的是保证软件正确地实现了某个特定要求的一系列活动,而确认指的是为了保证软件确实满足了用户需求而进行的一系列活动。
软件有效性的一个简单定义是: 如果软件的功能和性能如同用户所合理期待的那样,软件就是有效的。
需求分析阶段产生的软件需求规格说明书 ,准确地描述了用户对软件的合理期望,因此是软件有效性的标准,也是进行确认测试的基础。
确认测试通常使用黑盒测试法。
复查的目的是: 保证软件配置的所有成分都齐全,质量符合要求,文档与程序完全一致,具有完成软件维护所必须的细节,而且已经编好目录。
测试用例 :把测试数据和预期的输出结果称为测试用例。
一般说来,有下列 3 种调试途径可以采用: 1.蛮干法 2.回溯法 3.原因排除法
第十三章、软件项目管理
13.1 估算软件规模
13.1.1 代码行技术(LOC)
13.1.2 功能点技术(FP)
- 输入项数: 用户向软件输入的项数,这些输入给软件提供面向应用的数据。
- 输出项数: 软件向用户输出的项数,它们向用户提供面向应用的信息,
- 查询数: 查询即是一次联机输入,它导致软件以联机输出方式产生某种即时响应。
- 主文件数:逻辑主文件(即数据的一个逻辑组合,它可能是大型数据库的一部分或是一个独立的文件)的数目。
- 外部接口数:机器可读的全部接口(例如,磁盘或磁带上的数据文件)的数量,用这些接口把信息传送给另一个系统。
13.2 估算工作量
根据软件规模可以估算出完成该项目所需的工作量, 常用的估算模型为静态单变量模型、 动态多变量模型和 COCOMO2模型。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!