第12章 实施与支持

第12章实施与支持本章内容先导案例概述12.1程序开发12.2质量保证12.3数据转换12.4安装12.5文档12.6培训与用户支持12.7维护和系统增强要点回顾阅读章节要求先导案例TRI-STATE HEATING OIL公司：系统开始运行时的优先次序调整概述本章着重讨论SDLC的实施与支持阶段的活动。

系统移交给用户前的一系列活动称为实施。

系统投入使用后涉及到的活动被描述为支持。

12.1 程序开发12.1.1系统实施的顺序12.1.2框架开发12.1.3基于小组的程序开发12.1.4源代码的控制12.1.5版本12.1.1 系统实施的顺序1.输入、处理、输出(IPO)的开发顺序2.自顶向下和自底向上的开发顺序3.其他开发顺序的考虑1.输入、处理、输出(IPO)开发顺序 一种程序开发顺序，先实施输入模块，再实施处理模块，最后实施输出模块。

⑴结构化的设计和编程⑵OO的设计和程序开发⑶IPO开发顺序的优点与缺点⑴结构化的设计和编程分析员可通过检查系统流程图和结构图来决定IPO的开发顺序。

工资单系统的系统流程图2013年7月23日星期二第12章实施与支持工资单系统的结构图⑵OO的设计和程序开发关键是要分析数据的相互依赖性，即某些类或方法获取或者产生的数据是另外一些类或方法所需要的数据。

类中关于数据依赖性信息来源于程序包图表。

存在于程序包(子系统)中的数据依赖性暗示了嵌入类之间的数据依赖性。

四个R M O 子系统的程序包图客户类、目录类和程序包类与RMO系统中其他类之间无数据依赖关系, 按IPO的开发顺序,应该首先实施这三部分。

⑶IPO开发顺序的优点与缺点优点：简化测试重要的用户界面在早期就已着手开发 缺点：输出部分的实现滞后2.自顶向下和自底向上的开发顺序 术语来自于结构化的设计和结构化的编程。

这两个术语描述了模块的实施顺序与其在结构图中的位臵有关。

自顶向下的开发方法：先实现结构图中的上层模块的开发顺序。

自底向上的开发方法：先实现结构图中的下层模块的开发顺序。

用于OO的设计和编程关键问题是方法的依赖性——哪些方法调用哪些其他的一些方法。

在OO的子系统或类中，方法依赖性可根据导航可见性来衡量。

一个三层O O 设计的包图 包和类之间箭头显示导航可见性需求。

可视层中方法调用域层中方法，域层中的方法接着再调用数据访问层中的方法。

自顶向下方法先实现可视层中的类和方法，然后是域层，最后实现数据访问层中类和方法。

自底向上方法实现顺序相反。

自顶向下开发的优点与缺点优点：程序总是可以运行的。

缺点：在系统构造初期不能很有效地利用程序员的人力资源。

自底向上开发方法的优点与缺点优点：许多相关程序员可立即投入开发工作。

可为开发和测试活动争取到更多时间。

缺点：要求编写大量的驱动程序来测试底层模块，给开发和测试程序添加了许多麻烦。

3.其他开发顺序的考虑用户反馈信息、培训和文档：都依赖于系统的用户界面，尽早地实施用户界面，可使开发进程中的用户培训和用户文档的编写工作早开始，而且还允许用户针对界面质量和可用性提出反馈意见。

测试：随着单个的模块或方法的实现，必须对它们进行测试。

构建和测试计划包括的细节开发顺序；测试顺序；用于测试模块、模块群、程序和子系统的数据；验收标准；人员的安排(构建和测试)。

12.1.2 框架开发构建大型OO系统时，通常是建立一个对象框架(或一系列的基类)，它包括大多数或全部的应用程序中所包含的域和数据访问层类。

基类可在系统的许多部分和不同的应用程序中被重用。

基类是系统的关键组成部分，基类中的错误将会影响到系统的每一个程序，另外，后期对基类的更改将会使整个系统发生重大变化。

基类的开发任务往往分派给最优秀的程序员，并且对于基类测试比其他类更加全面彻底。

12.1.3 基于小组的程序开发程序开发通常是一个小组的程序员一起工作。

使许多程序员同时开发系统的不同部分，可缩短开发周期。

管理上的问题：编程组如何组织；特定的小组或成员如何分派任务； 成员与小组间的交流与协作。

开发小组常用的组织模式平等合作小组：由有着大体相同技术、经验和相似专业背景的人员组成的开发小组。

(实验性或高创造性)首席开发者小组：小组只有一个领导者，所有的重大决策都由他做出。

(任务对于成员的知识和技术可行性没有限制)协作专家小组：小组成员在技术和经验方面差异很大，很少有重叠。

(实验性或高创造性)(技术跨越范围很大、适合综合问题的处理)不同类型开发小组的比较和总结小组的组织原则组织原则是开发项目和组织结构的基础。

⑴保持小组规模相对较小(不超过10人) 。

⑵组织结构应与任务和工程的性质相匹配。

12.1.4 源代码的控制源代码控制系统(SCCS)：一种自动工具，用来跟踪记录源代码文件并控制对这些文件的改动。

SCCS把工程的源代码文件存储在一个仓库中。

像图书管理员一样完成登记和检查手续，跟踪记录每个程序员拥有的文件，确保只有授权过的用户才有权访问该仓库。

SCCS禁止多个程序员同时更新同一个文件,从而防止对于源代码改动的不一致性。

12.1.5 版本为简化测试和支持工作,复杂系统的开发、安装和维护是在一系列版本中进行的。

