1.简单题
软件工程的定义
1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。
1993年，电气电子工程师学会（IEEE）给出了一个更加综合的定义：
“将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中”。
阅读经典名著“人月神话”等资料，解释 software crisis、COCOMO 模型
softwrae crisis 软件危机
软件危机（英语：Software Crisis）是早期计算机科学的一个术语，是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题皆可能导致软件产品的寿命缩短、甚至夭折。软件开发是一项高难度、高风险的活动，由于它的高失败率，故有所谓“软件危机”之说。软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之电脑的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说，它谈到了写出正确、可理解、可验证的计算机程序的困难。
在《人月神话》中作者谈论到大型软件开发的成本随着规模指数性增加，在缺乏一定的方法论的情况下开发大型软件可能会导致难以预料的后果，可能导致软件极端复杂，难以按时交付，bug百出等情况，而加入更多的人力往往是火上浇油，非但不能使开发难度下降，还可能会让进度变得更加延后。
COCOMO模型
构造性成本模型（COCOMO，英文全称为Constructive Cost Model）是由巴里·勃姆（Barry Boehm）提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式，使用从项目历史和现状中的某些特征作为参数来进行计算。
构造性成本模型最初发表于1981年巴里·勃姆《软件工程经济学》一书中，做为一种在软件项中估算工作量、成本以及时间表的模型。它基于对TRW飞机制造公司的63个项目的研究。巴里·勃姆于1981年在该公司担任软件研究与技术总监。这项研究中的项目所包含的代码量从2000行到10000行，包含的编程语言从汇编语言到PL/I。这些项目采用瀑布模型进行软件开发，这是在1981年时主流的软件开发模式。
通常把上述模型引用为“COCOMO 81”。1997年，“COCOMO II”开始研发，并最终于2001年发表于《软件成本估算:COCOMO Ⅱ模型方法》一书中。COCOMO II是COCOMO 81的继承者，并且更适用于对现代软件开发项目进行估算。它为现代软件开发流程提供了更多支持，并提供了一个更新了的数据库。对于新模型的需求来源于软件开发技术从基于大型计算机和整晚的批处理到桌面开发、代码重用以及利用即有软件模块的改变。
构造性成本模型由三个不断深入和详细的层次组成。第一层，“基本COCOMO”，适用对软件开发进行快速、早期地对重要的方面进行粗略的成本估计，但因其缺少不同的项目属性（“成本驱动者”）的因素，所以准确性有一定的局限性。“中级COCOMO”中考虑进了这些成本驱动者。“详细COCOMO”加入了对不同软件开发阶段影响的考量。
软件生命周期
软件生命周期（Software Development LifeCycle）是指软件的产生直到成熟的全部过程。
生命周期是事物发展的客观规律，软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始，经历分析设计、实现、部署、维护，直到最后逐渐消亡的”。这是受到了第一个软件生命周期模型—瀑布模型影响，上述语句实质上简要的描述了瀑布型生命周期。 现在的软件生命周期不再只考虑瀑布型生命周期，另外常见的软件生命周期模型有原型模型、螺旋模型、迭代模型。所以现在的软件生命周期说明应当不再包括瀑布型生命周期中的典型阶段。
因此，现在对软件生命周期及软件生命周期模型采用如下定义：
- 软件生命周期是指软件的产生直到成熟的全部过程。
- 软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。
按照 SWEBok 的 KA 划分，本课程关注哪些 KA 或 知识领域？
SWEBok的知识领域有软件需求、软件设计、软件建构、软件测试、软件维护与更新、软件构型管理、软件工程管理、软件开发过程、软件工程工具与方法、软件质量。本课程关注的知识领域有软件需求、软件设计、软件建构、软件测试、软件构型管理、软件开发工程、软件工程工具与方法、软件质量等。
解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式
- Level 1 - initial 无序，自发的生产模式。
- Level 2 - Managed 有基本管理程序，能完成任务的生产模式。
- Level 3 - Defined 项目流程制度化，能实现持续生产和模式复制的生产模式。
- Level 4 - Quantitatively Managed 定量精准管理，能把控产品性能和生产流程的生产模式。
- Level 5 - Optimizing 优化管理，能持续更新和改善流程的生产模式。
用自己语言简述 SWEBok 或 CMMI （约200字）
CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型） ，是美国国防部的一个设想，1994年由美国国防部（United States Department of Defense）与卡内基-梅隆大学（Carnegie-Mellon University）下的软件工程研究中心（Software Engineering Institute，SEISM）以及美国国防工业协会（National Defense Industrial Association）共同开发和研制的，他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型，集成到一个框架中去，申请此认证的前提条件是该企业具有有效的软件企业认定证书。
CMMI目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
CMMI 1至5级简述
- 第1级：初始级
- 第2级：受管理级
- 第3级：已定义级
- 第4级：定量管理级
- 第5级：持续优化级
2.解释PSP各项指标及技能要求
待做事项
- 计划:估计这个任务需要多少时间
- 开发：
- 分析需求
- 生成设计文档
- 设计复审（和同事审核设计文档）
- 具体设计
- 具体编码
- 代码复审
- 测试（包括自我测试、修改代码、提交修改）
- 记录时间花费
- 测试报告
- 计算工作量
- 事后总结
- 提出过程改进计划
所需技能
- 时间管理和自我管理能力
- 表达和交流的能力
- 书面表达的能力
- 编程测试的能力
- 与人合作的能力
- 把任务按质按量完成的执行力
统计方式
- 拿到任务后，开始将任务分成多个阶段，确定每个阶段的工作任务和结束指标。
- 当一个阶段的工作开始，就记录下当下的时间，并在完成之后，记录这个阶段总共花费的时间，然后开始下一个阶段的任务和计时。
- 当所有任务完成之后，就能将之前记录的结果合起来做统计分析。
