软件开发过程

软件开发生命周期

软件从功能确定、设计到开发成功投入使用，并在使用中不断地修改、增补和完善，
直到被新的需要所代替而停止使用该软件的全过程。

1.问题定义阶段：明确要解决的问题是什么？
2.可性行研究阶段：明确做不做？
	用最小的代价在尽可能短的时间内从经济、技术、社会因素等方面论证解决方案
	的可行性。
3.需求分析阶段：  明确做什么？
4.概要设计(总体设计)阶段：明确怎么做？
5.详细设计阶段：明确具体做法？
	设计出程序的详细规格说明，即详细地设计每个模块，确定实现模块功能所需要
	的算法和数据结构。
    阶段性成果：详细设计规格说明书和单元测试计划等。
6.编码和单元测试阶段：编码和单元测试
7.综合测试阶段：通过各种类型的测试（及调试）使软件达到预定的要求。
	组装测试：根据设计的软件结构，把经过单元测试检验的模块按某种策略装配起
	来，在装配过程中对程序进行必要的测试。
	验收测试：按照规格说明书的规定，由用户对目标系统进行验收，看其是否达到
	需求规格说明书中定义的全部功能和性能等方面的需求。
9.软件维护阶段：各种必要的维护活动使系统持久地满足用户的要求。
	改正性维护：诊断和改正在使用过程中发现的软件错误
	适应性维护：修改软件易适应环境的变化
	完善性维护：根据用户的要求改进或扩充软件使它更完善
	预防性维护：修改软件为将来的维护活动预先做准备。

软件过程模型

    软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成
    各项任务的工作步骤。
    软件过程描述为了开发出客户需要的软件，什么人（who）、在什么时候
 （when）、做什么事（what）以及怎样（how）做这些事以实现某一个特定的
 具体目标。

瀑布模型：

1.瀑布模型又称线性顺序模型、生命周期模型，它强调开发的阶段性、早期计划和
需求调查以及产品测试。
	（1）时间上具有顺序性和依赖性
	（2）推迟实现的观点
	（3）质量保证的观点
 	   	   1）审核机制
 		   2）文档齐全
2.优点：瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布
模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。
3.缺点：“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。
	实际项目很少按照该模型给出的顺序进行；
	用户常常难以清楚地给出所有需求；
	用户必须有耐心，等到系统开发完成；
	过分依赖于早期的需求调查，不能适应需求的变化。

原形模型：

1.特点：可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。
2.原型模型存在的问题
       ⑴  为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。
       ⑵  为了演示，可能采用不合适的操作系统、编程语言、效率低的算法
，这些不理想的选择成了系统的组成部分。
       ⑶  在需求没有完全弄清楚，过程管理不够严格时会影响最终产品的性能。
3.对原型实现模型的基本要求：
       体现主要的功能；提供基本的界面风格；展示比较模糊的部分，以便于确认
或进一步明确，防患于未然；原型最好是可运行的，至少在各主要功能模块之间能够
建立相互衔接。
4.抛弃型（丢弃型）
       先构造一个功能简单质量要求不高的模型系统，对其进行反复分析修改，
形成比较好的设计思想，系统构造完成后就丢弃不用。针对系统的某些功能进行实际
验证，本质仍是瀑布模型。
演化型（追加型）
       由一个功能简单的模型系统作为最终系统的核心，再不断扩充修改逐步
 追加新要求，最后发展成最终系统。
 5.适用条件：用户不能给出完整、准确的需求说明，或者开发者不能确定算法的
 有效性，操作系统的适应性或人机交互的形式。

增量模型：

• 反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个
“增量”的发布或提交，该增量均是一个可运行的产品。
• 早期的版本实现用户的基本需求，并提供给用户评估的平台。
1.优点：
	在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交
产品。从第一个构件交付之日起，用户就能做一些有用的工作。
	整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步
开发。
	逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个
全新的软件可能给客户组织带来的冲击。
	采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段
多付出的劳动将在维护阶段获得回报。
2.困难：
	在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发
出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产
品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
	开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。
	多个构件并行开发，具有无法集成的风险。

螺旋模型：

螺旋模型的基本思想是降低风险。需要风险控制的一系列专门技术，因此投入较大，
适用于规模较大的复杂系统。
1.螺旋模型的优点
	对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量
作为软件开发的一个重要目标；
	减少了过多测试或测试不足；
	维护和开发之间并没有本质区别。
2.螺旋模型的特点
	风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大；
	主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户
能够更好的识别和对待每一个演化级别上的风险；
	随着迭代次数的增加，工作量加大，软件开发成本增加。

喷泉模型：


喷泉模型：

