一、简单题
软件工程的定义
——IEEE[IEE93]
(1) 将系统化、规范化、可度量的方法应用于软件的开发、运行和维护的过程,即将工程化应用于软件中。(2) 对(1)中所述方法的研究。
——其它定义
是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件,把经过实践考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,这就是软件工程。
阅读经典名著“人月神话”等资料,解释 software crisis、COCOMO 模型。
software crisis: 六十年代以来,随着计算机应用需求的驱动,系统软件和应用软件有很大的发展,如操作系统,编译系统和大型应用软件等。由于软件生产的复杂性和高成本,使大型软件的生产出现了很大的困难,即出现软件危机。
COCOMO: Constructive Cost Model,即构造性成本模型
- 基本COCOMO
基本COCOMO用一个以程序大小为自变量的经验函数来度量软件开发工作量(和成本)。程序大小用已估算出来的,以千为单位的源代码行数(KLOC)表示。
COCOMO适用于三类软件项目:
- 有机项目: 相对较小、较简单的软件项目,由较小的有经验的团队来完成,需求较少并且没有过份严格的限定。
- 中度分离项目: 指中等规模(大小及复杂度)的软件项目,由不同经验水平的人组成的团队来完成,需求中即有严格的部分也有不太严格的部分。
- 嵌入式项目: 指软件项目必须依赖于一套紧凑的硬件、软件以及符合操作限制。
基本COCOMO的等式如下:
E=ab(KLOC)bb E = a b ( K L O C ) b b
D=cb(E)db D = c b ( E ) d b
P=E/D P = E / D
其中E是用“人月”来计算的工作量,D是指累积的开发时间(月),KLOC是指对最终发布的代码行数的估计(千行代码),P指需要的人数。其中的一些系数 ab a b , bb b b , cb c b 和 db d b 如下表所示:
软件项目 | ab a b | bb b b | cb c b | db d b |
---|---|---|---|---|
有机型 | 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适用于快速、早期地粗略估算软件成本,但它没有考虑如不同的硬件条件、人员素质及经验、对现代工具与技术的使用,等其它会对软件成本有深远影响的项目属性,所以它的准确程度有限。
2. 中级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=ai(KLoC)(bi).EAF
E
=
a
i
(
K
L
o
C
)
(
b
i
)
.
E
A
F
其中E是以“人月”来计算的工作量,“KLoC”是产品发布的代码行数(千行代码),“EAF”是用上述方法计算得出的因子。系数
ai
a
i
和幂
bi
b
i
在下表中给出:
软件项目 | ai a i | bi b i |
---|---|---|
有机型 | 3.2 | 1.05 |
中度分离型 | 3.0 | 1.12 |
嵌入式 | 2.8 | 1.20 |
对于使用“E”来计算开发时间“D”的方法与基本COCOMO相同。
软件生命周期
- 软件分析时期: 问题定义、可行性研究、需求分析
- 软件设计时期: 总体设计、详细设计
- 编码与测试时期: 编码、测试
- 运行与维护时期
按照 SWEBok 的 KA 划分,本课程关注哪些 KA 或 知识领域?
SWEBOK: Software Engineering Body Of Knowledge,即软件工程知识体系
KA: Knowledge Areas,即知识领域
本课程关注的KA(11个):
- 软件需求
- 软件设计
- 软件构建
- 软件测试
- 软件维护
- 软件配置管理
- 软件工程管理
- 软件工程过程
- 软件工程模型和方法
- 软件质量
- 软件工程专业实践
解释 CMMI 的五个级别。例如:Level 1 - Initial:无序,自发生产模式。
CMMI: Capability Maturity Model Integration,即能力成熟度模型集成(也有称为: 软件能力成熟度集成模型)
五个级别:
- Level 1 - Initial:无序,自发生产模式。
- Level 2 - Managed: 建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。
- Level 3 - Defined: 已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。
- Level 4 - Quantitatively Managed: 分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。
- Level 5 - Optimizing: 过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
用自己语言简述 SWEBok 或 CMMI (约200字)
CMMI把现在所有现存实施的与即将被发展出来的各种能力成熟度模型,集成到一个框架中去。还将其严格地划分为初始级、可管理级、已定义级、量化管理级和优化管理级五个等级。这五个级别均提供给软件企业进行申请认证。这些渐进的认证级别,可以帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力。有了这些指导框架,软件企业能够制定合理的计划使得软件交付能够按时,并将经费控制在合理的范围内,同时还能保证软件的质量符合用户标准。
二、解释 PSP 各项指标及技能要求:
阅读《现代软件工程》的 PSP: Personal Software Process 章节。http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html
按表格 PSP 2.1, 了解一个软件工程师在接到一个任务之后要做什么,需要哪些技能,解释你打算如何统计每项数据? (期末考核,每人按开发阶段提交这个表)
PSP2.1 | Personal Software Process Stages | 相关技能 |
---|---|---|
Planning | 计划 | |
-Estimate | -估计这个任务需要多少时间 | 对团队协作能力的估计,任务复杂度的估计 |
Development | 开发 | |
-Analysis | -需求分析(包括学习新技术) | 以用户为中心的方法 |
-Design Spec | -生成设计文档 | 语言表达能力,文档编辑能力 |
-Design Review | -设计复审(和同事审核设计文档) | 合理性分析 |
-Coding Standard | -代码规范(为目前的开发制定合适的规范) | 了解各种现存的规范(作为参考),基于具体任务制定合适规范的能力 |
-Design | -具体设计 | 系统架构设计的能力,代码结构设计的能力 |
-Coding | -具体编码 | 编程能力 |
-Code Review | -代码复审 | 把握前面制定好的规范 |
-Test | -测试(自我测试,修改代码,提交修改) | 熟知软件测试方法,相关测试工具的使用 |
Reporting | 报告 | |
-Test Report | -测试报告 | 实事求是,清晰地表达测试过程遇到的问题 |
-Size Measurement | -计算工作量 | 灵活运用COCOMO |
-Postmortem & Process Improvement Plan | -事后总结,并提出过程改进计划 | 擅于抓重点和主干,架构和结构的优化能力。 |
统计方法: 借助于所使用的开发工具(如项目管理平台GitHub),和一些辅助的统计工具来对数据进行统计。