《《开发设计过程》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《开发设计过程》PPT课件.ppt（98页珍藏版）》请在三一办公上搜索。
1、结构化程序设计方法,一个结构化程序 就是用高级语言表示的结构化算法。用三种基本结构组成的程序必然是结构化的程序，这种程序便于编写、便于阅读、便于修改和维护。结构化程序设计强调程序设计风格和程序结构的规范化，提倡清晰的结构。结构化程序设计方法的基本思路是：把一个复杂问题的求解过程 分阶段进行，每个阶段处理的问题都控制在人们容易理解和处理的范围内。,采取以下方法来保证得到结构化的程序：自顶向下；逐步细化；模块化设计；结构化编码。,两种不同的方法：自顶向下，逐步细化；自下而上，逐步积累。,用这种方法逐步分解，直到作者认为可以直接将各小段表达为文字语句为止。这种方法就叫 做“自顶向下，逐步细化”。,自
2、顶向下，逐步细化方法的优点：考虑周全，结构清晰，层次分明，作者容易写，读者容易看。如果发现某一部分中有一段内容不妥，需要修改，只需找出该部分修改有关段落即可，与其它部分无关。我们提倡用这种方法设计程序。这就是用工程的方法设计程序。,模块设计的方法：模块化设计的思想实际上是一种“分而治之”的思想，把一个大任务分为若干个子任务，每一个子任务就相对简单了。在拿到一个程序模块以后，根据程序模块的功能将它划分为若干个子模块，如果这些子模块的规模还嫌大，还再可以划分为更小的模块。这个过程采用自顶向下方法来实现。子模块一般不超过50行。划分子模块时应注意模块的独立性，即：使一个模块完成一项功能，耦合性愈少愈
3、好。,自上而下的编程方法基本步骤（1）首先对你所面临的问题进行精确描述，即你遇到的到底是什么问题；（2）定义输入输出量，即分析我们的目的是什么和现有的条件；（3）设计算法，逐层分解，逐步求精，这是做事情的一个过程，大部分人做事出错就出在这个地方，懒得到逐层分解，逐步求精，总是妄想一步登天；（4）把算法转化为程序语言，这一步是踏踏实实做的过程，没有这一步你什么也做不成。（5）检测程序，我们做的东西是否正确，不正确检测错误。这一步是需要耐心的，不要怕错误，每一次检测都会让你提高。做事时，不要因一些错误而畏缩不前。,软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)3个时期组成。软件定义时
4、期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。开发时期通常由下述4个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。维护时期的主要任务是使软件持久地满足用户的需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。,1.3 软件生命周期,软件生命周期每个阶段的基本任务。问题定义可行性研究3.需求分析总体设计详细设计编码和单元测试综合测试软件维护,第2章 可行性研究,2.1 可行性研究的任务2.2 可行性研究过程2.3 成本/效益分析,可行性研究的目的，就是用最小的代价在
5、尽可能短的时间内确定问题是否能够解决。标准：系统完成后所能带来的效益是否大到值得投资开发这个系统的程度。（资本回报）,2.1 可行性研究的任务,技术可行性 技术风险分析技术解决方案的实用性 使用的技术实用化程度 技术解决方案合理程度技术资源的可用性 参与人员的工作基础 基础硬件/软件的可用性 软件工具实用性,用户操作可行性用户类型 外行型 熟练型 专家型操作习惯使用单位的计算机使用情况使用单位的规章制度,第3章 需求分析,3.1 需求分析的任务3.2 与用户沟通获取需求的方法3.3 软件需求规格说明3.4 实体-联系图3.5 验证软件需求,通信录,问题定义：以文件的方式保存用户录入的通讯录数据
6、 供用户查询和使用通讯录信息,通信录,功能需求：记录项的基本属性：,姓名、性别、住址、联系电话、电子邮件 等,通信录,功能需求：录入：操作添加一条新的记录项,删除：删除一条已经存在的记录项,修改：改变记录项的一个或多个属性，并用新的记录项覆盖已经存在的记录项,查找：根据用户输入的属性值查找符合条件的记录项,通信录,功能需求：通讯录数据以文件形式存储在磁盘上，根据实际需要定义文件的存储格式；在程序运行中需要对文件进行读取操作。,程序中还要对输入数据的容错性进行检查，可以保证通讯录数据的合法性。,第4章 总体设计,4.1 设计过程4.2 设计原理4.3 描绘软件结构的图形工具,总体设计的基本目的就
7、是回答“概括地说，系统应该如何实现?”这个问题，因此，总体设计又称为概要设计或初步设计。总体设计阶段的另一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。,典型的总体设计过程包括下述9个步骤：设想供选择的方案选取合理的方案推荐最佳方案功能分解5.设计软件结构6.设计数据库7.制定测试计划8.书写文档(系统说明、用户手册、测试计划、详细的实现计划、数据库设计结果）9.审查和复审,4.1 设计过程,过程、函数、子程序和宏等，都可作为模块。模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以
8、完成指定的功能满足用户的需求。采用模块化原理可以使软件结构清晰，能够提高软件的可靠性和可修改性，也有助于软件开发工程的组织管理。,4.2 设计原理 4.2.1 模块化,信息隐藏原理指出：应该这样设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。局部化有助于实现信息隐藏，隐藏的不是有关模块的一切信息，而是模块的实现细节。,4.2.2 信息隐藏和局部化,开发具有独立功能而且和其他模块之间没有过多的相互作用的模块，就可以做到模块独立。换句话说，希望这样设计软件结构，使得每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系很简单。模块的独立性很
9、重要，有两条理由：第一，有效的模块化(即具有独立的模块)的软件比较容易开发出来。第二，独立的模块比较容易测试和维护。总之，模块独立是好设计的关键，而设计又是决定软件质量的关键环节。,4.2.3 模块独立,通信录的模块结构图,4.3 描绘软件结构的图形工具,通信录,功能需求：录入：操作添加一条新的记录项,删除：删除一条已经存在的记录项,修改：改变记录项的一个或多个属性，并用新的记录项覆盖已经存在的记录项,查找：根据用户输入的属性值查找符合条件的记录项,通信录,功能需求：通讯录数据以文件形式存储在磁盘上，根据实际需要定义文件的存储格式；在程序运行中需要对文件进行读取操作。,程序中还要对输入数据的容
10、错性进行检查，可以保证通讯录数据的合法性。,通信录的模块结构图,输入输出终端,输入输出模块,管理模块,文件操作模块,存储文件,用户输入,系统输出,文件写入,文件读出,4.3 描绘软件结构的图形工具,4.3.1 层次图 层次图用来描绘软件的层次结构。层次图中的一个矩形框代表一个模块，方框间的连线表示调用关系。,第5章 详细设计,5.1 结构程序设计5.2 人机界面设计5.3 过程设计的工具,结构程序设计的概念最早由提出。1966年Bohm和Jacopini证明了，只用3种基本的控制结构就能实现任何单入口单出口的程序。这3种基本的控制结构是“顺序”、“选择”和“循环”。,5.1 结构程序设计,3种
11、基本的控制结构,出于要有一种不允许违背结构程序设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图。它有下述特点：(1)不可能任意转移控制。(2)很容易确定局部和全程数据的作用域。(3)很容易表现嵌套关系，也可以表示模块的层次结构。,6.3.2 盒图(N-S图),图6.4 盒图的基本符号,PAD是问题分析图(problem analysis diagram)的英文缩写，自1973年由日本日立公司发明以后，已得到一定程度的推广。它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。,6.3.3 PAD图,图6.5 PAD图的基本符号,下面以行李
12、托运费的算法为例说明判定表的组织方法。假设某航空公司规定，乘客可以免费托运重量不超过30kg的行李。当行李重量超过30kg时，对头等舱的国内乘客超重部分每公斤收费4元，对其他舱的国内乘客超重部分每公斤收费6元，对外国乘客超重部分每公斤收费比国内乘客多一倍，对残疾乘客超重部分每公斤收费比正常乘客少一半。用判定表可以清楚地表示与上述每种条件组合相对应的计算行李费的算法，如表6.1（见书118页）所示。,用判定树表示计算行李费的算法,5.2.1 设计问题系统响应时间、用户帮助设施、出错信息处理和命令交互。1.系统响应时间一般说来，系统响应时间指从用户完成某个控制动作(例如，按回车键或点击鼠标)，到软
13、件给出预期的响应(输出信息或做动作)之间的这段时间。2.用户帮助设施设计帮助设施时要解决的问题（见下页）,5.2 人机界面设计,3.出错信息处理出错信息和警告信息，是出现问题时交互式系统给出的“坏消息”。一般说来，交互式系统给出的出错信息或警告信息，应该具有下述属性。(1)信息应该用用户可以理解的术语描述问题。(2)信息应该提供有助于从错误中恢复的建设性意见。(3)信息应该指出错误可能导致哪些负面后果。(4)信息应该伴随着听觉上或视觉上的提示。(5)信息不能带有指责色彩。,4.命令交互命令行曾经是用户和系统软件交互的最常用的方式，现在面向窗口的、点击和拾取方式的界面已经减少了用户对命令行的依赖
14、。,通讯录,界面设计：,通讯录,界面设计：,通信录,功能需求：记录项的基本属性：,姓名、性别、住址、联系电话、电子邮件 等,通讯录,数据结构设计：struct myrecordunsigned int num;unsigned int group;char nameMAXLEN+1;char gender;date birthday;char addressMAXLEN+1;char phoneMAXLEN+1;char emailMAXLEN+1;,通讯录,数据结构设计：struct mydateunsigned int year;unsigned int month;unsigned in
15、t day;typedef struct mydate date;,通讯录,数据结构设计：三个查询关键字：记录编号、组别和联系人姓名 union mysearch_entryunsigned int num;unsigned int group;char nameMAXLEN+1;typedef union mysearch_entry search_entry;,通讯录-函数设计,menu.c输入输出文件,通讯录-函数设计,menu.c输入输出文件,通讯录-函数设计,file.c文件处理文件,通讯录-函数设计,control.c控制文件,通讯录的某个模块的流程图,第6章 实现,6.1 编码6
16、.2 软件测试基础6.3 白盒测试技术6.4 黑盒测试技术6.5 调试6.6 软件可靠性,通常把编码和测试统称为实现。所谓编码就是把软件设计结果翻译成用某种程序设计语言书写的程序。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误，它是对软件规格说明、设计和编码的最后复审。通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还应该进行各种综合测试。通过测试发现错误之后还必须诊断并改正错误，这就是调试的目的。,适宜的程序设计语言能使根据设计去完成编码时困难最少，可以减少需要的程序测试量，并且可以得出
17、更容易阅读和更容易维护的程序。由于软件系统的绝大部分成本用在生命周期的测试和维护阶段，所以容易测试和容易维护是极端重要的。,6.1 编码 6.1.1 选择程序设计语言,总的说来，高级语言明显优于汇编语言，因此，除了在很特殊的应用领域，或者大型系统中执行时间非常关键的一小部分代码需要用汇编语言书写之外，其他程序应该一律用高级语言书写。高级语言应该有理想的模块化机制，以及可读性好的控制结构和数据结构；语言特点应该使编译程序能够尽可能多地发现程序中的错误；,程序设计语言的实用标准：(1)可以得到的软件工具。(2)工程规模。(3)程序员的知识。(4)软件可移植性要求。(5)软件的应用领域。,源程序代码
18、的逻辑简明清晰、易读易懂是好程序的一个重要标准。程序内部的文档,6.1.2 编码风格,源程序代码的逻辑简明清晰、易读易懂是好程序的一个重要标准。程序内部的文档 包括恰当的标志符、适当的注解和程序的视觉组织。选取含义鲜明的名字，有助于阅读者理解程序，如果用缩写，那么缩写规则应该一致，并且应该给每个名字加注解。正确的注解非常有助于对程序的理解。通常在每个模块开始处有一段序言性的注解，简要描述模块的功能、主要算法、接口特点、重要数据以及开发简史。在模块内部，对于重要语句或分支应该注解。对全局变量做注释。程序清单的布局对于程序的可读性也有很大影响，应该利用阶梯形式使程序的结构清晰明显。函数间增加空行以
19、示分隔,6.1.2 编码风格,源程序代码的逻辑简明清晰、易读易懂是好程序的一个重要标准。全局变量应该“有限制地使用全局变量”。使用全局变量过多，会降低程序的清晰性；降低函数的通用性；滥用全局变量会造成程序的混乱函 数“工欲善其事，必先利其器”。我们在编写大型程序时，要善于利用已有的函数，以减少重复编写程序段的工作量,6.1.2 编码风格,/*/*函数原型：myrecord*input_app(void);*/*参数：无*/*返 回 值：新增的记录项的地址*/*函数功能：录入信息时处理键盘输入，对输入进行合法性检查。*/*/myrecord*input_app(void)int t;char s
20、100,c;system(cls);while(1)/*输入分组*/printf(group(1-10):);scanf(%d,6.1.2 编码风格,软件测试的目的与软件工程所有其他阶段的目的都相反。在测试阶段测试人员努力设计出一系列测试方案，目的是为了竭力证明程序中有错误不能按照预定要求正确工作。,6.2 软件测试基础,测试任何产品都有两种方法：如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用；如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。前一种方法称为黑盒测试，后一种方法称为白盒测试。,6.2.1 测试方法,对于软件
21、测试而言，黑盒测试法把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。黑盒测试又称为功能测试。白盒测试法与黑盒测试法相反，它的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。白盒测试又称为结构测试。,如果一个软件是为许多客户开发的，让每个客户都进行正式的验收测试是不现实的。在这种情况下，绝大多数软件开发商都使用被称为Alpha测试和Beta测试的过程，来发现那些看起来只有最终用户才能发现的错误。,6.2.2 Alpha和Beta测试,Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题
22、。总之，Alpha测试是在受控的环境中进行的。Beta测试由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因此，Beta测试是软件在开发者不能控制的环境中的“真实”应用。,所谓测试方案包括具体的测试目的、应该输入的测试数据和预期的结果。通常又把测试数据和预期的输出结果称为测试用例。其中最困难的问题是设计测试用的输入数据。因为不可能进行穷尽的测试，选用少量“最有效的”测试数据，做到尽可能完备的测试很重要。设计测试方案的基本目标是，确定一组最可能发现某个错误或某类错误的测试数据。,6.3 白盒测试技术,有选择地执行程序中某些最有代表性的通路是对穷
23、尽测试的惟一可行的替代办法。,6.3.1 逻辑覆盖,1.语句覆盖为了暴露程序中的错误，至少每个语句应该执行一次。A=2，B=0，X=42.判定覆盖判定覆盖又叫分支覆盖，它的含义是，不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次，也就是每个判定的每个分支都至少执行一次。A=3,B=0,X=3;A=2,B=1,X=13.条件覆盖条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。A=2,B=0,X=4;A=1,B=1,X=1,A=2，B=0，X=4,语句覆盖,A=3,B=0,X=3;A=2,B=1,X=1,判定覆盖,1.语句覆
24、盖为了暴露程序中的错误，至少每个语句应该执行一次。A=2，B=0，X=42.判定覆盖判定覆盖又叫分支覆盖，它的含义是，不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次，也就是每个判定的每个分支都至少执行一次。,3.条件覆盖条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。,A=2,B=0,X=4;A=1,B=1,X=1,4.判定/条件覆盖选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。A=2,B=0,X=4;A=1,B=1,X=15.条件组合覆盖条件组合覆盖是更
25、强的逻辑覆盖标准，它要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。A=2,B=0,X=4;A=2,B=1,X=1;A=1,B=0,X=2;A=1,B=1,X=1,6.点覆盖满足点覆盖标准要求选取足够多的测试数据，使得程序执行路径至少经过流图的每个结点一次，由于流图的每个结点与一条或多条语句相对应。点覆盖标准和语句覆盖标准是相同的。7.边覆盖为了满足边覆盖的测试标准，要求选取足够多测试数据，使得程序执行路径至少经过流图中每条边一次。通常边覆盖和判定覆盖是一致的。8.路径覆盖路径覆盖的含义是，选取足够多测试数据，使程序的每条可能路径都至少执行一次(如果程序图中有环
26、，则要求每个环至少经过一次)。,黑盒测试着重测试软件功能。黑盒测试并不能取代白盒测试，它是与白盒测试互补的测试方法，它很可能发现白盒测试不易发现的其他类型的错误。黑盒测试力图发现下述类型的错误：功能不正确或遗漏了功能；界面错误；数据结构错误或外部数据库访问错误；性能错误；初始化和终止错误。,6.4 黑盒测试技术,白盒测试在测试过程的早期阶段进行，而黑盒测试主要用于测试过程的后期。设计黑盒测试方案时，应该考虑下述问题：（1）怎样测试功能的有效性？（2）哪些类型的输入可构成好测试用例？（3）怎样划定数据类的边界？（4）系统能够承受什么样的数据率和数据量？（5）数据的特定组合将对系统运行产生什么影响
27、？,应用黑盒测试技术，能够设计出满足下述标准的测试用例集：（1）所设计出的测试用例能够减少为达到合理测试所需要设计的测试用例的总数；（2）所设计出的测试用例能够告诉我们，是否存在某些类型的错误，而不是仅仅指出与特定测试相关的错误是否存在。,调试是在测试发现错误之后排除错误的过程，虽然调试应该而且可以是一个有序过程，但是，目前它在很大程度上仍然是需要技巧和经验。,6.5 调试,调试过程总会有以下两种结果之一：找到了问题的原因并把问题改正和排除掉了；没找出问题的原因。在后一种情况下，调试人员可以猜想一个原因，并设计测试用例来验证这个假设，重复此过程直至找到原因并改正了错误。,6.5.1 调试过程,
28、图7.8 调试过程,调试是软件开发过程中最艰巨的脑力劳动，调试工作之所以困难的原因如下：（1）症状和产生症状的原因可能在程序中相距甚远。（2）当改正了另一个错误之后，症状可能暂时消失了。（3）症状可能实际上并不是由错误引起的。（4）症状可能是由不易跟踪的人为错误引起的。（5）可能很难重新产生完全一样的输入条件。（6）症状可能时有时无，这种情况在硬件和软件紧密地耦合在一起的嵌入式系统中特别常见。,如果用遍了各种调试方法和调试工具却仍然找不出错误原因，则应该向同行求助。在动手改正错误之前，软件工程师应该仔细考虑下述3个问题：是否同样的错误也在程序其他地方存在？将要进行的修改可能会引入的“下一个错误
29、”是什么？为防止今后出现类似的错误，应该做什么？,1.软件可靠性的定义软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。按照IEEE的规定，术语“错误”的含义是由开发人员造成的软件差错（bug），而术语“故障”的含义是由错误引起的软件的不正确行为。,6.6 软件可靠性 6.6.1 基本概念,2.软件的可用性软件可用性的一个定义是：软件可用性是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。,第7章 维护,7.1 软件维护的定义7.2 软件维护的特点7.3 软件的可维护性,软件工程的目的是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
30、,所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。1、把诊断和改正错误的过程称为改正性维护。2、适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动。3、在使用软件的过程中为满足用户增加新功能或修改已有功能的要求而进行的维护，叫完善性维护。,7.1 软件维护的定义,上述3类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。,在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的35%40%，1980年上升为40%60%，1990年上升为70%80%。,7.2 软件维护的特点维
31、护的代价高昂,因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。其他无形的代价还有：1、当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满；2、由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量；3、当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。,（1）理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。（2）需要维护的软件往往没有合格的文档，或者文档资料显著不足。（3）当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。（4）绝大多数软件在设计时没有考虑将来的修改。（5）软件
32、维护不是一项吸引人的工作。,7.2.1 维护的问题很多,2.维护报告应该用标准化的格式表达所有软件维护要求。软件维护人员通常给用户提供空白的维护要求表有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境(包括输入数据、全部输出数据以及其他有关信息)。对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。,可以把软件的可维护性定性地定义为：维护人员理解、改正、改动或改进这个软件的难易程度。,7.3 软件的可维护性,决定软件可维护性的因素主要有下述5个：可理解性可测试性可修改性可移植性5.可重用性,7.3.1 决定软件可维护性的
33、因素,软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。,7.3.2 文档,1.用户文档(1)功能描述，说明系统能做什么；(2)安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；(3)使用手册，简要说明如何着手使用这个系统(应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复和重新启动)；(4)参考手册，详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义(对参考手册最主要的要求是完整，因此通常使用形式化的描述技术)；(5)操作员指南(如果需要有系统操作员的话)，说明操作员应该如何处理使用中出现的各种情况。,2.系统文档所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。,在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。,7.3.3 可维护性复审,
