第 9 章 软件工程
软件开发模型
相当于软件开发中的一系列开发思想，开发体系
瀑布模型（被淘汰）：
有重大的缺陷：
导致：延期，成本超支，无法继续
每一个阶段的开始都会有对上一个阶段的 "评审"工作，评审上个阶段的成果是否符合要求
结构化开发模型--------------结构化
主要问题出在需求分析层次，初期就做出需求分析，然后按照需求进行设计、编码等工作，但是初期的需求实际是不明确的，做出的软件往往会被用户推翻，这样导致再次回到需求分析这个阶段，致使项目无法结束
瀑布模型适用于：需求明确、二次开发（大部分需求已经明确）
也可以用其他的方法把需求做明确，然后用瀑布模型进行开发
失败的原因：
-
对于需求的变化无法灵活的应对
-
无法清楚把握需求
其他经典模型
快速原型模型：
适用于：需求不明确的项目
客户和开发团队有隔阂，由于知识领域的区别，无法得到有效的沟通
获取到了基本需求之后，可以做一个简易系统，向用户展示系统应有的功能，不实现具体的功能，让用户知道软件有什么功能，从而获取用户的反馈
快速原型模型适合：需求分析阶段
演化模型；
从原型模型的简易系统，逐步演化为一个成熟的软件，这样的模型叫做演化模型
增量模型：
原型模型+瀑布模型
先开发核心模块，一步一步的进行开发
核心模块比较早的和用户进行了接触，每个模块做出来了以后都与核心模块一起将软件进行了完善，如果用户有意见需要修改，在软件的开发阶段就会进行修改，而不是整个软件系统开发完成后再修改，那样相当于回到了瀑布模型
螺旋模型
融合了：瀑布模型+原型模型+演化模型等模型
因为包含了原型，所以螺旋模型也可以解决需求不明确的情况
但是如果出现了原型，优先考虑原型解决需求不明确的问题
主要区别：有风险分析
V模型
强化的测试的功能
需求分析阶段：写验收测试和系统测试的测试计划
概要设计阶段：写集成测试（考虑模块之间的衔接是否正常）
详细设计阶段：写单元测试（测试各个模块的功能）
瀑布是先做后验证，出现问题只能重新再来
V模型是边做边验证，提早发现问题
喷泉模型：面向对象的模型
面向对象的模型都有：迭代和无间隙的特性
RAD（快速开发模型）
用VB，Delphi等可视化的工具做开发，就是RAD模型开发
特点：快速构件应用系统
信息系统的开发方法
主要四种：
-
结构化法
缺点：不灵活
一旦改系统规则：需求变，设计变，编码变，测试变
原因：系统和现实有比较大的差距
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上，针对系统的改变而进行的维护
适应数据环境：数据环境发生变化，
完善性维护：在系统的运行过程中，发现很多东西发生改变，要扩充功能——增强性能
主要是指增加一些新的功能，而不是应对问题去修改
预防性维护：在发现还没有出现的错误，提前进行准备（写测试，编码），但是却没有直接
对软件进行修改，即单纯的准备工作
千年虫问题：没有考虑到跨百年的情况，很多企业提前去做了申请