复旦MSE复习资料-软件工程部分(SE01 概论)

1、1软件工程复旦大学MSE考前辅导2021年10月 2参考书?软件工程：实践者的研究方法第6版 ?美roger s.pressman(著) ，郑人杰,马素霞,白晓颖 等(译) ，机械工业出版社，7111194004 |，2007-01-01软件工程导论第四版张海潘 编著，清华大学出版社，2003软件工程第二版齐治昌 谭庆平 宁洪著，高等教育出版社，2005实用软件工程第二版郑人杰、殷人昆、陶永雷，清华大学出版社，1997年3 计算机软件 软件生存周期 软件开发模型软件工程概论4计算机软件 计算机软件指计算机系统中的程序及其文档。 程序是计算任务的处理对象和处理规那么的描述。任何以计算机为处理工具

2、的任务都是计算任务。处理对象是数据如数据、文字、图形、图象、声音等，它们只是表示，而无含义或信息数据及有关的含义。处理规那么一般指处理的动作和步骤。程序必须装入计算机内才能工作。文档是为了便于了解程序所需的说明性资料，文档一般是给人看的，不一定装入计算机。5计算机软件 软件的特点 软件的分类6软件的特点软件是一种逻辑实体，而不是具体的物理实体，其开发本钱和进度难以估计软件的开发过程中没有明显的制造过程，一旦软件开发成功后，只须复制即可，但维护工作量大软件的运行和使用没有硬件那样的机械磨损，老化问题标准定义1 能够完成预定功能和性能的可执行指令；2 使得程序能够适当地操作信息的数据结构；3 描述

3、程序的操作和使用的文档。7各位大佬的定义Fritz Bauer曾在NATO会议上给出软件工程的定义：软件工程 是为了经济地获得能够在实际机器上高效运行的可靠软件而建立和使用的一系列好的工程化原那么。1983年，IEEEInstitute of Electrical & Electronic Engineers，电气与电子工程师协会给出了一个更为全面的定义：软件工程 是研究和应用如何以系统化的、标准的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。8软件工程的层次化软件工程是一种层次化的技术9 软件工程的层次1 软件工程必须以有组织的质量保证为根底，全面质量管理和过程改进使得更加成

4、熟的软件工程方法的不断出现。2 软件工程过程是进行一系列有组织的活动，从而能够合理地和及时地开发出计算机软件。过程定义了技术方法的采用、工程产品包括模型、文档、数据、报告、表格等的产生、里程碑的建立、质量的保证和变更的管理。3 软件工程方法为软件开发提供如何做的技术，它涵盖了工程方案、需求分析、系统设计、程序实现、测试与维护等一系列的任务。4 软件工具为过程和方法提供自动的或半自动的支持。这些软件工具被集成起来，建立起一个支持软件开发的系统，称之为计算机辅助软件工程CASE，Computer Aided Software Engineering。CASE集成了软件、硬件和一个存放开发过程信息的

5、软件工程数据库，形成了一个软件工程环境。10软件和硬件的比照与硬件相比，软件具有以下不同的特点：1 软件是逻辑的，而不是物理的产品。逻辑往往实际只存在于人的头脑当中，软件人员好比“皇帝的新衣故事中的裁缝，软件的开发过程极难加以控制。2 软件是由开发或工程化而形成的，没有明显的制造过程。软件本钱集中于“开上，意味着软件工程不能象硬件制造工程那样来管理。3软件在运行和使用期间，不存在硬件那样的磨损和老化问题，但它存在退化问题，开发人员必须维护软件。 4 大多数软件是自定的，而不是通过已有构件组装而成的。迄今为止，软件的开发尚未完全摆脱手工的方式。5 软件本钱相当昂贵。 6 软件本身是复杂的。111

