软件工程
软件危机（1968 60年代）
产生软件危机的原因：
一方面与软件本身的特点有关，另一方面也和软件开发和维护的方法不正确有关。
与软件本身特点有关：
1.软件不同于硬件，软件是计算机系统中的逻辑部件，缺乏“可见性”，管理和控制软件开发过程相当困难
2.软件在运行过程中不会因为使用长时间而被“用坏”，如果运行中发现了错误，很可能是遇到了一个在软件开发时期引入的在测试阶段没能检测出来的错误。
3.软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
4.对用户要求没有完整准确的认识就匆忙着手编写程序时许多软件开发工程失败的原因之一。
5.目前相当多的软件专业人员对软件开发和维护还有不少糊涂观念，在实践过程中或多或少采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。
6.错误的认知和做法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法让它运行，轻视软件维护等。
软件开发与维护的方法不正确有关：
1.只重视程序而忽视软件配置其余成分的糊涂观念。
2.软件开发人员在定义时期没有正确全面地理解用户需求，直到测试阶段或软件交付使用后才发现“已完成的”软件不完全符合用户的需要。
3.严重的问题是在软件开发的不同阶段进行修改需要付出的代价是很不相同的.
消除软件危机的途径：
1.首先应该对计算机软件有一个正确的认知。
2.必须充分认识到软件开发不是某个个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
3.应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法。
4.应该开发和使用更好的软件工具。
5.为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。
软件工程定义：（1968NATO 1993IEEE）
①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件;②研究①中提到的途径。
软件工程的基本原理：（7条）
1.用分阶段的生命周期计划严格管理
2.坚持进行阶段评审
3.实行严格的产品控制
4.采用现代程序设计技术
5.结果应该能清楚地审查
6.开发小组的人员应该少而精
7.承认不断改进软件工程实践的必要性
软件工程方法学
通常把在软件生命周期全过程中使用的一整套技术方法的集合成为方法学。
软件工程方法学包含三个要素：方法、工具和过程。方法是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；工具是为运用方法而提供的自动的或半自动的软件工程支撑环境；过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。区别（软件组成：程序 文档 数据）
目前使用的最广泛的软件工程方法学：
传统方法学:
传统方法学也称为生命周期方法学或结构化范型。它采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。
面向对象方法学:
与传统方法相反，面向对象方法把数据和行为看成是同等重要的，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
CASE :计算机辅助软件工程
**软件生命周期（三大八小）**填空
1.软件定义时期
1）问题定义—确定软件开发工程必须完成的总目标 要解决的问题是什么？
2）可行性研究–行或不行 值不值得？
3）需求分析—必须完成的功能 做什么？
2.软件开发时期
1）总体设计/概要设计—怎么做？
2）详细设计—怎么具体实现？
3）编码和单元测试—编写并测试编写的模块
4）综合测试—使软件达到要求
3.软件运行维护
1）软件维护—通过各种必要的维护活动使系统持久地满足用户的需要
软件过程
是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的步骤。软件过程描述为了开发出客户需要的软件，什么人、在什么时候、做什么事以及怎样做这些事以实现某一个特定的具体目标。
1.瀑布模型
–自上而下，用户需求须明确，文档驱动
–阶段间具有顺序性和依赖性、推迟实现的观点、质量保证的观点
2.快速原型模型：目的 获取需求
–快速、需求模糊
–资源规划管理困难、开发环境要求高
3.增量模型 适用：应用领域不熟悉 一次性开发难度大
–分批次交付、降低风险，先交付核心模块
4.螺旋模型
–风险分析（使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型）
–风险驱动
5.喷泉模型
–迭代、面向对象
6.Rational统一过程模型
–面向对象、用例驱动、适用大型项目
–最佳实践：迭代式开发 管理需求 使用基于构件的体系结构 可视化建模 验证软件质量 控制软件变更
–RUP软件开发生命周期：初始阶段 精化阶段 构建阶段 移交阶段
7.敏捷过程与极限编程
–敏捷过程：个体和交互胜过过程和工具 可以工作的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循计划
–极限编程（XP）：客户作为开发团队的成员 使用用户素材 短交付周期 验收测试 结对编程 测试驱动开发 集体所有 持续集成 可持续的开发速度 开放的工作空间 及时调整计划 简单的设计 重构 使用隐喻
8.微软过程
可行性研究的任务：确定问题是否值得去解决
可行性：技术、经济、操作、（法律 社会效益）
系统流程图：系统物理模型（黑盒）
