软件定义 以及软件过程模型

系统开发方法论

各类定义

软件定义： 计算机程序、文档，运行程序必须的数据、方法、规则。方法和规则在文档中说明，在程序中实现。

软件工程定义
把系统化、规范化、可度量的途径应用于软件开发、运行和维护过程中；研究其实现途径

软件分类：系统软件，支撑软件，应用软件
系统软件
居于计算机系统中最靠近硬件的一层。其它软件一般都通过系统软件发挥作用。它与具体的应用领域无关，如编译程序和操作系统等。编译程序把程序人员用高级语言书写的程序翻译成与之等价的、可执行的低级语言程序；操作系统则负责管理系统的各种资源、控制程序的执行。在任何计算机系统的设计中，系统软件都要予以优先考虑。
支撑软件
协助用户开发软件的工具性软件。支撑软件是在系统软件和应用软件之间，提供应用软件设计、开发、测试、评估、运行检测等辅助功能的软件，有时以中间件形式存在。随着计算机科学技术的发展，软件的开发和维护代价在整个计算机系统中所占的比重很大，远远超过硬件。因此，支撑软件的研究具有重要意义， 直接促进软件的发展。当然，数据库管理系统、 网络软件等也可算作支撑软件。
常见支撑软件：软件开发环境
1、软件开发环境(Software Development Environment，SDE)是指在基本硬件和宿主软件的基础上，为支持系统软件和应用软件的工程化开发和维护而使用的一组软件，简称SDE。它由软件工具和环境集成机制构成，前者用以支持软件开发的相关过程、活动和任务，后者为工具集成和软件的开发、维护及管理提供统一的支持。
2、数据库管理系统
数据库管理系统(Database Management System)是一种操纵和管理数据库的大型软件，用于建立、使用和维护数据库，简称DBMS。它对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。用户通过DBMS访问数据库中的数据，数据库管理员也通过dbms进行数据库的维护工作。它可使多个应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问数据库。

软件危机定义
在计算机软件开发和维护过程中遇到的一系列严重问题
软件危机主要表现
（1）开发成本和进度估计不准
延迟交付、取消项目
（2）用户对已交付软件不满意
开发人员对用户信息交流不充分，产品不符合用户需求
（3）软件产品质量靠不住
软件产品保证技术（审查、复审、测试）未坚持不懈应
用软件开发全过程
（4）软件可维护性差
开发时未考虑，很多错误难以改正
（5）软件没有适当文档资料 文档资料应在软件开发过程中产生，保证最新

软件生存周期
定义：软件生命周期(Software Life Cycle,SLC)是软件的产生直到报废或停止使用的生命周期
过程：
1、可行性研究与计划
2、需求分析
3、 总体设计
4、详细设计
5、实现（编码和单元测试）
6、集成测试： 将经过单元测试模块组装起来进行测试;通过测试使软件达到预定要求。
7、确认测试：由用户按需求规格说明书规定进行测试。
8 使用和维护

软件过程模型（生存周期模型）定义及分类

生存周期模型定义
实际从事软件开发工作时，软件规模、类型、 开发环境及技术方法等因素会影响到阶段划分， 及各阶段的执行顺序，形成不同生存周期模型， 又称过程模型。

分类：瀑布模型，快速原型模型，增量模型，螺旋模型，喷泉模型

瀑布模型
优点：(质量好)
提高软件质量，降低维护成本，缓解软件危机。
缺点：（需求方面灵活性差）
模型缺乏灵活性，无法解决需求不明确问题。用户不经过实践提出完整准确需求不切实际。
特点：
1.阶段具有顺序性和依赖性
前一阶段结束后一阶段开始，前一个阶段输出文档，后一个阶段输入文档。
2.推迟实现观点
瀑布模型在编码前设置系统分析、系统设计，推迟程序物理实现，保证前期工作扎实。
3. 质量保证观点
瀑布模型每阶段坚持两个重要做法:
一是每阶段都必须完成完整、准确的文档。软件开发时人员间通信、运行时期维护的重要依据。
二是每阶段结束前对文档评审。

传统瀑布模型过于理想化，但人在工作过程中 不可能不犯错误，所以实际瀑布模型带反馈环。

