Part I

  • 软件工程定义

    Software engineering is “(1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software,” and “(2) the study of approaches as in (1).” – IEEE Standard 610.12

  • 软件危机

    对软件危机(software crisis)的说明要从早期软件的开发模式说起：

    ​ 早期软件与今天动辄成千上万行的软件产品不同，它相对而言规模较小，且处于“作坊生产方式”中。 在那个时期， 程序设计如同其他的工艺制造品一样，是一门技艺，甚至对一些开发人员而言，它更是一门艺术，从当时鼎盛一时的《The Art of Programming》中，从业人员对于软件的态度可见一斑。然而，何为技艺，何为艺术？它意味着软件开发工作的低效与不可复用，就像手工制品一样，从原型到制作，每一阶段都需要开发人员的细细雕琢，至于正确与否，全靠工作者的经验与细心。总结而言，早期软件具有着如下特点：

    • 缺少软件开发工具的支持

    • 缺乏软件开发管理的理论与方法

    • 缺乏有效的软件开发后的维护

    可是，随着软件规模的不断增长，复杂的软件项目开始出现，而面对这些日益复杂化的软件项目，作坊式的 软件开发方式就显示出了它的疲态，越来越多的问题开始出现：

    • 软件开发成本日益增长

      • 开发成本超出预算

    • 软件开发进度难以控制

      • 实际进度比预定计划一再拖延

    • 用户对“已完成” 系统不满意的现象经常发生

      • 用户需求不明确

    • 软件产品的质量不可靠

      • Bug & Patch

    • 软件的可维护程度低

      • 数量不断膨胀的软件产品缺乏适当的文档资料

    ​ 总结而言，原本低效率、无组织的软件开发模式落于时代的发展之后，软件开发生产率跟不上硬件的发展和 人们需求的增长，于是众多的问题来了，软件开发陷入了危机之中，也就是我们所说的软件危机(software crisis) 。

  • COCOMO模型

    • 简介

      COCOMO，英文全称为constructive cost model，中文为构造性成本模型。它是一种精确、易于使用的，基于模型的成本估算方法，最早由勃姆 （Boehm） 于 1981 年提出。在软件工程中，它则是一种常见的软件规模估算方法。代码行分析方法作为一种度量估计方法，在20世纪80和90年代得到非常广泛的发展，在业界开发中有许多种估算工作量和进度的参数模型，其中最著名的就是COCOMO模型。

    • 模型

      COCOMO用3个不同层次的模型来反映不同程度的复杂性，他们分别为：

      ● 基本模型 （Basic Model）。 是一个静态单变量模型，它用一个以已估算出来的源代码行数 （LOC） 为自变量的函数来计算软件开发工作量。

      ● 中间模型 （Intermediate Model）。 则在用 LOC 为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。

      ● 详细模型 （Detailed Model） 包括中间 COCOMO 模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。

      同时根据不同应用软件的不同应用领域，COCOMO模型划分为如下3种软件应用开发模式：

      ● 组织模式（Organic Mode）。这种应用开发模式的主要特点是在一个熟悉稳定的环境种进行项目开发，该项目与最近开发的其他项目有很多相似点，项目相对较小，而且并不需要许多创新。

      ● 嵌入式应用开发模式 （Embedded Mode）。在这种应用开发模式种，项目受到接口要求的限制。接口对整个应用的开发要求非常高，而且要求项目有很大的创新，例如开发一种全新的游戏。

      ● 中间应用开发模式 （Semidetached Mode）。这时介于组织模式和嵌入式应用开发模式之间的类型。

    • 特点

      COCOMO 模型具有估算精确、易于使用的特点。在该模型中使用的基本量有以下几个：

      （1）DSI（ 源指令条数 ） ，定义为代码行数，包括除注释行以外的全部代码。若一行有两个语句，则算做一条指令。

      （2）MM（ 度量单位为人月 ） 表示开发工作量。

      （3）TDEV（ 度量单位为月 ） 表示开发进度，由工作量决定。

      （4）COCOMO 模型重点考虑 15 种影响软件工作量的因素，并通过定义乘法因子，从而准确、合理地估算软件的工作量。

    • 算法

      通过基础COCOMO的计算可以得出每个开发者需要投入的时间，整个项目的开发时间以及需要的人数,所需要的输入是软件的大小（以代码的行数（千行）为单位，记做SLOC）

      针对不同三种不同的工程结构，基础cocomo提供不同的系数：

      • 基础工程 - 小组拥有经验的开发人员开发需求定义不是十分严格的项目
      • 半独立项目 - 拥有不同程度的经验的中等规模的开发组开发部分需求是严格定义的，部分需求不是十分严格定义的项目
      • 嵌入式项目 - 开发拥有着严格的约束的项目，在软硬件等需求方面基础工程和半独立项目的组合

      基础COCOMO等式：

      需要的工作 (E) = ab(KLOC)^bb [单位是人员×月 ]

      开发时间 (D) = cb(Effort Applied)^db [单位是月]

      需要的人数 (P) = E/D [单位是个]

      其中KLOC是以千行代码为单位的软件大小，其他系数如： ab, bb, cb,db 如下图所示

      工程类型 ab bb cb db
      基础项目 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也存在一些很严重的缺陷，例如分析时的输入时优先的，不能处理意外的环境变换，得到的数据往往不能直接使用，需要校准，只能得到过去的情况总结，对于将来的情况无法进行校准等。

  • 软件生命周期

    • 软件生命周期的概念

      计算机软件有一个孕育、诞生、成长、成熟、衰亡的生存过程，即软件的生命周期(也称软件开发生命周期SDLC 或软件开发过程)。软件生命周期被划分为若干阶段，每个阶段有明确的任务，从而使规模、结构和管理复杂的软件开发过程得到适当的控制和管理。

    • 软件生命周期的划分

      软件生命周期分为6个阶段，包括可行性分析与开发计划、需求分析、设计(概要设计和详细设计)、编码实 现、测试、运行与维护等活动，将这些活动以适当的方式分配到不同的阶段去完成。

      • 可行性分析与计划阶段

        1. 确定软件开发的总体目标，给出功能、性能、可靠性以及接口等方面的要求，进行完成可行性分析。
        2. 估计可利用的资源(硬件、软件、人力等)、成本、效益、开发进度，进行投资-收益分析，制订开发计划。
        3. 提交可行性分析报告、开发计划等文档。

      • 需求分析阶段

        1. 分析用户提出的要求，给出需求详细定义，确定软件系统的各项功能、性能需求和设计约束，确定对文档编制的要求。
        2. 提交软件需求说明、软件规格说明、数据要求说明等文档和初步的用户手册。

      • 设计阶段

        1. 概要设计：把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应。
        2. 详细设计：对每个模块所要完成的工作进行具体的描述，提供源程序编写的直接依据。
        3. 提交结构设计说明、详细设计说明和测试计划初稿等文档。

      • 实现阶段

        1. 完成源程序的编码、编译(或汇编) 和排错调试，得到没有语法错误的程序清单。程序结构良好、清晰易读，且与设计相一致
        2. 编写进度日报、周报和月报(取决于项目的重要性和规模)。
        3. 提交用户手册、操作手册等面向用户的文档的编写工作。
        4. 编制测试计划。

      • 测试阶段

        1. 全面测试目标软件系统，并检查审阅已编制的文档，提交测试分析报告。逐项评价所生产的程序、文档以及开发工作本身，
        2. 提交项目开发总结报告。 在整个开发过程中(即前五个阶段中)，开发集体需要按月编写开发进度月报。

      • 运行与维护阶段

        1. 软件提交给用户后，在运行使用中得到持续维护，根据用户新提出的需求进行必要而且可能的扩充、删改、更新和升级。
        2. 软件维护包括改正性维护(发现错误)、适应性维护(适应运行环境变化) 和完善性维护(增强功能)。

  • SWEBOK知识域

    建立软件工程知识体系（SWEBOK）为软件工程确立边界，将其划分为10个知识域（KnowledgeAreas，KA），如下表：

    表1：SWEBOK知识域

    软件需求 Software Requirements
    软件设计 Software Design
    软件构造 Software Construction
    软件测试 Software Testing
    软件维护 Software Maintenance
    软件配置管理 Software Configuration Management
    软件工程管理 Software Engineering Management
    软件工程过程 Software Engineering Process
    软件工程工具和方法 Software Engineering Tools and Methods
    软件质量 Software Quality

    对于本课程，涉及下面这五个领域：

    • 软件需求分析
    • 软件设计
    • 软件开发过程
    • 软件工程工具和方法

  • CMMI的五个级别

    CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：

    ​ (1) 初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。

    ​ (2) 可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。

    ​ (3) 已定义级(Defined)。开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。

    ​ (4) 已管理级(Managed)。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，实现及时纠正。

    ​ (5) 优化级(Optimizing)。可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法

  • 对于CMMI的通俗解释

    CMMI英文全称是Capability Maturity Model Integration，直接翻译就是能力成熟度模型，直接看这几个中文字，你还是没有办法搞清楚CMMI是什么东西的。大家可能在网上见过很多《成功人士的七个习惯》（可能还有很多类似的名字）的文章吧？有人总结了成功人士的成功的原因，总结出他们的习惯，如果我们也能具备这些习惯，那么我们也很可能成为成功人士。类似的，CMMI可以看作是成功企业如何做好软件的一些习惯、做法、准则等的集合，是如何做好软件的最佳实践的集合。如果企业也能按照CMMI的要求做好，那么企业就很可能成为成功的企业。CMMI里面所有的要求，都是来自于成功企业的最佳实践的，具有很强的先进性。

Part II

  • 关于PSP的各项指标及技能要求

    根据PS2.1, 一位合格的软件工程师在收到任务后应该做如下的工作：

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

要完成这些工作，笔者认为可能需要如下技能：

1. 丰富的项目经历，能够根据以往经历大致推测出任务各个阶段的耗时。
2. 放眼全局的大局观，能够不纠结于细节，从整体上涉及项目的框架，掌握项目进展的节奏。
3. 一定的思维能力与文字功底 ，能清晰明确地分析需求，并将其整理为具体的、可操作的功能模块。
4. 勤于反思总结与自我纠正，能对自己的计划及实施情况有清楚的认识，并善于从中总结。

对于我们自己，要获取这些数据，可以通过看板工具 清楚地分配好个人任务与规划项目进展，通过github这个平台，我们可以实现对自我的测试与修改提交，并能在项目完成后通过github的contribution情况清楚地看到每个人地贡献。