通知 网站从因情语写改为晴雨,这个网站的模板也从calmlog_ex改为 whimurmur

软件工程概论学习笔记二

64人浏览 / 0人评论 / | 作者:whisper  | 分类: 软件工程  | 标签: 软件工程  | 

作者:whisper

链接:https://www.proprogrammar.com/article/882

声明:请尊重原作者的劳动,如需转载请注明出处


5 系统设计

需求分析:做什么

系统设计:怎么做

软件系统设计就是把软件需求变换成软件表示的过程

概要设计 详细设计

基本任务

1.数据库设计 2.软件结构设计 3.接口设计 4. 模块的详细设计

软件设计的基本原理

模块化 抽象 逐步求精 信息隐藏 模块独立性

模块化

单独命名的,包含数据说明、可执行语句等程序对象的集合,可以通过名字访问模块。

模块的属性:接口、功能、逻辑、状态。

类、过程、函数、子程序、宏等都是模块。

抽象

软件开发过程的每一步都是对较高一级抽象的解作一次具体化的描述。抽象层次逐渐降低,越 来越接近底层实现。

过程抽象 数据抽象

逐步求精

把问题的求解过程分解成若干步骤或阶段,每步都比上步更 精化,更接近问题的解法。

常与分层抽象的思想相结合

信息隐藏

每个模块都尽量对其他模块隐藏自己的内部实现细节

信息隐藏是实现抽象/模块化机制的基本支撑

模块独立性

模块独立性是指软件系统中每个模块只涉及某 个具体的子功能,与软件系统中其他模块之间的 接口比较简单。

内聚度 耦合度

内聚(cohesion):一个模块内部各个元素彼此结合的紧密程度。—尽量高

耦合(coupling):模块之间相互关联的程度。—尽量低

耦合度的七个层次

内聚的七个层次

结构化设计

结构化设计(Structured Design,SD)是一 种面向数据流的设计方法,它可以与结构化分析 (Structured Analysis,SA )方法衔接。

结构化设计是在模块化、自顶向下细化、结 构化程序设计等程序设计技术基础上发展起来的。 基本思想是将系统设计成由相对独立、功能单一 的模块组成的结构。

软件结构图

表示软件模块的控制层次结构。它以特定的符号表示模块、 模块间的调用关系和模块间信息的传递。

软件结构图的相关指标:宽度 深度 扇入 扇出 从属 主宰

变换型分析设计

变换型数据流图:数据沿着输入路径进入系统,经过一系列 数据变换,将数据的外部形式转换成对应的内部表 示,然后通过变换中心(也称主加工)处理,再沿 着输出路径转换成外部形式离开系统。具有这种特 性的数据流称为变换流。

事务型分析设计

事务型数据流图

事务型数据有明显的事务中心

事务中心分析事务(即输入数据)的类型

事务中心选择与该事务对应的一条活动流来执行

各活动流以事务中心为起点呈辐射状流出。

事务中心 活动流

软件结构优化准则

1.改造软件结构图,提高模块独立性。

2.深度、宽度、扇入和扇出适中

3.模块的作用范围应限制在该模块的控制范围内,例如下图中

4.模块大小要适中

5.降低模块接口的复杂性

结构化设计实例

1.需求描述

2.数据流图

3.软件结构图

4.软件模块的定义

面向对象设计

面向对象分析和设计的界限是模糊的

从面向对象分析到面向对象设计是一个逐渐扩充模型的过程

分析的结果通过细化直接生成设计结果

在设计过程中逐步加深对需求的理解

从而进一步完善需求分析的结果

面向对象设计的四个层次

确定系统的总体结构和风格,构造系统的物理模型,将 系统划分成不同的子系统。

中层设计:对每个用例进行设计,规划实现用例功能的 关键类,确定类之间的关系。

进行底层设计:对每个类进行详细设计,设计类的属性 和操作,优化类之间的关系。

补充实现非功能性需求所需要的类,比如界面类等等。

面向对象设计活动

系统构架设计 用例设计 类设计 数据库设计 用户界面设计

面向对象设计原则

结构化设计原则如模块化、抽象、信息隐藏、模块独立 性等也适用于面向对象设计

软件重用 使用框架

系统构架设计

构架设计的目的是要勾画出系统的总体结构,这项工作一般由经验丰富的构架设计师主持完成。

步骤1:构造系统的物理模型

步骤2: 设计子系统

步骤3:非功能需求设计:系统的安全性 可移植性 错误监测和故障恢复 通用性

用例设计

根据分析阶段产生的业务类图和交互图,由用例设计人员 研究已有的类,将它们分配到相应的用例中。

检查每个用例功能,依靠当前的类能否实现,同时检查每 个用例的特殊需求是否有合适的类来实现。

