软件工程导论 张海藩(第五版) 整理

 

              第一章,软件工程导论
一、软件工程是指导计算机软件开发和维护的一门工程学科
二、件工程的七条基本原理:
     1. 用分阶段的生命周期计划严格管理
       2. 坚持进行阶段评审
       3. 实行严格的产品控制
       4. 采用现代程序设计技术
       5. 结果应能清楚地审查
     6. 开发小组的人员应该少而精
       7. 承认不断改进软件工程实践的必要性
三、软件工程方法学包含3个要素:方法、工具和过程。
方法是完成软件开发的各项任务的技术方法,回答"怎样做"
的问题;工具是为运用方法而提供的自动的或半自动的软件
工程支撑环境;过程是为了获得高质量的软件所需要完成的
一系列任务的框架,它规定了完成各项任务的工作步骤。


四、 软件工程方法学: 传统方法学、面向对象方法学.

五、 软件生命周期:软件定义、软件开发和运行维护(也称
为软件维护)3个时期组成。
  

 1软件定义主要任务:问题定义、可行性研究和需求分析

 2开发时期主要任务:总体设计,详细设计,编码和单元
测试,综合测试(前两者为系统设计,后两者为系统实现)

 3维护时期主要任务:通过各种维护性活动使系统持久地
满足用户的需求,通常有四类维护:1,改正性维护,也就
是诊断和改正在使用过程中发现的软件错误;,2适应性维
护,即修改软件以适应环境的变化;3,完善性维护,即根
据用户的需求改进若扩充软件使它更完善,4,预防性维护,
即修改软件,为将来的维护活动预先做准备。

 
//①问题定义阶段必须回答的关键问题是:"要解决的问题
是什么?"②可行性研究~:对于上一个阶段所确定的问题
有行得能的解决办法吗?③需求分析:确定目标系统必须具
备哪些工能 ④总体设计:概括地说,应该怎样实现目标系
统?⑤详细设计:应该怎样具体地实现这个系统呢?⑥编码
和单元测试:写出正确的容易理解、容易维护的程序模块 ⑦
综合测试:通过各种类型测(及相应的调试)使软件达到预
定的要求,最基本的测试是集成测试和验收测试,集成测试
是根据设计的软件结构,把经过单元测试检验的模块按某种
选定的策略装配起来,在装配过程中对程序进行必要的测
试;验收测试则是按照规格说明的规定,由用户对目标系统
验收
 

六、 软件过程的各种模型:
1)瀑布模型(1.阶段间具有顺序行和依赖性2,推迟实
现的观点,3,质量保证的观点)

2)快速原型模型(快速建立起来的可以在计算机上运
行的程序,它所能完成的功能往往是最终产品能完成
的功能的一个子集)
 3)增量模型(把软件产品作为一系列的增量构件来设
计,编码,集成和测试。每个构件由多个相互作用的模块
构成并能完成特定的功能)
 4)螺旋模型(使用原型及其他方法来尽量降低风险,
风险驱动)
 
 5)喷泉模型
 
 
              第二章  可行性研究

一、可行性研究的任务
目的:就是用最小的代价在尽可能短的时间内确定问题是否
能够解决。


分析几种主要的可能解法的利弊,从而判断原定的系统规模
和目标是否现实,系统完成后所能带来的效益是否大到值得
投资开发这个系统的程度

二、可行性
   (1) 技术可行性  使用现有的技术能实现这个系统吗?
   (2) 经济可行性  这个系统的经济效益能超过它的开发
成本吗?
   (3) 操作可行性  系统的操作方式在这个用户组织内行
得通吗?
   (4)必要时还要从法律,社会效益等方面研究。(可选)
  
三、可行性研究过程
1. 复查系统规模和目标、2. 研究目前正在使用的系统
3. 导出新系统的高层逻辑模型、4. 进一步定义问题
5. 导出和评价供选择的解法、6. 推荐行动方针
7. 草拟开发计划、8. 书写文档提交审查

