目录
第一章软件工程概述
软件
软件是与计算机硬件相互依存，构成完整计算机系统的另一部分，他是计算机程序，数据，和相关文档的完整集合 软件=程序+文档+数据
- 程序是按事先设计的功能和性能要求执行的指令序列；
- 数据是使程序能正常操纵信息的数据结构，具体来说包括使系统初始运行所必须的数据如数据库和表的结构及初始的数据，系统运行中所需要的各种代码表、各种标志等。
- 文档是与程序开发，维护和使用有关的图文材料（是有关于管理、开发、用户、维护人员使用的文档）
软件的特点
- 软件是一个逻辑产品
- 软件不存在磨坏，用坏，老化的问题
- 软件的诞生过程主要是研制，生产只是简单的拷贝
- 软件受硬件和环境的影响
软件的分类
- 系统软件
- 应用软件
- 工程/科学软件
- 嵌入式软件
- 人工智能软件
- 产品线软件
- WebApp
- 移动App
另一种分类
- 系统软件：位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。
- 支持软件：支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。
- 应用软件：特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。
软件危机
因为软件危机的出现所以出现了软件工程
具体表现
- 对软件开发成本和进度的估算很不准确，甚至严重拖期和超出预算；
- 无法满足用户需求，导致用户很不满意；
- 软件产品质量不可靠；
- 软件可维护性差；
- 软件的文档资料不完整；
- 软件成本比重上升；
- 软件开发生产率跟不上计算机应用迅速深入的趋势
为什么会产生软件危机？
- 与软件本身的特点有关 (难于维护, 逻辑复杂)
- 与软件开发与维护的方法不正确有关
软件工程
概念
- 1993IEEE:把工程化的思想应用到软件开发中，把系统化的，规范化的，可度量的的途径用于软件开发，运行和维护过程
- 计算机科学技术百科全书 软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等。
目标
提高软件的质量和生产率，也就是在给定的成本，进度的前提下，开发出满足用户需求的高质量软件
三要素
- 工具 软件工程工具为过程和方法提供自动化或半自动化的支持
- 方法 为构建软件提供技术上的解决方法。
- 过程层 提供了一个框架，在这个框架下可以建立一个软件开发的综合的计划
- 软件工程是一种层次化的技术。任何工程方法必须构建在质量承诺的基础上。
软件工程的特性
- 软件工程关注于中大型的软件系统构建
- 软件工程的中心课题是控制复杂性
- 软件经常变换
- 开发软件的效率很重要
- 和谐的合作是开发软件的关键
- 软件必须有效支持用户
三代软件工程
传统软件工程
结构化分析->结构化设计->面向过程的编码->软件测试
面向对象软件工程
- 过程式编程范型：程序=数据结构+算法
面向对象基本概念
对象+类+继承+消息通信
OO分析与对象抽取->对象详细设计->面向对象的编码和测试
- 面向对象编程范型：程序=对象+消息
基于构件的软件工程
领域分析和测试计划定制->领域设计->建立可复用构件库->查找并集成构件
- 基于构件技术的编程范型：程序=构件+架构
软件的生命周期
一个软件项目从开始立项起，到废弃不用止，统称为软件的生存周期
定义时期
- 问题定义 问题报告文档
- 可行性研究 可行性研究报告
- 需求获取与分析 软件需求说明书
开发时期
- 概要设计（总体设计） 产生最佳方案 总体设计说明书
- 详细设计 具体模块的实现
- 编码和单元测试
- 综合测试 集成测试 确认测试 系统测试
维护时期
改正性维护、适应性维护、完善性维护
软件开发工具
软件工具是指能支持软件生存周期中某一阶段（如系统定义、需求分析、设计、编码、测试或维护等）的需要而使用的软件工具。
软件过程
定义
一个为创建高质量软件所需要完成的活动、动作和任务的框架 。
瀑布模型
基于软件生存周期的线性开发模型
强调软件文档：
- 每一个阶段必须完成规定的文档
- 每一个阶段都要复审完成的文档
特点：阶段间的顺序性和依赖性、推迟实现的观点、质量保证的观点
- 顺序性：前一阶段的工作完成后才能执行下一阶段的任务
- 依赖性：前一阶段的输出文档是下一阶段的输入文档
瀑布模型的优点
- 可强迫开发人员采用规范的方法（例如，结构化技术）。
- 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
- 严格地规定了每个阶段必须提交的文档。
瀑布模型的问题
- 难以应对需求变化：客户难以准确表达需求，软件团队很难准确理解需求。
- 过于理想：实际项目很少按照该模型给出的顺序进行；
- 风险太大：用户必须有耐心，等到系统开发完成才能见到软件；
- 阻塞状态：开发者常常被不必要地耽搁。
带反馈环的瀑布模型（可以回头改正以前的错误）
原型模型
原型开发模型的产生：
- 瀑布模型将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。
- 然而完整而准确的需求规格说明是很难得到的，因为在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求
- 随着开发工作的推进，用户可能会产生新的要求
- 开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境
原则
一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发
原型模型— 适用情况
用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；
开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；
增量模型
原理
增量模型以迭代的方式运用瀑布模型。
随着时间的推移，发布一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。
增量模型的优点
- 提高对用户需求的响应：用户看到可操作的早期版本后会提出一些建议和需求，可以在后续增量中调整。
- 人员分配灵活：如果找不到足够的开发人员，可采用增量模型，早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力。
- 可规避技术风险：不确定的功能放在后面开发。
- 由于每次只提交部分用户功能，用户有较充分的时间学习和适用
增量模型存在的问题
- 每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西。
- 加入新增量时应简单、方便 ——软件的体系结构应当是开放的。
- 仍然无法处理需求发生变更的情况。
- 管理人员须有足够的技术能力来协调好各增量之间的关系。
- 难以确定所有版本共需的公用模块。
并行度更高
螺旋模型
特点：
- 瀑布模型（顺序性、边开发边复审）+快速原型（迭代性）
- 风险分析->发现、控制风险
一个螺旋式周期:
- 确定目标：确定目标，选择方案，选定完成目标的策略
- 风险分析：从风险角度分析该策略
- 实施开发：启动一个开发活动
- 客户评审：评价前一步的结果，计划下一轮的工作
螺旋模型的优点
- 结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型。
- 采用循环的方式逐步加深系统定义和实现的深度，同时更好地理解、应对和降低风险。
- 确定一系列里程碑，确保各方都得到可行的系统解决方案。
- 始终保持可操作性，直到软件生命周期的结束。
- 风险驱动。
螺旋模型存在的问题
- 螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。
- 软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。
迭代和瀑布的区别:
- 迭代和瀑布的最大的差别就在于风险的暴露时间上。
- 瀑布模型的特点（文档是主体），很多问题再最后才会暴露出来。
- 迭代模型的特点，根据风险列表选择要在迭代中开发新的增量内容，每次迭代完成时都会生成一个经过测试的可执行文件，可核实是否降低了目标风险。
喷泉模型
特点 面向对象生命周期模型，体现迭代和无缝特性。
- 迭代 求精系统某部分常被重复工作多次，相关功能在每次迭代中逐渐加入演进系统。
- 无缝 分析、设计、编码各阶段间不存在明显边界。
优点： 无缝，可同步开发，提高开发效率，节省开发时间， 适应面向对象软件
缺点： 可能随时加各种信息、需求与资料，需严格管理文档，审核的难度加大。
RUP统一过程
原理
- 描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动。
- 基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”
二维生命周期
- 9个核心工作流，分为6个核心过程工作流和3个核心支持流。
- 核心过程工作流：商业建模、需求、分析和设计、实现、测试、部署
- 核心支持流：配置和变更管理、项目管理、环境
RUP将软件开发分为四个阶段：
- 初始阶段：该阶段的主要任务包括确定项目范围和边界，识别系统的关键用例，展示系统的候选架构，估计项目费用和时间，评估项目风险。其意图是建立项目的范围和版本，确定业务实现的可能性和项目目标的稳定性。提交结果包括原始的项目需求和业务用例。
制品：构想文档、有关用例模型的调查、初始的业务用例、早期风险评估、显示阶段和迭代的项目计划等制品；
- 细化阶段：该阶段的主要任务包括分析系统问题领域，建立软件架构基础，淘汰最高风险元素。其意图是对问题域进行分析，建立系统的需求和架构，确定技术实现的可行性和系统架构的稳定性。提交结果包括系统架构及其相关文档、领域模型、修改后的业务用例和整个项目的开发计划。
制品：补充需求分析、软件架构描述、可执行的架构原型
- 构建阶段：该阶段相对简单一些，其主要任务包括资源管理、控制和流程优化，开发剩余的构件，然后进行构件组装和测试等。其主要意图是增量式开发一个可以交付用户的软件产品。
制品：准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述。
- 提交(迁移)阶段：该阶段的主要任务包括进行β测试，制作发布版本，用户文档定稿，确认新系统，获取用户反馈，培训、调整产品使最终用户可以使用产品。其主要意图是将软件产品提交用户。
每个阶段又分为若干次迭代，每次迭代有一个核心工作流，都会经历需求、分析、设计、实现和测试等活动。
敏捷过程与极限编程
敏捷开发
软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品敏捷价值观
- 个人和他们之间的交流胜过开发过程和工具
- 可运行的软件胜过宽泛的文档
- 客户合作胜过合同谈判
- 对变更的良好响应胜过按部就班地遵循计划
敏捷原则
- 我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
- 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
- 经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 （小步快跑）
- 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
- 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
- 在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
- 可运行软件是进度的首要度量标准。
- 提倡可持续的开发速度。责任人(sponsor)、开发者和用户应该能够长期保持稳定的开发速度。
- 不断地关注优秀的技能和好的设计会增强敏捷能力。
- 简单——是减少不必要工作量的艺术——是必要的
- 最好的架构、需求和设计出自于自组织团队。
- 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。
敏捷过程
基于敏捷原则进行的软件开发过程，视为敏捷过程。
敏捷过程模型
- 极限编程
- Scrum
- 自适应软件开发（ASD）
- 动态系统开发方法（DSDM）
- 特征驱动开发（FDD）
- 精益软件开发（LSD）
- 敏捷建模AM
- 敏捷统一过程AUP
极限编程XP
极限编程是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。
极限编程的主要目标在于降低因需求变更而带来的成本。
采用迭代的交付方式，每个迭代很短（1-3周时间）。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。
- XP 编码
- 鼓励“测试驱动开发(TDD)”
- 鼓励“结对编程”
- 鼓励“重构”
- XP 测试
- 每天进行集成和确认测试（持续集成）
- “验收测试” 由客户确定，根据本次软件发布中所实现的用户故事而确定。
1581
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
