系统分析与设计 homework1 软件的本质与软件工程科学

Homework1 软件的本质与软件工程科学

简答题

1.软件工程的定义

• Software engineering is “(1) the application of a systematic, disciplined, quantifiableapproach to the development, operation, and maintenance of software, that is, the application of engineering to software,” and “(2) the study of approaches as in (1).” –– IEEE Standard 610.12

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

• 软件危机的成因
  • 本质原因：
    • 软件的大量需求与软件生产力效率之间的矛盾
    • 软件系统的复杂性与软件开发方法之间的矛盾
  • 软件开发的客观因素
    • 系统需求分析不足
    • 开发周期管理不善
    • 开发过程缺乏规范
    • 软件开发 =?程序编写
    • 质量控制标准规程滞后
    • 软件维护计划被忽视
  • 软件开发的产业因素
    • 软件企业的作坊式管理
    • 软件企业规模的急剧膨胀
• 表现：
  • 经费预算经常突破，完成时间一再拖延
  • 开发的软件不能满足用户要求
  • 开发的软件可维护性差
  • 开发的软件可靠性差
• 克服软件危机
  • 正确认识计算机软件的内涵
  • 采用工程项目管理方法实施软件开发的组织管理
  • 采用成熟的软件开发技术和方法，开发和使用适当的软件工具

3.软件生命周期

• 可行性分析与计划阶段

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

• 需求分析阶段

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

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

    步的用户手册。

• 设计阶段

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

• 实现阶段

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

• 测试阶段

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

• 运行与维护阶段

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

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

1. 软件需求

   ​ 软件需求KA涉及软件需求的引出、协商、分析、规范和确认。软件行业普遍承认，当这些活动执行得不好时，软件工程项目极易受到攻击。软件需求表示对软件产品的需求和约束，这些需求和约束有助于解决一些实际问题。

2. 软件设计

   ​ 设计被定义为定义系统或组件的架构、组件、接口和其他特性的过程，以及[该]过程的结果（IEEE 1991）。软件设计KA涵盖了设计过程和最终产品。软件设计过程是软件工程生命周期活动，在该活动中分析软件需求，以便对软件的内部结构及其行为进行描述，作为其构建的基础。软件设计（结果）必须描述软件架构——也就是说，软件是如何分解和组织成组件的，以及这些组件之间的接口。它还必须在细节层次上描述组件，以实现其构造。

3. 软件建设

   ​ 软件构建是指通过详细设计、编码、单元测试、集成测试、调试和验证的组合来详细创建工作软件。软件构建KA包括与满足其需求和设计约束的软件程序开发相关的主题。本KA涵盖软件构建基础知识、管理软件构建、构建技术、实践考虑和软件构建工具。

4. 软件测试

   ​ 测试是一项评估产品质量并通过识别缺陷来改进产品质量的活动。软件测试涉及根据有限的测试用例集上的预期行为对程序行为进行动态验证。这些测试用例是从（通常非常大）执行域中选择的。软件测试KA包括软件测试的基础知识、测试技术、人机界面测试和评估、测试相关措施和实际考虑。

5. 软件维护

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

6. 软件配置管理

   ​ 系统的配置是硬件、固件、软件的功能和/或物理特性，或这些特性的组合。它还可以被视为硬件、固件或软件项的特定版本的集合，根据特定的构建过程进行组合以满足特定的目的。因此，软件配置管理（SCM）是一门在不同的时间点识别系统配置的学科，目的是系统地控制配置的更改，并在整个软件生命周期中保持配置的完整性和可追溯性。软件配置管理KA包括对SCM过程的管理；软件配置识别、控制、状态核算、审核；软件发布管理和交付；以及软件配置管理工具。

7. 软件工程管理

   ​ 软件工程管理包括计划、协调、测量、报告和控制项目或程序，以确保软件的开发和维护是系统的、有纪律的和量化的。软件工程管理KA包括启动和范围定义（确定和协商需求、可行性分析以及需求的评审和修订）；软件项目规划（过程规划、工作量、成本和进度估计、资源分配、风险分析、质量规划）；软件项目E投资（测量、报告和控制；采购和供应商合同管理）；产品验收；项目绩效的审查和分析；项目结束；以及软件管理工具。

