Homework1 of Software-System-Analysis-and-Design

1、简答题

  • 软件工程的定义

    关于软件工程的定义，在 GB/T11457-2006 《信息技术 软件工程术语》中将其定义为”应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、和维护的工程或进行研究的学科”。简单地理解，可以说软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科，涉及了程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

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

    Software Crisis（软件危机）是早期计算机科学的一个术语，是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题皆可能导致软件产品的寿命缩短、甚至夭折。软件开发是一项高难度、高风险的活动，由于它的高失败率，故有所谓“软件危机”之说。从本质上来说，它谈到了写出正确、可理解、可验证的计算机程序的困难。危机表现在几个方面：

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

    COCOMO 模型（Constructive Cost Model，构造性成本模型），是由巴里·勃姆（Barry Boehm）提出的一种软件成本估算方法，基本的 COCOMO 是一种静态的单值模型，它使用以每千源代码行数（KLoC）来度量的程序大小来计算软件开发的工作量（及成本），其基本等式如下：

    其中 E 是用“人月”来计算的工作量，D 是指累积的开发时间（月），KLOC 是指对最终发布的代码行数的估计（千行代码），P 指需要的人数。而在中级 COCOMO 中则对软件工作量的估算使用了程度大小以及一组“成本驱动者”，包含了对产品、硬件、人员级项目属性的客观评价

    COCOMO 可以应用于三种不同的软件项目：

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

  • 软件生命周期

    软件生命周期（Software Development LifeCycle） 是指软件的产生直到报废或停止使用的生命周期。周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段。但随着新的面向对象的设计方法和技术的成熟，这样的周期概念也正逐渐减弱。

  • 按照 SWEBok 的 KA 划分，本课程关注哪些 KA 或 知识领域？    
    • 软件需求（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 1 - Initial：无序，自发生产模式
    • Level 2 - Managed：建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验
    • Level 3 - Defined：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的
    • Level 4 - Quantitatively Managed：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能
    • Level 5 - Optimizing：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进

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

    CMMI 全称是 Capability Maturity Model Integration，即 能力成熟度模型集成 （也有人称之为：软件能力成熟度集成模型）。它是一个过程改进方法，其目的是帮助软件企业对软件工程工程进行管理和改进，增强开发与改进能力，从而能够按时且不超预算地开发出高质量地软件。改模型依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI 为改进一个组织的各种过程提供了一个单一的集成化框架，其主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面

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

  • 阅读《现代软件工程》的 PSP：Personal Software Process 章节，按表格 PSP 2.1，了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？
Table PSP 2.1
  PSP State   Description Statistics Standard
Planning  计划阶段                        
  Estimate   估计这个任务需要多少时间   统计完成计划制定（包含ddl制定）所花的时间
Development 开发阶段  
  Analysis   分析需求   统计个人分析需求时，包含收集数据，调查需求等过程所耗的时间与人力
  Design Spec   生成设计文档   统计通过需求分析后的结果，完成产品设计文案所花的时间
  Design Review   设计复审（和同事审核设计文档）   统计完成设计后，寻求同伴共同探讨审核设计文案（设计合理性与可行性）并最终定案所用时间
  Coding Standard   代码规范（为目前的开发制定合适的规范）   统计确定设计后，为所设计的产品制定合适的代码规范所用时间
  Design   具体设计   统计确定规范后直至具体编码前所做的具体设计用时
  Coding   具体编码 记录具体编码（实现基本编码）阶段所用时长
  Code Review   代码复审   统计代码审核（仅做基本代码审查工作）的用时
  Test   测试（包括自我测试、修改代码、提交修改）   统计审查代码后所作的自我测试、修改代码并提交修改最终完成所用时间
Record Time Spent 记录时间花费   将以上所有工作总耗时统计一次，并分别计算占比
Test Report 测试报告   将测试过程中涉及到的问题已解决方法写成报告，并记录大概用时
Size Measurement 计算工作量  
Postmortem 事后总结  
Process Improvement Plan 提出过程改进计划