6、2软件的特点软件的开发和运行常受到计算机硬件的限制，对计算机硬件有着不同程度的依赖性软件的开发至今尚未完全实现自动化软件本钱相当昂贵相当多的软件工作涉及到社会因素13软件的分类系统软件：属于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。支持软件：支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。应用软件：特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。按软件功能进行划分：14 按软件规模进行划分：类别 参加人员数 研制期限 源程序行数 微型 1 14周 0

7、.5k 小型 1 16月 1k2k中型 25 12年 5k50k大型 520 23年 50k100k甚大型 1001000 45年 1M(=1000k)极大型 20005000 510年 1M10M15 按软件工作方式划分： 实时处理软件 分时软件 交互式软件 批处理软件 按软件效劳对象的范围划分： 工程软件 产品软件 软件的分类软件的开展16软件工程的目标软件工程旨在开发满足用户需要、及时交付、不超过预算和无故障的软件，其主要目标如下：1 合理预算开发本钱，付出较低的开发费用；2 实现预期的软件功能，到达较好的软件性能，满足用户的需求；3 提高所开发软件的可维护性，降低维护费用；4 提高软件

8、开发生产率，及时交付使用。17软件危机软件危机爆发于20世纪60年代末期，虽然人们一直致力于发现解决危机的方法，但是软件危机至今依然困绕着我们，并没有一种灵丹妙药可以完全治愈这种病痛。18软件危机21 软件开发的进度难以控制，经常出现经费超预算、完成期限一再拖延的现象。1979年，美国US Government Accounting Office对政府工程进行了调查，其中9个软件工程的结果如下：19软件危机32 软件需求在开发初期不明确，导致矛盾在后期集中暴露，从而对整个开发过程带来灾难性的后果。3 由于缺乏完整标准的资料，加之软件测试不充分，从而造成软件质量低下，运行中出现大量问题。20软件

9、危机4由于认识到软件的设计、实现、维护和传统的工程规那么有相同的根底，于是北大西洋公约组织NATO于1967年首次提出了软件工程Software Engineering的概念。关于编制软件与其他工程任务类似的提法，得到了1968年在德国召开的NATO软件工程会议的认可。委员会的结论是，软件工程应使用已有的工程规那么的理论和模式，来解决所谓的软件危机。软件危机至今仍然困绕着我们，这说明软件生产过程在许多方面和传统的工程相似，但却具有独特的属性和问题。2122 计算机软件 软件生存周期 软件开发模型软件工程概论23软件生存周期 software life cycle软件有一个孕育、诞生、成长、成熟

10、、衰亡的生存过程。这个过程即为计算机软件的生存周期软件生存周期大体可分为如下几个活动：计算机系统工程、可行性分析、软件工程方案、软件需求分析、软件设计、程序编码、测试及运行维护24计算机系统工程 计算机系统包括计算机硬件、软件和使用计算机的人。计算机系统工程的任务是确定待开发软件的总体要求和范围，以及与之有关的硬件、支持软件的要求。可行性分析 从经济、技术、法律等多个方面分析待开发的软件是否有可行的解决方案，并在假设干个可行的解决方案中作出选择。软件生存周期 software life cycle25软件工程方案 确定待开发软件的目标，并对资源分配、本钱估算、进度安排等作出合理的方案。软件需求

11、分析 确定待开发软件的功能、性能、数据、界面等要求，即解决待开发软件要“做什么的问题。软件生存周期 software life cycle26软件设计 主要解决待开发软件“怎么做的问题。 软件设计通常可分为系统设计也称概要设计或总体设计和详细设计。 系统设计的任务是设计软件系统的结构，包括软件系统的组成成分、各成分的功能和接口、成分间的连接和通信，同时设计全局数据结构； 详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法等。软件生存周期 software life cycle27编码 用某种程序语言为软件编写程序。测试 发现并纠正软件中的错误和缺陷。运行和维护 在软件运行期间，

