, 软件资格与水平考试 软件设计师 软件工程基础 讲义 www.ccidedu.com 1 课程概述 3 - 1.1 软件设计师级考试大纲分析 3 - 1.1.1 考试要求 3 - 1.1.2 考试科目设置 3 - 1.1.3 考试范围 3 - 1.2 软件设计师级试卷分析 5 - 2 软件工程基础知识 5 - 2.1 软件工程概述 5 - 2.1.1 软件生存周期 6 - 2.1.2 软件开发模型 7 - 2.2 软件需求分析 9 - 2.2.1 需求分析的任务 10 - 2.2.2 软件需求分析方法 10 - 2.3 软件开发项目管理 10 - 2.3.1 项目管理--成本估算 10 - 2.3.2 项目管理--风险分析 11 - 2.3.3 风险分析--风险评估.11 - 2.3.4 项目管理--进度管理 11 - 2.3.5 项目管理--人员管理 13 - 2.4 软件工具与软件开发环境 13 - 2.4.1 软件工具 13 - 2.4.2 软件开发环境 14 - 2.5 软件过程能力评估与质量保证 15 - 2.5.1 软件过程评估的意义 15 - 2.5.2 软件能力成熟度模型简介.16 - 2.5.3 软件质量管理与质量保证.17 - 3 系统分析基础知识 19 - 3.1 系统分析概述 19 - 3.2 结构化分析方法 20 - 3.2.1 基本概念 20 - 3.2.2 结构化分析方法--数据流图.20 - 3.2.3 结构化分析方法--数据词典.21 - 3.2.4 结构化分析方法--实体关系图.22 - 3.2.5 结构化分析方法--描述加工的结构化语言.24 - 3.3 系统分析报告 24 - 4 系统设计知识 25 - 4.1 系统设计概述 25 - 4.2 系统设计的内容 25 - 4.3 系统设计的步骤 25 - 4.4 系统设计的原则 25 - - 1 - 4.4.1 抽象 26 - 4.4.2 模块化 26 - 4.4.3 信息隐蔽 26 - 4.4.4 模块独立 26 - 4.5 结构化设计方法 27 - 4.5.1 基本概念 27 - 4.5.2 信息流的类型 27 - 4.6 系统总体结构设计 30 - 4.6.1 系统结构设计原则 30 - 4.6.2 子系统划分 30 - 4.6.3 系统模块结构设计 31 - 4.7 面向数据结构的设计方法 33 - 4.7.1 Jackson图.33 - 4.7.2 Jackson方法的设计步骤.34 - 4.8 系统详细设计 34 - 4.8.1 代码设计 34 - 4.8.2 输出设计 35 - 4.8.3 输入设计 35 - 4.8.4 处理过程设计 35 - 4.8.5 用户界面设计 36 - 4.8.6 安全控制设计 37 - 4.8.7 系统设计说明书 38 - 5 系统测试知识 38 - 5.1 基本原则 39 - 5.2 测试过程 39 - 5.3 测试策略和测试方法 39 - 5.3.1 人工测试 40 - 5.3.2 机器测试 40 - 5.4 软件测试步骤 41 - 5.4.1 单元测试 41 - 5.4.2 组装测试 42 - 5.4.3 确认测试 42 - 5.4.4 系统测试 43 - 6 系统文档 43 - 6.1 信息系统文档介绍 43 - 6.2 文档在角色间的共享 43 - 7 系统实施知识 44 - 7.1 系统实施概述 44 - 8 系统运行和维护知识 45 - 8.1 系统维护概述 45 - 8.2 维护与软件文档 45 - 8.3 系统维护的内容及类型 45 - 8.4 软件维护 46 - - 2 - 1 课程概述 1.1 软件设计师级考试大纲分析 1.1.1 考试要求 熟悉软件工程、软件过程改进和软件开发项目管理的基础知识 熟悉掌握软件设计的方法和技术 1.1.2 考试科目设置 <均包含软件工程知识> 计算机与软件工程知识:考试时间为 150 分钟,笔试 软件设计: 考试时间为 150 分钟,笔试 1.1.3 考试范围 计算机与软件工程知识 --系统开发与运行知识部分 软件设计 --软件工程部分 (1)软件开发与运行知识 ? 软件工程、软件过程改进和软件开发项目管理知识 ? 系统分析基础知识 ? 系统设计知识 ? 系统实施知识 ? 系统运行和维护知识 ? 面向对象开发方法 ? 软件工程、软件过程改进和软件开发项目管理知识 · 软件工程知识(软件危机(2002)) · 软件开发生命周期各阶段的目标和任务(2003,2004) · 软件开发项目管理基础知识 (时间管理、 成本管理、 质量管理、 人力资源管理、 风险管理(2004) 等)及其常用管理工具 · 软件开发模型(2001)(瀑布模型(2004) 、演化模型 (2001,2002) 、喷泉模型(2001)、螺旋模 - 3 - 型(2003) ) ? 系统分析基础知识 ·系统分析的目的和任务(2004) ·结构化分析方法(2004)(数据流图(DFD) (2003,2004) 、数据字典(DD) 、实体关系图 (ERD) 、描述加工处理的结构化语言(2002,2004)) · 统一建模语言(UML)(2004) · 系统规格说明书 ? 系统设计知识 · 系统设计的目的和任务 · 系统设计的原则(2003) · 结构化设计方法和工具(系统流程图、HIPO 图、控制流程图) · 系统总体结构设计(2002)(总体布局、设计原则、模块结构设计、数据存储设计、系统 配置方案) · 系统详细设计(代码设计、数据库设计、用户界面设计、处理过程设计) · 系统设计说明书 ? 系统实施知识 · 系统实施的主要任务 · 结构化程序设计、面向对象程序设计、可视化程序设计 · 程序设计风格 · 程序设计语言的选择 · 系统测试的目的、类型,系统测试方法(黑盒测试、白盒测试、灰盒测试) (2002,2004) · 测试设计和管理(错误曲线、错误排除、收敛、注入故障、测试用例设计、系统测试报 告) · 系统转换基础知识 ? 系统运行和维护知识 · 系统运行管理基础知识 · 系统维护基础知识 · 系统评价基础知识 ? 面向对象开发方法 · 面向对象开发概念(2003)(2004,2) (类(2003) 、对象(2003) 、属性、封装性、继承性、 多态性(2002)、对象之间的引用) · 面向对象开发方法的优越性以及有效领域(2004) · 面向对象设计方法(体系结构、类的设计、用户接口设计) · 面向对象实现方法(选择程序设计语言、类的实现、方法的实现、用户接口的实现、准 备测试数据) · 面向对象程序设计语言(如C++、Java、Visual、Bsasic、Visual C++)的基本机制 · 面向对象数据库、分布式对象的概念 (2)软件设计--软件工程 · 软件生存期模型(瀑布模型、螺旋模型、喷泉模型)和软件成本模型 · 定义软件需求(系统化的目标、配置、功能、性能和约束) · 描述软件需求的方法(功能层次模型、数据流模型、控制流模型、面向数据的模型、面向对 象的模型等) - 4 - · 定义软件需求的方法(结构化分析方法(2004) 、面向对象分析方法) · 软件设计(分析与集成、逐步求精、抽象、信息隐蔽) · 软件设计方法(结构化设计方法、Jackson 方法、Warnier 方法、面向对象设计方法) · 程序设计 (结构化程序设计 (程序流程图(2001,2) (2002,3) (2003) ) 、 面向对象程序设计(2003 ) (2004,2) ) · 软件测试的原则与方法 · 软件质量(软件质量特性、软件质量控制) · 软件过程评估基本方法、软件能力成熟度评估基本方法 · 软件开发环境和开发工具(分析工具、设计工具、编程工具、测试工具、维护工具、CASE) · 软件工程发展趋势(面向构件,统一建模语言(UML)(2004)) ·软件过程改进模型和方法 1.2 软件设计师级试卷分析 考试科目 计算机与软件工程知识 软件设计 题型分析 选择题 问答题 比重分析 软件工程占 25% 软件工程占 30%-40% 考试要求 基本概念、基础知识 综合应用的能力 知识点分布 结构化与面向对象知识各占一 半DFD 图、UML 图、ER 图、流程 图的应用技术 出题趋势分析 不超大纲,趋重细节 结构化与面向对象知识综合应 用,基础知识的掌握 2 软件工程基础知识 2.1 软件工程概述 ? 1968 年首次提出了"软件工程"这个名词,希望用工程化的原则和方法来克服软件危机. ? 研究内容: 软件开发模型 开发方法 工具 环境 ? 知识要点 - 5 - 软件生存周期 软件开发模型 2.1.1 软件生存周期 ? 软件生存过程:孕育、诞生、成长、成熟、衰亡. --这个过程即为计算机软件的生存周期. ? 软件生存周期包括 6 个阶段: ? 制定计划 ? 需求分析 ? 软件设计 ? 程序编制 ? 软件测试 ? 运行维护 (1)制定计划 ? 步骤 S1 确定要开发软件系统的总目标 S2 给出功能、性能、可靠性以及接口等方面的要求 S3 完成该软件任务的可行性研究 S4 估计可利用的资源(计算机硬件,软件,人力等)、成本、效益、开发进度 S5 制定出完成开发任务的实施计划,连同可行性研究报告,提交管理部门审查 (2)需求分析 ? 步骤 S1 对待开发软件提出的需求进行分析并给出详细的定义 S2 编写软件需求说明书或系统功能说明书及初步的系统用户手册 S3 提交管理机构评审 (3)软件设计 ? 步骤 S1 概要设计 — 把各项需求转换成软件的体系结构. 结构中每一组成部分都是意义明确的模块, 每 个模块都和某些需求相对应 S2 详细设计 — 对每个模块要完成的工作进行具体的描述,为源程序编写打下基础 S3 编写设计说明书,提交评审 (4)程序编制 ? 把软件设计转换成计算机可以接受的程序代码,即写成以某一种特定程序设计语言表示的 "源程序清单" ,即编码. (5)软件测试 ? 按规定的各项需求,逐项进行有效性测试,决定已开发的软件是否合格,能否交付用户使用 (6)运行维护 ? 改正性维护: 运行中发现了软件中的错误需要修正 ? 适应性维护: 为了适应变化了的软件工作环境,需做适当变更 ? 完善性维护: 为了增强软件的功能需做变更 - 6 - 2.1.2 软件开发模型 ? 软件开发模型直观地表达软件开发全部过程,明确规定要完成的主要活动和任务 ? 瀑布模型 ? 演化模型 ? 螺旋模型 ? 喷泉模型 (1)瀑布模型 特点: ? 从上一阶段接受本阶段工作的对象作为输入 ? 本阶段的工作成果作为输出传入下一阶段 ? 评估各阶段,若本阶段工作得到确认,继续,否则返回前一阶段 ? 可以增加反馈线来表示具有反馈回路的瀑布模型 (2)演化模型 - 7 - 特点: ? 在项目开发的初始阶段用户只能给出系统的核心,并根据实现的核心系统有效地提 出反馈,来支持系统的最终设计和实现. (3)螺旋模型 - 8 - 特点: 沿着螺线旋转,在四个象限上分别表达了四个方面的活动: ? 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件 ? 风险分析:分析所选方案,考虑如何识别和消除风险 ? 实施工程:实施软件开发 ? 客户评估评价开发工作,提出修正建议 (4)喷泉模型 特点: ? 迭代 ? 重复 ? 演进 ? 无间隙 ? 各阶段间无明显界限 2.2 软件需求分析 借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的 "做什么" 的问题. - 9 - 2.2.1 需求分析的任务 1.确定对系统的综合要求 系统功能要求、性能要求、运行要求、将来可能提出来的要求 2.分析系统的数据要求(建模) 3.导出系统的逻辑模型(数据流图、数据字典、IPO 图) 4.修正项目开发计划 5.开发原型系统 2.2.2 软件需求分析方法 ? 需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成 ? 它定义了表示系统逻辑视图和物理视图的方式 2.3 软件开发项目管理 ? 开始于技术工作开始之前,终止于软件工程过程结束 ? 成本估算 ? 风险分析 ? 进度管理 2.3.1 项目管理--成本估算 ? 方法1 ? 先估计完成软件项目所需的工作量(人月数) ,然后根据每个人月的代价(金额)计 算软件的开发费用: 开发费用 = 人月数 * 每个人月的代价 ? 方法2 ? 先估计软件的规模(源代码行数) ,然后根据每行源代码的平均开发费用(分析、设计、编码、测试所花的费用) ,计算软件的开发费用: 开发费用 = 源代码行数 * 每行平均费用 ? 估算源代码行数的方法: ? 请n位有经验的专家,每位专家对软件给出三个估计值: 最少源代码行数 最大代码行数 最可能的代码行数 ∑ = n i i E n 1 1 代码行数=n 位专家的估算期望值的平均值= 6 4 i i i i b m a E + + = 其中 Ei 为每位专家的估算期望值 - 10 - 2.3.2 项目管理--风险分析 (1)风险分析--风险识别 ? 风险识别:试图系统化地确定对项目计划(估算、进度、资源分配)的威胁 ? 风险识别方法:建立风险条目检查表,用来识别某些常见的已知的及可预测的风险,如:?产品规模 ? 商业影响 ? 客户特性 ? 开发环境 ? …… (2)风险分析--风险预测 ? 风险预测又称风险估算,从两方面评估一个风险: ? 风险发生的可能性或概率 ? 如果风险发生,所产生的后果 ? 4 种风险预测活动: ? 建立一个尺度或标准,以反映风险发生的可能 ? 描述风险的后果 ? 估计风险对项目和产品的影响 ? 标注风险预测的整体精确度,以免产生误解. 2.3.3 风险分析--风险评估 ? 风险评估步骤 ? 定义项目的风险参考水平值(成本、进度和性能 ) ; ? 建立每一组 与每一个参考水平值之间的关系; ( ) i i i x l r , , ri 表示风险,li 表示风险发生的概率,xi 表示风险产生的影响 ? 预测一组临界点以定义项目终止区域,该区域由一条曲线或不确定区域所界定; ? 预测什么样的风险组合会影响参考水平值. (4)风险分析--风险控制 ? 辅助项目组建立处理风险的策略 ? 风险控制需考虑三个问题: ? 风险避免 ? 风险监控 ? 风险管理及意外事件计划 2.3.4 项目管理--进度管理 ? 两种方式: 系统最终交付日期已经确定,软件开发部门必须在规定期限内完成; 系统最终交付日期只确定了大致的年限,最后交付日期由软件开发部门确定. ? 两种图形描述: Gantt 图-11 - PERT 图(1)进度管理图形描述--Gantt 图 优点:清晰地描述每个任务从何时开始,到何时结束以及各个任务之间的并行性. 缺点:不能清晰地反映出各任务之间的依赖关系,难以确定整个项目的关键所在,也不能反映计划 中有潜力的部分. (2)进度管理图形描述-- PERT 图 进度管理图形描述-- PERT 图-12 - 优点:清晰地反映出每个任务的开始时间、结束时间,还给出了任务之间的关系,即哪些任务完成 后才能开始另有一些任务,以及如期完成整个工程的关键路径.1,2,3,4,6,8,10,11,空任务. 缺点:不能反映任务之间的并行关系. 2.3.5 项目管理--人员管理 ? 按软件项目对软件人员分组: ? 需求分析组 ? 程序设计组 主程序员组、无主程序员组、层次式程序员组 ? 编码组 ? 测试组 ? 维护组 ? 质量保证组 2.4 软件工具与软件开发环境 ? 软件工具: ? 也称为 CASE 工具(计算机辅助软件工程,Computer Aided Software Engineering), 用来辅助软件开发、运行、维护、管理、支持等. ? 软件开发环境: ? 支持软件产品开发的软件系统,由软件工具集和环境集成机制构成. 2.4.1 软件工具 (1)软件工具--开发工具 ? 需求分析工具: ? 用以辅助软件需求分析活动,分为基于自然语言或图形描述的工具和基于形式化需 - 13 - 求定义语言的工具. ? 维护工具 ? 用以辅助软件设计活动,分为概要设计工具和详细设计工具 ? 编码与排错工具 ? 辅助程序员进行编码活动,分为有编码工具和排错工具 (2)软件工具--维护工具 ? 定义 用来辅助维护人员对软件代码及其文档进行各种维护活动. ? 分类 ? 版本控制工具:存储、更新、恢复和管理软件的版本 ? 文档分析工具:对软件开发过程中形成的文档进行分析,给出软件维护活动所需的 维护信息 ? 开发信息库工具:维护软件项目的开发信息,包括对象、模块等 ? 逆向工程工具:将形式表示的软件(源程序)转换成更高抽象形式表示的软件 ? 再工程工具:支持重构一个功能和性能更为完善的软件系统 (3)软件工具--软件管理和软件支持工具 ? 定义 用来辅助管理人员和软件支持人员的管理活动和支持活动,以确保软件高质量的完成. ? 分类 ? 项目管理工具:辅助软件的项目管理活动,包括项目的计划、调度、成本估算、及 质量控制等. ? 配置管理工具:辅助完成软件配置项的标识、版本控制、变化控制等. ? 软件评价工具:辅助管理人员进行软件质量保证的有关活动,确保软件的质量. (4)软件开发工具的评价和选择 ? 衡量软件开发工具的标准 ? 功能 ? 易用性 ? 稳健性 ? 硬件要求和性能 ? 服务和支持 2.4.2 软件开发环境 (1)软件开发环境的定义 ? 定义:支持软件产品开发的软件系统,由软件工具集和环境集成机制组成. ? 软件工具集: 支持软件开发的相关过程、活动和任务. ? 环境集成机制: 为工具集成和软件开发、维护和管理提供统一的支持,它通常包括数据集成、控制集成和界 面集成. 通过环境集成机制,各工具用统一的数据接口规范存储或访问环境信息库;各工具采用统一 的界面形式,保证各工具界面的一致性,同时为各工具或开发活动之间的通信、切换、调度和协同 工作提供支持. (2)软件开发环境的特征 - 14 - ? 环境的服务是集成性的 软件开发环境应支持多种集成机制,如平台集成、数据集成、界面集成、控制集成和过程集 成等. ? 环境应支持小组工作方式,并为其提供配置管理 ? 环境的服务可用于支持各种软件开发活动,包括分析、设计、编程、测试、调试、文档等 2.5 软件过程能力评估与质量保证 基点:软件产品的质量取决于软件开发过程 1987 年提出软件过程能力成熟度模型 CMM,在其基础上形成了国际标准(ISO/IEC 15504) . 知识要点: 1、软件过程评估的意义 2、软件能力成熟度模型简介 2.5.1 软件过程评估的意义 ? 软件过程评估是软件改进和软件能力评价的前提环节 1.软件过程改进的需要 (1)软件过程不断改进是软件工程的基本原理之一 ? 软件工程七原理: 按软件生存周期分阶段指定计划并认真实施 逐阶段进行确认 坚持严格的产品控制 使用现代程序设计技术 明确责任 用人少而精 不断改进开发过程 (2)软件过程改进是软件生存周期的基本过程之一 ? 软件工程界始终十分重视对软件过程的研究.20 世纪 70 年代中期形成了软件生存 周期的概念,1995 年正式发布了一项国际标准,即ISO/IEC 12207 信息技术——软 件生存周期过程,这是软件过程研究的一个重要成果.这项标准科学地定义了软件 生存周期的过程,总共 17 个,其中一个就是改进过程. 2.降低软件风险的需要 (1)软件采购者的需要--评价他人 软件产品或软件服务的采购单位进行招标、选择承制者时,为了降低风险,需要对备选单位 的软件过程能力进行评价,而这种评价的依据是对该单位的软件过程的评估结果. (2)软件承制者的需要--自我评价 软件产品研制单位和软件服务单位在响应顾客的需要、进行投标时,为了降低风险,需要对 自己的软件过程能力进行评价, 避免承担力所不及的任务,而这种评价的依据仍然是根据实际需要, 对相应软件过程的评估结果. - 15 - 2.5.2 软件能力成熟度模型简介 ? 软件过程:人们用于开发和维护软件及其相关产品(例如,项目计划、设计文档、代码、测 试用例、用户手册等等)的一系列活动、包括软件工程活动和软件管理活动. ? 软件过程能力:描述(开发组织或项目组)通过遵循其软件过程能够实现预期结果的程度.一 个软件开发组织或项目组的软件过程能力提供一种预测该组织承担下一个软件项目时最可 能的预期结果的方法. ? 软件过程性能:表示(开发组织或项目组)遵循其软件过程所得到的实际结果. --软件过程性能描述已得到的实际结果,而软件过程能力则描述最可能的预期结果. ? 软件过程成熟度:一个特定软件过程被明确和有效地定义、管理、测量和控制的程度.成熟 度可指明一个软件开发组织软件过程能力的增长潜力.软件过程成熟度越高,开发组织的软 件过程规范化和具体化程度越好. ? 软件能力成熟度等级: 软件开发组织在走向成熟的途中几个具有明确定义的表征软件过程能 力成熟度的平台.每一个成熟度等级为过程继续改进达到下一个等级提供一个基础. ? 关键过程域:互相关联的若干软件实践活动和有关基础设施的一个集合.即对软件能力成熟 度等级至关重要的过程域,它们的实施对达到该成熟度等级的目标起保证作用. ? 关键实践:对关键过程域的实施起关键作用的方针、规程、措施、活动以及相关基础设施的 建立. --关键实践一般只描述"做什么",而不强制规定"如何做". --关键过程域的目标是通过其包含的关键实践的实施来达到的. --基本观点:整个软件过程的改进是基于许多小的、进化的步骤,而不是通过一次革命性的创 新来实现的.这些小的进化步骤就通过一些关键实践来实现. ? 软件能力成熟度模型: 对软件组织进化阶段的描述,随着软件组织定义、实施、测量、控制和改进其软件过程,软 件组织的能力经过这些阶段逐步前进. 软件组织软件过程能力的增长模式: S1 确定当前过程成熟度并识别软件过程执行中的薄弱环节; S2 确定软件质量和过程改进的关键问题从而形成过程改进策略; S3 通过实施一组有限的关键实践活动,改善其全组织的软件过程. - 16 - 2.5.3 软件质量管理与质量保证 2.5.3.1 软件质量定义 ? 软件质量 指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体. ? 软件质量保证 指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动,其 目的是生产高质量的软件. 2.5.3.2 软件质量特性 ? 描述软件质量特性的软件质量模型 ? ISO/IEC 9126 软件质量模型 ? Mc Call 软件质量模型 ? ISO/IEC 9126 软件质量模型 - 17 - 质量特性和质量子特性的含义 ? 功能性(Functionality) :与一组功能及其指定的性质的存在有关的一组属性.功能是指满足 规定或隐含需求的那些功能. ? 可靠性(reliability) :与在规定的一段时间内和和规定的条件下,软件维持在其性能水平有 关的能力. ? 易使用性(usability) :与为使用所需的努力和由一组规定或隐含的用户对这样使用所作的个 别评价有关的一组属性. ? 效率(efficiency) :在规定条件下,软件的性能水平与所用资源量之间的关系有关的软件属 性. ? 可维护性(maintainability) :与进行规定的修改所需要的努力有关的一组属性. ? 可移植性(portability) :与软件可从某一缓建转移到另一环境的能力有关的一组属性. 2.5.3.3 软件质量保证 ? 目的:生产高质量的软件 ? 任务: (1) 应用技术方法:把软件质量设计到软件产品或软件系统中去,而不是在事后再施加质量保证. (2) 技术评审:进行质量评估. (3) 测试软件:软件测试不会揭露所有的错误种类. (4) 标准的实施. (5) 控制变更:应用于软件开发及软件维护阶段. (6) 度量(metrics):包括技术上的和管理上. (7) 记录保存和报告. - 18 - 3 系统分析基础知识 3.1 系统分析概述 系统分析的目的和任务 ? 系统分析侧重于从业务全过程的角度进行分析. ? 内容: A、业务和数据的流程是否通畅,是否合理; B、数据、业务过程和组织管理之间的关系; C、原系统管理模式改革和新系统管理方法是否可行等. ? 任务:提交系统分析报告,即系统方案说明书 系统分析报告的内容 ? 开发者对于现有组织管理状况的了解 ? 信息系统的功能需求 ? 数据和业务流程 ? 管理功能和管理数据指标体系 ? 新系统拟改动和新增的管理模型等 系统分析的主要步骤 系统分析过程图的说明 ? 系统开发的目的: 现有系统的物理模型→目标系统的物理模型. ? 系统分析的结果:得到目标系统的逻辑模型. ? 逻辑模型与物理模型的区别 逻辑模型:反应系统的功能和性质; 物理模型:反映系统的具体实现方案. ? 系统分析的工作步骤: - 19 - S1 建立当前系统的逻辑模型; S2 分析现状,提出改进意见和新系统的目标; S3 建立新系统的逻辑模型; S4 编写系统方案说明书. 3.2 结构化分析方法 3.2.1 基本概念 结构化分析(Structured Analysis)方法:简称 SA 方法 是一种面向数据流的需求分析方法 适用于:分析大型数据处理系统 基本思想:自顶向下,逐层分解 分解和抽象是人们控制问题复杂性的两种基本手段. 分析结果的成分: A 一套分层的数据流图 B 一本数据词典 C 一组小说明(也称加工逻辑说明) D 补充材料 3.2.2 结构化分析方法--数据流图 定义 数据流图或称数据流程图(Data Flow Diagram,DFD)是一种便于用户理解、分析系统数据 流程的图形工具.它摆脱了系统的物理内容,精确地在逻辑上描述系统的功能、输入、输出和数据 存储等,是系统逻辑模型的重要组成部分. (1)DFD 的基本成分 (2)分层数据流图的画法 - 20 - 步骤 S1 画系统的输入和输出:系统与外部实体之间的数据流情况,称为顶层图. S2 画系统的内部:将顶层图的加工分解成若干个加工,并用数据流将这些加工连接起来,使得顶层 图中的输入数据经过若干个加工处理后变换成顶层图的输出数据流.这张图称为 0 层图. S3 画加工的内部:用画 0 层图同样的方法画出每个加工的 DFD 子图. S4 重复第③步,直至图中的尚未分解的加工都足够简单.至此得到分层数据流图. 有关说明: 加工的确定方法:数据流的组成或值发生变化的地方;也可根据系统的功能确定加工. 数据流的确定方法:当用户把若干个数据看作一个单位来处理(这些数据一起到达,一起加工)时, 可把这些数据看成一个数据流. 数据存储的确定方法:表示以后某个时间要使用的数据. 加工分解:从加工画数据流图的过程等价于该加工的分解过程. (3)对图和加工进行编号 ① 父图与子图 父图可以有多张子图(这些子图位于同一层) ,但每张子图只对应于一张父图. ② 编号 顶层图只有一张,图中的加工只有一个. 0 层图只有一张,图中的加工号可以分别是 0.1,0.2,…或者是 1,2,… 子图号就是父图中被分解的加工号. 字图中的加工号由图号、圆点和序号组成. 例如, 某图中的某加工号为 2.4, 这个加工分解出来的子图号就是 2.4, 子图中的加工号分别为 2.4.1, 2.4.2,… (4)画图规则之一 命名规则:数据流、加工、数据存储、外部实体的命名反映其实际含义. 不同名规则:一个加工的输出数据流与输入数据流不同名. 数据流设置规则:允许一个加工有多条数据流流向另一个加工,也允许一个加工有两个相同的输出 数据流流向两个不同的加工. 数据存储设置规则:若一个数据存储首次出现时只与一个加工有关,那么这个数据存储应作为这个 加工的内部文件而不必画出. 加工的数据流守恒:每个加工必须既有输入数据流,又有输出数据流. 数据存储的数据流守恒:在整套数据流图中,每个数据存储必须既有读的数据流,又有写的数据流. 但在某一张子图中可能只有读没有写,或者只有写没有读. 数据守恒:一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得,或者是通 过该加工能产生的数据. 父图与子图的层间平衡:父图中某加工的输入输出数据流必须与它的子图的输入输出数据流在数量 和名字上相同.值得注意的是,如果父图的一个输入(或输出)数据流对应于子图中几个输入(或 输出)数据流,而子图中组成这些数据流的数据项全体正好是父图中的这一个数据流,那么它们仍 然算是平衡的.在考务处理系统例子中(见后),即统计分析表与难度分析表、统计分析表的关系. 注意:画数据流而不要画控制流. 3.2.3 结构化分析方法--数据词典 数据流图与数据词典的区别 数据流图:描述了系统的分解,但没有对图中各成分进行说明. - 21 - 数据词典:为数据流图中的每个数据流、文件、加工、数据项做出说明.其中对加工的描述称 为"小说明",也可以称为"加工逻辑说明". 词典条目 ① 数据流条目. ② 文件条目. ③ 数据项条目. 词典管理 提供排序、查找、统计、数据词典与数据流图间的一致性检测等功能. 3.2.4 结构化分析方法--实体关系图 定义 (Entity Relationship Diagram,ERD)是描述现实世界概念结构模型的图形工具. 知识要点 A ERD 基本成分 B 实体联系的基本形式 C 联系属性 D ERD 基本思想 E ERD 实例 (1) ERD 基本成分 ? ERD 基本成分:实体型、属性和联系. ? 实体型:用矩形框表示,如图(a)所示. ? 属性:用椭圆形框表示,如图(b)所示. ? 联系:指实体之间的联系,用菱形框表示,有一对一(1:1) ,一对多(1:n)或多 对多(m :n)三种联系类型.例如系主任领导系,学生属于某一系,学生选修课程, 这里"领导"、"属于"、"选修" 表示实体间的联系,可以作为联系名称.如图(c)所示. (2)实体联系的基本形式 ? 实体联系的基本形式 ①两个实体之间的联系,如下图(a)所示. ②两个以上实体间的联系,如下图(b)所示. ③同一实体集内部各实体之间的联系,例如一个部门内的职工有领导与被领导的联系,即某一职工 (干部)领导若干名职工,而一个职工(普通员工)仅被另外一个职工直接领导,这就构成了实体 内部的一对多的联系.如下图(c)所示. - 22 - (3)联系属性 联系属性 联系本身也是实体型,所以联系也可以有属性. 如果一个联系具有属性,则这些联系也要用无向边与该联系连接起来. 例如,学生选修的课程有相应的成绩.这里的"成绩"既不是学生的属性,也不是课程的属性,只能 是学生选修课程的联系的属性,如上图(a)所示.上图(b)中"供应数量"也是"供应"联系的属性. (4)ERD 基本思想 ERD 的基本思想 分别用矩形框、椭圆形框和菱形框表示实体、属性和联系,使用无向边将属性与其相应的实 体连接起来,并将联系分别和有关实体相连接,注明联系类型. 上图为几个 ERD 的例子,只给出了实体及其 ERD,省略了实体的属性. 下图描述了学生与课程联系的完整 ERD. - 23 - 3.2.5 结构化分析方法--描述加工的结构化语言 ? 结构化语言(如结构化英语) :介于自然语言和形式化语言之间的半形式化语言,是自然语 言的一个受限子集. ? 结构化语言没有严格的语法,它的结构通常可分为内外二层. 外层有严格的语法,如结构化英语的外层可以是 if-then-else,for-do,while-do,set 等结 构 内层的语法比较灵活,可接近于自然语言的描述. 示例:"折旧策略"的加工逻辑可以用结构化英语描述如下: Depreciation policy If the Current-Capital-Value is less than $1000 Then: Set Depreciation-Amount to Current-Capital-Value Set Current-Capital-Value to zero Otherwise: Set Depreciated-Amount to 10% of Current-Capital-Value Reduce Current-Capital-Value by 10% 3.3 系统分析报告 定义 是系统分析阶段的工作成果. 系统分析报告的主体 数据流图、数据字典和加工说明. 系统分析报告的作用 ? 描述了目标系统的逻辑模型,作为开发人员进行系统设计和实施的基础. ? 作为用户和开发人员之间的协议或合同,为双方的交流和监督提供基础. ? 作为目标系统验收和评价的依据. 系统分析报告的内容 (1) 组织情况概述 (2) 现行系统概述 (3) 系统逻辑模型 (4) 新系统在各个业务处理缓解拟采用的管理方法、算法或模型 (5) 与新的系统相配套的管理制度和运行体制的建立 (6) 系统设计与实施的初步计划 (7) 用户领导审批意见. - 24 - 4 系统设计知识 4.1 系统设计概述 目的 为系统制定蓝图,勾画出新系统的详细设计方案 项目开发过程不能按总体设计划分阶段顺利推进的原因 (1)系统逻辑模型中用户需求定义既不确定,也不完善. A 开发人员缺少足够的专业知识. B 用户尚缺少足够的技术知识. (2)系统分析描述目的系统的逻辑模型不总能充分描述新系统功能. (3)由于各阶段的工作之间可能存在反复,因此生命周期法中阶段的严格划分很难保证质量. 4.2 系统设计的内容 内容 1 总体结构设计 2 代码设计 3 输出设计 4 输入设计 5 处理过程设计 6 数据存储设计 7 用户界面设计 8 安全控制设计 4.3 系统设计的步骤 步骤 (1) 总体结构设计(又称概要结构设计) 定义:把总任务分解为许多基本的、具体的任务,这些具体任务合理地组织起来构成总任务. 基本任务:将系统划分为模块,决定每个模块的功能,决定模块的调用关系,决定模块的界 面,即模块间信息的传递. (2) 详细设计 定义:为各个具体任务选择适当的技术手段和处理方法. 内容:代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计、安 全控制设计. 4.4 系统设计的原则 z 抽象 - 25 - 软件工程中从软件定义到软件开发要经历多个阶段.在这个过程中每前进一步都可看作是对软 件解法的抽象层次的一次细化. z 模块化 z 信息隐蔽 z 模块独立 4.4.1 抽象 ? 定义 抽象是一种复杂现象进行简化的设计技术,重点说明一个实体的本质方面,而忽略或者掩盖不 很重要或非本质的方面. ? 抽象层次 在进行模块化设计时也可以有多个抽象层次,最高抽象层次的模块用概括的方式叙述问题的解 法,较低抽象层次的模块是对较高抽象层次模块对问题解法描述的细化,最低抽象层次就是实现该 软件的源程序代码. 4.4.2 模块化 定义 指将一个待开发的软件分解成若干个小的简单部分——模块,每个模块可独立地开发、测试, 最后组装成完整的程序. 特点 一种复杂问题的"分而治之"的原则. 目的 使程序的结构清晰,容易阅读、理解、测试、修改. 4.4.3 信息隐蔽 定义 用于开发整体程序结构,将每个程序的成分隐蔽或封装在一个单一的设计模块中,定义每一个 模块时尽可能少地显露其内部的处理. 作用 提高软件的可修改性、可测试性和可移植性. 4.4.4 模块独立 定义 指每个模块完成一个相对独立的特定子功能,并且与其他模块之间的联系简单. 模块独立程度的衡量标准:耦合与内聚 耦合:指模块之间联系的紧密程度.耦合度越高则模块的独立性越差. 内聚:指模块内部各元素之间联系的紧密程度.完成多个功能的模块的内聚度比完成单一功能 的模块的内聚度低.内聚度越低则模块的独立性越差. - 26 - 模块独立希望每个模块都是低耦合、高内聚. 4.5 结构化设计方法 4.5.1 基本概念 结构化设计(structured design,SD) 特点: SD 方法是一种面向数据流的设计方法,它可以与 SA 方法衔接. 基本思想 将系统设计成由相对独立、功能单一的模块组成的结构. 4.5.2 信息流的类型 在需求分析阶段,面向数据流的 SA 方法产生数据流图 DFD. 在系统设计阶段,面向数据流的 SD 方法将 DFD 转换成程序结构图. 信息流的定义 DFD 中从系统的输入数据流到系统的输出数据流的一连串连续变换. DFD 信息流的分类: 变换流与事务流. (1)变换流 工作原理 信息沿着输入通路进入系统,同时将信息的外部形式转换成内部表示,然后通过变换中心(也 称主加工)处理,再沿着输出通路转换成外部形式离开系统.具有这种特性的信息流称为变换流. 组成 变换流型 DFD 可以分成: 输入+变换(主加工)+输出 (2)事务流 工作原理 信息沿着输入通路到达一个事务中心,事务中心根据输入信息(即事务)的类型在若干个动作 序列(称为活动流)中选择一个来执行,这种信息流称为事务流. 特征 事务流有明显的事务中心,各活动流以事务中心为起点呈辐射状流出. (3) 、变换分析 变换分析是从变换流型的 DFD 导出程序结构图 步骤 S1 确定输入流和输出流,孤立出变换中心; S2 第一级分解:设计模块结构的顶层和第一层; S3 第二级分解:设计中、下层模块. 第一步 S1 确定输入流和输出流,孤立出变换中心 - 27 - 第二步 S2 第一级分解:设计模块结构的顶层和第一层 ? 变换流型 DFD 可映射成下图所示的程序结构图; ? 顶层模块:其功能就是整个系统的功能; ? 输入控制模块:接收所有的输入数据; ? 变换控制模块:实现输入到输出的变换; ? 输出控制模块:产生所有的输出数据. 顶层模块 输入控制 输出控制 变换控制 变换分析的第一级分解 第三步 S3 第二级分解:设计中、下层模块. ① 输入控制模块的分解:从变换中心的边界开始,沿着每条输入通路,把输入通路上的每个加工映 射成输入控制模块的一个低层模块. ② 输出控制模块的分解:从变换中心的边界开始,沿着每条输出通路,把输出通路上的每个加工映 射成输出控制模块的一个低层模块. ③ 变换控制模块的分解:变换控制模块通常没有通用的分解方法,应根据 DFD 中变换部分的实际 情况进行设计. (4)事务分析 事务分析是从事务流型 DFD 导出程序结构图. 步骤: S1 确定事务中心和每条活动流的流特性 S2 将事务流型 DFD 映射成高层的程序结构 S3 进一步分解 第一步 S1 确定事务中心和每条活动流的流特性 右图为事务流型 DFD 的一般形式. - 28 - 事务中心(图中的 T) : 位于活动流的起点, 活动流从该点成辐射状流出. 活动流:是信息流, 可以是变换流 也可以是另一条事务流. 事务流型的 DFD 的组成: 输入流+事务中心+若干条活动流 第二步 S2 将事务流型 DFD 映射成高层程序结构 右图为事务流型 DFD 的高层结构形式. 顶层模块:其功能就是整个系统的功能. 接收模块:接收输入数据,对应输入流. 发送模块:调度模块, 控制下层的所有活动模块. 活动流模块:对应活动流, 是该活动流映射成的 程序结构图中的顶层模块. 顶层模块 发送 接收 活动流1 活动流2 活动流n … 事务流型DFD的高层程序结构 - 29 - 第三步 S3 进一步分解 接收模块:类同于变换分析中输入控制模块的分解. 活动流模块:根据其流特性(变换流或事务流)进一步采用变换分析或事务分析进行分解. 4.6 系统总体结构设计 定义: 根据系统分析的要求和组织的实际情况,对新系统的总体结构形式和可利用的资源进行大致 设计,这是一种宏观、总体上的设计和规划. 系统总体设计的主要内容: 1 系统结构设计原则 2 子系统划分 3 系统模块结构设计 4 数据存储设计 4.6.1 系统结构设计原则 ① 分解——协调原则 ② 自顶向下的原则 ③ 信息隐蔽、抽象的原则 ④ 一致性原则 ⑤ 明确性原则 ⑥ 模块之间的耦合尽可能小,模块内部组合要尽可能紧凑. ⑦ 模块的扇入系数和扇出系数要合理. ⑧ 模块的规模适当. 有关说明: ? 模块的扇出系数:模块直接调用其他模块的个数. ? 模块的扇入系数:模块被其他模块调用时,直接调用的它的模块个数. ? 模块的扇入、扇出系数设置: ? 好的系统的平均扇入、扇出系统通常是 3 或4,一般不应超过 7. ? 菜单调用型模块扇入与扇出系统、公用模块扇入系统可以大一些. ? 模块的规模设置 ? 过大的模块:使系统分解得不充分. ? 过小的模块:降低模块的独立性,造成系统接口的复杂性. ? 最好的模块规模:程序系数限制在 1~2 页纸内. 4.6.2 子系统划分 划分原则 - 30 - ? 子系统要具有相对独立性 ? 子系统之间数据的依赖性尽量小 ? 子系统划分的结果应使数据冗余较小 ? 子系统的设置应考虑今后管理发展的需要 ? 子系统的划分应便于系统分阶段实现 ? 子系统的划分应考虑到各类资源的充分利用 子系统结构设计 ? 子系统结构设计的任务: ? 确定划分后的子系统模块结构,并画出模块结构图. ? 子系统结构设计考虑以下几个问题: ? 每个子系统如何划分成多个模块. ? 如何确定子系统之间、模块之间传送的数据及其调用关系. ? 如何评价并改进模块结构的质量. ? 如何从数据流图导出模块结构图. 4.6.3 系统模块结构设计 1、模块的概念 定义:组成系统的基本单位,系统中任何一个处理功能都可以及看成是一个模块. 特点:可以组合、分解和更换. 分类标准:根据模块功能具体化程度划分 分类:逻辑模块和物理模块 ? 逻辑模块:在系统逻辑模型中定义的处理功能. ? 物理模块:即逻辑模块的具体化,可以是一个计算机程序、子程序或若干条程序语 句,也可以是人工过程的某项具体工作. 模块的四要素: ? 输入和输出:模块的输入来源和输出去向都是同一个调用者,即一个模块从调用者 那里取得输入,进行加工后再把输出返回给调用者. ? 处理功能:指模块把输入转换成输出所作的工作. ? 内部数据:指仅供该模块本身引用的数据. ? 程序代码:指用来实现模块功能的程序. 模块特性 外部特性:反映了模块的外貌,即前两个要素,结构化设计考虑外部特性. 内部特性:即后两个要素,其具体实现在系统实施阶段完成. 2、模块结构图 模块结构图基本概念 ? 定义:是结构化设计中描述系统结构的图形工具.须定义模块的名字、功能和接口. ? 特点:关心模块的外部属性,即上下级模块、同级模块之间的数据传递和调用关系, 并不关心模块的内部. 知识要点: ? 结构设计原则 ? 模块结构图的基本符号 (1)结构设计原则 - 31 - 结构设计原则 ? 模块的独立性:所划分的模块其内部的凝聚性要强,模块之间的联系要少,即. ? 模块连接:模块之间的连接只能存在上下级之间的调用关系,不能有同级之间的横 向联系. ? 系统结构:整个系统呈树状结构,不允许网状结构或交叉调用关系出现. ? 模块(包括后继 IPO 图)的分类编码并归档. (2)模块结构图的基本符号 模块结构图基本符号 模块 调用 数据 控制 转接 ? 模块: 指用一个名字就可以调用的一段程序语句,用长方形表示. ? 调用: 箭头总是由调用模块指向被调用模块,但是应该理解被调用模块执行后又返回到调用模块. ? 特点:箭头由调用模块指向被调用模块,被调用模块执行后又返回到调用模块. ? 判断调用:通过判断条件决定是否调用一个从属模块,用菱形符号表示. ? 循环调用:通过循环功能循环调用一个或多个从属模块,用弧形箭头表示. 数据: 模块之间传送的数据用带空心圆的箭头表示,并在旁边标上数据名.下图(a)表示模块 A 调用 模块 B 时,A 将数据 x、y 传送给 B,B 将处理结果数据 z 返回给 A. 控制信息: 控制信息与数据的主要区别是前者只反映数据的某种状态,勿需处理.图15(b)中"无此职工" 就是用来表示送来的职工号有误的控制信息. - 32 - 转接符号 当模块结构图在一张纸上画不下,需要转接到另一张纸上,或者为了避免图上线条交叉时, 都可以使用转接符号,圆圈内加上标号,如下图所示. 4.7 面向数据结构的设计方法 定义: 面向数据结构的设计方法以数据结构作为设计的基础,它根据输入/输出数据结构导出程序的结 构. 适用:规模不大的数据处理系统. Jackson 方法是一种典型的面向数据结构的设计方法. 知识要点: 1 Jackson 图2Jackson 方法的设计步骤 4.7.1 Jackson 图 数据元素间逻辑关系分类:顺序、选择、重复. 表示数据结构 顺序:A 由B、C、D 三个成分顺序组成,其次序是从左到右; 选择:A 是B或C或D中的一个; 重复:A 由B重复出现多次(可以是 0 次)组成. 表示程序结构 方框表示模块,关系表示顺序、分支、重复. - 33 - 4.7.2 Jackson 方法的设计步骤 S1 分析并确定输入和输出数据的逻辑结构,并用 Jackson 图表示. S2 找出输入数据结构与输出数据结构间有对应关系的数据单元. 所谓有对应关系的数据单元是指有直接因果关系,在程序中可以同时处理的数据单元.对于 重复结构的数据单元,必须在重复次数和次序都相同时才有对应关系. S3 用下述的三条规则从描述数据结构的 Jackson 图导出描述程序结构的 Jackson 图. ? 为每对有对应关系的数据单元,按照它们在数据结构图中的层次在程序结构图的相 应层次画一个处理框.如果这对有对应关系的数据单元在输入数据结构图中所处的 层次与输出数据结构图中所处的层次不同,则取它们中较低的层次作为处理框在程 序结构图中的层次. ? 为输入数据结构图中剩余的每个数据单元,在程序结构图的相应层次上画一对应的 处理框. ? 为输出数据结构图中剩余的每个数据单元, 在程序结构图的相应层次上画一处理框. S4 列出所有的操作,并把它们分配到程序结构图的适当位置上. S5 用伪码表示程序. 4.8 系统详细设计 4.8.1 代码设计 设计原则 ? 唯一性:如职工编号、学生的学号等. ? 合理性:代码结构与响应的分类体系相对应. ? 可扩充性 ? 简单性 ? 适用性 ? 规范性.遵循国家有关编码标准.在一个代码体系中,代码结构、类型、编写格式 必须统一. ? 系统性:有一定的分组规则,如一级标准分类,二级标准分类等. 设计步骤 S1 确定代码对象; S2 考察已有标准代码; - 34 - S3 选择代码的种类与类型; S4 考虑检错功能; S5 编写代码表. 4.8.2 输出设计 从系统开发的角度看,输出决定输入,即输入信息只有根据输出要求才能确定. 输出设计内容: ? 确定输出内容 ? 选择输出设备与介质 ? 确定输出格式 输出方式: ? 报表输出:给出详细的记录数据,适于基层和具体事务的管理者, ? 图形输出:显示综合数据或发展趋势等信息,适于高层领导或宏观、综合管理部门 4.8.3 输入设计 目的:保证向系统输入正确的数据. 原则 ? 最小量原则 ? 简单性原则 ? 早检验原则 ? 少转换原则 内容 ? 确定输入内容 ? 输入方式设计 ? 输入格式设计 ? 校对方式设计 其中,校对方式分类: A 人工校对 B 二次键入校对(同一批数据两次键入) C 数据平衡校对 4.8.4 处理过程设计 总体结构设计:将系统分解成许多模块,并决定了每个模块的外部特征:功能和界面. 计算机处理过程设计:要确定每个模块的内部特征,即内部的执行过程,包括局部的数据组织、控 制流、每一步的具体加工要求及实施细节. 模块执行过程的描述表达方法: --处理过程设计的关键: ? 图形:如,传统的框图 - 35 - ? 语言:如,各种程序语言 ? 表格:如,判定表 (1) 程序流程图 流程图(flow chart) :即程序框图,是一种图形表示方法. 三种基本成分: ? 方框;表示加工步骤 ? 菱形;表示逻辑条件 ? 箭头:表示控制流 优点:直观、形象、容易理解. 缺点: ? 表示控制的箭头过于灵活,使用不当,流程图可能非常难懂,无法维护 ? 只描述执行过程而不能描述有关数据 适用:不适于结构化程序设计. (2) 盒图(NS 图) 原理: 将每个处理步骤用一个盒子表示.盒子可以嵌套.盒子只能从上头进入,从下头走出,除此 之外别无其他出入口. 适用:结构化程序设计. 优点: 与流程图相比,限制了随意的控制转移,保证了程序的良好结构. (3) 形式语言 定义:用来描述模块具体算法的非正式的比较灵活的语言. 特点:同结构性语言一致 ? 外层语法确定:用类似一般编程语言的保留字来描述控制结构. ? 内层语法不确定:可用自然语言来描述具体操作. 优点: ? 接近自然语言(英语) ,所以易于理解; ? 可作为注释嵌套在程序中成为内部文档,提高程序的自我描述性; ? 易于被计算机处理,可用行编辑程序或字处理系统对形式语言进行编辑修改. 缺点: ? 加工决策或判断的步骤较多,语句的嵌套层次太多 (4) 决策树 类属:决策树是一种图形工具. 适用:策略多、每个策略和若干条件有关的逻辑功能. (5) 决策表 优点:将比较复杂的决策问题简洁、明确、一目了然地描述出来. 缺点:树的结构比较复杂,图中各项注释比较繁琐. 类属:是一种呈表形的图形工具. 适用:判断条件多(各条件又相互组合) 、决策方案多的情形. 4.8.5 用户界面设计 用户界面定义: - 36 - 系统与用户之间的接口,控制和选择信息输入输出的主要途径. 设计原则 ? 友好、简便、实用、易于操作 设计内容: ? 菜单方式 ? 会话方式 ? 操作提示方式 ? 操作权限管理方式 (1) 菜单方式 菜单是信息系统功能选择操作的最常用方式. 菜单的形式: ? 下拉式 ? 弹出式 ? 按钮选择方式 (2) 会话管理方式 人机会话问题: ? 错误提示和警告性信息; ? 说明性提示; ? 控制型信息. 会话设计内容: 会话方式、容错能力和系统的模块结构. 基本工具:键盘、屏幕和打印机. 会话方式:回答式、菜单式、表格式和图形式 常用的人机会话方式: 纠错、容错的目的是保证会话的正确性,提高会话效率的方法: ? 提示法:分简单提示和重复提示法. ? 确认回答法:为用户误操作提供改错机会. ? 无效处理法:系统拒绝接收错误操作. ? 返回处理法:拒绝不熟悉系统的用户使用操作. ? 延时处理法:让用户有足够的时间理解系统的提问内容,防止错误回答. ? 帮助处理法:给用户提供帮助信息,并给予重新操作的机会. (3) 提示方式与权限管理 提示方式: ? 把操作提示和要点同时显示在屏幕的傍边,以使用户操作方便,这是当前比较流行 的用户界面设计方式. ? 另一种操作提示设计方式则是将整个系统操作说明书全送入到系统文件中,并设置 系统运行状态指针. 当系统运行操作时, 指针随着系统运行状态来改变, 当用户按"求助"健时,系统则立刻根据当前指针调出相应的操作说明. 权限管理: ? 一般都是通过入网口令和建网时定义该结点级别相结合来实现的. 4.8.6 安全控制设计 影响系统安全的因素: - 37 - ? 环境性因素:指管理机构的组织、硬件和系统软件、系统开发、自然环境等方面的 因素. ? 数据处理因素:指数据处理行为引起的各种情况. 4.8.7 系统设计说明书 系统设计报告是系统设计阶段的最终结果. 系统调查、系统分析、系统设计占总开发量的 70%. 系统设计说明书大纲: 一、引言 1.背景 2.摘要 3.工作条件/限制 4.参考和引用资料 5.专门术语定义 二、系统总体技术方案 1.模块设计 2.代码设计 3.输入设计 4.输出设计 5.数据库设计说明 6.模型库及方法库设计 7.网络设计 8.安全保密设计 9.实施方案说明书 5 系统测试知识 概念: 系统测试是为了发现错误而执行程序的过程. 测试目的: 以最少的人力和时间发现潜在的各种错误和缺陷. 信息系统测试内容: ? 软件测试:多数情况下测试即指软件测试. ? 硬件测试 ? 网络测试 系统测试意义: ? 是保证系统质量和可靠性的关键步骤; ? 是对系统开发过程中的系统分析、系统设计和实施的最后复查. 知识要点 ? 基本原则 ? 测试过程 - 38 - 5.1 基本原则 测试工作:应尽早并不断地进行测试. 测试人员:由专门人员而不是开发软件人员承担. 测试方案:不仅要确定输入数据,而且要根据系统功能确定预期输出结果.将实际输出结果与预期 结果相比较就能发现测试对象是否正确. 测试实例:输入条件包含有效合理的、不合理、失效的. 程序测试:不仅要检验程序是否做了该做的事,还要检验程序是否做了不该做的事. 按计划测试:避免测试的随意性.测试计划应包括测试内容、进度安排、人员安排、测试环境、测 试工具和测试资料等. 测试文档:测试计划、测试例子是软件文档的组成部分. 重新测试或追加测试 5.2 测试过程 测试过程:基本上与开发过程平行进行. ? S1 拟定测试计划. 考虑因素:项目开发时间、开发进度、人为因素和客观条件等. 内容:测试内容、进度安排、测试所需的环境和条件、测试培训安排等. ? S2 编制测试大纲. 测试大纲是测试的依据,包括:基本测试项目和测试完成的标准. ? S3 设计和生成测试例子. 内容:被测项目、输入数据、测试过程、预期输出结果等. ? S4 实施测试. 测试的实施阶段是由一系列的测试周期组成的,每个测试周期都对被测软件或设备进行完整的测 试. ? S5 生成测试报告. 内容:测试的概要说明、测试的结论,系统的缺陷和错误,另外,给出一些建议,如可采用的修 改方法,各项修改预计的工作量及修改的负责人员. 5.3 测试策略和测试方法 软件测试方法分类 ? 人工测试 ? 机器测试 ? 黑盒测试:功能测试 ? 白盒测试:结构测试 软件测试步骤 ? 单元测试:模块测试 ? 组装测试:集成测试 ? 确认测试:验收测试、… ? 系统测试:环境测试 - 39 - 5.3.1 人工测试 目的:通过对程序静态结构的检查,找出编译时不能发现的错误. 测试能力:可以发现程序中 30%~70%的编码和逻辑设计错误. 内容:人工测试又称为代码审查 ? 检查代码和设计是否一致 ? 检查代码逻辑表达是否正确和完整 ? 检查代码结构是否合理等. 人工测试方法 ? 个人复查: ? 内容:指程序员本人对程序进行检查. ? 特点:针对小规模程序,效率不高. ? 抽查: ? 内容:通常 3~5 人组成测试小组,测试人员应是没有参加该项目开发的有经 验的程序设计人员. ? 特点:人工检测程序很慢,只能选择少量简单的例子. ? 会审/代码复审. ? 内容:混合测试,在会审时,由编程人员逐句讲解程序,测试人员(其构成 与抽查法类似)逐个审查、提问,发现错误,使问题暴露. 5.3.2 机器测试 特点: ? 只能发现错误的症状,无法定位问题. 机器测试分类: ? 黑盒测试 ? 白盒测试 (1)黑盒测试 黑盒测试也称为功能测试. 定义: ? 在完全不考虑软件的内部结构和特性的情况下,测试软件的外部特性. 黑盒测试发现的错误类型: ? 是否有错误的功能或遗漏的功能? ? 界面是否有误? ? 输入是否正确接收? ? 输出是否正确? ? 是否有数据结构或外部数据库访问错误? ? 性能是否能够接受? ? 是否有初始化或终止性错误? (2)白盒测试 白盒测试也称为结构测试. 定义: ? 根据程序的内部结构和逻辑来设计测试例子,测试程序的路径和过程. - 40 - 测试原则: ? 程序模块中的所有独立路径至少执行一次. ? 在所有的逻辑判断中,取"真"和取"假"的两种情况至少都能执行一次. ? 每个循环都应在边界条件和一般条件下各执行一次. ? 测试程序内部数据结构的有效性等. 5.4 软件测试步骤 5.4.1 单元测试 单元测试也称为模块测试 特点: ? 在模块编写完成且无编译错误后就可以进行. ? 一般用白盒测试法 ? 多个模块可以同时进行. 单元测试主要从模块的以下五个特征进行检查: ? 模块接口 ? 局部数据结构 ? 重要的执行路径 ? 出错处理 ? 边界条件 ①单元测试--模块接口 模块接口保证测试模块的数据流可以正确地流入、流出. 测试要点: ? 测试模块的输入参数和形式参数在个数、属性、单位上是否一致. ? 调用其他模块时所给出的实际参数和被调用模块的形式参数在个数、属性、单位上 是否一致. ? 调用标准函数时所用的参数在属性、数目和顺序上是否正确. ? 全局变量在各模块中的定义和用法是否一致. ? 输入是否仅改变了形式参数. ? 开/关的语句是否正确. ? 规定的 I/O 格式是否与输入输出语句一致. ? 在使用文件之前是否已经打开文件或是用文件之后是否已经关闭文件. ②单元测试--局部数据结构 在单元测试中,局部数据结构出错是较常见的错误,测试时应重点考虑以下因素: ? 变量的说明是否合适. ? 是否使用了尚未赋值或尚未初始化的变量. ? 变量的初始值或默认值是否正确. ? 变量名是否有错(例如:拼写错) . ③单元测试--重要的执行路径 路径测试是最基本的单元测试任务 ? 计算方面的错误: 算术运算的优先次序不正确或理解错误;精度不够;运算对象的类型彼此不相容;算法错; - 41 - 表达式的符号表示不正确等. ? 比较和控制流的错误: 本应相等的量由于精度造成不相等; 不同类型进行比较; 逻辑运算符不正确或优先次序错误; 循环终止不正确(如多循环一次或少循环一次) 、死循环;不恰当地修改循环变量;当遇到分支循环 时,出口错误等. ④单元测试--出错处理 ? 出错条件 ? 出错处理路径 ⑤单元测试--边界条件 边界条件的测试是单元测试的最后工作. 边界条件测试需要开发两种模块: ? 驱动模块.相当于一个主程序,接收测试例子的数据,将这些数据送到测试模块, 输出测试结果. ? 桩模块,也称为存根模块.桩模块用来代替测试模块中所调用的子模块,其内可进 行少量的数据处理,目的是为了检验入口,输出调用和返回的信息. 提高模块的内聚度可以简化单元测试. 5.4.2 组装测试 定义:也称为集成测试,就是把模块按系统设计说明书的要求组合起来进行测试. 两种组装测试方法:非增量式集成与增量式集成: 5.4.3 确认测试 确认测试是软件测试的最后环节. 任务:进一步检查软件的功能和性能是否与用户要求的一样. 确认测试的基础:软件有效性验证的标准. 步骤: S1 有效性测试以及软件配置审查; S2 验收测试和安装测试; S3 有效性测试:通过黑盒测试检检测软件的功能、性能、容错性、维护性等; S4 软件配置审查:检查软件(源程序、目标程序)和文档(包括面向开发和用户的文档) ; - 42 - S5 验收测试:以用户为主的测试.验证软件的功能、性能、可移植性、兼容性、容错性等,测试时 一般采用实际数据. 5.4.4 系统测试 定义 将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起,进行信息系统的各种组 装测试和确认测试. 依据 系统测试是根据系统方案说明书来设计测试例子. 系统测试内容: ? 恢复测试:监测系统的容错能力. ? 安全性测试:检验系统的防范能力. ? 强度测试:测试承受异常情况的能力,是检查系统在极限状态下运行时,性能下降 的幅度是否在允许的范围内. ? 性能测试:通常与强度测试结合起来进行,并同时对软件、硬件进行测试.软件方 面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测. ? 可靠性测试:测试失效间隔时间 MTBF、年故障停机时间 MTTR. ? 安装测试 6 系统文档 6.1 信息系统文档介绍 信息系统文档的实质 ? 系统建设过程的"痕迹" ? 系统维护人员的指南 ? 开发人员与用户交流的工具 信息系统文档的作用 ? 规范的文档意味着系统是按照工程化开发的,意味着信息系统的质量保障. ? 文档的欠缺、随意性和不规范,意味着系统不可维护、不可升级、无扩展性、无生 命力. 信息系统文档的分类 ? 应用软件开发过程中产生的文档与硬件采购和网络设计中形成的文档; ? 规范文档与不规范文档(如来往文件、会议纪要、会计单据等) ; ? 系统实施纪录、程序资料和培训教程等. 6.2 文档在角色间的共享 文档在角色间的共享 ? 软件工程过程角色: - 43 - ? 系统分析人员 ? 系统开发人员 ? 项目管理人员 ? 系统维护人员 ? 系统评价人员 ? 用户 ? 在用户与其它角色之间共享的文档 ? 在系统开发人员与其它角色之间共享的文档 7 系统实施知识 7.1 系统实施概述 系统实施是新系统开发工作的最后阶段. 定义 指将系统设计阶段的结果在计算机上实现,将原来纸面上的、类似于设计图式的新系统方案 转换成可执行的应用软件系统. 知识要点 ? 任务 ? 系统实施过程中的非技术因素 ? 步骤 1、任务 任务 ? 按总体设计方案购置和安装计算机网络系统. ? 准备软件:软件包括系统软件、DBMS 以及应用程序.购买或编写程序. ? 培训用户 ? 准备数据:在确定数据库模型之后进行. ? 投入切换和试运行. 2、系统实施过程中的非技术因素 系统实施过程中的非技术因素 ? 企业的最高领导层 ? 企业的各级员工 ? 对信息系统使用持不信任态度的怀疑性排斥心理、畏惧心理 ? 信息系统的使用将传统的金字塔管理变为扁平管理,使以前无法暴露的灰色行为, - 44 - 将被一览无遗. 3、步骤 S1 按总体设计方案购置和安装计算机网络系统. S2 建立数据库系统. S3 程序设计. S4 收集有关数据并进行录入工作,然后进行系统测试. S5 人员培训、系统转换和试运行. 8 系统运行和维护知识 8.1 系统维护概述 定义: 维护人员理解、改正、改动和改进系统软件的难易程度. 可维护性的评价指标 维护与软件文档 软件文档的修改 维护应该针对整个软件配置:修改源程序代码必须改相应的技术文档. 可维护性的评价指标 ? 可理解性 ? 可测试性: 取决于易理解的程度,与系统的设计原则有直接关系. ? 可修改性: 影响因素包括模块的耦合、内聚、作用范围与控制范围的关系等. 8.2 维护与软件文档 文档是软件可维护性的决定因素. 文档的分类: ? 用户文档:描述系统功能和使用方法,不关心功能实现; ? 系统文档:描述系统设计、实现和测试. 系统开发阶段的技术审查和管理复查中的可维护性复审因素: ? 系统分析阶段:对将来要改进的部分和可能会修改的部分加以注解并指明,并且指 出软件的可移植性问题以及可能影响软件维护的系统界面; ? 系统设计阶段:从易修改、模块化和功能独立的目的出发,评价软件的结构和过程; ? 系统实施阶段:编码风格和内部说明文档. 8.3 系统维护的内容及类型 系统维护: ? 硬件维护,分类: - 45 - ? 定期的设备保养性维护:保养周期不等,内容包括例行的设备检查与保养、 易耗品的更换与安装等; ? 突发性的故障维护. ? 应用软件维护:[下接] ? 数据维护 ? 定义:数据库的安全性和完整性以及并发性控制. ? 数据维护中还有一项很重要的内容:代码维护. 8.4 软件维护 定义:指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改. 内容: - 46 -
下载该文档
文档格式：PDF
更新时间：2014-06-10
下载次数：0
点击次数：1
, 软件资格与水平考试 软件设计师 软件工程基础 讲义 www.ccidedu.com 1 课程概述 3 - 1.1 软件设计师级考试大纲分析 3 - 1.1.1 考试要求 3 - 1.1.2 考试科目设置 3 - 1.1.3 考试范围 3 - 1.2 软件设计师级试卷分析 5 - 2 软件工程基础知识 5 - 2.1 软件工程概述 5 - 2.1.1 软件生存周期 6 - 2.1.2 软件开发模型 7 - 2.2 软件需求分析 9 - 2.2.1 需求分析的任务 10 - 2.2.2 软件需求分析方法 10 - 2.3 软件开发项目管理 10 - 2.3.1 项目管理--成本估算 10 - 2.3.2 项目管理--风险分析 11 - 2.3.3 风险分析--风险评估.11 - 2.3.4 项目管理--进度管理 11 - 2.3.5 项目管理--人员管理 13 - 2.4 软件工具与软件开发环境 13 - 2.4.1 软件工具 13 - 2.4.2 软件开发环境 14 - 2.5 软件过程能力评估与质量保证 15 - 2.5.1 软件过程评估的意义 15 - 2.5.2 软件能力成熟度模型简介.16 - 2.5.3 软件质量管理与质量保证.17 - 3 系统分析基础知识 19 - 3.1 系统分析概述 19 - 3.2 结构化分析方法 20 - 3.2.1 基本概念 20 - 3.2.2 结构化分析方法--数据流图.20 - 3.2.3 结构化分析方法--数据词典.21 - 3.2.4 结构化分析方法--实体关系图.22 - 3.2.5 结构化分析方法--描述加工的结构化语言.24 - 3.3 系统分析报告 24 - 4 系统设计知识 25 - 4.1 系统设计概述 25 - 4.2 系统设计的内容 25 - 4.3 系统设计的步骤 25 - 4.4 系统设计的原则 25 - - 1 - 4.4.1 抽象 26 - 4.4.2 模块化 26 - 4.4.3 信息隐蔽 26 - 4.4.4 模块独立 26 - 4.5 结构化设计方法 27 - 4.5.1 基本概念 27 - 4.5.2 信息流的类型 27 - 4.6 系统总体结构设计 30 - 4.6.1 系统结构设计原则 30 - 4.6.2 子系统划分 30 - 4.6.3 系统模块结构设计 31 - 4.7 面向数据结构的设计方法 33 - 4.7.1 Jackson图.33 - 4.7.2 Jackson方法的设计步骤.34 - 4.8 系统详细设计 34 - 4.8.1 代码设计 34 - 4.8.2 输出设计 35 - 4.8.3 输入设计 35 - 4.8.4 处理过程设计 35 - 4.8.5 用户界面设计 36 - 4.8.6 安全控制设计 37 - 4.8.7 系统设计说明书 38 - 5 系统测试知识 38 - 5.1 基本原则 39 - 5.2 测试过程 39 - 5.3 测试策略和测试方法 39 - 5.3.1 人工测试 40 - 5.3.2 机器测试 40 - 5.4 软件测试步骤 41 - 5.4.1 单元测试 41 - 5.4.2 组装测试 42 - 5.4.3 确认测试 42 - 5.4.4 系统测试 43 - 6 系统文档 43 - 6.1 信息系统文档介绍 43 - 6.2 文档在角色间的共享 43 - 7 系统实施知识 44 - 7.1 系统实施概述 44 - 8 系统运行和维护知识 45 - 8.1 系统维护概述 45 - 8.2 维护与软件文档 45 - 8.3 系统维护的内容及类型 45 - 8.4 软件维护 46 - - 2 - 1 课程概述 1.1 软件设计师级考试大纲分析 1.1.1 考试要求 熟悉软件工程、软件过程改进和软件开发项目管理的基础知识 熟悉掌握软件设计的方法和技术 1.1.2 考试科目设置 <均包含软件工程知识> 计算机与软件工程知识:考试时间为 150 分钟,笔试 软件设计: 考试时间为 150 分钟,笔试 1.1.3 考试范围 计算机与软件工程知识 --系统开发与运行知识部分 软件设计 --软件工程部分 (1)软件开发与运行知识 ? 软件工程、软件过程改进和软件开发项目管理知识 ? 系统分析基础知识 ? 系统设计知识 ? 系统实施知识 ? 系统运行和维护知识 ? 面向对象开发方法 ? 软件工程、软件过程改进和软件开发项目管理知识 · 软件工程知识(软件危机(2002)) · 软件开发生命周期各阶段的目标和任务(2003,2004) · 软件开发项目管理基础知识 (时间管理、 成本管理、 质量管理、 人力资源管理、 风险管理(2004) 等)及其常用管理工具 · 软件开发模型(2001)(瀑布模型(2004) 、演化模型 (2001,2002) 、喷泉模型(2001)、螺旋模 - 3 - 型(2003) ) ? 系统分析基础知识 ·系统分析的目的和任务(2004) ·结构化分析方法(2004)(数据流图(DFD) (2003,2004) 、数据字典(DD) 、实体关系图 (ERD) 、描述加工处理的结构化语言(2002,2004)) · 统一建模语言(UML)(2004) · 系统规格说明书 ? 系统设计知识 · 系统设计的目的和任务 · 系统设计的原则(2003) · 结构化设计方法和工具(系统流程图、HIPO 图、控制流程图) · 系统总体结构设计(2002)(总体布局、设计原则、模块结构设计、数据存储设计、系统 配置方案) · 系统详细设计(代码设计、数据库设计、用户界面设计、处理过程设计) · 系统设计说明书 ? 系统实施知识 · 系统实施的主要任务 · 结构化程序设计、面向对象程序设计、可视化程序设计 · 程序设计风格 · 程序设计语言的选择 · 系统测试的目的、类型,系统测试方法(黑盒测试、白盒测试、灰盒测试) (2002,2004) · 测试设计和管理(错误曲线、错误排除、收敛、注入故障、测试用例设计、系统测试报 告) · 系统转换基础知识 ? 系统运行和维护知识 · 系统运行管理基础知识 · 系统维护基础知识 · 系统评价基础知识 ? 面向对象开发方法 · 面向对象开发概念(2003)(2004,2) (类(2003) 、对象(2003) 、属性、封装性、继承性、 多态性(2002)、对象之间的引用) · 面向对象开发方法的优越性以及有效领域(2004) · 面向对象设计方法(体系结构、类的设计、用户接口设计) · 面向对象实现方法(选择程序设计语言、类的实现、方法的实现、用户接口的实现、准 备测试数据) · 面向对象程序设计语言(如C++、Java、Visual、Bsasic、Visual C++)的基本机制 · 面向对象数据库、分布式对象的概念 (2)软件设计--软件工程 · 软件生存期模型(瀑布模型、螺旋模型、喷泉模型)和软件成本模型 · 定义软件需求(系统化的目标、配置、功能、性能和约束) · 描述软件需求的方法(功能层次模型、数据流模型、控制流模型、面向数据的模型、面向对 象的模型等) - 4 - · 定义软件需求的方法(结构化分析方法(2004) 、面向对象分析方法) · 软件设计(分析与集成、逐步求精、抽象、信息隐蔽) · 软件设计方法(结构化设计方法、Jackson 方法、Warnier 方法、面向对象设计方法) · 程序设计 (结构化程序设计 (程序流程图(2001,2) (2002,3) (2003) ) 、 面向对象程序设计(2003 ) (2004,2) ) · 软件测试的原则与方法 · 软件质量(软件质量特性、软件质量控制) · 软件过程评估基本方法、软件能力成熟度评估基本方法 · 软件开发环境和开发工具(分析工具、设计工具、编程工具、测试工具、维护工具、CASE) · 软件工程发展趋势(面向构件,统一建模语言(UML)(2004)) ·软件过程改进模型和方法 1.2 软件设计师级试卷分析 考试科目 计算机与软件工程知识 软件设计 题型分析 选择题 问答题 比重分析 软件工程占 25% 软件工程占 30%-40% 考试要求 基本概念、基础知识 综合应用的能力 知识点分布 结构化与面向对象知识各占一 半DFD 图、UML 图、ER 图、流程 图的应用技术 出题趋势分析 不超大纲,趋重细节 结构化与面向对象知识综合应 用,基础知识的掌握 2 软件工程基础知识 2.1 软件工程概述 ? 1968 年首次提出了"软件工程"这个名词,希望用工程化的原则和方法来克服软件危机. ? 研究内容: 软件开发模型 开发方法 工具 环境 ? 知识要点 - 5 - 软件生存周期 软件开发模型 2.1.1 软件生存周期 ? 软件生存过程:孕育、诞生、成长、成熟、衰亡. --这个过程即为计算机软件的生存周期. ? 软件生存周期包括 6 个阶段: ? 制定计划 ? 需求分析 ? 软件设计 ? 程序编制 ? 软件测试 ? 运行维护 (1)制定计划 ? 步骤 S1 确定要开发软件系统的总目标 S2 给出功能、性能、可靠性以及接口等方面的要求 S3 完成该软件任务的可行性研究 S4 估计可利用的资源(计算机硬件,软件,人力等)、成本、效益、开发进度 S5 制定出完成开发任务的实施计划,连同可行性研究报告,提交管理部门审查 (2)需求分析 ? 步骤 S1 对待开发软件提出的需求进行分析并给出详细的定义 S2 编写软件需求说明书或系统功能说明书及初步的系统用户手册 S3 提交管理机构评审 (3)软件设计 ? 步骤 S1 概要设计 — 把各项需求转换成软件的体系结构. 结构中每一组成部分都是意义明确的模块, 每 个模块都和某些需求相对应 S2 详细设计 — 对每个模块要完成的工作进行具体的描述,为源程序编写打下基础 S3 编写设计说明书,提交评审 (4)程序编制 ? 把软件设计转换成计算机可以接受的程序代码,即写成以某一种特定程序设计语言表示的 "源程序清单" ,即编码. (5)软件测试 ? 按规定的各项需求,逐项进行有效性测试,决定已开发的软件是否合格,能否交付用户使用 (6)运行维护 ? 改正性维护: 运行中发现了软件中的错误需要修正 ? 适应性维护: 为了适应变化了的软件工作环境,需做适当变更 ? 完善性维护: 为了增强软件的功能需做变更 - 6 - 2.1.2 软件开发模型 ? 软件开发模型直观地表达软件开发全部过程,明确规定要完成的主要活动和任务 ? 瀑布模型 ? 演化模型 ? 螺旋模型 ? 喷泉模型 (1)瀑布模型 特点: ? 从上一阶段接受本阶段工作的对象作为输入 ? 本阶段的工作成果作为输出传入下一阶段 ? 评估各阶段,若本阶段工作得到确认,继续,否则返回前一阶段 ? 可以增加反馈线来表示具有反馈回路的瀑布模型 (2)演化模型 - 7 - 特点: ? 在项目开发的初始阶段用户只能给出系统的核心,并根据实现的核心系统有效地提 出反馈,来支持系统的最终设计和实现. (3)螺旋模型 - 8 - 特点: 沿着螺线旋转,在四个象限上分别表达了四个方面的活动: ? 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件 ? 风险分析:分析所选方案,考虑如何识别和消除风险 ? 实施工程:实施软件开发 ? 客户评估评价开发工作,提出修正建议 (4)喷泉模型 特点: ? 迭代 ? 重复 ? 演进 ? 无间隙 ? 各阶段间无明显界限 2.2 软件需求分析 借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的 "做什么" 的问题. - 9 - 2.2.1 需求分析的任务 1.确定对系统的综合要求 系统功能要求、性能要求、运行要求、将来可能提出来的要求 2.分析系统的数据要求(建模) 3.导出系统的逻辑模型(数据流图、数据字典、IPO 图) 4.修正项目开发计划 5.开发原型系统 2.2.2 软件需求分析方法 ? 需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成 ? 它定义了表示系统逻辑视图和物理视图的方式 2.3 软件开发项目管理 ? 开始于技术工作开始之前,终止于软件工程过程结束 ? 成本估算 ? 风险分析 ? 进度管理 2.3.1 项目管理--成本估算 ? 方法1 ? 先估计完成软件项目所需的工作量(人月数) ,然后根据每个人月的代价(金额)计 算软件的开发费用: 开发费用 = 人月数 * 每个人月的代价 ? 方法2 ? 先估计软件的规模(源代码行数) ,然后根据每行源代码的平均开发费用(分析、设计、编码、测试所花的费用) ,计算软件的开发费用: 开发费用 = 源代码行数 * 每行平均费用 ? 估算源代码行数的方法: ? 请n位有经验的专家,每位专家对软件给出三个估计值: 最少源代码行数 最大代码行数 最可能的代码行数 ∑ = n i i E n 1 1 代码行数=n 位专家的估算期望值的平均值= 6 4 i i i i b m a E + + = 其中 Ei 为每位专家的估算期望值 - 10 - 2.3.2 项目管理--风险分析 (1)风险分析--风险识别 ? 风险识别:试图系统化地确定对项目计划(估算、进度、资源分配)的威胁 ? 风险识别方法:建立风险条目检查表,用来识别某些常见的已知的及可预测的风险,如:?产品规模 ? 商业影响 ? 客户特性 ? 开发环境 ? …… (2)风险分析--风险预测 ? 风险预测又称风险估算,从两方面评估一个风险: ? 风险发生的可能性或概率 ? 如果风险发生,所产生的后果 ? 4 种风险预测活动: ? 建立一个尺度或标准,以反映风险发生的可能 ? 描述风险的后果 ? 估计风险对项目和产品的影响 ? 标注风险预测的整体精确度,以免产生误解. 2.3.3 风险分析--风险评估 ? 风险评估步骤 ? 定义项目的风险参考水平值(成本、进度和性能 ) ; ? 建立每一组 与每一个参考水平值之间的关系; ( ) i i i x l r , , ri 表示风险,li 表示风险发生的概率,xi 表示风险产生的影响 ? 预测一组临界点以定义项目终止区域,该区域由一条曲线或不确定区域所界定; ? 预测什么样的风险组合会影响参考水平值. (4)风险分析--风险控制 ? 辅助项目组建立处理风险的策略 ? 风险控制需考虑三个问题: ? 风险避免 ? 风险监控 ? 风险管理及意外事件计划 2.3.4 项目管理--进度管理 ? 两种方式: 系统最终交付日期已经确定,软件开发部门必须在规定期限内完成; 系统最终交付日期只确定了大致的年限,最后交付日期由软件开发部门确定. ? 两种图形描述: Gantt 图-11 - PERT 图(1)进度管理图形描述--Gantt 图 优点:清晰地描述每个任务从何时开始,到何时结束以及各个任务之间的并行性. 缺点:不能清晰地反映出各任务之间的依赖关系,难以确定整个项目的关键所在,也不能反映计划 中有潜力的部分. (2)进度管理图形描述-- PERT 图 进度管理图形描述-- PERT 图-12 - 优点:清晰地反映出每个任务的开始时间、结束时间,还给出了任务之间的关系,即哪些任务完成 后才能开始另有一些任务,以及如期完成整个工程的关键路径.1,2,3,4,6,8,10,11,空任务. 缺点:不能反映任务之间的并行关系. 2.3.5 项目管理--人员管理 ? 按软件项目对软件人员分组: ? 需求分析组 ? 程序设计组 主程序员组、无主程序员组、层次式程序员组 ? 编码组 ? 测试组 ? 维护组 ? 质量保证组 2.4 软件工具与软件开发环境 ? 软件工具: ? 也称为 CASE 工具(计算机辅助软件工程,Computer Aided Software Engineering), 用来辅助软件开发、运行、维护、管理、支持等. ? 软件开发环境: ? 支持软件产品开发的软件系统,由软件工具集和环境集成机制构成. 2.4.1 软件工具 (1)软件工具--开发工具 ? 需求分析工具: ? 用以辅助软件需求分析活动,分为基于自然语言或图形描述的工具和基于形式化需 - 13 - 求定义语言的工具. ? 维护工具 ? 用以辅助软件设计活动,分为概要设计工具和详细设计工具 ? 编码与排错工具 ? 辅助程序员进行编码活动,分为有编码工具和排错工具 (2)软件工具--维护工具 ? 定义 用来辅助维护人员对软件代码及其文档进行各种维护活动. ? 分类 ? 版本控制工具:存储、更新、恢复和管理软件的版本 ? 文档分析工具:对软件开发过程中形成的文档进行分析,给出软件维护活动所需的 维护信息 ? 开发信息库工具:维护软件项目的开发信息,包括对象、模块等 ? 逆向工程工具:将形式表示的软件(源程序)转换成更高抽象形式表示的软件 ? 再工程工具:支持重构一个功能和性能更为完善的软件系统 (3)软件工具--软件管理和软件支持工具 ? 定义 用来辅助管理人员和软件支持人员的管理活动和支持活动,以确保软件高质量的完成. ? 分类 ? 项目管理工具:辅助软件的项目管理活动,包括项目的计划、调度、成本估算、及 质量控制等. ? 配置管理工具:辅助完成软件配置项的标识、版本控制、变化控制等. ? 软件评价工具:辅助管理人员进行软件质量保证的有关活动,确保软件的质量. (4)软件开发工具的评价和选择 ? 衡量软件开发工具的标准 ? 功能 ? 易用性 ? 稳健性 ? 硬件要求和性能 ? 服务和支持 2.4.2 软件开发环境 (1)软件开发环境的定义 ? 定义:支持软件产品开发的软件系统,由软件工具集和环境集成机制组成. ? 软件工具集: 支持软件开发的相关过程、活动和任务. ? 环境集成机制: 为工具集成和软件开发、维护和管理提供统一的支持,它通常包括数据集成、控制集成和界 面集成. 通过环境集成机制,各工具用统一的数据接口规范存储或访问环境信息库;各工具采用统一 的界面形式,保证各工具界面的一致性,同时为各工具或开发活动之间的通信、切换、调度和协同 工作提供支持. (2)软件开发环境的特征 - 14 - ? 环境的服务是集成性的 软件开发环境应支持多种集成机制,如平台集成、数据集成、界面集成、控制集成和过程集 成等. ? 环境应支持小组工作方式,并为其提供配置管理 ? 环境的服务可用于支持各种软件开发活动,包括分析、设计、编程、测试、调试、文档等 2.5 软件过程能力评估与质量保证 基点:软件产品的质量取决于软件开发过程 1987 年提出软件过程能力成熟度模型 CMM,在其基础上形成了国际标准(ISO/IEC 15504) . 知识要点: 1、软件过程评估的意义 2、软件能力成熟度模型简介 2.5.1 软件过程评估的意义 ? 软件过程评估是软件改进和软件能力评价的前提环节 1.软件过程改进的需要 (1)软件过程不断改进是软件工程的基本原理之一 ? 软件工程七原理: 按软件生存周期分阶段指定计划并认真实施 逐阶段进行确认 坚持严格的产品控制 使用现代程序设计技术 明确责任 用人少而精 不断改进开发过程 (2)软件过程改进是软件生存周期的基本过程之一 ? 软件工程界始终十分重视对软件过程的研究.20 世纪 70 年代中期形成了软件生存 周期的概念,1995 年正式发布了一项国际标准,即ISO/IEC 12207 信息技术——软 件生存周期过程,这是软件过程研究的一个重要成果.这项标准科学地定义了软件 生存周期的过程,总共 17 个,其中一个就是改进过程. 2.降低软件风险的需要 (1)软件采购者的需要--评价他人 软件产品或软件服务的采购单位进行招标、选择承制者时,为了降低风险,需要对备选单位 的软件过程能力进行评价,而这种评价的依据是对该单位的软件过程的评估结果. (2)软件承制者的需要--自我评价 软件产品研制单位和软件服务单位在响应顾客的需要、进行投标时,为了降低风险,需要对 自己的软件过程能力进行评价, 避免承担力所不及的任务,而这种评价的依据仍然是根据实际需要, 对相应软件过程的评估结果. - 15 - 2.5.2 软件能力成熟度模型简介 ? 软件过程:人们用于开发和维护软件及其相关产品(例如,项目计划、设计文档、代码、测 试用例、用户手册等等)的一系列活动、包括软件工程活动和软件管理活动. ? 软件过程能力:描述(开发组织或项目组)通过遵循其软件过程能够实现预期结果的程度.一 个软件开发组织或项目组的软件过程能力提供一种预测该组织承担下一个软件项目时最可 能的预期结果的方法. ? 软件过程性能:表示(开发组织或项目组)遵循其软件过程所得到的实际结果. --软件过程性能描述已得到的实际结果,而软件过程能力则描述最可能的预期结果. ? 软件过程成熟度:一个特定软件过程被明确和有效地定义、管理、测量和控制的程度.成熟 度可指明一个软件开发组织软件过程能力的增长潜力.软件过程成熟度越高,开发组织的软 件过程规范化和具体化程度越好. ? 软件能力成熟度等级: 软件开发组织在走向成熟的途中几个具有明确定义的表征软件过程能 力成熟度的平台.每一个成熟度等级为过程继续改进达到下一个等级提供一个基础. ? 关键过程域:互相关联的若干软件实践活动和有关基础设施的一个集合.即对软件能力成熟 度等级至关重要的过程域,它们的实施对达到该成熟度等级的目标起保证作用. ? 关键实践:对关键过程域的实施起关键作用的方针、规程、措施、活动以及相关基础设施的 建立. --关键实践一般只描述"做什么",而不强制规定"如何做". --关键过程域的目标是通过其包含的关键实践的实施来达到的. --基本观点:整个软件过程的改进是基于许多小的、进化的步骤,而不是通过一次革命性的创 新来实现的.这些小的进化步骤就通过一些关键实践来实现. ? 软件能力成熟度模型: 对软件组织进化阶段的描述,随着软件组织定义、实施、测量、控制和改进其软件过程,软 件组织的能力经过这些阶段逐步前进. 软件组织软件过程能力的增长模式: S1 确定当前过程成熟度并识别软件过程执行中的薄弱环节; S2 确定软件质量和过程改进的关键问题从而形成过程改进策略; S3 通过实施一组有限的关键实践活动,改善其全组织的软件过程. - 16 - 2.5.3 软件质量管理与质量保证 2.5.3.1 软件质量定义 ? 软件质量 指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体. ? 软件质量保证 指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动,其 目的是生产高质量的软件. 2.5.3.2 软件质量特性 ? 描述软件质量特性的软件质量模型 ? ISO/IEC 9126 软件质量模型 ? Mc Call 软件质量模型 ? ISO/IEC 9126 软件质量模型 - 17 - 质量特性和质量子特性的含义 ? 功能性(Functionality) :与一组功能及其指定的性质的存在有关的一组属性.功能是指满足 规定或隐含需求的那些功能. ? 可靠性(reliability) :与在规定的一段时间内和和规定的条件下,软件维持在其性能水平有 关的能力. ? 易使用性(usability) :与为使用所需的努力和由一组规定或隐含的用户对这样使用所作的个 别评价有关的一组属性. ? 效率(efficiency) :在规定条件下,软件的性能水平与所用资源量之间的关系有关的软件属 性. ? 可维护性(maintainability) :与进行规定的修改所需要的努力有关的一组属性. ? 可移植性(portability) :与软件可从某一缓建转移到另一环境的能力有关的一组属性. 2.5.3.3 软件质量保证 ? 目的:生产高质量的软件 ? 任务: (1) 应用技术方法:把软件质量设计到软件产品或软件系统中去,而不是在事后再施加质量保证. (2) 技术评审:进行质量评估. (3) 测试软件:软件测试不会揭露所有的错误种类. (4) 标准的实施. (5) 控制变更:应用于软件开发及软件维护阶段. (6) 度量(metrics):包括技术上的和管理上. (7) 记录保存和报告. - 18 - 3 系统分析基础知识 3.1 系统分析概述 系统分析的目的和任务 ? 系统分析侧重于从业务全过程的角度进行分析. ? 内容: A、业务和数据的流程是否通畅,是否合理; B、数据、业务过程和组织管理之间的关系; C、原系统管理模式改革和新系统管理方法是否可行等. ? 任务:提交系统分析报告,即系统方案说明书 系统分析报告的内容 ? 开发者对于现有组织管理状况的了解 ? 信息系统的功能需求 ? 数据和业务流程 ? 管理功能和管理数据指标体系 ? 新系统拟改动和新增的管理模型等 系统分析的主要步骤 系统分析过程图的说明 ? 系统开发的目的: 现有系统的物理模型→目标系统的物理模型. ? 系统分析的结果:得到目标系统的逻辑模型. ? 逻辑模型与物理模型的区别 逻辑模型:反应系统的功能和性质; 物理模型:反映系统的具体实现方案. ? 系统分析的工作步骤: - 19 - S1 建立当前系统的逻辑模型; S2 分析现状,提出改进意见和新系统的目标; S3 建立新系统的逻辑模型; S4 编写系统方案说明书. 3.2 结构化分析方法 3.2.1 基本概念 结构化分析(Structured Analysis)方法:简称 SA 方法 是一种面向数据流的需求分析方法 适用于:分析大型数据处理系统 基本思想:自顶向下,逐层分解 分解和抽象是人们控制问题复杂性的两种基本手段. 分析结果的成分: A 一套分层的数据流图 B 一本数据词典 C 一组小说明(也称加工逻辑说明) D 补充材料 3.2.2 结构化分析方法--数据流图 定义 数据流图或称数据流程图(Data Flow Diagram,DFD)是一种便于用户理解、分析系统数据 流程的图形工具.它摆脱了系统的物理内容,精确地在逻辑上描述系统的功能、输入、输出和数据 存储等,是系统逻辑模型的重要组成部分. (1)DFD 的基本成分 (2)分层数据流图的画法 - 20 - 步骤 S1 画系统的输入和输出:系统与外部实体之间的数据流情况,称为顶层图. S2 画系统的内部:将顶层图的加工分解成若干个加工,并用数据流将这些加工连接起来,使得顶层 图中的输入数据经过若干个加工处理后变换成顶层图的输出数据流.这张图称为 0 层图. S3 画加工的内部:用画 0 层图同样的方法画出每个加工的 DFD 子图. S4 重复第③步,直至图中的尚未分解的加工都足够简单.至此得到分层数据流图. 有关说明: 加工的确定方法:数据流的组成或值发生变化的地方;也可根据系统的功能确定加工. 数据流的确定方法:当用户把若干个数据看作一个单位来处理(这些数据一起到达,一起加工)时, 可把这些数据看成一个数据流. 数据存储的确定方法:表示以后某个时间要使用的数据. 加工分解:从加工画数据流图的过程等价于该加工的分解过程. (3)对图和加工进行编号 ① 父图与子图 父图可以有多张子图(这些子图位于同一层) ,但每张子图只对应于一张父图. ② 编号 顶层图只有一张,图中的加工只有一个. 0 层图只有一张,图中的加工号可以分别是 0.1,0.2,…或者是 1,2,… 子图号就是父图中被分解的加工号. 字图中的加工号由图号、圆点和序号组成. 例如, 某图中的某加工号为 2.4, 这个加工分解出来的子图号就是 2.4, 子图中的加工号分别为 2.4.1, 2.4.2,… (4)画图规则之一 命名规则:数据流、加工、数据存储、外部实体的命名反映其实际含义. 不同名规则:一个加工的输出数据流与输入数据流不同名. 数据流设置规则:允许一个加工有多条数据流流向另一个加工,也允许一个加工有两个相同的输出 数据流流向两个不同的加工. 数据存储设置规则:若一个数据存储首次出现时只与一个加工有关,那么这个数据存储应作为这个 加工的内部文件而不必画出. 加工的数据流守恒:每个加工必须既有输入数据流,又有输出数据流. 数据存储的数据流守恒:在整套数据流图中,每个数据存储必须既有读的数据流,又有写的数据流. 但在某一张子图中可能只有读没有写,或者只有写没有读. 数据守恒:一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得,或者是通 过该加工能产生的数据. 父图与子图的层间平衡:父图中某加工的输入输出数据流必须与它的子图的输入输出数据流在数量 和名字上相同.值得注意的是,如果父图的一个输入(或输出)数据流对应于子图中几个输入(或 输出)数据流,而子图中组成这些数据流的数据项全体正好是父图中的这一个数据流,那么它们仍 然算是平衡的.在考务处理系统例子中(见后),即统计分析表与难度分析表、统计分析表的关系. 注意:画数据流而不要画控制流. 3.2.3 结构化分析方法--数据词典 数据流图与数据词典的区别 数据流图:描述了系统的分解,但没有对图中各成分进行说明. - 21 - 数据词典:为数据流图中的每个数据流、文件、加工、数据项做出说明.其中对加工的描述称 为"小说明",也可以称为"加工逻辑说明". 词典条目 ① 数据流条目. ② 文件条目. ③ 数据项条目. 词典管理 提供排序、查找、统计、数据词典与数据流图间的一致性检测等功能. 3.2.4 结构化分析方法--实体关系图 定义 (Entity Relationship Diagram,ERD)是描述现实世界概念结构模型的图形工具. 知识要点 A ERD 基本成分 B 实体联系的基本形式 C 联系属性 D ERD 基本思想 E ERD 实例 (1) ERD 基本成分 ? ERD 基本成分:实体型、属性和联系. ? 实体型:用矩形框表示,如图(a)所示. ? 属性:用椭圆形框表示,如图(b)所示. ? 联系:指实体之间的联系,用菱形框表示,有一对一(1:1) ,一对多(1:n)或多 对多(m :n)三种联系类型.例如系主任领导系,学生属于某一系,学生选修课程, 这里"领导"、"属于"、"选修" 表示实体间的联系,可以作为联系名称.如图(c)所示. (2)实体联系的基本形式 ? 实体联系的基本形式 ①两个实体之间的联系,如下图(a)所示. ②两个以上实体间的联系,如下图(b)所示. ③同一实体集内部各实体之间的联系,例如一个部门内的职工有领导与被领导的联系,即某一职工 (干部)领导若干名职工,而一个职工(普通员工)仅被另外一个职工直接领导,这就构成了实体 内部的一对多的联系.如下图(c)所示. - 22 - (3)联系属性 联系属性 联系本身也是实体型,所以联系也可以有属性. 如果一个联系具有属性,则这些联系也要用无向边与该联系连接起来. 例如,学生选修的课程有相应的成绩.这里的"成绩"既不是学生的属性,也不是课程的属性,只能 是学生选修课程的联系的属性,如上图(a)所示.上图(b)中"供应数量"也是"供应"联系的属性. (4)ERD 基本思想 ERD 的基本思想 分别用矩形框、椭圆形框和菱形框表示实体、属性和联系,使用无向边将属性与其相应的实 体连接起来,并将联系分别和有关实体相连接,注明联系类型. 上图为几个 ERD 的例子,只给出了实体及其 ERD,省略了实体的属性. 下图描述了学生与课程联系的完整 ERD. - 23 - 3.2.5 结构化分析方法--描述加工的结构化语言 ? 结构化语言(如结构化英语) :介于自然语言和形式化语言之间的半形式化语言,是自然语 言的一个受限子集. ? 结构化语言没有严格的语法,它的结构通常可分为内外二层. 外层有严格的语法,如结构化英语的外层可以是 if-then-else,for-do,while-do,set 等结 构 内层的语法比较灵活,可接近于自然语言的描述. 示例:"折旧策略"的加工逻辑可以用结构化英语描述如下: Depreciation policy If the Current-Capital-Value is less than $1000 Then: Set Depreciation-Amount to Current-Capital-Value Set Current-Capital-Value to zero Otherwise: Set Depreciated-Amount to 10% of Current-Capital-Value Reduce Current-Capital-Value by 10% 3.3 系统分析报告 定义 是系统分析阶段的工作成果. 系统分析报告的主体 数据流图、数据字典和加工说明. 系统分析报告的作用 ? 描述了目标系统的逻辑模型,作为开发人员进行系统设计和实施的基础. ? 作为用户和开发人员之间的协议或合同,为双方的交流和监督提供基础. ? 作为目标系统验收和评价的依据. 系统分析报告的内容 (1) 组织情况概述 (2) 现行系统概述 (3) 系统逻辑模型 (4) 新系统在各个业务处理缓解拟采用的管理方法、算法或模型 (5) 与新的系统相配套的管理制度和运行体制的建立 (6) 系统设计与实施的初步计划 (7) 用户领导审批意见. - 24 - 4 系统设计知识 4.1 系统设计概述 目的 为系统制定蓝图,勾画出新系统的详细设计方案 项目开发过程不能按总体设计划分阶段顺利推进的原因 (1)系统逻辑模型中用户需求定义既不确定,也不完善. A 开发人员缺少足够的专业知识. B 用户尚缺少足够的技术知识. (2)系统分析描述目的系统的逻辑模型不总能充分描述新系统功能. (3)由于各阶段的工作之间可能存在反复,因此生命周期法中阶段的严格划分很难保证质量. 4.2 系统设计的内容 内容 1 总体结构设计 2 代码设计 3 输出设计 4 输入设计 5 处理过程设计 6 数据存储设计 7 用户界面设计 8 安全控制设计 4.3 系统设计的步骤 步骤 (1) 总体结构设计(又称概要结构设计) 定义:把总任务分解为许多基本的、具体的任务,这些具体任务合理地组织起来构成总任务. 基本任务:将系统划分为模块,决定每个模块的功能,决定模块的调用关系,决定模块的界 面,即模块间信息的传递. (2) 详细设计 定义:为各个具体任务选择适当的技术手段和处理方法. 内容:代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计、安 全控制设计. 4.4 系统设计的原则 z 抽象 - 25 - 软件工程中从软件定义到软件开发要经历多个阶段.在这个过程中每前进一步都可看作是对软 件解法的抽象层次的一次细化. z 模块化 z 信息隐蔽 z 模块独立 4.4.1 抽象 ? 定义 抽象是一种复杂现象进行简化的设计技术,重点说明一个实体的本质方面,而忽略或者掩盖不 很重要或非本质的方面. ? 抽象层次 在进行模块化设计时也可以有多个抽象层次,最高抽象层次的模块用概括的方式叙述问题的解 法,较低抽象层次的模块是对较高抽象层次模块对问题解法描述的细化,最低抽象层次就是实现该 软件的源程序代码. 4.4.2 模块化 定义 指将一个待开发的软件分解成若干个小的简单部分——模块,每个模块可独立地开发、测试, 最后组装成完整的程序. 特点 一种复杂问题的"分而治之"的原则. 目的 使程序的结构清晰,容易阅读、理解、测试、修改. 4.4.3 信息隐蔽 定义 用于开发整体程序结构,将每个程序的成分隐蔽或封装在一个单一的设计模块中,定义每一个 模块时尽可能少地显露其内部的处理. 作用 提高软件的可修改性、可测试性和可移植性. 4.4.4 模块独立 定义 指每个模块完成一个相对独立的特定子功能,并且与其他模块之间的联系简单. 模块独立程度的衡量标准:耦合与内聚 耦合:指模块之间联系的紧密程度.耦合度越高则模块的独立性越差. 内聚:指模块内部各元素之间联系的紧密程度.完成多个功能的模块的内聚度比完成单一功能 的模块的内聚度低.内聚度越低则模块的独立性越差. - 26 - 模块独立希望每个模块都是低耦合、高内聚. 4.5 结构化设计方法 4.5.1 基本概念 结构化设计(structured design,SD) 特点: SD 方法是一种面向数据流的设计方法,它可以与 SA 方法衔接. 基本思想 将系统设计成由相对独立、功能单一的模块组成的结构. 4.5.2 信息流的类型 在需求分析阶段,面向数据流的 SA 方法产生数据流图 DFD. 在系统设计阶段,面向数据流的 SD 方法将 DFD 转换成程序结构图. 信息流的定义 DFD 中从系统的输入数据流到系统的输出数据流的一连串连续变换. DFD 信息流的分类: 变换流与事务流. (1)变换流 工作原理 信息沿着输入通路进入系统,同时将信息的外部形式转换成内部表示,然后通过变换中心(也 称主加工)处理,再沿着输出通路转换成外部形式离开系统.具有这种特性的信息流称为变换流. 组成 变换流型 DFD 可以分成: 输入+变换(主加工)+输出 (2)事务流 工作原理 信息沿着输入通路到达一个事务中心,事务中心根据输入信息(即事务)的类型在若干个动作 序列(称为活动流)中选择一个来执行,这种信息流称为事务流. 特征 事务流有明显的事务中心,各活动流以事务中心为起点呈辐射状流出. (3) 、变换分析 变换分析是从变换流型的 DFD 导出程序结构图 步骤 S1 确定输入流和输出流,孤立出变换中心; S2 第一级分解:设计模块结构的顶层和第一层; S3 第二级分解:设计中、下层模块. 第一步 S1 确定输入流和输出流,孤立出变换中心 - 27 - 第二步 S2 第一级分解:设计模块结构的顶层和第一层 ? 变换流型 DFD 可映射成下图所示的程序结构图; ? 顶层模块:其功能就是整个系统的功能; ? 输入控制模块:接收所有的输入数据; ? 变换控制模块:实现输入到输出的变换; ? 输出控制模块:产生所有的输出数据. 顶层模块 输入控制 输出控制 变换控制 变换分析的第一级分解 第三步 S3 第二级分解:设计中、下层模块. ① 输入控制模块的分解:从变换中心的边界开始,沿着每条输入通路,把输入通路上的每个加工映 射成输入控制模块的一个低层模块. ② 输出控制模块的分解:从变换中心的边界开始,沿着每条输出通路,把输出通路上的每个加工映 射成输出控制模块的一个低层模块. ③ 变换控制模块的分解:变换控制模块通常没有通用的分解方法,应根据 DFD 中变换部分的实际 情况进行设计. (4)事务分析 事务分析是从事务流型 DFD 导出程序结构图. 步骤: S1 确定事务中心和每条活动流的流特性 S2 将事务流型 DFD 映射成高层的程序结构 S3 进一步分解 第一步 S1 确定事务中心和每条活动流的流特性 右图为事务流型 DFD 的一般形式. - 28 - 事务中心(图中的 T) : 位于活动流的起点, 活动流从该点成辐射状流出. 活动流:是信息流, 可以是变换流 也可以是另一条事务流. 事务流型的 DFD 的组成: 输入流+事务中心+若干条活动流 第二步 S2 将事务流型 DFD 映射成高层程序结构 右图为事务流型 DFD 的高层结构形式. 顶层模块:其功能就是整个系统的功能. 接收模块:接收输入数据,对应输入流. 发送模块:调度模块, 控制下层的所有活动模块. 活动流模块:对应活动流, 是该活动流映射成的 程序结构图中的顶层模块. 顶层模块 发送 接收 活动流1 活动流2 活动流n … 事务流型DFD的高层程序结构 - 29 - 第三步 S3 进一步分解 接收模块:类同于变换分析中输入控制模块的分解. 活动流模块:根据其流特性(变换流或事务流)进一步采用变换分析或事务分析进行分解. 4.6 系统总体结构设计 定义: 根据系统分析的要求和组织的实际情况,对新系统的总体结构形式和可利用的资源进行大致 设计,这是一种宏观、总体上的设计和规划. 系统总体设计的主要内容: 1 系统结构设计原则 2 子系统划分 3 系统模块结构设计 4 数据存储设计 4.6.1 系统结构设计原则 ① 分解——协调原则 ② 自顶向下的原则 ③ 信息隐蔽、抽象的原则 ④ 一致性原则 ⑤ 明确性原则 ⑥ 模块之间的耦合尽可能小,模块内部组合要尽可能紧凑. ⑦ 模块的扇入系数和扇出系数要合理. ⑧ 模块的规模适当. 有关说明: ? 模块的扇出系数:模块直接调用其他模块的个数. ? 模块的扇入系数:模块被其他模块调用时,直接调用的它的模块个数. ? 模块的扇入、扇出系数设置: ? 好的系统的平均扇入、扇出系统通常是 3 或4,一般不应超过 7. ? 菜单调用型模块扇入与扇出系统、公用模块扇入系统可以大一些. ? 模块的规模设置 ? 过大的模块:使系统分解得不充分. ? 过小的模块:降低模块的独立性,造成系统接口的复杂性. ? 最好的模块规模:程序系数限制在 1~2 页纸内. 4.6.2 子系统划分 划分原则 - 30 - ? 子系统要具有相对独立性 ? 子系统之间数据的依赖性尽量小 ? 子系统划分的结果应使数据冗余较小 ? 子系统的设置应考虑今后管理发展的需要 ? 子系统的划分应便于系统分阶段实现 ? 子系统的划分应考虑到各类资源的充分利用 子系统结构设计 ? 子系统结构设计的任务: ? 确定划分后的子系统模块结构,并画出模块结构图. ? 子系统结构设计考虑以下几个问题: ? 每个子系统如何划分成多个模块. ? 如何确定子系统之间、模块之间传送的数据及其调用关系. ? 如何评价并改进模块结构的质量. ? 如何从数据流图导出模块结构图. 4.6.3 系统模块结构设计 1、模块的概念 定义:组成系统的基本单位,系统中任何一个处理功能都可以及看成是一个模块. 特点:可以组合、分解和更换. 分类标准:根据模块功能具体化程度划分 分类:逻辑模块和物理模块 ? 逻辑模块:在系统逻辑模型中定义的处理功能. ? 物理模块:即逻辑模块的具体化,可以是一个计算机程序、子程序或若干条程序语 句,也可以是人工过程的某项具体工作. 模块的四要素: ? 输入和输出:模块的输入来源和输出去向都是同一个调用者,即一个模块从调用者 那里取得输入,进行加工后再把输出返回给调用者. ? 处理功能:指模块把输入转换成输出所作的工作. ? 内部数据:指仅供该模块本身引用的数据. ? 程序代码:指用来实现模块功能的程序. 模块特性 外部特性:反映了模块的外貌,即前两个要素,结构化设计考虑外部特性. 内部特性:即后两个要素,其具体实现在系统实施阶段完成. 2、模块结构图 模块结构图基本概念 ? 定义:是结构化设计中描述系统结构的图形工具.须定义模块的名字、功能和接口. ? 特点:关心模块的外部属性,即上下级模块、同级模块之间的数据传递和调用关系, 并不关心模块的内部. 知识要点: ? 结构设计原则 ? 模块结构图的基本符号 (1)结构设计原则 - 31 - 结构设计原则 ? 模块的独立性:所划分的模块其内部的凝聚性要强,模块之间的联系要少,即. ? 模块连接:模块之间的连接只能存在上下级之间的调用关系,不能有同级之间的横 向联系. ? 系统结构:整个系统呈树状结构,不允许网状结构或交叉调用关系出现. ? 模块(包括后继 IPO 图)的分类编码并归档. (2)模块结构图的基本符号 模块结构图基本符号 模块 调用 数据 控制 转接 ? 模块: 指用一个名字就可以调用的一段程序语句,用长方形表示. ? 调用: 箭头总是由调用模块指向被调用模块,但是应该理解被调用模块执行后又返回到调用模块. ? 特点:箭头由调用模块指向被调用模块,被调用模块执行后又返回到调用模块. ? 判断调用:通过判断条件决定是否调用一个从属模块,用菱形符号表示. ? 循环调用:通过循环功能循环调用一个或多个从属模块,用弧形箭头表示. 数据: 模块之间传送的数据用带空心圆的箭头表示,并在旁边标上数据名.下图(a)表示模块 A 调用 模块 B 时,A 将数据 x、y 传送给 B,B 将处理结果数据 z 返回给 A. 控制信息: 控制信息与数据的主要区别是前者只反映数据的某种状态,勿需处理.图15(b)中"无此职工" 就是用来表示送来的职工号有误的控制信息. - 32 - 转接符号 当模块结构图在一张纸上画不下,需要转接到另一张纸上,或者为了避免图上线条交叉时, 都可以使用转接符号,圆圈内加上标号,如下图所示. 4.7 面向数据结构的设计方法 定义: 面向数据结构的设计方法以数据结构作为设计的基础,它根据输入/输出数据结构导出程序的结 构. 适用:规模不大的数据处理系统. Jackson 方法是一种典型的面向数据结构的设计方法. 知识要点: 1 Jackson 图2Jackson 方法的设计步骤 4.7.1 Jackson 图 数据元素间逻辑关系分类:顺序、选择、重复. 表示数据结构 顺序:A 由B、C、D 三个成分顺序组成,其次序是从左到右; 选择:A 是B或C或D中的一个; 重复:A 由B重复出现多次(可以是 0 次)组成. 表示程序结构 方框表示模块,关系表示顺序、分支、重复. - 33 - 4.7.2 Jackson 方法的设计步骤 S1 分析并确定输入和输出数据的逻辑结构,并用 Jackson 图表示. S2 找出输入数据结构与输出数据结构间有对应关系的数据单元. 所谓有对应关系的数据单元是指有直接因果关系,在程序中可以同时处理的数据单元.对于 重复结构的数据单元,必须在重复次数和次序都相同时才有对应关系. S3 用下述的三条规则从描述数据结构的 Jackson 图导出描述程序结构的 Jackson 图. ? 为每对有对应关系的数据单元,按照它们在数据结构图中的层次在程序结构图的相 应层次画一个处理框.如果这对有对应关系的数据单元在输入数据结构图中所处的 层次与输出数据结构图中所处的层次不同,则取它们中较低的层次作为处理框在程 序结构图中的层次. ? 为输入数据结构图中剩余的每个数据单元,在程序结构图的相应层次上画一对应的 处理框. ? 为输出数据结构图中剩余的每个数据单元, 在程序结构图的相应层次上画一处理框. S4 列出所有的操作,并把它们分配到程序结构图的适当位置上. S5 用伪码表示程序. 4.8 系统详细设计 4.8.1 代码设计 设计原则 ? 唯一性:如职工编号、学生的学号等. ? 合理性:代码结构与响应的分类体系相对应. ? 可扩充性 ? 简单性 ? 适用性 ? 规范性.遵循国家有关编码标准.在一个代码体系中,代码结构、类型、编写格式 必须统一. ? 系统性:有一定的分组规则,如一级标准分类,二级标准分类等. 设计步骤 S1 确定代码对象; S2 考察已有标准代码; - 34 - S3 选择代码的种类与类型; S4 考虑检错功能; S5 编写代码表. 4.8.2 输出设计 从系统开发的角度看,输出决定输入,即输入信息只有根据输出要求才能确定. 输出设计内容: ? 确定输出内容 ? 选择输出设备与介质 ? 确定输出格式 输出方式: ? 报表输出:给出详细的记录数据,适于基层和具体事务的管理者, ? 图形输出:显示综合数据或发展趋势等信息,适于高层领导或宏观、综合管理部门 4.8.3 输入设计 目的:保证向系统输入正确的数据. 原则 ? 最小量原则 ? 简单性原则 ? 早检验原则 ? 少转换原则 内容 ? 确定输入内容 ? 输入方式设计 ? 输入格式设计 ? 校对方式设计 其中,校对方式分类: A 人工校对 B 二次键入校对(同一批数据两次键入) C 数据平衡校对 4.8.4 处理过程设计 总体结构设计:将系统分解成许多模块,并决定了每个模块的外部特征:功能和界面. 计算机处理过程设计:要确定每个模块的内部特征,即内部的执行过程,包括局部的数据组织、控 制流、每一步的具体加工要求及实施细节. 模块执行过程的描述表达方法: --处理过程设计的关键: ? 图形:如,传统的框图 - 35 - ? 语言:如,各种程序语言 ? 表格:如,判定表 (1) 程序流程图 流程图(flow chart) :即程序框图,是一种图形表示方法. 三种基本成分: ? 方框;表示加工步骤 ? 菱形;表示逻辑条件 ? 箭头:表示控制流 优点:直观、形象、容易理解. 缺点: ? 表示控制的箭头过于灵活,使用不当,流程图可能非常难懂,无法维护 ? 只描述执行过程而不能描述有关数据 适用:不适于结构化程序设计. (2) 盒图(NS 图) 原理: 将每个处理步骤用一个盒子表示.盒子可以嵌套.盒子只能从上头进入,从下头走出,除此 之外别无其他出入口. 适用:结构化程序设计. 优点: 与流程图相比,限制了随意的控制转移,保证了程序的良好结构. (3) 形式语言 定义:用来描述模块具体算法的非正式的比较灵活的语言. 特点:同结构性语言一致 ? 外层语法确定:用类似一般编程语言的保留字来描述控制结构. ? 内层语法不确定:可用自然语言来描述具体操作. 优点: ? 接近自然语言(英语) ,所以易于理解; ? 可作为注释嵌套在程序中成为内部文档,提高程序的自我描述性; ? 易于被计算机处理,可用行编辑程序或字处理系统对形式语言进行编辑修改. 缺点: ? 加工决策或判断的步骤较多,语句的嵌套层次太多 (4) 决策树 类属:决策树是一种图形工具. 适用:策略多、每个策略和若干条件有关的逻辑功能. (5) 决策表 优点:将比较复杂的决策问题简洁、明确、一目了然地描述出来. 缺点:树的结构比较复杂,图中各项注释比较繁琐. 类属:是一种呈表形的图形工具. 适用:判断条件多(各条件又相互组合) 、决策方案多的情形. 4.8.5 用户界面设计 用户界面定义: - 36 - 系统与用户之间的接口,控制和选择信息输入输出的主要途径. 设计原则 ? 友好、简便、实用、易于操作 设计内容: ? 菜单方式 ? 会话方式 ? 操作提示方式 ? 操作权限管理方式 (1) 菜单方式 菜单是信息系统功能选择操作的最常用方式. 菜单的形式: ? 下拉式 ? 弹出式 ? 按钮选择方式 (2) 会话管理方式 人机会话问题: ? 错误提示和警告性信息; ? 说明性提示; ? 控制型信息. 会话设计内容: 会话方式、容错能力和系统的模块结构. 基本工具:键盘、屏幕和打印机. 会话方式:回答式、菜单式、表格式和图形式 常用的人机会话方式: 纠错、容错的目的是保证会话的正确性,提高会话效率的方法: ? 提示法:分简单提示和重复提示法. ? 确认回答法:为用户误操作提供改错机会. ? 无效处理法:系统拒绝接收错误操作. ? 返回处理法:拒绝不熟悉系统的用户使用操作. ? 延时处理法:让用户有足够的时间理解系统的提问内容,防止错误回答. ? 帮助处理法:给用户提供帮助信息,并给予重新操作的机会. (3) 提示方式与权限管理 提示方式: ? 把操作提示和要点同时显示在屏幕的傍边,以使用户操作方便,这是当前比较流行 的用户界面设计方式. ? 另一种操作提示设计方式则是将整个系统操作说明书全送入到系统文件中,并设置 系统运行状态指针. 当系统运行操作时, 指针随着系统运行状态来改变, 当用户按"求助"健时,系统则立刻根据当前指针调出相应的操作说明. 权限管理: ? 一般都是通过入网口令和建网时定义该结点级别相结合来实现的. 4.8.6 安全控制设计 影响系统安全的因素: - 37 - ? 环境性因素:指管理机构的组织、硬件和系统软件、系统开发、自然环境等方面的 因素. ? 数据处理因素:指数据处理行为引起的各种情况. 4.8.7 系统设计说明书 系统设计报告是系统设计阶段的最终结果. 系统调查、系统分析、系统设计占总开发量的 70%. 系统设计说明书大纲: 一、引言 1.背景 2.摘要 3.工作条件/限制 4.参考和引用资料 5.专门术语定义 二、系统总体技术方案 1.模块设计 2.代码设计 3.输入设计 4.输出设计 5.数据库设计说明 6.模型库及方法库设计 7.网络设计 8.安全保密设计 9.实施方案说明书 5 系统测试知识 概念: 系统测试是为了发现错误而执行程序的过程. 测试目的: 以最少的人力和时间发现潜在的各种错误和缺陷. 信息系统测试内容: ? 软件测试:多数情况下测试即指软件测试. ? 硬件测试 ? 网络测试 系统测试意义: ? 是保证系统质量和可靠性的关键步骤; ? 是对系统开发过程中的系统分析、系统设计和实施的最后复查. 知识要点 ? 基本原则 ? 测试过程 - 38 - 5.1 基本原则 测试工作:应尽早并不断地进行测试. 测试人员:由专门人员而不是开发软件人员承担. 测试方案:不仅要确定输入数据,而且要根据系统功能确定预期输出结果.将实际输出结果与预期 结果相比较就能发现测试对象是否正确. 测试实例:输入条件包含有效合理的、不合理、失效的. 程序测试:不仅要检验程序是否做了该做的事,还要检验程序是否做了不该做的事. 按计划测试:避免测试的随意性.测试计划应包括测试内容、进度安排、人员安排、测试环境、测 试工具和测试资料等. 测试文档:测试计划、测试例子是软件文档的组成部分. 重新测试或追加测试 5.2 测试过程 测试过程:基本上与开发过程平行进行. ? S1 拟定测试计划. 考虑因素:项目开发时间、开发进度、人为因素和客观条件等. 内容:测试内容、进度安排、测试所需的环境和条件、测试培训安排等. ? S2 编制测试大纲. 测试大纲是测试的依据,包括:基本测试项目和测试完成的标准. ? S3 设计和生成测试例子. 内容:被测项目、输入数据、测试过程、预期输出结果等. ? S4 实施测试. 测试的实施阶段是由一系列的测试周期组成的,每个测试周期都对被测软件或设备进行完整的测 试. ? S5 生成测试报告. 内容:测试的概要说明、测试的结论,系统的缺陷和错误,另外,给出一些建议,如可采用的修 改方法,各项修改预计的工作量及修改的负责人员. 5.3 测试策略和测试方法 软件测试方法分类 ? 人工测试 ? 机器测试 ? 黑盒测试:功能测试 ? 白盒测试:结构测试 软件测试步骤 ? 单元测试:模块测试 ? 组装测试:集成测试 ? 确认测试:验收测试、… ? 系统测试:环境测试 - 39 - 5.3.1 人工测试 目的:通过对程序静态结构的检查,找出编译时不能发现的错误. 测试能力:可以发现程序中 30%~70%的编码和逻辑设计错误. 内容:人工测试又称为代码审查 ? 检查代码和设计是否一致 ? 检查代码逻辑表达是否正确和完整 ? 检查代码结构是否合理等. 人工测试方法 ? 个人复查: ? 内容:指程序员本人对程序进行检查. ? 特点:针对小规模程序,效率不高. ? 抽查: ? 内容:通常 3~5 人组成测试小组,测试人员应是没有参加该项目开发的有经 验的程序设计人员. ? 特点:人工检测程序很慢,只能选择少量简单的例子. ? 会审/代码复审. ? 内容:混合测试,在会审时,由编程人员逐句讲解程序,测试人员(其构成 与抽查法类似)逐个审查、提问,发现错误,使问题暴露. 5.3.2 机器测试 特点: ? 只能发现错误的症状,无法定位问题. 机器测试分类: ? 黑盒测试 ? 白盒测试 (1)黑盒测试 黑盒测试也称为功能测试. 定义: ? 在完全不考虑软件的内部结构和特性的情况下,测试软件的外部特性. 黑盒测试发现的错误类型: ? 是否有错误的功能或遗漏的功能? ? 界面是否有误? ? 输入是否正确接收? ? 输出是否正确? ? 是否有数据结构或外部数据库访问错误? ? 性能是否能够接受? ? 是否有初始化或终止性错误? (2)白盒测试 白盒测试也称为结构测试. 定义: ? 根据程序的内部结构和逻辑来设计测试例子,测试程序的路径和过程. - 40 - 测试原则: ? 程序模块中的所有独立路径至少执行一次. ? 在所有的逻辑判断中,取"真"和取"假"的两种情况至少都能执行一次. ? 每个循环都应在边界条件和一般条件下各执行一次. ? 测试程序内部数据结构的有效性等. 5.4 软件测试步骤 5.4.1 单元测试 单元测试也称为模块测试 特点: ? 在模块编写完成且无编译错误后就可以进行. ? 一般用白盒测试法 ? 多个模块可以同时进行. 单元测试主要从模块的以下五个特征进行检查: ? 模块接口 ? 局部数据结构 ? 重要的执行路径 ? 出错处理 ? 边界条件 ①单元测试--模块接口 模块接口保证测试模块的数据流可以正确地流入、流出. 测试要点: ? 测试模块的输入参数和形式参数在个数、属性、单位上是否一致. ? 调用其他模块时所给出的实际参数和被调用模块的形式参数在个数、属性、单位上 是否一致. ? 调用标准函数时所用的参数在属性、数目和顺序上是否正确. ? 全局变量在各模块中的定义和用法是否一致. ? 输入是否仅改变了形式参数. ? 开/关的语句是否正确. ? 规定的 I/O 格式是否与输入输出语句一致. ? 在使用文件之前是否已经打开文件或是用文件之后是否已经关闭文件. ②单元测试--局部数据结构 在单元测试中,局部数据结构出错是较常见的错误,测试时应重点考虑以下因素: ? 变量的说明是否合适. ? 是否使用了尚未赋值或尚未初始化的变量. ? 变量的初始值或默认值是否正确. ? 变量名是否有错(例如:拼写错) . ③单元测试--重要的执行路径 路径测试是最基本的单元测试任务 ? 计算方面的错误: 算术运算的优先次序不正确或理解错误;精度不够;运算对象的类型彼此不相容;算法错; - 41 - 表达式的符号表示不正确等. ? 比较和控制流的错误: 本应相等的量由于精度造成不相等; 不同类型进行比较; 逻辑运算符不正确或优先次序错误; 循环终止不正确(如多循环一次或少循环一次) 、死循环;不恰当地修改循环变量;当遇到分支循环 时,出口错误等. ④单元测试--出错处理 ? 出错条件 ? 出错处理路径 ⑤单元测试--边界条件 边界条件的测试是单元测试的最后工作. 边界条件测试需要开发两种模块: ? 驱动模块.相当于一个主程序,接收测试例子的数据,将这些数据送到测试模块, 输出测试结果. ? 桩模块,也称为存根模块.桩模块用来代替测试模块中所调用的子模块,其内可进 行少量的数据处理,目的是为了检验入口,输出调用和返回的信息. 提高模块的内聚度可以简化单元测试. 5.4.2 组装测试 定义:也称为集成测试,就是把模块按系统设计说明书的要求组合起来进行测试. 两种组装测试方法:非增量式集成与增量式集成: 5.4.3 确认测试 确认测试是软件测试的最后环节. 任务:进一步检查软件的功能和性能是否与用户要求的一样. 确认测试的基础:软件有效性验证的标准. 步骤: S1 有效性测试以及软件配置审查; S2 验收测试和安装测试; S3 有效性测试:通过黑盒测试检检测软件的功能、性能、容错性、维护性等; S4 软件配置审查:检查软件(源程序、目标程序)和文档(包括面向开发和用户的文档) ; - 42 - S5 验收测试:以用户为主的测试.验证软件的功能、性能、可移植性、兼容性、容错性等,测试时 一般采用实际数据. 5.4.4 系统测试 定义 将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起,进行信息系统的各种组 装测试和确认测试. 依据 系统测试是根据系统方案说明书来设计测试例子. 系统测试内容: ? 恢复测试:监测系统的容错能力. ? 安全性测试:检验系统的防范能力. ? 强度测试:测试承受异常情况的能力,是检查系统在极限状态下运行时,性能下降 的幅度是否在允许的范围内. ? 性能测试:通常与强度测试结合起来进行,并同时对软件、硬件进行测试.软件方 面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测. ? 可靠性测试:测试失效间隔时间 MTBF、年故障停机时间 MTTR. ? 安装测试 6 系统文档 6.1 信息系统文档介绍 信息系统文档的实质 ? 系统建设过程的"痕迹" ? 系统维护人员的指南 ? 开发人员与用户交流的工具 信息系统文档的作用 ? 规范的文档意味着系统是按照工程化开发的,意味着信息系统的质量保障. ? 文档的欠缺、随意性和不规范,意味着系统不可维护、不可升级、无扩展性、无生 命力. 信息系统文档的分类 ? 应用软件开发过程中产生的文档与硬件采购和网络设计中形成的文档; ? 规范文档与不规范文档(如来往文件、会议纪要、会计单据等) ; ? 系统实施纪录、程序资料和培训教程等. 6.2 文档在角色间的共享 文档在角色间的共享 ? 软件工程过程角色: - 43 - ? 系统分析人员 ? 系统开发人员 ? 项目管理人员 ? 系统维护人员 ? 系统评价人员 ? 用户 ? 在用户与其它角色之间共享的文档 ? 在系统开发人员与其它角色之间共享的文档 7 系统实施知识 7.1 系统实施概述 系统实施是新系统开发工作的最后阶段. 定义 指将系统设计阶段的结果在计算机上实现,将原来纸面上的、类似于设计图式的新系统方案 转换成可执行的应用软件系统. 知识要点 ? 任务 ? 系统实施过程中的非技术因素 ? 步骤 1、任务 任务 ? 按总体设计方案购置和安装计算机网络系统. ? 准备软件:软件包括系统软件、DBMS 以及应用程序.购买或编写程序. ? 培训用户 ? 准备数据:在确定数据库模型之后进行. ? 投入切换和试运行. 2、系统实施过程中的非技术因素 系统实施过程中的非技术因素 ? 企业的最高领导层 ? 企业的各级员工 ? 对信息系统使用持不信任态度的怀疑性排斥心理、畏惧心理 ? 信息系统的使用将传统的金字塔管理变为扁平管理,使以前无法暴露的灰色行为, - 44 - 将被一览无遗. 3、步骤 S1 按总体设计方案购置和安装计算机网络系统. S2 建立数据库系统. S3 程序设计. S4 收集有关数据并进行录入工作,然后进行系统测试. S5 人员培训、系统转换和试运行. 8 系统运行和维护知识 8.1 系统维护概述 定义: 维护人员理解、改正、改动和改进系统软件的难易程度. 可维护性的评价指标 维护与软件文档 软件文档的修改 维护应该针对整个软件配置:修改源程序代码必须改相应的技术文档. 可维护性的评价指标 ? 可理解性 ? 可测试性: 取决于易理解的程度,与系统的设计原则有直接关系. ? 可修改性: 影响因素包括模块的耦合、内聚、作用范围与控制范围的关系等. 8.2 维护与软件文档 文档是软件可维护性的决定因素. 文档的分类: ? 用户文档:描述系统功能和使用方法,不关心功能实现; ? 系统文档:描述系统设计、实现和测试. 系统开发阶段的技术审查和管理复查中的可维护性复审因素: ? 系统分析阶段:对将来要改进的部分和可能会修改的部分加以注解并指明,并且指 出软件的可移植性问题以及可能影响软件维护的系统界面; ? 系统设计阶段:从易修改、模块化和功能独立的目的出发,评价软件的结构和过程; ? 系统实施阶段:编码风格和内部说明文档. 8.3 系统维护的内容及类型 系统维护: ? 硬件维护,分类: - 45 - ? 定期的设备保养性维护:保养周期不等,内容包括例行的设备检查与保养、 易耗品的更换与安装等; ? 突发性的故障维护. ? 应用软件维护:[下接] ? 数据维护 ? 定义:数据库的安全性和完整性以及并发性控制. ? 数据维护中还有一项很重要的内容:代码维护. 8.4 软件维护 定义:指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改. 内容: - 46 -