软件工程专题作业.doc

软件工程专题作业 专业：计算机软件与理论 学号：1.总结并论述软件生存周期七个阶段各自的任务及要达到的目标。软件的生存周期是指一个软件从提出开发要求到软件报废所经历的整个时期。通过将整个生存周期划分为若干阶段，使得每个阶段均有明确的任务，我们可以把规模庞大、结构复杂、管理困难的软件开发变得容易控制和管理。软件的生存周期的基本划分原则是：各阶段的任务尽可能相对独立，同一阶段各项任务的性质尽可能相同。从而降低每个阶段任务的复杂程度，简化各阶段之间的联系，有利于软件开发的组织与管理。根据以上原则，软件生存周期可划分为可行性研究与项目开发计划、需求分析、概要设计和详细设计、编码、测试、维护七个阶段。下面详细叙述七个阶段各自的任务及要达到的目标。（1） 可行性研究和项目开发计划可行性研究与项目开发计划在立项报告批准之后进行，该阶段需要回答：“要解决的问题是什么？有哪几种解决方案？需要多少费用？需要多少资源？需要多少时间？”等问题。其目的就是用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得去开发，其中的问题是否能解决，避免造成时间、人力、资源和经费的巨大浪费。在这个阶段中，可行性分析要依靠项目开发计划提供依据，而项目开发计划只有在初步得到可行性研究后才能再深入制定，两个活动可以说是互相制约，互相促进的关系。同时在这个阶段中对要解决的问题定义十分重要，要注意和各方多沟通，得到尽可能准确的问题定义，再和各方再次沟通看看各方的理解是否相同，一般对问题的精确定义和理解在项目开发计划里解决比在需求分析阶段决解更合理，也可以更符合各方利益的要求，同时不会对软件开发方向造成隐患，亦不会给双方就软件开发报酬的商议造成不必要的麻烦。在用户提出一个软件开发要求后，系统分析员要对此用户的机构进行了解，明确它是一个什么样的机构，它的作用是什么，这有利于分析所开发的项目的原由，同时对使用此软件的最终部门要进行一系列的观察研究，组织开会讨论，通过这一系列工作就可以确定软件项目的性质、目标和规模，可行性研究实质上是要进行一次简化、压缩了的需求分析和设计过程，是要在较高层次上以较抽象的方式进行需求分析和设计过程。如果可行性研究的结果是可行的，接下来的任务就是制定详细的项目开发计划，项目开发计划主要根据所开发的项目的目标、性能、功能、规模来确定所需的资源，主要包括三个方面，即硬件资源（C）、软件资源和人力资源，除此之外还有对项目的开发费用，开发进度做出估计，可供决策者和用户参考。 至此，本阶段的工作任务已基本完成，这时候系统分析员应将可行性报告和项目开发计划一并提交管理部门审查。（2） 需求分析需求分析是在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。也即在开发者和使用者之间架起一座桥梁，让开发者最准确的知道“用户要的是什么”。需求分析阶段必须要准确地回答：软件系统必须做什么。即确定软件系统必须具备的功能和要达到的性能，并编写出详细的需求，包括所有面向用户、面向机器和其他软件系统的接口。需求分析的基本任务就是准确的定义新系统的目标，也就是将要实现的系统是个什么样的系统，要“做什么”的，达到什么样的要求，并确定开发软件的功能、性能、数据、界面等的要求。(1)必须能够表达和理解问题的数据域和功能域。数据域包括数据流（既数据通过一个系统时的变化方式）、数据内容和数据结构，而功能域反映上述三方面的控制信息。(2)可以把一个复杂问题按功能进行分解并可逐层细化。通常软件要处理的问题如果太大太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体功能。(3)建模。模型可以帮助分析人员更好地理解软件系统的信息、功能和行为，这些模型也是软件设计的基础。需求分析阶段的基本任务具体如下： I：问题识别（1） 功能需求（2） 性能需求 （3） 环境需求 （4） 用户界面需求 另外对软件各个部分和性能指标也要有一个明确的需求定义，如安全性、可靠性、可维护性、可移植性等等都要通过双方的共同讨论、研究，力求达到一个双方都可理解接受的指标。II：分析与综合，导出软件的逻辑模型 对于需求分析实际调研中所得到的信息，综合分析和理解，在此基础上通过规范的需求分析工具导出成为一个开发人员能够理解的软件逻辑模型。III：编写文档 （1） 编写“需求规格说明书”，把双方共同理解和分析得到的结果以规范的方式描述出来，作为今后工作的基础。 （2） 编写初步用户使用手册，根据需求规格说明书编写初步的用户使用手册，一来可以更进一步的说明问题，二来可以强制系统分析员站在需求者的角度考虑软件。 （3） 编写确认测试计划，作为软件验收时的依据。 （4） 修改项目开发计划文档，此时对要开发的软件有了更进一步清晰的了解，应对原来的开发计划做一些适当的修改。该阶段要形成软件合同的实质性内容。最终形成文档有：软件需求说明书、用户手册。需求分析过程中产生的文档还有用户需求说明书，产品需求说明书，需求评审报告，需求跟踪报告，需求变更控制报告。软件设计是一个把软件需求转换为软件表示的过程。最初这种表示只是描述了软件的总的体系结构，称为软件概要设计或结构设计。然后对结构进一步细化，称为详细设计或过程设计。（3） 概要设计概要设计阶段通常在软件开发程序中排在需求分析后面，因为它的结构设计是直接对应需求分析里的功能说明的，在这个阶段，要的依然不是编写代码，而是实现需求功能的软件结构，软件结构是以模块来组成的，所以这个阶段要做的就是把需求分析里所说明的软件功能转换成需求的体系结构，用模块的形式描述出来，在该体系结构中，每个模块都有明确的意义和功能。概要设计阶段的任务是分析与设计软件的体系结构，通过系统分解，确定子系统的功能和子系统之间的关系，子系统由哪些模块组成，这些模块的层次结构是怎样的，之间的调用关系如何，每个模块的功能是什么？将软件需求转化为数据结构和软件的系统结构，设计模块并确立模块之间的关系，另外还要设计目标系统的总体数据结构和数据库结构。概要设计的基本任务： 1、 设计软件系统的逻辑结构。(1) 采用某种设计方法，将一个复杂的软件系统按功能划分成许多有关系条理的模块。 (2) 准确定义每个模块的功能。 (3) 确定模块之间的调用关系。 (4) 对每个模块确定其接口（要以文档对接口的数量，顺序，作用，属性等进行详细说明，这很重要）。 (5) 对所设计的模块进行评估，尽量找出错误和不合理的地方，进行改正（这比软件做出来后的修改要容易得多）。软件结构的设计是非常重要的工作，它直接影响以后的详细设计和编码，不合理的结构将有可能把未完成的系统埋葬，所以应选用能力强和经验比较丰富的程序员来做。 2、 设计软件所需要的数据库系统一个好的软件一般都有一个专门为其设计的数据库系统，数据库的设计已自成理论体系，一般数据库的设计工作可分为数据结构设计和数据库设计，数据库设计还分为概念设计、逻辑设计和物理设计。3、 编写概要设计文档软件工程很强调文档的作用，概要设计也一样，要做好这阶段应有的文档才算是基本完成任务，对文档的编写主要是概要设计和数据库设计说明书，另外还有对需求分析阶段的用户手册和测试计划进行必要的修改，以更合理的对应所设计的软件系统。4、 评审这主要是对这阶段工作的一次回顾，看看有什么遗漏或错误的地方没有。评审也有很多不同的技术性手段，可一般都将重点放在功能、性能、可行性、接口正确性等方面。概要设计阶段形成文档：概要设计说明书、数据库设计说明书等。（4） 详细设计详细设计阶段就是对概要设计里所划分出来的模块要实现的功能用相应的设计工具详细的描述出实现步骤来，也即是写出代码的算法。在详细设计里所有的表述无论是语言或是图表，都应做到有精确的唯一解释，绝不允许出现有“二义性”或“多义性”的表述，所谓精确的表述就是要做到无论这份文档到了那个程序员手中，他都能看得懂文档的含意而且只有一个含意，不可能再解读出第二层意思来。详细设计的任务就是为每个模块所要完成的功能进行具体而精确的描述，要根据功能描述再转化成精确的、结构化的软件过程描述，即该模块的控制结构是怎样的，先做什么、后做什么，由什么样的条件判定，有什么重复处理等，并用相应的表示工具（比如程序流程图等）把这些控制结构表示出来。软件过程描述一般可直接对应到相应的代码，也就是以后程序员会根据这些过程描述来编写程序代码。此阶段的具体任务如下：(1)为每个模块进行详细的算法设计。这是需要用相应的工具来完成的，因为自然语言通常很容易具有“二义性”，而工具能做到含义唯一性。(2)为模块内的数据结构进行设计。(3)对数据库进行物理设计。注意这不是实现数据库，而是设计出数据库的具体物理结构。(4)其它设计（前期特殊代码设计、I/O格式设计、界面友好设计等）。(5)编写详细设计说明书。(6)评审。该阶段形成文档：详细设计说明书。（5） 编码编码阶段的任务是程序员根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言(必要时用汇编语言)，把详细设计的结果、每个模块的控制结构翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。编写代码时要做到高度对应在详细设计里所描述的算法，因为以后的“除虫”或升级等，很多时候都是以详细设计的文档资料为根据的，如代码和详细设计的描述的偏差，很容易误导以后进行维护工作的程序员，而且这种错误很难被发现，而那样会浪费掉很多不必要的人力物力。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率；还要注意的就是在编码时尽可能在重点和难点的地方留下注释，这样对后来的程序员读源代码也有很大的帮助。该阶段形成文档：以某特定程序设计语言表示的“源程序清单”（6） 测试在软件开发的一系列活动中，为了保证软件的可靠性，人们研究并使用了很多方法进行分析、设计及编码实现。但是由于软件产品本身无形态，它是复杂的、知识高度密集的逻辑产品，其中不可能没有错误，从客观上讲测试是找出BUG最直接和有效的方法。软件开发总伴随着软件质量保证的活动，而软件测试是主要活动之一。软件测试代表了需求分析、设计和编码的最终复审。在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。测试是保证软件质量的重要手段，其主要方法是在设计测试用例（Testing cases）的基础上检验软件的各个组成部分。这个阶段的任务是通过各种类型的测试，以尽可能少的时间和人力发现软件产品中尽可能多的错误，使软件达到预定的要求。(1) 软件测试是为了发现错误而执行程序的过程。(2) 一个好的测试用例能够发现至今尚未发现的错误。(3) 一个成功的测试是发现了至今尚未发现的错误的测试。该阶段形成文档：软件测试报告。（7） 维护软件维护就是软件交付给用户直至软件被淘汰的整个时期内为了改正错误或者满足新需求而修改软件的活动。软件维护是软件生存周期中时间最长的阶段。已交付的软件系统投入正式使用后，便进入了软件维护阶段，它可以持续几年甚至几十年。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。其原因可能是运行中发现了软件隐含的错误，也可能是用户环境的变化对软件提出了新的需求。要延续软件的使用寿命，就必须对软件进行维护。维护阶段的任务，是通过各种必要的维护活动使系统持久地满足用户的需要。软件维护的任务有四种类型：校正性维护、适应性维护、完善性维护和预防性维护。该阶段形成的文档：软件维护说明书。2.简述软件开发模型中瀑布模型和快速原形模型，并比较各自的优缺点和适用范围。（1） 瀑布模型（Waterfall Model）首先是由Royce提出的，直到80年代早期，它一直是唯一被广泛采用的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，从系统需求分析开始直到产品发布和维护，规定了它们自上而下、相互衔接的固定次序，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，如同瀑布流水逐级下落，这也是瀑布开发名称的由来。 图一：瀑布模型在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，完成工作内容并给出成果，作为输出，当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型严格按照生存周期各个阶段的目标、任务、文档和要求来进行开发。它是以文档形式驱动的。开发人员试图在每一活动过程结束后，通过严格的阶段性复审与确认，得到该阶段的一致、完整、准确和无二义性的良好文档，并以“冻结”这些文档为该阶段的结束标志，保持不变，作为下一阶段活动的唯一基础，从而形成一个理想的线性开发序列，以每一步的正确性和完整性来保证目标系统的质量，也即是通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。 瀑布模型有以下优点1）为项目提供了按阶段划分的检查点。2） 当前一阶段完成后，您只需要去关注后续阶段。3） 可在迭代模型中应用瀑布模型。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。由于过度强调文档的作用，这种模型的线性过程太理想化，往往难以办到，其主要问题在于： 1) 在项目各个阶段之间极少有反馈。2) 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； 3) 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； 4) 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 5) 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。6) 缺乏灵活性，不够直观，不支持软件产品的演化。瀑布模型适用于项目的需求和解决方案在项目开始前很明确，功能和性能明确、完整、无重大变化的软件开发。类似公司的财务系统、库存管理系统、短期项目等。不适用于软件需求不明确或不准确的项目开发。（2） 快速原型（Rapid Prototype）模型又称原型模型，它是增量模型的另一种形式，快速原形是利用原形辅助软件开发的一种新思想。在开发真实系统之前，经过简单快速分析，快速实现一个原型，该原型的基础上，用户与开发者在试用原形过程中加强通讯与反馈，通过反复评价和改进原形，进一步细化待开发软件的需求，减少误解，弥补遗漏，通过逐步调整原型使其满足客户的要求，逐渐完成整个系统的开发工作。快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。快速原型模型在功能上等价于产品的一个子集。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。 根据原型的不同作用,有三类原型模型: 1、探索型原理 这种类型的原型是把原型用于开发的需求分析阶段，目的是要型清用户的需求，确定所期望的特性，并探索各种方案的可行性。它主要针对开发目标模糊，用户与开发都对项目都缺乏经验的情况，通过对原型的开发来明确用户的需求。 2、实验型原型 这种原型主要用于设计阶段，考核；实现方案是否合适，能否实陋。对于一个大型系统，若对设计方案心中没有把握时，可通过这种原型来证实设计方案的正确性。 3、演化型原型 这种原型主要用于及早向用户提交一个原型系统，该原型系统或者包含系统的框架，或者包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。 快速原型模型的运用方式 由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。 1、抛弃策略是将原型用于开发过程的某个阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束后，原型随之作废。探索型和实验型就是采用此策略的。 2、附加策略是将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略。 采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、人员素质、可供支持的原型开发工具和技术等，这要根据实际情况的特点来决定。 快速原型的优点是克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。 快速原型的缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。快速原型模型尤其适用于在软件需求不明的情况下，需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。3.面向过程和面向对象分析方法各有哪些特点。软件工程中的分析具有两个方面的意义：在认识事物方面，具有一整套分析和认识问题域的方法、原则和策略，这些方法、原则和策略使开发人员（系统分析员）对问题域的理解比不遵循软件工程方法更为全面，深刻和有效；在描述事物方面，它具有一套表示体系和文档的规范，比仅用自然语言表达更为准确，也更接近后期的开发阶段。因此，在软件工程中分析成了软件开发的关键一环。 （1） 面向过程其实是最为实际的一种思考方式，就是算面向对象的方法也是含有面向过程的思想，可以说面向过程是一种基础的方法，它考虑的是实际的实现，即分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了，也即是自顶向下，逐步求精。面向过程是在面向对象出现之前，以及之后，甚至延用至今的思想。面向过程分析的工作内容主要包括：理解，表达和验证。面向过程是以功能为中心来描述系统，把所有的功能全部在一个大的类里定义出来。对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，从上往下步步求精，强调功能的抽象和模块化，将解决问题的过程看做一个处理过程，所以面向过程最重要的是模块化的思想方法。而各过程模块则通过函数参数和全局变量达到联系的目的。当程序规模不是很大时，面向过程的方法还会体现出一种优势，因为程序的流程很清楚，按着模块与函数的方法可以很好的组织。当系统庞大时，功能多了，各种操作之间的调用关系也很复杂，当需要修改一个功能时就可能引发一连串的改动，使修改和维护成本很昂贵。（2） 比较面向过程，面向对象的方法主要是把事物给对象化。面向对象是分析出某个问题所涉及到的实体，然后通过定义实体和实体间的互动解决问题；把构成问题事务分解成各个对象，对象包括属性与行为。建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。围绕现实世界的概念来组织模块，采用对象描述问题空间的实体，用程序代码模拟现实世界中的对象，使程序设计过程更自然、更直观。面向对象分析中，对功能以对象为基本单位进行分类，以数据为中心来描述系统，相对于功能而言，数据具有更强的稳定性：把责任分发到相应的类，哪里出了问题或是没有完成任务，只要修改相应的类以及极小部份的其他改动。面向对象把一个复杂的问题分解成多个能够完成独立功能的对象（类），然后把这些对象组合起来去完成这个复杂的问题。采用面向对象模式就象在流水线上工作，我们最终只需将多个零部件（已设计好的对象）按照一定关系组合成一个完整的系统。这样使得软件开发更有效率。因此面向对象分析的关键，是识别出问题域内的对象，并分析确定它们相互之间的关系，最终建立起问题域的简洁，精确，可理解的正确模型。面向对象分析模型有三种用途：用来明确问题需求；为用户和开发人员提供明确需求；为用户和开发人员提供一个协商的基础，作为后继的设计和实现的框架。建立对象模型的工作大体上按照下列顺序进行：寻求问题域内的对象，识别出对象间的关系，定义属性，定义服务。事实上，分析工作不可能严格地按照