适用条件：主要用于支持面向对象开发过程，体现了软件创建所固有的迭代和
无间隙的特征。
特点：１. 开发过程有分析、系统设计、软件设计和实现4个阶段。
	  ２.各阶段相互重叠，它反映了软件过程并行性的特点。 
	  ３.以分析为基础，资源消耗成塔型。
	  ４.反映了软件过程迭代性的自然特性，从高层返回低层无资源消耗。 
	  ５.强调增量开发，整个过程是一个迭代的逐步提炼的过程。  
优点：
	喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是
可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
缺点：
    喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不
利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面
对可能随时加入各种信息、需求与资料的情况。

统一软件开发过程(RUP)

1.RUP是一个面向对象且基于网络的程序开发方法论。
2.RUP重复一系列周期，每个周期由一个交付给用户的产品结束。
  每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个
  核心工作流（需求、分析、设计、实现、测试）分别迭代。
# RUP过程模型四个阶段：
初始阶段：进行问题定义，确定目标系统范围，评估其可行性，降低关键风险。
细化阶段：制定项目计划、配置各类资源、建立系统架构（包括各类视图）。
构造阶段：开发整个产品，并确保产品可移交给用户。
移交阶段：产品发布、安装、用户培训。
# 特点：
（1）软件开发是一个迭代过程；
（2）软件开发是由用例驱动的；
（3）软件开发是以架构设计（Architecture Design） 为中心的。
# 适合的场景
从规模上说，它可以用于大、中、小型软件开发，从个人到大型团队开发都可以。

从种类上说，它可以开发信息管理系统、分布式系统、并行系统、实时系统及Web
系统。

RUP采用管理和技术相结合的二维方法，特别适合需求易变动的高风险项目。

敏捷开发与极限编程

# 什么是敏捷过程？
	敏捷过程是容易适应变化并迅速做出调整，在保证质量的前提下做到文档适量
适度。
    敏捷开发方法并不是一个具体的过程，而是一个概况性的术语。具有以人为
核心、循环迭代、响应变化的特点，着眼于高质量的快速交付令客户满意的工作软
件。
    
# 敏捷过程的特征
    开发过程以代码为核心，而不是以文档为核心。代码编写，测试，发布，重构，
然后进入第二次迭代，经过多次小型迭代开发过程逐步逼近实际需求。
    以人为本。程序员在软件开发中不再是单纯被管理的对象，而是开发的主体。
所有的主要设计策略的制定，开发方法的选择，需求的确定都由程序员决定，因为他
们才是真正生产软件的人，他们最了解如何开发软件。
    
# 敏捷方法如何保证开发进度，开发效率，开发质量？
（1）这个问题的答案就是靠人自我的管理，团队自我的管理。
（2）敏捷方法抛弃了机械、严格的过程控制，就必须依赖于程序员和开发团队的高
标准自我要求：严格的自律，团队合作精神，个人高度自觉的主动性，责任感。
       敏捷方法的高效和高质量实际上是以程序员的高素质和开发团队的高度合作
的开发文化为基础的。
       
# 敏捷过程的四条基本价值观
个体和交互         VS       过程和工具
可以工作的软件     VS       面面俱到的文档
客户合作           VS       合同谈判
响应变化           VS       遵循计划

# 敏捷开发的代表方法
1.动态系统开发： DSDM
        ——Dynamic  Systems Development Method 
2.特征驱动开发：FDD
        ——Feature-Driven Development
3.水晶模型: Crystal
4.Scrum模型
5.极限编程：XP
        ——eXtreme Programming
        
# 极限编程XP
1.极限编程是敏捷开发中最有名的一个, 适于小型项目。
2.极限编程对于传统的软件工程看来是“极端的”实践。
3.XP团队使用现场客户、特殊计划方法和持续测试来提供快速的反馈和全面的交流。
这可以帮助团队最大化地发挥他们的价值。

# 极限编程的四条基本价值观
 1.  改善沟通2.  寻求简单3.  获得反馈4.  富有勇气

极限编程的迭代开发过程

12条有效经验

结对编程： 所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建
的。

测试驱动开发： 编写单元测试是一个验证行为，更是一个设计行为。同样，它更是
一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验
证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，
然后使之通过。

重构：随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达
力。 

持续集成 ：团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有
人责任代码集成。

集体代码所有权： 任何结对的程序员都可以在任何时候改进任何代码。没有程序员
对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。 

编码标准： 系统中所有的代码看起来就好像是被单独一人编写的。 

隐喻： 将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单
独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道
该模块是错误的。 

可持续的速度： 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工
作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。

极限编程XP与RUP
相同点
它们的基础都是面向对象方法，都重视代码、文档的最小化和设计的简化，采用动态适应变化的演进式迭代周期(取代传统的瀑布型生命周期)、需求和测试驱动并鼓励用户积极参与等。
不同点
RUP细化阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础；而XP没有包含业务建模、部署等概念，反映了它以编程为中心，节省一切的思想。