12、当发现了软件中潜藏的错误或需要增加新的功能或需将软件移植到另一运行平台等情况出现时对软件进行修改。软件生存周期 software life cycle28 计算机软件 软件生存周期 软件开发模型软件工程概论29软件开发模型软件开发模型是软件开发全部过程、活动和任务的结构框架也称软件过程模型或软件生存周期模型软件工程的主要环节3031软件开发模型典型的软件开发模型有：瀑布模型waterfall model演化模型evolutionary model增量模型incremental model螺旋模型spiral model喷泉模型water fountain model基于构件的开发模型compo

13、nent-based development modelRUP开发模型敏捷过程模型最傻瓜的方法边做边改型。就是建立一个版本 用运行状态的评估来确定 修改到用户满意为止！相当的傻瓜！3233瀑布模型可行性研究需求分析与规约设计与规约编码与单元测试集成测试系统测试运行与维护341970年提出瀑布模型特征接受上一阶段的结果作为本阶段的输入利用这一输入实施本阶段应完成的活动对本阶段的工作进行评审将本阶段的结果作为输出，传递给下一阶段缺点缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发开发早期存在的问题往往要到交付使用时才发现，维护代价大瀑布模型快速原型模型快速原型模型的第一步是建造一个快速原型，

14、实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步那么在第一步的根底上开发客户满意的软件产品。显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。 3536 软件往往难以一次开发完成，我们可以在获取了一组根本的需求后，通过快速分析，构造出该软件的一

15、个初始版本，称为原型prototype，然后根据用户在试用原型的过程中提出的反响意见和建议对原型进行改进，获得原型的新版本，重复这一过程，最终可得到令用户满意的软件产品。 演化模型采用迭代的思想，渐进地开发，逐步完成软件版本。 增量模型、螺旋模型都属于演化模型演化模型37增量模型38增量模型将软件的开发过程分成假设干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量版本，后一版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品增量模型融合了瀑布模型的根本成分重复地应用和演化模型的迭代特征增量模型强调每一个增量都发布一个可运行的产品增量模型39增量模型特别适用

16、于：需求经常变化的软件开发市场急需，而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发增量模型能有方案地管理技术风险，如早期增量版本中防止采用尚未成熟的技术增量模型40于1988年提出是瀑布模型和演化模型的结合，并增加了风险分析螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即： 制定方案：确定软件目标，选定实施方案，弄清工程开发的限制条件 风险分析：分析所选方案，考虑如何识别和消除风险 工程实施：实施软件开发 客户评估：评价开发工作，提出修正建议螺旋模型41 42优点：设计上的灵活性,可以在工程的各个阶段进行变更。 以小的分段来构建大型系统,使本钱计算变得简单容易

17、。客户始终参与每个阶段的开发,保证了工程不偏离正确方向以及工程的可控性。随着工程推进,客户始终掌握工程的最新信息 , 从而他或她能够和管理层有效地交互。缺点：采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的工程开发中，如果未能够及时标识风险，势必造成重大损失。 过多的迭代次数会增加开发本钱，延迟提交时间。 螺旋模型43喷泉模型44喷泉模型是一种支持面向对象开发的模型，是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和屡次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序

18、要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。 表达迭代和无间隙特征 迭代：各开发活动常常重复工作屡次，相关的功能在每次迭代中随之参加演进的系统 无间隙：开发活动之间不存在明显的边界喷泉模型45优点：开发人员可以同步进行开发，可以提高软件工程开发效率，节省开发时间，适应于面向对象的软件开发过程。缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于工程的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时参加各种信息、需求与资料的情况。 46支持软件复用reuse利用预先包装好的软件构件来构造应用系统基于构

19、件的开发模型融合了螺旋模型的许多特征印度做的很好基于构件的开发模型47软件构件是一个独立发布的功能局部，可以通过其接口访问它的效劳。它可以是被封装的对象类、一些功能模块、软件框架framework、设计模式Pattern等。 基于构件的开发:开发者在设计和详细描述阶段，使用内部开发的构件和公开市场的构件来为他们的应用软件提供尽可能多的功能。然后，开发者编写其它的构件来粘联代码，把构件一一连接。他们可以把新写的构件放进公司的知识库，以至于其它人就可以使用这些构件的功能。这种做法有效提高了软件重用的效率并降低了开发本钱。基于构件的开发模型优点和缺点48模型优点缺点瀑布模型文档驱动系统可能不满足客户

