系统分析与设计HW1

软件工程的定义

1993年，电气电子工程师学会（IEEE）给出了一个定义："将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中"。

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

Software crisis：软件危机是落后的软件生产方式无法满足迅速增长的计算机软件需求, 从而导致软件开发与维护过程中出现一系列严重问题的现象。 这些严重的问题阻碍着软件生产的规模化、商品化以及生产效率，让软件的开发和生产成为制约软件产业发展的“瓶颈”。

软件开发是一项高难度、高风险的活动，由于它的高失败率，故有所谓“软件危机”之说。软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之电脑的力量带来的冲击和可能要处理的问题的复杂性。

危机表现在几个方面：

• 项目运行超出预算。
• 项目运行超过时间。
• 软件质量低落。
• 软件通常不匹配需求。
• 项目无法管理，且代码难以维护。

软件危机的原因：

• 软件是计算机的逻辑部件而不是物理部件。软件问题是在开发时期引入的而在测试阶段没能测出来的故障，修改软件故障要修改软件原来的设计。

• 软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。为了在预定时间内开发出规模庞大的软件，必须由许多人分工合作，软件开发工作量随软件规模增大非线性增长。

• 与早期软件开发个体化特点有关：认为软件开发就是写程序并设法使之运行，轻视需求分析和软件维护。也就是说是和软件开发和维护有关的许多错误认识和作法的形成，可以归因于在计算机系统发展的早期阶段软件开发的个体化特点。

• 缺乏正确的理论指导。缺乏有力的方法学和工具方面的支持。由于软件开发不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件开发产品的个性化，也是发生软件开发危机的一个重要原因。

COCOMO:构造性成本模型（COCOMO，英文全称为Constructive Cost Model）是由巴里·勃姆（Barry Boehm）提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式，使用从项目历史和现状中的某些特征作为参数来进行计算。

构造性成本模型由三个不断深入和详细的层次组成。第一层，“基本COCOMO”，适用对软件开发进行快速、早期地对重要的方面进行粗略的成本估计，但因其缺少不同的项目属性（“成本驱动者”）的因素，所以准确性有一定的局限性。“中级COCOMO”中考虑进了这些成本驱动者。“详细COCOMO”加入了对不同软件开发阶段影响的考量。

软件生命周期

软件生命周期是指软件的产生直到成熟的全部过程。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

生命周期的每一个周期都有确定的任务，并产生一定规格的文档（资料），提交给下一个周期作为继续工作的依据。按照软件的生命周期，软件的开发不再只单单强调“编码”，而是概括了软件开发的全过程。软件工程要求每一周期工作的开始只能必须是建立在前一个周期结果“正确”前提上的延续；因此，每一周期都是按“活动 ── 结果 ── 审核 ── 再活动 ── 直至结果正确”循环往复进展的。

典型划分GB8567（4个时期7个阶段）：

1. 软件分析时期：问题定义、可行性研究、需求分析
2. 软件设计时期：总体设计、详细设计
3. 编码与测试时期：编码、测试
4. 运行与维护时期

按照 SWEBok 的 KA 划分，本课程关注哪些 KA 或 知识领域？

ACM与IEEE Computer Society联合修定的SWEBOK（Software Engineering Body of Knowledge）提到，软件工程领域中的核心知识包括：

• 软件需求（Software requirements）
• 软件设计（Software design）
• 软件建构（Software construction）
• 软件测试（Software test）
• 软件维护与更新（Software maintenance）
• 软件构型管理（Software Configuration Management, SCM）
• 软件工程管理（Software Engineering Management）
• 软件开发过程（Software Development Process）
• 软件工程工具与方法（Software Engineering Tools and methods）
• 软件质量（Software Quality）
• 软件工程专业实践（Software Engineering Professional Practice）
• 软件工程经济（Software Engineering Economics）
• 计算基础（Computing Foundations）
• 数学基础（Mathematical Foundations）
• 工程基础（Engineering Foundations）

本课程关注软件设计、软件测试、软件构型管理、软件工程管理、软件开发过程、软件质量等核心知识。

解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式。

1．初始级：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。

2．可管理级：建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。

3． 已定义级：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。

4． 量化管理级：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。

5． 优化管理级：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

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

SWEBok描述了在软件工程中被普遍接受的知识。这些知识被分类为15个知识领域，涵盖了软件工程相关的基本概念，并附上了详细介绍这些知识的链接。SWEBok可以视为一个软件工程知识的菜单，由SWEBok我们可以知道“有什么方法可供使用”，再来决定“使用什么方法”。

CMMI是能力成熟度模型，被用来衡量团队能力。CMMI等级评价了软件开发团队的开发能力、项目管理水平。CMMI等级越高的团队，越有能力开发大型项目。值得注意的是，越高的CMMI等级，越是注重项目管理，如：

CMMI第5级包含第2级到第4级的20个流程领域外，增加:

1. OPM：(Organizational Performance and Management）组织的绩效与管理，选择并推展渐进创新的组织过程和技术改善，改善应是可度量的，所选择及推展的改善需支持基于组织业务目的的质量及过程执行目标。
2. CAR：（Causal Analysis and Resolution）因果分析与解决。识别缺失的原因并进行矫正，进一步的防止未来再次发生。

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

阅读《现代软件工程》的 PSP: Personal Software Process 章节。 http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html
按表格 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)
• 事后总结(Postmortem)
• 提出过程改进计划(Porcess Improvement Plan)

需要的技能： 编写代码、单元测试、效能分析、编写文档

统计数据的方法：使用集中的时间段来做上述的步骤，方便计时。