下载掌阅APP，畅读海量书库
立即打开
20世纪70年代，温斯顿·罗伊斯（Winston Royce）提出了瀑布模型，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。直至今日，该模型仍然具有强大的生命力。瀑布模型（Waterfall Model）又称流水式过程模型，它形象地用阶梯瀑布描述，水由上而下一个阶梯一个阶梯地倾泻下来，最后进入一个风平浪静的大湖，这个大湖就是软件企业的产品库，该产品库建立在软件企业的服务器上，如图1-1所示。
图1-1 广西德天瀑布
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前阶段的活动接受上一阶段活动的工作结果，并完成所需的工作内容。需要对当前阶段活动的工作结果进行验证，如果验证通过，则该结果作为下一阶段活动的输入，继续进行下一阶段的活动，否则返回上一阶段修改。
在瀑布模型中，软件生命周期的过程是由需求、设计、编码、测试、发布等阶段组成的，把每个阶段作为瀑布中的一个台阶，把软件生存过程比喻成瀑布中的流水，软件生存过程在这些台阶中由上向下地流动。瀑布模型规定了各项关键软件工程活动，自上而下、相互衔接、逐级下落，如同瀑布的固定次序，如图1-2所示。当发现某一阶段的上游存在缺陷时，可以通过追溯，予以消除或改进，但要付出很大代价，因为水要在瀑布台阶上倒过来向上流动，需要消耗很多能源或动力。
图1-2 瀑布模型示意图
软件开发过程规划为“需求—设计—编码—测试—发布”的线性过程，其最大特点就是简单直观。里程碑或基线驱动，或者说文档驱动。过程逆转性很差或者说不可逆转，根据上游的错误会在下游发散性传播的原理，逆转将会延误工期，增加成本，造成重大损失。
瀑布模型的缺点是：瀑布只能一个台阶一个台阶地往下流，不可能倒着往上流。瀑布式生命周期通常会导致项目后期，如实施阶段（当第一次构建产品并开始测试时）出现“问题堆积”，在整个分析、设计和实现阶段隐藏下来的问题，会在这时逐步暴露出来。更可怕的是，错误的传递会发散扩大。
为了克服瀑布模型的缺陷，微软公司采取严格的里程碑管理制度。能力成熟度模型集成（Capability Maturity Model Integration，CMMI）则采取阶段评审和不符合项（Noncompliance Items）动态跟踪制度，只有前一阶段的不符合项全部改正后，才允许开发人员进入后一阶段的工作。所谓不符合项，是在评审中发现的问题项，它与Bug既有联系，又有区别。对于这些不符合项，软件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底。
增量模型（Incremental Model）是遵循递增方式来进行软件开发的。软件产品被作为一组增量构件（模块），每次需求分析、设计、实现、集成、测试和交付一起构建，直到所有构件全部实现为止。这一过程就像小孩子搭积木盖房子一样，如图1-3所示。
图1-3 增量模型示意图
增量模型的本意是：要开发一个大的软件系统，应该先开发其中的一个核心模块（或子系统），然后开发其他模块（或子系统），这样一个一个模块（或子系统）增加上去，就像搭积木一样，直至整个系统开发完毕。增量模型的特点为任务或功能模块驱动，可以分阶段提交产品；有多个任务单，这些任务单的集合构成项目的一个总《任务书》或总《用户需求报告》/《需求规格说明书》。当然，在每增加一个模块前，先要对该模块进行模块测试，通过后再将此模块加入系统中，然后进行系统集成测试，系统集成测试成功后，再增加新的模块。这样多次循环，直到系统搭建完毕。由此可见，这样的软件系统本身应该是模块化的，每个模块应该是高内聚（模块内部的数据与信息关系紧密）、低耦合（模块之间的数据与信息联系松散）、信息隐蔽（模块包装后信息很少外露）的，这样的模块当然是可组装、可拆卸的。
不是任何软件都适合采用增量模型，软件项目或产品选择增量模型必须满足下列条件：
（1）在整个项目开发过程中，需求都可能发生变化，客户接受分阶段交付。
（2）分析设计人员对应用领域不熟悉，难以一步到位。
（3）中等或高风险项目。
（4）用户可参与到整个软件开发过程中。
（5）使用面向对象语言或第四代语言。
（6）软件公司自己有较好的类库、构件库。
增量模型的优点：由于将一个大系统分解为多个小系统，就等于将一个大风险分解为多个小风险，因此降低了开发难度；人员分配灵活，刚开始不用投入大量人力资源。如果核心模块产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，即可先发布部分模块给客户，对客户起到镇静剂的作用。
增量模型的缺点：如果软件系统的组装和拆卸性不强，或开发人员全局把握水平不高（没有数据库设计专家进行系统集成），或者客户不同意分阶段提交产品，或者开发人员过剩，都不宜采用这种模型。
当高级别需求只对软件产品的期望有一个总体的看法，而缺乏关于系统输入、处理需求和输出要求的详细信息时，可以采用原型模型来开发软件。原型模型反映了通过客户与产品的原型不断地进行交互和试验来增加开发过程灵活性的尝试，如图1-4所示。一旦客户对原型的功能感到满意，开发过程就会继续，开发人员确定客户实际需求规格说明。在此过程中根据项目的工作量估算系统组件的复杂程度，确定客户的需求并确定客户是否对原型的功能感到满意是必不可少的。如果原型的第一个版本不能满足客户的需求，那么必须迅速转换成第二个版本。原型模型可以大大降低风险。
图1-4 原型模型示意图
针对瀑布模型的缺陷，人们提出了迭代模型（Iterative Model）。在多种迭代模型中，美国的I.Jacobson、G.Booch和J.Rumbaugh三位软件专家提出的RUP （Rational Unified Process）模型最成功。RUP试图集中所有的生命周期开发模型的优点，用统一的建模语言UML加以实现。RUP模型示意图如图1-5所示。
图1-5 RUP模型示意图
迭代是指活动的多次重复。原型不断完善，增量不断产生，都是迭代的过程。因此，原型模型和增量模型都可以看成局部迭代模型。但这里所讲的迭代模型是由RUP推出的一种“逐步求精”的面向对象的软件开发过程模型，被认为是软件界迄今为止最完善、可实现商品化的开发过程模型。为使项目能够顺利地进行，一种较灵活且风险更小的方法是：多次执行各个开发工作流程，从而更好地理解需求，设计出更为强壮的软件构架，逐步提高开发组织能力，最终交付一系列逐步完善的实施成果，这就是迭代生命周期模型。
迭代生命周期模型的特点：迭代或迭代循环驱动，每一次迭代或迭代循环，均要走完初始（先启）、精化、构建、产品化（移交）这四个阶段。RUP 的主要特征是采用迭代的、增量式的开发过程；采用统一建模语言（UML）描述软件开发过程；有功能强大的软件工具（如IBM Rational Rose）支撑。
根据软件开发的实际情况，建议具有以下特征的项目，可以考虑使用迭代生命周期模型。
（1）迭代生命周期模型是以迭代为主要特征的。项目组的管理人员和核心成员，应对迭代的开发方式比较熟悉，并具有丰富的软件工程知识和实施经验。
（2）项目组的管理人员和核心成员应对软件工程的核心过程——业务建模、需求获取、分析设计、实施、测试、部署、配置与变更管理、项目管理和环境等比较熟悉。
（3）面向对象技术比较适合采用迭代方式进行，采用面向对象技术（如OOA、OOD等）的项目组，建议使用迭代生命周期模型。
（4）该模型是以软件构架为中心的开发方式，项目组的核心设计人员应具备一定程度的软件架构知识，并熟练掌握软件架构设计技能。
（5）项目组全体成员应熟悉UML，并能利用建模工具（如IBM Rational Rose等）进行分析、策划、设计、测试等。
（6）该模型是以风险管理为驱动的开发方式，项目组的管理人员应具备风险管理的知识和技能。
（7）拥有实施软件产品开发、组装的软件组织。
迭代生命周期模型要求的条件是最苛刻的，初学者不宜随便使用。
迭代生命周期模型分为以下四个阶段：
（1）初始阶段：本阶段的主要工作是确定系统的业务用例（Use Case）和定义项目的范围。为此，需要标识系统要交互的外部实体，定义高层次的交互规律，定义所有的用例并对个别重要的用例进行描述和实现。业务用例包括成功的评估、风险确认、资源需求和以阶段里程碑表示的阶段计划。
（2）精化阶段：本阶段的主要工作是分析问题域，细化产品定义，定义系统的构架并建立基线，为构建阶段的设计和实施提供一个稳定的基础。
（3）构建阶段：本阶段的主要工作是反复地开发，以完善产品，达到用户的要求，包括用例的描述、完成设计、完成实现和对软件进行测试等工作。
（4）产品化（移交）阶段：本阶段的主要工作是将产品交付给用户，包括安装、培训、交付、维护等工作。
迭代生命周期模型的9个核心内容：
（1）业务建模：了解目标组织（将要在其中部署系统的组织）的结构及机制；了解目标组织中当前存在的问题，并确定改进的可能性；确保客户、最终用户和开发人员就目标组织达成共识；导出支持目标组织所需的系统需求。通俗地讲，业务建模就是用户业务流程的重新规划与合理改进，即业务流程的优化，目的是使开发出来的系统能反映最优化的业务流程。
（2）需求获取：与客户在系统的工作内容上保持一致；使系统开发人员能够更清楚地了解系统需求；定义系统边界；为计划迭代的内容提供基础；为估算开发系统所需成本和时间提供基础；定义系统的用户界面，重点是用户的需要和目标。
（3）分析设计：将需求转换为未来系统的设计；逐步开发强壮的系统构架；使设计适合实施环境，为提高性能而进行设计。
（4）实施：对照实施子系统的分层结构定义代码结构；以构件（源文件、二进制文件、可执行文件以及其他文件等）方式实施类和对象；对已开发的构件按单元进行测试；将各实施成员（或团队）完成的结果集成到可执行系统中。
（5）测试：核实对象之间的交互；核实软件的所有构件是否正确集成；核实所有需求是否已经正确实施；确定缺陷并确保在部署软件之前将缺陷解决。
（6）部署：将构件部署到网络的各个节点上，使最终用户可以使用该软件产品。
（7）配置与变更管理：始终保持工作产品的完整性和一致性。
（8）项目管理：为软件密集型项目的管理提供框架；为项目计划、人员配备、执行和监测提供实用准则；为风险管理提供框架。
（9）环境：为软件开发组织提供软件开发环境（流程和工具），该环境将支持开发团队。
迭代模型的优点：在开发的早期或中期，用户需求可以变化；在迭代之初，不要求有一个相近的产品原型；模型的适用范围很广，几乎适用于所有项目的开发。
迭代模型的缺点：传统的组织方法是按顺序（一次且仅一次）完成每个工作流程，即瀑布式生命周期。迭代模型采取循环工作方式，每次循环均使工作产品更靠近目标产品，这要求项目组成员具有很高的开发水平并掌握先进的开发工具。反之，存在较大的技术和技能风险。
以极限编程（XP）运动先驱者出现的Kent Beck和Ron Jeffries等人，他们将CMM/CMMI为代表（还有ISO9001等）的过程管理思想，称为重载软件过程，而将他们自己提出的过程管理思想，称为轻载软件过程，即敏捷过程。敏捷过程表明了完全不同的立场，宣称好的开发过程应该可以在保证质量的前提下，做到文档适度、度量适度和管理适度，并且根据变化能迅速作出自我调整。他们认为：
● 个人和交互胜于过程和工具。
● 可用的软件胜于详尽的文档。
● 与客户协作胜于合同谈判。
● 响应变化胜于遵循计划。
敏捷开发的基本要点是采用递增式（或称之为迭代式、螺旋式等）的开发方式，概括为12条软件开发原则，这是敏捷方法或敏捷建模必须遵循的原则，现简述如下。
（1）将尽早地和不断地向客户提交有价值的和满意的软件，作为最优先的目标。
（2）自始至终地欢迎客户提供需求和需求变化，利用这种变化为客户产生竞争优势。
（3）经常交付（从几周到几个月）可用的软件，尽可能缩短时间间隔。
（4）在项目开发过程中，业务人员和开发人员必须每天一起工作。
（5）围绕优秀人员建立项目，给予所需的环境和支持，相信他们能完成任务。
（6）面对面的交流，是项目团队传递信息最好的方式。
（7）工作软件（软件工作产品）所处的状态，是首要的软件度量。
（8）鼓励并支持软件开发的持续性，这样可加快产品化进程，在业务领域处于领先地位。
（9）采用先进技术和优秀设计，以增强敏捷性。
（10）简单，少而精，只做必须做的，这是一门艺术。
（11）要相信：最好的架构、需求和设计，出自自己的团队。
（12）每隔一段时间，团队要反思自己的过去，调整自己今后的行为。
目前，行业常用的敏捷方法有Scrum方法（见图1-6）、动态系统开发方法（DSDM）、水晶方法、功能驱动开发（FDD）、精益开发（LD）、极限编程（XP）、自适应软件开发（ASD）等。
图1-6 Scrum方法示意图
敏捷团队要求人员自驱动、自管理，没有传统意义上的上下级关系。Scrum方法中的Scrum Master角色可以理解为敏捷专家或教练，不等同于传统模型中的团队负责人角色。敏捷团队人员可以参加Scrum Master培训并考取相关国际认证。Scrum Master国际认证如图1-7所示。
图1-7 Scrum Master国际认证
敏捷方法特别适合于中小型软件企业，以及大型企业的中小型软件项目。它与CMMI（重载过程）可以平等互利、取长补短、和平共处。敏捷方法对个人的素质要求很高，CMMI对整体的素质要求很高。它们是两种不同的管理模式，目的为了实现同一个目标。在敏捷方法推广过程中，切记不能为了敏捷而敏捷。团队要根据组织、项目、人员等特点选择最适合的软件开发模型或进行多个开发模型的结合及裁剪。
可持续的研发优势的源泉是卓越的研发流程。以某项卓越设计、天赐良机、竞争对手的某次失误为基础的优势是不可能长久的。而卓越的研发流程则始终能够发现机遇，推出有竞争力的产品和服务，并以最快的速度把这些研发成果投入市场。
流程是指解决问题的一系列步骤。流程可以通过遵循他人做事一贯的方法来降低风险。研发流程需要不断地持续改进以保持其规范性和先进性。
摩托罗拉公司的 M-Gates 产品研发流程是基于新产品开发的门径管理系统（Stage-Gate System，SGS）。SGS是由罗勃特.G.库珀（Robert G.Cooper）于20世纪80年代创立的一种新产品开发流程管理技术。这一技术被视为新产品开发过程中的一项基础程序和产品创新的过程管理工具。
SGS 流程将整个产品开发过程划分成一系列预设的阶段（Stage），每个阶段的入口检查点称为Stage-Gate，顾名思义为门径管理。一个典型的SGS流程如图1-8所示，包含5个阶段：确定范围、项目立项、开发、测试和检验、投放市场。
图1-8 SGS流程
SGS流程的每个阶段都需要收集阶段入口检查点的信息。作为质量控制检测和决策点，阶段的入口检查点决定了整个流程能否向下一个阶段推进。阶段入口检查点通常包括：一套预定的输出或交付物；判断标准和准则；预定的结果或产出。
SGS将研发活动纳入企业的经营活动，使管理者从较完整的角度来看待研发管理。其优点是理论简单直接，流程易懂易学易用，在实际工作中便于经验的积累，容易学习、推广和实施。
1996—1998年，摩托罗拉公司的市场份额和盈利能力落后于竞争对手。其中，市场份额下降9%；盈利能力下降18%。公司分析发现，根本原因在于缺乏良好的流程，导致业绩下滑。
1998 年，摩托罗拉公司进行核心流程重新设计，将 SGS 理论和自己的实践经验相结合提出M-Gates产品研发流程，作为摩托罗拉公司产品研发管理的基础。M-Gates 流程的设计目标是显著改进产品的上市速度，并提高对产品成功的预测能力，提高公司效率。
M-Gates是由16个摩托罗拉标准的里程碑组成的，这些里程碑加快了产品推向市场的速度，提高了业务的可预见性。这16个M-Gates代表全面的跨职能的研发生产活动，保障了业务计划的执行。
M-Gates 被设计为跨职能的、包含许多现有的路线方案的优秀元素，而且可以广泛应用于所有的职能部门。M-Gates包含5个部分：业务开发、业务计划、项目定义、实施、投放市场。流程管理M-Gates如表1-1所示。
表1-1 流程管理M-Gates
针对不同项目的自身特点，M-Gates可以根据项目实际情况作出精简和改进。摩托罗拉M-Gates实例如表1-2所示。
表1-2 摩托罗拉M-Gates实例
有了更好的产品研发流程，摩托罗拉公司大部分产品投放市场的时间就可缩短一半，可在较短的研发周期内开发出更适合市场需求的产品。例如，摩托罗拉公司在两年内把对讲机产品研发时间缩短了46%。正是摩托罗拉公司研发流程管理的持续性、预见性、规范性、程序性及其纠错能力，使其研发处于领先地位。
本节的工程实践案例将围绕一次面向电力行业应用领域的软件开发项目展开。重点谈谈项目初期的可行性与计划研究工作，具体包括项目背景介绍、现状分析、项目目标的导出、软件来源、实施基础、实施方案和改进型项目的开发模型选择。
在项目初期，要确定该软件的开发目标和总的要求，要进行可行性分析、投资-收益分析、制订开发计划，并完成可行性分析报告、开发计划等文档。可行性分析报告是项目初期策划的结果，可以作为项目决策的依据。
1.项目背景介绍
电力行业是国民经济的基础性、支柱性、战略性产业。电力系统是由发电、变电、输电、配电和用电等环节组成的电能生产与消费系统。从承担的具体职能来看，电力网络可进一步细分为输电网和配电网。《配电网建设改造行动计划（2015—2020年）》指出，配电网承担着直接向用户供电的重任，在整个电力系统中占有至关重要的地位。配电网直接面向终端用户，与广大人民群众的生产生活息息相关，是服务民生的重要公共基础设施。
配电管理系统（DMS）由配电自动化系统（DAS）、配电网监控与数据采集（Supervisory Control and Data Acquisition，SCADA）系统、配电地理信息系统（GIS）和需求侧管理（DSM）等共同构成。SCADA 在电力系统上的应用较早，是以计算机为基础的生产过程控制与调度自动化系统，可以对现场的运行设备进行监视和控制。GIS 是一种特定的空间信息系统，是在计算机硬、软件系统支持下，对整个或部分地球表层空间中的有关地理分布数据进行采集、存储、管理、运算、分析、显示和描述的技术系统。
高效的监视和控制工作离不开智能且可视化的图形窗口，各类配电网接线图正是工程调度员监控实时运行信息的图形资料。简而言之，如果把发电厂比作电力系统的心脏，输电网比作主动脉，那么配电网就是遍布全身、直接向身体各个器官供血的“毛细血管”，配电网接线图就是工程人员的“眼睛”。透过这双清晰、智能的“眼睛”，配电网供、断电及实时数据等信息将一目了然地呈现于工程实施人员的眼前。
基于以上背景，数据正确、布局科学且智能化的配电网接线图系统的设计和开发，可以大幅提升监控调度人员的工作效率，有效降低工程实施成本，具有非常重要的工程应用价值。配电网接线图自动生成功能的开发实践，是一项面向电力行业领域的工程实践应用项目。本书后面的章节将此项目简称为自动成图系统。
2.现状分析
配电网接线图是SCADA系统实时监控的重要图形依据，它可视化地反映了供电情况，是供电运行、故障排除的重要依据。排布清晰、布局科学的接线图为实现智能配电网调度提供了可能性。
现有配电网接线图的工程应用流程存在可视化效果不佳、自动生成效率低和智能化水平不高等问题。整个流程如下：工程调度员选择需要实时监控的线路；系统依据电气数据和地理数据经过搜索和排布计算，生成对应线路的接线图；工程调度员依据实际地理位置对接线图的布局效果进行调整，校验线路数据的正确性。这样，一幅能基本满足监控要求的接线图就生成了。这样的“自动成图”过程大大增加了系统操作员的工作量，远远不能满足工程监控的实时性要求。
3.项目目标的导出
配电网接线图的自动成图需求，通常来自两类用户的反馈：一类是城网和农网工程现场的调度人员的实施意见，另一类是供电局用户的系统操作体验。项目问题鱼骨图如图1-9所示。目前，自动成图功能的用户问题反馈集中于接线图的排布效果、线路兼容性及实时监控的易用性三个方面。
图1-9 项目问题鱼骨图
4.软件来源
企业或政府组织获取软件的途径有多种，组织可以通过信息技术服务公司、套装软件提供商、企业解决方案软件提供商、云计算和开源软件提供者获得软件，也可以通过内部系统开发资源获得（包括复用现有的软件构建）。自动成图系统作为 SCADA 系统的智能可视化开发项目，其基础数据来源于服务民生的 SCADA系统和 GIS，具有极高的信息和网络安全级别。因此，自动成图系统只能由组织内部开发人员基于已有系统构件和现有自动成图功能进行优化以满足新的业务需求。
5.实施基础
自动成图系统以SCADA系统和GIS为基础。系统架构图如图1-10所示，工程调度员通过某城市配电网监控平台查看某条线路的实时运行情况，该配电网接线图由该城市Web服务器发布。配电网接线图的地理位置和电气数据的计算，分别由GIS和SCADA系统完成。国网GIS服务器统一管理各个城网和农网的地理信息工作站，对发送监控请求的线路计算地理信息。SCADA 系统负责提供该线路的实时运行数据。因此，SCADA系统是配电网接线图的实时电气数据源，GIS是地理信息数据源。
图1-10 系统架构图
6.实施方案
关联图、生态系统图、特性树和事件列表是常见的开发范围可视化表示工具。识别出受影响的业务过程可以帮助定义范围边界，可以通过用例图描述用例和角色之间的边界范围。
实时电气数据源和地理信息数据源为自动成图系统提供了数据可行性。自动成图系统对现有电力系统有较强的依赖。项目总体实施策略是保持图1-10所示的系统架构设计不变，重点对自动成图系统的实现流程和算法理论进行改进，以达到开发目标。具体实施上，对现状进行调研，总结原有方案的优缺点、局限性及存在的问题；召开研讨会，基于项目的实际环境和条件制定方案。实施方案导出过程图如图1-11所示。
图1-11 实施方案导出过程图
7.改进型项目的开发模型选择
软件项目类型是多样的，如开发任何类型产品的敏捷项目、改进型项目、替换型项目、引入软件包方案的项目、外包项目、业务过程自动化项目、业务分析项目以及嵌入式和其他实时系统等。在此，自动成图系统属于需要对现有系统改进功能以满足修订后的业务规则与业务需求的改进型项目。
软件开发模型为软件工程提供了特定的路线图，该路线图规定了所有活动的流程、动作、任务、迭代的程度、工作产品及工作的组织方式。常见的软件开发模型和方法包括本章介绍的瀑布模型、增量模型、原型模型、迭代模型及敏捷方法等。
结合项目背景、软件开发组织管理机制和市场战略目标等影响因素，为项目选择合适的软件开发模型可以保证软件开发的秩序，力求做到活动和任务都是按照过程的特定指引顺序进行的。面向应用领域的工程实践项目往往混用两种甚至多种软件开发模型，或者在项目不同阶段采用不种类型的开发模型。
自动成图系统总体来说是一种系统处理过程简单、涉及面窄的小型系统。它基于已有系统构件和现有自动成图功能，有一定的原型基础，但用户对成图效果的要求仍然是不明确的，需要系统开发人员和用户对成图效果的共同摸索。在此背景下，选择快速原型模型作为开发模型，把系统主要功能和接口通过快速开发制作出软件样品，以可视化的形式展现给用户，及时征求用户意见，从而最大限度地接近用户需求。原型展示给用户时，用户部分接受，则继续修改不接受部分，直到用户满意。系统的形成和发展是逐步完成的，是一个动态迭代和循环的过程，每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价，所以是应对变化最有效的方法。综上所述，自动成图系统采用演化式的快速原型模型是有益的。
自动成图系统的总体业务目标包括排布效果、多种线路类型的兼容性及实时监控的易用性三个方面。产品统一进行项目总体规划、业务需求分析、原型系统分析；三个业务目标分三个阶段分别规划、设计和开发完成，三个阶段产品逐一加入集成测试；然后对完整产品进行确认测试，最后提交产品。改进型项目的开发模型如图1-12所示。
生命周期中各个阶段的定义如表1-3所示。
图1-12 改进型项目的开发模型
表1-3 生命周期中各个阶段的定义
续表
改进型项目面临一些特殊的需求问题和挑战，例如，现有系统缺少或没有可用的需求文档，熟悉当前系统的一些用户可能不喜欢新的变化，改变可能会引起性能降低，改进功能时有可能添加了看似有利于达成目标而实际并不必要的功能，等等。第2章将介绍需求开发和管理的一些实践经验。