计算机软件系统的基本概念(ppt 114页).ppt

1、计算机软件基础The software basic of computer,主讲：刘志强,第15单元 软件工程概论,第2页,教学目标,了解软件工程的基本概念 掌握软件工程的基本理论、技术和方法，运用于软件的开发和生产,第3页,教学内容,了解软件、软件工程的基本概念 软件的特征 软件危机、软件工程 瀑布模型、原型模型 软件生存周期中各个阶段的任务、实施方法及步骤,第4页,本单元涉及内容,概述 软件的基本概念 软件的发展和软件危机 第9章 软件工程 9.1 软件工程 9.2 软件生存周期 9.3 软件工程管理,第5页,一、基本概念,软件 计算机系统中所有程序、数据结构及有关文档资料的总称。软件是计

2、算机技术和人类智慧高度结合的产物，软件开发不是简单、机械地重复生产，而是创造性的脑力劳动。 软件的作用 软件是今后信息产业发展的推动力。美国最近在24项高科技领域中调查结果表明，其中18项与软件有关。,第6页,软件工程学的体系结构,软件工程学,软件开发技术,软件开发方法学 软件工具 软件工程环境,软件工程管理,软件管理学 软件经济学,第7页,问题的由来,软件内在规律。任何事物有它自己的客观规律和发展轨迹。只有认识了它，才能驾驭它。 软件地位及作用。软件是计算机系统中重要的组成部分。但在早期它并没有引起业界的重视。随着计算机技术的发展，随着“软件危机”的出现，以及软件危机对社会危害的增大，软件的

3、地位和作用也越来越重要。 软件工程学。业界人士不得不设置专门的学科软件工程学来研究软件开发、生产的内在规律，用于指导现代工程化的软件生产。,第8页,软件的特征（与硬件产品比较）,软件是逻辑产品 软件产品质量的体现方式不同 软件产品的失败曲线不同 软件产品的成本构成不同 软件产品不存在同类零件替换 软件产品的静态和动态属性,第9页,软件是逻辑产品,软件产品具有产值、价格、质量和功能的特性，但看不见,是逻辑的、无形的，是脑力劳动的结晶。,第10页,软件产品质量体现方式不同,质量体现方式不同： 实用、可靠、可操作性； 可维护性强 方便用户 不会折旧、损坏、老化,第11页,软、硬件失败曲线,第12页,

4、成本构成不同,12% 需求率,4%,生产率,开发人员,成本构成不同： 主要投资在研制；软件研制是一种人力、资金密集 的产业，而软件生产只是简单的复制、安装和培训。,第13页,软件产品不存在同类零件替换,硬件可更换零部件。当硬件产品中某个部件损坏后，可以用相同的备用部件更换，使硬件系统恢复正常工作。 软件不能更换零部件。而软件产品却没有相同的备用部件可言，因为软件出现的每一个故障，要么是由于设计考虑不周造成的，要么是编程错误造成的。由于软件无备用部件可供更换，因而软件维护比硬件维护要复杂得多,成本也高得多。,第14页,软件产品的静态和动态属性,软件是由程序和相关文档资料组成的。 程序是具有双重属

5、性的： 交流。它是求解客观问题的逻辑描述，是供阅读和交流的，它的表示是静态的； 执行。程序最终是通过运行去执行特定的操作和数据处理，它又具有极其复杂和丰富内涵的动态属性。 程序是否正确的有双重标准： 静态的程序正确与否是检查它的语法和句法是否符合规则要求； 动态的程序正确与否则要动态的测试程序的所有逻辑流结构和数据结构是否正确。 而后一种测试的难度和代价较之前一种要大得多。,第15页,硬件生产率大幅提高,如今，计算机的发展已进入一个新的历史阶段； 硬件产品已系列化、标准化，“即插即用”。 硬件产品的生产可以采用最高精尖的现代化工具和手段、自动成批生产。生产效率几百万倍的提高。 生产能力过剩。,

6、返 回,第16页,软件生产率很低,伴随计算机的普及，整个社会对计算机应用的需求越来越大。 但软件的生产却还沿用“手工作坊”的生产方式，人工编程生产。生产效率仅提高了几倍。 生产能力极其低下。,返 回,第17页,硬、软件供需失衡,社会大量需求，生产成本高，生产过程控制复杂，生产效率低等等因素构成软件生产的恶性循环。 由此产生“软件危机”。,返 回,第18页,矛盾引发“软件危机”,软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 为了研究、解决软件危机，诞生了一门新兴学科软件工程学。它把软件作为工程对象，从技术措施和组织管理两个方面来研究、解决软件危机。,第19页,软件危机的具体

7、体现,（1）软件开发进度难以预测 （2）软件开发成本难以控制 （3）用户对软件功能难以满足 （4）软件产品质量无法保证 （5）软件产品难以维护 （6）软件缺少文档资料,第20页,（1）软件开发进度难以预测,拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。 以丹佛新国际机场为例。该机场规模是曼哈顿机场的两倍，宽为希思机场的10倍，可以全天侯同时起降三架喷气式客机；投资1.93亿美元建立了一个地下行李传送系统，总长21英里，有4，000台遥控车，可按不同线路在20家不同的航空公司柜台、登机门和行李领取处之间发送和传递行李；支持该系统的是5，000个电子眼、400台无线电接受