四、系统流程图:是概括地描绘物理系统的传统工具。
  
    数据流图:  描绘信息流和数据从输入移动到输出的过
程中所经受的变换。数据流图是系统逻辑功能的图形表示
 
   数据字典:数据字典是关于数据的信息的集合,也就是
对数据流图中包含的所有元素的定义的集合。

一般说来,数据字典应该由对下列4类元素的定义组成:
(1)数据流
(2)数据流分量(即数据元素)
(3)数据存储
(4)处理
       
 

          第三章    需求分析
  需求分析是软件定义时期的最后一个阶段,它的基本任务
是准确地回答"系统必须做什么"这个问题。(可选)


一、 需求分析的任务还不是确定系统怎样完成它的工作,
而仅仅是确定系统必须完成哪些工作,也就是对目标
系统提出完整、准确、清晰、具体的要求。


二、3.1.1 确定对系统的综合要求
1. 功能需求、2. 性能需求、3. 可靠性和可用性需求
4. 出错处理需求、5. 接口需求、6. 约束
7. 逆向需求、8. 将来可能提出的要求


三、3.1.2  分析系统的数据要求
   分析系统的数据要求通常采用建立数据模型的方法
3.1.3  导出系统的逻辑模型
  综合上述两项分析的结果可以导出系统的详细的逻辑模
型,通常用数据流图、实体-联系图、状态转换图、数据字
典和主要的处理算法描述这个逻辑模型。

 

四、获取需求的方法
3.2.1  访谈
3.2.2  面向数据流自顶向下求精
3.2.3  简易的应用规格说明技术
3.2.4  快速建立软件原型

 

五、3.3.1  分析建模
需求分析过程应该建立3种模型,它们分别是数据模型、功
能模型和行为模型。

3.4节将介绍的实体-联系图,描绘数据对象及数据对象之间
的关系,是用于建立数据模型的图形。
2.4节讲过的数据流图,描绘当数据在软件系统中移动时被
变换的逻辑过程,指明系统具有的变换数据的功能,因此,
数据流图是建立功能模型的基础。

3.6节将介绍的状态转换图(简称为状态图),指明了作为外
部事件结果的系统行为。为此,状态转换图描绘了系统的各
种行为模式(称为"状态")和在不同状态间转换的方式。状态
转换图是行为建模的基础。

3.4  实体-联系图(数据对象、属性、联系)
3.6  状态转换图(状态、事件、符号)
3.7  其他图形工具、3.7.1  层次方框图
3.7.2  Warnier图、3.7.3  IPO图


六、验证软件需求(可选)
(1) 一致性 所有需求必须是一致的,任何一条需求不能和
其他需求互相矛盾。
(2) 完整性 需求必须是完整的,规格说明书应该包括用户
需要的每一个功能或性能。
(3) 现实性 指定的需求应该是用现有的硬件技术和软件技
术基本上可以实现的。对硬件技术的进步可以做些预测,对
软件技术的进步则很难做出预测,只能从现有技术水平出发
判断需求的现实性。
(4) 有效性 必须证明需求是正确有效的,确实能解决用户
面对的问题。


               第4章  形式化说明技术(不考)
有穷状态机、petri网、z语言


               第5章  总体设计
1,总体设计又称为概要设计或初步设计。它的基本目的就
是回答"概况地说,系统应该如何实现?"这个问题。(可
选)

划分出组成系统的物理元素(黑盒子级)--程序、文件、
数据库、人工过程和文档等

2, 总体设计过程通常由两个主要的阶段组成:系统设计阶
段,确定系统地具体实现方案;结构设计阶段,确定软件结
构。(可选)

3、设计软件的结构
      1、确定系统中每个程序是由哪些模块组成
   2、这些模块相互间的关系
   
二、设计过程包括九个步骤:

