软件危机是计算机软件开发和维护过程中所遇到一系列严重问题

第一篇：软件危机是计算机软件开发和维护过程中所遇到一系列严重问题

软件危机是计算机软件开发和维护过程中所遇到一系列严重问题

软件工程是指导软件开发和维护的一门学科

面向对象方法学的四个要点：面向对象方法=对象+类+继承+用消息通信

面向对象三种模型：对象模型（描述系统数据结构），动态模型（描述系统控制

结构），功能模型（描述系统功能结构）

对象模型的五个层次：主题类，类与对象层，结构层，属性层，服务层 瀑布模型：典型的文档驱动模式。喷泉模型是对象模型

系统流程图：是概括的描绘物理系统的传统工具，他的思想是用图形符号以黑

盒子形式描绘组成系统的每一个部件（程序，文档，数据库，人工

过程等）

简易的应用规格说明书：是一种面向团队的收集方法，他提倡用户与开发者密

切合作，共同标识问题，提出解决问题要素，商讨不同方案并指定

基本需求

实体联系图：描绘数据对象及之间的联系，用来建立数据模型，简称E—R图 实体联系图包含：实体（数据对象），关系和属性三大基本成分

软件工程使用的方法划分成：半形式化，形式化，非形式化

总体设计：（1）系统设计阶段（任务：确定系统具体实现方案）（2）结构设计

方案（任务：确定软件结构）

维护的四项活动：改正性维护，完善性维护，适应性维护，预防性维护

简答：

测试过程按4个步骤进行：单元测试（模块测试），集成测试（子系统和系统测

试），确认测试（验收测试），平行测试

决定软件的可维护性因素：可理解性（），可测试性（），可修改性（），可移植

性（），可重用性（）

对象模型，功能模式和动态模型三者之间的关系：（1）针对每个类建立动态模

型，描述了类实例的生命周期或运行周期（2）状态转换驱使行为

发生（3）功能模型中的处理或用例对应于对象模型中的类所提供的服务（4）数据流图中的数据存储，源点和终点，通常是对象模

型中的对象（5）数据流图中的数据流往往是对象模型中对象的属

性值，也可能是整个对象（6）用例图中的行为者，可能是对象模

型中的对象（7）功能模型中的处理可能产生动态模型中的事件（8）

对象模型描述数据流图中的数据流，数据存储，数据源地，终点的结构

第二篇：软件工程是指导计算机软件开发和维护的工程学科

软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来

开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法

结合起来，这就是软件工程。软件工程强调使用生存周期方法学和各种结构分析及结构设计

技术。它们是在七十年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户

对软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策略就是

“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略。软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长

周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。

采用软件工程方法论开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地

进行开发。前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任

务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶

段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后

一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从

技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果检查

通不过，则必须进行必要的返工，并且返工后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出“最新式的”（即和所开发的软件完全一致的）高质量的文档资料，从而

保证在软件开发工程结束时有一个完整准确的软件配置交付使用。文档是通信的工具，它们

清楚准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生存周期的下一阶段之前，必须补足这些遗漏的细节。在完成生存周期每个阶段的任

务时，应该采用适合该阶段任务特点的系统化的技术方法，结构分析或结构设计技术。把软

件生存周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分

工协作，从而降低了整个软件开发工程的困难程度；在软件生存周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性。总之，采用软件工程方法论

可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。目前划分软件生存周期

阶段的方法有许多种，软件规模、种类、开发方式、开发环境以及开发时使用的方法论都影

响软件生存周期阶段的划分。在划分软件生存周期的阶段时应该遵循的一条基本原则就是使

各阶段的任务彼此间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个

阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发工程的组织管理。一般说

来，软件生存周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进一步划分

成若干个阶段。下面的论述主要针对应用软件，对系统软件也基本适用。软件定义时期的任

务是确定软件开发工程必须完成的总目标；确定工程的可行性，导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。

这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划

分成三个阶段，即问题定义、可行性研究和需求分析。开发时期具体设计和实现在前一个时

期定义的软件，它通常由下述四个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程

中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求

时应该及时改进软件满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次

维护活动本质上都是一次压缩和简化了的定义和开发过程。下面扼要介绍软件生存周期每个

阶段的基本任务和结束标准。问题定义问题定义阶段必须回答的关键问题：“要解决的问题

是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间

和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。通过问题定义阶段的工作，系统分析员

应该提出关于问题性质、工程目标和规模的书面报告。通过对系统的实际用户和使用部门负

责人的访问调查，分析员扼要地写出他对问题的理解，并在用户和使用部门负责人的会议上

认真讨论这份书面报告，澄清含糊不精的地方，改正理解不正确的地方，最后得出一份双方

都满意的文档。问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的时间。２可行性研究。这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得

通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统

分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。可行性研究应该

比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值

得去解，是否有可行的解决办法。在问题定义阶段提出的对工程目标和规模的报告通常比较

含糊。可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基

础上更准确、更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本／效益分析是这个阶段的主要任务之一。可行性研究的结果是

使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取

得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入要

多的人力物力。及时中止不值得投资的工程项目，可以避免更大的浪费。３需求分析这个阶

段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做

什么”，主要是确定目标系统必须具备哪些功能。用户了解他们所面对的问题，知道必须做

什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问

题；软件开发人员知道怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全

清楚。因此系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用

户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。

在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须准确完整

地体现用户的要求。系统分析员通常都是计算机软件专家，技术专家一般都喜欢很快着手进

行具体设计，然而，一旦分析员开始谈论程序设计的细节，就会脱离用户，使他们不能继续

提出他们的要求和建议。较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结

束标准，需求分析阶段必须提出完整准确的系统逻辑模型，经过用户确认之后才能进入下一

个阶段，这就可以有效地防止和克服急于着手进行具体设计的倾向。４总体设计。这个阶段

必须回答的关键问题是：“概括地说，应该如何解决这个问题？”首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用计算机自动完成还是用人工完成；如果使

用计算机，那么是使用批处理方式还是人机交互方式；信息存储使用传统的文件系统还是数

据库。通常至少应该考虑下述几类可能的方案：低成本的解决方案。系统只能完成最必要的工作，不能多做一点额处的工作。中等成本的解决方案。这样的系统不仅能够很好地完成预

定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用

户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。高成本的“十全十美”的系统。这样的系统具有用户可能希望

有的所有功能和特点。系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估

计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好的系

统（最佳方案），并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。上面的工作确定了解决问题的策略以及目标系统

需要哪些程序，但是，怎样设计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的关系。

通常用层次图或结构图描绘软件的结构。５详细设计。总体设计阶段以比较抽象概括的方式

提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键

问题：“应该怎样具体地实现这个系统呢？”这个阶段的任务还不是编写程序，而是设计出

程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程

蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。通常用ＨＩＰ

Ｏ图（层次图加输入／处理／输出图）或ＰＤＬ语言（过程设计语言）描述详细设计的结果。

６编码和单元测试。这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。程

序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇

编语言），把说细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一

个模块。７综合测试。这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件

达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结

构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或

在用户积极参加下）对目标系统进行验收。必要时还可以再通过现场测试或平行运行等方法

对目标系统进一步测试检验。为了使用户能够积极参加验收测试，并且在系统投入生产性运

行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。

通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求也可以

决定测试和调试过程什么时候可以结束。应该用正式的文档资料把测试计划、详细测试方案

以及实际测试结果保存下来，做为软件配置的一个组成成分。８软件维护。维护阶段的关键

任务是，通过各种必要的维护活动使系统持久地满足用户的需要。通常有四类维护活动：改

正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适

应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出

维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试

程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析

维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软

件定义和开发的全过程。