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

目录

• 软件工程的定义
• 解释导致 software crisis 本质原因、表现，述说克服软件危机的方法
• 软件生命周期
• SWEBoK 的 15 个知识域
• 简单解释 CMMI 的五个级别
• 用自己语言简述 SWEBok 或 CMMI
  
  

正文

软件工程的定义

软件工程是：
（1）应用系统的，规范的，可量化的方法来开发，操作和维护软件，即将工程上的方法应用到软件（开发）上
（2）除此之外，对于（1）中提到的方法的研究，也计入软件工程范畴

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

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

• 概括地说，软件危机包含下述两方面的问题：
  （1）如何开发软件，以满足对软件日益增长的需求；
  （2）如何维护数量不断膨胀的已有软件。

• 产生软件危机的本质原因：
  软件危机是由计算机能力的迅速增加以及无法解决的问题的复杂性造成的。随着软件复杂性的增加，因为现有方法不足，出现了许多软件问题。

• 软件危机典型表现：
  项目运行超预算
  项目运行时间过长
  软件效率很低
  软件质量很差
  软件通常不符合要求
  项目难以管理，代码难以维护
  软件从未交付过

• 克服软件危机的方法
  (1) 充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法，特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训。在开发软件的过程中努力作到良好的组织，严格的管理，相互友好的协作；
  (2) 推广在实践中总结出来的开发软件的成功的技术和方法，并研究更好、更有效的技术和方法，尽快克服在计算机系统早期发展阶段形成的一些错误概念和作法；
  (3) 根据不同的应用领域，开发更好的软件工具并使用这些工具。将软件开发各个阶段使用的软件工具集合成一个整体，形成一个很好的软件开发支环环境；
  总之为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。

软件生命周期

和其它事务一样，一个软件产品或者软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，这个过程就称为软件生命周期。
可以把整个软件生命周期分成若干个阶段，使得每个阶段有明确的任务，使规模大、结构复杂和管理复杂的软件开发变得容易控制和管理。通常，软件生存周期包括：

• 问题的定义及规划
  此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
• 需求分析
  在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。
• 软件设计
  此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。
  软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
  软件设计的核心在于把握好那些决定“服务质量”的因素，比如软件的性能，可扩展性，安全性，怎样划分模块的组成，怎样组织和封装软件的组件，以及其他一些虽然不作为软件主要应用的方面但会对其支持方面有所影响的方方面面。
  软件设计的原理包括抽象，分解和模块化，耦合和内聚，封装，充分性，完整性和原始性。软件设计主要关注软件的兼容性、可扩展性、容错性、可维护性、模块化、可靠性、可重用性、健壮性、安全性、可用性和互操作性。耦合和内聚是两个用来评估软件设计质量的方法。
• 程序编码
  此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
• 软件测试
  在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性
• 运行维护
  软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

周期模型：
从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。
典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。

SWEBoK 的 15 个知识域

（An Overview of the SWEBOK Guide 请中文翻译其名称与简短说明）

• 软件工程实践相关的知识领域

  • 软件需求
    软件需求知识领域关注软件需求的启发，协商，分析，规范和验证。在软件行业中，人们普遍认为，当这些活动表现不佳时，软件工程项目非常容易受到攻击。软件需求表达了对软件产品的需求和限制，这些需求和约束有助于解决一些现实问题。

  • 软件设计
    定义系统或者组件的体系结构、组件、接口和其他特征的过程，以及这个过程所得到的结果

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

  • 软件测试
    测试是一项旨在评估产品质量并通过识别缺陷来改进产品质量的活动。软件测试涉及在有限的测试用例集上针对预期行为动态验证程序的行为。这些测试用例是从（通常非常大的）执行域中选择的。软件测试知识领域包括软件测试的基础知识; 测试技术; 人机界面测试与评估等。

  • 软件维护
    软件维护包括增强现有功能，调整软件以在新的和修改的操作环境中运行，以及纠正缺陷。这些类别称为完善，自适应和纠正性软件维护。软件维护知识领域包括软件维护的基础知识（维护的性质和需求，维护类别，维护成本）; 软件维护中的关键问题（技术问题，管理问题，维护成本估算，软件维护测量）; 维护过程; 软件维护技术（程序理解，重新设计，逆向工程，重构，软件退役）; 灾难恢复技术和软件维护工具。

  • 软件配置管理
    系统的配置是硬件，固件，软件或这些的组合的功能和/或物理特征。它还可以被视为根据特定构建过程组合的特定版本的硬件，固件或软件项的集合，以满足特定目的。因此，软件配置管理（SCM）是在不同时间点识别系统配置的规则，用于系统地控制配置的改变，以及在整个软件生命周期中维持配置的完整性和可追溯性。软件配置管理KA涵盖SCM过程的管理; 软件配置识别，控制，状态核算，审计; 软件发布管理和交付;

  • 软件工程管理
    软件工程管理涉及规划，协调，测量，报告和控制项目或程序，以确保软件的开发和维护是系统化的，规范化的和量化的。软件工程管理知识领域涵盖了启动和范围定义（确定和协商要求，可行性分析以及要求的审查和修订）; 软件项目计划（过程计划，工作量估算，成本和进度，资源分配，风险分析，质量计划）; 软件项目制定（计量，报告和控制;收购和供应商合同管理）; 产品验收; 审查和分析项目绩效; 项目结束等。

  • 软件工程过程
    软件工程知识领域关注软件生命周期过程的定义，实施，评估，测量，管理和改进。

  • 软件工程模型和方法
    软件工程模型和方法知识领域解决了涵盖多个生命周期阶段的方法;

  • 软件质量
    软件质量是许多SWEBOK V3 知识领域中普遍存在的软件生命周期问题。此外，软件质量知识领域还包括软件质量的基础知识（软件工程文化，软件质量特性，软件质量的价值和成本以及软件质量改进）; 软件质量管理流程（软件质量保证，验证和确认，审核和审核）; 和实际考虑（缺陷表征，软件质量测量和软件质量工具）。

  • 软件工程专业实践
    软件工程专业实践关注软件工程师必须具备的专业，负责和道德的软件工程知识，技能和态度。软件工程专业实践知识领域涵盖专业性（专业行为，专业协会，软件工程标准，雇佣合同和法律问题）; 道德准则; 小组动态（团队合作，认知问题复杂性，与利益相关者互动，处理不确定性和模糊性，处理多元文化环境）和沟通技巧。

