软件工程导论01-概论
（钱乐秋-软件工程（第3版）-笔记）
软件工程
个人观点：软件工程是一门理论课，因为软件的特点，当时没有一个规范性系统性的开发流程，导致各种问题的发生（软件危机），因此，有了一门叫《软件工程》的科目，进行对软件开发过程的系统了解。
（这么无聊的东西不会真有人看吧，不会吧不会吧~）
软件危机
概念：软件危机是指许多项目不能满足客户的需求或许多软件项目超出预算和时间安排（客人、钱、时间）
表现：
- 对软件开发成本和进度估计不准确
- 用户对“已完成”软件系统不满意的现象经常发生（用户对成品不满意）
- 软件成品质量往往靠不住（软件质量不行）
- 软件常常是不可维护的或很难维护的（维护工作不行）
- 软件通常没有文档资料（无说明书）
- 软件成本在计算机系统总成本中所占的比例逐年上升（成本上涨）
- 软件开发生产率的提高远远跟不上计算机应用迅速普及深入的趋势
原因：
- 客户往往对需求表达不清晰，有二义性
- 软件开发人员对客户所提需求的理解和愿景有偏差
- 大型软件项目需多人协同完成，缺乏管理经验
- 开发人员不能有效地、独立地处理大型软件的全部关系
- 缺乏有力的方法学和工具的支持
- 软件项目的特殊性和人类的局限性
如何克服：
- 消除错误的概念和做法（关键在如何消除）
- 使用成功的（最新的）开发技术和方法
- 使用软件工具和软件工程支持环境
- 加强环境管理
计算机软件
计算机软件概念
计算机软件是在计算机系统中的程序和文档
程序：程序是计算任务的处理对象和处理规则
文档：文档是程序的一般阐明行资料
计算任务：计算任务是以计算机为处理工具的任务
处理对象：处理对象包括数据和信息
处理规则：处理规则是指数据处理的动作和步骤
计算机软件主要特点
- 软件具有逻辑结构
- 软件是被开发的或被设计的，有极大的维护工程
- 软件拥有比硬件老化更难的难题----新的需求
计算机软件的其他特点
- 软件要基于硬件的基础上进行开发
- 软件至今为止未实现自动化
- 软件开发成本较为昂贵
- 软件工作涉及到社会因素
软件的故障模型
软件的分类
- 系统软件
- 支持软件
- 应用软件
按软件工作方式划分：
- 实时处理软件
- 分时软件
- 交互式软件
- 批处理软件
按软件服务对象的范围划分：
- 项目软件
- 产品软件
按使用的频度进行划分：
- 一次使用
- 多次使用
按软件失效的影响划分：
- 高可靠性软件
- 一般可靠性软件
需求定义语言requirement defintion language
概念：需求定义语言用来书写软件需求定义
软件需求定义：软件需求定义是软件功能需求和非功能需求的定义性描述
功能需求：功能需求是指刻画软件“做什么”
非功能需求：非功能需求是指刻画诸如功能性限制、设计限制、环境描述之类的需求
经典的需求定义语言：PSL语言
功能性语言functional language
概念：功能性语言用来书写软件功能规约
软件功能规约：软件功能规约是软件功能严格而完整的陈述。通常它只刻画系统“做什么”的外部功能，而不涉及系统“如何做”的内部算法
典型的功能性语言有广谱语言、伪码、z语言
设计性语言design language
概念：设计性预言用来书写软件设计规约
软件设计规约：软件设计规约是软件设计严格而完整的陈述。一方面他是软件功能规约的算法细化，刻画软件“如何做”的内部算法；另一方面，他是软件实现的依据
典型的设计性语言有PDL预言（program design language）、流图、数据字典、架构图
实现性语言
概念：实现性语言用来书写计算机程序
实现性语言也称编程语言或程序设计语言
文档语言documentation language
概念：文档语言用来书写软件文档
例：各种说明书
软件工程
定义
软件工程是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法制作软件的工程。
目标
生产具有确定性、可用性以及价格合宜的产品
正确性：反映了软件产品实现相应功能规约的程度
可用性：反映了软件的基本结构、实现及其文档为用户可用的程度
价格合宜：反映了软件开发和运行的总代价满足用户要求的程度
原理
- 选取适宜的开发模型
- 采用合适的设计方法
- 提供高质量的工程支持
- 重视软件工程的管理
软件生存周期
软件有一个孕育、诞生、成长、成熟、死亡的生存过程，这个过程即为计算机软件的生存周期
软件生存周期可分为七个活动：
计算机系统工程、需求、设计、编码、测试、运行和维护
计算机系统工程：任务是确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算、可行性分析。
需求：主要解决开发软件“做什么”的问题。
确定软件功能、性能、数据、接口和约束等要求，生成软件要求规约
设计：主要解决“怎么做”的问题。
软件设计通常可分为系统设计（也称概要设计和总体设计）和详细设计
系统设计：任务是设计软件系统的体系结构，软件系统的组成部分、各个成分的功能和接口、成分间的连接和通信，同时设计全局数据结构
详细设计：任务是设计各个组成成分的细节，包括局部数据结构算法等
编码：用某种程序设计语言，讲设计的结果转换为可执行的程序代码
测试：主要是发现并纠正软件中的错误和缺陷和不当的功能。测试主要包括单元测试、集成测试、确认测试和系统测试。
运行和维护：在软件运行期间，当发现了软件中潜藏的错误或需要增加新的功能或使软件适应外部环境的变化等情况出现时对软件进行修改。
软件过程
定义
软件过程是生产一个最终满足目标要求且达到工程目标的软件产品所需要的步骤。软件过程是软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合。
含义
个体含义：指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程、软件管理过程等。
整体含义：指软件产品或系统在所以上述含义下的软件过程的总体。
工程含义：指解决软件过程的工程，应用软件工程的原则、方法来构造软件过程模型，并结合软件产品的具体需求进行实例化，以及在用户环境下的运作，以此进一步提高软件生产率，降低成本。
软件生存周期的过程
基本过程：供各主要参与方在软件生存周期期间使用
主要参与方：是指发起或完成软件产品开发、运行或维护的组织，包括软件产品的需方、供方、开发方、操作方和维护方。
支持过程：具有不同的目的，并作为一个有机组成部分来支持其他过程，以便取得软件项目的成功并提高软件项目的质量。根据需要，支持过程被其他过程应用和执行。
组织过程：可被某个组织用来建立和实现由相关生存周期过程和人员组成的基础结构，并不断改进这种结构和过程。
ISO/IEC 12207标准把软件生存周期中可以开展的活动分为5个基本过程，8个支持过程和4个组织过程。每一个过程划分为一组活动，每项活动进一步划分为一组任务。
5个基本过程：（货公开运维）
- 获取（acquisition）过程：确定需方向供方获取系统、软件或软件服务的活动
- 供应（supply）过程：确定供方向需方提供系统、软件或软件服务的活动
- 开发（development）过程：确定开发者定义并开发软件的活动
- 运行（operation）过程：确定操作者在规定的环境中为其用户提供运行计算机系统服务的活动。
- 维护（maintenance）过程：确定维护者提供维护软件服务的活动
8个支持过程：（党配直言雀脸审问）
- 文档编制：确定记录生存周期过程产生的信息所需的活动
- 配置管理：确定配置管理活动
- 质量保证：确定客观地保证软件和过程符合规定的要求以及建立的计划所需的活动
- 验证：根据软件项目要求，按不同深度确定验证软件所需的活动
- 确认：确认软件所需的活动
- 联合评审：确定评价一项活动的状态和产品所需的活动
- 审计：确定为判断符合要求、计划和合同所需的活动
- 问题解决：确定一个用于分析和解决问题的过程
4个组织过程：（关机改配）
- 管理：确定生存周期过程中的基本管理活动
- 基础设施：确定建立生存周期过程的基础结构的基本活动
- 改进：确定为建立、测量、控制和改进其生存周期过程所需开展的基本活动
- 培训：确定提供经适当培训的人员所需的活动
能力成熟模型CMM（Capability Maturity Model）
用于评价软件机构的软件过程能力成熟度的模型。
此模型在建立之初，主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程。
CMM提供了一个成熟度等级框架： 1级-初始级、 2级-可重复级、 3级-已定义级、 4级-已管理级和5级-优化级。
软件过程成熟度等级：（初重定管优）
- 初始级（initial）：软件过程的特点是无秩序的，甚至是混乱的。几乎没有说明过程是经过妥善定义的，成功往往依赖于个人或小组的努力。
- 可重复级（repeatable）：建立了基本的项目管理过程来跟踪成本·、进度和功能特性。指定了必要的过程纪律，能重复早先类似应用取得的成功。
- 已定义级（defined）：已将管理和工程活动两方面的软件过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。
- 已管理级（managed）：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。
- 优化级（optimizing）：过程的量化反馈和先进的新思想、新技术促使过程不断改进。
CMM的结构：
成熟度等级：表明了一个软件组织的过程能力和水平。除初始级外，每个成熟度等级都包含若干个关键过程域，为了达到某个成熟度级别，该级别（以及较低级别）的所有关键过程域都必须得到满足，并且过程必须实现制度化。
关键过程域：都有一组对改进过程能力非常重要的目标，并确定了一组相应的关键实践，CMM提供了18个关键过程域。
目标：定义了每一个关键过程域的范围、界限和意义。
关键实践：描述了建立一个过程能力，必须完成的活动和必须具备的基础设施。（软件过程必须包括什么，而不去规定这些过程是如何实现的）
每个关键过程域的关键实践都是按照5个共同特性进行组织的，主要解决关键实践的实施或制度化问题。
5个共同特性：执行约定、执行能力、执行活动、测量和分析、验证实现
18个关键过程域：
能力成熟模型集成CMMI
背景：CMM的成功导致了各种模型的衍生，每一种模型都探讨了某一特定领域中的过程改进问题，模型的繁衍导致模型框架、术语等方面的矛盾和不一致。美国国防部、美国国防工业委员会和SEI/CMU于1998年启动CMMI项目，希望CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。
CMMI模型为每个学科的组合都提供两种表示法：阶段式模型和连续式模型
CMMI阶段式模型
阶段式模型的结构类同于软件CMM，它关注组织的成熟度，其成熟度等级如下：
CMMI V1.1包含了24个过程域，他们被划分在成熟度等级2~5中，如下：
| 成熟度等级 | 过程域 |
|---|---|
| 已管理的 |
需求管理REQM 项目计划PP 项目监督和控制PMC 供应商合同管理SAM 度量和分析MA 过程和产品质量保证PPQA 配置管理CM |
| 已定义的 |
需求开发RD 技术解决方案TS 产品集成PI 验证VER 确认VAL 组织级过程焦点OPF 组织级过程定义OPD 组织级培训OT 集成化项目管理IPM 风险管理RSKM 集成化建组IT 决策分析和解决方案DAR 组织级集成环境OEI |
| 定量管理的 | 组织级过程性能OPP，项目定量管理QPM |
| 优化的 | 组织级改革和实施OID，因果分析和解决方案CAR |
CMMI连续式模型
连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级。（Capability level,CL）
CMMI中包括六个过程域能力等级，等级号为0~5。能力等级表明了单个过程域中组织执行的好坏程度。
允许组织对连续式模型的过程域进行剪裁，也允许对不同的过程域采用不同的能力等级
下图给出了某组织的过程域能力等级：
CL0未完成的：过程域未执行或未达到CL1中定义的所有目标
CL1已执行的：其共性目标是：
- 过程将可标识的输入工作产品转换成可标识的输出工作产品
- 实现支持过程域的特定目标
CL2已管理的：其共性目标集中于管理过程的制度化。
- 根据管理级规定，将使用哪个过程
- 项目遵循已文档化的计划和过程描述
- 所有正在工作的人都有权使用足够的资源
- 所有工作任务和工作产品都被监控、控制和评审
CL3已定义的：其共同目标集中于已定义过程的制度化。
- 过程是按照组织的剪裁指南，从组织的标准过程集中剪裁得到的
- 还必须收集过程资产和过程的质量，并用于将来对该过程的改进上
CL4定量管理的：其共性目标集中于可定量管理的过程的制度化。
- 使用测量和质量保证来控制和改进过程域
- 建立和使用关于质量和过程执行的定量目标作为管理准则
CL5优化的：使用量化（统计学）手段改变和优化过程域，以对付客户要求的改变和持续改进计划中的过程域的功效。
连续式模型，包含与阶段式模型相同的24个过程域，将24个过程域划分为过程管理、项目管理、工程和支持四个过程组：
| 类型 | 过程域 |
|---|---|
| 过程管理 |
组织级过程焦点OPF 组织级过程定义OPD 组织级培训OT 组织级过程性能OPP 组织级改革和实施OID |
| 项目管理 |
项目计划PP 项目监督和控制PMC 供应商合同管理SAM 集成化项目管理IPM 风险管理RSKM 集成化建组IT 项目定量管理QPM |
| 工 程 |
需求管理REQM 需求开发RD 技术解决方案TS 产品集成PI 验证VER 确认VAL |
| 支 持 |
配置管理CM 过程和产品质量保证PPQA 度量和分析MA 决策分析和解决方案DAR 组织级集成环境OEI 因果分析和解决方案CAR |
软件过程模型
定义
软件过程模型是软件开发全部过程、活动、任务的结构框架。
软件过程模型也称软件开发模型或软件生存周期模型
典型的软件过程模型有：
- 瀑布模型（waterfall model）
- 演化模型（evolutionary model）
- 增量模型（incremental model）
- 原型模型（prototyping model)
- 螺旋模型（spiral model）
- 喷泉模型（water fountain model）
- 基于构件开发模型（component-based development model）
- 形式方法模型（formal methods model）
瀑布模型
特征
- 接受上一阶段的结果作为本阶段的输入
- 利用这一输入实施本阶段应完成的活动
- 对本阶段的工作进行评审
- 将本阶段的结果作为输出，传递给下一阶段
缺点
- 缺乏灵活性，难以试应需求不明确或需求经常变化的软件开发
- 开发早期存在的问题往往要到交付使用时才发现，维护代价大
演化模型
- 许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功。
- 可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型（prototype），然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品。
- 演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程。
- 演化模型适用于对软件需求缺乏准确认识的情况。
- 典型的演化模型有：增量模型、原型模型、螺旋模型。
增量模型
增量模型特别适用于：
- 需求经常变化的软件开发
- 市场急需，而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发
增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术
原型模型
原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。
原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型。
被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。
原型的类型
（探石眼）
- 探索型：其目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性
- 实验型：其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠。
- 演化型：其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。
原型的使用策略
- 废弃（throw away）策略：主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统。
- 追加（add on）策略：主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统。
原型可作为单独的过程模型使用，它也常被作为一种方法或实现技术应用于其它的过程模型中。
螺旋模型
是瀑布模型和演化模型的结合，并增加了风险分析
螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：
制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
风险分析：评价所选的方案，识别风险，消除风险
工程实施：实施软件开发，验证工作产品
客户评估：评价开发工作，提出修正建议
- 螺旋模型出现了一些变种，它可以有3到6个任务区域。
- 螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本。
- 如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止。
- 多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。
喷泉模型
喷泉模型是一种支持面向对象开发的模型，体现迭代和无间隙特征。
迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中随之加入演进的系统
无间隙：开发活动之间不存在明显的边界
基于构件的开发模型
基于构件的开发是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化的、现存的软件构件。
领域工程：目的是构建领域模型、领域基准体系结构和可复用构件库。
- 为此目的，首先要进行领域分析，分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和领域基准体系结构，标识领域的候选构件。
- 对候选构件进行可变性分析，以适应多个应用系统的需要
- 构建可复用构件，经严格测试和包装后存入可复用构件库（称为构件工程）
应用系统工程：目的是使用可复用构件组装应用系统。
- 分析待开发的应用系统，设计应用系统的体系结构，标识应用系统所需的构件
- 在可复用构件库中查找合适的构件（也可以购买第三方的构件）
- 特化选中的构件，必要时作适当的修改，以适应该应用系统的需要
- 开发那些未找到合适构件的应用部分
- 组装应用系统
- 评价构件的复用系统情况，以改进可复用构件，同时对新开发的部分进行评价，并向构件工程推荐候选构件
基于构件的开发模型对提高软件生产率、提高软件质量、降低成本、提早上市时间起到很大的作用
形式方法模型
形式化方法（formal methods）是建立在严格数学基础上的一种软件开发方法。软件开发的全过程中，从需求分析、规约、设计、编程、系统集成、测试、文档生成、直至维护各个阶段，凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法。
形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的岐义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。
敏捷软件开发
软件开发的新挑战
- 快速的市场进入时间，要求高生产率
- 快速变化的需求
- 快速发展的技术
传统的软件开发方法
- 强调过程
- 强调文档
- 开发人员负担过重
称为重载(Heavyweight)方法
针对上述问题，产生了一系列轻载(Lightweight)方法，如XP、SCRUM等。
背景
2001年2月，新方法的一些创始人在美国犹他州成立了敏捷软件开发联盟 ，简称Agile 联盟。Agile 联盟起草了一个敏捷软件开发宣言，该宣言由四个价值观声明组成，并提炼出敏捷软件开发方法必须遵循的12条原则。Agile方法是在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法。笼统的讲就是，“刚刚好”（Just enough），即开发中的活动及制品既不要太多也不要太少。
Agile方法的价值观
1.个人和交互高于过程和工具
- 不是否定过程和工具的重要性，而是更强调软件开发中人的作用和交流的作用。
- 软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件。
- 如果光有定义良好的过程和先进的工具，而人员的技能很差，又不能很好地交流和协作，软件是很难成功地开发的。
2.可运行软件高于详尽的文档
- 通过执行一个可运行的软件来了解软件做了什么，远比阅读厚厚的文档要容易得多。
- 敏捷软件开发强调不断地快速地向用户提交可运行的软件（不一定是完整的软件），以得到用户的认可。（好家伙,对用户使用热暴力）
- 好的必要的文档仍是需要的，它能帮助我们理解软件做什么，怎么做以及如何使用，但软件开发的主要目标是创建可运行的软件。
3.与客户协作高于合同（契约）谈判
- 只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变。
- 要想通过合同谈判的方式，将需求固定下来常常是困难的。
- 敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来发现用户的需求。
4.对变更及时做出反应高于遵循计划
- 任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起止日期。然而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变。
- 因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划以适应变化。
Agile方法的指导原则
（太理想了，现实能存在绝对难能可贵）
- 最优先的是通过尽早地和不断地提交有价值的软件使客户满意
- 欢迎变化的需求，即使该变化出现在开发的后期，为了提升对客户的竞争优势，Agile过程利用变化作为动力
- 以几周到几个月为周期，尽快、不断地发布可运行软件
- 在整个项目过程中，业务人员和开发人员必须天天一起工作
- 以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任
- 项目组内效率最高、最有效的信息传递方式是面对面的交流
- 测量项目进展的首要依据是可运行的软件
- 敏捷过程提倡可持续的开发，项目发起者、开发者和用户应能长期保持恒定的速度
- 应时刻关注技术上的精益求精和好的设计，以增强敏捷性
- 简单化是必不可少的，这是尽可能减少不必要工作的艺术
- 最好的构架、需求和设计出自于自我组织的团队
- 团队要定期反思怎样才能更有效，并据此调整自己的行为
Agile方法的适用范围
- 需求不确定、易挥发（Volatile,意指今天的要求明天就不需要了）
- 有责任感和积极向上的开发人员
- 用户容易沟通并能参与
Agile的经典方法
Extreme Programming（简称XP）
- XP从字面上可以译为极端编程。实际上，XP是一种审慎的、有纪律的软件生产方法，其发明人为Kent Beck
- XP的核心是四大价值，即改善沟通、寻求简单、获得反馈和富有勇气
- XP独一无二的突出了测试的重要性，甚至将测试作为整个开发的基础，每个开发人员不仅要书写软件产品的代码，同时也必须书写相应的测试代码（苦逼开发要兼顾测试）
SCRUM
- SCRUM同样也包括了很多具体做法，比如，SCRUM将开发过程划分为30天的迭代周期，每一个迭代周期叫一个Sprint，每天有一个15分钟的短会，用来决定第二天的任务安排，这样的短会就叫做scrum
- SCRUM较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。
Crystal Methodologies（简称Crystal）
- Crystal是一系列的方法。不同类型的项目需要采用不同的方法。可从两个维度来划分项目，一是项目规模，以人数计算；二是产品发生错误的后果，以严重性计算
- Crystal也强调在每个迭代后的Review，并以此进行Crystal方法的自身改进
Feature Driven Development（简称FDD）
- FDD定义了5个流程，分别是Develop an Overall Model、Build a Features List、Plan by Feature、Design by Feature和Build by Feature
- 开发人员被归为两种，一种是程序员，另一种是class所有者。主程序员不作具体的编程工作，但要负责将Feature和Class对应起来，并充当开发协调者、设计者、技术支持和指导者等；class所有者则进行实际的编程（程序员不用写程序可还行）
Adaptive Software Development（简称ASD）
- ASD的发明人Jim Highsmith，他有多年的预测型方法的研究、教学和实施经验，但后来，他发现这些预测型方法根本就存在很大的缺陷，尤其不适合当前的软件业务
- ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不像其他方法那样有很多具体的实践方法，它更侧重为ASD的重要性提供最基本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性
Dynamic Systems Development Methodology（简称DSDM）
- DSDM也称业务中心框架开发方法，它倡导以业务为核心，快速而有效的进行系统开发
- DSDM描述了在快速开发以业务为中心的环境中包含的各个方面——项目管理、预估、原型建立、时光盒法、配置管理、测试、质量保证、角色和职责、项目组结构、工具环境、风险管理、可维护性、重用、以及供应商和购买者的关系
- DSDM的基本观点是，任何事情都不可能一次性的圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准
Pragmatic Programming
- 注重实效的编程方法对核心过程进行了审视——即根据需求，创建用户乐于接受的、可工作和易维护的代码
- 从个人责任到职业发展，直至保持代码灵活和易于改编重用的架构技术
- 防止软件变质、消除陷阱，编写灵活、动态和易适应的代码、避免出现相同的设计、用契约、断言和异常对代码进行防护等内容
CASE工具与环境
在软件工程活动中，软件工程师和管理人员按照软件工程的方法和原则，借助于计算机及其软件工具的帮助，开发、维护、管理软件产品的过程称为计算机辅助软件工程
软件工具是用来辅助计算机软件的开发、运行、维护、管理、支持过程中的活动或任务的软件
按支持的软件过程活动分类：
- 开发过程：需求分析工具，设计工具，编码工具，测试工具.
- 维护过程：版本控制工具，文档分析工具，逆向工程（reverse engineering）工具，再工程（reengineering）工具
- 管理过程：项目管理工具，配置管理工具，软件评价工具
集成型开发环境是一种把支持多种软件开发方法和过程模型的软件工具集成到一起的软件开发环境
集成型开发环境由环境集成机制和工具集组成
环境集成机制包括：
- 数据集成机制：为各种相互协作的工具提供统一的数据接口规范
- 控制集成机制：支持各个工具或开发活动之间的通信、切换、调度和协同工作，并支持软件开发过程的描述、执行与转接
- 界面集成机制：支持工具界面的集成和应用系统的界面开发，统一界面风格
软件工程导论01-概论相关推荐
- 软件工程导论 01章软件工程学概述
1.软件是程序.数据以及各种相关文档的集合. 程序是对计算任务的处理规则的描述,数据是对计算任务的处理对象的描述,文档则是有关计算机程序功能.设计.编制与使用的文字图形资料. 软件等于程序加数据加相关 ...
- 《软件工程导论》课后习题答案
<软件工程导论>课后习题答案 第一章 软件工程概论 1．什么是软件危机? 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题.这些问题表现在以下几个方面: (1)用户对开发出 ...
- 软件工程导论 期末知识点复习总结
title: 软件工程导论 期末知识点 复习 categories: 计算机专业课 tags: "软件工程" 软件工程知识点总结,仅仅为了期末考试.带*不重要了解一下即可,黑体重点 ...
- 软件工程导论团队项目
软件工程导论团队项目(速课小龙) 一．团队介绍 1.团队成员 邓 旭 2016012068 (组长) 陈逸璇 2016012056 周紫伊 2016012043 谢月鹏 2016012066 洪泽芳 ...
- 微信小程序云开发体会——总结软件工程导论大作业
微信小程序云开发体会--总结软件工程导论大作业 前言 第一次接触 具体难题 好用的技术 开发完之后的体会 无法不热爱更多 前言 可能大家完成这次作业都会选择比较擅长的领域--网页前后端.这的确是比较稳 ...
- 《软件工程导论》考研复试整理
一.名词解释 DFD 数据流图Data Flow Diagram PDL 过程设计语言 Process Design Language PAD 问题分析图 Problem Analysis Diagr ...
- 软件工程导论复试——一、软件工程学概述
软件工程导论复试 本文用书 <软件工程导论>第六版张海藩.牟永敏 清华大学出版社 一.软件工程学概述 软件危机:计算机软件开发和维护时遇到的一系列严重问题 典型表现: (1) 对软件开发成 ...
- 首经贸电子信息复试软件工程导论
一.名词解释 DFD 数据流图Data Flow Diagram PDL 过程设计语言 Process Design Language PAD 问题分析图 Problem Analysis Diagr ...
- 软件工程导论第三章复习总结附思维导图
软件工程导论第三章复习总结附思维导图 概述 准确回答"系统必须做什么" 必须理解并描述问题的信息域,根据这条准则应该建立数据模型 必须定义软件应该完成的功能,这条准则要求建立功能模 ...
- 软件工程导论期末考点总结
文章目录 一.软件工程学概述 1.1.软件危机 1.2.软件工程 1.2.1.软件工程的介绍 1.2.3.软件工程方法学 1.3.软件生命周期 1.4.软件过程 1.4.1.瀑布模型 1.4.2.快速 ...
最新文章
- iPhone Safari下iframe不显示滚动条无法滚动的解决方法
- 微服务接入oauth2_微服务权限终极解决方案，Spring Cloud Gateway+Oauth2实现统一认证和鉴权！...
- 七牛直播云服务技术揭秘
- 【渝粤题库】国家开放大学2021春1313学前儿童卫生与保健题目
- IDEA快速修改类名和文件名
- 实例57:python
- tornado框架基础05-模板继承、UImodul和UImethods
- Python numpy 多维数组切片
- java中awt和swing是的关系以及区别
- 进程间通信 IPC interprocess communication
- Android性能分析工具Systrace和TraceView的使用
- 基于机器视觉技术的表面缺陷检测技术综述
- android 关联dicom文件,基于Android的DICOM浏览器的开发
- PyS60开发环境搭建
- 219-6-3Google浏览器书签备份
- 数字化转型的必要性和意义
- MBA中国网关注：打造最佳团队的5大秘诀
- C++学习资料和视频
- 2021-第五空间智能安全大赛-Web-EasyCleanup
- SpringBoot基础的依赖说明