第1章软件工程学概述重点.ppt

* * * * * * * 不带反馈环的，基本上是顺序的。因为 --原型系统已通过与用户交互而得到验证。 --开发人员建立原型时已得到很多知识。 本质：快速，第一个系统常常抛弃（理想） 理想上，原型可以作为标示软件需求的一种机制。如果建立了可运行原型，开发者就可以在此基础上试图利用已有的程序片断或使用工具（报表生成器、窗口管理器等）来进快生成工作程序。 但当原型已经完成了上述目的之后，我们将如何处理它们呐？Brook 给出了一个答案： “在大多数项目中，建造的第一个系统很少是可用的。它可能太慢，太大，难以使用或三者皆有。没有其它选择，只能重新开始，虽然痛苦，但会得到更好的结果。建造一个经过重新设计的版本，解决了上述的问题……。当使用了新的系统概念或新技术时，你应该建造一个抛弃型的系统，因为即使是最好的计划也不可能是无所不知的，第一次就能完全正确。因此，管理上的问题不是你是否要建造一个指导系统，然后抛弃它，你必须这么做。唯一的问题是：是否需要事先计划好建造一个抛弃型系统，或是承诺要将抛弃型系统交付给用户。” * （1） 原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。 （2） 开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。 软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同阶段，如图1.4中虚线箭头所示。 * 用户似乎看到的是软件的工作版本，其实……原型只是“用口香糖和打包绳”拼凑起来的；为了使原型很快能够工作没有考虑软件的总体质量和长期的可靠性。当被告知该产品必须重建，才能使其达到高质量时，用户叫苦连天，会要求做“一些修改”，使原型成为最终的工作产品。如此，软件开发管理常常就放松了。 开发者常常需要实现上的折衷，以使原型能够尽快工作。一个不合适的操作系统或程序设计语言可能被采用，仅仅因为它是通用的和有名的；一个效率低的算法可能被使用，仅仅为了演示功能。经过一段时间之后，开发者可能对这些选择已经习惯了，忘记了他们不合适的所有原因。于是这些不理想的选择就成为了系统的组成部分。 虽然会出现问题，原型仍是软件工程的一个有效范型。关键是如何定义一开始的游戏规则，即用户和开发者两方面必须达成一致：原型被建造仅是为了定义需求，之后就该被抛弃（或至少部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。 * * * * * * * * * * * * * * * * * * * * * * * * * NATO 北大西洋公约组织 * IEEE (Institute of Electrical and Electronics Engineers)美国电气及电子工程师学会 * * * * * * * * * * * * * * * * * * * 教务管理工作是高等学校教育工作的一项重要内容， 是整个学校管理的核心和基础。 教务管理工作是学校教学 工作的中枢， 是保证高校教学机制正常运转的枢纽， 它是一项目的性、 计划性、 适应性、 创造性和科学性很强的工作。教务管理工作关系到高校教学秩序的稳定和教学质量的提高， 关系到高校的发展和人才的培养， 教务管理在高校中占有相当重要的地位。 建立教务管理系统，促进管理规范化，科学化，提高效率，减少出错，服务学生，教师，教务管理人员。 范围定义：是否值得去做？是否可行？学生多少？教师多少？需要做的事情大概多少？多少门课，多少教室，实验室等等。 * * * * * * * 3. 增量模型（渐增模型） (Incremental Model) 先完成一个系统子集的开发，再按同样的开发步骤增加功能 (系统子集),如此递增下去直至满足全部系统需求。 系统的总体设计在初始子集设计阶段就应作出设想。 增量模型 需求分析 验证 规格说明 验证 设计 验证 维护 针对每个构件完成详细设计、编码和集成，经测试后交付给用户 分析 分析 分析 分析 设计 设计 设计 设计 编码 编码 编码 编码 测试 测试 测试 测试 增量1 增量2 增量3 增量4 交付 交付 交付 交付 ● ● ● ● ● 增量模型的优点 在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。 整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。 逐步增加产品功能