第四章 常用系统开发方法Word文档格式.docx
- 文档编号:5253293
- 上传时间:2023-05-04
- 格式:DOCX
- 页数:67
- 大小:137.79KB
第四章 常用系统开发方法Word文档格式.docx
《第四章 常用系统开发方法Word文档格式.docx》由会员分享,可在线阅读,更多相关《第四章 常用系统开发方法Word文档格式.docx(67页珍藏版)》请在冰点文库上搜索。
关于IT项目的管理可以参考有关的文献,本课件不再详细论述。
这里着重介绍如何衡量计算机软件产品质量的方法,即一个称为"
软件能力成熟度"
的模型,它是提高信息系统软件产品质量的一种重要的框架,通过这种模型来加强计算机软件系统的开发过程管理,以提高软件的开发质量,该模型又称能力成熟度模型,英文写成CapabilityMaturityModel,简称CMM。
能力成熟度模型CMM提供了一个系统过程改进框架,该框架与软件生命周期无关,与所采用的开发技术也无关。
根据这个框架制定企业内部具体的系统开发过程,可以极大程度地提高按计划的时间和成本提交有质量保证的系统产品的能力。
CMM认为保证系统质量的根本途径就是提升企业的系统开发生产能力,而企业的系统开发生产能力又取决于企业的系统开发过程能力,特别是在系统开发和生产中的成熟度。
企业的系统开发过程能力越成熟,其系统生产能力就越有保证。
所谓系统开发过程能力,是指企业从事系统产品开发和生产过程本身透明化、规范化、和运行强制化。
企业在执行系统开发过程中可能会反映出原定过程的某些缺陷,这时可以根据反映的问题来改善这个过程。
周而复始,这个过程逐渐完善、成熟。
这样一来,项目的执行不再是一个黑盒,企业可以清楚地知道项目是按照规定的过程进行的。
系统开发及生产过程中成功和失败的经验教训也就能够成为今后可以借鉴和吸取的营养,从而可以大大促进信息系统生产的成熟度的提高。
CMM模型描述和分析了系统开发过程能力的发展程度,确立了一个系统开发过程能力成熟度的分级标准,如图4-1-1所示。
随着能力成熟度逐步提高,企业的竞争力也在不断地提高,系统开发的风险则逐步下降,系统产品的质量稳步上升。
图4-1-1能力成熟程度的分级标准
在CMM中等级的特征为:
∙初始级:
系统开发过程的特点是无序的,有时甚至是混乱的。
系统开发过程定义处于几乎毫无章法和步骤可循的状态,系统产品所取得的成功往往依赖于极个别人的努力和机会。
∙可重复级:
已经建立了基本的项目管理过程,这些过程可以用于对成本、进度和功能特性进行跟踪。
对于类似的工程项目,有章可循并能重复以取得成功的经验。
∙已定义级:
用于管理的和工程的系统开发过程均已文档化、标准化,并形成了整个系统开发组织的标准系统开发过程。
全部项目均采用与实际情况相吻合的、适当修改后的标准系统的开发过程来进行操作。
∙可管理级:
系统开发过程和产品质量有详细的度量标准。
系统开发过程和产品质量得到了定量的认识和控制。
∙优化级:
通过对来自系统开发过程、新概念和新技术等方面的各种有用信息的定量信息,能够不断地、持续性地对系统过程进行改造。
CMM以具体实践为基础,是一个系统开发实践的纲要,以逐步演进的框架形态不断地完善系统开发和维护过程,成为软件企业变革的内在原动力,与静态的质量管理标准-例如ISO9001等,形成了鲜明的对比。
ISO9001标准在提供一个良好的体系结构与实施基础方面能够很有效,而CMM是一个演进的、有动态尺度的标准,可以驱使企业在当前的系统开发实践中不断地改进和完善。
CMM作为一个指南能够帮助企业选择、采纳和合理使用一些先进的管理方法,并在实践活动中不断提高和完善系统开发成熟度的能力。
围绕这些实践活动逐步形成了一套制度,即在指定的成本和时间内,交付提高质量的软件产品所需要的、有纪律的、精确定义的并能有效度量的软件工程过程。
二、系统开发方法概述
管理信息系统的开发是一项复杂的系统工程工作。
它涉及的知识面广、部门多。
至今还没有一种完全有效的方法来很好的完成系统的开发。
但也确有一些方法在系统开发很有帮助,这里就此进行一些介绍。
从20世纪60年代开始,人们已开始注意信息系统开发的方法和工具。
70年代,系统开发的生命周期(LifeCycle)法较好的给出了过程的定义,改善了开发的过程。
然而,问题的累积,性能的缺陷,加深了系统开发的困难,80年代以后,友好的语言和自动化编程工具的出现,使开发方法又有些进步,但维护费用很高。
90年代利用模块化和模块联接技术,大大降低了维护成本,提高了效率。
90年代中期,由于Web技术的出现,许多工作可以由用户去做,但系统工作仍然很多。
下面我们根据时代的特点,介绍系统开发方法的演变。
1.70年代
以前系统开发工作好像在做手工艺品。
编出各种各样的程序,程序难写、难懂,更难以维护。
因而标准化成为用户和开发公司的愿望。
当时的开发环境是:
·
第三代语言(如COBOL)用于编程。
已有数据库管理系统,用于数据管理。
联机处理和批处理混合使用。
主要针对主干机开发。
只由专业程序员进行程序开发。
利用标准符号来说明过程。
用户只在定义需求阶段和安装阶段介入开发。
企图用结构化的程序设计方法和自动化的项目管理。
这时系统开发方法依据著名的“瀑布模型”,见图4-1-2。
图4-1-2瀑布模型
结构化的意思是企图使开发工作标准化。
结构化开发的目标是有序、高效、高可靠性和少错误。
有序是按部就班,相同情况得出相同结构,达到标准化。
结构化还要求建立标准的文档。
当然结构化有其负面的影响,它可能妨碍程序员的创造性。
但对一个大系统来说,只有纪律才能维持高的生产率。
在每个开发阶段,加强检查是提高可靠性、减少错误的主要方法。
在70年代后期,人们开始强调“初期阶段”的重要性。
差错产生得越早,纠正所花的成本越高。
也就是说,纠正差错越早所花成本越低。
为了较早的发现错误,当时方法主要有两种,一种是数据驱动开发,另一种是合作开发,这在当时起到一定作用。
2.
80年代
80年代初一些开发环境逐渐成熟,如第四代语言(4GL)。
这使得有可能使用原型法(prototyping)。
原型法和生命周期法是两种思路完全不同的方法。
生命周期法企图在动手开发前,完全定义好需求,然后经过分析、设计、编程和实施,一次全面的完成目标;
原型法则相反,在未定义好全局前,先实现局部,然后不断修改,最终实现全面满足要求。
两种方法实现的最终系统应当是同功能的,但它们实现的途径却是完全不同的。
一种是单次的,一种是多重循环的。
4GL是一种面向问题的语言。
它不只是一种语言,而且包含一种环境,这种环境包括:
关系数据库系统、数据字典、非过程语言、交互查询机构、报告生成器、排序和选序处理和文本编辑、图形处理、数据分析和模型工具、宏命令库、程序界面、复用程序、软件库、支持和恢复、安全和保密以及与其它数据库的联系等。
进行原型法开发要求4GL有很强的交互能力。
越先进的交互方式,越是prototyping的良好环境。
80年代末期,计算机辅助软件工程(ComputerAidedSoftwareEngineering,CASE)和面向对象(Object-Oriented,OO)的开发方法得到很大的发展,90年代初开始实际应用。
对象是一组数据和一组操作的集合,这组操作可以存取和处理这组数据。
对象还可以组成类(classes〕。
面向对象的方法有以下特点:
它把数据和操作绑扎在一起作为一个对象。
这里数据是主动的,操作跟随数据。
面向对象的方法很容易做到程序重用,重用也较规范;
面向对象技术使新系统开发和维护系统很相似,因为均是重用己有部件。
当用于企业管理时,面向对象的方法模拟企业的运行,这时开发者和企业管理者的沟通用的是企业语言,而不是技术术语。
面向对象的方法特别适用于图形、多媒体和复杂系统。
如上所述,60--70年代是结构化系统分析和设计时代,80年代初是Prototyping时代,80年代末是CASE和OO时代,那么90年代的特点是什么呢?
可能是客户/服务器的时代,或基于WEB的开发时代。
这时客户宁愿买现成的软件包,甚至是整个系统,而不愿自己开发。
用户买来许多软件部件,自己或请顾问公司把它们集成起来。
这就是系统集成或基于部件的开发,在90年代中后期这种趋势越来越明显。
三、系统开发方法的分类
下面我们对系统开发或系统分析与设计方法进行一下分类。
按时间过程来分,开发方法分为生命周期法和原型法,实际上还有许多处于中间状态的方法。
原型法又按照对原型结果的处理方式分为试验原型法和演进原型法。
试验原型法只把原型当成试验工具,试了以后就抛掉,根据试验的结论做出新的系统。
演进原型法则把试好的结果保留,成为最终系统的一部分。
按照系统的分析要素,可以把开发方法分为三类:
①面向处理方法(ProcessingOriented,简称PO)。
②面向数据方法(DataOriented,简称DO)。
③面向对象的方法(ObjectOriented,简称OO)。
PO就是指系统分析的出发点在于搞清系统要进行怎样的处理,分为两种:
一种是面向功能,由企业的职能出发;
一种是面向过程。
由企业运营流程出发,划分成一些过程进行处理分析。
而DO首先分析企业的信息需求,建立企业的信息模型,然后建立全企业共享的数据库。
OO是先分析企业的一些对象,把描述对象的数据和对对象的操作放在一起,如果多个对象共享某些数据和操作,共享的数据和操作就构成了对象类。
现在十分流行的面向过程的系统分析方法,在概念上它是把功能与数据结合,从本质上可以认为是面向对象的方法。
如果把面向对象的方法和面向过程的系统分析结合,将会对系统开发的方法注入新的活力。
1.以过程特点分类
生命周期法
(LifeCycle,LC):
进行系统分析与设计时,将系统开发过程划分为系统请求、规划、分析、设计、实施、运行等几个阶段,每个阶段首尾相连,形成系统的一个生命周期。
演进原型法
(Evolution,EV):
从一个初型系统不断改进,最后成为一个最终的应用系统。
实验原型法
(ExprimentPrototyping,EP):
建立真实系统的模型,由局部模型不断实验改进,最后得到整个系统的模型。
2.以系统的立足点分类
面向功能方法
(FunctionOriented,FO):
首先搞清系统功能,按功能收集系统要求,按功能划分子系统。
面向数据方法
(DataOriented,DO):
首先分析企业的信息需求,然后建立全企业的数据库。
面向对象方法
(ObjectOriented,OO):
首先分析系统的一些对象,把描述对象的数据和对对象的操作放在一起,共享的数据和操作构成对象类。
原型法
(Prototyping):
是借助于新一代自动化的程序生成工具和应用系统,快速模拟出一个原型系统,然后再经过开发者和用户反复评价、修改和逐步完善,最终形成用户满意的应用系统。
3.从方法体系上
自顶向下方法:
首先将整个系统作结构化划分,然后从高层到基层、从整体到局部、从一个组织的功能、机制、任务到内部每个经营管理活动的细节进行系统分析和设计。
需求分析法:
面对一个复杂的组织、信息需求时,把握系统的关健和需求进行分析的方法。
常用的有:
关键成功因子法(CSFs),企业系统规划法(BSP)。
原型法:
(同上)
生命周期法LC:
面向对象OO:
四、常用系统开发方法的分类
1.基于自顶向下、结构化、生命周期思想的开发方法
.结构化分析设计技术
.约当结构化系统开发方法
.中国的映射模型设计法
.詹姆斯.马丁的战略数据规划法
.企业系统规划法
.杰克逊的结构化程序和设计JSP、JSD
2.基于新一代系统开发工具和快速开发方法
.原型法及其分支(瀑布型、快速型)
.计算机辅助软件工程(CASE)
3.面向对象法的系统开发方法
.面向系统设计OO法
.面向数据库OO法
.面向系统程序设计OO法
.面向知识工程师OO法
4.3原型方法(Prototyping)
原型方法是80年代随着计算机软件技术的发展,特别是在关系数据库系统(RDBS,RelationalDataBaseSystem)、第四代程序生成语言(4GL,4thGenerationLanguage)和各种系统开发生成环境产生的基础上,提出的一种从设计思想到工具、手段都是全新的系统开发方法。
一、原型法概述
1.什么是原型方法
传统的结构化开发方法强调系统开发每一阶段的严谨性,要求在系统设计和实施阶段之前预先严格定义出完整准确的功能需求和规格说明。
然而,对于规模较大或结构较复杂的系统,在系统开发前期,用户往往对未来的新系统仅有一个比较模糊的想法。
由于专业知识所限,系统开发人员对某些涉及具体领域的功能需求也不太清楚。
虽然可以通过详细的系统分析和定义得到一份较好的规格说明书,却很难做到将整个管理信息系统描述完整,且与实际环境完全相符,很难通过逻辑推断看出新系统的运行效果。
因此当新系统建成以后,用户对系统的功能或运行效果往往会觉得不满意。
同时随着开发工作的进行,用户会产生新的要求或因环境变化希望系统也能随之作相应更改,系统开发人员也可能因碰到某些意料之外的问题希望在用户需求中有所权衡。
总之,规格说明的难以完善和用户需求的模糊性已成为传统的结构化开发方法的重大障碍。
原型方法(Prototyping)正是对上述问题进行变通的一种新的系统开发方法。
在建筑学和机械设计学中,“原型”指的是其结构、大小和功能都与某个物体相类似的模拟该物体的原始模型。
在管理信息系统开发中,用“原型”来形象地表示系统的一个早期可运行版本,它能反映新系统的部分重要功能和特征。
“原型方法”则是利用原型辅助开发系统的一种新方法。
原型方法要求在获得一组基本的用户需求后,快速地实现新系统的一个“原型”,用户、开发者及其他有关人员在试用原型的过程中,加强通信和反馈,通过反复评价和反复修改原型系统,逐步确定各种需求的细节,适应需求的变化,从而最终提高新系统的质量。
因此可以认为原型方法确定用户需求的策略,它对用户需求的定义采用启发的方式,引导用户在对系统逐渐加深理解的过程中作出响应。
2.原型方法的运用方式
原型方法虽然是在研究用户需求的过程中产生的,但更主要的是针对传统结构化方法所面临的困难,因而也面向系统开发的其它阶段和整个过程。
由于软件项目的特点,运用原型的目的和开发策略的不同,原型方法可表现为不同的运用方式,一般可分为以下三种类型:
(1)探索型(ExploratoryPrototying)主要是针对开发目标模糊、用户和开发人员对项目都缺乏经验的情况,其目的是弄清对目标系统的要求,确定所期望的特性并探讨多种方案的可行性。
(2)实验型(ExperimentalPrototying)用于大规模开发和实现之前考核、验证方案是否合适,规格说明是否可靠。
(3)演化型(EvolutionaryPrototying)其目的不在于改进规格说明和用户需求,而是将系统改造得易于变化,在改进原型的过程中将原型演化成最终系统。
它将原型方法的思想贯穿到系统开发全过程,对满足需求的改动较为适合。
3.原型法基本思想
原型法凭借着系统分析人员对用户要求的理解,在强有力的软件环境支持下,快速地给出一个实实在在的模型(或称原型、雏形),然后与用户反复协商修改,最终形成实际系统。
这个模型大致体现了系统分析人员对用户当前要求的理解和用户想要希望实现后的形式。
二、原型定义策略
1.需求定义的要求
需求定义是管理信息系统开发过程中的关键一环,它对最终系统的成功与否绝对重要。
一般说来,需求定义必须满足以下的要求:
(1)正确性所规定的需求必须是用户所需要的。
(2)完整性需求应是完整、准确的,所有需求必须加以适当说明。
(3)可理解性用户和开发者双方应能以一种共同的方式来解释和理解所规定的需求。
(4)一致性各需求之间不能有逻辑上的矛盾。
(5)非冗余性不应有含混不清的、多余的需求和说明。
(6)可测试性需求应该能够验证,相应的文档应当易读和可修改。
通过以上需求定义的特性可以看出,需求定义工作是一项严肃和艰巨的工作。
在管理信息系统开发的需求定义中,应包括以下基本内容。
2.需求定义的基本内容
(1)系统约束业务环境对最终系统的某些限制,例如计算机资源的限制,企业有关法则、政策的约束等等。
(2)系统输入/输出每个子系统或功能模块中输入/输出数据的特征及定义。
例如数据元素的内容、来源、数量、频数输出的媒介等。
(3)系统数据需求和数据元素系统中数据定义以及数据间的关系,数据元素的属性与特征的定义。
例如格式、名字、类型等。
(4)功能确切指定系统应完成的操作和逻辑转换。
图4-3-1
改动--费用曲线
(5)性能与可靠性明确系统的性能特征和耐故障能力。
如果需求定义工作完成的不好,则在以后的各开发阶段中势必要进行各种纠错、补救工作,这将大大影响系统开发的时间和质量。
另一方面,软件开发的实践表明,在系统开发后期引入一个变动,要比在早期引入相同变动所需付出的代价高2~3个数量级,图4-3-1的改动—费用曲线定性地描绘了在系统开发的不同时期引入一个变动需要付出的代价的变化趋势。
图4-3-2是美国贝尔实验室统计得出的定量结果。
图4-3-2
改正一个问题需要付出的代价
此外,研究还表明,在传统的结构化系统开发中(SDLC),百分之六十到八十的错误来源于需求定义阶段,如图4-3-3所示。
4-3-3
SDLC中系统错误的来源
以上充分说明,系统开发中需求定义是系统成败的关健一步,对确定需求定义的技术和方法必须有足够的重视。
3.结构化的严格定义策略
严格定义(预先定义)是目前采用较多的一种需求定义方法。
在采用严格定义的传统的结构化开发方法中,各个工作阶段排列成一个理想的线性开发序列,在每一工作阶段中,都用上一阶段所提供的完整、严格的文档作为指导文件,因此它本质上是一种顺序型的开发方法,图4-3-4所示。
4-3-4
结构化方法的开发顺序
在传统的结构化开发中,需求的严格定义建立在以下的基本假设上:
(1)所有需求都能够被预先定义
假设意味着,在没有实际系统运行经验的情况下,全部的系统需求均可通过逻辑推断得到。
这对某些规模较小、功能简单的系统是可能的,但对那些功能庞大、复杂的较大的系统则显然是困难的。
即使事先做了深入细致的调查和分析,当用户见到新系统的实际效果时,也往往会改变原先的看法,会提出修改或更进一步增加系统功能的要求,所以再好的预先定义技术也会经常反复。
这是因为人们对新事物的认识与理解将随着直观、实践的过程进一步加深,这是与人类认识世界的客观规律相一致的。
所以,能够预先定义出所有需求的假设在许多场合是不能成立的。
(2)开发人员与用户之间能够准确而清晰地交流
假设认为,用户与开发人员之间,虽然每人都有自己的专业、观点、行话,但在系统开发过程中可以使用图形/文档等通信工具进行交流,进行清晰、有效的沟通,这种沟通是必不可少的。
可是在实际开发中,往往对一些共同的约定每个人都可能会产生自己的理解和解释。
即使采用结构化语言、判定树、判定表等工具,仍然存在精确的、技术上的不严密感。
这将导致人们有意无意地带有个人的不同理解而各行其事,所以在多学科、多行业人员之间进行有效的通信交流是有一定困难的。
(3)采用图形/文字可以充分体现最终系统
在使用严格定义需求的开发过程中,开发人员与用户之间交流、通信的主要工具是定义报告,包括叙述文字、图形、逻辑规则和数据字典等技术工具。
它们的一个共同特点,都是静止的、被动的,不能实际表演,很难在用户头脑中形成一个具体的形象。
因此,要静止的图形/文字描述来体现一个动态的系统是比较困难的。
除了所论述的情况外,上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷。
首先是文档量大,由于在结构化方法的每个阶段都必须写出规范、严密的各种文档,这些文档虽然有助于开发人员之间、用户与开发人员间的通信交流,有助于开发过程的规范化,但由于编写文档花费大量人力和时间,导致系统开发周期增大。
其次是开发过程可见性差,来自用户的反馈太迟。
由于在需求定义、系统设计阶段都不能在用户终端显示新系统的实际效果,一直到系统实现阶段结束,用户才有机会通过对新系统的实际操作和体会,来提出他们对新系统的看法和意见,但此时整个开发已近尾声,若想修改前几段的工作或修改需求定义,都将付出较大的代价,有时这种修改甚至会导致整个系统的失败。
综上所述,需求的严格定义的基本假设在许多情况下并不成立,传统的结构化方法面临着一些难以跨越的障碍。
为此,需要探求一种变通的方法。
4.原型定义的策略
原型方法以一种与严格定义法截然不同的观点看待需求定义问题。
原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。
从一个能满足用户基本需求的原型系统开始,允许用户在开发过程中提出更好的要求,根据用户的要求不断地对系统进行完善,它实质上是一种迭代的循环型的开发方式,如图4-3-5所示。
图4-3-5
原型法的开发过程
采用原型方法时需要注意的几个问题:
(1)并非所有的需求都能在系统开发前被准确地说明。
事实上,要想严密、准确地定义任何事情都是有一定难度的,更不用说是定义一个庞大系统的全部需求。
用户虽然可以叙述他们所需最终系统的目标以及大致功能,但是对某些细节问题却往
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第四章 常用系统开发方法 第四 常用 系统 开发 方法