swallows-锻锤
什么是软件工程
:
用来制造软件的工程
化的
方法
软件的特性
:
软件是抽象的，而不是
物理的
—
看不见摸不到
软件是极其复杂的
软件的手工开发方式、智力密集型
对计算机硬件依赖性
软件是被开发或设计的，而不是被制造的
软件不会磨损和老化，但维护困难
软件的高成本
软件危机的表现
:
?对软件开发成本
和进度的估算很不准确，甚至严重拖期和超出预算；
?无法满足用户需求，导致用户很不满意；
?质量很不可靠，经常失效；
?难以更改、调试和增强；
?没有适当的文档；
?软件成本比重上升；
?软件开发生产率跟不上计算机应用迅速深入的趋势。
什么是软件神话
,
它的危害
< br>:
软件神话
(software
myths)
：关于软件及其开发过程的一些说法被人盲目相信
?
影响到几乎所有的角色：管理者、顾客、其他非技术性的角
色、具体的技术人
员；
?
看起来是事实的合理描述
(
有时的确包含真实的
成分
)
、符合直觉，并经常被拿
来做宣
传；
?
实际上误导了管理者和技术
人员对软件开发的态度，从而引发了严重的问题；
软件工程面临的挑战有哪些
:
?
遗留系统
(Legacy system)
?
多年以前开发出来的软件，在长期使用过程中不断的被人修改；
?
日益增加的维护成本和修改困难已经成为令人头疼的问题；
?
例如：
Y2K
问题；
?
高可信软件开发
?
关注软件的正确性、可靠性、安全性、保密性；
?
以形式化方法为发展趋势，
通过保证模型的可信度来保证系统的可信度；
?
异构系统的集成与互操作
?
采用不同技术开发出来的系统，
运行在不同的硬件平台和操作系统上，
它们之间需要进行自动的数据交换；
?
更快的交付时间
?
顾客要求快速响应需求，而软件开发的周期难以有效缩短；
On demand
(
随需应变
)
?
软件开发方式的变化
? Web 2.0
、
open
source
?
基于
Internet
的协同开发模式
软件工程的范围和目标
:
?
范围：
?
软件
开发过程
(
设计、开发、运行、维护
)
?
软件开发中应遵循的原则和管理技术
?
软件开发中所采用的技术和工具
?
目标：
?
高质量
?
按时交付
?
控制成本
?
满足用户需求
软件工程的四大组成部分
:
工具、方法、过程、质量
第二章
核心概念与思想
功能性需求和非功能性需求及其特性
:
功能性需求
(Functional Requirement
s)
：
系统能够完成所期望的工作的能力
?
完备性：
软件能够支持用户所需求
的全部功能的能力；
?
正确
性：
软件按照需求正确执行任务的能力；
?
健壮性：
在异常情况下，软件能够
正常运行的能力
容错能力；
恢复能力；
——
正确
性描述软件在需求范围之内的行为，而
健壮性描述软件<
/p>
在需求范围之外的行为。
? <
/p>
可靠性：
在一定的环境下，在给定的时间内，系统不发生故障的概
率，或
者是快速从错误状态恢复到正确状态的能力。
非功能性需求
(Non-Functional Requir
ements)
：
系统能够完成所期望的工作的
性能与质量
?
性能
：
软件的
“
时间
-
空间
”
效率；
?
易用性：
用户使用软件的容易程度
，用户容易使用和学习；
?
清晰
性：
易读、易理解，可以提高团队开发效率，降低维护代价；
?
安全性：
在对合法用户提供服务的
同时，阻止未授权用户的使用；
?
可扩
展性：
软件适应
“
变化
”
的能力，系统很容易被修改从而适应新的需求
或采用
新的算法、数据结构的能力；
?
兼容
性：
不同产品相互交换信息的能力；
? <
/p>
移植性：
是软件不经修改或稍加修改就可以运行于不同软硬件环境
(CPU
、
OS
和编译器
)
的能力；
?
经济性：
开发成本、开发时间和对
市场的适应能力。
?
商业
质量：
上市时间、成本
/
受益、目标市
场、与老系统的集成、生命周
期长短等。
软件工程的
7
条原理
:
?
用分阶段的生命周期计划严格管理
?
坚持进行阶段评审
?
实行严格的产品控制
?
采用现代程序设计技术
?
结果应能清楚地审查
?
开发小组的人员应少而精
?
承认不断改进软件工程实践的必要性
软件工程的几个核心思想
:
复用
(Reuse):
?
在一个新系统中，大部分的内容是
成熟的，只有小部分内容是全新的。
?
构造新的软件系统可以不必每次从零做起；
?
直接使用已有的软构件，即可组装成新的系统；
?
复用已有的功能模块，
既可以提高开发效率，
也可以改善新开发过程中带来的
质量问题；
分而治之
(Divide and Conquer):
?
将复杂问题分解为若干可独立解决
的简单子问题，
并分别独立求解，
以降低复
杂性；
?
然后再将各子问题的解综合起来，形成最初复杂问题的解。
折中
(Trade-off):
?
不同的需求之间往往存在矛盾与冲
突，
需要通过折中来作出的合理的取舍，
找
到使双方均满意的点。
第三章
软件过程模型
理解黑盒与白盒
各种模型的优缺点及英文缩写如
RAD,
RUP
(
瀑布模型、原型模型、
RAD
）
?
瀑布模型
(waterfall model)
?
增量过程模型
(incremental process
model)
?
增量模型
(incremental model)
?
快速应用程序开发
(Rapid
App. Dev., RAD)
?
演化过程模型
(evolutionary model)
?
螺旋模型
(spiral
model )
?
原型模型
(iterative model)
?
开放源码过程
(open
source)
?
统一过程模型
(Rational Unified
Process, RUP)
?
其他过程模型
(other models)
?
形式化过程
(formal
method model)
?
软件复用过程
(component-based
reuse)
瀑布模型
(waterfall model)
?
优点：
?
简单、易懂、易用；
?
每个阶段必须提供文档，
而且要求
每个阶段的所有产品必须由
SQA
小组仔细验
< br>证。
?
缺点：
?
在开发早期，
用户难以清楚地确定所有需求
，
< br>需求的错误很难在开发后期纠正，
因此
难以快速响应用户
需求变更
；
?
这种模型几乎完全依赖规格说明文档，而
客户无法理解和阅读这些文档
，容易
导致不能满足客户需求。
?
客户必须
在项目接近尾声的时候才
能得到可执行的程序
，
对系统中存在的重大
缺陷，如果在评审之前没有被发现，
将可能会造成重大损失。
快速应用程序开发
(Rapid App. Dev.,
RAD)
?
快速应用开发
RAD (Rapid Application
Development)
?
侧重于短开发周期
(
一般为
60~90
天<
/p>
)
的增量过程模型，是瀑布模型的高速变体，
通过
基于构件的构建方法
实现快速开发；
< br>
?
多个团队并行进行开发
，
但启动时间有先后，先启动团队的提交物将作为后启
动团队的输入；
?
缺点：
?
需要大量的人力资源
来创建多个相
对独立的
RAD
团队；
?
如果
没有在短时间内为急速完成整
个系统做好准备
，
RAD
项目将会失败
；
?
如果系统不能被合理的模块化
，
RAD
将会带来很多问题；
?
技术风险很高的
情况下，不宜采用
RAD
。
原型模型
(iterative model)
?
优点：
?
节省时间和成本；
?
提高和改善客户
/
用户的参与程度；
?
缺陷：
?
为了尽快完成原型，开发者
没有考虑整体软件的质量和长期的可维护性；
?
用户可能混淆原型系统与最终系统
，
原型系统在完全满足用户需求之后可能会
被直接交
付给客户使用；
?
过长的开发时间；
?
额外的开发费用。
第四章
软件需求的作用
?
“Requirement is the Basics of Quality”
?
充分理解现实中的业务问题，并作为软件设计的基础；
?
为软件项目的成本、时间、风险估计提供准确的依据；
?
减少开发工作量，避免将时间与资源浪费在设计与实现错误
的需求上；
?
通过提供需求文档和需求基线，来有效的管理系统演化与变更；
?
作为顾客与开发团队之间正式合同的一部分；
?
为最终的验收测试提供标准和依据；
需求的分类：业务需求、用户需求、功能性需求、非功能性需求
NFR
的度量
:
? NFR(Non
-Functional Requi
rements)
：检验起来非常困难，一般采用一些可度
量的
特性进行描述。
良好的需求应具备的特性
:
?
完整性：
每一项需求都必须将所要实现的功能描述清楚
?
正确性：
每一项需求
都必须准确地陈述其要开发的功能；
?
可行性：
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施
的
?
必要性：
每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记
录
下来
?
划分优先级：
给每项需求、
特性或使用实例分配一个实施优先级
以指明它在特
定产品中所占的分量
?
无二义性：
对所有需求说明的读者都只能有一个明确统一的解释
?
可验证性：
检查一下每项需求是否能通过设计测试用例或其它的验证方法，如
用演示、检测等来
确定产品是否确实按需求实现
需求工程的总体流程：
需求获取
(Requirement
Elicitation)
需求分析
(Requirement Analysis)
需求规格说明
(Software Requirement
Specification, SRS)
需求验证
(Requirement
Verification)
需求管理
(Requirement Management)