快速原型模型 快速建立反映用户主要需求的原型系统，反复由用户评价修正需求，开发出最终产品。
优点：（需求分析，交互）
1、 确定需求上优于瀑布模型（通过原型与用户交互）；
2、提供学习手段，通过开发原型和演示原型对开发者和使用者了解系统都有积极作用；
3、有的软件原型可以成为最终产品的一部分。
缺点：（快，结构不好）
快速建立的系统结构加连续修改可能导致产品质量低下原型系统的内部结构可能不好。

增量模型（渐增模型）
区别于瀑布和快速原型模型：
瀑布和快速原型模型是一次把满足所有需求产品提交给用户。增量模型是分批向用户提交产品。增量模型在各个阶段并不交付一个的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品， 开发软件时将软件产品作一系列增量构件设计、编码、集成和测试。 开发时分批逐步向用户提交产品，每次提交一个满足用户需求子集的增量构件，直到最后一次得到满足用户全部需求的完整产品为止。
优点（适应需求变化）
这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险
缺陷（开放式、整体性）： 
（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 
（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。 
实例（给出第一个增量模型，完善需求后再给出第2个）
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。 
例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。 

螺旋模型 （ 加入风险分析，常指导大型软件项目）
优点：
大型软件开发项目有较好的风险控制；
缺点：
需要风险评估的经验；
笛卡尔坐标四象限表达四方面活动：
制定计划 ，风险分析 ，实施工程 ，客户评估
沿螺线自内向外每旋转一圈开发出更完善新版本。

喷泉模型（面向对象方法的生存周期模型）
优点：
无缝，可同步开发，提高开发效率，节省开发时间， 适应面向对象软件
缺点：
可能随时加各种信息、需求与资料，需严格管理文档，审核的难度加大
特点:
1 迭代：
求精，系统某部分常被重复工作多次，相关功能在每次迭代中逐渐加入演进系统。
2 无缝：
分析、设计、编码各阶段间不存在明显边界。

敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中 就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态
核心原则
◆主张简单
当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建（overbuild）你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。
◆拥抱变化 需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。

软件开发有一大难题就是客户脑子中的需求难于描述出来， 我们通常的应对方法是这样：
先花上几个月整理需求， 天天和客户座谈， 画出几百页的流程图， 写出上千页的文档， 最后把客户都快搞晕了。
软件开发有一大难题就是客户脑子中的需求难于描述出来， 我们通常的应对方法是这样：
先花上几个月整理需求， 天天和客户座谈， 画出几百页的流程图， 写出上千页的文档， 最后把客户都快搞晕了。
然后是详细设计， 开发， 测试， 我们强悍的技术团队开始发动， 一切都严格按照计划进行， 一切看起来都很完美， 看来项目马上成功结束了！
但是客户的验收测试给了我们当头一棒： 这个界面怎么少了一个选项 ？ 那个界面怎么不能跳转 ， 那个功能需要给领导一个后门， 还有， 我的业务规则怎么不能改？ 什么？ 在代码中写死了？ 唉，你们做的系统啊， 根本就不能用 ！每个人都很郁闷， 几个月的辛苦开发看来要付诸东流了。
从这个场景中能看出的是， 我们从客户那里得到的需求描述和需求文档， 其实离客户真正想要的软件还差的很远。 在瀑布式的开发模式下，验收测试发现的问题，要想改正代价是非常高昂的。
一个想法自然而然就浮现出来： 为了避免到最后习惯性崩盘，能不能让客户经常性的做验收测试？ 让他们经常性的去使用一个可以工作的软件， 从而告诉我们那些地方还有欠缺 ？ 那些地方做错了？ 这样我们可以迅速的修改， 这样我们就会轻松多了 ！
我们可以把软件开发划分成一个个小的开发周期， 例如每个周期就两三周时间， 在这两周之内我们完成一个或几个功能， 然后就让用户去试用， 有问题立刻反馈，在下一个开发周期马上改掉。 这样就可以逐步逼近客户的最终目标。
这还带来了一个额外的好处， 不用花费巨长的时间来分析，整理冗长的需求文档了。
听起来很美是不是？ 但是仔细想想这里边的问题很多。
引用于白话敏捷软件开发
为什么敏捷开发难于成功？