8、机、56台条形码扫描仪和100台计算机。按原定计划要在1993年万圣节前启用，但一直到1994年6月，机场的计划者还无法预测行李系统何时能达到可使机场开放的稳定程度。,第21页,（2）软件开发成本难以控制,投资一再追加，令人难于置信。往往是实际成本比预算成本高出一个数量级。 而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量，从而不可避免地会引起用户的不满。,第22页,（3）用户对产品功能难以满足,开发人员和用户之间很难沟通、矛盾很难统一。往往是软件开发人员不能真正了解用户的需求，而用户又不了解计算机求解问题的模式和能力，双方无法用共同熟悉的语言进行交流和描述。 在双方互不充

9、分了解的情况下，就仓促上阵设计系统、匆忙着手编写程序，这种“闭门造车”的开发方式必然导致最终的产品不符合用户的实际需要。,第23页,（4）软件产品质量无法保证,系统中的错误难以消除。软件是逻辑产品，质量问题很难以统一的标准度量，因而造成质量控制困难。 软件产品并不是没有错误，而是盲目检测很难发现错误，而隐藏下来的错误往往是造成重大事故的隐患。,第24页,（5）软件产品难以维护,软件产品本质上是开发人员的代码化的逻辑思维活动，他人难以替代。除非是开发者本人，否则很难及时检测、排除系统故障。 为使系统适应新的硬件环境，或根据用户的需要在原系统中增加一些新的功能，又有可能增加系统中的错误。,第25页

10、,（6）软件缺少适当的文档资料,文档资料是软件必不可少的重要组成部分。 实际上，软件的文档资料是开发组织和用户的之间权利和义务的合同书，是系统管理者、总体设计者向开发人员下达的任务书，是系统维护人员的技术指导手册，是用户的操作说明书。 缺乏必要的文档资料或者文档资料不合格，将给软件开发和维护带来许多严重的困难和问题。,第26页,软件生产随规模增大而复杂度增大,以美国宇航局的软件系统为例： 1963年 水星计划系统 200万条指令 1967年 双子星座计划系统 400万条指令 1973年 阿波罗计划系统 1000万条指令 1979年 哥伦比亚航天飞机系统 4000万条指令 假设1个人一年生产一万

11、条有效指令，那么是否4000人生产一年，或400人生产10年就能完成任务吗？答案是否定的。一万条指令的复杂度决不仅仅是100条指令复杂度的100倍。,第27页,典型失败系统的例子,IBM公司开发OS/360系统，共有4000多个模块，约100万条指令，投入5000人年，耗资数亿美元，结果还是延期交付。在交付使用后的系统中仍发现大量（2000个以上）的错误。,第28页,软件危机产生的原因,产生软件危机有两个方面的原因： 内部因素。与软件本身的特点有关。内在因素是客观的存在，只能因势利导加以解决。 外部因素。与软件开发和维护的技术方法有关。外部因素是可以完善、提高的。,第29页,软件特点的因素,软

12、件是逻辑产品，是代码化了的人的思维活动。在总体构思时，别人无法管理和干预。在写出程序、并在机器上运行之前，进展情况难以掌握，开发质量也无法评估。这些都给管理和控制带来不便。 软件是特定问题在计算机上的运行描述。实际问题的复杂性决定了一个实用软件系统规模往往十分庞大。程序规模越大，控制、管理难度也就越大。,第30页,软件开发维护技术方法的因素,开发人员和用户之间的矛盾。许多软件系统开发失败的主要原因是开发人员在没有准确、完整地了解了用户的需求后就急于编程；用户对需求也往往不能准确、完整地提出。 软件产品有其生命周期。在周期的各个阶段有其具体的任务，如何完成任务，各个阶段有不同的技术方法和操作步骤

13、。只有科学的按生命周期各阶段的任务去组织实施，才能保证质量，降低成本；急于求成，不按科学规律、方法实施，只能“事倍功半”，事与愿违。 软件产品的使用寿命很长。在这期间因功能的增加、硬件的更新换代，都要对软件进行必要的修改。据统计数据表明，软件维护的费用占总费用的55%70%。软件工程的一个重要目标就是提高软件的可维护性，减少软件维护的代价。,第31页,解决软件危机的途径,为了解决软件危机就要从技术措施和组织管理两个方面去研究，不断总结经验教训，提高软件产品的生产效率，降低软件开发和维护的成本。 开发软件选用最好的开发工具是至关重要的，即选择、设置良好的软件工程支撑环境。工具选用的好，它可以“放

14、大”人的智力，大大加快软件开发速度，提高软件质量。,第32页,软件开发的演变过程,程序设计阶段 软件设计阶段 软件工程阶段,第33页,程序设计阶段（1946年1955年）,特点： 尚无软件的概念，程序设计主要围绕硬件进行开发，规模很小，工具简单，无明确分工（开发者和用户），程序设计追求节省空间和编程技巧，无文档资料。主要是用于科学计算。,第34页,软件设计阶段（1956年1970年）,特点： 硬件环境相对稳定，出现“软件作坊”的开发组织形式。开始使用产品软件（可购买），从而建立了软件的概念。系统规模越来越庞大，高级编程语言层出不穷，应用领域不断拓宽，开发者和用户有了明确分工，社会对软件的需求量

