SWSAD Homework1

1. 软件工程的定义

很多学者、组织机构都分别给出了自己对于软件工程的定义：

Software engineering is the application of engineering to the development of software in a systematic method.[1][2][3]

Notable definitions of software engineering include:

• “the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software”—The Bureau of Labor Statistics—IEEE Systems and software engineering - Vocabulary[4]
• “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”—IEEE Standard Glossary of Software Engineering Terminology[5]
• “an engineering discipline that is concerned with all aspects of software production”—Ian Sommerville[6]
• “the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines”—Fritz Bauer[7]

概括来说：

• 采用工程的概念、原理、技术和方法来开发与维护软件。
• 把经过时间考验的管理技术和当前能够得到的最好的技术方法
  结合起来

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

（1）本质原因：

• 软件危机的根源
  • 软件的大量需求与软件生产力效率之间的矛盾
  • 软件系统的复杂性与软件开发方法之间的矛盾
• 软件本身的特点
  • 软件是一种抽象逻辑
  • 软件是开发人员的智力劳动成果
  • 软件具备强烈的个性化特征
  • 软件规模日趋庞大，实现的业务逻辑与流程复杂
• 软件开发的客观因素
  • 系统需求分析不足
  • 开发周期管理不善
  • 开发过程缺乏规范：软件开发 =？程序编写
  • 质量控制标准规程滞后
  • 软件维护计划被忽视
• 软件开发的产业因素
  • 软件企业的作坊式管理
  • 软件企业规模的急剧膨胀

（2）表现

• 软件开发进度难以预测
  • 拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。
• 软件开发成本难以控制
  • 投资一再追加，令人难于置信。往往是实际成本比预算成本高出一个数量级。
  • 而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量，从而不可避免地会引起用户的不满。
• 用户对产品功能难以满足
  • 开发人员和用户之间很难沟通、矛盾很难统一。往往是软件开发人员不能真正了解用户的需求，而用户又不了解计算机求解问题的模式和能力，双方无法用共同熟悉的语言进行交流和描述。在双方互不充分了解的情况下，就仓促上阵设计系统、匆忙着手编写程序，这种"闭门造车"的开发方式必然导致最终的产品不符合用户的实际需要。
• 软件产品质量无法保证
  • 系统中的错误难以消除。软件是逻辑产品，质量问题很难以统一的标准度量，因而造成质量控制困难。
  • 软件产品并不是没有错误，而是盲目检测很难发现错误，而隐藏下来的错误往往是造成重大事故的隐患。
• 软件产品难以维护
  • 软件产品本质上是开发人员的代码化的逻辑思维活动，他人难以替代。除非是开发者本人，否则很难及时检测、排除系统故障。
  • 为使系统适应新的硬件环境，或根据用户的需要在原系统中增加一些新的功能，又有可能增加系统中的错误。
• 软件缺少适当的文档资料
  • 文档资料是软件必不可少的重要组成部分。实际上，软件的文档资料是开发组织和用户的之间权利和义务的合同书，是系统管理者、总体设计者向开发人员下达的任务书，是系统维护人员的技术指导手册，是用户的操作说明书。
  • 缺乏必要的文档资料或者文档资料不合格，将给软件开发和维护带来许多严重的困难和问题。

（3）克服软件危机的方法

• 正确认识计算机软件的内涵。
• 采用工程项目管理方法实施软件开发的组织管理。
  • 软件开发应该是一种组织良好、管理严密、协同配合的工程活
    动。
• 采用成熟的软件开发技术和方法，开发和使用适当的软件工具。

3. 软件生命周期

软件生命周期的6个阶段：

• 可行性分析与计划阶段
  • 确定软件开发的总体目标，给出功能、性能、可靠性以及接口
    等方面的要求，进行可行性分析。
  • 估计可利用的开发资源 (硬件、软件、人力等)、成本、效益、
    开发进度，进行投资-收益分析，制订开发计划。
  • 提交可行性分析报告、开发计划等文档。
• 需求分析阶段
  • 分析用户提出的要求，给出用户需求详细定义，确定软件系统
    的各项功能、性能需求和设计约束，确定对文档编制的要求。
  • 提交软件需求说明、软件规格说明、数据要求说明等文档和初
    步的用户手册。
