软件工程课堂笔记.的精简版..ppt

CH01软件和软件工程 1.软件的特点:软件是设计开发的,而不是传统意义上生产制造的;软件不会磨损,但是会退化 多数软件仍是根据实际顾客需求定制的:在软件设计中,大规模的复用才刚刚开始 2.IEEE对软件工程的定义:将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护, 即将工程化方法应用于软件;上述方法的研究 3软件工程层次图:工具方法-过程质量关注点 4通用软件工程过程框架包括5个活动:沟通;策划;建模;构建;部署。 5.软件神话:它实际上是误导了管理者和从业人员对软件开发的态度,从而引发了严重的问题 管理神话 神话:我们已经有了一本写满软件开发标准和规程的宝典。它无所不包,囊括了我们可能问到的任 何问题。 ·现实:这本宝典也许的确已经存在,但不能保证它已在实际中采用、反映了软件工程的现状、可以 适应不同应用环境、在缩短交付时间的同时还关注保证产品的质量等等 ·神话:如果我们未能按时完成计划,我们可以通过增加程序员人数而赶上进度 现实:新人加入一个软件项目后,原有开发人员必须牺牲本来的开发时间对新人进行培训,减少了 应用于高效开发的时间 神话:如果我将一个软件外包给另一家公司,则我可以完全放手不管 现实:如果开发团队不了解如何在内部管理和控制软件项目,那在外包项目中都会遇到困难 客户神话: 神话:有了对项目目标的大概了解,便足以开始编写程序,可以在之后的项目开发过程中逐步充实 细节 ·现实:虽然通常难以得到综合全面且稳定不变的需求描述,但对项目目标模糊不清的描述将为项目 施带来灾难,只有客户和开发人员之间保持持续有效的沟通才能得到清晰的需求描述。 神话:虽然项目需求不断变更,但是因为软件是弹性的,因此可以很容易地适应变更  现实:软件需求的变更引入时机不同,变更造成的影响也不同,如提出的较早,则费用影响较小, 但随着时间的推移,变更的代价也迅速増加,因为资源已经分配,设计框架已经建立,此时变更可 能会引起剧变,需要添加额外的资源或修改主要设计架枃 从业者神话: 神话:当我们完成程序并将其交付使用之后,我们的任务就完成了。 现实:软件首次交付顾客使用之后花费的工作更多 神话:对于一个成功的软件项目,可执行程序是惟一可交付的成果 现实:軟件配置包括很多内容,可执行程序只是其中之一。各种工作产品(如模型、文档、计划) 是成功实施软件工程的基础,为软件技术支持提供了指导 神话:软件工程将导致我们产生大量无用文档,并因此降低工作效率。 现实:软件工程并非以创建文档为目的,而是为了保证软件产品的开发质量 CH02过程模型 1.瀑布模型 项目启动、需求获取。策划:项目估算、进度计划、项目跟踪。建模:分析 计。构建:编码、测试。部署:交付、支持、反馈。 优缺点:它提供了一个模板,使得分析、设计、编码、测试与维护工作可以在该模板的指导下有 予地展开,避免了软件开发、维护过程中的随意状态。对于需求确定、变更相对较少的项目,线性 顺序模型仍然是一种可以考虑采取的过程模型。采用这种模型,曾经成功地进行过许多大型软件工 ③存在问题:(为什么瀑布模型有时候会失效?)实际项目很少严格遵守该顺序。客户通常难以清 楚描述所有需求。只有到项目接近尾声时,才有可执行程序 3.增量模型: ①经过的活动:  第一个増量模型往往是核心部分的产品,它实现了软件的基本需求,但很多已经明晰或者尚不明晰 的补充特性还没有发布。每个增量的开发可用瀑布或快速原型模型。和原型模型不一样的是,增量 模型虽然也具有“迭代”特征,但是每一个增量都发布一个可操作的产品,不妨称之为“产品扩充 代”。它的早期产品是最终产品的可拆卸版本,每一个版本都能够提供给用户实际使用 ·②优缺点: 优点:能在较短时间内向用户提交可完成部分工作的产品。用户有较充裕的时间学习和适应新产 品。易于保证核心功能正确。可以基于早期版本来获取需求。项目完全失败的风险小。可以为那些 创新的功能开拓市场。规避了资源缺乏的风险。 缺点:把用户需求转化为功能递增的不同版本可能比较难。以确定所有版本共需的公用模块。 ③存在问题 如果你的客户要求你在一个不可能完成的时间提交产品,向他建议只提交一个或几个增量,此 后再提交软件的其他增量 増量和原型的比较:任何增量的处理流程均可结合原型实现;増量模型与原型相同,本质上都 是迭代的:增量模型强调每个増量都是可操作的;早期的増量是整体的一部分,而原型最终要被抛 4.原型开发 沟通→快速策划→建模快速设计→构建原型→部署交付及反馈(组成一个圆圈) ②优缺点 尤点:用户能够感受到实际系统:开发者能很快建造出一些东西 ③存在问题:开发者没有考虑整体软件质量