15、剧增。但是软件开发技术没有重大突破，生产效率低下，从而导致“软件危机”产生。,第35页,软件工程阶段（1970年至今）,由于软件危机的产生，迫使人们不得不研究、改变软件开发的技术手段和管理方法。从此软件生产进入软件工程时代。 特点： 硬件已向“四化”（巨型、微型、网络、智能）发展，数据库技术已成熟并广泛应用，第三、四代语言出现。 第一代软件技术结构化程序设计在数值计算领域取得优异成绩； 第二代软件技术软件测试技术、方法、原理用于软件生产过程； 第三代软件技术处理需求定义技术，用于软件需求分析和描述。,第36页,二、软件工程,“软件工程”一词是1968年北大西洋公约组织的计算机科学家在当时联邦德

16、国召开的专门讨论解决“软件危机”的国际会议上正式提出并使用的，并由此诞生了一门新兴学科软件工程学。 “软件工程学”是一门交叉学科，它涉及计算机科学、管理科学、工程学和数学。 计算机科学培养的是计算机科学家，而软件工程则是培养软件工程师。,第37页,软件工程的目标,软件工程的基本目标是： 开发尽可能多的软件产品； 提高软件的生产效率； 满足应用的功能需要； 降低软件开发成本。,第38页,软件工程的指导思想,为解决软件危机，把“软件”这种特殊商品的生产、管理过程纳入传统工程管理的轨道； 用计算机科学中的最新成果应用于软件工程中 用管理学的原理和方法进行软件生产管理 用工程学的观点进行核算，制定工程

17、进度和实施方案 用数学方法建立软件的可靠模型和各种有效算法,第39页,软件工程基本原理,自1968年提出“软件工程”的概念以来，专家学者又陆续突出了100多条关于软件工程的准则。 著名软件工程专家B.W.Boehm于1983年发表的一篇论文中提出了软件工程的七条基本原理。他认为这七条原理是确保软件产品质量和开发效率的最小准则集合。,第40页,软件工程七条基本原理,用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 开发小组人员少而精 承认不断改进软件工程实践的必要性,第41页,用分阶段生命周期计划严格管理,在软件的整个生命周期中应该制

18、定并严格执行六类计划：项目概要、项目进度表、项目控制、产品控制、验证及运行维护计划。 不同层次的管理人员必须严格按照计划各尽其职地去管理软件开发与维护工作，绝不能受客户或上级的影响而擅自背离预定计划。,第42页,坚持进行阶段评审,软件的质量保证工作不能等到编码阶段结束之后再进行。这是因为： 大部分错误是在编码之前造成的（根据Boehm统计，设计错误占软件错误的63%，编码错误占37%）。 错误发现与改正得越晚，所付出的代价也越高。 因此，在每个阶段进行严格的评审，尽早发现并修正各个阶段中所犯的错误是一条必须遵循的重要原则。,第43页,示意图关于阶段评审作用,第44页,实行严格的产品控制,在软件

19、开发过程中不应随意改变需求（改变一项需求往往要付出很高的代价），但不能禁止更改需求。当必须修改时，为了保持软件各配置成分的一致性，必须实行严格的产品控制（主要是实行基准配置管理）。 一切有关修改软件的建议（特别是涉及到对基准配置的修改建议）都必须按照严格的规程进行评审，获准后才能实施修改）。 绝对不能谁想修改就随意进行修改的行为。,第45页,采用现代程序设计技术,以前的结构化程序设计技术，如今的面向对象程序设计技术都被实践证明是各个不同历史阶段的优秀程序设计技术和方法。 采用先进的技术既可以提高软件开发的效率，又可以提高软件维护的效率。,第46页,结果应能清楚地审查,软件产品是看不见、摸不着的

20、逻辑产品，软件开发人员的工作进展情况可见性差。为了提高开发过程的可见性，应根据软件开发项目中的目标完成期限，规定开发组织的责任和产品标准，使得到的结果能够清楚的审查。,第47页,开发小组人员少而精,开发小组成员的素质应该高，人员不宜过多。人员素质和数量是影响产品质量和开发效率的重要因素。 素质高的人开发效率比低的人高几倍甚至几十倍，而错误则明显得少； 人数增加，管理难度也增加。,第48页,承认不断改进软件工程实践的必要性,要积极主动地采纳新的软件技术，要不断总结经验；不能自以为是，固步自封，唯我独好。 大千世界，错综复杂，只有不断学习，才能不断进取，不断进步。,第49页,软件工程应用范围,个人

21、程序、中小型或一般程序同开发人员之间的关联较小，应用SE方法收效甚微。 大型程序要由若干个程序员小组承担开发，相互关系极其复杂，因此，必须自始至终坚持SE方法。,第50页,应用程序分类,分类 程序规模 模块数 开发时间 开发人数,极小 500行以下 1020 14周 1人 小 1K2K行 2550 16月 1人 中 5K50K行 2501000 12年 25人 大 50K100K行 1000以上 23年 520人 甚大 1M行 45年 1001000人 极大 1M10M行 510年 20005000,第51页,传统软件工程模式,70年代，计算机技术水平不高，开发工具少而且性能差。对于大型复杂问