设想供选择的方案、选取合理的方案、推荐最佳方案
功能分解、设计软件结构、 设计数据库
制定测试计划、书写文档、审查和复审

三、 设计原理:模块化、 抽象、逐步求精  信息隐藏和局
部化、模块独立


四、模块独立性的度量:
 两个定性标准度量:内聚和耦合
耦合:衡量不同模块间互相依赖(连接)的紧密程度
内聚:衡量一个模块内部各个元素彼此结合的紧密程度

五、耦合
数据耦合 (Data Coupling)(低耦合)
特征耦合
控制耦合 (Control Coupling) 
公共环境耦合(Common Coupling)
内容耦合 (Content Coupling)(高耦合)

六、设计原则
耦合是影响软件复杂程度的一个重要因素。
     尽量使用数据耦合、少用控制耦合和特征耦合,限制
公共环境耦合的范围,完全不用内容耦合。
    
七、模块内聚

八、设计原则,如果给上述7种内聚的优劣评分,将得到如
下结果:
功能内聚 10分    顺序内聚 9分
通信内聚 7分    过程内聚  5分
时间内聚 3分     逻辑内聚  1分
偶然内聚 0分  
力争做到高内聚、识别提高低内聚的模块

九、启发规则:
1. 改进软件结构提高模块独立性2. 模块规模应该适中
3. 深度、宽度、扇出和扇入都应适当4. 模块的作用域应该
在控制域之内5.力争降低模块接口的复杂程度
6. 设计单入口单出口的模块7. 模块功能应该可以预测

十、描绘软件结构的图形工具(可选)
 层次图    HIPO图    结构图
 面向数据流的设计方法:信息流的类型:变换流 、事务流
分析步骤:
第1步 复查基本系统模型、第2步 复查并精化数据流图
第3步 确定数据流图具有变换特性还是事务特性。
第4步 确定输入流和输出流的边界,从而孤立出变换中心。
第5步 完成"第一级分解"。变换型数据流图被映射成一个
输入、变换和输出的信息处理过程。
第6步 完成"第二级分解"。把数据流图中的每个处理映射
成软件结构中一个适当的模块。
第7步 使用设计度量和启发式规则对第一次分割得到的软
件结构进一步精化。


                    第6章  详细设计

6.1目标:系统的具体实现。
    6.1.1应该得出对目标系统的精确描述,从而在编码阶段可
以把这个描述直接翻译成用某种程序设计语言书写的程序。
    6.1.2结构程序设计的经典定义如下所述:"如果一个程序的
代码块仅仅通过顺序、选择和循环这3种基本控制结
构进行连接,并且每个代码块只有一个入口和一个出
口,则称这个程序是结构化的。"
    6.13 如果只允许使用顺序、IF-THEN-ELSE型分支和
DO-WHILE型循环这3种基本控制结构,则称为经典
的结构程序设计;
    6.1.4如果除了上述3种基本控制结构之外,还允许使用
DO-CASE型多分支结构和DO-UNTIL型循环结构,
则称为扩展的结构程序设计;
    6.1.5 如果再加上允许使用LEAVE(或BREAK)结构,则称为
修正的结构程序设计。


6.2   人机界面设计: 1. 系统响应时间、 2. 用户帮助设施
        3. 出错信息处理、4. 命令交互

6.3  过程设计的工具:
    程序流程图、盒图(N-S图)、 PAD图、判定表
    判定树、 过程设计语言

 

6.4 面向数据结构的设计方法:
      6.4.1 Jackson方法和Warnier方法是最著名的两个面向数据
结构的设计方法.
 使用面向数据结构的设计方法,当然首先需要分析确
定数据结构,并且用适当的工具清晰地描绘数据结构。
 Jackson方法:
       
        (1) 分析并确定输入数据和输出数据的
逻辑结构,并用Jackson图描绘这些数据结构。
 
        (2) 找出输入数据结构和输出数据结构中有对应关系