细化每个用例的类图,描述实现用例的类及其类之间的相 互关系,其中的通用类和关键类可用特殊颜色区分。

类的设计

详细设计用例类图中的每一个类:类的属性、方法。

6 系统实现

程序设计语言

第一代为机器语言

第二代为汇编语言

第三代为高级语言

第四代为“非过程性语言”

第五代为自然语言

高级语言 过程式语言(如Cobol,Forturn,Algol,Pascal,Ada,C) 函数式语言(如Lisp) 数据流语言(如SISAL,VAL) 面向对象语言(如Smalltalk, CLU,C++,java)逻辑语言(如Prolog) 字符串语言(如SNOBOL) 并发程序设计语言(如Concurrent Pascal,Modula 2)等。

脚本语言

WEB服务端:PHP,ASP,JSP等

Web客户端:Javascipt

广泛应用开发:Perl,Python,Ruby

专用脚本语言:Tcl/tk

非过程性语言

数据库管理 SQL、Adabas等;

报告生成 Progress 4GL Query/Result等;

数值优化 MATLAB等;

Web开发 WaveMaker等;

编程原则

程序总体风格

1.使用编程语言所推荐的业界编程风格

2. 代码格式保持一致性

3. 写朴实自然的代码

4. 逻辑清晰、简洁、紧凑

5. 理解和遵循已有规范

程序中的标识符命名要有意义

函数

1.函数的第一规则是要短小,第二条规则是还要更短小。

2.函数应该做一件事 做好这件事。只做这一件事。

3.尽量少的函数参数

1.类应该短小

2.单一权责原则(SRP)

3.内聚

4.开放闭合原则(OCP)

系统

注释

1. 程序头

2.主要变量(结构、联合、类或 对象):含义的注释。

3. 应保持注释与代码完全一致。

4. 处理过程的每个阶段和典型算法前都有相关注释说明, 但是 不要对每条语句注释。

格式

函数与函数之间留空行。

相关函数,如果某个函数调用另外一个, 就应该把他们放在一起,而且调用者应 该尽可能放在被调用者的上面。

“相关概念的代码放在一起。相关性越强, 比如一个大功能逻辑靠在一起。 ”变量声明:变量声明应该尽可能靠近 其使用位置。

代码保持整洁

程序效率

一般是用时间复杂度、空间复杂度来衡量

提高程序效率

降低时间复杂度

减小空间复杂度

软件版本管理

所有系统开发及实施的软件项目都应进行版 本管理。项目中所有正式文档和代码都应纳 入配置库。

版本管理的对象包括且不仅限于:

项目总体计划、可行性研究报告、开发计划、需求 说明书、需求设计原型、设计说明书、系统开发变 更申请单。

系统管理手册、用户操作手册、培训计划、培训记录、 源程序

支持系统运行的配置文件、存储过程脚本、测试计 划、测试用例、测试脚本、测试报告、上线计划、 上线申请、版本维护日志。

人员权限

1、配置库管理员  2、开发工程师 3、测试工程师 4、其他人员

软件版本管理的维护

软件工程各阶段产生的各种文档和代码,应及时并统一 上载到配置库由配置库管理员统一管理。对于要修改的 配置项,应从配置库中检出(check out)后修改,修改 完毕后及时检入(check in),并填写修改的原因和内容。 配置项的历史版本应保存在配置库中

软件版本管理的意义

标识、控制和追踪软件开发和实施过程中产生的各种 软件产品版本。

开发者自己对产品进行测试,检查产品是否存在缺陷、 错误,验证产品功能与说明书、用户手册是否一致。

适用于软件源代码、产品版本的管理。通常内部使用, 不对外发布。

软件版本管理工具

CVS SVN GIT

软件版本命名规则

7 软件测试与调试

软件测试:是指识别软件缺陷的过程,即实际结 果与预期结果的不一致。是为了发现程序中的错误 而执行程序的过程。

软件测试对象:软件开发过程中所产生的需求规格说明、概要设计、详 细设计、源代码都是软件测试的对象

软件测试重点

测试用例的良好设计

测试工作的管理

测试环境的建立

软件测试度量

测试覆盖率

缺陷发现率

测试成功率

软件测试技术和方法

黑盒测试方法

白盒测试主要方法

软件测试用例

软件测试是根据软件开发各阶段的规格说明和程序 的内部结构而精心设计的一批测试用例,并利用这些测试用例 运行程序以及发现错误的过程。

自动化测试工具

软件测试文档

测试计划 测试用例 测试报告 统计和总结

软件测试与软件开发过程关系

测试执行过程三个阶段

初测期 细测期 回归测试期

集成测试过程中两个重要里程碑

功能冻结 代码冻结

软件测试步骤

单元 (模块) 测试 集成测试 系统测试或确认测试

Alpha测试和Beta测试

软件测试准则

