软件工程初探 -- Homework 1

最新推荐文章于 2022-03-04 18:52:48 发布

Jack_CJZ

最新推荐文章于 2022-03-04 18:52:48 发布

阅读量497

点赞数

分类专栏：系统分析与设计文章标签：软件工程

本文链接：https://blog.csdn.net/Jack_CJZ/article/details/79535473

版权

系统分析与设计专栏收录该内容

10 篇文章 0 订阅

订阅专栏

1、简单题

软件工程的定义
1. IEEE 的综合定义：
  
  将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中。
2. GB/T11457-2006《信息技术软件工程术语》的定义：
  应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、和维护的工程或进行研究的学科。
  
  包括：
  - 创立与使用健全的工程原则，以便经济地获得可靠且高效率的软件。
  - 应用系统化，遵从原则，可被计量的方法来发展、操作及维护软件；也就是把工程应用到软件上。
  - 与开发、管理及更新软件产品有关的理论、方法及工具。
  - 一种知识或学科，目标是生产质量良好、准时交货、匹配预算，并满足用户所需的软件。
  - 实际应用科学知识在设计、建构计算机程序，与相伴而来所产生的文件，以及后续的操作和维护上。
  - 使用与系统化生产和维护软件产品有关之技术与管理的知识，使软件开发与修改可在有限的时间与费用下进行。
  - 建造由工程师团队所开发之大型软件系统有关的知识学科。
  - 对软件分析、设计、实施及维护的一种系统化方法。
  - 系统化地应用工具和技术于开发以计算机为主的应用。
  - 软件工程是关于设计和开发优质软件。
3. 更多定义：
  
  是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过实践考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，这就是软件工程。

阅读经典名著“人月神话”等资料，解释 software crisis、COCOMO 模型。

Software Crisis，软件危机是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题皆可能导致软件产品的寿命缩短、甚至夭折。随着计算机应用需求的驱动以及计算能力的巨大提升，软件生产变得更为复杂，成本更高，大型软件的生产出现了很大的困难，即出现了软件危机。软件危机的本源是复杂、期望和改变，从本质上来说，它谈到了写出正确、可理解、可验证的计算机程序的困难。

软件危机使人们认识到中大型软件系统与小型软件有着本质性差异：大型软件系统开发周期长、费用昂贵、软件质量难以保证、生产率低，它们的复杂性已远超出人脑能直接控制的程度。软件危机主要表现在：
- 项目运行超出预算
- 项目运行超出计划的时间
- 生产的软件非常低效
- 生产的软件质量低落
- 生产的软件通常不匹配需求
- 项目无法管理，且代码难以维护
- 生产的软件永远无法完成交付
COCOMO 模型，即构造性成本模型，是一种精确的、易于使用的，基于模型的软件成本估计方法。从本质上说是一种参数化的项目估算方法，是把项目的某些特征作为参数，通过建立一个数字模型预测项目成本的回归分析公式。

COCOMO 可应用于三种不同的软件项目：
- 有机项目 — 相对较小、较简单的软件项目，由较小的有经验的团队来完成，需求较少并且没有过份严格的限定。
- 中度分离项目 — 指中等规模（大小及复杂度）的软件项目，由不同经验水平的人组成的团队来完成，需求中既有严格的部分也有不太严格的部分。
- 嵌入式项目 — 指软件项目必须依赖于一套紧凑的硬件、软件以及符合操作限制。
COCOMO 模型按其详细程度可以分为三级：
- 基本 COCOMO 模型：是一个静态单变量模型，它用一个已估算出来的以源代码行数（LOC）为自变量的经验函数计算软件开发工作量。基本 COCOMO 的等式如下：
  $E = a b (K L O C) b b D = c b (E) d b P = E / D$ $\begin{align} & E = a_b(KLOC)^{b_b} \\ & D = c_b(E)^{d_b} \\ & P = E/D \end{align}$
其中 $E$ 是指软件开发的工作量（单位：人月）， $D$ 是指累积的开发时间（单位：月）， $KLOC$ 是指对最终发布的软件所含代码行数的估计（单位：千行代码）， $P$ 则指需要的人数（单位：人）。而其余的系数 $a_b, b_b, c_b, d_b$ 如下表所示：

Software project $a_b$ $b_b$ $c_b$ $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适用于快速、早期地粗略估算软件成本，但它没有考虑如不同的硬件条件、人员素质及经验、对现代工具与技术的使用，等其它会对软件成本有深远影响的项目属性，所以它的准确程度有限。
- 中级 COCOMO 模型：在基本 COCOMO 模型的基础上，再用设计产品、硬件、人员、项目等方面的影响因素调整工作量的估算。中级 COCOMO 模型对软件工作量的估算使用了程度大小以及一组“成本驱动者”，包括对产品、硬件、人员及项目属性的客观评价。这种扩展包含了四类“成本驱动者”，而每个类分别会有对应的小属性，每个小属性都会得到一个6点的评估，从“非常低”到“非常高”（重要性或大小），可用的因子值如下：

		评估
成本驱动者	非常低	低	正常	高	很高
产品属性
软件可靠性需求	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.00	1.11	1.30
内存约束			1.00	1.06	1.21
虚拟机稳定性		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

