第 9 章 软件工程

软件开发模型

相当于软件开发中的一系列开发思想，开发体系

瀑布模型（被淘汰）：

有重大的缺陷：

导致：延期，成本超支，无法继续

每一个阶段的开始都会有对上一个阶段的 "评审"工作，评审上个阶段的成果是否符合要求

结构化开发模型--------------结构化

主要问题出在需求分析层次，初期就做出需求分析，然后按照需求进行设计、编码等工作，但是初期的需求实际是不明确的，做出的软件往往会被用户推翻，这样导致再次回到需求分析这个阶段，致使项目无法结束

瀑布模型适用于：需求明确、二次开发（大部分需求已经明确）

也可以用其他的方法把需求做明确，然后用瀑布模型进行开发

 

 

 

 

失败的原因：

1. 对于需求的变化无法灵活的应对
2. 无法清楚把握需求

其他经典模型

快速原型模型：

适用于：需求不明确的项目

客户和开发团队有隔阂，由于知识领域的区别，无法得到有效的沟通

获取到了基本需求之后，可以做一个简易系统，向用户展示系统应有的功能，不实现具体的功能，让用户知道软件有什么功能，从而获取用户的反馈

 

 

快速原型模型适合：需求分析阶段

 

演化模型；

从原型模型的简易系统，逐步演化为一个成熟的软件，这样的模型叫做演化模型

增量模型：

原型模型+瀑布模型

先开发核心模块，一步一步的进行开发

核心模块比较早的和用户进行了接触，每个模块做出来了以后都与核心模块一起将软件进行了完善，如果用户有意见需要修改，在软件的开发阶段就会进行修改，而不是整个软件系统开发完成后再修改，那样相当于回到了瀑布模型

 

 

螺旋模型

融合了：瀑布模型+原型模型+演化模型等模型

因为包含了原型，所以螺旋模型也可以解决需求不明确的情况

但是如果出现了原型，优先考虑原型解决需求不明确的问题

 

主要区别：有风险分析

 

V模型

强化的测试的功能

需求分析阶段：写验收测试和系统测试的测试计划

概要设计阶段：写集成测试（考虑模块之间的衔接是否正常）

详细设计阶段：写单元测试（测试各个模块的功能）

 

 

瀑布是先做后验证，出现问题只能重新再来

V模型是边做边验证，提早发现问题

喷泉模型：面向对象的模型

面向对象的模型都有：迭代和无间隙的特性

RAD（快速开发模型）

用VB，Delphi等可视化的工具做开发，就是RAD模型开发

特点：快速构件应用系统

信息系统的开发方法

主要四种：

1. 结构化法

   

   缺点：不灵活

   一旦改系统规则：需求变，设计变，编码变，测试变

   原因：系统和现实有比较大的差距

2.原型法

需求分析阶段，解决需求不明确的开发

抛弃型原型+演化型原型

3.面向对象方法

优点：可复用，和显示世界结合很密切

做需求分析的时候会把设计的活给干了

4.面向服务方法

 

 

 

 

结构化设计原则

基本原则：

信息隐藏：部门与部门之间的合作，不是具体针对个人，而是通过约定好的规则（接口）进

行合作

模块独立：

内聚：模块内部的连接紧密情况

 

耦合：模块之间的连接紧密情况

扇入：被其他模块调用

 

扇出：调用其他模块

 

系统结构/模块结构

软件测试

测试原则与类型

主要出现在上午题中，有时在论文中

 

程序员会设计出一些可以通过测试的用例，并且设计的用例的范围不够全面，都是针对自己的软件设计而言的，不容易找出问题

 

默认用户的输入都是不可靠的

 

修改一个BUG有可能会引入新的BUG，所以不能立刻发布

    

桌前检查：程序员自己检查自己编写的程序

代码走查：开发人员与架构师集中讨论代码的过程

         目的：交换有关代码是如何书写的思路

 

 

 

测试用例设计

 

黑盒测试

不考虑内部结构，测试输入与输出是否对应

 

 

等价类划分：

覆盖面更加全面

 

边界值：比如90分也是及格，但是上面写x>90

 

通常将等价类划分和边界值分析结合使用

 

错误检测强调的是一种经验

EG：微软的非科班团队：妇女

 

 

 

 

 

白盒测试

针对程序结构进行测试用例的设计，针对每个分支，测试所有的分支，覆盖度高

 

条件覆盖：将组合的条件判断分开来，比判定覆盖更全面

 

白盒测试最主要的四个：语句覆盖，判定覆盖，条件覆盖，路径覆盖

测试阶段

先做单元测试后做集成测试

 

一般的项目做到确认测试就截止，但是一些集成项目还需要将所有的东西连接到一起进行系统测试

 

单元测试：

    关注是模块级的东西，测试局部功能，局部数据结构，局部接口

    完成了单元测试表示已经将模块级的东西全部测完了，保证了每个模块（函数）的内容没有问题

集成测试：

    将各个模块连接起来进行整体间的测试，测试他们的衔接有没有问题

    就是将模块进行组装

                组装的两种形式

                        1>一次性组装

                        2>增量式组装（工作量比较大）

                            2个拼起来测->4个拼起来测->8个拼起来测…….

 

上级调用模块

确认测试：

确认的判别是否按照需求开发的软件

Alpha：在开发环境去测试

beta：用户参与的测试 EG：qq的BETA版本

验收测试：用户参与，查看是不是他要求的产品

系统测试：（偏重压力、性能）

负载：不同的负载之下，软件的性能表示

    EG：并发1000与并发2000

强度：在系统发生异常/资源不是正常配置的强控下，软件是否正常

压力:在极限值的情况下，软件是否会崩溃等

 

 

冒烟测试->集成测试

    在进行相关的维护之后，会不会有明显的问题

    冒烟测试和回归测试都是在修复BUG后进行的测试，但冒烟测试更加的简单，只是初

步的进行测试

 

 

 

系统运行与维护

可维护性：

易分析性：源代码理解起来很容易，看起来很好懂

易改变性：修改这段代码的容易程度

耦合性的问题：模块之间低耦合，改变起来很容易

                模块之间耦合高，不容易改，牵一发而动全身

易测试性：

改正性维护：软件开发出来的在用户使用后才发现的BUG，这个时候去维护，修复BUG

适应性维护：软件的运行环境发生变化（不一定指跨平台）

比如：将win2008上的软件运行在winxp上，针对系统的改变而进行的维护

            

            适应数据环境：数据环境发生变化，

完善性维护：在系统的运行过程中，发现很多东西发生改变，要扩充功能——增强性能

            主要是指增加一些新的功能，而不是应对问题去修改

预防性维护：在发现还没有出现的错误，提前进行准备（写测试，编码），但是却没有直接

            对软件进行修改，即单纯的准备工作

千年虫问题：没有考虑到跨百年的情况，很多企业提前去做了申请