软件常用的开发步骤（软件开发方法整理）
软件常用的开发步骤（软件开发方法整理）对于软件生命周期的划分，不同的标准有不同的规定，如GB8566-88-软件工程国家标准-计算机软件开发规范将软件分为了8个阶段，具体如下：软件也有诞生和消亡，指软件自开始构思与研发到不再使用消亡的过程。2、软件开发模型3、软件重用技术4、形式化开发方法。
简单介绍软件开发方法是软件开发方法学。
提供该方法的主要目的是提高软件开发质量、降低软件的成本。
系统学习软件开发方法的步骤，主要有：
1、软件生命周期
2、软件开发模型
3、软件重用技术
4、形式化开发方法。
软件生命周期软件也有诞生和消亡，指软件自开始构思与研发到不再使用消亡的过程。
对于软件生命周期的划分，不同的标准有不同的规定，如GB8566-88-软件工程国家标准-计算机软件开发规范将软件分为了8个阶段，具体如下：
l 可行性分析与计划
通过可行性研究，来决定开发此软件的必要性，可行性分析中确定软件的目标、范围、风险、开发成本等内容，从而制定初步的软件研发计划。
产出物《可行性分析报告》、《初步软件研发计划》
l 需求分析
确定软件做成什么样
产出物《需求规格说明书》
l 概要设计
确定整个软件的技术蓝图，根据需求内容从技术层面完成设计方案，主要确定系统的架构、子系统之间的关系、接口规约、数据库模型、编码规范等内容。
作为程序员的工作指南，共程序员了解系统的内部原理。
产出物《概要设计说明书》
l 详细设计
从概要设计中进行细化。
产出物《详细设计说明书》
l 研发实现
编码和单元测试。
产出物源代码。
l 集成测试
经过细心的组织，制订集成测试计划。
产出物《测试用例》、《测试报告》
l 确认测试
验证软件是否同需求一致，是否达到了预期目标。
l 使用和维护
使用过程中会产生新的需求。同时软件维护的过程会贯穿整个软件的使用过程。
当使用和维护结束后，软件系统也就自消亡，软件系统的生命周期结束。
软件开发模型由于软件进行大规模的开发时代，需要遵循一定的开发方法才能取得成功，这些模式化的方法称之为开发模型。
瀑布模型核心思想：从一个特定的阶段流向下一个阶段。
该模型认为软件开发是一个阶段化的精确的过程。主要由需求分析、总体设计、详细设计、编码与调试、集成测试与系统测试，同时每个阶段都会向上一个阶段进行反馈缺陷，由上一个阶段进行修正。
优点：分段明确，阶段界限明确。
各个阶段会产生完整的文档，故也称之后面向文档的软件开发模型。
当软件需求明确、稳定时，可以采用瀑布模型按部就班地开发软件，反之会暴露需求的缺陷、后期修改代价昂贵、难以控制开发的风险。
瀑布V模型采用瀑布模型出现的缺陷无法避免，只能争取在交付前发现更多的缺陷。所以测试成为了最关键的环节。【测试质量直接影响到时软件的质量】，由此产生的瀑布V模型，提出更加强调测试。
1、完成需求分析之后进入总体设计外，还指向了系统测试，即将产生同软件需求一致的系统测试用例，同时软件产品是否符合最初的需求将在系统测试阶段得到验证。
2、其它的以此类推。
瀑布V模型除了保持瀑布模式的阶段文档驱动的特点，而且更强调了软件产品的验证工作。
|
瀑布模型的缺点： 1、所有后续工作来源地需求，如果需求出现不正确，所有事项将出现偏差。 2、后期的维护工作相当繁重，大部分是在修正需求中的问题。 3、瀑布模型难以适应变化，如果后期出现了需求变化，整个系统又得从头开始。 4、所有阶段完成才能交付给用户，用户等待时间长，有可能存在最终用户才发现不能够满足客户的需求。 5、每个阶段会产生一大堆的文档，这些文档对客户没有意义，但却需要花费大量的人力，所以也称瀑布模型为重载过程。 |
为若干瀑布的迭代，根据不同的迭代特点可以深化为螺旋模型、增量模型和原型开发。
将瀑布模型与演化模型结果，不仅体现了两个模型的优点，还强调了其他模型均忽略的风险分析。
螺旋模型包含4个阶段：需求定义、风险分析、工程实现和评审，组成一次迭代。
基于瀑布模型的开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制，把项目拆解成一个一个的小项目，每个项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调的是风险分析，适用于庞大而复杂、具有高风险的系统，及时地识别、分析、决定采取何种对策。
存在缺点：
1、需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
2、过多地迭代次数会增加开发成本，延迟提交时间。
增量模型主要用于系统的技术架构成熟、风险较低的时候，主要有两种策略：
1、增量发布：首先做好分析和设计工作，然后将系统划分为若干不同的版本，每一个版本都是一个完整的系统。用户可以在很短的时间内就可以得到系统的初始版本并试用，试用过程中进行反馈，降低项目风险，需要注意：
(1) 每一个版本都是完整的、可用的。
(2) 版本间增量要均匀，如一个月一次，不能存在一个版本为1个月，后一个片为4个月的情况。
2、原型法：每一次迭代都经过一次完整的生命周期，当用户很不明确需求和技术架构时，存在很多不可知的因素，可采用原型法。
(1) 初始时针对一般用户需求进行快速地实现，并不考虑算法的合理性或系统的稳定性。
(2) 主要目的是为了获取精确的用户需求，或验证架构的可用性。
后期会抛弃原型法，重新实现完整的系统。
构建组装模型利用软构建进行拱积木式的开发，即构件组装模型。
定义软件功能后，将对构件的组装结构进行设计，将系统划分成一组构件的集合，明确构建之间的关系。
构件是独立的、自包容的，因此架构的开发也是独立的，构件之间通过接口相互协作 。
优点：
1、构件的自包容性让系统的扩展变得更加容易
2、设计良好的构件更容易被重用，降低软件开发的成本。
3、粒度小时，可分为不同的若干小组，独立完成。
缺点：
1、对构件设计需要经验丰富的架构师，设计不良的构件难以实现构件的优点
2、重用度时，性能会做出让步
3、增加研发人员的学习成本
4、第三方构件的质量难以控制
统一开发过程统一开发过程（Unified Process UP）是一种软件过程，是一个优秀的软件开发模型，提供了完整的开发过程解决方案，可以有效地降低软件开发过程的风险。
UP的二维模型UP是一个二维模型，时间主线就是横轴的阶段，主要经过初始、细化、构建和交付。
纵轴是按不同的阶段进行的主要工作。
任何一个阶段的工作都不是绝对的，都是相互交叠配合的，但每一个阶段都有侧重点：
初始阶段：最重要的工作是界定系统范围，明确系统目的，这一阶段业务建模和需求工作成为重头戏。
细化阶段：开发者需要抽象出软件的逻辑模型，设计出软件的架构，这一阶段分析工作是最主要的工程活动。
构件阶段：开发者完成系统的构建，并进行测试和部署，这一阶段实施和测试是最主要的活动。
交付阶段：这一阶段不可避免地要对软件系统进行重构、修改、测试和部署。
纵轴而言，主要的工作流是：业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境称为UP的核心工作流。可分为工程活动与管理活动，业务建模、需求、分析设计、实施、测试、部署为工程活动，配置与变更管理、项目管理、环境称为管理活动。(其中环境，也称环境管理，主要用于定义必需的工具、活动的指南、活动的流程规范、工作产品的模板、基本的开发设施等 。
UP的生命周期生命周期与时间主线阶段一一对应，共有4个里程碑：
1、目标里程碑，对应先启阶段的结束，明确系统的目标和范围即到达该里程碑；
2、架构里程碑，开发者需要确定稳定的系统架构；
3、能力里程碑，已经足够稳定和成熟，并完成Alpha测试；
4、发布里程碑，需要完成系统的Beta测试、完成系统发布和用户培训等工作。
UP的特点1、每一个阶段都可以进行需求、设计等活动；
2、采用不同的迭代方式，可以演变为演化模型或增量模型；
3、更容易控制软件开发的风险；
4、未经裁剪的UP是一个重载过程；
5、实际应用中，可根据具体问题对UP进行裁剪，从而使其可以适应各种规模的软件和开发团队。
架构师在UP中的活动1、建立系统架构模型
2、同需求人员和项目管理人员密切协作
3、细化软件架构
4、保持整个架构的概念完整性
还需要定义设计方法、设计指南、编码指南、评审设计等 工作，也有人称UP是一个以架构师为中心的开发模型。
敏捷方法2001年2月发表《敏捷软件开发宣言》，指出
1、尽早地、持续地向客户交付有价值的软件对开发人员来说最重要的；
2、拥抱变化
3、经常交付可工作的软件
4、业务人员和开发人员紧密合作
5、满足团队人员的需求，并给予足够的信任
6、面对面沟通
7、进度的度量方式
8、可持续的开发
9、不断追求优秀的技术和良好的设计
10、最简单，尽可能减少工作量
11、最好的架构、需求和设计 都来自于一个自我组织的团队
12、团队要定期的总结如何能够更有效率，然后相应的自我调整
基于以上宣言，市场上共提出11种开发方法，如AD、AM、ASD、Crystal、FDD、DSDM、LSD、Scrum、TDD、XBreed、XP。
最常用的是XP（极限编程）。
极限编程XP为最成熟的一种，XP是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。
1、在更短时间内，更早地提供具体、持续的反馈信息；
2、迭代地进行计划编制，最开始迅速生成一个总体计划
3、依赖自动测试程序来监控开发进度
4、依赖口头交流、测试和源程序进行沟通
5、倡导持续的演化式的设计
6、依赖于开发团队内部的紧密协作
7、尽可能达到程序员短期的利益和项目长期利益的平衡
由价值观、原则、实践和行为4部分组成。
一、四大价值观
XP的核心是其总结沟通、简单、反馈、勇气4大价值观。
1、沟通：项目中许多问题就出在缺乏沟通的开发人员身上，所以要求小组成员之间做到时持续的、无间断的交流。鼓励大家口头交流、通过交流解决问题，提高效率。
2、简单：提倡够用就行，也就是尽量简单化。
3、反馈：开发人员要注重反馈，通过持续、明确的反馈来暴露软件状态的问题。
4、勇气：需要有勇气面对快速开发，面对可能的重新开发。
二、12个最佳实践
XP中集成了12个最佳实践。
1、计划游戏：先快速的制定一个概要设计，随着细化不断的清晰，再逐步完善这份计划，产生的结果是一套用户故事及后续的一两次迭代的概要设计；
2、小型发布：“持续集成、小步快跑”，每一次发布的版本应该尽可能的小，前提条件是每个小版本有足够的商业价值，值得发布。
3、隐喻：寻求共识、发明共享词汇、创新的武器、描述架构。
4、简单设计：认为设计不应该在编码之前一次性完成。
5、测试先行
6、重构：一种对代码进行改进，而不影响功能的实现技术；
7、结对编程：团队协作、知识交流与共享
8、集体代码所有制
9、持续集成
10、每周工作40小时
11、现场客户
12、编码标准
特征驱动开发FDD方法也是一个迭代的开发模型，FDD的每一步强调质量，不断地交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息。
一、FDD的角色定义
三要素：人、过程和技术，6种关键性角色：
1、项目经理：
2、首席架构设计师
3、开发经理
4、主程序员
5、程序员
6、领域专家
二、核心过程
1、开发整体对象模型：业务建模的阶段，强调全系统的完整的面向对象建模，需要领域专家和首席架构师相互配合，完成整体对象模型；
2、构造特征列表：所谓特征指的是一个小的、对客户有价值的功能，采用动作、结果和目标来描述特征，特征的粒度最好把握在两周之内，可以整理出系统的需求。
3、计划特征开发：项目经理构造出特征列表、特征间的依赖关系进行计划，安排开发任务；
4、特征设计：主程序员带着特征小组特征进行详细设计，为后面的构建做准备；
5、构建特征：实现
三、最佳实践
组成FDD的最佳实践包含：领域对象建模、根据特征进行开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。
软件重用软件重用利用已存在的软件元素建立新的软件系统，可以是软件产品、源程序、也可以是文档，甚至是领域知识。软件重用可以提高软件的开发效率、降低软件的开发成本、缩短软件的开发周期、提高软件质量。
重用主要包含：源代码重用、架构重用、应用框架的重用、业务建构的重用、文档及过程的重用、软构件的重用、软件服务的重用。
构件技术两个重要的特征：自包容和可重用。
形式化方法指采用严格的数学方法，使用形式化规约语言来精确定义软件系统。
