ISDM定义
ISDM不仅只是—种如何开发信息系统的方法／过程模型。ISDM是—套整体方法，包含：
- —个通过分析方法、工具和技术操作的分析框架。描述系统开发中分析问题与解决问题的行为特征。主要指，面向过程、面向数据、面向对象。
- 支持分析框架的过程模型(process-model , 指开发活动的次序和持续时间）。描述系统开发随时间变化而呈现的阶段特征和项目管理与组织上的特征。有些类似SDLC, 如，瀑布模型、原型法、螺旋模型、敏捷软件开发等。
- 从技术上来讲， mis开发是系统阶段特征和行为特征的结合。因此， ISDM可视为包含开发信息系统用到的所有方法、操作和过程的框架。
完整的ISDM包含SDLC与开发方法、开发技术、开发工具及环境三层。
• SDLC ：ISDM开发方法的过程模型可能混用多种SDLC 以适用不同项目需求。
• 开发方法：主要指面向过程、面向数据、面向对象。是—个通过分析方法、工具和开发技术操作的分析框架。
• 开发技术：中间件、可视化、软件复用等
• 开发环境和工具： CASE 、SDE 、SEE 、IPSE等
ISDM 中的这四项内容彼此相互联系、相互支持、相互制约。
• 开发环境／工具位于最底层，说明其他层面均需要开发环境／工具的支持
• 开发技术是组成开发方法的基本成分，例如，结构化开发方法是由结构化分析技术、结构化设计技术、结构化程序设计技术组成。开发技术也是过程模型/SDLC的有力支持者。
• 开发方法能够完成系统开发生命周期的每一个阶段。实际开发中可以根据项目特点混合使用多种过程模型和多种开发方法。
• SDLC模型为每—种开发方法提供了一种组织和实施开发过程的基本框架。
开发方法
开发方法是一组思想、规范、过程、技术、环境及工具的集成。
开发方法是将具体的方法与技术包装在—起而形成的—种思想体系。是—个通过分析方法、工具和技术操作的分析框架，服务于ISDM 。任何—种开发方法都需支持ISDM的过程模型。
分类：
- 面向过程的开发方法（ 结构化方法）一70年代的主流
将系统工程的概念运用于软件系统的开发过程中提出了自顶向下、结构化系统开发方法。- 系统化：自顶向下，模块化，层层细分
- 工程化：分阶段划分工作；每阶段设定许多工程化图表
• 各种流程图和结构图！如DFD 、TFD
• 程序文档
- 面向数据的开发方法（数据建模和信息工程）一80年代主流
- 面向对象的开发方法( OO方法）一90年代的主流
- 面向对象分析(OOA , Object-Oriented-Analysis)：根据系统的需求，识别分析对象、类、属性和结构并对其进行描述。大体按照如下步骤进行
- 面向对象设计(OOD , Object-Oriented-Design)：对分析的结果进行进一步的抽象、归类和整理并设计人—机界面、数据库及任务管理系统。
- 面向对象实现(OOP , Object-Oriented-Programming)：利用程序设计语言对对象类、组件和结构进行程序设计，将上—阶段的设计结果转化为实际应用。
- 面向对象测试(OOT , Object-Oriented-Testing)：对程序进行集成和测试。
开发技术
开发技术指运用一些特殊的工具和规则支持某一种开发方法或过程模型的某些阶段。
开发工具／环境
系统开发环境／工具是指用于支持SDLC 、开发方法以及开发技术的应用系统。
-
计算机辅助软件工程： Computer Aided Software Engineering, CASE
CASE方法是—种自动化或半自动化的信息系统开发环境，它能够全面支持除系统调查外的任意开发步骤，使原来由手工完成的开发过程转变为由自动化工具支持的自动化开发过程包括：流程建模与管理工具；项目计划与管理工具；文档工具；需求分析与跟踪工具；编程工具；质量保证工具；代码维护工具；Web开发工具；原型与仿真工具；数据库设计工具；界面设计与开发工具。。。
软件开发环境： Software Development Environment, SDE
软件工程环境： Software Engineering Environment ,SEE
集成化项目／程序支持环境： Integrated Project/Programming Support Environment, IPSE
SDLC
系统开发生命周期(system development life cycle , SDLC) 是—个描述系统开发阶段组成的框架。
SDLC通常包括必须顺序执行的—些开发阶段，包括：可行性研究，系统调查，分析，设计，开发，实施和维护(feasibility study, systems investigation, analysis, design, development, implementation, and maintenance , 实际上这个阶段的定义并没有统—标准，通常在5-20个阶段，不同学者，不同机构都有自己的阶段划分）。
不管采用什么模型，项目实施中有四项活动是必不可少的——需求、设计、编码和测试。
IS是针对具体目标构建的用于特定组织的非常复杂的结构。由于这种特殊性，每个系统开发过程需要—个指导框架来配置、概述和监控生命周期所有阶段的开发进度。虽然在这个框架中使用的方法取决千每个项目的特殊特征，但是有些关键组成部分是所有框架都应该包含的。
• 如，将开发过程分成几个阶段，每个阶段都有—个开始、结束、—系列特定的活动、可交付成果（为确保每个所需任务绩效责任而定期生成的文档）、监控工具等。
• 通过商业采购（从外部供应商购买—套软件应用程序）引入IS而非内部开发也—样。两者都意味着实施、成熟和终止的过程。
WBS (work breakdown structure) 是SDLC的核心，不同的过程模型有不同的实现。
分解的每—阶段规定它的任务、工作流程、管理目标及要编制的文档，使开发工作易于管理和控制，形成—个可操作的规范。
SDLC可以分为两种通用类型。
-
第—种是 瀑布模型(waterfall model, Royce 1970提出），它们描述了像瀑布流动—样顺序排列的连续阶段的SDLC模型。最初包括了7个步进阶段：系统需求、软件需求、分析、程序设计、编码、测试、操作(system requirements 、software requirements 、analysis 、program design 、coding 、testing 、operations) 。
- 瀑布模型是—种很流行的方法学，因此根据不同的研究和应用背景，它演变出了很多变种，各阶段的名称差异也很大。但，所有变体都有—个基本共性：是—个顺序模型，每个阶段必须在下—阶段开始之前完成，就像瀑布—样，软件开发被视为不断地向下流经不同阶段。
- 它本质上仍是从传统方法学（ 即功能分解）的角度描述IS开发，只是更强调流程、严格的文档、各阶段的自足性(self-contained) 。如，设计阶段开始前，必须彻底和最终确定需求分析，编码完全完成，才能进行测试。每个阶段被认为是—个静态组件，这个过程中是—个刚性的步骤。以前步骤的后续更改（例如，发现有需求被遗漏）没有办法处理。
SDLC-waterfall model-wbs，图中标记为▲阶段为选定的里程碑，该阶段完成时需进行里程碑评审活动，并对其输出进行严格的变更控制。
SDLC-waterfall model-wbs- 该模型的优点：
1、阶段分明、活动明确：为软件开发工作提供—种结构化、有序的方法；
2、过程控制可见性较强：按照顺序开展每—个阶段的工作／每—阶段是在上—阶段彻底完成的情况下才启动，可以保证每—个阶段的开发质量都有保证，减少了返工；
3、开发过程中的各项文档降低了沟通的成本，有利于及早发现问题，降低项目的阶段成本；
4 文档多，过程记录比较全，有利于后期维护。 - 该模型的缺点：
1、不能回溯：项目从开始到发布可见的版本需要较长的周期，用户直到项目开发晚期才能了解产品的真实面貌和质量，不易变更；如果必须回溯则回溯成本很大。
2、缺乏灵活性：不能跨阶段操作；
3、文档多，花费较多成本。 - 该模型的适用范围：
1、产品定义（或项目需求）和技术方案非常明确、用户的需求有很好的了解；
2、对质量的要求高于对成本和进度的要求；
3、工期相对较宽裕；
4、开发队伍技术力量较弱或缺乏经验；
5、需要经常维护项目。
-
第二种类型的SDLC是增量型模型(incremental-type models) 。
- 瀑布模型是单程过程(single-pass process)，而增量模型不是单程的，增量模型依次设计、测试和实施—部分系统，这样在每个阶段（或增量）中可以从客户那里获取—些反馈，从而帮助构建下阶段增量。
然后，该反馈将被用作下—次构建的起点。在不断的连续构建下，系统会逐步完善，直至充分满足用户意图。每个阶段都有自己的计划和结构，并允许以不同的速度和时间开发系统的各个部分，最终将其纳入整个系统。因此，该模型在突出了不同开发阶段顺序性的同时，也允许在各增量之间进行变更、改进。 - 基本步骤：
在定义了用户要求和系统需求进行总体构架设计后，采用序列化地创建产品的方法进行开发的过程。每—个线性序列产生软件的—个可发布的“增量”，第—个建立的增量完成预计功能／性能的—部分（往往包含了核心功能，即实现了基本的需求），下—个增量实现另外的部分，增加更多的功能／性能，然后与前面实现的增量进行集成，如此循环，直到系统完全实现。 - 增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进—步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。其实现过程简图如下所示：
• 在策划阶段，项目经理需要与客户协商确定增量量的数目、规模每—增量发布的时间表
• 在概要设计阶段需要考虑各增量集成的顺序、接口等问题，制定集成策略。
• 增量循环的循环体可以根据项目的实际情况进行控制。
SDLC- Incremental model-wbs- 该模型的优点：
1、在达到初始需求之前可降低成本：采用增量模型可以灵活分配人员，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下—个增量；
2、可快速生产出可使用的系统：它提供了—种先推出核心产品的途径，这样即可先发布部分功能给客户，对客户起到镇静剂的作用，．
3、能够有计划地管理技术风险。 - 该模型的缺点：
1、系统集成难度大：由于各个构件是逐渐并入已有的软件体系结构中的，各增量的集成难度增大，所以在概要设计阶段需要制定详细的集成策略，．
2、项目管理风险加大：在开发过程中，需求的变化是不可避免的，增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。 - 该模型的适用范围：
1、用户核心需求非常清楚；
2、项目人员不足
3、产品可以分割成不同的阶段分别完成
- 瀑布模型是单程过程(single-pass process)，而增量模型不是单程的，增量模型依次设计、测试和实施—部分系统，这样在每个阶段（或增量）中可以从客户那里获取—些反馈，从而帮助构建下阶段增量。
-
绝大多数SDLC模型都是瀑布模型、增置模型或两者混合体的变种。如：
• V模型源自瀑布模型，强调测试阶段，认为每个阶段都需要—定的测试。呈现为V形：先如瀑布模型般向下移动，从需求分析到设计再到编程，—旦编码完成，再回头向上移动，从单元测试、集成测试、系统测试到验收测试，进行多阶段测试。
• 快速应用开发模式(rapid application development model , RAD , Gottesdiener 1995) 源自增量模型，适用于有严格时间限制的项目，试图将IS开发同组织目标相结合。
• 螺旋模型(spiral SDLC model , Boehm 1988) 源自增量模型，系统开发呈现为连续的波浪形，类似螺旋式增长，同时引入了风险分析。- 系统开发过程由一系列循环或迭代组成。每次循环都从确定当前阶段的目标和需求以及备择方案和约束分析开始。
这个开始过程将用原型或其它模拟方法勾画出计划，同时突显出存在风险的领域（风险将在下一步中考虑）。
随着风险不断降低，原型也不断改进。当原型变得足够稳定，风险也降低到可接受的水平，就变换到基本的瀑布方法，进入步进阶段：概念、需求、设计、实施。
—旦这个周期结束，就立即启动另—个周期，这也意味着一个新的系统增量开始了。 - 螺旋模型与增量生命周期有—些相似之处，但后者没有风险评估。螺旋模型的各次循环将规划作为第—步，然后转向需求分析，随后计算风险。在风险计算阶段，模型启动—个风险确定和替代方案制定过程，因此风险管理可视为模型核心。
• 螺旋模型强调风险分析使其成为成为大型关键任务项目的理想模型。缺点是小型项目效率不高，风险评估过程会增加系统的费用。
• 迭代模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
• 迭代模型实施重要的关键点是架构设计（概要设计）、制定迭代开发计划。
SDLC-Spiral Life Cycle Model
- 迭代模型具有以下优点：
1、降低了在—个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这—个开发有误的迭代的花费；
2、降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙；
3、加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率
4 由于用户的需求并不能在—开始就做出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。 - 迭代模型的缺点：
1、风险管理成本较高：迭代模型本身强调风险，但风险管理本身也存在成本问题；如果风险管理成本过大，将会严重影响项目的利润，．
2、对项目组成员的要求非常高：在风险分析、进度管理等方面，需要有较高层次的人员配置及丰富的项目管理和项目实施的经验。这对于开发队伍技术力量较弱或缺乏经验的团队很难实施。 - 适用范围
1、在项目开发早期需求可能有所变化；
2、分析设计人员对应用领域很熟悉，．
3、高风险项目；
4、用户可不同程度地参与整个项目的开发过程，．
5、使用面向对象的语言或统—建模语言(Unified Modeling Language , UML)
6、使用CASE (Computer Aided Software Engineering 计算机辅助软件工程）工具，如Rose
7、具有高素质的项目管理者和软件研发团队。
• 原型模型是—个迭代框架，自上世纪80年代初以来，它就是许多敏捷导向的软件
开发方法的核心。研究发现，采用原型方法的SDLC模型被认为更有活力，更能满足客户需求，而且风险更低，效率更高。- 原型模型的基本思路是创建整个或部分系统的试用版（即原型， prototype) , 然后不断修正原型，直至最终版。
原型法是—个过程，可以是更大SDLC模型的—部分，也可以直接作为—种SDLC方法。其重点在软件创建，不太关注文档。它也奉行用户中心论，因为需要用户反馈修正原型 - 原型模型大体有四个阶段。
• 首先，分析和确定用户需求
• 接下来，开发原型
• 然后，由用户进行测试并提供实时反馈
• 最后，如果需要改进，则改进并发布新原型。
• 持续循环，直到用户接受产品，不再需要进行实质性更新，循环终止并发布最终版本。
- 原型模型根据原型最终保留清况分为非抛弃型和抛弃型两种：
• 非抛弃型原型是先根据用户的最主要的要求，开发出能实现系统最基本功能的—个原型，再根据用户对原型使用与评价的意见，反复修改完善原型，直到用户满意的最终系统为止。
原型模型从需求收集开始，软件开发组与目标用户—起定义软件的总体目标，标识出已知的需求，并规划出进—步定义的区域。然后是“快速设计”。快速设计建立软件中对用户可见的部分，即“原型”。原型由用户评估，
并据此进—步精化用户需求。逐步调整原型使其满足用户的要求，同时也使开发组对该软件有更好的理解，这个过程是迭代的，每—个迭代完成后均可生成—个可用的产品版本。
• 抛弃型原型—般用来描述和验证用户需求，可以采用与实际开发所不同的开发工具，建立模拟的数据库系统，从而达到与用户交流的最好效果。到用户需求确定之后即不再继续开发此原型。与非抛 - 弃型原型模型的主要区别在于：
• 目的不同，抛弃型原型模型的目的是为了与用户更好的沟逄；
• 手段不同，抛弃型原型模型采用的技术手段与正式开发可以完全不同；
• 结果不同，抛弃型原型模型的工作产品不会在软件研发中使用或大星使用，而多用于开发demo及验证用户需求。
- 原型模型具有以下优点：
1、符合人们认识事物的规律，系统开发循序渐进，反复修改，确保较好的用户满意度；
2、开发周期短，费用相对少；
3、由于有用户的直接参与，系统更加贴近实际，易学易用，减少用户的培训时间 - 原型模型的缺点：
1、开发过程管理要求高，整个开发过程要经过修改—评价—再修改”的多次反复，．
2、用户过早看到系统原型，误认为系统就是这个模样，易使用户失去信心；
3、开发人员易将原型取代系统分析
4、缺乏规范化的文档资料，不利于系统的后期维护。 - 原型模型适合于：
1、处理简单过程明确、涉及面窄的小型系统，．
2、大型系统的需求阶段，用原型去跟用户交流，需求分析会更加明确和细化。
原型模型不适合于：
1、大型复杂系统，难以模拟
2、存在大量运算、逻辑性强的处理系统
3、管理基础工作不完善、处理过程不规范的系统
4、大量批处理的系统。
• 敏捷模型 Agile Life Cycle Model
2001 年敏捷软件开发宣言(Agile manifesto) , 旨在将各种敏捷模型的最佳特征汇集到—起。敏捷宣言中总结了—下敏捷开发原则：
1、客户满意最重要的(Customer satisfaction is the highest priority)
2、需求变更不是开发障碍(Change in requirements is welcomed, no longer an obstacle)
3、定期连续发布软件(Software is delivered regularly in consecutive releases)
4、积极主动性是项目成功关键(Motivated individuals are key to successful projects)
5、面对面交流是成功合作关键(Face-to-face conversation is paramount to successful collaboration)
6、能用的软件是衡量项目进度的标准(Working software is the measure of the project's progress)
7、应鼓励可持续开发(Sustainable development should be encouraged)
8、重视技术和设计质量(Emphasis on technical and design quality)
9、应该倾向于简单化(Simplicity should be favored)
10、自组织团队是项目开发的最佳形式(Self-organizing teams are the best form of project development)
11、应该定期讨论团队改进问题(There should be regular discussions on team improvement)敏捷模型的众多变种都遵循这些原则，比较有名的如Scrum和XP模型。虽然各变种的时间段或阶段划分描述各不相同，我们还是可以将敏捷开发过程大体分为4步。
第1步是项目选择和批准(project selection and approval) 。在此阶段，由开发人员、管理人员和用户组成的团队会确定系统的范图、目标和需求，彻底分析各种备选方案，评估各种想法的风险。
第2步是项目启动(project initiation) 。确定项目目标和范围后，组建开发团队，并配备好适当的环境和工具，以及系统所依据的工作架构，拟定工作计划。
第3步是迭代构建(construction iterations) , 每次迭代都包括规划和构建。开发人员以连续增星的方式发布软
件，以不断满足各利益相关方的需求。这—阶段很强调合作，测试也很重要。
第4步是产品发布(product release) , 包括两步：首先，完成对整个系统的最终测试，以及任何必要的更正和文档；然后，发布产品，向用户提供培训。开发团队可能会维护项目，以便后续的产品改进和用户支持。优点：
• 敏捷SDLC能在几个星期而不是几个月内交付产品，开发速度非常快。
• 另—个优点是它非常灵活，能在严格的时间限制内，需求不断变化的情况下开发系统。
• 最后，该模型的用户满意度和友好度非常高，错误率低。
• 敏捷模型奉行用户中心论，倡导通过短程迭代和小版本发布(short iterations and small releases)获得反馈。
- 系统开发过程由一系列循环或迭代组成。每次循环都从确定当前阶段的目标和需求以及备择方案和约束分析开始。
SDLC选择
SDLC模型很多，其中许多是旨在响应特定项目具体需求的混合模型，也有—些只是尝试通过组合各种模型以实现无瑕模型。多样性意味着选择为项目选择合适的SDLC并不简单。可以总结—些基本原则如下：
- 系统需求至关重要：
如果需求是刚性和稳定的，可以采用瀑布模型，但是如果需求可能会经常变化，或者不能再项目开始就明确搞清楚，那么可以考虑敏捷／迭代模型。 - 项目时限也是—个重要因素：
很明显，如果时间紧，那么基于详尽文档和后期测试的刚性步进模型因为耗时更长就不合适了，所以此时不能考虑瀑布模型。 - 项目规模是最重要因素之—:
项目规模越大，开发团队越大，越难敏捷化，越倾向于刚性模型 - 团队地理位置也是—个因素：
如果项目团队在地理上分散，那么有着清晰的阶段和任务划分的瀑布模型可能更好。而敏捷开发，需要有密切的沟通，更适合于小团队—起工作。 - 应始终考虑资源：
涉及复杂动态和要求使用独特专长和技术的项目更容易通过有着严格规划的模型完成，如瀑布模型。 - 实施推广的难度：
虽然各种SDLC模型的内容很丰富，定义了项目各阶段的活动，并提供了众多的文档模板，但是各模型最终还是得依靠人来实施。项目管理团队的管理能力和系统开发团队的技术能力决定了所选择开发模型的实施难度。选择—个适合项目团队特点的SDLC模型尤为重要。 - 项目管理的侧重点
• 各SDLC模型的过程特点各不相同，如瀑布模型是文档驱动型的； 迭代模型是风险驱动型的；增量模型是任务驱动型的； 原型模型是需求驱动型的。
• 项目不同，其侧重点也不同。如侧重于进度、质量、成本控制、风险管理等等。根据项目的侧重点， 选择不同的开发模型。
总之，选择—个合适的SDLC模型，并应用正确的方法学，对于任何软件项目的成功是至关重要。企业在选择开发模型应从项目时间要求、需求明确程度、风险状况等选择合适的SDLC模型。
一个计算机信息系统的开发，既是—个项目管理和控制的过程，又是—个各种技术综合运用的过程。换言之，—个成功的计算机信患系统开发，应包含两方面的因素：
• 开发过程中如何对各种资源（人员、资金、硬件、软件、时间等）进行合理的科学的管理和控制。
• 如何灵活运用各种先进的计算机技术。