系统分析与设计作业 1

简答

1. 软件工程的定义

首先翻译一下来自Wikipedia的定义：软件工程是进行软件开发，操作和维护的一种系统化，规范化，可量化的方法，是工程实践在软件开发上的应用和研究。
按照我自己的理解，软件工程就是对于软件开发的每一个步骤（开发，操作，维护，成本……）的一个全方位的考量，是管理一款软件全部生产流程的学科。

2. 解释导致 software crisis 本质原因、表现，述说克服软件危机的方法

• 本质原因： 随着计算机的发展，软件的需求越来越复杂，软件规模变得越来越大，计算能力依照摩尔定律进行提升，因此落后的软件生产方式无法控制满足这样的需求，因此产生了软件危机；
• 表现： 比如软件开发进度难以预测，软件开发成本难以控制，用户对产品功能难以满足，软件产品质量无法保证，软件产品难以维护，软件缺少适当的文档资料等；
• 客服软件危机的方法： 首先要引入先进的管理办法，这就是软件工程要学习的内容；

3. 软件生命周期

就是对软件开发的各个过程进行了划分，主要可以划分为以下的几个阶段：

可行性分析与计划，需求分析，设计，编码实现，测试，运行和维护

人们又建立了不同的软件生命周期模型，比如瀑布法，划分了五个过程（Requirement需求；Design设计；Implementation编码实现；Verification验证测试；Maintenance维护），其它的模型有不同的划分；

4. SWEBoK 的 15 个知识域（An Overview of the SWEBOK Guide 请中文翻译其名称与简短说明）

2 软件工程实践中的知识领域

• 2.1 Software Requirements 软件要求
  涉及软件要求的启发、协商、分析、规范和验证。软件行业普遍承认, 当软件工程项目执行不力时, 这些项目就会非常脆弱。软件需求表达了对软件产品的需求和限制, 这些需求和约束有助于解决一些现实世界的问题。

• 2.2 Software Design 软件设计
  设计系统或组件的体系结构、组件、接口和其他特征的过程和结果 (ieee 1991)。

• 2.3 Software Construction 软件构建
  指通过详细设计、编码、单元测试、集成测试、调试和验证相结合的方式, 详细创建工作软件。

• 2.4 Software Testing 软件测试
  测试是一项通过识别缺陷来评估产品质量和改进产品质量的活动。软件测试涉及针对有限的测试用例集上的预期行为对程序的行为进行动态验证。

• 2.5 Software Maintenance 软件维护
  软件维护包括增强现有功能、调整软件以在新的和改进的操作环境中运行以及纠正缺陷。

• 2.6 Software Configuration Management 软件配置管理
  软件配置管理 (scm) 是在不同时间点识别系统配置的学科, 目的是系统地控制对配置的更改, 以及维护完整性和在整个软件生命周期中配置的可追溯性。

• 2.7 Software Engineering Management 软件工程管理
  软件工程管理包括规划、协调、测量、报告和控制项目或计划, 以确保软件的开发和维护是系统的、有纪律的和量化的。

• 2.8 Software Engineering Process 软件工程过程
  软件工程负责软件生命周期过程的定义、实施、评估、测量、管理和改进。

• 2.9 Software Engineering Models and Methods 软件工程模型与方法
  软件工程模型和方法 ka 解决了包含多个生命周期阶段的方法。

• 2.10 Software Quality 软件质量
  软件质量是一个普遍存在的软件生命周期问题。

• 2.11 Software Engineering Professional Practice 软件工程专业实践
  软件工程专业实践涉及软件工程师以专业、负责和合乎道德的方式实践软件工程所必须具备的知识、技能和态度。

3 Knowledge Areas Characterizing the Educational Requirements of Software Engineering 软件工程教育要求知识领域

• 3.1 Software Engineering Economics 软件工程经济学
  软件工程经济学负责在业务环境中做出决策, 使技术决策与组织的业务目标保持一致。

• 3.2 Computing Foundations 计算基础
  涵盖了提供软件工程实践所需的计算背景的基本主题。所涉及的主题包括问题解决技术、抽象、算法和复杂性、编程基础知识、并行和分布式计算的基础知识、计算机组织、操作系统和网络通信。

• 3.3 Mathematical Foundations 数学基础
  为软件工程的实践提供必要的数学背景；

• 3.4 Engineering Foundations 工程基础
  涵盖了为软件工程实践提供必要的工程背景的基本主题。

5. 简单解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式。

成熟度级别 1: 初始 Initial
不可预测和被动。工作已经完成, 但经常被推迟和超出预算。

成熟度级别 2: 托管 Managed
在项目级别上管理。项目是有计划的、执行的、测量的和控制的。

成熟度级别 3: 定义 Defined
主动, 而不是反应。全组织标准为项目、计划和投资组合提供指导。

成熟度级别 4: 量化管理 Quantitatively Managed
测量和控制。本组织以数据为导向, 实现量化的业绩改进目标, 这些目标是可预测的, 并与之保持一致, 以满足内部和外部利益攸关方的需求。

成熟度级别 5: 优化 Optimizing
稳定灵活。本组织注重持续改进, 旨在对机遇和变化进行支点和反应。组织的稳定性为敏捷性和创新提供了一个平台。

6. 用自己语言简述 SWEBok 或 CMMI （约200字）

SWEBok：是IEEE组织的一个项目，软件工程知识体系指南。在这本指南中，IEEE首次建立了软件工程领域知识体系的基线，他们的工作满足了部分想要促进该领域理论和实践的进展的想法。在这之前，社会上的相关工作受到了历史学科经验的指导，但没有受到一些遇到的问题或者解决方法的帮助。它是对过去几年不断发展和演变的知识体系的一个概略和指南，这个知识体系不是静态的，必须随着软件工程的成熟而发展和演变，是软件工程基础设施中一个有价值的元素。

CMMI：全称是Capability Maturity Model Integration，即能力成熟度模型集成，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。