的数据单元。所谓有对应关系是指有直接的因果关系,
在程序中可以同时处理的数据单元(对于重复出现的数
据单元必须重复的次序和次数都相同才可能有对应关
系)。
 (3) 用下述3条规则从描绘数据结构的Jackson图导出
描绘程序结构的Jackson图:
        第一,为每对有对应关系
的数据单元,按照它们在数据结构图中的层次在程序
结构图的相应层次画一个处理框(注意,如果这对数据
单元在输入数据结构和输出数据结构中所处的层次不
同,则和它们对应的处理框在程序结构图中所处的层
次与它们之中在数据结构图中层次低的那个对应);
 第二,根据输入数据结构中剩余的每个数据单元所处
的层次,在程序结构图的相应层次分别为它们画上对
应的处理框;
 第三,根据输出数据结构中剩余的每个数据单元所处
的层次,在程序结构图的相应层次分别为它们画上对
应的处理框。
 在导出程序结构图的过程中,由于改进的Jackson图规
定在构成顺序结构的元素中不能有重复出现或选择出
现的元素,因此可能需要增加中间层次的处理框
 (4) 列出所有操作和条件(包括分支条件和循环结束条
件),并且把它们分配到程序结构图的适当位置。
 (5) 用伪码表示程序


6.5  程序复杂程度的定量度量: McCabe方法、Halstead方法

 


                 第7章  实现
7.1通常把编码和测试统称为实现。

7.2所谓编码就是把软件设计结果翻译成用某种程序设计
语言书写的程序。

7.3测试的目的就是在软件投入生产性运行之前,尽可能
多地发现软件中的错误。

单元测试、综合测试

7.4软件测试的目标:(1) 测试是为了发现程序中的错误而
执行程序的过程;(2) 好的测试方案是极可能发现迄今为止
尚未发现的错误的测试方案;(3) 成功的测试是发现了至今
为止尚未发现的错误的测试。
测试方法:
n 黑盒测试: 如果已经知道了产品应该具有的功能,可
以通过测试来检验是否每个功能都能正常使用;
n 白盒测试:如果知道产品的内部工作过程,可以通过
测试来检验产品内部动作是否按照规格说明书的规定
正常进行。


7.5  测试步骤:(重点)
1模块测试、2 子系统测试、3. 系统测试
4. 验收测试、5. 平行运行

7.6集成测试:
1、自顶向下集成2、自底向上集成
 
7.7 白盒测试技术   逻辑覆盖:

1. 语句覆盖2. 判定覆盖3. 条件覆盖4. 判定/条件覆盖
5. 条件组合覆盖6. 点覆盖7. 边覆盖8 . 路径覆盖

控制结构测试:
1. 基本路径测试:
第一步,根据过程设计结果画出相应的流图。
第二步,计算流图的环形复杂度。
第三步,确定线性独立路径的基本集合。
第四步,设计可强制执行基本集合中每条路径的测试用例。

 

7.8 黑盒测试技术:

等价划分、边界值分析、错误推测
软件可靠性:基本概念、估算平均无故障时间的方法
4. 估计错误总数的方法:
1) 植入错误法 2) 分别测试法
 
第8章 维护

8.1  软件维护的定义:
  软件已经交付使用之后,为了改正错误或者满足新的需
要而修改软件的过程。
  
改正性维护:在任何大型程序的使用期间,用户必然会发
现程序错误,并且把他们遇到的问题报告给维护人员。
适应性维护:也就是为了和变化了的环境适当地配合而进行
的修改软件的活动,是既必要又经常的维护活动。
完善性维护:在使用软件的过程中用户往往提出增加新功
能或修改已有功能的建议,还可能提出一般性的改进意见。
预防性维护:当为了改进未来的可维护性或可靠性,或为
了给未来的改进奠定更好的基础而修改软件

 

你可能感兴趣的:(数据结构,测试,单元测试,工具,任务,产品)