22、题的求解方法有很大的局限性影响。 软件工程采用的方法：把软件生存周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低整个软件开发工程的困难程度。 在实现每个阶段的任务时，采用的是系统化的技术方法结构化分析和结构化设计技术。 传统软件工程模式的缺点：强调了分阶段实施模块化、结构化程序设计技术和方法，而忽视了人在软件开发过程中的地位和作用。,第52页,现代软件工程模式,现代软件工程是在传统软件工程模式的基础上，为了强调人在系统开发中的作用，同时为了适应软件新技术的发展趋势而提出的。其基本要点是： 以人为主，充分利用软件开发方法及软件开发工具； 开发人员的组织管

23、理对软件开发成功与否至关重要； 基于软件组件的软件开发技术。各种功能的可重用软件组件不断问世。这使得在软件开发过程中编程工作量日趋减少，取而代之的是在设计好系统体系结构后，利用软件组件构造或重构软件系统。 由于软件组件是标准化设计、成品化生产的，极易构造使用，从而大大简化了设计、编程、测试各个环节的工作量，提高了工作效率和生产效率。 由于在软件开发过程中最大限度地采用软件组件，使得软件开发过程变为系统分析、系统构造、系统测试的集成过程。,第53页,阶段的划分及主要任务,系统分析 系统设计 系统测试 软件组件 系统开发人员的组织管理,第54页,系统分析,系统分析从系统需求入手，从用户观点出发建立

24、系统用户模型。用户模型从概念上全方位表达系统需求及系统与用户的相互关系。系统分析在用户模型的基础上，建立适应性强的独立于系统实现环境的逻辑结构。 分析阶段独立于系统实现环境，可以保证建立起来的系统结构具有相对的稳定性，便于系统维护、移植或扩充。 在系统分析阶段，系统的逻辑结构应从以下三方面全面反映系统的功能与性能： （1）信息。完整描述系统中所处理的全部信息； （2）行为。完全描述系统状态变化所需处理或功能； （3）表示。详细描述系统的对外接口与界面。,第55页,系统设计,在系统设计阶段，首先考虑具体的实现环境。在设计时，可能会对系统结构作一些调整，但为了保持系统结构的稳定性，应尽可能避免由于

25、实现环境的特定要求而改变系统结构。 设计、构造系统的软件组件。设计软件组件的主要内容是定义组件的结构、功能和外部接口，以及组件之间的相互关系和通信方式。对于复杂的大系统，还可以根据组件之间关联的紧密程度，将关联密切的多个组件形成一个子系统，子系统之间具有松散的耦合。 在系统实现阶段，对于需要开发的软件组件，选择采用某种合适的程序设计语言编写相应的源代码程序，完成系统实现工作。,第56页,系统测试,系统测试包括单元测试、集成测试和系统测试。就功能而言与传统软件工程模式中系统测试的功能相同。,第57页,软件组件,在现代软件工程的开发过程中，软件组件只是一个辅助或支撑系统构造的一个过程。 软件组件开

26、发主要是开发与维护系统构造过程中用到的组件。将软件组件作为一个单独的过程，目的是将组件作为构造软件的“零部件”。 随着软件技术的不断发展及软件工程的不断完善，软件组件将会作为一种独立的软件产品出现在市场上，供应用开发人员在构造应用系统时选用。,第58页,系统开发人员的组织管理,现代软件工程不仅包括软件开发方法、工具和过程，更强调人在开发过程中的作用。一个复杂的系统开发过程，涉及到众多的以人为主的各种开发活动，通过这些活动的有机配合与协调才能保证系统开发的成功。因此，系统开发人员的组织管理是现代软件工程中的重要方面。 组织管理方法有以下几个要点： 明确系统开发人员与用户之间的责任与义务； 明确各

27、类开发人员的主要工作及责任； 制定或选择工程开发规范。,第59页,三、软件生命周期,软件生存周期指从软件的需求分析、设计、编程、测试、交付用户使用到版本升级、或被被自然淘汰的过程。 软件工程的应用模式也称为软件生存周期模式。通常也称其为“瀑布模型”（B.W.Bohem提出的该模型)。,第60页,软件生命周期各个阶段任务,需求分析、定义 系统总体设计 系统编程 系统测试 系统维护,第61页,需求分析、定义,任务是：收集、分析、理解、确定用户的要求；然后把用户的要求精确、完整地描述表达出来。 目的：要回答“要解决什么问题？”， 既系统”做什么？“。 分两步骤： 可行性研究： 制定软件开发计划 进行

28、需求分析 阶段结果， 产生出： 可行性报告、软件计划、需求说明书,第62页,系统总体设计,任务是： 设计软件系统的模块层次结构 模块间逻辑关系、参数 每个模块的功能 目的：要回答“如何解决该问题？”， 既系统”怎样做？“。 分两步骤： 概要设计：解决系统的模块划分、模块的层次结构及数据库设计。 详细设计： 解决每个摸块内部算法和数据结构。 阶段结果； 产生出： 系统设计说明书和模块功能说明书。,第63页,系统编程,任务是： 根据设计说明书中每个模块的控制流程编出相应的程序。 阶段结果： 软件系统的源程序。,第64页,系统测试,任务是：检查、发现程序中的错误，提高软件的可靠性。回答：“该系统是否