所有测试都应该能追溯到用户需求

应当把“尽早地和不断地进行软件测 试” 作为软件开发者的座右铭。

pareto原则:测试发现的错误中的80%很可能是由程序中20%的模块造成的

应该从“小规模”测试开始,并 逐步进行“大规模”测试

测试用例应由输入数据和预期的输出结果两部分 组成,并兼顾合理的输入和不合理的输入数据

穷举测试是不可能的

应该由独立的第三方从事测试工作

程序修改后要回归测试

应长期保留测试用例,直至系统废弃

白盒测试

逻辑覆盖

语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖

插桩法:目标代码插桩法 源代码插桩法

逻辑覆盖测试不同标准发现错误能力

黑盒测试

黑盒测试着重测试软件功能

黑盒测试与白盒测试是互补的测试方法,它能发 现白盒测试不易发现的其他类型的错误。

①功能不正确或遗漏了功能 ②界面错误 ③性能错误

黑盒测试方法

等价划分法 边界值分析法 错误推测法 因果图法等

软件调试

是泛指重现软件缺陷(错误)问题,定位和查找 问题根源,最终解决问题的过程

软件测试是发现错误,软件调试是发现并修改错误

调试包含两个步骤

确定程序中可疑错误的准确性质和位置

修改错误

调试的基本步骤

1. 定位(确定程序中出错的位置)

2. 研究、找出错误的内在原因

3. 修改相关程序,甚至可能要修改需求或设计阶段的相 关工作。

4. 对修改后的程序部分重新进行原始测试,以确认: 是否已排除该错误,是否引进新错误

5. 若所做的修改无效,则应撤消本次修正,恢复程序于 修改之前的状态,再重复上述步骤1一4,直至修改成功

8 软件维护

软件维护是指在软件产品发布后,因修正错误、提升 性能或其他属性而进行的软件修改

软件维护的分类

改正性维护 适应性维护 完善性维护 预防性维护

软件维护的特点

非结构化维护和结构化维护差别巨大,非结构化维护的 对象只是程序代码,而内部文档不足,导致维护需要付 出很大代价。

结构化维护的对象是完整的软件配置,需要从设计文档 评价开始,经过分析软件特点,估量修改带来的影响, 再经过一系列修改步骤才开始编写相应源代码,这使得 软件维护减少了精力的浪费,提高维护的总体质量

维护的代价很大,在过去几十年里,维护费用逐年 上升,而且如果软件开发没有运用软件工程方法学, 原来的开发者不参与维护,那么维护的工作和质量 将指数地增加。

维护的难度很大。因为理解别人的程序本来就有难 度,而没有合格的文档、或原始开发人员可能不在、 或绝大多数软件在设计时没有考虑将来的修改等等 都会造成维护的难度增加。

软件维护过程

维护过程本质上是修改和压缩了软件定义和开发过程

软件可维护性

软件可维护性指的是维护人员对该软件进行维护的 难易程度,具体包括理解、改正、改动和改进该软 件的难易程度

软件系统的规模大小 软件系统的年龄 软件设计结构合理 性

可维护性可通过7个质量特性来衡量:

可理解性 可测试性 可修改性 可靠性 可移植性 可使用性 效率

维护的副作用

所谓维护的副作用就是因修改软件而造成新的错误或出 现其它不希望发生的情况,有三种副作用:

修改代码的副作用 修改数据的副作用 修改文档的副作用

9 软件项目管理

根据项目管理的理论,结合软件项目开发的实际,保证 工程化系统开发方法顺利实施的管理实践

它是为使软件项目能够按照预定的成本、进度、质量顺 利完成,从而对成本、进度、质量、人员、风险、过程 等进行分析、管理、控制的一系列活动。

软件工程三线索

项目管理知识体系

软件项目生命周期

软件度量

软件度量是对软件开发项目、过程及其产品进行数据定 义、收集以及分析的持续性定量化过程,目的在于对此 加以理解、预测、评估、控制和改善。

通过软件度量可以改进软件开发过程,促进项目成功, 开发高质量的软件产品

项目度量是针对软件开发项目的特定度量,目的在于度 量项目规模、项目成本、项目进度、顾客满意度等

软件质量度量指标

初期故障率 偶然故障率

平均失效前时间(Mean Time to Failure,MTTF) 平均修复时间(Mean Time to Repairation, MTTR)

需求管理

需求工程

项目范围管理

项目范围

软件产品范围:表现为软件需求规格说明书

还包括项目中应展开的工作,例如制定项目计划、编写 文档、用户培训等

需求规格说明书(SRS)

功能特征描述 系统接口描述 质量特征描述

软件项目任务分解

项目任务分解就是为了实现项目的目标,把项目要完成 的工作,包括管理活动和工程活动,分解成一个个可控 的、小的任务。

