软件工程理论与实践
目录
一. 引言 (2)
二. 什么是软件工程 (2)
1. 什么是软件 (2)
2. 软件开发中普遍存在的问题 (3)
3. 什么是软件工程 (4)
4. 为什么要实施软件工程 (5)
三. 软件工程的基本内容 (6)
1. 软件生存期 (6)
2. 软件工程过程 (9)
3. 软件工程方法 (12)
4. 软件工程管理 (14)
四. 怎样才能开发一个成功的项目 (16)
1. 开发者的困惑 (17)
2. 什么样的软件机构才具有质量保证的可信度 (17)
3. 了解您的项目所属类型 (18)
4. 开发过程中的关键点与人员 (18)
5. 如何实现工程化的软件开发 (19)
五. 结束语 (19)
一.引言
当人类从大规模的机械与电气化生产为特征的工业社会迈入以“3C”（即Communication通信，Control控制和Computer计算机）为特征的信息社会时，人们怎么也无法预料，信息技术会给人类社会带来如此巨大的变革。当“软件”像“硬件”一样成为人们日常生活与工作不可缺少的部件时，对软件以及开发人员的需求呈爆炸式的增长。但是，一方面是计算机技术人员的紧缺，另一方面是低层次的重复开发而对宝贵人力资源的浪费；一方面是社会对软件需求的巨增，另一方面是软件生产的低效和软件危机的爆发。人们从来也没有像现在这样认识到软件工程的重要。但是，面对浩繁的工程理论，人们感到茫然无措，IT人员的高流动性使得本就难以维护的软件更是“雪上加霜”。
能否按期、按质、按费用预算开发出一个用户满意的﹑可持久维护的软件系统，是开发者最为关心的问题。个体手工化的开发方式注定要造成项目的失败，而采用工程化的原则﹑方法与管理进行软件生产才是摆脱危机﹑使得软件开发成功的唯一出路。
本篇内容从用户需求的角度展开，围绕着什么是软件工程﹑为什么要实施软件工程﹑软件工程可以为用户开发系统提供何种帮助﹑如何应用理论指导实践以及开发一个成功的项目必须注意的关键活动。
二.什么是软件工程
1.什么是软件
不能够正确地理解软件的概念，就不可能开发出高质量的软件系统。软件不仅仅是程序，软件=程序+文档+数据+规范（规程），
①规范（规程）：是开发组织为某类软件开发制定的标准与规范，越是开发
成熟度高的组织，其规范越具体越精确和量化，大多以模板﹑表格或规程
等量化的形式表示，是软件工程理论的一种具体应用和实践。
②数据：是一个软件系统正常运行所依赖的数据结构和必要的系统数据和用
户数据
③文档：是开发全过程中，按照组织规范(规程)填写的，与软件开发﹑维护
和使用有关的图文材料或文件。它是对程序必要的补充说明，是软件重要
的组成部分。
④程序：是可执行的程序﹑程序的源代码﹑必要的注释以及必要的程序资源
（如动态链接库，控件或API函数等），可理解和可测试性比程序技巧更
为重要。
软件产品必须要有一个完整的配置，程序只是软件产品的一个组成部分。
尽管人们借助硬件的概念定义了软体为软件，实际上软件具有它自己的特点。
①软件是一个逻辑实体，而不是一个具体的物理实体，看不见摸不着，只能
通过观察﹑分析﹑思考与判断去了解它，因而具有抽象性。
②软件生产与硬件不同，没有明显的制造过程，也不像硬件那样，一旦研制
成功，可以重复制造，而且硬件质量是在制造过程中进行控制的。软件的
生产实际上是高智力的开发过程，它的质量是在开发过程中进行全程控制
的，更具有复杂性和难于控制，而一旦研制成功，它的生产仅仅是复制。
③软件在运行与使用期间没有硬件那样的机械磨损和老化问题，硬件的维护
不频繁，主要在修理和更换部件上；而软件需时时维护，且更具复杂性，
软件维护具有修改的特征，本身就是一个二次开发的过程，往往使得系统
的功能加强。
④软件开发是一个高智力﹑创造性及高强度的脑力劳动，需各种人才协同工
作，管理复杂度高，甚至软件系统开发的成败七分在管理三分在技术，人
员的流动不利于开发工作，也不是一个项目组中人员与越多越好，十分强
调开发组的组织结构与人员分工与投入比例。
⑤由于软件开发至今尚未完全摆脱手工工艺的开发方式，管理技术﹑开发技
术以及相应的工具支持还很欠缺，人们软件工程应用的水平还比较低，使
得软件生产率低且质量难于保证。
⑥软件在其开发过程中，错误具有积累和放大的效应
总之，软件开发应该加强管理，重视前期的计划﹑分析与设计，坚持阶段评审，
充分采用实践中成型的工程开发模式和规范，利用工具提高工程开发效率和应
用水平，注重开发全过程的质量控制和过程控制。
2.软件开发中普遍存在的问题
问题即是难点，只有认清问题，才能避免错误从而走向成功。由于人们对软件没有清楚的认识，加之软件本身固有的特点和软件技术发展的局限，使得开发一个成功的项目很难。问题主要有以下几个方面：
●软件开发无计划性
由于缺乏软件开发的经验和有关开发数据的积累，使得开发工作的计划很难制
定，即使制定了计划，由于凭主观盲目制定，而使计划脱离实际难于实施。开
发者认识到工程化开发的必要性，但缺乏既有理论又有实践经验的人才去实
施，软件工程开发中项目经理或系统分析员档次的人才奇缺，从而使一个项目
在开发之初就缺少全局性有效的计划，这些计划包括项目开发计划﹑进度计划
﹑文档编制计划﹑经费估算与消耗计划﹑安装培训计划，质量保证计划以及过
程控制计划等
●软件需求分析困难
由于用户与开发者之间固有的沟通代沟，使得需求定义困难或不准确或不充
分，造成问题积累，而到后期难于挽回和更正。有些系统本身需求就是模糊不
清的，而且需求一直处于变动的状态。因此，如何弄清用户的需求，如何确认
需求的正确性与完备性，如何精确地表达需求规格是一个难点。需求分析是软
件开发整个过程中最关键的阶段，是项目成败的关键，必须采用必要的技术﹑
方法和工具来实现。
●软件开发过程无规范或缺乏规范
开发过程缺乏统一的﹑公认的方法论和规范指导，参加的人员各行其是。加之
不重视文档工作，使得软件难于维护，配置不完整，开发工作不规范，开发不
是一个系统的﹑集体的行为，而是依赖个体能力的大小。将软件工程浩繁的理
论变为实践中可具体操作的工程规范或规程，是许多开发组织急需解决而又缺
乏能力解决的问题。
●缺乏量化管理，没有进行开发全过程的管理和控制
开发任务的分解与量化是开发中的一个难点，没有量化的任务就没有精确的管
理。作为项目经理首要的任务就是管理，包括：开发规范的选择或制定，选择
开发的过程模型，明确开发的阶段及其成果，分解任务并合理地分配任务，明
确评审的标准，组织实施全程的过程控制﹑质量控制与配置管理。因此，对项
目经理能力与经验的要求是比较高的，同时强调开发组织内部要配有专职的各
项管理人员，并建立合理的控制机制，防患于未然。这些都是开发组织软件开
发成熟度所要求的。
●缺乏合理的人员投入，人员流动大，造成开发困难
一个项目的开发在不同阶段有不同的人力投入，并不是投入的人员越多越好，
阶段不同投入人员的层次不同，随意增加人员是不利于项目开发的。许多开发
组织并未意识到这一点，加之开发工作的个体化与IT行业人员流动大等特点，
造成开发或维护工作陷入困境。如何在人员流动的情况下保证软件开发和维护
工作的正常进行是开发中的一个难点。
●缺乏阶段成果的评审和必要的配置管理
许多开发组织没有阶段的评审制度，更缺乏评审的标准，使软件错误积累并放
大下传到后一个阶段，造成错误的集众难返。没有采取必要的配置管理，引起
版本的不一致。
●开发组织中普遍存在的错误认识
①软件开发就是编程，程序员水平的高低决定了系统开发的成败。其实对于
编程工作来说60%以上的工作是写文档，40%是写程序。需求分析的好坏
决定了系统开发的成败。
②轻视测试﹑轻视维护，认为这些人员都是无足轻重的。其实在软件开发整
个过程中，测试是质量保证最重要的一个环节，也是技术难度最大的工作。
应该委派技术水平高的非成果的责任者来完成这项工作。而维护无论在费
用消耗上﹑工作量上以及时间上都是整个过程中所占比例最大的阶段
③项目经理虽然重要，但可以不懂技术，仅仅是个管理人员而已。其实合格
的项目经理必须经历程序员到系统分析员的过程，只有这样背景的项目经
理才能合理地划分任务，并实施有效的管理。
④测试就是验证程序能正确执行其功能。其实成功的测试是发现错误的测
试，发现的错误越多则说明测试用例越好。程序测试≠软件测试，软件测
试还包括文档﹑数据与程序等完整配置的测试，而忽视了这一点往往造成
文档或数据与程序的不一致。
⑤测试与编程是同一个人，程序的任何修改没有进行回归测试，测试用例不
是软件的配置内容。
⑥软件的修改是随意的，不需要经过审批，开发人员自己就能决定。
⑦当开发任务紧张时，可通过随时追加人员来加快开发进度，保证按期完成
3.什么是软件工程
解决问题的出路在于工程化的开发，吸收硬件工程已有的经验，从系统角度考
虑问题，并采用工程化的定量方法﹑规范和工具组织软件开发工作。软件工程是指导软件开发和维护的工程学科，其核心思想是把软件产品（就像其它工业产品一样）看作是一个工程产品来处理。把需求计划﹑可行性研究﹑工程审核﹑质量监督等工程化的概念引入到软件生产中，以期达到工程项目的三个基本要素：进度﹑经费和质量的目标。软件工程也针对软件的特点研究不同于其他工业产品的一些独有特性，为软件开发提供方法﹑工具和过程的支持。有一点需要说明的是，软件工程理论与软件工程应用是软件工程研究的不同方面，需要根据不同项目的类型，摸索一套易于操作便于管理和验证的开发模式和配套工具，这是用户最为关心的。
保证网上项目开发质量的基础有如下几点：
●有多个具有实践指导意义的项目开发模式（含模板），可以根据用户项目
的类型由用户选择使用，保证用户项目按照符合ISO9001的标准进行开
发，并确保软件开发的质量
●提供自行研制的软件工作室工具，按照工程化管理的要求，协助虚拟公司
完成网上项目开发的管理工作
●提供软件工程应用指导和监督以及必要的CASE工具租赁服务
●帮助用户找到合适的开发人员和技术资源
4.为什么要实施软件工程
由于软件开发中内在的问题，造成了软件危机的局面，唯有工程化的工业生产模式才能从根本上解决危机问题，并满足信息社会对软件需求的急剧增加和高质量的要求。组织实施软件工程项目，从技术上和管理上采取了多项措施以后，最终希望得到项目的成功。成功指的是达到以下几个主要指标：
●付出较低的开发成本
●达到要求的软件功能
●取得较好的软件性能
●开发的软件易于移植
●需要较低的维护费用
●能按时完成开发计划，及时交付使用
在实际开发的具体项目中，企图让以上几个目标都达到理想的程度往往是非常困难的，而且这些目标很可能是互相冲突的或互补的，相互关系参见下图：
实际上，实施软件开发项目就是力图在以上目标的冲突中取得一定程度的平衡。
三.软件工程的基本内容
软件工程的要素有三个：方法﹑工具与过程。
软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算﹑需求分析﹑数据结构﹑总体设计，详细设计，编码﹑测试以及维护等。软件工程方法常采用特殊的语言﹑图形表达方法及一套质量保证标准。
软件工具为软件开发方法提供了自动化或半自动化的软件支撑环境（即CASE工具），这些工具支持从分析﹑设计﹑编码﹑测试到管理的方方面面的工作，提高开发的效率与质量。
软件工程过程则是将软件工程的方法与工具综合起来以达到合理﹑及时地进行计算机软件开发的目的。过程定义了方法使用的顺序﹑要求交付的文档﹑为保证质量和协调变化需要的管理﹑及软件开发各个阶段完成的里程碑。
1.软件生存期
如同其它任何事物一样，软件也具有从孕育﹑诞生﹑成长﹑成熟﹑衰亡的生存过程，称之为软件生存期。生存期将软件开发过程划分为任务相对独立的阶段，这些阶段可以因项目类型不同而有不同的划分，它们有重复，执行时也可以有迭代，开发时可由过程模型来确定，一般划分为六个阶段：
①软件计划
确定软件系统的总目标﹑开发范围﹑开发过程的阶段划分与过程模型的选择；分解任务，明确人员的角色与任务分工；确定阶段里程碑；进行资源与成本的估算；制定项目管理所需的规范与计划，包括项目开发计划﹑进度计划﹑文档编制计划﹑质量保证计划，过程追踪与控制计划。这一阶段是形成管理标准与任务的主要阶段，所制定的文档是下一步项目开发实施管理的依据和指南
②需求分析与定义
需求分析主要解决用户要“做什么”的问题。开发人员与用户碰头协商，分析其需求，然后采用无二义性的规范形式（往往套用组织内部规定的规格说明书模板）精确定义用户的需求，从而形成重要的里程碑文档——软件规格说明书。软件规格说明书需提交管理机构评审，并纳入配置管理的范围。这个阶段是软件开发成功的最关键阶段，需要富有经验的系统分析员领导完成，同时要采用一定的工程方法﹑工具和模型辅助分析工作，分析的好坏直接影响软件产品的质量。这一时期的任何错误都会给后期的工作带来巨大的影响，而且更改错误的代价将越高。
分析并精确定义用户的需求是困难与复杂的事情，一般要确定以下几个内容： 软件系统在整个系统中的边界与接口
系统业务流程，划分出相对独立的子系统，并确定其相互关系和接口
用户的功能需求
性能需求（包括相应时间﹑存储容量等）
环境需求
可靠性需求
安全保密需求
用户界面与操作需求
资源需求。它包括两个方面：数据需求
人力﹑设备与支撑软件的需求 成本消耗与开发进度需求
将来可能提出的需求。该需求为系统将来可能的扩充与修改做准备。
图形模型与文档的结合是很好的需求定义的形式，分析的技术提供了多种分析途径和表达方式，这是软件工程技术与方法研究的内容。
③软件设计
软件设计主要解决针对用户需求该“如何做”的问题，分为概要设计与详细设计。该阶段工作的基础是需求规格说明书，按照设计方法，可将需求规格一步一步转换为更详细的实现描述，包括：系统物理实现方案，软件结构以及各个模块内部算法的具体实现流程。该阶段产生重要的里程碑文档有：概要设计说明书，数据库设计说明书，详细设计说明书，测试计划等，这些阶段产品都应该提交管理部门评审，并纳入软件配置管理的范围。
④软件实现
该阶段工作的基础是详细设计说明书。程序员根据说明书中的算法过程描述，进行编程和单元测试。这些工作是开发组织比较容易做到的。但需要提醒用户的是：程序员良好的编程习惯，程序内部文档化程度以及开发组织的编程规范将直接影响程序的可理解性﹑可阅读性，最终影响软件的可维护性。因此，编程的质量标准不应该是技巧的高低，而是易于理解和维护。
⑤测试
该阶段工作的基础是软件测试计划，并将形成测试结果报告，供管理部门对软件质量进行评价，并纳入配置管理。测试是软件质量保证的最后一道关口，但绝不是唯一的质量把关措施。测试的目的也绝不是证明程序能正确执行，而是以发现错误为其根本目的。除单元测试在实现阶段完成外，测试阶段主要完成集成测试（大系统还包括子系统测试）﹑验收测试。测试中发现的问题往往是前期各阶段评审中没有发现的错误。它们之间的关系如下：
软件的错误不单单是编码错误，还包括数据和文档不一致引起的错误，据统计设计错误占软件错误的63%，编码错误仅占37%。因此，坚持阶段评审是及早发现前期错误的有效办法。
⑥运行/维护
已交付的软件投入正式使用，便进入运行/维护阶段。维护是软件整个生存期中最漫长﹑花费最大的阶段。由于软件自身的特点，维护实际上是二次开发的过程，软件开发过程中可维护性质量指标将直接影响维护的代价高低。这一时期维护工作以及所占工作量比例如下：
2.软件工程过程
把用户的需求转变成软件产品的过程叫做软件工程过程。它是将软件生存期各个阶段或活动组织成一定的工序，以获得高效的软件开发效率。软件工程过程与用户选择的开发方法及项目类型紧密相关，决定了软件开发的模式。每个开发组织都可以针对不同类型的软件项目，选取不同的工程过程，而且过程选取得是否合适直接影响软件开发的效率与质量。过程模型的选择与组织实施是需要开发经验做为基础的，是软件工程实践的难点之一。这里不详细介绍各种过程模型的特点，主要介绍有那些主要过程模型，以及如何为项目选择合适的过程。
①编码—修正模型
这是个体手工做坊式生产采用的过程模型。该模型中，开发只有两个阶段，即编写程序和修改程序。当项目拿到，几个程序员简单一商量就开始编程，然后就是调试，当调试一通过就算完成任务，并拿给用户使用。这种过程是目前许多中小型公司的开发模式，对于较小的软件尚能应付，当软件开发规模不断扩大，这种模型就会引起严重的后果，必须加以改进
②瀑布模型
这是传统的开发过程模型，将生存周期的各个阶段组成自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落呈线性图式。
该模型采用了严格而又僵化的过程工序，比较适合需求相对稳定而又便于定义、开发有较大把握的系统。而实际情况是，大部分项目的需求是易变和不确定的，各个阶段的工作要有上下几个反复才能逐步确定。因此，将僵化的过程变为灵活的过程，才能符合实际项目开发的需要。
③演化模型
这是工程实践中大量使用，且最为有效的过程模型之一，又称快速原型法。这种方法的核心思想是原型演进，即在获得用户的初步需求基础上，快速开发出一个试验性的“原型产品”（如界面原型），用户试用原型，并反馈意见，然后开发人员修改原型，经过多次反复直到获得用户满意的产品。演化模型吸收了硬件工程中“样机”的概念，比较适合需求易变且不确定的项目，它克服了瀑布模型僵化的缺点，但带来的负面效应是增大了项目开发的风险，进度难以估计。由于大量4GL语言的出现，使得构造原型快速而又方便，是建议用户选择的一种开发模式。
④螺旋模型
对于一个复杂的大型项目，开发一个原型往往达不到要求，要开发若干版本的原型并不断进行风险分析和评价才能获得最终可运行的﹑满足用户需求的原型，再在此基础上进行系统开发，螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略的风险分析，成为大型﹑高风险且复杂的系统常用的开发过程模型。这种模型虽具有优势，但用户掌握它较为困难，对于中小型项目来说一般不采用这样的方法。
⑤喷泉模型
这是采用面向对象方法开发系统的常用过程模型，其核心思想表现为阶段成果的高度复用和迭代，各阶段是连续的﹑无缝隙的而且又是相交的（无缝即是阶段间没有明显的边界）。因此，采用面向对象的开发不强调阶段的划分，各种活动可以灵活的迭代和交替。
⑥ 迭代增量式开发模型
这种方法不是在项目结束时一次性提交软件，而是分块逐次开发和提交。构造阶段由多次开发组成，每次开发都包含编码﹑测试和集成，所得产品满足项目需求的某一个子集，或提交给早期用户，或纯粹是内部提交。每次迭代都包含了软件生命期的所有阶段，即：分析﹑设计﹑实现和测试阶段。
该方法实施的过程是：先选择一些功能点，然后完成这些任务，随后再选择别的功能点，如此循环往复。初始阶段主要考虑项目范围，细化阶段进行高层分析与设计，并为构造阶段制定计划。构造过程是一系列迭代过程，每一次迭代开发都是一个小项目，要有分析到测试的全过程，完成一次迭代后应向用户演示。迭代开发在功能上是增量式的，而已有代码又会有部分修改。这种方法适于面向对象的系统开发，缺点是将风险推至测试和集成阶段
ISO9000与CMM 模型（即软件组织能力成熟度模型）是国际上公认的软件质量保证的过程及其改进标准，它们肯定了软件过程对于软件质量的影响程度，好的过程意味着高质量的软件，而且好的软件过程还意味着用低的开销来生产高质量的软件。
3. 软件工程方法
软件开发实际上是一个对问题求解的过程，从认识论角度看，整个软件开发过程可归结为两项主要活动，即认识问题及其相关的事物和基于这种认识所进行的描述。软件开发的各个阶段都存在不同层次上的认识与描述的问题。工程方法为各阶段如何认识与描述问题提供了可量化﹑有序的步骤﹑工具﹑模型及方法。开发方法有很多，常规的开发方法介绍如下：
① 功能分解法
以功能为中心来组织系统，以功能分解为主要方法，数据结构是功能设计的副产品。 这种方法软件的成分是：
软件=功能
+子功能（模块）
+功能接口
功能分解法是小型软件开发常采用的方法，对于大型项目来说，该方法常用于软件的局部设计。这种方法易于掌握，但开发的软件适应能力较差，因为一个系统中最易变动的因素是功能，其次是数据结构，最不易变的是对象。功能分解法常用的模型工具是软件结构层次图，HIPO 图等。
② 结构化方法（又称数据流法）
采用自上而下﹑逐步求精的思想，采用SA —SD —SP 三种前后衔接的不同阶段的结构方法，分别实现了从分析﹑概要设计到详细设计阶段对问题域不同程度的认识和基于认识的描述，从而将用户需求转变为计算机能够理解的程序描述。这种方法的基本观
点是：任何系统都是信息变换的系统，原始信息经过一次次的加工或变换，最后以用户需要的形式输出。该方法跟踪数据流及其变换过程，用系统流程图﹑数据流程图﹑数据字典﹑IPO图﹑软件结构图以及PAD图﹑NS图等众多的详细设计工具，辅助完成相应的工作，可用的CASE工具也非常丰富。这种方法软件的成分是：软件=数据流
+数据处理（变换）
+数据存储
+外部实体
+处理说明（用IPO图表示）
+数据字典
结构化方法是经典的开发方法，应用最为广泛，适宜于任何系统的分析与设计，而且易于掌握，是目前国内常用的开发方法。但是由于该方法以过程为中心构造系统，而用户的业务过程是最易变的部分，因此，以此开发的软件应变能力较差，维护量大而应用寿命相对较短。
③信息建模法（又称实体—关系法）
该方法以数据为中心来构造系统，功能仅仅是数据的副产品。它的核心概念是实体及其相互关系，将问题域中的事物抽象为实体，用实体间的关系映射问题域中事物之间的关系。常用的模型工具是实体关系图（又称ER图）。信息建模法普遍应用于MIS系统数据库的开发设计，对于具有明显业务过程的系统并不十分适合，以此构造的软件比结构化方法更具有一定的应变能力，维护工作易于开展。
④面向对象的方法
这是较新的开发方法，它克服了以上方法的片面性，用对象来对应问题域中的事物，用对象间的关系去刻画事物间的关系。从而使分析完整且直接地反映客观事物的结构与关系。面向对象方法最大的优势是：各阶段成果平滑而又无缝地衔接与集成（从分析﹑设计到编程），并能实现最大程度的复用，从而实现软件生产像硬件生产那样高度的部件组装目标。因此，面向对象方法是今后最盛行的开发方法，适用于任何类型的软件开发，以此开发的系统最为稳定，而且易于复用。唯一不足的是，这种方法难于掌握，是目前软件工程应用中的一个难点。
这种方法产生的软件是由一系列离散的对象构成，对象彼此独立而又相互协作，通过消息建立动态的依赖关系。成分是：
软件=对象﹑类
+结构与关系
+继承
+封装
+消息通信
面向对象方法通用的语言是UML语言，主要的模型工具有：类图（对象图）﹑UseCase﹑交互图﹑主体图﹑状态图以及辅助的图形工具。Rational公司的CASE工具是最为完备的面向对象分析﹑设计与实现工具，支持整个生存期的开发工作。除此之外，国产的PlayCASE 与青鸟工具也是相当不错的CASE产品。
⑤快速原型法
快速原型法不是一个方法学，而是一个开发过程模型，对于上面介绍的各种方法学派都可以与快速原型结合来组织项目的开发。这是工程实践中证明最为有效的一种开发模式。
⑥Jackson方法与Warnier方法
该方法的核心是将数据结构转变为程序结构，是详细设计的主要方法之一。主要采用的模型
工具是Jackson图和Warnier图。这种方法适合于数据表单的处理系统，可将表单的数据结构直接映射成程序结构。
⑦测试方法
常规测试方法有很多，基本采用的策略是：
用黑盒法设计基本测试方案，再用白盒法做必要补充
在任何情况下均采用边界值进行测试
必要时用等价类划分法补充
用错误推测法进行补充
根据软件可靠性要求，采用不同逻辑覆盖标准设计测试用例
对于程序的任何修改要进行回归测试
由于面向对象系统与面向过程系统的差异较大，它的测试方法与常规方法有很大不同，其基本内容是：以类为单位进行测试，采取先测试类间依赖度小的类，再测试依赖度大的类；先测试基类，后测试子类的逐步集成的顺序。
面向对象的测试有三种：
●类测试（类内测试）
对单个类进行测试，相当于常规方法的单元测试阶段。这个阶段需要编写一些类的驱动程序和桩程序，建立类测试的测试支撑环境。类的测试中，每个类都有其测试的顺序，合适的类测试顺序可以大大减少“桩”的编写工作量，节省测试成本。
类测试包括：
a)基于类的规格说明测试（又称静态测试）
?采用常规测试方法，按照规格说明对类的每个成员函数进行测试
?将类作为黑盒，对类界面上的公共函数进行测试，观察类的外部功能
是否满足规格要求
b)基于类的状态测试
将类中的各种成员函数组织成各种可能的调用序列进行测试，观察类的状
态变化是否有异常
●类集成测试（类间测试）
将通过类测试的单个类按照某种策略集成起来，对类间关系（包括继承关系﹑聚合关系﹑关联关系以及动态消息）进行测试。这部分的难点是确定类集成的测试顺序，基本原则是：按层次自上而下，依赖少的类先测，依赖多的类后测；基类先测，子类后测。合适的集成测试顺序会大大减少测试成本。
●回归测试
当一个类进行修改后，新的变化会波及影响到其它的类，该类以及那些受影响的类都必须进行回归测试。类的影响范围边界，称之为“防火墙”，凡是防火墙之外的类就无需进行回归测试了，而其内的则必须进行测试。
⑧进度计划
常用的方法有：甘特图法﹑PERT技术和CPM法，COCOMO模型法
其中最常用的方法是PERT技术和CPM法，它可由多种自动化工具辅助计划的制定
4.软件工程管理
管理即是对整个软件生存期的一切活动进行全过程管理，是项目成败的关键。其任务是：有效地组织人力，使用先进的技术与工具，按进度要求来完成预定的软件项目，并保证软件产品的质量。
管理人员的职能包括：制定计划﹑建立组织﹑量化任务并配备人员﹑进行全过程指导﹑监控和检验。
开发过程中要实施的管理工作有以下几个方面：
①人员组织管理
在软件工程的各个阶段，根据需要配备各种层次的技术人员和管理人员，建立分工明确而又高效的开发组织结构。开发组织结构一般有以下几种形式：
按课题划分的模式
按职能划分的模式
矩阵形模式的模式
程序设计与开发是以程序小组的形式组织的，常有的象是有三种：
主程序员制小组
民主制小组
层次式小组
常见的人员角色有：项目经理﹑系统分析员﹑高级程序员﹑程序员﹑测试工程师﹑QA 人员﹑软件配置管理人员（或文档管理员）﹑系统管理员等。各类人员参与项目开发的时间和参与程度如下：
②计划管理
管理的前提是制定有效﹑可行的计划。一个项目开发过程中主要的计划包括：
●项目开发计划
是软件开发的综合性计划，内容包括：开发过程流程、任务、进度计划、人员角色与组织、环境、资源、提交的产品、最迟交付的时间、以及项目实施中相关的计划与标准。
●质量保证计划
明确此类软件质量、度量的标准，质量检查点以及质量保证实施的流程。
●配置管理计划
明确配置管理的范围﹑组织机构与人员职责﹑配置项定义，配置管理的阶段成
果以及变更控制过程
●软件测试计划
明确测试的阶段划分、不同测试阶段的主要任务、方法、进度以及人员的职责。
●文档编制计划
明确文档编制的种类、内容、进度、审查与修改的批准手续、以及人员的职责。
●安装/培训计划
明确软件交付后实施安装与培训的目标、要求、进度、及人员职责。
当项目比较小时，可在项目开发计划中写明其它计划的内容，而不再分开撰写。
③标准化管理
制定开发组织内部的项目开发规范和标准，是高质、高效生产软件的前提，是需要在项目启动之初必须明确并培训的内容。标准制定的内容包括：
●开发过程标准
项目经理应根据项目的特点选取合适的过程模型。
●文档标准
项目类型不同，开发方法不同，文档模板也不同，管理者应确定项目所需的各
种文档模板，并强调模板对各类开发人员工作的指导作用和量化作用。
开发的标准与规范是分层次的，分为国际标准﹑国家标准﹑行业标准﹑企业内部标准以及项目组自己制定的开发规范。
④软件配置管理
包括软件版本管理和文档管理，可以采用手工或工具的方式实现。配置管理的对象是各阶段纳入配置管理且经过评审的基线产品。内容包括：
配置项变更控制与记录
文档的跟踪和受控存取
对软件配置的不断审核
⑤软件质量保证管理
建立实施全过程的质量控制机制和机构，坚持阶段性的评审与复查；制定质量指标体系和度量标准；保证按质量保证计划进行质量检查点的审查与评价；做好质量记录，以便改进过程。
⑥费用支出管理
开发过程中经费超支是许多开发组织都面临的问题，除了经费估算风险的存在，没有做好费用支出控制和阶段预算是主要的一个原因。各个时期的项目进度报告应对上一阶段的费用支出进行统计，并对下一个阶段费用支出进行估算与分配，做好费用支出控制管理。
⑦项目追踪与过程控制管理
管理人员负责进度控制；对各种计划进行任务落实与实施，并追踪其进展情况；掌握各种任务的目前执行状态，并对各类人员工作量和所分配任务的完成情况进行统计。
四.怎样才能开发一个成功的项目
这里不想具体介绍成功项目的开发过程（在下一章《项目开发模式》将详细介绍），只想指出一个成功项目的开发必须具备的条件，给用户以指导性的帮助。
1.开发者的困惑
对于开发者来说，开发一个成功的项目似乎多具有随机性。其实掌握工程开发的关键点，运用实践中经过验证的﹑成功的项目开发模式，是有把握稳操胜卷的。在开发者中存在一些困惑，主要有以下几点：
①软件是投资者的还是程序员的
②软件工程好是好，但理论太虚，以至不知如何应用
③理论与实例都能够理解，但面对一个具体问题还是不知如何下手去做
④开发的工作头绪太多，不知孰重孰轻
⑤知道管理的重要，但不知管什么﹑更不知如何量化管理
下面将回答有关问题，帮助用户解惑
2.什么样的软件机构才具有质量保证的可信度
我们观察到，许多软件机构的开发质量是相当不稳定的，项目开发的好坏依赖于个别优秀的人才。要想稳定﹑持续地保证软件高质量地完成，只能依靠建立反映有效的软件开发实践和管理实践的成熟的工程过程才能达到。
不成熟的软件机构具有的特征:
软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划。甚至有时，即使制定了计划，仍不按计划执行，或计划根本不可行。
没有一个客观的基准来判断产品的质量，产品质量难以预测。质量保证评审﹑测试等保证活动常常被削弱或被取消。产品在交付前，对用户来说，一切都是不可预见的。
软件机构是反应型的，管理人员经常要集中精力去应付危机或是难以预料的突发事件
由于计划没有实事求是地进行估计，造成超支﹑进度一拖再拖。当最后限期临近时，不得不加班加点赶进度，削减软件功能，降低软件的质量。
成熟的软件机构具有的特征:
具有全面而充分的组织和管理软件开发和维护过程的能力
软件的质量和客户对软件的满意程度不是由开发人员决定的，而是管理员按计划进行全程的质量监控和过程监控获得的
具有一套客观甚至是量化的基准来判别产品质量，并分析产品和过程的问题，以不断改进开发过程，并能防患于未然。
软件过程与开发方法相吻合，全体人员都能普遍理解并参与，而且人员职责清晰而明确，协同工作有条不紊。
软件开发过程成熟度模型:
CMM模型与ISO9000质量保证体系都是国际公认的过程改进模型，是评价软件承包机构的质量保证能力的一把标尺。它将一个开发组织的开发能力成熟度分为五个等级。
图中方框里面的内容代表相应的成熟级别的关键过程领域。每个领域都有一组相关的活动。这个模型的基本思想是：开发组织的过程成熟度是要不断地在实践中持续改进，其过程是一个演进的过程，并给出了从不成熟组织提高到成熟组织的一种结构框架。
3.了解您的项目所属类型
项目的类型多种多样，类型不同可采用的开发方法﹑过程﹑阶段性产品以及文档模板也不同。没有一种万能的开发模式可供用户套用，但可能有针对某类项目的开发模式可供用户借鉴。如果您是一个有工程经验的开发者，您可以为您的项目制定合适的开发模式；如果您是一个生手，可充分利用已有的项目开发模式指导自己的项目队伍。但无论怎样，了解您的项目类型﹑选择合适的开发模式是必须要做的事情。
4.开发过程中的关键点与人员
管理在于有效精确的计划，计划在于准确的分解与分配，准确到位的分解与分配在于管理者对任务深入的了解和丰富经验的支持。
开发过程中的关键点主要包括：
●计划的制定。强调计划对开发工作的指导作用，最重要的计划是项目开发计划
（含进度计划和文档编制计划），其次是质量保证计划
●注重项目的分析和测试，抓两头带中间，将高质量的人用于项目开发的前期与
后期
●管理高于技术，量化的管理是成功开发的前提，而模板是量化任务的最好形式，
重视模板对工作的指导作用 ●
建立质量与过程的全程可控与反馈机制，并且评价标准要尽量量化 ● 注意工程实践的积累，制定和完善开发标准﹑规范与模板，按照规范来开发系
统，并逐渐形成自己固定的开发模式
● 规范﹑模板与工具是成功项目的必要资源
●
建立高效的开发组织结构，人员配备合理，要明确管理最重要的对象是人
开发组织中关键的人员包括：
● 项目经理
项目经理是一个项目开发组织的最高领导，他（她）的经验﹑能力与知识对项目的成败产生直接的影响。一个合格的项目经理应该有着程序员﹑系统分析员的经历或知识水平，并富有项目管理的实践经验
● 系统分析员
系统分析质量的好坏是一个项目开发成败的关键。系统分析员应该具有程序员的经历﹑丰富的领域知识和系统分析实践的经验，应该善于与人沟通，对软件发展的技术有充分的了解
● 质量保证员（QA ）
QA 是一个成功项目不可缺少的角色，他（她）应该具有各角色丰富的知识与经验，能够善于发现开发过程中潜在的质量问题，并提出问题防范的措施，对各类软件应有的质量指标有明确的认识。
5. 如何实现工程化的软件开发
具体的过程可参照下一章的内容，这里大致的过程是：
① 明确项目的类型，选择合适的开发过程模式
② 制定精确合理的项目开发计划（含进度计划和文档编制计划），
将任务分解并分配到人
③ 明确阶段里程碑和相应完成的人员
④ 确定软件的质量指标和度量标准，建立质量保证计划
⑤ 按规范和成熟的过程模型实施具体的开发 五. 结束语
软件工程通过成熟的开发过程，引导开发者建立从用户问题域到软件域的映射，过程中的每一步映射都使得问题的解更进一步地细化。软件工程为开发组织提供了科学﹑量化而又客观的方法和可遵循的步骤，使得软件开发不再依赖个人水平而是取决于组织整体工程应用水平，实现了工业化的生产模式。
全程的过程控制和质量控制