• 设计阶段
  • 概要设计/逻辑设计：把各项软件需求转换成软件的体系结构。
    结构中的每一个组成部分意义明确，并和某些需求相对应。
  • 详细设计/物理设计：对按照概要设计分解的每个模块所要完成
    的工作进行具体的描述，提供源程序代码编写的直接依据。
  • 提交概要结构设计说明书、详细设计说明书和测试计划初稿等
    文档。
• 实现阶段
  • 完成源程序的编码、编译 (或汇编) 和运行调试，得到没有语法
    错误的程序清单。程序结构良好、清晰易读，且与设计相一致。
  • 编写进度日报、周报和月报 (取决于项目的重要性和规模)。
  • 编制测试计划。
  • 提交用户手册、操作手册等面向用户的文档。
    软件生命周期的6个阶段
• 测试阶段
  • 全面测试目标软件系统，并检查审阅已编制的文档，提交测试
    分析报告。逐项评价所实现的程序、文档以及开发工作本身，
    提交项目开发总结报告。
• 运行与维护阶段
  • 软件提交给用户后，在运行使用中得到持续维护，根据用户新
    提出的需求进行必要而且可能的扩充、删改、更新和升级。
  • 软件维护包括改正性维护 (发现错误)、适应性维护 (适应运行环
    境变化) 和完善性维护 (增强功能)。
• 软件生命周期的前五个阶段也合称开发阶段。在整个开发阶段，开
  发团队需要按月编写开发进度月报。

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

• 软件工程实践知识领域
  • 软件需求：涉及软件需求的引入、协商、分析、规范和确认，用于对软件产品的需求和约束。
  • 软件设计：设计软件系统的架构、组件、接口、其它特性的过程，以及该过程的结果。
  • 软件构造：通过详细的设计、实现代码、单元测试、集成测试、调试和验证来构造软件。
  • 软件测试：评估产品质量并通过缺陷来改进产品质量。
  • 软件维护：修改现有的软件，使软件适应新的环境，以及修复软件已知的缺陷。
  • 软件配置管理：系统地控制硬件、固件、软件的特定版本，并在整个软件生命周期内保持配置的完整性和可追溯性。
  • 软件工程管理：包括计划、协调、衡量、报告、控制项目或程序，以确保软件的开发和维护是系统的、有纪律的和量化的。
  • 软件工程过程：即软件生命周期，包括生命周期过程中的定义、实现、评估、测量、管理和改进。
  • 软件工程模型和方法：指软件生命周期管理中的建模模型与软件开发方法。
  • 软件质量：包括软件的基础质量、软件质量的管理过程，以及实用性。
  • 软件工程职业实践：涉及软件工程师实现软件工程所必须具备的知识、技能、态度。
• 软件工程基础教育
  • 软件工程经济学：包含软件工程经济学基础、非盈利决策、经济风险和不确定性估算等。
  • 计算基础：包括问题解决技术、抽象、算法和复杂性、编程基础、并行和分布式计算基础、计算机组成、操作系统、网络通信等。
  • 数学基础：涵盖为软件工程实践提供必要的数学背景的知识点，比如数论、图与树、离散概率、语法和有限状态机等。
  • 工程基础：涵盖为软件工程实践提供必要的工程背景的知识点，比如统计分析、工程设计等。

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

• 初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。
• 可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。
• 已定义级(Defined)。开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。
• 已管理级(Managed)。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，实现及时纠正。
• 优化级(Optimizing)。可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。

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

CMMI协助软件开发人员持续改善流程的成熟度以及软件质量，从而提升软件开发项目及公司的管理能力，最终达到软件开发功能正确、缩短开发进度、降低开发成本、确保软件质量的目标。 概括来说，CMMI达到了两个目的：一是将多学科领域之间的公共过程域进行了提炼；二是减少了过程域的总数量。CMMI集成众多领域的标准和规范，在实施过程中实际上也很灵活。企业在利用CMMI进行过程改进的时候，首先必须根据自身的主要业务类型和改进目标等，选择适合于自身的规范。例如：从事某个领域软件开发的企业，没有外包和采购业务，那么可以考虑使用在软件开发和系统工程方面进行了集成的CMMI SW/SE。对于需要集成多个产品，或者产品开发受到其他工程影响的企业，可以采用CMMI-SE/SW/IPPD。另外对于涉及到产品的获取和转包方面的企业，可以考虑使用CMMI-SE/SW/IPPD/SS。