20、的需求快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于维护增量模型开发早期反馈及时，易于维护需要开放式体系结构，可能会设计差、效率低螺旋模型风险驱动风险分析人员需要有经验且经过充分训练49 RUP模型50RUP模型 UML过程的根本特征是：用例驱动，以架构为核心，迭代并且增量用例驱动： 用例获取系统的功能需求，它们“驱动需求分析之后的所有阶段的开发。在分析阶段，它们被用于获取所需的功能并经客户确实认。在设计和实现阶段，用例必须被实现，在测试阶段，用例用于验证系统。RUP模型RUPRational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网

21、络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。 RUP和类似的产品-例如面向对象的软件过程OOSP，以及OPEN Process都是理解性的软件工程工具-把开发中面向过程的方面例如定义的阶段，技术和实践和其他开发的组件例如文档，模型，手册以及代码等 等整合在一个统一的框架内。51AOPAOP，aspect objected programming,较好的说法是面向切面编程，按我的理解是，它能减少和系统的其他局部的耦合，是系统能更好的维护和重构，叫他切面，就

22、是说他可以在需要 它的时候将其参加到系统中，且能很好的和原系统配合，当不需要的时候就可以去除，也不会重新修改代码。在Spring开源框架中最重要的就是依赖注入和AOP了，利用它，可以让程序员能更好的管理事务和业务bean,DAO bean,用它来做系统运行日志，就是个例子。52形式化方法模型用于开发计算机系统的形式化方法是描述系统性质的基于数学的技术，这样的形式化方法提供了一个框架，可以在框架中以系统的而不是特别的方式刻划、开发和验 证系统。 如果一个方法有良好的数学根底，那么它就是形式化的，典型地以形式化规约语言给出。这个根底提供一系列精确定义的概念，如：一致性和完整性，以及定义标准 的实现

23、和正确性。 形式化方法的本质是基于数学的方法来描述目标软件系统属性的一种技术。不同的形式化方法的数学根底是不同的，有的以集合论和一阶谓词演算为根底如Z和 VDM，有的那么以时态逻辑为根底。形式化方法需要形式化规约说明语言的支持53形式化方法的分类根据说明目标软件系统的方式，形式化方法可以分为两类1面向模型的形式化方法。面向模型的方法通过构造一个数学模型来说明系统的行为。 2面向属性的形式化方法。面向属性的方法通过描述目标软件系统的各种属性来间接定义系统行为。 54根据表达能力，形式化方法可以分为五类：1基于模型的方法：通过明确定义状态和操作来建立一个系统模型使系统从一个状态转换到另一个状态。用

24、这种方法虽可以表示非功能性需求诸如时间需求，但不能很好地表示并发性。如：Z语言，VDM，B方法等。 2基于逻辑的方法：用逻辑描述系统预期的性能，包括底层规约、时序和可能性行为。采用与所选逻辑相关的公理系统证明系统具有预期的性能。用具体的编程构 造扩充逻辑从而得到一种广谱形式化方法，通过保持正确性的细化步骤集来开发系统。如：ITL区间时序逻辑，区段演算DC，hoare 逻辑，WP演算，模态逻辑，时序逻辑，TAM时序代理模型，RTTL实时时序逻辑等。 3代数方法：通过将未定义状态下不同的操作行为相联系，给出操作的显式定义。与基于模型的方法相同的是，没有给出并发的显式表示。如：OBJ， Larch族

