软件分析与设计作业

软件分析与设计作业

1、简单题

软件工程的定义

软件工程的定义包为将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中。

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

软件危机是早期计算机科学的一个术语，是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题皆可能导致软件产品的寿命缩短、甚至夭折。软件开发是一项高难度、高风险的活动，由于它的高失败率，故有所谓“软件危机”之说。软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之电脑的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说，它谈到了写出正确、可理解、可验证的计算机程序的困难。1970年代和1980年代的软件危机。在那个时代，许多软件最后都得到了一个悲惨的结局，软件项目开发时间大大超出了规划的时间表。一些项目导致了财产的流失，甚至某些软件导致了人员伤亡。同时软件开发人员也发现软件开发的难度越来越大。在软件工程界被大量引用的案例是Therac-25的意外：在1985年六月到1987年一月之间，六个已知的医疗事故来自于Therac-25错误地超过剂量，导致患者死亡或严重辐射灼伤。

构造性成本模型（COCOMO，英文全称为Constructive Cost Model）是由巴里·勃姆提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式，使用从项目历史和现状中的某些特征作为参数来进行计算。构造性成本模型由三个不断深入和详细的层次组成。第一层，“基本COCOMO”，适用对软件开发进行快速、早期地对重要的方面进行粗略的成本估计，但因其缺少不同的项目属性（“成本驱动者”）的因素，所以准确性有一定的局限性。“中级COCOMO”中考虑进了这些成本驱动者。“详细COCOMO”加入了对不同软件开发阶段影响的考量。

基本COCOMO是一种静态的单值模型，它使用以每千源代码行数（KLoC）来度量的程序大小来计算软件开发的工作量（及成本）。COCOMO可以应用于三种不同的软件项目：

• 有机项目 - 相对较小、较简单的软件项目，由较小的有经验的团队来完成，需求较少并且没有过份严格的限定。
• 中度分离项目 - 指中等规模（大小及复杂度）的软件项目，由不同经验水平的人组成的团队来完成，需求中即有严格的部分也有不太严格的部分。
• 嵌入式项目 - 指软件项目必须依赖于一套紧凑的硬件、软件以及符合操作限制。

中级COCOMO对软件工作量的估算使用了程度大小以及一组“成本驱动者”，包括对产品、硬件、人员及项目属性的客观评价。这种扩展包含了四类“成本驱动者”，每个类又有一些小的属性：

• 产品属性
  
  • 软件可靠性需求
  • 应用数据库的大小
  • 产品复杂度
• 硬件属性
  
  • 运行时的性能约束
  • 内存约束
  • 虚拟机稳定性
  • 回复时间的需求
• 人员属性
  
  • 分析能力
  • 软件工程能力
  • 应用经验
  • 虚拟机的经验
  • 编程语言经验
• 项目属性
  
  • 采用的软件工具
  • 采用的软件工程手段
  • 对开发时间的要求

这15个属性的每一个都会得到一个6点的评估，从“非常低”到“非常高”（重要性或大小）。

软件生命周期

软件生命周期（Software Development LifeCycle）是指软件的产生直到成熟的全部过程。
生命周期是事物发展的客观规律，软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始，经历分析设计、实现、部署、维护，直到最后逐渐消亡的”。这是受到了第一个软件生命周期模型—瀑布模型[1]影响，上述语句实质上简要的描述了瀑布型生命周期。 现在的软件生命周期不再只考虑瀑布型生命周期，另外常见的软件生命周期模型有原型模型、螺旋模型[2]、迭代模型。所以现在的软件生命周期说明应当不再包括瀑布型生命周期中的典型阶段。
因此，现在对软件生命周期及软件生命周期模型采用如下定义：

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

最近几年来，给软件生命周期带来最多活力的是敏捷软件开发，使得这个领域呈现出勃勃生机，出现了一些更好响应变化、迎接竞争的生命周期模型。敏捷软件开发明确对生命周期模型提出了要求：短迭代开发。迭代模型的历史可以追溯到上世纪50年代，但以往的迭代模型并没有对迭代周期长度提出要求。而在敏捷软件开发中，迭代周期长度一般不超过2个月，而常见的迭代周期是2周到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）

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

解释 CMMI 的五个级别

• Level-1 Initial 无序
• Level-2 Managed 已管理
• Level-3 Defined 已定义
• Level-4 Quantitatively Managed 已量化地管理
• Level-5 Optimizing 优化中

CMMI

CMMI（ Capability Maturity Model Integration）的本质是软件管理工程的一个部分。软件过程改善是当前软件管理工程的核心问题， 50多年来计算的发展使人们认识到要高效率、高质量和低成本地开发软件，必须改善软件生产过程。基於模型的过程改进是指用采用能力模型来指导组织的过程改进，使之过程能力稳定的进行改善，该组织也能变得更加成熟。 然而，软件组织形成一套完整而成熟的软件过程不是一蹴而就的事情，需要经历一系列的成熟度。软件组织首先要进行差异分析，评定自己比较接近哪一个成熟度，然后再根据自身的情况来决定要采取哪些改进活动，来更有效地改进自己的软件过程。这就对软件过程的评定提出了一个客观的标准。美国卡内基梅隆大学软件工程学院於1987年研究成功的SW-CMM（Capability Maturity Model for Software）就是这样的一个理论模型，其目的在於帮助软件组织改善软件生产流程，以探索一个保证软件产品质量、缩短开发周期、提高工作效率的软件工程模式与标准规范。

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

• Planning
  
  • Estimate
• Development
  
  • Analysis
  • Design Spec
  • Design Review
  • Coding Standard
  • Design
  • Coding
  • Code Review
  • Test
• Record Time Spent
• Test Report
• Size Measurement
• Postmortem
• Process Improvement Plan

即：

• 计划
  
  • 估计这个任务需要多少时间
• 开发
  
  • 分析需求
  • 生成设计文档
  • 设计复审 (和同事审核设计文档)
  • 代码规范 (为目前的开发制定合适的规范)
  • 具体设计
  • 具体编码
  • 代码复审
  • 测试（包括自我测试，修改代码，提交修改）
• 记录时间花费
• 测试报告
• 计算工作量
• 事后总结
• 提出过程改进计划

统计方法：按照每个部分所花费的小时数进行统计计算。