所有这些因子乘积的结果就是“工作量调整因子”： $EAF$ ，通常这个值的范围是 $[0.9, 1.4]$

中级 COCOMO 的计算公式如下：

E = a i (K L O C) (b i) . E A F

$E = a_i(KLOC)^{(b_i)}.EAF$
其中

E $E$ 是指软件开发的工作量（单位：人月），

KLOC $KLOC$ 是指对最终发布的软件所含代码行数的估计（单位：千行代码），

EAF $EAF$ 则是用上述方法计算得出的因子。系数

ai $a_i$ 和幂

bi $b_i$ 则由下表给出：

软件项目	$a_i$	$b_i$
有机型	3.2	1.05
中度分离型	3.0	1.12
嵌入式	2.8	1.20

详细 COCOMO 模型：包括中间 COCOMO 模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。

软件生命周期

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

本课程主要关注以下的 KA：
- Software requirements
- Software design
- Software configuration management
- Software engineering management
- Software engineering process
- Software engineering models and methods
- Software quality
- Engineering foundations
解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式。

五个级别的解释如下表所示：

级别	解释
Level 1 - Initial	过程无序，进度、预算、功能、质量不可预测，企业处于自发生产模式，一般不具备稳定的软件开发环境，通常在遇到问题的时候，就放弃原定的计划而只专注于编程与测试。
Level 2 - Managed	建立了管理软件项目的政策，以及为贯彻执行这些政策而定的措施。基于以往项目的经验来计划与管理新的项目。达到此级别的企业，其过程已经实现制度化，有规律，可重复。
Level 3 - Defined	过程实现标准化。有关软件工程和管理工程的特定的、面对整个企业的软件开发与维护的过程的文件将被制定出来。同时把这些过程集成到一个协调的整体中去。
Level 4 - Quantitatively Managed	企业对产品及过程建立起定量的质量目标，同时在过程中加入规定的、清楚的、连续的度量。作为企业的度量方案，要对项目的重要过程活动进行生产率和质量的度量。软件产品因此而具有可预期的高质量。达到该级的企业已实现过程定量化。
Optimizing	整个企业将会把重点放在对过程进行不断的优化，采取主动的措施去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析各有关过程的有效资料，作出对新技术的成本与效益的分析，并提出对过程进行修改的建议。达到该级的公司可自发的不断改进，防止同类缺陷二次出现。

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

CMMI 为衡量一个企业的软件工程技术和管理的成熟程度提供了具体的五级标准，同时也为企业的过程改进提供了明确的方向和目标，因此，它是一种有效的过程改进方法。CMMI 模型的五个成熟度级别分别为初始级、管理级、定义级、量化管理级和优化级，每个级别都对一个企业的配置管理 CM、度量和分析 MA 、项目监控 PMC 等十六个核心过程区域进行了评价和度量，是综合评价一个企业当前过程中软件生产能力的重要指标。而另一方面，CMMI 模型帮助企业的过程改进设置改进目标和优先级，为质量过程提供指引，能够有效地帮助企业不断改进。

2、解释 PSP 各项指标及技能要求

根据 PSP 2.1，一个工程师在接到任务后应该如何做、需要哪些技能以及我打算如何统计数据如下表格所示：

PSP 2.1	应该如何做	需要的技能	如何统计数据
Planning	计划	统筹规划、掌握软件开发流程
Estimate	估计这个任务需要多少时间	对整个任务目标有清晰的认识，对软件开发的整个过程非常熟悉	搜集资料，结合前人经验进行估计
Development	开发	设计能力、编程能力、熟悉规范
Analysis	分析需求	需求分析和挖掘	搜集资料，与同伴讨论，征求指导老师意见
Design Spec	生成设计文档	良好的写作、熟练运用设计工具、头脑风暴	搜集优秀设计文档模版，并学习设计工具的使用
Design Review	设计复审（和同事审核设计文档）	严密谨慎的思维、细心观察能力	仔细检查，向有经验者咨询可能出错的地方
Coding Standard	代码规范（为目前的开发制定合适的规范）	熟悉标准规范并灵活运用	搜集各种规范资料和白皮书，并参考各种应用样例
Design	具体设计	熟练运用设计工具、把握整体框架	再次审查设计文档，严格根据开发流程进行设计
Coding	具体编码	代码能力、严格遵守编程规范
Code Review	代码复审	细心调试的能力	了解调试工具说明书中各项功能数据
Test	测试（包括自测，修改代码，提交修改）	熟悉测试工具和模型的使用和遵守测试过程规范	了解测试工具说明书中各项功能数据，并搜集测试过程需要的数据资料
Record Time Spent	记录用时	养成计时习惯	手动计时
Test Report	测试报告	良好的写作、熟练运用报告撰写工具	搜集优秀测试报告文档模版，熟悉报告撰写流程
Size Measurement	计算工作量	熟悉COCOMO模型、准确记录并收集所需数据	在开发和测试过程中注意记录计算工作量所需的各项数据
Postmortem	事后总结	总结反省、不断思考
Process Improvement Plan	提出过程改进计划	总结反省、不断思考、精益求精、不断创新