8. 软件工程过程

   ​ 软件工程KA涉及软件生命周期过程的定义、实现、评估、测量、管理和改进。所涵盖的主题包括过程实施和变更（过程基础设施、过程实施和变更模型以及软件过程管理）；过程定义（软件生命周期模型和过程、过程定义注释、过程适应和过程自动化）；过程评估模型和方法；度量（过程测量、产品测量、测量技术和测量结果质量）和软件过程工具。

9. 软件工程模型与方法

   ​ 软件工程模型和方法KA描述了包含多个生命周期阶段的方法；特定于特定生命周期阶段的方法由其他KA涵盖。所涵盖的主题包括建模（软件工程模型的原理和属性；语法与语义与不变量；前提条件、后条件和不变量）；模型类型（信息、结构和行为模型）；分析（分析正确性、完整性、一致性、质量和交互；可追溯性和权衡分析）；和软件开发方法（启发式方法、形式方法、原型方法和敏捷方法）。

10. 软件质量

    ​ 软件质量是一个普遍存在的软件生命周期问题，在许多Swebok v3 KAS中都有解决。此外，软件质量KA包括软件质量基础（软件工程文化、软件质量特征、软件质量的价值和成本以及软件质量改进）；软件质量管理过程（软件质量保证、验证和确认、评审和审计）；以及实用性。l注意事项（缺陷描述、软件质量度量和软件质量工具）。

11. 软件工程专业实践

    ​ 软件工程专业实践涉及软件工程师以专业、负责和道德的方式实践软件工程所必须具备的知识、技能和态度。软件工程专业实践KA涵盖专业性（专业行为、专业协会、软件工程标准、雇佣合同和法律问题）；道德规范；群体动力学（团队合作、认知问题复杂性、与利益相关者互动、处理不确定性和模糊性、处理具有多元文化环境）；以及沟通技巧。

12. 软件工程经济学

    ​ 软件工程经济学KA关注于在业务环境中做出决策，以使技术决策与组织的业务目标保持一致。所涵盖的主题包括软件工程经济学基础（提案、现金流、货币时间价值、规划范围、通货膨胀、折旧、重置和退休决策）；非营利决策（成本效益分析、优化分析）；估算、经济风险和不确定性（估算技术，DEC）风险和不确定性下的ISION）；以及多属性决策（价值和测量尺度、补偿和非补偿技术）。

13. 计算基础

    ​ KA计算基础涵盖了为软件工程实践提供必要计算背景的基本主题。所涵盖的主题包括问题解决技术、抽象、算法和复杂性、编程基础、并行和分布式计算基础、计算机组织、操作系统和网络通信。

14. 数学基础

    ​ 数学基础KA涵盖了为软件工程实践提供必要数学背景的基本主题。所涉及的主题包括集合、关系和函数；基本命题和谓词逻辑；证明技术；图和树；离散概率；语法和有限状态机；以及数论。

15. 工程基础

    ​ 工程基础KA涵盖了为软件工程实践提供必要工程背景的基本主题。涵盖的主题包括经验方法和实验技术；统计分析；测量和度量；工程设计；模拟和建模；以及根本原因分析。

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

1. Initial：过程不可预测、控制不良和反应性差
2. Managed：以项目和为特征的过程通常是反应性的
3. Defined：以组织为特征并具有前瞻性的过程。（项目根据组织的标准定制其过程）
4. Quantitatively Managed：测量和控制的过程
5. Optimizing：专注于流程改进

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

​ 能力成熟度模型集成（CMMI）是一个抽象的模型，可以用于指导项目、部门或者是整个组织的流程改进。它并不是一个标准，需要结合具体的实践。它提供了详细的抽象信息和示例，但是具体的实现方式还是要取决于体系。CMMI整合传统上独立的组织功能，设定流程改进目标和优先级，为质量流程提供指导，并为评估当前流程提供参考。比起SWEBok没办法合适的度量一个企业的软件工程能力，CMMI因为更抽象更适合各种各类的企业去follow。