一、简答题

1. 软件工程的定义

为了克服软件危机,北约组织成员国的软件工作者于1968年和1969 年两次召开会议 (NATO 学术会议),提出了“软件工程”概念,著名的瀑布模型也同期出现。最早的定义是由德国计算机科学家 F.L. Bauer 给出的:

Establishment and use of sound engineering principles to economically obtain software that is reliable and works on real machines efficiently.

软件工程是为了经济地获得能够在实际机器上高效运行的、可靠的软件而建立和应用一系列坚实的软件工程原则。

目前普遍使用的软件工程定义是由 IEEE 给出的:

(1) the application of a *systematic, disciplined, quantifiable*approach to the development, operation, and maintenance of software, that is, the application of engineering to software

(2) the study of approaches as in (1).

(1) 软件工程是将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护。

(2) 对上述的研究方法。

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

本质原因:

软件危机的原因与硬件和软件开发过程的整体复杂性有关。 主要原因是计算能力的提高超过了程序员有效利用这些能力的能力,具体矛盾为:

  • 软件的大量需求与软件生产力效率之间的矛盾
  • 软件系统的复杂性与软件开发方法之间的矛盾

表现形式:

  • 项目运行超出预算
  • 项目运行时间过长
  • 软件运行效率低
  • 软件质量低
  • 软件通常不符合要求
  • 项目难以管理且代码难以维护
  • 软件从未交付

克服软件危机的方法

  • 正确认识计算机软件的内涵
  • 采用工程项目管理方法实施软件开发的组织管理
  • 采用成熟的软件开发技术和方法,开发和使用适当的软件工具

3. 软件生命周期

计算机软件有一个孕育、诞生、成长、成熟、衰亡的生存过程,这样的过程称为软件的生命周期 (也称软件开发生命周期 SDLC)。软件生命周期将软件开发过程划分为若干阶段,每个阶段有明确的任务目标和运行机制,从而使复杂的软件开发过程能够得到适当的控制和管理。大多数软件开发过程可以被模糊地描述为敏捷(agile)开发。还有瀑布(waterfall),原型设计,迭代增量式开发(iterative and incremental development),螺旋式开发,快速应用程序开发和极限编程等方法。

从时间的角度来说, 可以把整个周期划分为六个阶段:可行性分析与计划、需求分析、设计 (概要 设计和详细设计)、编码实现、测试、运行与维护。

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

GB/T 8567-2006:《计算机软件文档编制规范》

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

为了克服软件危机,IEEE Computer Society 构建软件生产的最佳实践与相关知识的框架,称为 Software Engineering Body of Knowledge。指导软件工程人才的培养与学科建设。2014 V3 版的 SWEBoK 将知识分为软件工程实践和基础教育两个部分,共 15 个知识域(knowledge areas / KAs)。Software Requirements,Software Design 是其中最重要的两个领域。15个KA为:

  • 软件需求(Software requirements)

软件需求表达了对软件产品的需求和限制,这些需求和约束有助于解决一些现实问题。

  • 软件设计(Software design)

软件设计过程是软件工程生命周期活动,其中分析软件需求以产生软件内部结构及其行为的描述,其将作为其构造的基础。

  • 软件构建(Software construction)

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

  • 软件测试(Software test)

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

  • 软件维护与更新(Software maintenance)

软件维护包括增强现有功能,调整软件以在新的和修改的操作环境中运行,以及纠正缺陷。

  • 软件配置管理(Software Configuration Management, SCM)

系统的配置是硬件,固件,软件或这些的组合的功能和/或物理特征。

  • 软件工程管理(Software Engineering Management)

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

  • 软件开发过程(Software Engineering Process)

软件生命周期过程的定义,实施,评估,测量,管理和改进。

  • 软件工程模型与方法(Software Engineering Models and Methods)

解决了涵盖多个生命周期阶段的方法

  • 软件质量(Software Quality)

普遍存在的软件生命周期问题

  • 软件工程专业实践 (Software Engineering Professional Practice)

软件工程专业实践关注软件工程师必须具备的专业,负责和道德的软件工程知识,技能和态度。

  • 软件工程经济学 (Software Engineering Economics)

在业务环境中做出决策,以使技术决策与组织的业务目标保持一致。

  • 计算基础 (Computing Foundations)

提供软件工程实践所需的计算背景的基础主题。

  • 数学基础 (Mathematical Foundations)

提供软件工程实践所必需的数学背景的基础主题。

  • 工程基础 (Engineering Foundations)

提供软件工程实践所必需的工程背景的基础主题。

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

1

  • Level 1 - Initial:无序,自发生产模式。
  • Level 2 - Management:可管理,制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。
  • Level 3 - Defined:已定义,已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。
  • Level 4 - Quantitatively Managed:量化管理,分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。
  • Level 5 - Optimizing:优化管理,过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

6. 用自己语言简述 SWEBok 或 CMMI (约200字)

SWEBoK (Software Engineering Body of Knowledge):

软件工程知识体系,由IEEE 计算机协会制作发布。其 2014年的 V3 一共包括了 15 个知识域,其中包括11个软件工程实践知识域,以及4个软件工程教育基础知识域,后4个是之前版本所没有的。事实上,SWEBoK描述的是广泛共识的知识,SWEBoK V3项目组希望能建立SWEBOK每三年周期性更新的制度,持续改进知识体系。

CMMI (Capability Maturity Model Integration)

能力成熟度模型集成分为5个级别:初始级,已管理级,已定义级,量化管理级,优化级。

1.初始化–>2.已管理级–>3.已定义级–>4.量化管理级–>5.优化级

这5个成熟度等级为评价软件过程能力提供了一个有序的级别,同时也为软件过程改进工作指明了方向,让人们分清轻重缓急,指导人们一步一步地改进过程能力而不是企图跳跃式地前进。

除了成熟度等级,CMMI还有一个重要的概念是过程域(Process Area)。过程域指出了达到某个成熟度等级必须要解决的一族问题。除了初始级以外,每个成熟度等级都有若干个过程域。由于成熟度等级是循序渐进的,如果想达到某个成熟度等级,例如CMMI 3级,除了满足CMMI 3级本身11过程域之外,还要满足CMMI 2级的7个过程域,依此类推。

二、PSP 2.1 (不需要提交)

1. 阅读《现代软件工程》的 PSP: Personal Software Process 章节

2. 按表格 PSP 2.1, 了解一个软件工程师在接到一个任务之后要做什么,需要哪些技能,解释你打算如何统计每项数据? (期末考核,每人按开发阶段提交这个表)

软件工程师在接到任务后要按顺序完成下面的一些任务:

  1. 计划
    • 估计这个任务需要多少时间
  2. 开发
    1. 分析需求
    2. 生成设计文档
    3. 设计复审(和同事审核设计文档)
    4. 代码规范(为目前的开发制定合适的规范)
    5. 具体设计
    6. 具体编码
    7. 代码复审
    8. 测试(包括自我测试,修改代码,提交修改)
  3. 记录花费时间
  4. 书写测试报告
  5. 计算工作量
  6. 事后总结
  7. 提出过程改进计划

其中需要的技能:

  1. 需求分析,从用户的角度出发
  2. 项目设计,选择合适的模型和结构
  3. 设当的项目经验并且知道相关的代码规范
  4. 编码能力过关
  5. 了解基本测试的流程和方法

主要统计数据的方法是以时间统计为基础。对于每项数据,统计具体完成的时间(以小时为单位),以此推导出完成该项任务的效率和成果评估。