软工概论学习二

过程模型:

定义:

是软件的产生直到报废的生命周期到最终维护的全过程当中包含的哪些活动和任务的结构框架

瀑布模型:

先干完前一个阶段,才能干后面的一个,一个阶段一个阶段做。软件开发之后才知道软件是这样的。针对于系统来说

特点:

相邻阶段顺序性和依赖性
推迟实现的观点
质量保证的观点

规定软件生命周期自上而下、相互衔接的固定次序,如同瀑布一样,逐级下落

优点:

严格按照过程来做,强迫开发人员采用规范化的方法
每个阶段必须提交文档
每个阶段的产品都必须进行质量验证

缺点:

各阶段存在极少的反馈
只有在项目的生命周期的后期才能看到结果
通过过多的强制完成日期和里程碑来跟踪各个项目阶段

适合：

适合需求明确的项目开发

快速原型模型:

对于用户的需求,利用更快捷的手段,建立模型,让用户看到所希望的软件产品。其过程不是很严格。针对于某一部分功能来说。完成一部分功能,让用户看到。

主要是快速地利用工具软件生成代码,适用大型软件,分期的软件

优点:

可以得到比较良好的需求定义
适合需求有变化的人
有利于开发与培训同步
费用低，开发周期短且对用户友好

适合什么样的软件开发:

适合需求复杂、难以确定、动态变化的软件

增量模型:

根据增量需求是否明确,从而选用瀑布模型或快速原型模型

优点:

人员分配灵活
如果核心产品受欢迎，那么可以增加人力对下一个增量进行开发
能够有计划地管理技术风险
整体计划不能够按时完成的时候，可以推出核心产品进行示众

缺点:

由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
需求变化不可避免，比较容易退化为边做边改模型，从而是软件过程的控制失去整体性

螺旋模型:

优点:

设计上的灵活性,可以在项目的各个阶段进行变更
以小的分段来构建大型系统，使得计算成本变得简单容易
客户参与开发，保证了项目不偏离正确方向以及项目的可控性
随着项目推进，客户始终掌握项目的最新消息，从而能够和管理层进行互动
客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品

缺点：

采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
过多的迭代次数会增加开发成本，延迟提交时间

适用：
需求难以获取和确定、软件开发风险较大的软件系统

喷泉模型:

定义：

以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。

优点：

该模型的各个阶段没有明显的界限
开发人员可以同步进行开发
可以提高软件项目开发效率，节省开发时间
适应于面向对象的软件开发过程

缺点：

在开发过程中需要大量的开发人员，因此不利于项目的管理
要求严格管理文档

适用:主要用于采用面向对象技术的软件开发项目

统一过程与UML不是同一概念

解释:UML是提供支持面向对象软件工程时间必要的一种技术，是一种建模语言，并不是方法论；而统一过程是面向对象分析与设计的方法学，是一种软件工程框架

XP重构和结对编程

XP:极限编程,是一种轻量级的、灵巧的软件开发方法。具有严谨和周密的特征。

结对编程:指是两位程序员并肩坐在同一台电脑前,共同探讨设计方案、共同设计算法、共同编写程序代码、共同完成各种测试。

重构:以不改变代码外部行为而进行其内部结构的方式来修改软件系统的过程。它是一种修改或简化内部设计,净化代码的方法,目的是尽可能减少错误、优化系统
结对编程:两个人面对同一台计算机共同为一个故事开发代码。它提供了一种实时解决问题和实时质量保证机制,同时也使得开发者能集中精力于手头的问题

统一过程

四个阶段:

初始阶段

初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体,在较高层次上定义交互的特性。
细化阶段

细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。
构造阶段

在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量。
交付阶段

交付阶段的重点是确保软件对最终用户是可用的。

六个核心流:

需求工作流

目标:确保开发人员构建正确的系统
分析工作流

目标:分析和细化需求
设计工作流

对分析工作流的细化,直到设计模型可以被程序员实现为止
实现工作流

目标:用选择的实现语言实现目标系统
测试工作流

质量保证组的职责,每一个构建一旦实现,就由质量保证组对其进行测试,称为单元测试
部署工作流

制作软件的外部版本、软件打包、分发、为用户提供帮助和支持

其他

模型名称	技术特点	适用范围
瀑布模型	简单,分阶段,阶段间存在因果关系,各个阶段完成后都有评审,允许反馈,不支持用户参与,要求预先确定需求	需求易于完善定义且不易变更的软件系统
快速原型模型	不要求需求预先完备定义,支持用户参与,支持需求的渐进式完善和确认,能够适应用户需求的变化	需求复杂、难以确定、动态变化的软件系统
增量模型	软件产品是被增量式地一块块开发的,允许开发活动并行和重叠	技术风险较大、用户需求较为稳定的软件系统
迭代模型	不要求一次性地开发出完整的软件系统,将软件开发视为一个逐步获取用广需求、完善软件产品的过程	需求难以确定、不断变更的软件系统
螺旋模型	结合瀑布模型、快速原型模型和迭代模型的思想,并引进了风险分析活动	需求难以获取和确定、软件开发风险较大的软件系统
RUP	可改造、扩展和剪裁:可以对它进行设计、开发、维护和发布;强调迭代开发	复杂和需求难以获取和确定的软件系统;
软件开发项目组拥有丰富的软件开发和管理经验

借鉴MBA智库百科