HomeWork 1

软件工程的定义

即研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

来自IEEE给出的更加综合的定义是：将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中。

Software Crisis

造成software crisis的原因：

• 软件不同于硬件，它是计算机系统的逻辑部件而不是物理部件。软件问题是在开发时期引入的而在测试阶段没能检测出来的故障，而要处理软件故障需要修改软件原来的设计，这将使软件的开发成本大大增加；
• 软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。为了在预定时间内开发出规模庞大的软件，必须由许多人分工合作，软件开发工作量随软件规模增大非线性增长；
• 与早期软件开发个体化特点有关：认为软件开发就是写程序并设法使之运行，轻视需求分析和软件维护。也就是说是和软件开发和维护有关的许多错误认识和作法的形成，可以归因于在计算机系统发展的早期阶段软件开发的个体化特点；
• 缺乏正确的理论指导。缺乏有力的方法学和工具方面的支持。由于软件开发不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件开发产品的个性化，也是发生软件开发危机的一个重要原因。

software crisis的表现：

• 对软件开发成本和进度的估计常常很不准确。这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量，从而不可避免地会引起用户的不满。
• 用户对“已完成的”软件系统不满意的现象经常发生。软件开发人员和用户之间的信息交流往往很不充分，“闭门造车”必然导致最终的产品不符合用户的实际需要。
• 软件质量保证技术（审查、复审和测试） 没有坚持不懈地应用到软件开发全过程中。
• 软件常常是不可维护的。由于开发过程没有统一的、公认的规范，软件开发人员按各自的风格工作，各行其是。很多程序中的错误是非常难改正的，实际上不可能使这些程序适应新的硬件环境，难适应用户要求增加的新的功能需求，软件的复用性不高。
• 软件通常没有适当的文档资料。计算机软件不仅仅是程序，还应该有一整套文档资料。这些文档资料应该是在软件开发过程中产生出来的，而且应该是“最新式的”（即和程序代码完全一致的）。软件通常没有适当的文档资料，文档资料的作用是：管理和评价软件开发过程的进展情况，开发者与用户和开发者之间通信的工具，维护工具。
• 软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程fe的不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本随着通货膨胀以及软件，规模和数量的不断扩大而持续上升。1985年美国软件成本占计算机系统总成本的比例90%。
• 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

软件的生命周期

软件生命周期一般包括可行性分析与计划、需求分析、设计 (概要 设计和详细设计)、编码实现、测试、运行与维护等活动。这些活 动应当以适当的方式分配到不同的阶段去完成。

• 可行性分析与计划

  • 确定软件开发的总体目标，给出功能、性能、可靠性以及接口 等方面的要求，进行可行性分析。
  • 估计可利用的开发资源 (硬件、软件、人力等)、成本、效益、 开发进度，进行投资-收益分析，制订开发计划。
  • 提交可行性分析报告、开发计划等文档。

• 需求分析

  • 分析用户提出的要求，给出用户需求详细定义，确定软件系统 的各项功能、性能需求和设计约束，确定对文档编制的要求。

  • 提交软件需求说明、软件规格说明、数据要求说明等文档和初

    步的用户手册。

• 设计

  • 概要设计/逻辑设计:把各项软件需求转换成软件的体系结构。 结构中的每一个组成部分意义明确，并和某些需求相对应。
  • 详细设计/物理设计:对按照概要设计分解的每个模块所要完成 的工作进行具体的描述，提供源程序代码编写的直接依据。
  • 提交概要结构设计说明书、详细设计说明书和测试计划初稿等 文档。

• 实现

  • 完成源程序的编码、编译 (或汇编) 和运行调试，得到没有语法错误的程序清单。程序结构良好、清晰易读，且与设计相一致。
  • 编写进度日报、周报和月报 (取决于项目的重要性和规模)。
  • 编制测试计划。
  • 提交用户手册、操作手册等面向用户的文档。

• 测试

  • 全面测试目标软件系统，并检查审阅已编制的文档，提交测试分析报告。逐项评价所实现的程序、文档以及开发工作本身，提交项目开发总结报告。

• 运行与维护

  • 软件提交给用户后，在运行使用中得到持续维护，根据用户新 提出的需求进行必要而且可能的扩充、删改、更新和升级。
  • 软件维护包括改正性维护 (发现错误)、适应性维护 (适应运行环境变化) 和完善性维护 (增强功能)。

SWEBoK 的 15 个知识域

• Software Requirement 软件需求：软件需求表达了对软件产品的需求和限制，这些需求的约束有助于解决一些现实问题；
• Software Design 软件设计：软件设计（结果）必须描述软件体系结构—即软件如何分解和组织成组件以及这些组件之间的接口。它还必须描述能够构建它们的详细程度的组件；
• Software Construction 软件结构：软件结构是指通过结合详细设计，编码，单元测试，集成测试，调试和验证来详细创建工作软件；
• Software Testing 软件测试：是一项旨在评估产品质量并通过识别缺陷来改进产品质量的活动；
• Software Maintenance 软件维护：增强现有功能，调整软件以在新的和修改的操作环境中运行，以及纠正缺陷；
• Software Configuration Management 软件配置管理：在不同时间点识别系统配置的规则，用于系统地控制配置的改变，以及在整个软件生命周期中维持配置的完整性和可追溯性；
• Software Engineering Management 软件工程管理：涉及规划、协调、测量、报告和控制项目或程序，以确保软件的开发和维护是系统化的、规范化的和量化的；
• Software Engineering Process 软件工程过程：关注软件生命周期过程的定义、实施、评估、测量、管理和改进；
• Software Engineering Models and Methods 软件工程模型与方法：解决涵盖多个生命周期阶段的方法；其他KAs涵盖特点生命周期阶段的特定方法；
• Software Quality 软件质量：许多SWEBOK V3 KAs中普遍存在的软件生命周期问题；
• Software Engineering Professional Practice 软件工程专业实践：关注软件工程师必须具备的专业，负责和道德的软件工程知识，技能和态度；
• Software Engineering Economics 软件工程经济学：关注在业务环境中作出抉择，以使技术决策与组织的业务目标保持一致；
• Computing Foundations 计算基础：提供软件工程实践所需的计算背景的基础主题；
• Mathematical Foundations 数学基础：提供软件工程实践所需的数学背景的基础主题；
• Engineering Foundations 工程基础：提供软件工程实践所需的工程背景的基础主题；

CMMI 的五个级别

Level 1-初始级 ：软件工程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力，管理是反应式的；

Level 2-可管理级：建立了基本的项目管理过程来跟踪费用、进度和功能特性；制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验；

Level 3-已定义级：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的；

Level 4-量化管理级：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能；

Level 5-优化管理级：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

SWEBoK & CMMI

软件工程知识体系（SWEBoK）是IEEE为克服软件危机而构建软件生产的最佳实践与相关知识的框架，来指导软件工程人才的培养与学科建设。

能力成熟度模型集成（CMMI）是一种改进过程的方法，其目的是协助提升组织的绩效，增强开发与改进能力，从而能够按时、不超预算地开发出高质量的软件。