29、能实现规定的操作？”。 分三个阶段： 模块测试 测试每个模块的程序是否有错； 组装测试 测试模块之间的接口是否正确； 确认测试 测试整个软件系统是否满足用户功能、性能要求。 测试三大基本技术： 逻辑覆盖（白盒法） 边值分析（黑盒法） 等价类划分（黑盒法） 阶段结果：测试报告；说明测试数据的选择，测试对象、测试结果是否符合预期结果等。,第65页,系统维护,任务是：改正软件系统在使用过程中发现的隐含错误，扩充在使用过程中的新的功能要求； 目的：维护软件系统的正常运行； 阶段结果：软件系统的问题报告和软件修改报告（记录发现软件错误的情况以及修改软件的过程）。,第66页,瀑布模型,需求分析7%,系统设

30、计6%,软件编程7%,软件测试13%,软件维护67%,用户要求,分析报告,系统设计报告,源程序,测试报告,更改要求,U A M,A T M,M P,U T P,U A M P,A 系统分析员 M 项目管理员 P 程序员 T 高级程序员 U 用户,第67页,瀑布模型的特点,瀑布模型具有顺序性和依赖性,即后一阶段的工作必须在前一阶段的工作完成后才能开始。 把逻辑设计与物理设计清楚地划分开，是瀑布模型的重要指导思想。 瀑布模型强调的是优质，即每一步都循序渐进，及早消除隐患，从而保证软件质量。 它的致命缺点在于只有做出精确的需求分析，才能取得预期的结果。由于各种客观、主观的原因，需求分析往往不很精确，

