系统分析与设计第一次作业

软件工程的定义

1993年，电气电子工程师学会（IEEE）给出了一个定义：“将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中”。

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

本质原因是：计算机能力的迅速提高和无法解决的问题的复杂性。随着软件复杂性的提高，由于现有方法不足，许多软件问题涌现了出来。
通俗点说，没有计算机时，根本没有编程上的问题；有了一些没那么强的计算机时，编程的问题出现了，但问题不大；现在计算机越来越强大，编程也就越来越复杂，也随之成为一个庞大而复杂的问题。
表现：
项目运行超预算
项目运行超时
软件效率很低
软件质量很差
软件通常不符合需求
项目难以管理，代码难以维护
软件从未交付过
克服软件危机的方法：
针对软件危机的本质原因，当务之急就是构建软件生产的最佳实践与知识体系，发展更好的软件开发和管理方法，比如面向过程编程(PP)、面向对象编程(OOP)、面向切面编程(AOP)等都是过去十年来提出的用来改善软件质量管理的方法。但软件由于其自身的复杂性，很容易被这样那样的不可预测的问题所侵袭，所以只能说尽可能地避免或者减少其问题，而很难完全解决软件危机。

软件生命周期

软件生命周期是指软件的产生直到成熟的全部过程。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

生命周期的每一个周期都有确定的任务，并产生一定规格的文档（资料），提交给下一个周期作为继续工作的依据。按照软件的生命周期，软件的开发不再只单单强调“编码”，而是概括了软件开发的全过程。软件工程要求每一周期工作的开始只能必须是建立在前一个周期结果“正确”前提上的延续；因此，每一周期都是按“活动 ── 结果 ── 审核 ── 再活动 ── 直至结果正确”循环往复进展的。

典型划分GB8567（4个时期7个阶段）：

1.软件分析时期：问题定义、可行性研究、需求分析

2.软件设计时期：总体设计、详细设计

3.编码与测试时期：编码、测试

4.与维护时期

SWEBok的15个知识域

• Software Requirements：软件需求
  关注软件需求的启发，协商，分析，规范和验证。软件需求表达了对软件产品的需求(needs)和限制，有助于解决一些现实问题。

• Software Design：软件设计
  定义系统或组件的体系结构，组件，接口和其他特征的过程以及该过程的结果。

• Software Construction: 软件构建
  指通过结合详细设计，编码，单元测试，集成测试，调试和验证来详细创建工作软件。

• Software Testing：软件测试
  测试是一项旨在通过识别缺陷来评估产品质量并改进产品质量的活动。

• Software Maintenance：软件维护
  软件维护包括增强现有功能，调整软件以在新的和修改的操作环境中运行，以及纠正缺陷。这些类别称为完善，自适应和纠正性软件维护。

• Software Configuration Management：软件配置管理
  软件配置管理（SCM）是在不同时间点识别系统配置的规训(discipline)，用于系统地控制配置的改变，以及在整个软件生命周期中维持配置的完整性和可追溯性。

• Software Engineering Management：软件工程管理
  软件工程管理涉及规划，协调，测量，报告和控制项目或程序，以确保软件的开发和维护是系统化的，规范化的和量化的。

• Software Engineering Process：软件工程过程
  关注软件生命周期过程的定义，实施，评估，测量，管理和改进。

• Software Engineering Models and Methods：软件工程模型和方法
  解决了涵盖多个生命周期阶段的方法。

• Software Quality：软件质量
  是许多SWEBOK V3 KAs中普遍存在的软件生命周期关心问题。

• Software Engineering Professional Practice：软件工程专业实践
  关注软件工程师要专业、负责、道德地实践软件工程所必须具备的知识，技能和态度。
  软件工程基础教育要求：

• Software Engineering Economics ：软件工程经济学
  软件工程经济学KA关注的是在业务环境中做出决策，以使技术决策与组织的业务目标保持一致。

• Computing Foundations：计算基础
  计算基础KA涵盖了提供软件工程实践所需的计算背景的基础主题。

• Mathematical Foundations：数学基础
  数学基础KA涵盖了提供软件工程实践所必需的数学背景的基础主题。涵盖的主题包括集合，关系和功能;基本命题和谓词逻辑;证明技巧;图论和树;离散概率;语法和有限状态机;数论。

• Engineering Foundations：工程基础
  工程基础KA涵盖了提供软件工程实践所必需的工程背景的基础主题。涵盖的主题包括经验方法和实验技术;统计分析;测量和指标;工程设计;仿真与建模;根本原因分析。

简单解释CMMI的五个级别

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

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

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

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

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

用自己的语言简述SWEBok或CMMI

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