测试版本:在开发过程中生成的系统版本。

测试版本提供一个静态的系统映像和用于评估工程进展的检查点。

版本跟踪很复杂。

每个版本都需要惟一地标识出是给用户还是给测试者。

检查点(CheckPoint)指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。

可将检查点看作是一个固定“采样”时点，而时间间隔根据项目周期长短不同而不同，频度过小会失去意义，频度过大会增加管理成本。

常见的间隔是每周一次，项目经理需要召开例会并上交周报。

各种版本α版本：一个未完成的但是已准备好了接受严格测试的系统。

(生命周期很短，通常只有几天或几星期)β版本：一个足够稳定的系统，可接受终端用户的测试。

(经过数周或数月典型测试)产品版本、发布版本或产品发布：正式对用户发布或可投入使用的系统。

维护版本：对已有功能提供纠错和较小改动的系统更新。

RMO客户支持系统的测试和产品版本的时间线RMO客户支持系统的各个版本的描述版本控制软件：控制同一个系统的多个版本的精密的软件。

SCCS中都具有所需的版本控制功能。

程序员和支持人员可选取当前的版本或任何以前的版本来执行、测试或修改，修改以后将保存成一个新的版本，这样可使历史映像保持原样。

β版本和产品版本只要被安装在用户的机器上，必须对其进行备份。

备份版本：用来测试未来的错误报告。

如，当用户报告1.0版本出错时，支持人员将从存档中调出此版本并安装，力图重现用户出过的错误，反馈给用户的信息也是针对1.0版本而言12.2 质量保证12.2.1质量保证12.2.2技术复审12.2.3测试12.2.1 质量保证质量保证(QA)：保证IS满足最低质量标准的过程。

QA包括一系列活动，贯穿整个SDLC，有利于从一开始就尽可能地检错纠错，建立一个正确系统。

分析阶段：明确系统需求中的分歧和矛盾；设计阶段：使系统满足需求，并使得设计决策正确，以实现尽可能无错的程序；实施阶段：测试。

QA(quality assurance)活动被敷衍原因 进度的压力使得各个阶段紧紧相连，在只追求速度的情况下，常忽略QA活动；QA活动要求开发人员公开其工作, 以便别人全面检查和提出批评, 很多人不情愿； 许多人认为测试人员总是带来坏消息，他们错误地认为没有消息就是好消息，而忽略测试就是避免坏消息的一种方法。

12.2.2 技术复审技术复审：一组开发人员对设计和构建细节进行正式或非正式的复审活动。

遍查：技术复审形式，它由两人或多人来审查模型或程序的正确性和完整性。

检查：一组开发人员对设计和构建细节的正式复审，每个开发者都有明确的任务。

技术复审可达到的目的可在测试前减少由5-10种因素导致的错误数量； 节约大约50％的测试开销。

技术复审可减少开发费用并缩短开发周期，因大量的错误不会延误到在编码、测试、诊断和修改阶段。

测试和技术复审都可发现50％-75％的错误，有些错误很容易被任意一种方法发现，但有些错误采用某一种方法很难被发现，而采用另外的方法则变得很容易发现，因此，两种方法结合起来比12.2.3 测试1. 软件测试2. 单元测试3. 集成测试4. 系统测试5. 谁来测试软件软件测试职业1. 软件测试测试工作贯穿于整个生命周期。

每种类型的测试计划产生于SDLC的相关阶段，一旦完成测试计划，便可以进行具体的测试。

直到系统的相关部分都已完成后，才能进行测试工作。

SDLC各个阶段之间关系以及不同类型的测试SDLC各个阶段和每个阶段可进行的测试工作测试实例与测试数据测试实例：对开始状态、软件必须响应的一个或多个事件，期望得到的响应或结束状态等内容的正式描述。

测试数据：用于测试一个或一组模块乃至整个系统的一组开始状态和事件。

2. 单元测试单元测试或模块测试：在与其他模块进行集成之前，对单一的代码模块或方法的测试活动。

单元：函数、子程序、过程或方法(术语“模块”代表这些程序结构中的任意一种)。

单元可是相联系的模块组成的较小的“组”，它们通常作为一个“组”来执行。

目的：在单个模块组成大的软件单元(如程序、类和子系统等)前，尽可能地找出并改正其中的错误。

计算工资单的部分结构图⑴驱动程序⑵存根(桩)程序⑴驱动程序一种为单元测试而开发的模块，用来模仿尚未开发的模块的调用行为。

实现的功能：为测试的函数设臵输入参数值；调用要测试的模块，并把输入参数传递给它；接收被测试模块的返回参数，并打印或显示它们。

用于测试计算工资总额模块的驱动程序模块使用驱动程序使得被调用的次级模块能够在编写调用模块之前得到测试。

驱动程序在自底向上的开发模式中得到了广泛的应用，因为在父模块开发之前，子模块(或方法)已经开发完毕并通过了单元测试。

⑵存根程序一种为了测试而开发可模仿一个尚未开发的模块的执行或行为的模块。

适于自顶向下的开发模式。

自顶向下的开发模式经常是从为程序或类中的每个模块或方法编写存根程序开始的。

随着开发过程中每个模块或方法代码的完全实现，这些代码逐渐取代模块或方法中的存根程序。

用于测试计算工资总额模块的存根程序模块3. 集成测试测试一组模块或方法的性能。

⑴目的：发现单元测试不能发现的错误。

⑵错误来源⑶结构化软件的集成测试⑷OO软件的集成测试。