软件危机：
为了解决软件危机，1968、1969年NATO连续召开了两次会议，提出了软件工程的概念。
软件危机的具体表现：
●软件开发进度难以预测；
●软件开发成本难以控制；
●软件功能难以满足用户期望；
●软件质量无法保证；
●软件难以维护；
●软件缺少适当的文档资料。
软件工程定义
软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件
工程活动，包括以下4个方面。
(1)P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。
(2)D(Do)——软件开发。开发出满足规格说明的软件。
(3)C(Check)——软件确认。确认开发的软件能够满足用户的需求。
(4)A(Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。
敏捷模型
1.敏捷方法的特点
1)适应性和预设性
2)面向人而非面向过程
2.敏捷方法的核心思想
(1)敏捷方法是适应型，而非可预测型；
(2)敏捷方法是以人为本，而非以过程为本；
(3)迭代增量式的开发过程。
主要敏捷方法简介
(1)极限编程(ExtremeProgramming,XP)。在所有的敏捷型方法中，XP是最引人瞩目的。极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从4个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
(2)水晶系列方法。水晶系列方法是由AlistairCockburn提出的敏捷方法系列。它与XP方法一样，都有以人为中心的理念，但在实践上有所不同。其目的是发展一种提倡“机动性的"方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。Crystal家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的Crystal家族成员。
(3)Scrum。该方法侧重于项目管理。Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架(是一种流程、计划、模式，用于有效率地开发软件)。在Scrum中，使用产品Backlog来管理产品的需求，产品Backlog是一个按照商业价值排序的需求列表。根据Backlog的内容，将整个开发过程被分为若干个短的迭代周期(Sprint)。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求组成Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。当所有Sprint结束时，团队提交最终的软件产品。
(4)特征驱动开发方法(Feature Driven Development,FDD)。FDD是由Jeff De Luca和大师Peter Coad提出来的。FDD是一个迭代的开发模型。FDD认为有效的软件开发需要3个要素：人、过程和技术。
FDD定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。根据项目大小，部分角色可以重复。
FDD有5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。
统一过程模型(RUP)
软件统一过程(Rational Unified Process,RUP)是Rational软件公司创造的软件工程方法。RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。
RUP的生命周期
RUP软件开发生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，这9个核心工作流如下。
●业务建模(Business Modeling):理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
●需求(Requirements):定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
●分析与设计(Analysis & Design):把需求分析的结果转化为分析与设计模型。
●实现(Implementation):把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
●测试(Test):检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
●部署(Deployment):打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
●配置与变更管理(Configuration & Change Management):跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
●项目管理(Project Management):为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
●环境(Environment):为软件开发机构提供软件开发环境，即提供过程管理和工具的支持
RUP的四个阶段
RUP把软件开发生命周期划分为多个循环(Cycle),每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段(Phase)组成，每个阶段完成确定的任务。
●初始(inception)阶段：定义最终产品视图和业务模型，并确定系统范围。
●细化(elaboration)阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
●构造(construction)阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
●移交(transition)阶段：把产品提交给用户使用。
RUP中的核心概念
●角色(Role):Who的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，如体系结构师(Architect)、设计人员(Designer)、实现人员(Implementer)、测试员(tester)和配置管理人员(Configuration Manager)等，并对每一个角色的工作和职责都做了详尽的说明。
●活动(Activity):How的问题。活动是一个有明确目的的独立工作单元。
●制品(Artifact):What的问题。制品是活动生成、创建或修改的一段信息。也有些书把Artifact翻译为产品、工件等，和制品的意思差不多。
●工作流(Workflow):When的问题。工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。
RUP的特点
RUP是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。
对于一个软件系统，不同人员所关心的内容是不一样的。因此，软件的体系结构是一个多维的结构，也就是说，会采用多个视图(View)来描述软件体系结构。RUP采用如下所示的“4+1”视图模型来描述软件系统的体系结构。 在“4+1”视图模型中，分析人员和测试人员关心的是系统的行为，会侧重于用例视图；最终用户关心的是系统的功能，会侧重于逻辑视图；程序员关心的是系统的配置、装配等问题，会侧重于实现视图；系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图；系统工程师关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。
