Homework 1 for UML

简单题

软件工程的定义

  • 电气电子工程师学会(IEEE)给出的定义:”将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程,即将工程化应用于软件开发中”。

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

  • 软件危机(英语:Software Crisis)是早期计算机科学的一个术语,是指在软件开发及维护的过程中所遇到的一系列严重问题,这些问题皆可能导致软件产品的寿命缩短、甚至夭折。软件开发是一项高难度、高风险的活动,由于它的高失败率,故有所谓“软件危机”之说。软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之电脑的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说,它谈到了写出正确、可理解、可验证的计算机程序的困难。危机表现在几个方面
    • 项目运行超出预算。
    • 项目运行超过时间。
    • 软件质量低落。
    • 软件通常不匹配需求。
    • 项目无法管理,且代码难以维护。
  • 构造性成本模型(COCOMO,英文全称为Constructive Cost Model)是由巴里·勃姆(Barry Boehm)提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式,使用从项目历史和现状中的某些特征作为参数来进行计算。

软件生命周期

  • 软件生命周期(Software Development LifeCycle)是指软件的产生直到成熟的全部过程。把整个软件生存周期划分为若干阶段,使得每个阶段有明确的任务,使规模大,结构复杂和管理复杂的软件开发变的容易控制和管理。通常,软件生存周期包括:
    1. 问题定义。要求系统分析员与用户进行交流,弄清“用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”,提交用户审查和确认。
    2. 可行性研究。一方面在于把待开发的系统的目标以明确的语言描述出来,另一方面从经济、技术、法律等多方面进行可行性分析。
    3. 需求分析。弄清用户对软件系统的全部需求,编写需求规格说明书和初步的用户手册,提交评审。
    4. 开发阶段。开发阶段由三个阶段组成:
    1. 设计
    2. 实现:根据选定的程序设计语言完成源程序的编码。
    3. 测试
      1. 维护:维护包括四个方面 * 改正性维护:在软件交付使用后,由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段,这些隐藏的错误在某些特定的使用环境下就会暴露。 * 适应性维护:是为适应环境的变化而修改软件的活动。 * 完善性维护 :是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。 * 预防性维护:是为了进一步改善软件系统的可维护性和可靠性,并为以后的改进奠定基础。

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

  • 已发布的SWEBOK V3版软件工程领域内有以下15个知识领域(KAs):
    • Software requirements 软件需求
    • Software design 软件设计
    • Software construction 软件构建
    • Software testing 软件测试
    • Software maintenance 软件维护
    • Software configuration management 软件配置管理
    • Software engineering management 软件工程管理
    • Software engineering process 软件工程过程
    • Software engineering models and methods 软件工程模型和方法
    • Software quality 软件质量
    • Software engineering professional practice 软件工程专业实践
    • Software engineering economics 软件工程经济学
    • Computing foundations 计算基础
    • Mathematical foundations 数学基础
    • Engineering foundations 工程基金会
  • 本课程关注的KA包括:
    • Software requirements 软件需求
    • Software design 软件设计
    • Software engineering management 软件工程管理
    • Software engineering process 软件工程过程
    • Software engineering models and methods 软件工程模型与方法

解释 CMMI 的五个级别。例如:Level 1 – Initial:无序,自发生产模式。

  • Level 1 – Initial:初始级,软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。
  • Level 2 – Managed:可重复级/受管理级,建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。
  • Level 3 – Defined:已定义级,已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。
  • Level 4 – Quantitatively Managed,已量化管理级。分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。
  • Level 5#### Optimizing:优化级,过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

用自己语言简述 SWEBok 或 CMMI (约200字)

  • 能力成熟度模型集成(英文:Capability Maturity Model Integration,简称CMMI或“希迈”)是一个过程改进方法,它的目的是帮助组织改进他们的绩效。“希迈”可以被用于引导横贯一个项目、一个部门或一个完整的组织的过程改进。 “希迈”目前致力于三个感兴趣的区域:
    1. 产品和服务开发——希迈开发方面(英文:CMMI for Development,简称 CMMI-DEV 或“希迈-开”),
    2. 服务创建、管理和交付——希迈服务方面(英文:CMMI for Service,简称 CMMI-SVC 或“希迈-服”),以及
    3. 产品和服务采购——希迈采购方面(英文:CMMI for Acquisition,简称 CMMI-ACQ 或“希迈-采”)。

“希迈”由来自行业、政府和位于卡内基·梅隆大学的软件工程研究所(软工所)的一组专家开发。希迈模型为开发或改进用于达成一个组织的商业目标的过程提供指导。一个希迈模型也可能被用作用于评价组织的过程成熟度的框架。


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

阅读《现代软件工程》的 PSP: Personal Software Process 章节。

http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html

按表格 PSP 2.1, 了解一个软件工程师在接到一个任务之后要做什么,需要哪些技能,解释你打算如何统计每项数据?

  • 一个软件工程师在接到任务之后,有以下步骤:

    • 计划
      • 估计这个任务需要多少时间
    • 开发
      • 需求分析(包括学习新技术)
      • 生成设计文档
      • 设计复审(和同事审核设计文档)
      • 代码规范(为目前的开发定制合适的规范)
      • 具体设计
      • 具体编码
      • 代码复审
      • 测试(自我测试,修改代码,提交修改)
    • 记录时间花费
    • 测试报告
    • 计算工作量
    • 事后总结
    • 提出过程改进计划
  • 所需技能:
    • 软件开发的经验
    • 设计创新思维
    • 编码能力
    • 软件测试技能
  • 我认为在一般的不复杂项目中,我们可以通过统计各阶段完成时间来估计工作量,以及对项目进行分析。