1、简单题
软件工程的定义
“the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software”—IEEE Systems and software engineering.1
“The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software” – IEEE Standard Glossary of Software Engineering Terminology.1
GB/T11457-2006《信息技术 软件工程术语》中将其定义为”应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、和维护的工程或进行研究的学科”。
包括2：
- 创立与使用健全的工程原则，以便经济地获得可靠且高效率的软件。
- 应用系统化，遵从原则，可被计量的方法来发展、操作及维护软件；也就是把工程应用到软件上。
- 与开发、管理及更新软件产品有关的理论、方法及工具。
- 一种知识或学科，目标是生产质量良好、准时交货、匹配预算，并满足用户所需的软件。
- 实际应用科学知识在设计、建构计算机程序，与相伴而来所产生的文件，以及后续的操作和维护上。
- 使用与系统化生产和维护软件产品有关之技术与管理的知识，使软件开发与修改可在有限的时间与费用下进行。
- 建造由工程师团队所开发之大型软件系统有关的知识学科。
- 对软件分析、设计、实施及维护的一种系统化方法。
- 系统化地应用工具和技术于开发以计算机为主的应用。
- 软件工程是关于设计和开发优质软件。
解释software crisis、COCOMO模型
Software Crisis–软件危机
软件危机（Software Crisis）是早期计算机科学的一个术语，是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题皆可能导致软件产品的寿命缩短、甚至夭折。软件开发是一项高难度、高风险的活动，由于它的高失败率，故有所谓“软件危机”之说。软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之电脑的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说，它谈到了写出正确、可理解、可验证的计算机程序的困难。3
软件危机其原因，衔接到硬件的整体复杂度，与软件开发流程。危机表现在几个方面：
- 项目运行超出预算。
- 项目运行超过时间。
- 软件质量低落。
- 软件通常不匹配需求。
- 项目无法管理，且代码难以维护。
硬件成长率每年大约30％，软件每年只勉强以4～7％速度在成长，信息系统的交付日期一再延后，许多待开发的软件系统无法如期开始。1960年代软件开发成本占总成本20％以下；1970年代软件成本已达总成本80％以上，软件维护费用在软件成本中高达65％。1986年公布的数据，所有验收的外包软件中，竟然只有4％可用，其余96％却是不堪一用。大部分的企业自行开发的信息系统中，有四分之三也是功败垂成。因此软件维护成本居高不下，软件产品质量低落是最主要的原因。4
COCOMO–构造性成本模型5
构造性成本模型最初发表于1981年巴里·勃姆《软件工程经济学》一书中，做为一种在软件项中估算工作量、成本以及时间表的模型。它基于对TRW飞机制造公司的63个项目的研究。
基本COCOMO
基本COCOMO是一种静态的单值模型，它使用以每千源代码行数（KLoC）来度量的程序大小来计算软件开发的工作量（及成本）。COCOMO可以应用于三种不同的软件项目：
- 有机项目 - 相对较小、较简单的软件项目，由较小的有经验的团队来完成，需求较少并且没有过份严格的限定。
- 中度分离项目 - 指中等规模（大小及复杂度）的软件项目，由不同经验水平的人组成的团队来完成，需求中即有严格的部分也有不太严格的部分。
- 嵌入式项目 - 指软件项目必须依赖于一套紧凑的硬件、软件以及符合操作限制
基本COCOMO的等式如下:
其中E是用“人月”来计算的工作量，D是指累积的开发时间（月），KLOC是指对最终发布的代码行数的估计（千行代码），P指需要的人数。其中的一些系数 ab,bb, cb和db如下表所示：
基本COCOMO适用于快速、早期地粗略估算软件成本，但它没有考虑如不同的硬件条件、人员素质及经验、对现代工具与技术的使用，等其它会对软件成本有深远影响的项目属性，所以它的准确程度有限。
| Software project | ||||
|---|---|---|---|---|
| 有机型 | 2.4 | 1.05 | 2.5 | 0.38 |
| 中度分离型 | 3.0 | 1.12 | 2.5 | 0.35 |
| 嵌入式 | 3.6 | 1.20 | 2.5 | 0.32 |
中级COCOMO
中级COCOMO对软件工作量的估算使用了程度大小以及一组“成本驱动者”，包括对产品、硬件、人员及项目属性的客观评价。这种扩展包含了四类“成本驱动者”，每个类又有一些小的属性：
- 产品属性
- 软件可靠性需求
- 应用数据库的大小
- 产品复杂度
- 硬件属性
- 运行时的性能约束
- 内存约束
- 虚拟机稳定性
- 回复时间的需求
- 人员属性
- 分析能力
- 软件工程能力
- 应用经验
- 虚拟机的经验
- 编程语言经验
- 项目属性
- 采用的软件工具
- 采用的软件工程手段
- 对开发时间的要求
这15个属性的每一个都会得到一个6点的评估，从“非常低”到“非常高”（重要性或大小）。下表中列出了可用的因子值。所有这些因子的乘积的结果就是“工作量调整因子(EAF)”通常这些因子的值是从0.9到1.4。
| 成本 | ||||||
|---|---|---|---|---|---|---|
| 成本驱动者 | 非常低 | 低 | 正常 | 高 | 很高 | 非常高 |
| 产品属性 | ||||||
| 软件可靠性需求 | 0.75 | 0.88 | 1.00 | 1.15 | 1.40 | |
| 应用数据库的大小 | 0.94 | 1.00 | 1.08 | 1.16 | ||
| 产品复杂度 | 0.70 | 0.85 | 1.00 | 1.15 | 1.30 | 1.65 |
| 硬件属性 | ||||||
| 运行时的性能约束 | 1.00 | 1.11 | 1.30 | 1.66 | ||
| 内存约束 | 1.00 | 1.06 | 1.21 | 1.56 | ||
| 虚拟机稳定性 | 0.87 | 1.00 | 1.15 | 1.30 | ||
| 回复时间的需求 | 0.87 | 1.00 | 1.07 | 1.15 | ||
| 人员属性 | ||||||
| 分析能力 | 1.46 | 1.19 | 1.00 | 0.86 | 0.71 | |
| 应用经验 | 1.29 | 1.13 | 1.00 | 0.91 | 0.82 | |
| 软件工程能力 | 1.42 | 1.17 | 1.00 | 0.86 | 0.70 | |
| 虚拟机的经验 | 1.21 | 1.10 | 1.00 | 0.90 | ||
| 编程语言经验 | 1.14 | 1.07 | 1.00 | 0.95 | ||
| 项目属性 | ||||||
| 采用的软件工具 | 1.24 | 1.10 | 1.00 | 0.91 | 0.82 | |
| 采用的软件工程手段 | 1.24 | 1.10 | 1.00 | 0.91 | 0.83 | |
| 对开发时间的要求 | 1.23 | 1.08 | 1.00 | 1.04 | 1.10 |
中级COCOMO的计算公式如下： 其中E是以“人月”来计算的工作量，“KLoC”是产品发布的代码行数(千行代码)，“EAF”是用上述方法计算得出的因子。系数和幂在下表中给出：
| 软件项目 | ||
|---|---|---|
| 有机型 | 3.2 | 1.05 |
| 中度分离型 | 3.0 | 1.12 |
| 嵌入式 | 2.8 | 1.20 |
对于使用“E”来计算开发时间“D”的方法与基本COCOMO相同。
软件生命周期6
软件生命周期（Software Development LifeCycle）是指软件的产生直到成熟的全部过程。
生命周期是事物发展的客观规律，软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始，经历分析设计、实现、部署、维护，直到最后逐渐消亡的”。这是受到了第一个软件生命周期模型—瀑布模型影响，上述语句实质上简要的描述了瀑布型生命周期。 现在的软件生命周期不再只考虑瀑布型生命周期，另外常见的软件生命周期模型有原型模型、螺旋模型、迭代模型。所以现在的软件生命周期说明应当不再包括瀑布型生命周期中的典型阶段。
因此，现在对软件生命周期及软件生命周期模型采用如下定义：
- 软件生命周期是指软件的产生直到成熟的全部过程。
- 软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。
最近几年来，给软件生命周期带来最多活力的是敏捷软件开发，使得这个领域呈现出勃勃生机，出现了一些更好响应变化、迎接竞争的生命周期模型。
敏捷软件开发明确对生命周期模型提出了要求：短迭代开发。迭代模型的历史可以追溯到上世纪50年代，但以往的迭代模型并没有对迭代周期长度提出要求。而在敏捷软件开发中，迭代周期长度一般不超过2个月，而常见的迭代周期是2周到4周，因此可以称之为“短迭代”。
有些敏捷软件开发在主开发过程前安排有预研或计划或架构或需求阶段等等，在主开发过程后安排有系统集成测试或验收测试或试运行等等，这样做并不违反敏捷开发原则，但其主开发过程应当采用短迭代开发，而且主开发过程的工期应当占有显著的比例，形成多个短迭代。
敏捷开发讲究固定的节奏，建议按照固定的节奏开发，所以短迭代的周期长度在开始选定之后，一般不作改变。同样的原因，敏捷迭代与迭代之间一般不安排缓冲期，上个迭代未完成的内容放到下个迭代中进行处理。
敏捷开发迭代与瀑布生命周期的阶段是不同的。瀑布型中需求分析阶段的产物一般是需求规格说明书，不同阶段的产物是不同的；而敏捷开发迭代的产物是软件本身，前期迭代的产物也许不完整，但各个敏捷开发迭代的产物是一致的、逐步改进完善的软件本身。
按照SWEBok的KA划分，本课程关注哪些KA或 知识领域？
ACM与IEEE Computer Society联合修定的SWEBoK（Software Engineering Body of Knowledge）提到，软件工程领域中的核心知识包括：
- Software requirements
- Software design
- Software Engineering Tools and methods
- Software construction
解释CMMI的五个级别78
- Level 1 - initial（初始级）： 无序、 自发生产模式。
- Level 2 - Managed（可管理）： 管理制度化、 建立了基本的管理制度和规程。
- Level 3 - Defined（已定义）： 开发过程实现标准化、 文档化。
- Level 4 - Quantitatively Managed（已量化管理）： 产品和过程已建立了定量的质量目标。
- Level 5 - Optimizing（优化中）： 集中精力改进过程， 得出最佳方法。
用自己语言简述SWEBok或 CMMI
SWEBok
SWEBok全称Software Engineering Body of Knowledge（软件工程知识体系），是一个说明了公认软件工程知识体系的国际标准。
软件工程知识体系指南由诸多专业团体和行业成员合作产生，经由IEEE计算机协会出版。2013年底，SWEBok V3被批准并发布。它将原先2004版本的SWEBok的十个知识领域(KA)扩充和细化为十五个知识领域(KA)，还承认但未定义了数个条例，包括计算机工程（Computer Engineering），系统工程（Systems Engineering），项目管理（Project Management），质量管理（Quality Management），通用管理（General Management），计算机科学（Computer Science）等等
2、解释 PSP 各项指标及技能要求：
| PSP2.1 | Personal Software Process Stages | Time (%) Senior Student | Time (%) SDE | Time (%) Plan |
|---|---|---|---|---|
| Planning | 计划 | 8 | 6 | 8 |
| - Estimate | - 估计这个任务需要多少时间 | 8 | 6 | 8 |
| Development | 开发 | 82 | 88 | 85 |
| - Analysis | - 需求分析（包括学习新技术） | 6 | 10 | 8 |
| - Design Spec | - 生成时间文档 | 5 | 6 | 5 |
| - Design Review | - 设计复审（和同事审核设计文档） | 4 | 6 | 4 |
| - Coding Standard | - 代码规范（为目前的开发制定合适的规范） | 3 | 3 | 3 |
| - Design | - 具体设计 | 10 | 12 | 15 |
| - Coding | - 具体编码 | 36 | 21 | 30 |
| - Code Review | - 代码复审 | 7 | 9 | 10 |
| - Test | - 测试（自我测试，修改代码，提交修改） | 13 | 21 | 20 |
| Reporting | 报告 | 9 | 6 | 7 |
| - Test Report | - 测试报告 | 3 | 2 | 3 |
| - Size Measurement | - 计算工作量 | 2 | 1 | 1 |
| - Postmortem & Process Improvement Plan | - 事后总结，并提出过程改进计划 | 3 | 3 | 3 |
- 一个软件工程师在接到一个任务之后，首先要进行计划的估计，然后进入开发阶段，最后进行项目报告。开发阶段不仅仅是具体编码，还需要进行需求的分析，文档的管理，代码的规范，代码的设计，以及编码后的审核和测试等等
- 考虑自身能力实际，应该把重点放在测试和编码上。同时，应当兼顾需求分析和代码规范，明确的需求是快速编码的前提，代码规范是维护性的保证。
参考：