系统分析与设计第一周作业
软件工程的定义
软件工程学科诞生后，人们为软件工程给出了不同的定义，例如最早的定义是由 F.L. Bauer 给出的，即”软件工程是为了经济地获得能够在实际机器上高效运行的、可靠的软件而建立和应用一系列坚实的软件工程原则”。而美国梅隆卡耐基大学软件工程研究所（SEI）给出的定义则是软件工程是以工程的形式应用计算机科学和数学原理，从而经济有效地解决软件问题。但目前普遍使用的软件工程定义是由 IEEE 给出的，即软件工程是将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护。
软件工程概念实际存在两层含义，从狭义概念看，软件工程着重体现在软件过程中所采用的工程方法和管理体系，例如，引入成本核算、质量管理和项目管理等，即将软件产品开发看作是一项工程项目所需要的系统工程学和管理学。从广义概念看，软件工程涵盖了软件生命周期中所有的工程方法、技术和工具，包括需求工程、设计、编程、测试和维护的全部内容，即完成一个软件产品所必备的思想、理论、方法、技术和工具。
解释导致 software crisis 本质原因、表现，述说克服软件危机的方法
原因：
- 软件的规模越来越大，结构越来越复杂。
- 软件开发管理困难而复杂。
- 软件开发费用不断增加。
- 软件开发技术落后。
- 生产方式落后。
- 开发工具落后，生产率提高缓慢。
表现：
- 经费预算经常突破，完成时间一再拖延。由于缺乏软件开发的经验和软件开发数据的积累，使得开发工作的计划很难制定。主观盲目制定计划，执行起来与实际情况有很大差距，使得开发经费一再突破。由于对工作量估计不足，对开发难度估计不足，进度计划无法按时完成，开发时间一再拖延。
- 开发的软件不能满足用户要求。开发初期对用户的要求了解不够明确，未能得到明确的表达。开发工作开始后，软件人员和用户又未能及时交换意见，使得一些问题不能及时解决，导致开发的软件不能满足用户的要求，因而导致开发失败。
- 开发的软件可维护性差。开发过程中没有同意的、公认的规范，软件开发人员按各自的风格工作，各行其是，开发过程无完整、规范的文档，发现问题后进行杂乱无章的修改。程序结构不好，运行时发现错误也很难修改，导致维护性差。
- 开发的软件可靠性差。由于在开发过程中，没有确保软件质量的体系和措施，在软件测试时，又没有严格的、充分的、完全的测试，提交给用户的软件质量差，在运行中暴露出大量的问题。
克服：
为了消除软件危机，首先应该对计算机软件有一个正确的认识。正如上面所说，应该彻底消除在计算机系统早期发展阶段形成的“软件就是程序”的错误观念。一个软件必须由一个完整的配置组成，事实上，软件是程序、数据及相关文档的完整集合。其中，程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当的处理信息的数据结构；文档是开发、使用和维护所需要的图文资料。
更重要的是，必须充分认识到软件开发不是某个个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合共同完成的工程项目。必须充分吸收和借鉴人类长期以来从事各种工作项目所积累的行之有效的原理、概念、技术和方法。特别要吸收几十年来人类从事计算机硬件研究和开发的经验教训。
应该推广使用在实践总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的错误观念和做法。
应该开发和使用更好的软件工具。正如机械工具可以“放大”人类体力一样，软件工具可以“放大”人类的智力。在软件开发的每个阶段都有许多烦琐重复的工作需要完成，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。如果把各个阶段使用的软件工具有机的集合成一个整体，支持软件开发的全过程，则称为软件工程支撑环境。
软件生命周期
六大阶段：
- 可行性分析和计划阶段
- 确定软件开发的总体目标，给出功能，性能，可靠性，接口等方面的要求，进行可行性分析
- 估计可利用的资源(硬件，软件，人力等)，成本，效益，开发进度，进行投资收益分析，制定开发计划
- 提交可行性分析报告，开发计划等文档
- 需求分析阶段
- 分析用户提出的要求，给出需求详细定义，确定软件系统的各项功能，性能需求和设计约束，确定对文档的编制的要求
- 提交软件需求说明，软件规格说明，数据要求说明等文档和初步用户手册
- 设计阶段
- 概要设计：将各项需求转换为软件的体系结构。软件的每一组成部分都是意义明确的模块，每个模块和某些需求相对应
- 详细设计：对没一个模块要完成的工作进行具体的描述，提供源编程编写的直接依据
- 提交结构设计说明，详细设计说明和测试计划初稿等文稿
- 实现阶段
- 实现源码编码，编译，和排错调试，得到没有语法错误的程序清单。程序结构良好，清晰易读，且与设计想一致
- 编写进度日报，周报，和月报
- 提交用户手册，操作手册等面向用户的文档的编写工作
- 编写测试计划
- 测试阶段
- 全面测试目标软件系统，并检查审阅已编制的文档，提交测试分析报告。逐项评价所生产的程序、文档以及开发工作本身，提交项目开发总结报告
- 在整个开发过程中 (即前五个阶段中)，开发集体需要按月编写
开发进度月报。
- 运行与维护阶段
- 软件提交给用户后，在运行使用中得到持续维护，根据用户新
提出的需求进行必要而且可能的扩充、删改、更新和升级。 - 软件维护包括改正性维护 (发现错误)、适应性维护 (适应运行
环境变化) 和完善性维护 (增强功能)。
- 软件提交给用户后，在运行使用中得到持续维护，根据用户新
常见模型：
- 瀑布模型 (Waterfall Model)
- V-W 模型 (V Model and W Model)
- 快速应用开发模型 (RAD Model)
- 原型模型 (Prototype Model)
- 增量/演化/迭代模型 (Incremental Model)
- 螺旋模型 (Spiral Model)
- 喷泉模型 (Fountain Model, Object-Oriented Model)
- 基于构件的开发模型 (CBSD Model)
- Rational 统一过程模型 (RUP Model)
- *敏捷开发模型与极限编程 (Agile Modeling and XP)
- 可行性分析和计划阶段
SWEBoK 的 15 个知识域（An Overview of the SWEBOK Guide 请中文翻译其名称与简短说明）
- 软件需求：软件要求 KA 关注软件需求的启发，协商，分析，规范和验证。在软件行业中，人们普遍认为，当这些活动表现不佳时，软件工程项目非常容易受到攻击。软件需求表达了对软件产品的需求和限制，这些需求和约束有助于解决一些现实问题。
- 软件设计：设计被定义为定义系统或组件的体系结构，组件，接口和其他特征的过程以及[该]过程的结果（IEEE 1991）。软件设计 KA 涵盖了设计过程和最终产品。软件设计过程是软件工程生命周期活动，其中分析软件需求以产生软件内部结构及其行为的描述，将作为其构造的基础。软件设计（结果）必须描述软件体系结构——即软件如何分解和组织成组件以及这些组件之间的接口。它还必须描述能够构建它们的详细程度的组件。
- 软件构建：软件构建是指通过结合详细设计，编码，单元测试，集成测试，调试和验证来创建工作软件的细节。软件构建 KA 包括与满足其要求和设计约束的软件程序开发相关的主题。该 KA 涵盖了软件构建基础;管理软件建设；建筑技术；实际考虑；和软件构建工具。
- 软件测试：测试是一项旨在评估产品质量并通过识别缺陷来改进产品质量的活动。软件测试涉及在有限的测试用例集上针对预期行为动态验证程序的行为。这些测试用例是从（通常非常大的）执行域中选择的。软件测试 KA 包括软件测试的基础知识；测试技术；人机界面测试与评估；与测试有关的措施；和实际考虑。
- 软件维护：软件维护包括增强现有功能，调整软件以在新的和修改的操作环境中运行，以及纠正缺陷。这些类别称为完善，自适应和纠正性软件维护。软件维护 KA 包括软件维护的基础知识（维护的性质和需求，维护类别，维护成本）；软件维护中的关键问题（技术问题，管理问题，维护成本估算，软件维护测量）；维护过程;软件维护技术（程序理解，重新设计，逆向工程，重构，软件退役）；灾难恢复技术和软件维护工具。
- 软件配置管理：系统的配置是硬件，固件，软件或这些的组合的功能和/或物理特征。它还可以被视为根据特定构建过程组合的特定版本的硬件，固件或软件项的集合，以满足特定目的。因此，软件配置管理（SCM）是在不同时间点识别系统配置的规则，用于系统地控制配置的改变，以及在整个软件生命周期中维持配置的完整性和可追溯性。软件配置管理 KA 涵盖 SCM 过程的管理；软件配置识别，控制，状态核算，审计；软件发布管理和交付；和软件配置管理工具。
- 软件工程管理：软件工程管理涉及规划，协调，测量，报告和控制项目或程序，以确保软件的开发和维护是系统化的，规范化的和量化的。软件工程管理 KA 涵盖了启动和范围定义（确定和协商要求，可行性分析以及要求的审查和修订）；软件项目计划（过程计划，工作量估算，成本和进度，资源分配，风险分析，质量计划）；软件项目制定（计量，报告和控制;收购和供应商合同管理）；产品验收；审查和分析项目绩效；项目结束；和软件管理工具。
- 软件工程过程：软件工程 KA 关注软件生命周期过程的定义，实施，评估，测量，管理和改进。涵盖的主题包括流程实施和变更（流程基础架构，流程实施和变更模型以及软件流程管理）；流程定义（软件生命周期模型和流程，流程定义，流程适应和流程自动化的符号）；过程评估模型和方法；测量（过程测量，产品测量，测量技术和测量结果的质量）；和软件处理工具。
- 软件工程模型和方法：软件工程模型和方法 KA 解决了涵盖多个生命周期阶段的方法;其他KAs涵盖特定生命周期阶段的特定方法。涵盖的主题包括建模（软件工程模型的原理和属性;语法与语义与不变量；前置条件，后置条件和不变量）；模型类型（信息，结构和行为模型）；分析（分析正确性，完整性，一致性，质量和相互作用；可追溯性；以及权衡分析）；和软件开发方法（启发式方法，形式方法，原型方法和敏捷方法）。
- 软件质量：软件质量是许多 SWEBOK V3 KAs 中普遍存在的软件生命周期问题。此外，软件质量 KA 还包括软件质量的基础知识（软件工程文化，软件质量特性，软件质量的价值和成本以及软件质量改进）；软件质量管理流程（软件质量保证，验证和确认，审核和审核）；和实际考虑（缺陷表征，软件质量测量和软件质量工具）。
- 软件工程专业实践：软件工程专业实践关注软件工程师必须具备的专业，负责和道德的软件工程知识，技能和态度。软件工程专业实践 KA 涵盖专业性（专业行为，专业协会，软件工程标准，雇佣合同和法律问题）；道德准则;小组动态（团队合作，认知问题复杂性，与利益相关者互动，处理不确定性和模糊性，处理多元文化环境）；和沟通技巧。
- 软件工程经济学：软件工程经济学 KA 关注的是在业务环境中做出决策，以使技术决策与组织的业务目标保持一致。涵盖的主题包括软件工程经济学的基本原理（提案，现金流量，货币时间价值，计划视野，通货膨胀，折旧，替代和退休决策）；非营利性决策（成本效益分析，优化分析）；估计，经济风险和不确定性（估算技术，风险决策和不确定性）；和多属性决策（价值和衡量尺度，补偿和非补偿技术）。
- 计算基础：计算基础 KA 涵盖了提供软件工程实践所需的计算背景的基础主题。涵盖的主题包括问题解决技术，抽象，算法和复杂性，编程基础，并行和分布式计算的基础知识，计算机组织，操作系统和网络通信。
- 数学基础：数学基础 KA 涵盖了提供软件工程实践所必需的数学背景的基础主题。涵盖的主题包括集合，关系和功能；基本命题和谓词逻辑；证明技术；图形和树；离散概率；语法和有限状态机；和数论。
- 工程基础：工程基础 KA 涵盖了提供软件工程实践所必需的工程背景的基础主题。涵盖的主题包括经验方法和实验技术；统计分析；测量和指标；工程设计；仿真与建模；和根本原因分析。
简单解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式。
初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
可管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
优化管理级
过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性：
每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。
用自己语言简述 SWEBok 或 CMMI （约200字）
CMMI 全称是 Capability Maturity Model Integration，即能力成熟度模型集成（ 也有称为：软件能力成熟度集成模型）。
定义：对于软件组织在定义、实现、度量、控制和 改善其软件过程的各个发展阶段的描述。
目的：帮助企业进行对软件工程过程的管理和改进 , 增强开发制造能力 , 从而能按时地、不超预算地制造质量的软件。
通俗一点说，CMMI就是一套指南，做事的一般方法，改进质量的参考框架。我们参考它提供的方法，通过控制我们的项目管理过程，来达到提高软件质量的目的。
CMMI为企业带来价值主要体现在以下几个方面：
对开发流程进行标准化和规范化，保证项目进度和质量。
有利于成本控制，缩减不必要的项目开支。
- 建立完备的知识库，不畏惧人才流失。
- 持续改善流程，提高质量和效率。
- 在一些投标项目竞争中，更具有优势。——这也是一般外包公司特别重视这个证的原因。
- 来自美国制定的国际标准，更能得到国外的认可。——所以一般软件公司要准备融资上市前都力争拿到此证的原因。
评论