关于软件工程你至少应该掌握这些模型开云APP 开云官网入口
根据软件服务对象的范围不同： 通用软件（操作系统、数据库等） 定制软件（企业ERP、卫星控制系统等）
按软件工作方式不同（结合操作系统发展记忆）： 实时处理软件 分时软件 交互式软件 批处理软件
按照支撑应用开发的工具类型可以将其划分为 ： 支持软件开发过程的工具 支持软件维护过程的工具 支持软件管理过程和支持过程的工具
所谓软件危机（Software Crisis）就是计算机软件在开发和维护过程中所遇到的一系列严重问题，具体表现在：
Fritz Bauer首次提出了“软件工程”的概念：软件工程是为了经济地获得能够在实际机器上高效运行的可靠软件而建立和使用的一系列好的工程化原则。
Boehm为软件工程下的定义：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序提供所必需的相关文件资料。
Fairley认为：软件工程学是为在成本限额以内按时完成开发和修改软件产品所需的系统生产和维护的技术和管理的学科。
IEEE计算机学会将“软件工程”定义为：应用系统化的、规范化的、定量的方法来开发、运行和维护软件，即：将工程应用到软件。
八条一般原理： （1）抽象 （2）信息隐藏 （3）模块化 （4）局部化 （5）确定性 （6）一致性 （7）完备性 （8）可验证性
七条基本原理： （1）用分阶段的生命周期计划严格管理 （2）坚持进行阶段评审 （3）实行严格的产品控制 （4）采用现代程序设计技术 （5）结果应能清楚地审查 （6）开发小组的人员应少而精 （7）承认不断改进软件工程实践的必要性
特征：本活动的工作对象来自于上一项活动的输出，这些输出一般是代表本阶段活动结束的里程碑式的文档。根据本阶段的活动规程执行相应的任务。产生本阶段活动相关产出——软件工件，作为下一活动的输入。对本阶段活动执行情况进行评审。
瀑布模型将测试作为软件实现之后的一个独立阶段，使得在分析和设计阶段潜伏下来的错误得到纠正的时机大为推迟，造成较大的返工成本；而且体系结构级别的缺陷也只能在测试阶段才能被发现，使得瀑布模型驾驭风险的能力较低。 瀑布模型将测试阶段独立于编码之后，给人们造成了一种不良的影响，即：相对于编码而言，分析与设计工作更重要，而并没有强调测试的重要性，尽管测试有时会占据项目周期的一半时间。 V模型的价值在于纠正了人们这种错误的认识，将测试分等级，并和前面的开发阶段对应起来。
W模型由两个V型模型组成，分别代表测试与开发过程。 V模型虽然强调了测试阶段的重要性（对测试进行分级，并和开发阶段相对应），但它却继承了瀑布模型的缺点，即将测试作为一个独立的阶段，所以并没有提高模型抵抗风险的能力。 为了尽早发现分析与设计的缺陷，必须将测试广义化，即扩充确认（validation）和验证（verification）内容，并将广义的测试作为一个过程贯穿整个软件生命周期。基于这个出发点，Evolutif公司在V模型的基础上提出了W模型。 W模型也存在局限性，它并没有改变瀑布模型中需求、设计和编码等活动的串行关系，同时测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段的工作，因此，W模型仍然只适合于需求比较稳定的软件项目。
产生原因：瀑布，v，w都将软件生命周期划分为串行阶段，前一个阶段完成才能开始后一个阶段。但是完整而准确的需求规格说明很难得到。
原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。
1. 从认知论的角度看，原型方法遵循了人们认识事物的规律，因而更容易为人们所普遍接受。
2. 原型方法将模拟的手段引入分析的初期阶段，沟通了人们的思想，缩短了用户和开发人员之间的距离。
1. 对于一个大型系统，如果不经过系统分析得到系统的整体划分，而直接用原型来模拟是很困难的。
2. 对于大量运算的、逻辑性较强的程序模块，原型方法很难构造出该模块的原型来供人评价。
3. 对于原有应用的业务流程、信息流程混乱的情况，原型构造与使用有一定的困难。
4. 对于一个批处理系统，由于大部分活动是内部处理的，因此应用原型方法会有一定的困难。
由于需求很难调研充分，所以很难一次就开发成功。 演化模型提倡两次开发。 第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求； 第二次在此基础上获得较为满意的软件产品。
Mills等人于1980年提出 ，指首先对系统最核心或最清晰的需求进行分析、设计、实现、测试并集成到系统中。再按优先级逐步对后续的需求进行上述工作，逐步建设成一个完整系统的开发方法。
增量模型结合了瀑布模型和演化模型的优点。它可以让客户得到一些机会延迟对详细需求的决策，即客户的需求可以逐步提出来；另外每一次“增量”需求的划分与“增量”实现的集成是以不影响系统体系结构为前提的。
举例： 使用增量模型开发文字处理软件时，可以按照以下优先级进行增量开发：
主要针对大型项目的开发： （1）需求功能复杂，无法一开始就明确；开发周期长，中途需求经常变化； （2）往往存在诸多风险因素，在不同程度上损害软件开发过程和软件产品的质量，所以必须对风险进行管理。
制定计划：确定软件项目目标；明确对软件开发过程和软件产品的约束；制定详细的项目管理计划；根据当前的需求和风险因素，制定实施方案，并进行可行性分析，选定一个实施方案，并对其进行规划。
风险分析：明确每一个项目风险，估计风险发生的可能性、频率、损害程度，并制定风险管理措施规避这些风险。
客户评估：客户使用原型，反馈修改意见；根据客户的反馈，对产品及其开发过程进行评审，决定是否进入螺旋线的下一个回路。
喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。
各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。
特点： 迭代性、无间隙性 喷泉模型是以对象驱动的模型，主要用于描述面向对象的软件开发过程。
开发人员可以针对不同的对象集合并行进行开发，即存在多个子开发流程，这些子开发流程在对象集成时同步。其优点是可以提高软件项目开发效率，节省开发时间。但是，由于各个开发阶段的重叠性，开发人员的管理和阶段生成的工件管理存在困难，因此，在应用喷泉模型时需要结合其他模型，比如结合增量模型在增量管理方面的优点，合理地划分并发任务，控制开发人员的调度；结合瀑布模型在文档控制方面的优点，严格控制每一个迭代周期应该产生的文档，并进行评审，对于在本周期没有完成的任务，不应该象瀑布开云 开云体育平台模型那样不允许进入下一阶段，而是纳入下一次迭代周期。
构件组装模型利用==模块化思想==将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组装高效率、高质量地构造软件系统。构件组装模型本质上是演化的，开发过程是迭代的 。
构件组装模型的开发过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。
快速应用开发（Rapid Application Development，RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。
RAD模型使用构件组装方法进行快速开发。如果需求理解得很好且约束了项目范围，RAD过程使得一个开发队伍能够在很短时间内（如60到90天）创建出系统。 RAD采用第四代语言技术快速生成应用
⑴ 业务建模：通过捕获业务过程中信息流的流动及处理情况描述业务处理系统应该完成的功能，主要回答下列问题：什么信息驱动业务流程？生成什么信息？谁生成该信息？该信息流往何处？谁处理它？
⑵ 数据建模：对业务建模阶段中部分定义的信息流进行细化，形成一组支持该业务处理功能所需的数据对象。标识出每个数据对象的特征，并定义这些数据对象之间的关系。
⑶ 过程建模：数据建模阶段定义的数据对象被变换以实现完成一个业务功能所需的信息流，过程建模则对业务建模中的业务处理功能进行详细定义，这些业务处理功能的操作对象就是数据建模阶段形成的数据对象。
⑷ 应用生成：RAD利用第四代语言技术（4GL），复用已有的程序构件或是创建新的可复用构件，在自动化工具辅助下，完成软件的构件组装或者软件的自动生成，从而快速构造软件系统。
⑸ 测试及迭代：RAD模型强调复用，许多程序构件已经是测试过的，这减少了软件系统测试的时间，但新构件必须测试，所有构件间的接口也必须完全测试到。当一轮需求完成快速开发后，可以迭代进入下一轮需求的开发。
缺点： 并非所有应用都适合采用RAD，如果一个应用不能被模块化，那么构造应用的构件就无法快速获取。 由于时间约束，开发人员和客户必须在较短的时间内完成一系列的需求分析，沟通配合不当都会导致应用RAD模型的失败。 RAD适合于管理信息系统的开发，对于其他类型的应用系统，如技术风险较高、与外围系统的互操作性较高等，不太合适。
RUP统一过程模型是一个面向对象的基于web的程序开发方法论 。 RUP既是一种软件生命周期模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件要素整合在统一的框架中。
每个阶段结束于一个主要的里程碑(Major Milestones)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。
RUP的迭代增量开发思想是融合了喷泉模型和增量模型的一种综合生命周期模型。
敏捷建模原则： (1)优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意； (2)即使到了开发的后期，也欢迎改变需求； (3)敏捷过程利用变化来为客户创造竞争优势； (4)经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好； (5)围绕被激励起来的个体来构建项目； (6)给他们提供所需的环境和支持，并且信任他们能够完成工作； (7)在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈；工作的软件是首要的进度度量标准；敏捷过程提倡可持续的开发速度； (8)责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度； (9)优秀的技能和好的设计会增强敏捷能力； (10)简单是最根本的； (11)最好的构架、需求和设计出于自组织团队； (12)每隔一定时间，团队会在如何才能更有效地工作方面进行反省，对自己的行为进行调整。
实用软件工程（第二版），郑人杰、殷人昆、陶永雷，清华大学出版社 开云 开云体育平台2004Kaiyun App下载 全站Kaiyun App下载 全站
扫一扫关注微信公众帐号
