02_软件生存周期与软件过程
02_软件生存周期和软件过程
软件生存周期
一个软件从立项起, 到废弃不用为止, 称为软件的生存周期.
一般被划分为三个阶段 : 计划 开发 运行.
软件生存周期的主要活动
需求分析
该阶段是从用户的角度去理解系统在功能上需要实现什么功能, 而不是怎样去实现, 需求分析的目标是把用户对待软件开发的软件提出的功能需求去整理, 也需要把性能需求, 环境约束等进行描述最终形成完整清晰规范的需求文档。
软件分析
他的任务是 ：用户和软件人员双方一起来充分地理解用户的要求，并把共同的理解明确地表达成一份书面资料——系统说明书。
软件设计
细分为总体设计和详细设计，总体设计包括确定软件的总体结构和其他全局性的设计原则，详细设计是确定软件中的每一个部件的数据结构和操作。形成 概要设计说明书，详细说明书。
编码(测试)
按照程序设计语言和可复用软件工具包把设计文档转换为源程序。
软件测试
在编码的同时对代码进行测试，执行集成测试，确认测试 和 系统测试。
运行维护
作为软件生命周期的最后一个阶段，运行维护阶段的主要任务是做好软件维护，使软件在整个生命周期内满足用户的需求并可以延长其使用寿命。
传统的软件过程
瀑布模型
瀑布模型是一种基于软件生命周期的线性开发模型。
瀑布模型图 ：
瀑布模型特点 :
- 阶段间的依赖性和顺序性
顺序性 ： 只有等前一个阶段完成之后，后一个阶段才能开始。
依赖性 ：前一个阶段的输出文档是后一个阶段的输入文档。
- 推迟实现
瀑布开发模型的实践表明，对于大中型软件而言，编码进行的越早，完成开发的时间反而越长，因为过早编码容易返工，造成灾难性的后果。
因此在瀑布模型中采用推迟实现，即为了避免返工的风险，在需求分析和软件设计阶段只考虑系统的逻辑模型，等到编码的时候再来完成程序清单。
- 保证质量
为了保证质量，瀑布模型对软件文档采取了以下两条严格的限制。
第一 : 每一个阶段必须完成相应的文档，如果文档不能完成则不能认为该阶段任务完成。
第二 ：每一阶段都要对完成的文档进行复审，以便尽早发现问题并解决问题。
- 存在的问题
只有当分析员做出准确的需求分析时，才能得到预期的效果，但是多数的用户并不熟悉计算机，且分析员往往对用户的专业也是了解不深，这样就难免会出现在开发的初始阶段不能彻底弄清楚软件的需求。
快速原型模型
快速原型模型的中心思想是 : 建立一个可以反映用户主要需求的模型，让用户实际的看一下系统的概貌，然后判断哪些功能需要改进原型直到建立完全符合用户需求的新系统。
原型系统只包括未来系统主要功能以及系统的接口，并不包括系统的细节，对系统的性能需求如硬件的运行速度也可以推迟考虑。
快速原型模式图 :
有可能存在的问题 :
- 用户舍不得将原型废弃不用，而要求开发者仅作少量修改就交付使用以减少成本。
- 开发者明知道他有很多的不足却不愿全部推到重来。
软件演化模型
随着软件规模的不断增长，复杂软件开始采用渐增式或者迭代式的开发方法，于是，一种称为演化模型的渐进式开发模型应运而生，迭代的思想为 ：使所开发的软件在迭代中逐步完善。
常见的演化模型有增量模型与螺旋模型。
增量模型
增量模型使瀑布模型的顺序特征与快速原型模型的迭代特性相结合的产物。
这种模型把软件看作一系列的相互联系的增量，每一次迭代完成其中一个增量。
例如 : 完成一个大型的文字处理软件，第一个增量完成文件管理，文档编辑与生成功能，第二个增量完成拼写检查等功能 …
螺旋模型
螺旋模型使目前软件开发中最常用的一种软件开发方法，使在瀑布模型和快速原型模型基础上演变而来，尤其适合于大型软件开发。
螺旋模型是一种典型的迭代模型，每迭代一次，螺旋线就前进一周。
缺点 ：它难以使用户相信演化方法使可控的，过多的时间周期会增加开发成本和时间，适用于需求不明确的项目使用。
构件集成模型
什么是构件 ：使用面向对象的思维将事物封装为包含数据和加工该数据的方法的类，经过适当的设计和实现的类称为构件。
构件集成模型的特征 : 构件集成模型利用预先定义好的构件来构造应用软件系统。
形式化方法模型
软件开发方法可以区分为形式化方法和非形式化方法，前者多流行于学术界，而后者意在用工程方法生产出质量高，易于维护的软件产品。
转换模型
转换模型是将形式化的软件开发方法与程序自动生成技术相结合的一种软件开发模型。
过程 ：
- 确定形式化的需求规格说明书。
- 进行自动的程序变换。
- 对形式化的记录进行测试。
净室模型
净室模型是一种形式化的增量开发模型，基本思想是在力求分析和设计阶段就消除错误，确保正确，然后在无缺陷的状态下实现软件制作。
7 种开发模型的主要特点
| 开发模型 | 特点 | 适用场合 |
|---|---|---|
| 瀑布模型 | 线性模型，每一阶段必须产生相应的文档 | 需求明确的中小型软件开发 |
| 快速原型模型 | 用户介入早，迭代完成用户需求，应用快速开发工具 | 需求模糊的小型软件开发 |
| 增量模型 | 每次迭代完成一个增量 | 容易分块的大型软件开发 |
| 螺旋模型 | 典型的迭代模型，重视风险分析 | 具有不确定性的大型软件开发 |
| 构件集成模型 | 软件开发与构件开发同时进行 | 领域工程，行业的中型软件开发 |
| 转换模型 | 形式化的需求规格说明书，自动的程序变换系统 | 理想化模型，暂没有软件支持 |
| 净室模型 | 形式化的增量开发模型，在结晶状态下实现软件开发 | 开发团队熟悉形式化方法，中小型软件开发 |
统一过程和敏捷过程
统一过程
统一过程（Unified Process，UP）是由 Rational 公司开发的一种以用例驱动、以体系结构为核心、迭代及增量的软件过程模型，由 UML 方法和工具支持，广泛应用于各类面向对象项目。
统一过程描述了软件开发过程中各个环节应该做什么,怎么做,什么时候做以及为什么这样做, 描述了一组以某种顺序完成的活动.
统一过程在一个二维空间中描述软件开发的活动, 他将一个生命周期分为四个阶段(初始,细化,构建,迁移) : 每个阶段有可以分为一个或者多个迭代. 迭代是一个完整的循环, 他的产品是一个可执行版本, 是正在开发的系统的一个子集, 从一个迭代到下一个迭代, 不断成长, 成为最终系统.
敏捷过程
敏捷开发是一种以人为核心，以迭代方式循序渐进的方法，其软件开发的过程被称为敏捷过程。
在这一过程中，软件被拆分为多个子项目，并且各个子项目都要经过测试，具备集成和可运行的特征，在此过程中软件一直处于可用的状态。
敏捷开发的价值观 ：
－ 个人和交互胜过过程和工具
－ 可以运行的软件胜过面面俱到的文档
－ 客户合作胜过合同谈判
－ 响应变化胜过遵循计划
敏捷开发是一个持续的应用原则，模式以及实践来改进软件的结构和可读性的过程，而不是一个事件，他致力于保证系统设计在任何在任何时间都尽可能简单，整洁，富有表现力。
极限编程
极限编程是一个轻量级的，敏捷的软件开发方法，同时它也是一个非常严谨和周密的方法，他的价值观为：交流，简单，反馈和勇气，即任何一个项目都可以通过４方面入手：加强交流，从简单做起，寻求反馈，勇于实事求是。
XP建议采用循环迭代的开发方法，他将复杂的开发方法分解为一个个相对比较简单的小周期，通过积极的交流，反馈以及其他一系列的方法使开发人员和客户都可以非常清楚开发进度，变化以及待解决的问题和潜在的困难等，并根据实际情况及时的调整开发过程。
软件可行性研究
可行性研究的内容和步骤
研究的内容：
－ 经济可行性：实现这个系统有没有经济效益，多长时间可以收回成本。
－ 技术可行性：现有的技术能否实现该系统，有哪些技术难点，建议采用的技术。
－ 运行可行性：为新系统规定的运行方式是否可行？
－ 法律可行性：新系统开发会不会在社会上或者政治上引起侵权破坏或者其他责任问题？
可行性研究的内容和步骤
研究的步骤：
－ 对当前系统进行调查和研究
－ 导出新系统的解决方案
－ 提出推荐的方案
－ 编写可行性论证报告
系统概述 ：包括对当前系统及其存在的问题进行简单描述, 新的目标系统和他的各个子系统的功能与性能, 新系统与当前系统的比较等.
可行性分析 : 这是报告的主体, 包括系统在经济上和技术上,法律上的可行性, 以及对新系统的主客观条件的分析.
责任问题？
可行性研究的内容和步骤
研究的步骤：
－ 对当前系统进行调查和研究
－ 导出新系统的解决方案
－ 提出推荐的方案
－ 编写可行性论证报告
系统概述 ：包括对当前系统及其存在的问题进行简单描述, 新的目标系统和他的各个子系统的功能与性能, 新系统与当前系统的比较等.
可行性分析 : 这是报告的主体, 包括系统在经济上和技术上,法律上的可行性, 以及对新系统的主客观条件的分析.
结论意见 : 综合上述分析, 说明新系统是否可行.