• 软件工程教育要求相关的知识领域

  • 软件工程经济学
    软件工程经济学知识领域关注的是在业务环境中做出决策，以使技术决策与组织的业务目标保持一致。涵盖的主题包括软件工程经济学的基本原理（提案，现金流量，货币时间价值，计划视野，通货膨胀，折旧，替代和退休决策）; 非营利性决策（成本效益分析，优化分析）; 估计，经济风险和不确定性（估算技术，风险决策和不确定性）; 和多属性决策（价值和衡量尺度，补偿和非补偿技术）。

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

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

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

简单解释 CMMI 的五个级别

• Maturity Level 1 - Initial
  无序，自发产生模式
• Maturity Level 2 - Managed
  建立基本管理过程，能借鉴已有项目的成功经验。缺点是只能借鉴已有的项目，不够系统，比较被动。
• Maturity Level 3 - Defined
  管理过程组织化，项目根据组织的标准进行，主动性增强
• Maturity Level 4 - Quantitatively Managed
  量化管理，过程可控，管理操作有理论依据，结果性能可预测
• Maturity Level 5 - Optimizing
  过程的量化反馈和先进的新思想、新技术促使管理过程不断改进。
  每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。

用自己语言简述 SWEBok 或 CMMI

下面自己选择简述CMMI：

• CMMI英文全称是Capability Maturity Model Integration，即成熟度模型，由卡耐基梅隆大学的软件工程学院（SEI）注册，这个模型总结了大量成功企业研发软件的习惯、准则等，如果一个企业能够按照CMMI里面的准则来完成自己的软件开发，那么这个企业就很有可能成为下一个成功的企业。

• CMMI里面所有的要求，都是来自于成功企业的最佳实践的，它的优秀毋庸置疑，如果一个企业按照CMMI的准则执行了，但是最后仍然没有取得成功，那么不是CMMI本身的问题，而是我们自己没有理解好或者是没有执行好CMMI。

• CMMI有两种表述方式：连续式与阶段式，两种方式只是从不同的角度来阐述CMMI，其实质上表达的内容是一致的。就好像我们做数据库设计的时候，可能会设计不同的视图来查看相同数据表的数据，只是角度不一样。
  之所以会有这两种方式，是因为SEI内部有两派，一派支持连续式，一派支持阶段式，互不相让，最后无法达成一致，于是同时就有连续式与阶段式两种表达方式。
  连续式更加能反应过程改进的本质，并且能更好地引导企业把过程改进做到实处，但连续式比较难以理解。
  阶段式是直接继承CMM（即CMMI的前身，现在已经不用了）的，大家都比较容易理解，而且阶段式有级别之分，便于企业在商业上进行宣传，但很容易导致企业为了过级而过级。
  用连续式评估，企业会得到很多个PA的Level，用阶段式评估，企业会得到一个整体的Level。

• CMMI 1至5级简述在前面：简单解释 CMMI 的五个级别提到过了，就不说了
  下面说一下评级的方法：
  第1级是不需要评估的，哪怕你们是手工作坊开发的软件公司，也可以说是CMMI1级。从2级开始到5级，SEI在每个级别都有详细的标准。要通过高级别的评估，要满足这个级别以下所有级别的标准。例如：一个进行4级评估的企业，评估的时候首先是看是否达到2级要求，然后是3级要求，然后才是4级要求。评估的时候，如果2级的标准达到，但3级的要求达不到，就算4级的要求达到了，也只能算2级。下面是各个级别的标准：
  

• 看到最后你可能还会疑惑：CMMI不是没啥用吗，这么多标准，会导致成本增加，得不偿失了。
  但是其实我个人不是这样认为的，就好像我们读《成功人士的X个习惯》这种书一样，我们按照其中的习惯做，会让我们自己变得很累，让我们自己很不习惯，但是却能够增大自己成功的概率。
  所以企业也是一样，按照CMMI标准运作，不一定100%成功，但是成功的概率增加了，所以这个标准还是很有用的。
  就像前面说的一样，如果企业遵循CMMI仍然失败了，那么大概率不是CMMI本身的问题，而是我们自己没有理解好或者是没有执行好CMMI。

上面的CMMI简述参考了这篇文章，讲的非常通俗易懂，如果想要更好的了解CMMI，推荐阅读。