系统开发的方法篇1
[关键词]DmBia信息构建信息系统开发信息构建师
一、引言
信息构建（informationarchitecture简称ia），是美国建筑师沃尔曼（RichardSaulwurman）在1975年首次提出的。在将信息的收集、组织和表示与建造建筑物的相应过程进行比较之后，其认为在满足使用者需求这一点上，构筑信息建筑物与构筑物理建筑物有异曲同工之处，都可以看成是一种服务于特定目标的建筑设计工作，由此创造性的提出了ia这样一个概念，并在此基础上将其应用到各个领域中。
信息构建在国外的研究已30多年，近十年的发展最为突出，从2000年开始，美国情报科学技术学会（aSiSt）已经连续六年举办了以ia为主题的峰会，而在中国，则开始于2001年在湖北襄樊召开的新世纪情报学学科建设、发展与应用研讨会。而其在中国的真正研究与推广则可以视2001年在湖北襄樊召开的新世纪情报学学科建设、发展与应用研讨会为起点。ia发展的主要推动力是信息载体及其所依托环境的不断变化，特别是因特网的迅速普及和推广，使得企业面临很大的信息爆炸，信息生态环境日渐复杂、冗余，如何从复杂繁多的信息中把握提取对企业有用的信息成为企业成功的关键因素之一。而ia理论在某种程度上能够解决或者说是缓解这一问题，它的出发点在于关注用户的感受，体现以人为本的宗旨，努力改善信息浏览、信息检索和数据交换等各方面的信息处理和展示，以用户可理解为最终目标，构建信息。
信息构建的发展近年来越发迅速，在某些领域中也有重大突破，但归纳而言其主要的应用领域较多体现在网站设计、网络信息管理等方面，在其他领域的涉及相对而言比较的少。而本文借此欲创造性地尝试把信息构建的理论应用到信息系统开发中去，分析传统信息系统开发的不足，换角度思考信息系统开发，并提出相对更为有效合理的基于ia的信息系统开发方法。并希望为以后信息构建理论在其他领域的应用作铺垫。
二、信息构建与信息系统开发
信息系统开发方法通过近几十年的发展已经到达一个成熟阶段，形成了几种比较成熟也较为常用的方法，本文称之为传统开发方法，如生命周期法、原型法以及面向对象法。随着新技术的不断出现，新的开发方法也不断涌现，大多是基于某种软件技术的，如基于UmL技术、基于web、基于internet交互技术的等。信息系统的开发作为一项耗资大、开发周期长、技术复杂、涉及面广的系统工程，如果没有相应的开发方式来实现，就无法达到预先设定的目标。但在综合这一系列信息系统开发方法之后，发现目前仍存在一系列的问题，例如miS的重复建设，企业的各个部门往往会出现多个职能域的miS，而各个miS之间又普遍存在“孤岛效应”，重复建设很难避免;miS建设缺乏全局性、战略层面的意识，造成物流、资金流、事务流、信息流在部门内、各部门间以及本单位与外部单位之间流通的不顺畅；信息可理解不突出，这也是目前就突出的问题所在，即使是系统最终能够发挥出其有效性以及可用性，而在其实施阶段，使用者不得不花费较长的时间去学习以及适应这一系统，通常情况下很难完全掌握系统的操作，也就无法发挥其最大的效用，eRp在我国发展的“早死”现象就是最好的例证。
而信息构建理论关注的焦点正是如何解决这类问题，突出核心思想为“以用户为中心，使用户可理解”，国外一些学者已经在很多领域作了尝试，并取得一定成果，如elaineG.toms的信息交互模型、Sarahbidigare的Shoppingcart模型、LouisRosenfeld的企业信息构建模型(eaiRoadmap)等。也是基于这样的思想，本文将信息构建的方法论和思维应用到信息系统开发中去，在弥补传统开发方式不足的同时，也希望使最终开发的信息系统具有可行性、可操作性，并保证系统的易用性和有用性。
三、基于ia的信息系统开发模型
在充分理解信息构建理论以及信息系统开发的概念、内涵、方法、现有模型或方法的基础，建立基于信息构建的信息系统开发模型（theDevelopmentmodelBasedoninformationarchitecture，简称DmBia），根据图1可以了解其具体包括六个流程:信息概念设计信息内容组织信息结构设计信息界面设计信息系统实现信息系统评估。
1.DmBia的基本流程
（1)信息概念设计
该阶段主要是以理解信息系统开发用户为宗旨，了解企业现状，确定用户需求，包括信息系统需求企业用户的整体环境，企业优弱势，系统目标以及系统可行性等等。现状了解主要采用市场调查，同时与其他方式相结合的方法。整个市场调查分析的核心在于信息系统开发人员或者说是信息构建师怎样去理解用户信息。以网站信息系统为例，包括理解网站系统建立的短期和长期目标是什么？谁是潜在的观众？人们为何使用你的网站？如何按照重要性程度为每个目标排序？用户在网站上的行为特征？竞争对手的现状？网站的特性和标准，比如下载时间、网页大小、版面、外观和感觉等等？在确定所有以上问题的答案后，再次征求意见，最终得到客户认可的网站目标。
（2)信息内容组织
该阶段的主要工作是根据掌握的信息，通过合理的方法，组织信息内容，形成定义信息结构的文档。作为模型的核心内容之一，信息内容组织的合理性直接影响后期流程的成效。其目的在于能够合理地对现有的用户信息进行归类、区分，尽可能实现所有系统使用者的需求，以便后续的结构设计、定向检索等。信息组织一直是传统图书馆学的研究对象，其方式有很多种，常见的是分类方式以及主体方式。目前，国内外信息构建师较为关注的是沃尔曼先生提出了“LatCH组织模式”、LouisRosenfeld和petermorville提出的精确组织方法[8]和模糊组织方法以及孟广均先生提出的信息组织体系。
（3)信息结构设计
该阶段的主要工作是搭建用户的整体信息结构。用户可以利用自己的想象力和经验，去了解信息，理解信息。但当一个信息系统没有提供背景知识时，就必须要有一个逻辑清晰的结构，来形成背景知识以便让观众循着这个结构联想或学习，了解信息的内容，进而找到所需信息的所在地。因此关键点集中在寻找一种结构，一个能最简便表达主题的、正确的、特有的组织格式，能够使读者忽略无关信息，最快发现感兴趣的东西；一个能够容纳信息，以及决定所要显示内容的结构。在信息结构设计时，同样必须完全把握贯穿模型始终的核心思想即需理解用户信息，掌握用户需求。为保证最终的设计结构满足系统目的，信息构建师应从不同的环境中选择需要的信息，并将这些零碎的内容片段的各种元素设计成为一个结构完美、和谐、统一、有机的整体。
（4)信息界面设计
信息界面设计也可以认为是外观设计、视觉设计，以用户理解为主。信息界面设计的效果体现在能够使那些对信息系统不熟悉的用户通过一定的简单了解或操作就能够直接使用信息系统，并获得所需的信息。信息构建与界面设计之间有非常紧密的关系，在设计潜在系统结构的早期阶段，就需要界面设计人员的参与，因为潜在的信息构架必定会影响其在用户界面水平上所做的工作。界面是一个桥梁，许多的对话和交互都是从它开始的，它也是商业目标和用户体验的交叉点。好的界面设计能从表达潜在目的的背景中生成一个有效的、引人注意的视觉体验。信息界面设计主要内容体现两个方面。一个是界面的美观性，用户的可接受性，另一个则是要体现足够的系统导航性。
（5)信息系统实现
该阶段将软环境的设计向硬环境的设计转变，整个信息系统实现流程按照笔者模型的设计，主要内容包括系统软件选择，硬件购置，网络布局，系统调试等几个方面。这里主要涉及的是各种计算机网络技术，因此信息构建师需要具备相关的专业知识，也和与其他相关人员配合进行。该阶段很好地体现了信息构建是基于各个学科知识理论之上这一特点。
（6)信息系统评估
该阶段是对系统实现效果的评估，主要是指与用户需要的符合性以及与预先目标的一致性。评估的方面主要包括信息内容组织、信息结构设计和信息界面设计的合理性，以及信息系统的硬件和软件的可靠性。在这里根据信息构建的原理，提出基于用户的信息构建评估，即系统必须体现可用性、信息使用户可理解。以网站设计为例，其主要涉及到内容组织评估，包括内容与用户需求的一致性、内容登机划分是否标准等;信息结构评估，是指内容的组合连接，也就是信息片断是否符合用户所需;信息导航评估，是指导航要数是否清晰，冗余是否多，标识是否明显;信息检索评估，是指检索反映速度是否较快，检索结果是否达到用户满意，检索结果信息展示是否用户可理解等；界面美观评估，是指其信息网站界面基调是否一致、是否体现企业文化内涵等。
2.DmBia的基本原理
在模型具体应用中，各个阶段的最终目的都在于最终系统的用户可理解，保证在企业对信息需求和利用日益扩大的今天，通过信息构建，可以更好的了解信息，掌握信息，利用信息，创造价值。因而各个阶段始终体现以信息可理解为目的。信息的变化按照周晓英博士的理论，一般可以划分为信息片断、信息集合、信息结构、信息空间四个信息状态，见图2。
模型的构造遵循信息构建的原理，在综合国内外学者对信息构建理解和使用方法的基础上，并考虑信息系统开发的适应性，模型开发原理主要按照信息状态变化过程的四个方面展开，即:
信息片断的集成原理，是指信息构建过程是从信息片段的采集开始，对采集的信息，通过一定的集成准则，集合所采集的信息，简单而言，把采集到的用户未知的信息转换为用户可知的信息，主要涉及到三大方面，集成各种信息资源、综合合理应用不同的媒介和工具、信息最佳有效集成。
信息集合有序原理，是指信息构建过程中对信息集合中信息内容的组织和信息形式的表达形成有序、逻辑、主题鲜明的信息结构体系。
信息结构展示原理，是指信息构建师为序化后的信息设计一个协调一致的、功能化的信息构架,简单的说就是设计一个信息展示界面，一方面有效地展示信息系统构建用户所需表达的信息，另一方面使信息系统使用户能感知信息结构中所存在的信息，可以方便地、心情愉悦地从中获得信息，满足自己的信息需求和实现自己的目标。
信息空间优化原理，是指信息构建过程通过一系列手段和措施，在复杂的庞大的信息空间中帮助人们缓解信息环境造成的心理上的迷惑或行动上的困境，减轻人们认知负担，加强人们信息感知和信息捕捉能力，促进信息接受和利用。
3.DmBia的基本原则
在模型的实际应用中，信息构建师除了必须在理解信息构建基本原理的基础上，同时必循遵循信息构建的一些基本原则。在信息构建其他学者所制定的原则之上，结合信息系统开发领域的自身规律，得出以下几点模型应用的原则:
以用户为中心原则，是指信息构建时要以用户为中心，从用户的理解、用户的兴趣、用户的习惯、用户的期望、用户的评价方面开始设计和运作。
整体性最优原则，是指必须从整体和各组成部分的相互关系来考察事物，从整体目标和功能出发，正确处理系统各组成部分之间的相互关系和相互作用。就是把复杂问题化成若干相对简单的子问题以方便求解。
突出设计原则，是指重视对信息结构、信息界面或信息内容的外观和展示形式进行设计。
美观与功能平衡原则，是指信息构建时要考虑构建结果应当具有的目的和效用，为目的服务而不是为外在的东西服务。
系统开发的方法篇2
关键词：变速器耐久；实车采集；档位载荷分解；半轴扭矩
引言
变速器是全车动力传递，连接发动机及底盘的重要系统，它的耐久性表现对于整车耐久性表现起了关键性作用[1]。在某车型开发中，选取了某一款已经量产的变速器系统，由于整车重量、发动机输出功率和扭矩的变化，变速箱系统搭载在新车型上是否会出现耐久失效，同时，该车型分别在国内和国际市场投放，同一款变速器的耐久性能是否能够满足不同市场耐久需求，成为车型开发中不确定性问题。
1.变速器系统载荷采集及数据预处理
变速器内部结构复杂，空间狭小不易布置传感器。一般都选择与其连接的传动系统上布置传感器，例如半轴扭矩传感器、车轮六分力传感器。相比车轮六分力传感器，半轴扭矩传感器结构简单，购买和改制成本都相对低廉，且采集数据上无差异。在测试车辆半轴上粘贴应变片，组成桥路连接，将桥路与外购的滑环连接就形成一个半轴扭矩传感器。通过在扭转工作缸上标定，得到应变与扭矩之间的关系见，建立趋势线得到应变和扭矩间的线性关系为：扭矩=0.501×应变+11.05。
考虑到后期分析需要，实车采集数据包含半轴扭矩数据、车速数据、发动机转速数据等。对采集数据信号进行消除奇异点处理，并将车速信号转化为半轴转速信号，利用应变与扭矩之间的趋势线将采集到的应变信号转化为半轴扭矩信号。
2.各档位载荷分解和结果分析
现代汽车手动变速器由5-6个档位组成，每个档位都有不同的速比，所以每个档位的载荷不相同，对应每个档位的寿命要求也不相同，一档是车辆行驶中关键档位，使用最为频繁，使用时变速箱系统乃至与其相关的发动机系统、传动系统都受到很大载荷，具有较高的研究代表性，故本文的研究对象选取一档，其他档位的方法与其相似。
2.1半轴扭矩与半轴转数关系的建立
扭矩-转速分布图是针对轴等旋转零部件的一种区间计数方法，广泛应用于齿轮系的设计和分析[2]。已知转速时间历程（rpm）的不连续的时间间隔（?ti，i=1，m），计算转轴在给定扭矩（ti）下的转数（ni）。转轴在扭矩ti下可以表示为：
ni=（1）
利用式（1）分析试验场实车采集数据可以得到，国内市场版变速箱一档行驶时半轴采集到的扭矩分布和半轴转速情况，见表1。表中的正（+）扭矩和负扭矩（-）分别表示采集车辆受发动机输出扭矩行驶和惯性滑行状态下行驶。
2.2变速器寿命分析
变速器行业标准规定寿命台架输入转速为发动机最大扭矩点转速，输入扭矩为发动机最大，要求一档在此条件下输入轴完成10.8×105转的运转，档位不出现失效[3]。而整车采集的结果为多个区间，这就需要利用抗扭转寿命曲线（t-n曲线）进行转化。
利用大量试验可以得到抗扭转寿命曲线，这条曲线可以表示为：
ti=t’f（ni）b（2）
式中：ti为扭矩；t’f为疲劳强度系数；b为疲劳强度指数，不同的零部件，不同的损伤模式，疲劳强度指数也不同，这里以变速器中最容易损坏的轴承为例b=-。
由于实车采集的数据是位于变速器输出端，行业标准中规定的是输入端，这
就需要在分析前期进行统一，变速箱输入轴的扭矩和转数可以表示为：
t入=t出/GR（3）
n入=n出×GR（4）
式中：t入为变速箱输入扭矩；t出为变速箱输出扭矩；n入为变速箱输入轴的总转数；n出为输出轴的总转速；GR为变速箱一档和主减速的传动比乘积，本研究传动比乘积为14.89。为了便于计算忽略了机械效率的损失。
将行业标准中规定的输入扭矩作为目标扭矩t目标，其方程式为：
n目标=n入×（t入/t目标）-1/b（5）
式中：n目标为目标扭矩下的转数。根据式（3）（4）（5）可以试验场采集数据中半轴在一档位置的扭矩和转数转化成在行业标准规定的目标扭矩下反映的寿命情况，见表1，为了稳妥将惯性滑行状态下行驶的负扭矩转变为正扭矩。
区间
编号t出/kn.mn出t入/n.mn入n目标
11.249058118262816381
21.191700743414275235882
3198093673652306189577
40.96000602233988453
50.8242635490336624008
60.73663147136388724282
70.67415402760773095
80.510379343864292507
90.415132756346187
100.3900203350047
110.230551311374747
120.110875740490921
13-0.15504472049453106
14-0.229448913109647084553
15-0.3502177201869755326204
16-0.4384922714331844761
17-0.520128347494264862
18-0.611080404125234625
19-0.75688472117633770
20-0.88290543086718203
21-0.9192860717952717
22-175467280831458
23-1.1114677442696029497
24-1.2160238159659453511
25-1.352438719521322262
26-1.475439428083039999
27-1.520843101776029135947
表1一档目标输入扭矩下转数分布情况
将表1中“n目标”列进行求和，可以得到所有扭矩区间转化到目标扭矩下完成的圈数为846962转，这个转数小于行业标准中10.8×105转的要求，该量产变速器一档是符合新开发车型国内市场版耐久需求的。
2.3变速器寿命试验方法建立和验证改进
通过上述对比分析，该车型国内市场版开发选用了已经通过行业标准验证的变速器，但是在该车型海外市场版开发过程中，通过对海外试验方法的实车采集和数据处理发现该变速器并不符合耐久的需求。利用采集转化后的数据在台架上开展相关验证，验证中出现了轴承损坏和齿面磨损的问题，通过在设计中改进，开发出专门针对海外市场版的变速箱，二次台架验证关闭了上述问题。
在后期完成的整车耐久验证中，同期开发两个版本的车型在不同的整车验证体系下，变速器系统均未发生失效，路试的结果证明了变速器系统满足市场要求。
3.结语
本文以某新开发车型为研究对象，采集变速器输出端半轴上的扭矩载荷和运转圈数，分解获得各个扭矩区间内的寿命情况，利用抗扭转寿命曲线转寿命化到目标扭矩下寿命情况，通过对比国家行业标准来判断变速器的寿命是否符合市场需求。利用台架在产品开发初期就发现变速器耐久匹配上存在的问题，提前对存在的问题加以整改，达到了整车路试一轮验证通过，减少开发周期，降低开发成本的目的。
参考文献：
[1]周方，胡子涛.手动变速器试验方法[J]研究论文，2010：Vol.48，no.12
系统开发的方法篇3
【关键词】敏捷方法企业应用系统改进
一、敏捷方法应用于企业系统开发的核心思想及内容
1.1敏捷方法应用于企业系统开发的核心思想
（1）灵活性：敏捷方法的核心思想之一就是适应性，这是因为在软件开发的过程中会有很多问题是难以预测的，尤其是在面对变化莫测的客户需求，更加需要一定的灵活性。而敏捷方法相对于传统方法而言就具备一定的灵活性和适应性，并且能够充分利用不同的客户需求来对自己进行进一步地完善；（2）创新性：其次敏捷方法的核心思想还包含以人为本的思想，这是因为传统软件的开发过于强调对开发过程的监督和管理，但是却没有充分发挥个人的特性，因此在很大程度上限制了产品的开发。因此敏捷方法更加看重人的独特性和创新性，在实际研发的过程中不会过于限制和管理，而是以一个较为开放和平等的态度去对待软件开发；（3）迭代增量的开发模式：敏捷方法以原有的软件开发思想作为基础，在实际的开发过程中采用迭代增量式的方法，因此敏捷方法开发的软件版本都具有小型化的特点。其会依据客户需求的优先程度以及风险的大小来制定发行计划。
1.2敏捷方法在企业应用系统开发中的实践
1.2.1敏捷方法在企业应用开发中需遵循的原则
1）核心思想
从整体上来看敏捷方法包含了四个核心价值思想，其主要内容为简单、沟通、反馈和勇气。具体细分来看简单则表示在设计和编码的过程中要遵循简单的原则，即设计的最终目的是为了满足当前的使用需求而不用做假想，因此需要编码设计的更为简单化；沟通则是指设计者、开发者以及客户之间要进行及时地沟通，这样可以有效地对客户需求进行了解，并且设计出高效适用的软件；反馈则是紧接沟通而言的，意思是指需要设计者、开发者以及客户之间充分进行交流，从而达成一致意见，实时的反馈可以帮助设计出来的产品更有说服力；勇气的含义则是针对设计者以及开发者而言的，在设计的过程中设计者以及开发者应勇敢做出选择，不要害怕进行取舍或者是重构。
2）敏捷方法在企业应用系统开发过程实践规则
除了上述的四个核心价值观以外，另外还有一些实践规则需要遵循，其包含了方方面面具体内容为简单设计、测试驱动、代码重构、成对编程、持续集成、现场客户、发行版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40小时工作机制。这12个实践规则共同组成了应用系统开发的准则，该内容也需要不断完善。
二、敏捷方法在企业应用系统开发过程中局限
敏捷方法在企业应用系统开发的过程中也会遇到各种难点，譬如由于客户的需求是不确定的，这个问题体现在实际的操作过程中会难以满足不同客户群的所有需求。加之客户是无法参与到软件开发的整个过程之中的，因此这种非透明性也会给产品设计带来诸多问题。为此针对敏捷方法在企业应用系统开发研究，加强对方法的改进和创新十分有必要。
2.1客户需求难以满足
软件开发过程中有一个难点问题需要进一步解决，那就是客户需求不确定性的问题，这也是为什么在应用系统的开发过程中会出现各种各样实质性的问题，为此加强对不同客户群需求的研究和关注十分有必要。同时传统的软件开发过程是需要将前期的调研分析进行细致划分和整理，并且以合同的形式来确立客户的需求。这是因为在实际的操作过程中很难一次性地针对客户的需求进行详细地了解，更不可能实现对客户需求的完全掌握。
2.2开发过程的非透明性
要想真正意义上满足客户的实际需求，必须要在原型的基础之上进行演示、试用、测试，这是一个漫长的过程，而且有时候在实际使用过程中才能挖掘和确定客户的真正需求。为此要想让客户群体满意是一件非常难的事情，这就需要客户可以参与到软件开发和研发的过程中，但是这在实际操作的过程中是难以实现的。系统开发过程非透明性的问题，导致了很多问题的不断发生，例如系统工作模式和操作界面与客户的要求存在一定距离，甚至会截然相反。
三、敏捷方法在企业应用系统开发中的应用探析
（1）迭代式项目：从迭代项目计划的内容上来看，其主要是指将系统开发的整个过程分成若干了过程和小部分，并严格按照一定的要求来完成。在这个过程之中，通过不断地完善和改进可以促使系统处于一直可使用的状态；（2）项目文档：项目文档也是敏捷方法在企业应用系统开发过程中的一个重要内容，其对于系统开发来说有着至关重要的作用，为此加强对维护系统方面文档的编写将是一个好主意；（3）重构改进：重构的改进也是敏捷方法的一个重点内容，其可以利用系统日志机制，实现对问题的分析和处理，即当每次重构之后若能够保证系统日志监控系统正常运行，就可以找出错误源；（4）项目运行维护：项目的运行维护是指，对于系统的开发是一个长期改进和不断完善的过程，因此在进行模块和功能上的变更时，要进行科学管理和维护，扩展和变更目的是为了适应业务环境变化的需要。
四、敏捷方法在企业应用系统开发中的改进
（1）开发模式：在具体的实施过程中要将项目进行分块开发和处理，从其根本目的上来看，是为了合理地规避风险，同时有必要先做架构设计从而可以很好地利于各平台，实现在开发模式上的统一；（2）需求挖掘：软件开发的最终目的是要实现对客户需求的满足，因此在具体的实践过程中要加强对客户需求的挖掘，采用具体的办法可以是问卷调查、进行素材的收集和整理。更为重要的是将这些有效的数据进行整合并加以分析，找到当前市场上的空缺和客户多样化的需求；（3）团队组织：软件开发的过程是十分复杂的，因此一个好的组织和团队是十分有必要的。敏捷方法在企业应用系统开发的过程中也要借助团队的力量。团队之间要做到科学分配任务，从而保证系统开发可以又好又快地完成；（4）质量控制：质量控制在敏捷方法当中也是十分重要的，只有切实保障系统开发后投入实践的作用；（5）开发过程控制：开发的整个过程是十分艰难的，每一个环节都是至关重要的，为此加强对系统开发的过程控制相当有必要。
五、结束语
加强对敏捷方法在企业应用系统开发过程中的应用和改进研究，需要从多个角度进行深入讨论和考虑，尤其是针对当前敏捷方法在企业应用系统开发过程中的实际运用情况，对现存的一些问题进行剖析从而找到问题发生的根本原因。更为重要的是针对当前敏捷方法在企业应用系统开发过程中透露出来的不足进行进一步改正，为此加强对问题的分析以及措施的探索十分有必要和有意义。希望通过本文的研究和探讨，能够不断发挥敏捷方法在企业应用系统开发过程中的作用。
参考文献
[1]荣国平，刘天宇，谢明娟，陈婕妤，张贺，陈道蓄.嵌入式系统开发中敏捷方法的应用研究综述[J].软件学报，2014，v.2502：267-283.
系统开发的方法篇4
关键词：软件工程；软件项目管理；组件；最佳实践
1引言
在当今信息社会，信息技术已经普遍地服务于社会的各行各业，以计算机信息系统为核心的it技术已成为最活跃、最有发展潜力的支柱产业，绝大多数的社会业务领域都形成了非常成熟的高水平的行业应用软件。但由于软件开发过程的缺陷、项目管理的问题和缺乏对企业内部软件开发过程的最佳实践总结与应用，软件系统的开发还存在着严重的问题。根据美国standishgroup对2003年美国1.35万个软件项目的统计，有问题的和失败的软件项目占66%，
遵守统一过程（rup）提出了六项最佳实践即迭代的开发软件、需求管理、使用基于构件的体系结构、可视化软件建模、验证软件质量和控制软件变更。软件开发过程以体系结构为核心、按照高级抽象宏观指导下，通过领域建模、主题业务分解、功能任务确定和过程实现的层次建模方法完善最佳实践的过程；基于体系结构为核心的、适应性和动态扩展方便的组件集成的方式，增量、迭代式软件开发组织过程；迫切需要通过设计流程、技术、方法和人员等各个有机结合才能实现健壮的需求管理、项目计划、项目跟踪、质量保证和业务扩展应用，通过组件集成降低软件工程总体的代价；因此软件开发过程的最佳实践也应是为完成某项任务时最高效（最少的努力）和有效（最佳的效果）的方式，并且是基于一段时间内被大量人员检验的可重复过程。在最佳实践完善与实践中，以提高软件生产能力为根本目标的软件工程管理。
本文提出普遍适应意义的最佳实践过程基于软件过程控制中，关注软件目标、软件边界及范围、软件成本和其它与问题领域相关的目标，具体的实践过程步骤如下：
（1）建立并设计适应本企业技术能力的软件开发规划及标准。
在项目启动、项目计划、软件过程和跟踪监控等软件项目管理核心过程控制中，首先要基于企业所在行业、领域特点和技术积累经验建立恰当的过程模型与相应过程标准。例如在设计中考虑某系统的业务管理角色、授权信息在系统运行期间是相对静态不变的即“数据动态、业务静态”的启发规则，设计约束和实现的组件服务标准设定为“一次数据获取，二次数据组装，三次业务静态应用”，进而保证了设计思想与编码过程中的统一模式，成为该软件最佳实践的一个重要因素。
（2）基于软件过程的人员授权。
在实践中，应该基于软件过程的3p（人员、问题和过程），将三者基于主题业务特征、人员能力和角色职责、软件过程任务，量化授权资源、责任和里程碑责任人。例如在某软件过程责任授权中，为实现软件过程的阶段和任务，按照最佳实践的方式进行组织与评审。
（3）定义需求规格获取的工程方法、管理配置变更制度建设。
按照操作、控制简便和实用，指导性强的原则，基于企业的组织特点和技术生产水平，以快速原型系统为典型特征，适应软件变化特征和便于阶段评审的软件过程的制品配置管理。
（4）以领域分析建模为基础的抽象设计方法指导。
设计过程遵循自顶向下、由粗到细、逐步细化，抽象为指导设计的原则，按照分治和启发式规则完善体系结构设计和组件化应用系统设计。比如我们进行信息化系统的建模过程中，可以按照业务流程分析和指导下，确认界面原型，根据业务的操作与规格约束，确定界面的统一性和布局、界面要素的层次性，基于实际业务流程的信息模型特征进行软件系统基础设施的设计与组件配置和开发，这样实现了软件系统的设计统一性和开发编码的自动化规格，降低各个阶段的开发代价与维护成本。
（5）严格的阶段项目评估和设计原则、约束指导进行统一过程管理。
（6）组件化、标准接口协议规范的集成风险控制。
（7）过程的跟踪与适当、及时变更控制与配置管理。
（8）适应主题业务特征与行业规律的功能设计。
组件定义的粒度，编码规则，集成化的开发与构建系统模式指导
（9）可控制的项目目标、量化的设计约束和标准化过程管理流程。
（10）项目全过程的标准软件制品规格控制。
通过上述统一的软件开发过程模式，使企业能够适应不同的项目实践要求和良好的系统解决方案，同时，又能够具有适当的过程控制灵活性和风险控制。
4最佳实践工程案例
按照本文所提出软件开发过程的最佳实践步骤得到实践检验的软件系统的特点总结如下：
通过以上不同特点、规模不同的软件项目情况统计可得出，本文所提出的采用软件开发的最佳实践方法进行组织，从软件错误或缺陷数量、产生的阶段过程、维护代价等方面来看，提高了软件开发效率，降低软件开发成本，软件过程可控，结果预期和维护代价均得到满足，项目预期成功几率大大提高，提高了软件开发生产力。
5结论
本文所提出的最佳实践，从软件开发过程组织与控制上，均保证了在软件过程中符合软件工程的原则和方法实践指导。通过多个不同类型和规模的软件案例统计可得出，本方法在中、小型软件系统开发、软件工程管理等过程中，具有较强的指导意义。
本文所提倡的最佳实践方法因为选择的案例和实践均为中、小型规模项目，因此在最佳实践的开发过程中，软件风险、决策选择和软件目标的建模方法等没有过多强调。如何结合中、小型规模软件项目开发中，重点解决的是保证快速、高效、高质量和低代价的目标下，更突出阶段风险评估、过程评审和决策过程的控制是研究和解决的重点内容。
参考文献
[1]zhangwei,zhouchang-le.muti-agentconcurrentmodelinsoftwareprojectmanagement.applicationresearchofcomputers,vol.2004,pp.17-19.
[2]kurtc.wallnau,scotta.hissons,robertc.sealord,buildingsystemscommercialcomponents,addison-wesley,2001.
[3]韩万江,姜立新.软件项目管理案例教程[m].chinamachinepress,2005.
[4]garmus,d,anddavid,h.thesoftwaremeasuringprocess:apracticalguidetofunctionalmeasurements.nj:yourdonpress,1996.
系统开发的方法篇5
关键词：面向对象设计UmL用例图数据字典
中图分类号：tp393.09文献标识码：a文章编号：1007-9416（2015）09-0000-00
1引言
风险管理系统是一个对外应用系统，从最初的需求分析、概要设计、详细设计、编码和单元测试、综合测试和系统的部署、上线及培训，在这一套完整的系统设计开发中，贯穿了面向对象的方法和思想。本文以贵阳市风险管理系统为例，概述一下整个软件项目开发的全过程。
2风险管理系统开发过程
风险管理系统是于09年10月份正式开始启动的，客户方派出了10名左右的业务人员与我们做需求分析的讨论。在一开始，双方主要是学习《风险管理实施方案（试点）（“二・五・一”系统工程）》指导文件的精神，评估项目的规模和拟定开发的大体框架。经过一个多月的讨论，初步规划出了风险管理系统的整体框架图，如图2.1所示。
图2.1贵阳市风险管理系统顶层功能结构图
2.1需求分析阶段
在一开始的时候，对整个风险管理系统，根据“二・五・一”文件整体划分为2大类，执法风险管理和尊从风险管理。将文件中的94条遵从风险和200条执法风险一一梳理，提取能够用计算机在现有的征管系统和税收管理员平台中抓取的风险点并根据业务需求划分为申报征收、登记发票类、税收减免类、计会统票类、稽查法制类、5大类。最后经双方讨论，在原有的业务需求上增加一些功能点，包括纳税户风险评估、遵从风险的事前风险、风险特征库的信息查询和执法案例库的查询形成了最终的一个风险管理的顶层用例图和最终的需求文档，图2.2为顶层用例图。
图2.2风险管理系统顶层用例图
在需求文档中，以用例为驱动，描述了该风险管理系统的大体功能实现。此时已经是经过了2个多月的反复修改和讨论。系统的大体结构模型已经出来，接下来就是设计阶段。
2.2概要设计阶段
在概要设计阶段，主要工作就是数据库层的设计，确定系统框架，划分功能模块。概要设计阶段的进度主要取决于需求阶段对系统设计的整体把握情况，同时在更深入的设计中也会暴露出在需求分析阶段的盲点和不足，需要返回到需求设计阶段再讨论再分析，可以说这是一个迭代的过程。这里以绩效考核这个小功能模块为例来看一下概要设计的内容。
在概要设计之初，根据系统总体功能结构图，划分功能模块，在接下来的每一个设计阶段都以功能模块为单位形成对应的设计文档，最后整合成整体的设计文档。绩效考核的概要设计文档包括六个方面：模块结构图、模块功能描述、模块用例图、模块类图、数据字典和收集到的原始表单。其中收集到的原始表单不一定每一个功能模块的概要设计文档中都必须有，只有在业务需求中提供了表单的才将原始表单的表样附加在概要设计文档中。原始表样对我们后台数据库的表结构的设计也有一定的帮助。在概要设计文档中最重要的就是用例图及用例说明和类图设计及数据字典：用例图是系统功能的一种图形化的模拟，通过用例图及辅助的用例说明，可以确定系统的主要实现功能和使用该功能的用户，也就是常说的角色权限的划分，这些都必须在用例图中体现出来；类图设计和数据字典主要是后台数据库的设计，在实际的数据库中需要哪些表或视图，基本上类图中的每一个实体类对应的就是数据库中的表或者视图，数据字典是对数据库中将要使用的表结构的分析，包括表的字段名（字段的中文名和英文名）、字段的长度、字段的属性等都有定义，方便在详细设计阶段设计表结构。同时在类图中也体现了表之间的关系，主、外键关系，关联关系，对我们下面的建表也有指导作用。
图2.3绩效考核用例图
图2.3描述的是绩效考核用例图的，绩效考核模块一共有两个用例，每个用例有前置条件，表示该用例在什么情况下使用，对用例的描述，主要是介绍该用例实现的业务功能，用例的行为者是指使用这个用例的用户和角色，行为者是为了系统部署以后对用户权限的划分，同时能在一定程度上确保系统的安全使用，后置条件描述的是该用例发生以后系统会产生的数据流向以及系统的下一个状态。
图2.4是绩效考核类图，用例图从业务角度描述的是系统的功能，而类图是从数据结构的角度描述系统的内部数据结构，用例图和类图都是面向对象分析方法中常用的数据分析方法。
图2.4绩效考核类图
绩效考核类数据字典
序号字段中文名字段英文名属性字段长度方式备注说明
1考核iDKHiDVarchar213自动生成序列系统调度时生成
2市局iDSwJBmVarchar26自动写入
3区县局iDQXJBmVarchar210自动写入
4税务所iDSwSBmVarchar211自动写入
5风险点数量FXDSLnumber9系统统计系统调度时生成
6税务登记户数SwDJHSnumber10系统统计系统调度时生成
…………
30严重级风险未处理数YZwCLSnumber系统统计系统调度时生成
2.3详细设计
在经过需求分析和概要设计阶段以后，系统的雏形已经基本形成的，进入详细设计后的主要工作就是建表和界面设计。建表需要统一，一般有1―2个人协作完成，这样数据表及表间的关系比较清晰明了，建表完成以后，将表的表名和建表语句分发给各个功能模块的设计小组；其次就是界面设计，界面设计的方法有很多种，一般采用的是在woRD文档中用表格和颜色来设计界面图，用不同的颜色来表示界面的控件和按钮，这里还是以绩效考核模块为例来说明详细设计的主要任务。详细设计文档包括功能模块设计的相关数据集，该模块与其他模块之间的关系，是否存在相互调用，如果有相互的调用关系，模块小组之间还必须对界面上的功能以及表结构统一规划，相互沟通；详细设计文档中最主要的就是用户界面的详细设计，这一部分又包括：界面结果或菜单结果，这个主要是为了最终系统整合时的系统菜单栏的设计服务；其次是用户界面图，用户界面图不但有每一个页面的设计图还对应有该页面的界面处理流程和界面约束描述；最后就是用户界面和模块关系表，这个关系表体现的就是页面之间的跳转关系，图2.5是绩效考核菜单结构图。
图2.5绩效考核菜单结果
图2.6县（市、区）局绩效考核成绩查询页面设计
图2.6是一个页面效果图，描述的是县（市、区）局绩效考核成绩查询页面设计图。
在详细设计文档中以页面为单位，对每一个页面的设计风格、页面上使用控件的名称以及点击控件后的触发事件都有详细的描述设计，包括数据控件使用的哪一个数据集的哪一个方法，方法的SQL语句在这个文档里都体现出来了，这样在后面的编码阶段就只需要根据详细设计编码实现就可以了。
2.4编码和单元测试
编码和单元测试是整个系统设计中相对简单的环节，当然这个前提是需求分析，概要设计和详细设计已经做得很完善的情况下，如果前面的三个环节有一个没有分析全面，那么编码阶段就可能出现表设计不合理，某些功能的实现与设计有出入，需要重新回到设计阶段，甚至回到需求分析阶段，这些都会导致项目进度的滞后，使软件系统不能如期的交付用户验收使用。在做编码的同时，程序开发人员也充当了测试人员的角色，此时的单元测试与编码是在一起完成实现的。
2.5综合测试
一个高质量的软件必须有充分的测试，整个系统开发完成以后，将各个功能模块整合还一起形成一个最初的测试版本，这是就需要测试人员经行大量的测试，在风险管理项目中主要是进行白盒测试，测试一般包括：单元测试（这个测试我们需在编码阶段完成）、集成测试；在综合测试阶段主要就是集成测试，大概要经行3―5轮的反复测试，最初的测试主要是功能测试，然后是用户级的测试，包括测试界面的友好性和界面风格的统一等等。最后是压力测试，压力测试一般是用作系统的性能测试，测试系统的性能瓶颈和系统部署的硬件设备的最低配置要求，这些都可以用压力测试来实现。
2.6系统的部署上线和培训
系统开发出来，经过综合测试合格以后，就需要将整个系统从开发环境移植到实际使用环境中进行用户使用测试，在这一过程中也会暴露出系统的各种问题，需要开发设计人员及时对系统进行修改调整，当然这个调整时小规模的调整，系统在真实环境中运行一段时间，需要观察系统的稳定程度，其中也可以穿插有客户的用户测试，压力测试以及系统的操作使用的培训，如果运行稳定无误，客户验收合格，整个项目开发才宣告结束。
3结语
在风险管理系统的整个开发设计流程中，从需求分析阶段开始直到最后的综合测试，都体现了面向对象的设计思路和方法。在需求分析阶段，采用了面向对象分析中UmL建模的思想，以用例为驱动进行需求分析；在详细设计阶段采用面向对象编程，选用VisualC#进行B/S模式的开发，使用面向对象的设计与编码实现能有效的保证软件质量，缩短开发周期，降低软件开发成本，极大的提高了对软件开发过程的管理效率。
系统开发的方法篇6
随着科学技术的不断进步，计算机硬件也进入了高速发展阶段，软件开发方法也随之得到不断更新。面向对象（oo）方法于60年代后期被提出，但花了近乎20年才被人们广泛认识和使用。如今，面向对象软件已成为行业内的主流，并在软件行业中占据着非常重要的位置。传统的软件工程方法常把数据与处理的过程分开，大大增加了软件开发的难度。面向对象方法吧软件工作视作离散解空间对象的结合，并使问题空间与解空间的结构、描述模型相一致，简化了程序的同时降低了软件系统开发的难度。
目前，国内普遍采用传统的结构化分析设计和面向对象程序相结合的方式进行项目开发，并且大部分项目也取得了成功。但这种方法无法让实现两者的平滑过渡及连续性，并且不利于软件重用、维护、测试等工作的进行。如果全过程仅采用面向对象软件工程方法，则能确保信息系统开发的完整性和一致性。由于面向对象数据库产品尚未完善，因此此方法很难应用于实际中。为此，必须制定相应的规则和算法，确保面向对象分析、面向对象设计的结果能正确地向关系数据库转换。
一、关于面向对象软件工程
1.面向对象。面向对象主要是指在满足客户需求的基础下，将需求合理构建成独立的业务模块，之后利用多态、继承、封装、抽象的编程思想对业务逻辑进行构建，使之与业务需求相一致，最后将各模块整合以达到最佳的预期效果。
2.面向对象软件工程。面向对象本文由收集整理软件工程时面向对象技术和软件工程相结合的产物。面向对象技术贯穿到面向对象软件工程的全过程，并将过程中形成的面向对象分析、面向对象设计和面向对象程序设计三部分，贯穿到软件工程的各个相应阶段。面向对象软件工程所采用的具体模型不外乎以下几种：整体——部分模型、类——对象模型、对象模型、分类模型和状态模型。
3.面向对象的方法。随着时代的发展，面向对象分析和面向对象设计的理论和技术都得到了逐步完善，软件开发方法也不断地推陈出新。国内外目前已衍生出多种的面向分析方法，其中最有影响力的主要有：booch方法、rumbaugh方法、coad和yourdon方法、jacobson方法、统一的ooa方法（uml）。从面向对象分析到面向对象设计是一个将模型逐渐扩充的过程。在这个过程中，主要考虑的是如何分析处理问题，对于与特定计算机相关的问题则可以忽略不计。面向对象设计可以分为高层设计和低层设计两个阶段，高层设计主要用于建立体系整体架构，低层设计则主要用于对类的详细设计。
二、面向对象方法在医院收费信息系统的应用
为了更好地理解面向对象软件工程方法在信息系统开发中的应用，我们采用了医院的收费信息系统为例。首先，可将医院收费的需求构建成三个独立的业务模块——功能模型、动态模型、对象模型。
1.功能模型
对收费信息系统进行业务分类，其中主要包括划价和查询统计两个子系统。分类的目的是为了业务模块的构建更合理清晰，节省和减少了系统操作人员的工作时间和工作量。病人缴费以后，操作人员可通过划价子系统输出其收费单据，并按有关规定将单据导入数据库中。如果病人想清楚医院的具体收费，操作人员可键入查询条件，从而为病人输出相关单据。
2.动态模型
医院收费信息系统被划分为两个子系统，其中划价子系统的动态模型主要显示为一些列的前台操作，其主要表现为：病人请求→划价员根据相关单据进行划价；病人付款→操作人员打出收据→将信息导入数据库→修改记录。查询统计子系统跟划价子系统类似，主要均是由病人提出请求，操作员再根据病人需求键入查询条件，从而输出病人的相关统计表单。
3.对象模型
本系统主要涉及到的重要的类模型为——库存类图、人员类图和单据类图。
（1）库存类图。库存类模型所增加的属性（库存量、生产日期、保质期）主要跟药物和其特性密切相关。医院内各种药物及材料都标明了库存量和保质期，而药品则常被细分为：西药、中药、中成药。
（2）人员类图。病人和医院工作人员均继承在人员类中，其中病人是医院收费信息系统的主角，划价请求、查询请求、缴费等划价子系统业务都是病人类的方法。医院工作人员类又可细分为三个子类，包括医生类、收费员类和操作员类。医生类是必然的存在，病人的病情及其主治医生，这些都需要存档。操作员是除病人外在系统中的又一主角，查询、划价、统计均是其工作。由此可见，系统的操作运行离不开操作员。收费员的工作极为简单，只需进行收费操作即可。
系统开发的方法篇7
1 对象的生命周期
在ooa中,通常把对象的生命周期划分为3个阶段,即发生、发展、消亡,对于一般应用领域这样划分无疑是正确的,但管理信息系统有其自身的特殊性,如有计划、稳定等过程,因此其对象有必要确定为孕育、产生、发展、成熟和消亡5个阶段的发展过程。(1)孕育阶段:指对象的实体还没有正式出现,而是根据目前的各种需要提出的设想、进而转变成计划的阶段。例如增加员工计划,客户咨询、协商,产品计划、设计等等,都属于这个阶段,mis的管理工作应该从这里开始。但在这一特殊阶段里,在多数情况下还没有严格意义上的对象,因此,在分析时通常要进行单独处理。(2)发生阶段:对象的实体正式出现阶段,这一阶段主要表现特征是使得对象具体化,如员工的招聘,客户的合同签定,产品的投料、加工等等。(3)发展阶段:对象从产生到成熟的发展过程,如员工岗前培训、定期培训,客户合同履行,产品的装配、改进、更新换代等等。(4)成熟阶段:指对象的稳定、定性、定型阶段,在这一阶段中,对象没有发生本质的变化。如:员工的工作(考核)、客户的售后服务、设备维护保养等。(5)消亡阶段:对象退出系统,如员工调离、退休、死亡等,产品入库、销售,设备报废、调拨等。
在同一个组织中,几乎所有的对象均明显地表现出上述5个阶段的生命过程。值得一提的是,把对象的生命周期划分成5个阶段,有利于数据的挖掘、分析和决策,如客户这一对象,从它对产品的咨询、协商便开始记录,有利于今后对产品性能、需求、服务质量的分析。其次,有的对象生命周期中的5个阶段在时间上是交替进行的,如员工对象:培训-工作-培训-工作,但仍可以分别放在发展(培训)、成熟(工作考核)两个阶段处理。
2 对象的分布模式
所有组织的存在都有其目标,对应于目标相应的实体,姑且称为目标型对象;我们围绕着该目标的展开而配备、设置了各种各样的实体,这些实体都是直接为实现该目标服务的,将它们叫做服务型对象;为管理、控制这些服务型对象而设置了各种管理机构,这些机构同时负责与外部、上级进行联系,这些实体叫管理型对象;此外,还有与管理型对象直接联系的外部实体,如此以形成辐射状体系,即所谓“目标中心”。在mis中,所有对象分布在4个层次:目标层、服务层、管理层和外部层,分别是目标型对象、服务型对象、管理型对象和外部对象。在生产型企业中,目标是生产产品、进行销售,从而获得利润。因此,其目标层的对象是企业生产的产品。围绕产品生产需要原材料、部件、原材料仓库、加工设备、操作员工、产品仓库等,因此我们可以在服务层上有围绕目标对象类的各种服务性对象类。在功能层上则是对服务性对象进行管理的管理性对象类,如人事科、生产科、技术科、设备科、供应科、销售科等等。最后一层是外部层,如原材料、部件供应商,产品客户、售后服务等。一个组织目标中心。组织中的所有机构也应有自己的目标中心,现将它们称为目标中心,但所有的分目标必须服从于组织的整体目标,也只有这样整个组织才能显示出旺盛的活力。如库房是一个机构,库房的目标是管理原材料、配件、成品,为这些对象服务的是货架(货位)、管理员,管理层就是库房,与它有关的外部实体是供应、销售、车间等。
3 对象的识别方法
在mis面向对象系统分析中,主要工作是建立对象的逻辑模型,即对象的识别,对象属性说明方法说明以及方法的处理逻辑说明,其中最关键的是对象的识别。由上面的分析可知,所有的对象均具有孕育、发生、发展、成熟、消亡5个阶段,而所有组织(机构)的对象也都分布在以目标为中心的目标层、服务层、管理层、外部层这4个层次上;根据对象的生命周期、按4个层次进行对象识别的方法,我们称之为“目标中心识别法”。采用目标中心识别法进行对象识别的方法与步骤如下:(1)确定组织的目标,并找到为实现这一目标的实体——对象。如生产企业,其目标是生产产品,获得利润。因此在目标层上的对象就是产品。(2)根据目标型对象的需求,对目标型对象逐个进行分析,找出与其直接相关、直接为其服务的对象。如典型的丝绸服装企业围绕产品的服务是提供生产产品的原材料、配件,产品加工所需的设备,进行产品加工的人员,以及产品加工后的测试、检验人员和仪器,最后是产品的存放等。这样就有:原材料、配件、仓库、设备、工人等对象。(3)对服务型对象进行归类,分析确定对其控制、管理的对象。管理层对象在初始分析中,保留原有的实体,然后再根据系统整体需要进行取舍。(4)确定与管理层有关的外部对象。查找不属于本组织的、与本组织管理层对象有联系的外部对象。以上方法和步骤可以适应于组织总体对象识别、也适应于组织中机构的对象识别。
4 对象的多态性问题
根据目标中心分析法提取的对象,都具有上述的生命周期,这种生命周期反映对象的多态性。此时,处理对象多态性的方法有两种。第一种:把一种状态作为一个对象处理;第二种:综合各个阶段对象的属性,可以定义一种基类,其它几种状态利用对象的继承性,作为基类的子类。基类应包含各个子类共同的、稳定的属性和成员。在“孕育”阶段,有些情况下,对象还没有正式出现,这时仅是概念对象,必须另作处理;但有时对象已经出现,可与其他阶段一样看待。如在“员工”这一对象中,其基类的属性有:姓名、性别、年龄、工种、地址、电话等,而子类有:招聘计划、招聘、培训、在岗、退休(调离、死亡)。从语义上,这些应该是对象的方法(成员函数),但对象在不同阶段有它自己的属性,如培训,有培训项目、培训时间、成绩等,具有属性必然有其自身的成员函数,应该作为对象的子类来处理,而不是方法。
系统开发的方法篇8
关键词：管理信息系统；原型法
在管理信息系统的开发过程中，采用有效的开发方法是非常重要的。开发管理信息系统的具体方法很多，大致可将它们分为结构化生命周期开发方法、原型法、面向对象开发方法和CaSe开发方法等几大类，这些方法各有优缺点。
目前较为流行的管理信息系统开发方法是结构化生命周期开发方法。但是，结构化生命周期开发方法存在着周期长、成本高的缺点。研究人员在关系数据库系统、第四代程序生成工具和各种系统开发生成环境诞生的基础上，提出了开发管理信息系统的快速应用程序开发方法（RapidapplicationDevelopment，RaD）,这种方法的本质是尽快地开发出可以使用的原型系统，因此也把此方法称为快速原型法简称原型法。
1.原型法的基本思想
运用原型法开发管理信息系统，首先要对用户提出的初步需求进行总结，然后构造一个合适的原型系统并运行，此后，通过系统开发人员与用户对原型系统的运行情况的不断分析、修改和研讨，不断扩充和完善系统的结构和功能，直至符合用户要求为止。它并不注重对管理信息系统进行全面、系统地调查和分析，而是根据对用户的信息需求的大致了解，借助强有力的软件环境支持，迅速构造一个新系统的原型，然后通过反复修改和完善，最终完成新系统的开发。快速原型法的特点是快速地创建出管理信息系统的测试版本，该版本可以用来演示和评估，用户可以借助这种测试版本更加详细地提出自己的需求，系统开发人员可以借助这种测试版本挖掘用户的需求，然后在此基础上对系统的测试版本进行修改。
原型法的上述基本思想，体现出以下特征：
1)原型法并不要求系统开发之初完全掌握系统的所有需求。事实上，由于各种因素的影响，系统的所有需求不可能在开发之初就可以预先确定，用户只有在看到一个具体的系统时，才能对自己的需求有完整准确的把握，同时也才能发现系统当前存在的问题和缺陷。
2)构造原型必须依赖快速的原型构造工具。只有在工具的支持下才能迅速建立系统原型，并方便地进行修改、扩充、变换和完善。
3)原型构造工具必须能够提供目标系统的动态模型，才能通过运行它暴露出问题和缺陷，有利于迅速进行修改和完善。
4)原型的反复修改是必然的和不可避免的。必须根据用户的要求，随时反映到系统中去，从而完善系统的结构和功能，使系统提供的信息真正满足管理和决策的需要。
2.原型法的工作流程
原型法的基本工作流程可描述为以下几步：
1)用户对新系统提出开发需求。
2)开发人员对开发需求（各种问题）进行总结
3)利用工具开发一个系统原型。
4)双方一起进行测试和评价，确定下一步处理方式：对该原型进行分析和修改，并根据新的要求修改。
5)反复对修改后的原型进行测试和评价，是否还有新功能需要增加。直至完成系统开发并交付使用。
上述工作流程归纳如图所示。
原型法的运用，必须依赖强有力的软件支撑环境作后台。这个环境至少应具备：一套操作方便灵活的关系型数据库管理系统软件；一个与数据库系统相适应的数据字典生成工具；一套与数据库系统相适应的快速查询系统并支持复合条件查询；一套支持结构化编程、代码自动生成和维护的高级软件工具或环境。
3.在实践过程中优缺点
快速原型法的特点是快速地创建出管理信息系统的测试版本，该版本可以用来演示和评估，用户可以借助这种测试版本让用户在开发之初就看到系统雏形，了解管理信息系统，更加详细地提出自己的需求，有利于用户及早参与开发过程，激发参与开发的热情和积极性；也可以使用户培训工作同时启动，有利于系统今后顺利交接和运行维护。系统开发人员可以借助这种测试版本挖掘用户的需求，然后在此基础上对系统的测试版本进行修改。
（1）使用原型开发方法有下面一些明显的优点：
1)对于那些用户需求无法确定的项目来说，是一个非常有效的开发方法；
2)鼓励用户参与系统开发的积极性，提高了用户使用系统的热情；
3)由于用户参与到了信息系统的开发过程中，所以项目开发过程的透明度和支持度都非常高；
4)用户和管理阶层可以更快地看到可以工作的信息系统原型，也就是可以更早地得到企业的解决方案；
5)与其他开发方法相比，可以尽快地发现系统中存在的错误和疏漏，提高信息系统的开发质量；
6)测试和培训相对简单，因为许多用户在开发过程中已经参与了测试和培训；
7)这种开发方法大大降低了信息系统的开发风险，这是因为使用不断循环的技术解决方案取代了一次性提交的技术解决方案。
（2）使用原型开发方法存在的主要缺点如下：
1)对于大型系统或复杂性高的系统，没有充分的系统需求分析、功能分析、结构分析，很难构造出原型；
2)这种方法鼓励采用了"编码、实现、修复"的开发方式，这样可能提高了整个系统生命周期的运行支持和维护成本；
3)这种方法失去了开发过程中选择更好的技术方案的机会，因为技术人员和用户都希望尽快地看到可以使用的原型；
4)这种方法过于强调速度，使得许多潜在的系统质量缺陷没有得到很好的解决。
在管理信息系统开发过程中，使用原型开发方法开发进程管理复杂，要求用户和开发人员的素质高，配合默契；必须依赖强有力的支撑环境，否则无法进行。应用原型法进行系统开发，构造原型快速；开发进程加快，周期缩短，反馈及时。一般地，快速原型方法适于开发小型的信息系统项目。
参考文献：
[1]黄梯云，管理信息系统[m].北京：高等教育出版社，2004.1
[2]严建渊，miS的概念和开发[J].电子与信息化，2001.2
系统开发的方法篇9
尽管当前web系统开发已经成为系统开发的重要环节，但是开发的流程却仍然依靠开发人员的个人经验的积累，缺少系统、规范的方法。这使得web系统开发资源复用率低，移植性差，并且维护性和继承性都得不到良好的体现。本文通过对成熟的web开发方法应具备的特性和功能进行论述，进而分析现有web开发方法的优缺点，从而分析和对比这些方法，对存在的问题予以讨论，并提出未来的研究重点。
【关键词】web开发软件工程web应用
1引言
互联网的自诞生以来就在不断的飞速发展中，与之相应的各种互联网技术层出不穷。当今的社会中，web已经渗透到了士农工商各个行业中，成为日常生活中重要的组成部分。web工程可以将传统的信息和数据库系统搬到internet上，拓展了信息交互的手段。
然而web系统的开发流程却面临着很多问题，比如缺少严格和系统的方法。目前web开发还是主要凭借开发者的经验积累，然而复杂的web系统很难依靠个人的经验独立完成。即时费时费力的开发出来一套系统，又因为缺少系统方法，不同系统间相差太大，可移植性和参考性很差，导致重复开发，资源的浪费。本文将就对成熟的web开发方法应具备的特性和功能进行论述，进而分析现有web开发方法的优缺点，从而分析和对比这些方法，对存在的问题予以讨论，并提出未来的研究重点。
2web开发方法应具备的特性
成熟的web开发方法，应当是整体化的web应用开发流程。我们知道，系统化、整体化的好处是可以提高开发效率和质量。因此，成熟的web开发方法应具有如下的主要特性：
（1）web开发方法要易于掌握，因为开发方法的设计初衷是为了降低开发者的工作量，因此开发方法应当易学易懂。但web开发方法还是应当可以将web程序的各方面描述清楚，达到表达能力和难度的平衡。与此同时，web设计方法还应当借鉴常见的开发语言和技术特点，使得开发者更快更好的适应。
（2）web开发方法还应当具有对复杂系统建模的能力。web应用可以使用的范围非常广泛，因此大量的传统信息和数据库系统都进行了web移植。这些应用都具有不同的、复杂的功能，开发方法应当适用于该类需求，应当具有对商业过程、工作流建模的能力。
（3）web开发方法还应当具有表现层建模的能力，这一点在传统设计方法中尝尝忽略。界面是和用户交流的接口，因此需要非常重视界面的表达能力，丰富的界面表达将使得系统更人性化，并将系统的信息完整的表达出来。
（4）web开发方法还应能在较高的抽象层次上表达系统和资源的集成方法。因为新的系统可能要与原有系统相结合，而原有系统的开发语言则种类繁多，开发方法要能适应这种情况。另外，还要保障接口的标准性，从而便利开发出的系统和资源与数据库相连接。
3web开发方法研究现状
随着web技术的飞速发展，越来越多的人注意到web开发的重要性，因此很多web开发方法被研究出来。现今web应用开发方法具有一些共性的特点，比如将web系统模型分为领域模型、导航模型和展示模型，然后经过概念建模、逻辑建模、物理建模和实现四个过程完成web系统开发。这四个过程中，领域模型只用来描述web应用中领域对象的。展示模型用于描述web页面的展示形式，是导航对象和导航行为的最终体现。导航模型是web模型不同于传统的重要部分，它用于描述web应用的导航特性，用于连接领域模型和展示模型。下文将对几个典型的web开发方法进行简介。
3.1HDmlite
HDm[9]（HypermediaDesignmethod）是一种应用很广泛的web设计方法，主要用在web信息系统。该方法的核心是定义结构、导航和表现，并用HyperBase、access、表现方案形式化。HDmlite的特点是可以自动生成，其对HDm进行了扩充，完成从概念方案到逻辑和物理表示的模型转换。但自动生成仅是对静态只读信息页面有效。
3.2webmL
webmL（webmodelingLanguage）是w3i3项目定义的web模型描述语言。该语言可以在概念层次上对web应用进行复杂描述。它提供了图形化高度抽象的web应用描述方法，并包含了完整的设计过程和工具。此外，由于webmL支持XmL，可以自动产生代码。
3.3Rmm
Rmm（Relationshipmanagementmethodology）常用于设计、构建和维护internetweb系统。其目的是减少动态数据库驱动的维护成本。该语言具有形象化、迭代式过程等特点。Rmm模型分三层，即内容层、多媒体层和表示层。Rmm开发方法特别针对导航机制进行了优化，便于构建和测试。
3.4araneus（aDm）
araneus由数据库研究衍生而来，其内容层采用eR模型对领域对象进行建模，多媒体层分为两个阶段，概念设计和逻辑设计。该语言可以将数据库结构映射到超文本结构，并自动生成HtmL页面。数据库设计和多媒体设计之间，逻辑设计和概念设计之间的区分是araneus的特点所在。
目前的web开发方法还有很多，如oo-H方法，Ume方法等，在此并不过多赘述，感兴趣的读者可以很方便的查阅到相关的技术文献。
4结论
前文中概述了web开发方法所应当具有的特点，并简介了当前的web开发方法的特点。可以看到，尽管可用的web开发方法很多，不同方法各具特色，但是每种方法都是针对于一个和数个方面进行的优化，并不能满足于系统化的软件工程设计需求。因此，这些方法的实际应用程度也并不高，造成了很多的浪费。
目前web开发方法主要还是存在方法复杂的问题。web开发方法研究者仅根据自己的领域，而没有考虑到多领域的融合问题。另外，尽管web开发方法提供表现层建模，但多数方法在该方面过于简单，没有体现出设计细节。而模型间缺少清楚和灵活的映射，这也使得层间的连接非常的贫瘠。总的来说，目前的在规范化角度做得很好，但在工程化的方面还很欠缺，所以在未来的研究中，应当令web系统研究方法更具工程化的特性。
参考文献
[1]梅宏，陈锋，冯耀东等.aBC：基于体系结构，面向构件的软件开发方法[J].软件学报，2003，14（4）：721-732.
系统开发的方法篇10
关键词：软件工程；项目管理；角色
计算机管理信息系统(简称miS系统)的开发是一项复杂的系统工程。从70年代开始，人们逐渐认识到，为了保证miS系统开发成功，必须采用工程化的系统开发方法，并研究出一些符合工程化标准的开发方法。这些方法旨在指导开发者进行工程化的系统开发，从而加快miS系统开发的速度、保证质量、以及降低开发成本。工程化的系统开发方法确实在开发实践中取得了一定的效果。
那么，是不是采用了工程化的系统开发方法便一定能保证miS系统开发的成功呢？答案是否定的。有许多失败的miS系统的例子，其开发也是采用了工程化的方法，或声称采用了这种方法。但结果在投入了大量资金后，系统却不能达到预期的目标，满足不了用户的需求，以致用户方怀疑是否应进行该项目的开发，或者开发所选择的硬件、软件以及开发工具是否得当。究竟问题出在哪里呢？通过对一些失败的miS系统的分析，发现问题并没有出在开发方法本身，以及硬软件的选择上，而是出在了开发方法的实施过程中，也就是说主要出在开发项目的管理上。
任何一种开发方法最终是要由人来实施的，人们在开发工作实施过程中不可避免地要遇到许多项目管理方面的问题，如何正确对待、解决这些问题，直接关系到miS系统开发的成败。目前计算机界虽有许多关于miS系统开发中项目管理方面的问题的讨论，但大多局限于针对理想开发环境中的理想开发模型的讨论。而实际的开发环境和开发模型却各不相同，它受到各种客观因素的影响，忽略这些因素，或者回避、不解决存在的问题，必将导致开发工作的不完善、甚至于失败。本文就是要通过讨论如何处理实际miS系统开发中一些重要因素之间的关系，分析项目管理中存在的矛盾，来揭示其中存在的问题并探讨解决的方案。
1
什么是miS系统开发的项目管理
miS系统开发的项目管理是根据管理科学的理论，联系miS系统开发的实际，保证工程化系统开发方法顺利实施的管理实践。它包括miS系统开发中的项目评估及可行性分析、人员管理、进度管理及成本控制等方面。
2
项目开发中的角色及其职责
一个miS系统的开发需要用户方与开发方的共同协作。在一个miS系统开发中，开发方人员和用户方人员各自扮演着不同的角色。主要角色有：
用户方的项目管理人员：他是开发项目的组织者，负有开发项目的计划、系统的阶段验收及对系统整体进度的监控、经费的使用、与开发方的项目管理人员工作的协调、用户方的使用人员的组织与培训等职责。
用户方的业务人员：miS系统需求的提出者，也是miS系统的最终用户。他们是对应用系统开发成功与否的最终评判者。
用户方的决策层：miS系统开发的最终决策机构，决策层要对miS系统开发的项目的上马、经费的预算以及系统所要达到的总目标等作出决策。其决策直接关系到miS系统的开发能否成功与顺利实施。
开发方的项目管理人员：负责项目的计划、开发人员的组织与调度、开发进度的检查、以及与用户方项目管理人员工作的协调。
开发方的软件编程人员：根据用户方的需求、按照项目的计划及进度进行系统开发。
3
项目管理中各种问题及各种关系的处理
3．1 用户方与开发方的关系
用户方与开发方是对立的统一体，双方均希望将开发项目做好。但用户方可能对计算机系统工程，如工程组织，缺乏全面的了解；而开发方对用户方的需求、细节也可能了解不充分。由此使得用户方与开发方对工程的理解从一开始就存在着差异。而这种认识上的差异与理解的不同往往在开发初期并没有表现出来，当系统开发结束时，双方才发现这种差异使开发出的系统与实际需求偏差甚远。因此，miS系统开发项目管理的重要目标便是建立一个便于开发方与用户方之间进行交流的环境。在系统需求分析阶段，开发方与用户方的深入的交流是项目获得成功的关键。但这种交流却经常由于各种双方的误解而难以沟通。
在需求分析阶段，开发方的分析人员总是先把精力集中在整个系统的总的需求上，而不会对具体细节作过多的考查。当用户方提出一些细节要求时，开发方往往说：“这些问题留待后面讨论”，而糟糕的是以后却可能永远不会再谈及这个问题。当用户方认为已经向开发方提出这些需求时，开发方却根本未予考虑。
因此，开发初期，用户方的项目管理人员应该把这些“留待后面讨论”的需求单独记录整理，在开发方做完系统的整体需求分析后，项目管理人员应及时提出对系统进行进一步的、更深入细致的、具体的需求分析，以解决那些开发方要“留待后面讨论”的问题。
在某些需求尚未确定时，用户方项目管理人员往往会说：“这部分需求我们还要考虑，不过你们可以先按现在的模式做。”遗憾的是，开发方经常就会把现在的工作模式作为将来的、确定的需求去设计开发系统，而把用户方在此需求上的未确定因素抛在脑后。当后来用户方要求其改变时，开发方便陷入了窘境。因此，用户方管理人员应尽量将需求陈述清楚，对不能确定的因素，应提出几种可能的实施方案供开发方参考，以保证开发方系统设计时，将不确定因素设计成灵活可变的功能。
其实，需求分析报告是对系统需求的书面表达形式。由于需求分析报告是采用软件设计的术语编写的，因此常常令计算机背景知识较少的用户方难以理解，也就很难发现需求报告中与实际需求不符之处，更难提出建设性的意见。特别是那些编写得较差的需求分析报告，用户方更是不知所云。
因此，用户方的项目管理人员一定要要求开发方对需求分析报告进行进一步更详细的解释，以便用户方准确地理解需求分析报告内容，能及早地发现需求与实际的偏差。这也是对需求分析工作的总结与确认。
用户方说：“计算机应该能实现这个功能，为什么会做不到？”用户方往往容易过高地估计计算机的软件开发工具的能力，总认为它一定能实现任何所需功能，期望值过高，所以经常会对所设计的软件大失所望。其实任何技术均有其一定的局限性，计算机系统也不例外，系统开发的最终结果只能达到有限的目标。
因此，双方应详细制定系统最终实现的目标，切不可用一些简单的术语来笼统概括需求，例如：“实现办公自动化”、“建立现代化的miS系统”这种抽象的术语只能将用户对miS系统的理解引入误区。
总之，用户方与开发方的关系是项目管理所要处理的最重要的关系之一，增加沟通和减少误解是处理好这个关系的关键。所以项目管理人员要有效地安排开发方软件人员与需求方使用人员的交流，保证有畅通的交流渠道。在交流中用户方要尽量避免含糊不清的需求，而开发方要杜绝敷衍了事、得过且过的行为。
3．2 用户方项目管理人员与使用人员（业务人员）及决策层的关系
用户方项目管理人员与系统使用人员的关系是十分微妙的。一方面，miS系统使使用人员减轻工作强度、提高工作效率；而另一方面，miS系统改变了现行的工作管理模式，使使用人员失去了一定的灵活性和随意性。但是miS系统的成功与否有赖于使用人员的检验。再好的系统，如果使用人员不愿意用，也不能说获得了成功。特别是在miS系统的试运行阶段，使用人员对miS系统的使用实际上是对系统的深入测试，他们将发现许多在软件测试时疏漏的程序错误，从而有助于帮助开发方进一步完善软件功能，提高软件的实用性、稳定性及可靠性。因此，如何鼓励使用人员使用miS系统，帮助他们克服对新的工作模式的畏难情绪，也成为项目管理的任务之一。
用户方的决策人士是用户方项目管理人员领导，由于行政手段是推行miS系统使用的有力手段之一，他对项目的支持是使miS系统开发成功关键与顺利实施的保证。因此用户方项目管理人员应随时与决策层沟通，取得其鼎力支持，这也是保证软件开发、使用成功的一个致关重要的因素。
任何一种新的工作方式，均必然有其适应及完善过程，用户方的项目管理人员、决策层及使用人员必须充分认识到这一点。当出现问题时，用户方项目管理人员应迅速分析问题，正确判断哪些问题属于不适应新的工作模式引起的，哪些问题属于操作不当引起的，哪些问题属于miS系统本身不完善引起的。对于那些由于不适应新的工作模式引起的问题，项目管理人员应引导使用人员迅速适应新的工作模式，必要时也要说服用户方的决策层采用行政手段推动实施；对于那些由于操作方法不当引起的问题，项目管理人员应培训使用人员正确操作系统；而对于那些由于miS系统本身不完善引起的问题，项目管理人员应迅速与开发方协调，尽快排除系统中的错误。
在系统试运行初期，使用人员常抱怨说：“这个界面不方便，不好用”。
在软件界面设计方面，用户方管理人员应注意提醒开发方注重其实用性、简便性、易操作性，要注意现行工作模式的特点，照顾使用人员的工作习惯，以便降低系统的使用难度。这将有利于新系统的顺利实施，有助于工作方式的顺利过渡。
综上所述，项目管理人员应时刻注意取得决策层的理解与支持；要帮助使用人员尽快地适应新的工作方式，帮助他们解决使用中遇到的问题；并使系统在使用中不断地得以完善。
3．3 项目管理人员与软件编程人员的关系
项目管理人员与软件编程人员的关系处理得如何将直接影响软件编程人员的积极性。在miS项目开发中，项目管理人员经常处在两面夹攻的地位。一面是使用人员，而另一面是软件编程人员。当使用人员对系统提出问题，并要求改动时，除了最简单的界面修改外，软件编程人员往往总是找出各种理由(如影响进度、系统结构会打乱、性能会受影响等)予以否定。而这正是引起开发方与用户方矛盾的最经常的原因。
作为项目管理人员，既要满足用户方的需求变化，又要充分调动开发人员的积极性。由于系统分析不够准确，用户方业务需求的改变等诸多因素，均会导致要求开发方修改程序。作为项目管理人员应及早提醒开发方程序修改的必要性，在实际运作过程中用户方管理人员应尽早介入开发工作，及时发现问题，解决问题。在系统试运行阶段，将用户方不断提出的需求改动加以归纳整理，集中问题与开发方一起讨论解决方案。这样既满足了用户方对系统改动的需求，又不会不规则地时常打断开发人员的正常开发工作，使开发人员处于不断的修改状态而失去耐心。
3．4 硬件与软件的关系
miS系统的硬件与软件都是组成miS系统的重要部分。但目前在miS系统的建设中，却经常出现重硬轻软的情况。
据统计，目前国内用户在硬件（包括网络）方面的投资占总投资额的78％，而软件投资只占22％。确实，先进的设备、优良的技术性能有助于提高miS系统的性能。而miS系统的建设是否应追求高、新、尖、一步到位，却是值得商榷的。在计算机技术飞速发展的今天，计算机厂商不断地推出新产品，其性能价格比均极大地优于旧产品。就拿硬盘技术来举例：1994年1个GB的硬盘价格与1997年9个GB的硬盘价格相当，可见一步到位的想法是不切合实际的。同时，系统性能过多地超出应用需求实际上是一种浪费。因此，根据业务需求“统一规划、分步实施”是项目管理人员应注意掌握的原则。在规划时认真考虑业务发展、技术的进步，在实施方面，时刻要将硬件配备的重点放在设备稳定、性能可靠及可扩充可升级方面。
如果说在硬件设备方面存在不惜投入、追求一步到位的现象，那么在软件开发方面，用户方却往往太苛刻了一点。殊不知，一个好的、高质量的miS系统，是要靠软件编程人员来开发的。这里的高质量是指软件的可用性、使用的方便性以及可维护性、可升级性等诸方面，这是软件得以推广的必要条件。如果投入资金过少，必造成开发人员不能全身心地投入到某一个项目的开发工作中，当开发方认为他们的投入已与用户方的付出相当时，便不愿意继续投入精力，从而造成开发工作的虎头蛇尾。miS系统达不到预期效果，再好的硬件也难能发挥其作用。当然，由于用户方对工程组织、工程量计算、技术含量分析等诸方面开发因素估价困难，很难正确计算出合理的软件开发价格。用户方项目管理人员可以聘请有关专家、或参考同行业国内外开发情况加以核定。
在开发费的控制方面，用户方应合理运用价格这个有力武器，付款方式及付款条件要严格与开发进度、软件质量以及软件维护服务质量挂钩，使其成为督促及约束开发方的手段。
3．5 性能与灵活的关系
性能与灵活是系统设计中的一对矛盾，似乎是系统设计人员而不是项目管理人员应该考虑的问题。但实际上，由于国内的许多miS系统的失败都与这个矛盾处理得不当有关，因此，我们认为应该在项目管理中充分考虑性能与灵活的关系，随时提醒系统设计人员处理好这个矛盾。性能是系统可用性的重要因素，很难想象一个响应速度很慢的系统能得到最终用户的认可。而灵活性是系统适应变化能力的重要因素，一个无法适应工作模式变化的系统也是难以推行的。然而，根据传统的miS系统理论，增加灵活性将增加系统复杂性，降低系统性能。那么，应该如何对待这对矛盾呢？
在目前的情况下，相对系统性能来说，灵活性是矛盾的主要方面，其原因有如下两点：
3.5.1由于目前大部分单位的管理模式都处在探索阶段，可能引起变动的因素很多，因此根据现行的管理模式设计出的miS系统将面临使用单位管理模式的变化的考验。所以现在的miS系统在设计时要充分考虑这些不确定因素，灵活才能适应这些变化。
3.5.2由于计算机技术的发展，计算机硬件速度飞速提高，系统性能的极大地提高，从而增加灵活性所引起的系统性能的下降并不明显。
当听到软件编程人员说：“为了提高运行速度，我们假设某个参数是不变的”、“如果想加一种查询方式，可能要改动表结构”时，项目管理人员应引起足够的重视。提醒软件编程人员要充分考虑到用户方需求的灵活性，在软件设计中，要尽量避免用牺牲系统灵活性来换取系统性能的提高。而是应在程序设计方面通过优化程序结构来提高系统性能。