软件危机
软件危机(Software Crisis)：计算机软件的开发和维护过程所遇到的一系列严重问题。
软件危机的表现：
- 对软件开发成本和进度的估算很不准确，甚至严重拖期和超出预算；
- 无法满足用户需求，导致用户很不满意；
- 质量很不可靠，经常失效；
- 难以更改、调试和增强；
- 没有适当的文档；
- 软件成本比重上升；
- 软件开发生产率跟不上计算机应用迅速深入的趋势。
软件生命周期
软件工具是指能支持软件生存周期中某一阶段（如系统定义、需求分析、设计、编码、测试或维护等）的需要而使用的软件工具。
软件工程就像是提高效率的系统的方法论。而软件工具就是统一格调的方法，但我认为这可以扩展到其他的事物上，在生活中也统合加载一套软件工程的方法论，这应该大有裨益。
过程流
过程模型
- 写了再改模型
- 瀑布模型
- 增量过程模型
- 演化过程模型
- 原型开发模型
- 螺旋模型
- 并发模型
- 基于构件的开发
瀑布模型
瀑布模型的变体–V模型
瀑布模型的特点
- 阶段间具有顺序性和依赖性
- 推迟实现的观点
- 质量保证的观点
瀑布模型的优点
- 可强迫开发人员采用规范的方法（例如，结构化技术）。
- 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
- 严格地规定了每个阶段必须提交的文档。
瀑布模型的问题
- 难以应对需求变化：客户难以准确表达需求，软件团队很难准确理解需求。
- 过于理想：实际项目很少按照该模型给出的顺序进行；
- 风险太大：用户必须有耐心，等到系统开发完成才能见到软件；
- 阻塞状态：开发者常常被不必要地耽搁。
瀑布模型的适用场合
- 需求相当稳定，客户需求被全面的了解风险管理。
- 开发团队对于应用领域非常熟悉。
- 外部环境的不可控因素很少。
- 小型清晰的项目。
原型开发模型（快速原型）
原型开发模型的产生：
瀑布模型将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。
然而完整而准确的需求规格说明是很难得到的，因为： 在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求
随着开发工作的推进，用户可能会产生新的要求
开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境
原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。
一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发
原型开发的优点
快速开发出可以演示的系统，方便了客户沟通。
采用迭代技术能够使开发者逐步弄清客户的需求。
原型的使用策略：
废弃（throw away）策略 主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统
追加（add on）策略 主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统
增量模型
增量模型以迭代的方式运用瀑布模型。
随着时间的推移，发布一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。
增量模型的使用方法
软件被作为一系列的增量来进行开发，每一个增量都提交一个可以操作的产品，可供用户评估。
第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性。
客户使用上一个增量的提交物并进行评价，制定下一个增量计划，说明需要增加的特性和功能。
重复上述过程，直到最终产品产生为止。
增量模型的优点
提高对用户需求的响应：用户看到可操作的早期版本后会提出一些建议和需求，可以在后续增量中调整。
人员分配灵活：如果找不到足够的开发人员，可采用增量模型，早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力。
可规避技术风险：不确定的功能放在后面开发。
增量模型存在的问题
每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西。
加入新增量时应简单、方便 ——软件的体系结构应当是开放的。
仍然无法处理需求发生变更的情况。
管理人员须有足够的技术能力来协调好各增量之间的关系。
难以确定所有版本共需的公用模块。
螺旋模型
Boehm于1988年提出，是一种演化过程模型，主要针对大型软件项目的开发。 风险驱动的软件开发模型
采用循环的方式，逐步加深系统定义和实现的深度，确定一系列里程碑，确保stakeholders都支持系统解决方案。
第一圈一般开发出产品的规格说明，接下来开发产品的原型系统，并在每次迭代中逐步完善，开发不同的软件版本，结合了原型的迭代性质和瀑布模型的可控性、系统性特点。
螺旋模型的优点
结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型。
采用循环的方式逐步加深系统定义和实现的深度，同时更好地理解、应对和降低风险。
确定一系列里程碑，确保各方都得到可行的系统解决方案。
始终保持可操作性，直到软件生命周期的结束。
风险驱动。
螺旋模型存在的问题
螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。
软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。
专用过程模型
基于构件的开发 — 能够使软件复用
形式化方法模型 — 注重需求的数学规格说明
面向方面的软件开发 — 为定义、说明、设计和构建方面提供过程和方法
统一过程 — 一种“用例驱动、以构架为中心的迭代和增量”，软件过程和统一建模语言(UML)紧密结合
优点：
充分利用软件复用，提高了软件开发的效率。
允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。
缺点：
缺乏通用的构件组装结构标准，风险较大；
构件可重用性和系统高效性之间不易协调；
由于过分依赖于构件，构件质量影响着最终产品的质量。
形式化方法模型
从广义上讲，形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。
狭义的讲，形式化方法是运用形式化语言，进行形式化的规格描述、模型推理和验证的方法。 形式化方法原则上就是用数学与逻辑的方法描述和验证软件。可以实现从描述到实现的自动转换。
优点
- 能够开发出无缺陷的软件
缺点
成本高、耗时
对开发人员的技术水平要求高
敏捷开发
软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长
敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品
敏捷价值观
个人和他们之间的交流胜过开发过程和工具
可运行的软件胜过宽泛的文档
客户合作胜过合同谈判
对变更的良好响应胜过按部就班地遵循计划
敏捷原则
我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 （小步快跑）
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
可运行软件是进度的首要度量标准。
提倡可持续的开发速度。责任人(sponsor)、开发者和用户应该能够长期保持稳定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单——是减少不必要工作量的艺术——是必要的 最好的架构、需求和设计出自于自组织团队。
每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。
敏捷过程
基于敏捷原则进行的软件开发过程，视为敏捷过程。
敏捷过程模型
- 极限编程
- Scrum
- 自适应软件开发（ASD）
- 动态系统开发方法（DSDM）
- 特征驱动开发（FDD）
- 精益软件开发（LSD）
- 敏捷建模AM
- 捷统一过程AUP
极限编程XP 极限编程是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。 极限编程的主要目标在于降低因需求变更而带来的成本。 采用迭代的交付方式，每个迭代很短（1-3周时间）。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。
- XP 编码
- 鼓励“测试驱动开发(TDD)”
- 鼓励“结对编程”
- 鼓励“重构”
- XP 测试
- 每天进行集成和确认测试（持续集成）
- “验收测试” 由客户确定，根据本次软件发布中所实现的用户故事而确定。
Scrum
- 一种敏捷开发的模型。
- 采用短周期迭代交付方式
Scrum 流程包括：
1
2
3
3个角色
3个工件
5个活动
Scrum中的角色
- 同项目经理类似的Scrum主管:负责维护过程和任务
- 产品负责人代表利益所有者
- 开发团队包括了所有开发人员
Scrum的工件（资料、文档）
- Product Backlog产品订单
- Sprint Backlog冲刺订单
- Burndown chart燃尽图
Scrum的活动
- Sprint冲刺
- Sprint planning meeting冲刺计划会
- Daily standup meeting每日立会
- Sprint review冲刺评审会
- Retrospective meeting回顾会议
软件需求
- 用户解决问题或达到目标所需的条件和能力
- 系统或系统部件为满足合同、标准、规范或
- 它正式规定文档所需具有的条件和能力
- 以上条件和能力的文档说明
软件需求的三个层次:
- 业务需求
- 用户需求
- 功能需求
需求工程的基本活动
获取需求
细化(需求分析)
协商
编写需求规格说明
确认需求
需求管理
需求获取技术
面谈
调查
观察实际业务过程
原型法
头脑风暴
场景技术