项目任务分解的结果是W BS(Wo r k Br e a k d o w n Sturcture)

项目进度管理

项目进度管理就是要采用一定的方法对项目 范围所包括的活动及其之间的相互关系进行分析,对各 项活动所需要的时间进行估计,按照项目要求编制进度 计划,并在项目的时间期限内合理地安排和控制活动的 开始和结束时间

进度管理6个子过程

活动定义 活动排序 活动资源估计 活动历时估计 制定进度计划 进度控制

软件项目成本管理

成本管理的主要目的就是将项目的运作成本控制在预算 的范围内,或者控制在可以接受的范围内。

成本管理包括

资源计划编制 成本估算 成本预算 成本控制

软件项目质量管理

功能性 效率 易用性 可靠性 可维护性 可移植性

软件质量管理模型

项目质量计划

是一项确定项目所要达到的质量标准以及如何 达到该质量标准的计划安排。

项目质量保证

是指在执行项目质量计划的过程中,经常性地对整个项 目质量计划执行情况所进行的评估、核查与改进等工作。

是一项确保项目质量计划能够得以执行和完成的工作, 使项目质量能够最终满足项目质量要求的系统性工作。

项目质量控制

是指在项目实施过程中,对项目质量的实际 情况进行监督,判断是否符合相关的质量标准,并分析 产生质量问题原因,制订出相应措施来消除导致不符合 质量标准的因素,确保项目质量得以持续不断地改进

软件质量控制方法

软件项目配置管理

是一种标识、组织和控制修改的技术,目的是使错误 降为最小并最有效地提高生产效率。软件配置管理贯穿于整个 软件生命周期,它为软件研发提供了一套管理办法和活动原则

软件配置管理的目标

软件配置管理的目标就是为了标识变更、控制变更、 确保变更正确实现并向其他有关人员报告变更。

配置管理过程

配置项的标识、跟踪 配置环境建立 基线变更管理 配置审计 配置状态统计 配置管理计划

软件项目团队管理

软件项目团队管理就是采用科学的方法,对项目组织 结构和项目全体参与人员进行管理,在项目团队中开展一 系列科学规划、开发培训、合理调配、适当激励等方面的 管理工作,使项目组织各方面的主观能动性得到充分发挥, 同时促进高效的团队协作,以利于实现项目的目标

主要内容

项目组织的规划 团队人员获取 团队建设 团队日常工作管理 沟通管理

软件风险管理

在风险影响软件项目成功实施前,对它进行识别和处理, 并预防和消除风险的发生

识别风险(会有哪些风险?)

预防和消除风险(最好别让风险发生)

制定风险发生后的处理措施(万一发生该怎么办?)

软件项目收尾

项目收尾过程是对项目管理计划中收尾部分的执行。

是项目承建方和客户对最终产品进行验收,使项目 有序地结束的过程。

项目最后的执行的结果有两种状态: 成功 失败

范围确认 质量验收 费用决算 合同终止 项目资料检查和归档 项目总结

软件项目管理计划

在软件项目实施方案中,根据现有的人力资源、技术能 力、项目工期合理地制定项目管理计划。

软件项目管理计划包括项目组织架构、工作分解结构、 进度管理计划、需求调研计划、项目资源计划、配置管 理计划、质量管理计划、项目风险计划等

进度管理计划

根据进度管理前面四个子过程的输出,如活动排序(网 络图)、估算活动资源、估算资源持续时间,编制项目 的进度计划,确定项目活动的计划开始日期和计划完成 日期,并确定相应的里程碑。

进度编制基本方法

甘特图法 关键路径 法(正推法, 逆推法) 关键链法

需求调研计划

调研系统需求 绘制需求模型 编写需求规格说明书

项目资源计划

项目资源包括软件项目实施过程中的资金、人力、设备、 设施等。 项目资源是保证项目顺利而有效实施的重要保证。关系 到项目的成本、质量和进度等项目目标实现的重要条件

项目资源矩阵表

项目质量计划

是一项确定项目所要达到的质量标准以及如何 达到该质量标准的计划安排。

配置管理计划

配置管理计划的主要内容包括配置项的标识和命名规范、 配置管理环境方案、配置管理活动计划和时间表、基线 计划、发布计划等

人员配置计划

人员配置管理计划描述何时以何种方式满足项 目的人力资源需求

项目团队组建的相关问题 时间表 成员遣散安排 培训需求 表彰和奖励 合规性

风险管理计划

针对风险分析的结果,制定风险应对策略和措施的过程, 其目标是应对、减少、以至于消灭风险事件。

风险应对策略

回避风险 转移风险 缓解风险 接受风险


亲爱的读者:有时间可以点赞评论一下

点赞(0) 打赏

全部评论

还没有评论!
广告位-帮帮忙点下广告