25、代数规约语言等； 4过程代数方法：通过限制所有容许的可观察的过程间通信来表示系统行为。此类方法允许并发过程的显式表示。如：通信顺序过程CSP，通信系统演算 CCS，通信过程代数ACP，时序排序规约语言LOTOS，计时CSP(TCSP，通信系统计时可能性演算TPCCS等。 5基于网络的方法：由于图形化表示法易于理解，而且非专业人员能够使用，因此是一种通用的系统确定表示法。该方法采用具有形式语义的图形语言，为系统开发和再工程带来特殊的好处。如 Petri图，计时Petri图，状态图等。达能力，形式化方法可以分为五类5556以体系结构为中心： 首先定义一个根底的体系结构，然后将它原型化并加以评估，最

26、后进行精化。体系结构给出系统的映象，它定义系统的不同局部、它们的关系和交互，它们的通信机制以及关于如何增加或修改体系结构中的成分的全部规那么。体系结构涉及到功能性和非功能性两个方面，要定义一个易修改、易理解和允许复用的系统。57迭代： 用UML建模最好经过假设干次较小的迭代，不要试图一次就定义模型或图的所有细节，开发是逐步进行的，每次迭代增加一些新的信息和细节。每次迭代都要对前次的结果评价，并用于下一次迭代的输入。迭代的过程提供连续的反响，这些反响不仅改善了最终的产品，而且改善了过程本身。 在决定每一次迭代应做什么时，要考虑这次迭代对系统的最大影响或最高风险。考虑最大影响的迭代意味着使系统能尽

27、早提交给用户，考虑最高风险的迭代意味着尽早处理工程中的难点，以降低工程的风险。 58增量 ：增量开发是在屡次迭代的过程中每次增加一些功能或用例的开发，每次迭代都包含分析、设计、实现、测试等阶段，通过假设干次增量开发完成整个系统的开发，这样的开发过程分解了开发的风险，不至于把风险留到开发的后期。每次迭代集中在几个功能或用例的开发上，如发现问题，其错误往往比较小，相应的风险也小，修改也相对容易。 59敏捷联盟：敏捷软件开发宣言2001个体和交互胜过过程和工具；可工作软件胜过宽泛的文档；客户合作胜过合同谈判；响应变化胜过遵循方案。敏捷建模60我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客

28、户。 欢送对需求提出变更即使是在工程开发后期。要善于利用需求变更，帮助客户获得竞争优势。 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 工程过程中，业务人员与开发人员必须在一起工作。 要善于鼓励工程人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 敏捷宣言背后的12条原那么61可用的软件是衡量进度的主要指标。 敏捷过程提倡可持续的开发。工程方、开发人员和用户应该能够保持恒久稳定的进展速度。 对技术的精益求精以及对设计的不断完善将提升敏捷性。 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 最正确的架构、

29、需求和设计出自于自组织的团队。 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。 敏捷宣言背后的12条原那么62极限编程Extreme Programming，XP( P57图4-1，生命周期：筹划、设计、编码、测试。XP原那么：现场客户、简单设计、测试驱动、结对编程、代码全体拥有、持续集成、小型发布自适应软件开发Adaptive Software Development,ASD)(P61,图4-2，生命周期：思考、协作、学习动态系统开发方法Dynamic SystemDevelopment Method，DSDM敏捷过程模型63动态系统开发方法Dynamic SystemDevel

30、opment Method，DSDM：使用迭代软件过程，每一个迭代都遵循80%原那么如果交付整个系统需用100%时间，那么80%的应用系统可以用20%的时间交付。DSDM生命周期的敏捷过程模型：可行性研究业务研究功能模型迭代设计和构建迭代实现敏捷过程模型64Scrum敏捷过程模型P63图4-3原那么(和敏捷宣言一致：组织小型团队以到达：沟通最大化，负担最小化，非语言描述、非形式化知识。过程对技术和业务变化必须具有适应性，以“保证制造具有最好可能的产品。过程生产频繁发布“可检查、可调整、可测试、可文档化、可构建的软件增量。开发工作和开发人员划分为“清晰的、低耦合的局部或包。坚持在产品构建过程中进

31、行测试和文档化。Scrum过程提供“在任何需要的情况下都能完成产品的能力。敏捷过程模型65特征驱动开发Feature Drive Developmeng,FDDP65图4-4特征-是可以在2周或者更短时间实现的具有客户价值的功能。FDD更加强调工程管理原那么和技术。在特征设计和构建阶段定义6个里程碑：设计走查，设计，设计检查，编码，代码检查，促进构建敏捷过程模型软件神话什么都是浮云不要用机械工程的概念来套用6667观点之一我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。 客观事实好的参考书无疑能指导我们的工作，充分利用书籍中的方法、技术和技巧

32、，可以有效地解决软件开发中大量常见的问题。但实践者并不能依赖于书籍，因为在现实工作中，由于条件千差万别，即使是相当成熟的软件工程规范，常常也无法套用。另外，软件技术日新月异，没有哪一种软件标准能长盛不衰。观点之二如果我们已经落后于计划，可以增加更多的程序员来赶上进度。客观事实软件开发不同于传统的机械制造，人多不见得力量大。如果给落后于计划的项目增添新人，可能会更加延误项目。因为新人会产生很多新的错误，使项目混乱，并且原有的开发人员向新人解释工作和交流思想都要花费时间，使实际的开发时间更少，所以制定恰如其分的项目计划是很重要的。【讲解】假设一个项目估计需要12人月工作量，指定由3个人在4个月内完

33、成，如果第一个月的任务花了两个月才完成，那么增加人力的结果如何？假设增加2个人参加项目，不论新增加的人适应能力有多强，总需要有人去帮助了解熟悉情况，如果这些工作占用了一个月的时间，这样又有3个人月工作量在新计划之外。由于人员增加，工作任务需要重新划分，到第3个月结束时虽然有5个人在工作，实际上余留下7个人的工作量。观点之三项目需求总是在不断变化，但这些变化能够很容易地满足，因为软件是灵活的。客观事实软件需求确实是经常变化的，但这些变化产生的影响会随着其引入时间的不同而不同。对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代价越少，

34、修改越晚代价越大，就跟治病一样道理。 观点之四有了对目标的一般描述就足以开始写程序了，我们以后可以再补充细节。客观事实不完善的系统定义是软件项目失败的主要原因。关于待开发软件的应用领域、功能、性能、接口、设计约束和标准等需要详细的描述，而这些只有通过用户和开发人员之间的通信交流才能确定。越早开始写程序，就要花越长时间才能完成它。观点之五一旦我们写出了程序并使其正常运行，我们的工作就结束了。人们有时认为，只有差的软件产品才需要维护。客观事实从如图1.12所示的统计数据来看，软件投入的50%70%是花费在交付给用户之后。品质差的产品被丢弃，只有好的产品才需要维护和改进。观点之六一个成功的项目唯一应

35、该提交的就是运行程序。客观事实软件包括程序、数据和文档，其中文档是成功开发的基础，为软件维护提供了指导。 帮助回忆观点一：开放软件源代码就一定好。 观点二：软件质量问题可通过软件测试得到彻底解决。68观点一一般人都认为开放源代码对一个软件系统的完善有很好的促进作用，因为这样可以集合很多人的智慧，但这种观点并不完全正确。大家赞同开放源码，其实很大程度上是因为先有了Linux成功的例子，而Linux的出现和成功是有它一定的背景的，很大程度上是因为不支持源码开放的代表-微软的缘故。开放源代码对促进全球软件和信息技术行业的快速开展是很有益处的，但是关于源代码的GPL授权方式目前还看不到它对软件企业开展的好处。一味强调过度开放源代码，在现在盗版泛滥的时代，拥有源代码的公司如何得到回报，没有回报就没有进一步研发资金，软件的开展从何而来。 69观点二为了克服软件危机和提高软件质量，人们进行了大量的研究和实践。最初的重点是着眼于技术革新，从各种软件工具如编辑、编译、调试工具等等研制开始，开展成为对开发各阶段进行全面支持的计算机辅助软件工程CASE环境。同时，注重软件开发模型研究，也就是如何划分软件开