31、常常给日后的开发带来隐患。,第68页,原型模型样品模型,原型模型的主要思想： 先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。 原形模型的特点： (1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。 （2）缩短了开发周期，加快了工程进度。 （3）降低成本。 原型模型的缺点： 当告诉用户，还必须重新生产该产品时，用户是很难接受的。这往往给工程继续开展带来不利因素。,第69页,快速原型模型,分析,原型 样品 模型,设计,编程,测试,使用,修改 与 改进,在系

32、统分析与 设计中，采用 交互式，反复 修改与不断改 进的方式进行。,还有的把原型模式嵌套在瀑布模型中运用。,第70页,螺旋模型,螺旋模型将工程划分为4个主要活动：制定计划、风险分析、实现工程和用户评价。4个活动螺旋式地重复执行，直到最终得到用户认可的产品。 制定计划：确定软件目标,选定实施方案,弄清项目开发限制条件。 风险分析:分析可选方案,分析识别风险,研究解决化解风险的办法。 实现工程:实施软件产品的开发。 用户评价:对当前工作结果进行评价，提出改进产品的建议。 螺旋模型的缺点:很难让用户确信这种演化方法的结果是可以控制的.,第71页,其他模型,智能模型 也称基于知识的软件开发模型，它与专

33、家系统结合在一起。该模型应用基于规则的系统，采用归纳和推理机制，帮助软件人员完成开发工作，并使维护在系统规格说明一级进行。 该模型在实施过程中要建立知识库，将模型本身、软件工程知识与特定领域的知识分别存人数据库。以软件工程知识为基础的生成规则构成的专家系统与含应用领域知识规则的其他专家系统相结合，构成这一应用领域软件的开发系统。 面向对象生存周期模型 其主导思想是：在整个软件开发过程中将面向对象技术贯穿于整个生存周期。当然，还要结合传统开发模式中好的、已被无数成功开发活动证明是可行的经验和技术。,第72页,四、软件工程管理,软件工程项目管理的任务 软件人员组织与管理 软件配置管理 软件知识产权

34、保护,第73页,软件工程项目管理的任务,软件工程项目管理所涉及的范围覆盖了整个软件工程过程。它管理的任务是：根据项目合同书的要求，制定项目计划和工程进度安排、监督和检查项目实施过程、保证工程满足要求的质量标准、分析确定并排除风险、在规定的期限和预算成本内完成项目。包括： 项目计划和进度安排 项目追踪和质量保证 成本估算 风险分析,第74页,项目计划和进度安排,项目计划要列出软件开发要做的主要工作和任务清单，要回答“软件工程项目做什么”。 在工作和任务清单中要清楚地描述出： 项目划分的各个实施阶段 每个阶段的工作重点和任务是什么 完成本阶段工作和任务的人力、资源需求，时间期限 阶段工作和任务的成

35、果形式 项目实施过程中对风险、疑难、其他不可预见因素等的处理机制 各任务组及开发人员之间的组织、协调关系等。,第75页,进度安排,在制定项目进度安排时，主要依据是合同书和项目计划。通常的做法是把复杂的整体项目分解成许多可以准确描述、度量、可独立操作的相对简单的任务，然后安排这些任务的执行顺序，确定每个任务的完成期限、开始时间和结束时间。 开始需要考虑的主要问题是： 项目可以支配的人力及资源 项目的关键路径 生存周期各个阶段工作量的划分 工程进展如何度量 各个阶段任务完成标志 如何自然过渡到下一阶段的任务等。,第76页,项目追踪和质量保证,项目追踪实施由项目管理人员负责。他们必须按进度安排表追踪

36、检查每一个任务。如果任务实际完成日期滞后于进度安排，则管理人员可以行使职权范围内的权力采取各种补救措施以减少进度误期所造成的影响。包括对资源重新定向，对任务重新安排，甚至可以修改交付日期以调整已经暴露的问题。 质量保证在软件生存周期中是至关重要的。人们在管理项目时往往只强调必须按期完成任务，必须遵循进度计划，必须把成本控制在预算范围内，却忽视了在生存周期各个阶段工作和任务应满足规定的质量标准。,第77页,软件质量主要因素包括,正确性 在预定的系统环境下能正确地完成预期的功能； 健壮性 在预定意外环境下系统能适当地给予预期的响应； 完整性 对未经授权的操作，系统能够进行控制； 可用性 系统在完成

37、预定任务的功能时能够圆满地实现； 灵活性 系统应能满足硬件环境升级和部分功能扩充需求； 可理解性 用户和维护人员应非常容易的理解和使用系统； 可维护性 用户按文档资料应能排除常见系统故障，保持系统正常运行； 可移植性 在厂家协助下，系统可以移植到其他硬件环境且费用可以接受； 可重用性 系统全部或部分代码可以在其他应用系统中被使用； 可测试性 系统容易测试。,第78页,保证软件质量的措施,为了保证软件质量，在软件开发过程中应采取下列措施： （1）审查 （2）复查和管理复查 （3）测试,第79页,审查,在软件生存期各个阶段结束之前，都要对该阶段产生的结果和软件配置文档进行严格技术审查。 审查过程包

38、括： 计划：组织审查组、分发材料等； 概况介绍：对大的项目，让主程序员介绍概况； 准备：评审员阅读材料，取得项目有关知识； 评审会：目的是发现和记录错误； 返工：开发者修改已经发现的问题； 复查：检查返工是否真正解决了问题。,第80页,复查和管理复查,复查是检查已有的材料，以断定本阶段的工作是否能够开始或继续。每个阶段开始时的复查是为了肯定前一个阶段结束时确实进行了认真的复查，已经具备了开始当前阶段工作所必须的材料。 管理复查是指：向开发组织或使用部门的管理人员提供有关项目的总体状况以及进度等方面的情况，以便他们从管理的角度对开发工作进行审查。,第81页,测试,测试是用测试用例执行系统，以检查

39、测试结果是否和预期结果一致。 在测试过程中将产生以下文档： 测试计划：确定测试范围、方法、测试用例和所需资源等； 测试过程：详细描述与每个测试方案有关的测试步骤和数据（包括测试预期结果）; 测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且要通过调试解决所发现的问题。,第82页,成本估算,成本估算和成本管理是软件项目管理的核心任务之一。在制定项目计划时，就必须对项目需要的人力及其他资源、项目持续时间和项目成本做出估算。如果新项目和以往的项目类似，估算可以参考以前的成本费用。 现在已有一些用于软件成本估算的技术可供借鉴。这些估算技术各有其优缺点，但以下几方面是共同的：

40、事先建立软件的工作范围； 以软件度量（经验度量、相似工程类比的度量）为基础做出估算 把项目分解为可单独进行估算的小块,第83页,成本估算方法,就方法论而言，有两种基本的成本估算方法：自顶向下和自底向上。 自顶向下法是对整个工程项目的总开发时间和总工作量做出估算，然后将它们按阶段、步骤和任务进行分配。 自底向上法则正好相反，先分别估算各个任务所需要的工作量和开发时间，再相加，从而得到总的工作量和总的开发时间。这两种方法都要求采用某种方法做出估算。 有许多估算方法可以利用，大致划分为三类：专家估算法、类推估算法、算式估算法。,第84页,成本估算方法简介,专家估算法 依靠一个或多个专家对项目做出估算

41、，其精度主要取决于专家对估算项目的定性参数的了解和他们的经验。 类推估算法 在自顶向下法中，类推估算法将估算项目的总体参数与类似项目进行直接比较得到结果；在自底向上法中，类推是在两个具有相似条件的工作单元之间进行。 算式估算法 前两种估算法的缺点在于：它们依靠的是带有主观猜测和盲目性的估算方法。算式估算法则是企图避免主观因素影响的一种方法。算式估算法有两种基本类型：由理论导出的算法和由经验得出的算法。,第85页,风险分析,在开发新的软件系统过程中，由于存在许多不确定因素，软件开发失败的风险是客观存在的。因此，风险分析对于软件项目管理是决定性的。风险分析实际上就是贯穿在软件工程过程中的一系列风险

42、管理步骤，其中包括：风险识别、风险估计、风险管理策略、风险解决和风险监督等。,第86页,主要风险因素, 产品大小。实践经验表明项目风险和产品的大小成正比。公认产品大小度量单位是以代码行或功能点计。 技术相关。未曾使用过的新技术都存在风险。包括未使用过的新型硬件、支持软件，缺乏标准与规范的非传统的开发方法等。技术过时也是风险。技术风险一般难于改正。 开发环境。适用的开发工具不足、不可靠、使用不方便等因素，都会降低开发效率。 组织规模和人员经验。 客户因素。表现在客户需求经常矛盾，不了解客户的特殊需要，客户不了解项目中采用的新技术，且双方又难于沟通等。,第87页,软件人员组织与管理,人员是软件工程

43、项目最重要、也是最为活跃的资源因素。如何组织得更加合理，如何管理得更加有效，从而最大限度地发挥这一重要的资源潜力，对于成功地完成软件工程项目至关重要。 项目组的组织结构 程序设计小组的组织形式 软件项目的管理,第88页,项目组的组织结构,开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参加人员的素质有关。 建立项目组织时要考虑这样一些原则： 项目责任制度。项目必须实行项目负责人责任制。项目责任人对项目的完成负全部责任。 人员少而精。项目组成员之间的交流和协作是项目成败的关键。人员少，具有便于组织管理、合理分工、减少通信等优点；人员精，有利于互相激励、发挥各自的特长优势，提高工作效率。

44、,第89页,选择组织结构的模式,（1）按课题划分 按课题划分小组。小组成员自始至终参加所承担课题的各项任务。 （2）按职能划分 按任务的工作阶段划分成若干个专业小组。例如，分别建立计划组、需求分析组、设计组、实现组、测试组、质量保证组、维护组等。要开发的软件产品在每个专业小组完成阶段加工后，沿工序流水线向下传递。这种流水线模式便于小组人员熟悉本组的工作，进而变成这方面的专家。但也有小组之间的通信接口增多，通信路径延长等问题。 （3）矩阵形模式 这种模式实际上是以上两种模式的结合。既设立项目经理负责项目的管理，又成立一些专门组，每个成员参加其中一个组的实际工作。矩阵形结构组织的优点是：参加专门组

45、的成员可在组内交流其在各项目中取得的经验，这更有利于发挥专业人员的作用。而且各个项目有专人负责，有利于项目的完成。,第90页,程序设计小组的组织形式,一般情况下，程序设计人员是在一定程度上独立自主地完成各自的任务。但这并不意味着互相之间没有联系。事实上，人员之间联系得多少和联系方式与生产效率直接相关。 程序设计小组内人数少，如23人，则人员之间的联系比较简单。但随着人数的增加，相互之间的联系是按非线性关系变得复杂起来。因此，小组内部人员的组织形式对生产率也有很大的影响。,第91页,主程序员组,组由主程序员、程序员和后援工程师为核心组成。 主程序员是经验丰富能力强的高级程序员，负责小组全部技术活

46、动的计划、协调与审查工作，还负责设计和实现项目中的关键部分。 后援工程师协助和支持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的工作，并在必要时代替主程序员工作，以便使项目能继续进行。 程序员负责项目的具体分析与开发，以及文档资料的编写工作。根据系统规模大小及难易程度，小组还可以聘请一些专家、辅助人员、软件资料员协助工作。 主程序员组这种集中领导的组织形式突出了主程序员的领导作用，简化了人际通信。这种组织形式能否取得好的效果，很大程度上取决于主程序员的技术水平和管理才能。美国的软件产业中大多采用主程序员组的组织形式。,第92页,民主小组,小组由经验丰富的技术人员组成。项目有关的

47、所有重大决策都由全体成员集体讨论、确定解决。这种组织形式强调发挥每个成员的积极性，要求每个成员充分发挥主动精神和协作精神。通过充分讨论，也是在互相学习，因而在组内形成一个良好合作的工作气氛。但有时也会因此削弱个人的责任心和必要的权威作用。有人认为这种组织形式适合于研制时间长、开发难度大的项目。 日本软件产业中大多采用这种组织形式，取得较好的效果。这种组织形式在强调发挥每个成员的积极性的同时，也创造了一个尊重每个成员的良好工作环境。由于小组成员在工作上能够很好地配合，因而做到了较长时间稳定的人员合作关系。这样的小组形式避免了美国因软件人员频繁流动对工作造成的严重干扰。,第93页,层次小组,小组内

48、人员分为3级：组长、高级程序员和程序员。 组长负责全组工作，包括任务分配、技术评审和复查、掌握工作量和参加技术活动。组长直接领导2至3名高级程序员。 高级程序员通过基层小组，管理若干个程序员。这种组织结构只允许必要的人际通信。它比较适合项目本身就是层次结构状的课题以及大型软件项目的开发。,第94页,软件项目的管理,软件项目管理包括项目指导和项目检验。 指导的目的是在软件项目的实施过程中，动员和促进工作人员积极完成所分配的任务。 检验是软件管理的最后一个方面。它是对照计划检查执行情况的过程，同时也是对照软件工程标准检查实施情况的过程。在发现项目的实施与计划或标准有较大的偏离时，应采取措施加以解决

49、。 管理内容包括： 指导工作的要点 检验管理的要点 检验管理的工作范围,第95页,指导工作的要点, 鼓励。恰当而且及时地鼓励是非常重要的。要建立健全竞争和激励机制，它可使人们充满信心，勇于继续克服困难，愿意努力进一步提高工作效率，迎接新任务的挑战。 引导。通常，人们愿意追随那些能够体谅个人要求或实际困难的领导。高明的领导人应能体察到这些，并能巧妙地把个人的要求和目标与项目工作的整体目标结合起来，至少应能做到在一定程度上的协调，或在一个工作周期内一致。要制定相对优惠的“留人”政策，稳定骨干队伍。从风险分析中可知，大幅度的人员调整是非常有害的，即使是人员的临时观念也会使项目付出无形的代价，因而蒙受

50、无谓的损失。,第96页,检验管理的要点,重大偏离。在软件项目实施过程中，必须注意：工作与计划之间、任务与标准之间的重大偏离。遇到有这种情况时应及时向管理部门报告并采取相应的措施给予适当的处置。 选定标准。检验管理需要事先确定应当遵循的标准，使得软件项目的工作进展可以用某些客观、精确且有实际意义的标准加以衡量。 特殊情况。管理人员必须注意软件项目实施的一些特殊情况，认真分析其中的一些特殊问题，加以解决。,第97页,检验管理的工作范围,检验管理可能涉及到以下几个方面： 质量管理。包括明确度量软件质量的因素和准则，决定质量管理的方法和工具，以及实施质量管理的组织形式。 进度管理。检验进度计划执行的情

51、况。 成本管理。度量并控制软件项目的开销。 文档管理。检验文档编写是否符合要求。 配置管理。检验、控制软件配置项的变更。,第98页,软件配置管理,软件配置管理是人们在软件工程实践过程中总结出的一套管理办法和原则。软件配置管理将伴随整个软件生存周期。 软件配置管理和基线 配置管理的任务,第99页,软件配置管理和基线,什么是软件配置项？一般认为：软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。 软件配置项包括： 与合同、过程、计划和产品有关的文档和资料； 源代码、目标代码和可执行代码； 相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。,第100页,基线,什么是基线

52、？第一次提出的软件配置项就构成基线配置项。基线分类列表如下： 系统功能说明。系统模型，项目计划，进度安排； 软件需求规格说明。包括：图形分析模型、过程、原型、数学规格说明； 设计规格说明。包括：数据设计、体系结构设计、界面设计、对象的描述等；验收规格说明； 测试规格说明。包括：测试计划、测试用例、测试预期结果、测试记录等； 数据库描述。包括：数据模式、记录结构、数据项描述； 模块规格说明。包括：模块功能、模块算法、模块接口等描述； 运行系统。包括：模块代码、链接模块、数据库、支持及工具程序等； 用户文档。包括：安装说明、操作说明、用户手册等；培训计划；维护文档，包括：故障报告、维护要求、更改记

53、录等； 项目采用的有关标准和规程。,第101页,配置管理的任务, 标识软件配置项 版本控制 变更管理 审计,第102页, 标识软件配置项,大型软件工程项目开发过程中可能会产生许多技术文档。随着软件系统的变更，有关文档也将发生变化。因此，对软件配置项的管理是一个动态管理的过程。为了便于管理，首先要便于检索。而要检索就必须对所有的配置项进行标识、命名。标识软件配置项是配置项管理的重要基础工作。 所有的软件配置项均可以当作对象来标识。例如，基本对象可以是一段需求规格说明、一个模块的源代码清单、一组测试用例等。将这些正文单元命名后作为基本对象，再将基本对象按内部逻辑进行组合，就形成复合对象。复合对象表

54、示的是一本设计规格说明书、一个完整的源程序清单。,第103页,版本控制,版本更新是软件生存期中的自然现象。软件系统每做一次修改，就应该变更一次版本。不同版本反映的是不同时期、不同硬件环境、不同用户需求的该软件系统的特定功能。为了保持该软件系统一脉相承的完整性，每一个软件配置项修改后的以前版本都要保留。 版本更新就好像一棵生长的树。所有版本均按版本模型（树形结构）存放于仓储库中。为节省仓储库的存储空间，版本存放采用增量法，即只存放新版本与旧版本不同部分的内容。,第104页, 变更管理,有变更的需求就要有变更的控制和管理。它的主要任务包括： 分析变更的必要性和合理性，确定是否实施变更； 记录变更信

55、息，填写变更控制单； 做出更改，并交上级审批； 修改相应的软件配置项（基线），确立新的版本； 评审后发布新版本。,第105页, 审计,软件配置项的更改反映了用户提高、扩充软件系统功能和性能的要求以及软件开发人员对软件需求定义的认识的提高。 如何保证变更需求和变更实施结果的一致性？如何保证任何一个变更能顺利正确地完成？这正是审计的作用。为保证软件配置项变更的合理性和严肃性，必须实行严格的审计控制。 一般采用两种方法进行审计： 正式技术评审 着重检查对软件配置项的变更的技术正确性。综合考虑此软件配置项的变更对其它配置项乃至整个软件系统的潜在影响和作用。 软件配置审核 是审核变更的落实情况；变更修改

56、是否完成？变更手续是否完备？变更修改有无违反标准？,第106页,软件知识产权保护,计算机软件是人类知识、智慧和创造性劳动的结晶，软件产业是知识和资金密集型的新兴产业。由于它具有开发工作量大、周期长，而生产（复制）容易、费用低等特点，因此，长期以来，软件的知识产权得不到尊重，软件的真正价值得不到承认，靠非法窃取他人软件而牟取商业利益成了信息产业中投机者的一条捷径。因此，软件产权保护已成为急待解决的一个社会问题，是我国软件产业健康发展的前提。 1967年在瑞典斯得哥而摩成立了世界知识产权组织。1980年我国正式加入该组织。1990年9月我国颁布了著作权法，确定计算机软件为保护的对象。1991年6月由国务院正式颁布了我国计算机软件保护条例。 应该学习并掌握必要的软件保护法律知识。一方面要尊重别人的智力劳动成果，不应任意侵犯他人的软件版权；另一方面要采取切实的保护措施保护自己以及本单位开发的软件成果。,第107页,软件知识产权的法律保护,知识产权 又称为智力成果产