软件规模范文（精选8篇）
软件规模 第1篇
软件工程不同于一般工业工程技术。软件工程的三个基本要素是方法、工具和过程。在过去,软件工程的焦点是探索新的软件开发方法和技术来提高软件生产率和质量。几十年来计算机的发展,使人们认识到要高效率、高质量和低成本的开发软件,必须改善软件生产的过程,软件生产转向以改善软件过程为中心。事实上,软件过程的不断改进才是增进软件开发组织的能力和提高软件质量的第一要素[1]。传统的瀑布开发过程存在对需求要求明确、到末期才交付有用的产品等缺点,无法适应需求复杂多变的软件开发;而RUP是面向对象开发方法,通过迭代的开发过程逐步明确需求并通过增量的方式提交产品,成为现代软件开发的主流。本文在实践中进行RUP迭代开发,并进行软件估算的研究,第一章分析RUP开发的特点,第二章针对RUP的特点选择软件估算技术;第三章研究在RUP开发中具体的估算方法以及应用实践;第四章进行总结。
1 RUP开发特点
传统结构化开发方法采用瀑布型开发模型,开发和测试存在V模型的特点。在软件开发的早期阶段完全并且详细捕获用户的需求,依据需求进行软件的估算,到开发的末期实现并组装完整个产品才进行需求的测试。在实际开发复杂软件特别是软件人员不熟悉的领域中,想在开发早期获得完全准确的需求,几乎是不可能的;并且用户经常在开发的过程中改变需求。因此,在这种开发过程下,很难保证估算的准确性。
RUP (Rational Unified Process)由Ivar Jacobson的The Objectory Approch和The Rational Approch发展而来,吸收了多种开发模型的优点。RUP软件开发生命周期是一个如图1所示二维的软件开发模型。横轴通过时间组织,分为4个状态:初始、细化、构造和交付,每个状态由多次的迭代构成,每次迭代过程都具有展开的生命周期特征,体现开发过程的动态结构;纵轴是以工作流为内容的逻辑活动,体现开发过程的静态结构。其中各个条纹形状的渐变表示各项工作量所占比重的变化趋势。
与传统的瀑布方法相比,RUP的软件开发过程有两个重要的特点:一是以用例驱动的方式进行开发,用例是一种用户容易理解的需求描述工具,并且RUP与UML(Unified Model Language)具有良好的集成以及多种CASE工具的支持,可以快速建立需求的可视化模型,有利于开发者和用户之间的沟通;二是以迭代方式进行开发,每次迭代都提交可运行的产品并测试,需求能够在迭代过程中不断被检验和修正。
2 RUP开发的软件估算技术
2.1 RUP开发软件估算技术选择
软件估算[1]就是通过对软件项目的规模、工作量、进度、关键计算机资源进行科学的预测。所有估算活动中,软件项目规模的估算是基础。目前常用的软件规模估算技术,有代码行、功能点、用例点等。其中代码行技术与实现有关;功能点技术有不断完善的规范,独立于程序设计语言和整个软件生命周期使用的技术和工具,得到广泛的应用。但是功能点方法是基于面向过程的开发方法,而RUP方法是以用例为驱动的面向对象的开发方法。许多研究者对功能点方法如何应用在RUP进行研究,如文献[2]研究从用例中提取功能点的各个要素并计算功能点,但是功能点方法没有体现出面向对象开发的特点;有些研究者提出了基于面向对象开发的其他度量方法,如文献[3]提出“类”点分析法的规模评价模型,但是“类”在设计阶段中产生,而软件规模的估计应该在需求阶段进行,并且“类”的描述面向设计人员,不适合作为与用户进行交流的描述工具。
软件估算在项目早期需求业务建模阶段进行,而用例是面向对象开发中应用广泛的需求描述技术。RUP就是通过用例来描述需求,开发过程以用例为驱动。用例点方法[4,5]是Gustav Kamer在1993年提出的,是基于用例估算软件项目规模及工作量的一种方法,简称UCP(use case point method)。UCP方法是对功能点方法上的改进,但又与功能点有着本质的不同。它的基本思想是利用已经识别出的用例和角色,分析它们的复杂度并进行分类,并结合技术和环境因子计算用例点。文献[4,5]中通过各种实验,将用例点方法的估算结果与专家估算结果以及实际情况进行比较,都表明了用例点方法估算的结果准确性超过专家估算结果。
2.2基于用例点的软件规模估算方法
用例点计算方法是:首先根据基于用例分析角色复杂度和用例复杂度,分别计算角色权重UAW和用例权重UUCW,然后结合技术因子TCF和环境因子EF计算出系统的用例点。
2.2.1角色权重UAW的计算
在各个文献中,角色复杂度的分析基本一致,也就是基于用例找出系统的所有角色,对其中每一个角色根据表1分析它与系统之间交互的复杂程度,并将其归类为简单、中等、复杂三个类别之一。
假设一个系统中共有sa个角色,其中三种类型角色的数量分别为sai(i=1,2,3),那么可以用公式1计算UAW:
2.2.2用例复杂度的计算
各种文献中对用例复杂度的度量方法并不一致,例如文献[6]基于用例活动图中所使用的判断结点、同步结构、循环结构等特殊结构来判断用例复杂度;文献[7]基于系统实体个数来判断用例复杂度;文献[8]基于系统顺序图分析事务的个数来判断用例复杂度。经过仔细分析,用例活动图除了描述系统做什么,也描述了怎么做,结构复杂;实体需要综合分析各种需求因素才能获得。因此用例活动图和实体在需求阶段的早期都较难准确给出。而系统顺序图是利用用户的领域语言描述一个特定场景发生的事件以及顺序,是与用户交流的一个良好的图形工具,因此准确性相对容易保证。从系统顺序图中可以抽取出事务,所谓的事务定义为一系列任务(事件)的原子集,这些事件要么一起完全执行,要么一起均不执行。一个用例图中包含许多事件,一个事务可能包含其中的一个或多个事件。在RUP早期建模阶段,根据用例说明和系统顺序图可以较方便地分析出一个用例的事务数量[8]。因此,本文采用分析用例事务个数的方法来区分用例的复杂度。具体的过程是:首先分析用例中包含的事务的数量,然后根据表2的判断规则,将用例归类为简单、中等、复杂三个类别之一。
假设一个系统中共有sc个用例,其中三种类别的用例数量分别为scj(j=1,2,3),那么可以用公式2计算UUCW:
2.2.3技术复杂度TCF和环境复杂度EF的计算
用例描述的仅仅是行为(功能)需求。然而规模估算时,非功能性需求以及项目风险对于项目规模的影响也是很大的,忽略了它们,会造成严重的低估。非功能性需求归纳为技术和环境两个方面[6,7],技术方面分解为13个技术因子,环境方面分解为8个环境因子,分析其中每个因子与系统的相关性,计算出技术复杂度TCF和环境复杂度EF。
根据上述计算出来的数据,利用公式3计算系统的用例点。
3 RUP迭代中用例点的估算过程及实践
图1表明,RUP的开发经历了初始、细化、构造和交付,整个系统的估算在初始阶段开始,在细化和构造中不断调整。RUP采取迭代增量产品的开发过程,因此估算用例点不是基于整个系统,而是基于每次迭代完成的子系统来估算,然后估计每次迭代完成的子系统的用例点,最后累加估算出整个系统的总用例点。
设估计开发过程分成n-1个子系统迭代开发,为实现这n-1个子系统需要迭代n-1次,设估算第i(i=1..n-1)次迭代实现第i个子系统的用例点为ucpi,则系统总的用例点为式(4)。
RUP开发是在迭代过程中不断地进行需求的验证,用户也可能在迭代中改变需求。因此在实际开发中,除了第1次迭代,其他每次迭代要完成两个工作:一是实现新系统,二是修正前期迭代过程可能出现的错误。因此实际总的迭代次数为n次,第n次迭代主要进行错误的修正。
前期迭代过程可能出现的错误包括需求方面的错误和设计方面的错误。在这里开发员对需求的理解错误以及用户改变需求都统称为需求方面错误。本文假设在开发过程没有出现设计方面的错误,只考虑需求错误。表3表示实际开发过程中这两项工作的用例点。
表3中(i=1..n),表示第i次迭代实现新子系统的用例点,且表示第j个子系统在第i次迭代修正错误后重新计算的用例点,αij表示第j个子系统在第i次迭代中需要修改的比例。一般情况下,在迭代前期,需求不稳定,αij比较大,但在后期,需求相对稳定,αij的值逐渐减少,甚至为0。因此迭代开发中总的用例点为式(5)。
在初期估算过程中,αij的值难以估算,为简单起见,可以将利用公式3计算的系统总用例点乘以一个比例值α来估算修改所需的用例点,α的具体值与开发团队的开发能力有关,需要根据历史数据来估计。以“连锁超市管理系统”的RUP开发实践为例,在初始阶段,估计了该系统要完成3次子系统,分别在3次迭代中实现,估算总的系统用例点sucp为3 353.05,因为缺乏历史数据,暂时取比例值α为0.3,估算修正的用例点为3 353.05×0.3=1005.9,总和为4 358.95;实际开发迭代过程的用例点如表4,总和为4 490.7,误差3%。
4结束语
软件的产品质量需要过程来控制,RUP的迭代开发是现代主流的开发过程,这个过程如何进行软件规模的估算,我们进行了初步的实践,积累了一些经验。很多工作还需要在后续中进一步研究:如修正错误的比例值α需要历史数据的积累;本文只考虑了需求方面的错误修正,实际开发中还可能出现设计方面错误,这方面的错误的用例点如何计算等等,这些都需要在后续工作中进一步研究。
摘要：RUP的开发具有迭代、以用例为驱动的特点,是现代软件开发的主流。UCP是基于用例的软件规模估算技术。应用RUP进行实践开发,通过估算迭代次数,并应用UCP估算每次迭代开发的新系统用例点和修正旧系统用例点,从而估算系统总的软件规模。
关键词：统一软件过程(Rational Unified Proeess,RUP),用例点,规模估算,统一建模语言(Unified Modeling Language,UML),迭代
参考文献
[1] Laird L M,Carrl B M.Software measurement and estinmation:a practical Approach.IEEE Computer Society,2006
[2]郑明辉,周慧华,马光致.基于UML需求分析模型的软件规模估算方法.计算机应用与软件,2004;3:23-25
[3]张桂珠,须文波.构建面向对象系统规模评价模型.计算机应用, 2006:2:439-441
[4] Banerjee G.Use case estimation framework.Annual IPML Conference, 2004:1-12
[5] Anda B,Angelvik E,Ribu K.improving estimation practices by applying use case models.Springer-Verlag Berlin Heidelberg,2002; 383-397
[6]王悠,张熙.用例驱动的软件复杂性度量及应用,计算机工程与设计,2007;6:2542-2546
[7]彭英.软件成本估算模型的研究与应用.长沙:中南大学,2007
软件规模 第2篇
一、软件名称：
网上外卖订餐系统
二、软件性质：
本软件系统实现的是网上外卖的应用系统。使用面向对象的开发过程。开发中使用java语言。本软件主要使用了UML进行面向对象的设计和建模。利用面向对象的思想，从项目需求分析到系统设计，画了大量UML模型。更加直观具体地体现了本系统的功能亮点。
三、软件规模：
本系统的开发人数为四人，属于小型的软件系统，开发目标代码在两千~五千行。开发周期为两周。
四、软件要实现的目标：
本系统主要针对高校的外卖订餐流程和对订单处理实行信息化而构建出来的网络平台，学生通过浏览器上网访问订餐网站可以实现网上浏览菜式和订餐功能，店员通过后台管理登陆实现对订单的处理，通过信息化处理给学生订餐带来方便更给外卖店管理人员带来了长远利益。
五、题目来源、选题背景
进入21世纪以来，餐饮行业以年均20%的增长速度，成为国民经济中的发展最快的行业之一。随着人们生活水平的不断提高，人们甚至想要不出门就能吃到可口的饭菜——这就是外卖。在我国高校内餐饮行业外卖行业更是发展最快的一个行业，在内蒙古科技大学每年都有几间新的外卖店的产生。外卖订餐已经成为内蒙古科技大学学生生活中不可缺的一部分，而订餐的方式也随着学生们的要求提高，不断的多样化和成熟化。
依靠电话订餐是目前最主要的订餐方式，使用电话订餐方式有不少的缺陷，比如：时效问题、打电话的成本等等。目前内蒙古科技大学外卖订餐行业的现状分析如下：
1)外卖店数量众多，各店竞争较大。
2)外卖店多数实行人工方式订餐，即打电话订餐登记。这种订餐方式造成订餐很不方便特别在订餐高峰期，经常出现打电话打不通的现象。
3)外卖店多数没有实行市场分析，一些菜式在顶峰期出现缺菜现象，而一些菜式却出现积累现象，造成了资源的浪费和经济损失。
4)外卖店没有对外卖进行财务管理，造成对店内资金管理不明确和店员滥用资金的可能。
5)无法为店内管理层提供准确的决策信息，掌握及时的市场消息。
软件百强沧桑巨变 规模仍是软肋 第3篇
当很多软件企业还在为跨
入10亿元俱乐部而努
力的时候,中国软件业务收入迈过100亿元门槛的企业总数达到了3家—华为、中兴通讯和神州数码。
这是5月底工业和信息化部公布的2010年(第九届)中国软件业务收入前百家企业名单显示的。前100家企业共实现软件业务收入2448.7亿元,比上届增加了409.2亿元。
工信部从2002年开始第一届软件百家企业的评选。近9届百家企业的平均更新率达到25%,显示出中国软件业的激烈竞争和沧桑变化,单个软件企业规模普遍偏小、抵御风险能力不足,是名单不断变化的重要原因。
入围门槛不断提高
本届百家企业入围门槛为3.96亿元,比上届增加了8545万元,提高27.3%,其中超过10亿元的企业有43家,远远多于2002年第一届的12家。其中,前10家企业的软件业务总收入为1515亿元,在百家企业总收入中的比重高达61.9%,显示出行业较高的集中度。
2002年～2010年,百家企业的入围门槛逐年提高。2002年的入围门槛只有9200多万元,相比之下,2010年的百家企业入围门槛比2002年翻了两番,年均增幅超过3500万元。
虽然华为连续9届都位列百家企业的首位,具有很高的稳定性,但百家企业的名单更新调整仍然很快,软件产业竞争的激烈可见一斑。工信部的统计显示,9届百家企业平均更新率达到25%,第八届名单中的13家企业因收入达不到本届门槛而退出,另有5家企业因亏损或转产、重组等原因退出,典型代表就是以MP3芯片风靡一时的炬力集成电路设计有限公司。
在众多企业中,排名靠前的企业稳定性较好,第一届百家企业的前30名企业中,仍有19家企业在最新一届的百家名单中。那些从名单上消失的企业包括托普集团、波导股份、UT斯达康、湖南湘计信息软件股份有限公司等。UT斯达康甚至曾在2006年百家企业名单中名列第四,软件销售收入高达到59.86亿元,如今明星陨落,令人唏嘘不已。
规模相对较小的企业调整较快,第一届百家企业的后20家企业中只有3家企业仍在最新一届的百家名单中。记者对比名单后发现,2002年排名83位的国电南瑞科技股份有限公司,在最新一届名单中被纳入到南京南瑞集团公司统一计算,后者以34.50亿元位居12位; 2002年名单中列97位的泰豪信息技术股份有限公司则被同方股份有限公司收入麾下,同方股份2010年收入40.71亿元,位列第10; 2002年位居81位的长春一汽启明信息技术有限公司,以启明信息技术股份有限公司的名字位列2010年名单的32位,收入从2002年的1.08亿元增加到13.16亿元。
做大做强
仍是重要课题
9年来,中国软件业取得了喜人的成绩。2009年,我国软件服务业完成软件业务收入9513亿元,占电子信息产业的比重由2001年的6.3%提高到2009年的15.6%。不过,中国软件业整体并未摆脱“中小企业集团军”的形象。即便最新一届百家软件企业的总收入达到了2448.7亿元,这个数字也无法与微软、IBM等跨国软件企业的单体规模相提并论—2009年IBM实现营收958亿美元。
由此可见,增强企业的自主创新能力、做大做强仍是中国软件企业的重要课题。
如何做大做强?新一届百家企业名单体现出中国软件企业的两大发展趋势:一是企业的国际化步伐加快,服务外包能力不断增强。据了解,本届百家企业出口超过110亿美元,占全行业出口的半数以上,其中外包出口超过10亿美元。查看2010年百家企业名单,知名的软件外包企业就有浙大网新、东软集团、软通动力、大连华信、文思创新等企业,而华为、中兴、浪潮、方正等前10强企业也都有软件外包等出口业务,海外市场在华为总收入中的比重甚至高达60%～70%。
另一个趋势是通过兼并重组做大企业规模。据不完全统计,2009年国内披露出来的大型软件企业并购案超过40起,涉及总金额超过16亿美元,比上年增长100%以上。其中,联创和亚信的合并是近年来国内软件产业最大的并购案,涉及金额达到7.3亿美元; 用友、金蝶、中软国际等企业也在国内针对行业软件展开了数起并购,以增强自身的核心竞争力; 东软集团则将并购的触角伸向了海外,继2009年以1200万欧元收购芬兰SESCA旗下三家嵌入式开发的子公司后,今年又以600万欧元收购全球汽车导航软件提供商ISG的相关业务。
两化融合的新机遇
面对困扰中国软件业多年的规模不足问题,中国软件业正在不断探索,寻找市场机遇。
9年来,百家企业的收入构成中产品类收入逐步降低,比重由第一届的70%降为第九届的57%; 服务类收入不断提升,比重由第一届的4%上升为第九届的10%,软件服务化的趋势非常明显。在应用行业上,则由最初的以通信行业为主向金融、交通、能源、工业控制等多个领域并重转化,系统集成由通用型计算机网络集成向行业解决方案转化,软件附加值日益提高。
在最新一届百家企业名单发布时,工信部总经济师周子学向中国软件企业提出了几点建议,比如抢抓产业发展的新机遇、提高自主创新能力、积极开拓国际市场等,而他最后强调的,就是中国软件企业要坚定不移地走两化融合道路。
国内巨大的信息化市场为软件产业创造了重要的发展机遇,两化融合战略既给软件服务业的发展提出了新的要求,也为其创造了更加广阔的内需发展空间。两化融合蕴藏的嵌入式软件机遇和行业解决方案机遇,或许将成为中国软件业的突破口。
面向中小规模软件的需求分析方法 第4篇
“软件危机”自上世纪60年代提出以来,至今仍没有彻底解决问题,而根据权威统计分析显示,软件项目的失败大部分就是源于需求问题。鉴于需求阶段是软件开发的初期,一个重要课题就是如何为软件的开发奠定一个稳固可靠的根基。
1需求调研
开发任务下来后首先是组织开发团队,在明确目标任务后,就要开始了解需求。这个阶段要求形成一个需求调研文档。开发方与用户方如何进行有效地沟通是重点。
1.1调研人员素质要求
如果调研人员里面有一个即了解业务又懂技术的人为调研过程做“翻译”是最好不过的,但是不可能总有这么一个人存在,于是就只能靠双方的有效沟通。所以,在需求调研的时候,对开发方的语言表达能力、沟通能力、领悟能力都有较高的要求,要积极引导用户表达出具体要求,还要善于挖掘用户的需求。
1.2图表解读法
图表解读是调研过程中非常实用的一种方法。因为基本上任何业务都有图表要求,包括各种各样的信息打印、统计结果表,实际业务中绝大多数的概念、信息都包含在这些打印图表上。
1.3图表解读实例分析
从表1可以得出一些明显的信息采集点,而这些信息采集点就是组成数据表结构的基础。
1.4编写需求调研报告
每次调研需求后,需要将需求分类整理,分为容易实现的需求,可以实现的需求,较难实现的需求,暂时不能实现的需求,根本不可能实现的需求,下次与用户讨论时展示给用户看。最后整理双方多次交流时记录的所有信息,完成需求调研文档的编写。
1.4.1需求调研报告的内容
需求调研文档一般来说是简单的功能描述性文字,主要内容是编写系统要实现哪些功能。
比如,前面介绍的学习进度输出报表,可以用表2来描述它的输出功能。
1.4.2需求调研报告的作用
与用户的沟通不可能一次完成,在编写需求调研文档的时候肯定会遇到很多模糊不清楚的地方,整理出来将问题集中,再约定双方进行商讨,直到问题全部得到解决。最后形成正式的需求调研报告,要求用户仔细阅读并签字。签字主要就是明确一个责任,可以督促双方在这个阶段将需求做得尽量地仔细和完善。当然,任何看似完善的需求都经不起时间的考验,业务本身就是多变的,在整个开发周期中都不可能保证用户的要求不发生变化,用户随时可能增加和改变要求,这就是需求变更的问题。所以前期的需求调研越仔细今后的变更就可能越少。一个好的需求调研文档并不是要求做到没有变更,而是在主要的功能结构上没有变化,今后可能的变更不会影响到结构或流程的变化。用户在需求调研文档上签字的目的也是一种责任,需要用户对当前流程和主要功能的确认。用户可能会不愿意签字,这时候还需要开发人员有一定的心理分析能力和谈判技巧去说服用户,得到用户签字后的需求调研报告才是一份完整可行的报告。需求调研报告是写给用户和软件设计人员看的,它必须要明确软件需要做什么。
1.5非功能性需求调研
调研阶段,除功能性需求外,还应该考虑非功能性需求,非功能性需求它不一定是解决“我想要我的系统实现这种功能”,而是解决“如何使这个系统能在实际环境中运行”,还可以包括产品必须遵从的标准、规范和约束以及操作界面的具体细节和构造上的限制。
前年开发一个工资软件,最初因为考虑到用户分散在几个校区,部分操作人员的技术水平有限,选定了BS模式,最后交件的时候,一位关键用户因为习惯于EXCL的操作,且喜欢以前CS模式老软件的窗口控件提供的灵活的操作界面,对于在这方面稍显笨拙的网页界面就感到了操作上极大地不方便,在他的强烈要求下,开发人员不得不为他所涉及到的相关模块重新开发了一套基于CS的程序。这个教训就是,要了解尽可能多的用户和潜在用户群,不同用户在操作上的要求肯定不太一样,哪些是关键用户、哪些是次要用户,在需求调研的时候就应该注意用户的特定要求,为后面的系统框架的设定和开发工具的选择准备参考意见。
2.2实例演示
2.2.1数据表关系
画出主要模块菜单的层次结构关系,一般给出系统前两级的菜单模型,下面以一个较简单的但在操作上有较强顺序要求的“学生信息系统”为例,其主要功能模块设计如图1。
2.2.2模块功能概要说明
对每个主要菜单的功能做概要描述。如图2。
2.2.3程序流程图
绘制顶层程序流程图,如图3。
2.2.4系统概念及定义
对系统中使用的一些专业化的名称做说明,比如系统中的默认信息、公用信息、系统基本专业术语的解释等(如图4)。
2.2.5系统构架和开发工具的选定
充分调研用户的需求而决定,用户的范围、技术基础等都是参考对象。
2.2.6数据结构设计
打开前一阶段的需求调研报告,将里面所描述的需要采集的信息点进行分类整理,利用专业工具诸如Power Designer进行数据库的设计,设计完成后导出每个表的结构,再分别对每个表上的操作编写详细设计和算法。
表一般包括表名、表结构、功能说明、流程设计、输出报表、操作界面等。表结构即字段定义、字段意义、关键字定义、键定义等信息;功能说明描述该表上的所有操作,即将调研阶段的功能具体细化到每个操作,这部分是需求设计的重点,期间还可以将关键算法的设计编写出来;流程设计即以图的方式画出该表与其他表的关系;输出报表则设计出所有有关的报表样式。
需求分析文档主要是给开发人员看的,是代码编写人员的直接指导型文档,也是测试人员的重要参考依据,因此分析文档的编写要周详、描述要准确,一般是采用自然语言与伪码相结合的方式,怎样书写能最清晰地表达程序的功能就怎样写,某些复杂的地方甚至可以写成编程代码让程序员直接使用从而避免“翻译”过程中出现错误。
还是以“学生信息系统”的“电子注册用户”表为例,详细设计如图5。
可见,在功能设计的编写上,必须明确各个操作对数据信息的影响,详细到让一个不懂业务甚至不要求了解整体流程的程序员都能按照这个分析文档开始代码的编写,他只需要按照系统定义及标准、按照指令编写代码,因此需求分析文档写给设计人员和编码人员看的,必须要明确软件需要怎样做。
2.3提前感知用户的需求
一个有经验的分析员要善于挖掘用户的潜在需求。在交流的时候要善于启发用户,捕捉看似无关的信息,提前感知用户的需求,使自己处于主动地位。
例如在就采集学生平时成绩的谈话快要结束的时候,某用户感叹“现在教学部门在抓学习过程,说不定今后会加强对平时成绩的考核,除了平时作业,还要加强对上机、实验、网上讨论等学习过程的的考察,让这些指标也作为综合成绩的一部分”。对于这句话,敏感的分析员可以提取的信息是,在不久的将来,平时成绩可能要包含多个内容,而刚才讨论只有一个平时成绩的设计就不能满足发展的需求了,必须为今后的发展做可扩充性设计,但是如果现在就设计成多个环节成绩的采集又会增加录入人员的负担,毕竟多个项目只是设想,即便实现也可能只针对部分课程,那么如何设计呢?考虑两种情况,最后分析员采取了多项成绩内容的设计方案,操作上可有用户自行选择单个或多个录入的方式,如图6所示。
如图6中A图所示,系统默认只有“成绩1”这一列的录入框有效,对于当前只有一个成绩来说用户不需要改动任何设置,如果今后出现多个成绩要求录入,用户根据实际情况点击“成绩X”让该列的录入框可见即可,见图6中的B图。
2.4必须考虑业务环境
设计数据结构、算法的时候,还有一个重要的因素要考虑,那就是“业务环境”。常常遇到这样的情况,当用户反应软件不能正常使用的时候,开发人员在自己的机器上模拟时却没有任何问题,到现场才发现这样那样的原因。
一个真实的例子,在最初设计学生学籍管理软件的时候,开发人员为了保证数据的绝对准确,基本上没有设计任何冗余信息字段,在算法上使用了相当多的关联语句,测试没有问题,但是在实际使用中,由于信息量的庞大导致系统的运算速度极慢,很多功能根本无法完成,无奈之下,只得对若干数据表进行重新设计,增加一些冗余信息字段,虽然可能出现某些数据不一致的情况,但在某些对数据严格性要求不太高的环节不会造成坏的影响,相反必要的冗余信息还可以帮助业务人员追查历史。因此如果缺乏对业务场景的了解,又如何能够真正理解需求呢?断了“业务环境”之章,必将导致取出的“需求”之义有所偏差。
2.5需求变更问题
需求分析报告编写完成后,开发人员可以按照这个文档开始代码的编写了。但需求可能随时发生变更。需要注意的是,任何变更,必须立即通知需求分析人员,因为只有编写分析报告的人才最熟悉整个系统的结构和数据之间的关系,才能分析出这个功能的变更可能影响到的其他功能,从而站在系统全局的角度再次对变更的功能进行设计。
3总结
最后总结一下需求阶段需要做的事情:组织一个具有较强沟通能力、表达能力、领悟能力和敏感度高的调研小组;与用户一起讨论系统功能,形成需求调研报告;分析系统使用环境、细化功能模块,设计系统架构、程序流程和数据结构,形成需求分析报告;需求变更要立即通知需求分析人员。
2.1需求分析报告的内容
需求分析主要包括的内容有:总体功能描述、功能描述及数据表关系、程序流程图、系统概念及定义、系统构架、开发工具、数据库设计、功能详细设计及算法等。
2需求分析
需求调研阶段所占的时间大概只是整个需求分析阶段的1/4,大量细致的工作在编写需求分析文档上。需求分析以调研报告为基础开始编写。这个过程是一个将用户的业务逻辑转化为程序逻辑的过程。
参考文献
[1]徐锋.软件需求最佳实践:SERU过程框架原理与应用.电子工业出版社.2008.
[2]Suzanne Robertson,James Robertson.Mastering the Requirements Process(2nd Edition).Addison-Wesley Professional王海鹏译.掌握需求过程.人民邮电出版社.2007.
[3]Stephen Withall.Software Requirement Patterns.Microsoft Press曹新宇译.软件需求模式.机械工业出版社.2008.
软件规模 第5篇
《软件工程功能规模测量NESMA方法》标准主要以现有国家标准及国际权威文献为参考,并结合国内软件功能规模测量的发展现状非等效采用了国际标准ISO/IEC 24570:2005《Software engineering-NESMA functional size measurement method version 2.1-Definitions and counting guidelines for the application of Function Point Analysis》(软件工程NESMA功能规模测量方法版本2.1 使用功能点分析的定义和统计准则)。在标准编制过程中,编写组通过研读相关国内外参考文献,听取各方专家意见,对原标准内容进行了适度的修改完善,并重新编排章节,使得最终完成的行业标准结构清晰,核心内容突出,更加具有实施的可操作性。
本标准原立项名称为《软件工程NESMA功能规模测量方法版本2.1 使用功能点分析的定义和统计准则》,后变更为《软件工程功能规模测量NESMA方法》。
2 编制背景
随着国内软件行业的蓬勃发展,行业各方迫切需要在软件规模测量方面达成统一认识。为此,在工信部软件与服务业“十二五”规划中,“强化标准体系建设与推广”部分提到标准重点工作之一是制定实施测试评估标准。在软件规模测量方面,国际标准化组织(ISO)已经采纳了多种软件规模测量方法作为标准,为了促进国内软件行业的健康发展,提升我国软件开发项目估算水平,迫切需要借鉴国际标准,并结合我们自己的实践,尽快建立起软件规模测量方面的国家或行业标准。
NESMA分析方法作为一种主流的功能规模测量方法已经在各行业得到广泛应用,并已经形成ISO/IEC 24570:2005。为满足行业发展需要,响应工信部“十二五”规划要求,有必要尽快引入此标准,指导国内软件规模测量方面的国家或行业标准的制修订。
3 主要内容
本标准对ISO/IEC 24570:2005 进行了非等效采用,重点阐述应用程序及项目功能点规模测量方法,以及围绕此方法所涉及的概念和方法的介绍。对于具体的功能点计数方法,可参考另一正在报批的行业标准《软件工程软件功能规模测量方法功能点计数》。本标准主要内容包括:
● 功能点分析方法概述。简要介绍了功能点分析方法所涉及的主要概念,如功能点计数、功能复杂度、功能点统计、功能类型、计数范围和边界等;
● 通用统计准则。给出了一个适用于功能点计数的通用统计准则,并分别从特定的视角给出了通用的功能点分析准则。使用该准则可以确保功能点计数的一致性,以最大程度地降低因测量人员不同而造成功能点计数的误差;
● 应用程序功能点计数方法。给出了确定应用程序边界的准则,这有助于框定应用程序功能点计数的范围。对于全新应用程序、修改的应用程序以及重建的应用程序的功能点计数方法分别给出了具体的说明和实施步骤;
● 项目功能点计数方法。给出了确定项目功能点计数范围的准则,这有助于框定项目功能点计数的范围。对于功能开发项目、功能完善项目以及替换应用程序时的功能点计数方法分别给出了具体的说明和实施步骤;
● 功能点分析的具体实施步骤。指明了项目功能点计数和应用程序功能点计数的关系,并给出了功能点分析的具体实施步骤,具有很强的可操作性;
● 通用系统特征影响程度定义。给出了通用系统特征影响程度(具体量化分值)的详细定义。
4 与ISO/IEC 24570:2005 的主要差异
在本标准的编制过程中,标准编写组召开了多次专家研讨会,专家们从各自不同的角度对本标准的内容提出了修改意见和建议,确保了标准的通用性和合理性。通过分析研究并在与国内相关标准进行比较分析的基础上,我们发现原ISO/IEC 24570:2005 的内容过于庞杂,且和另一行业标准《软件工程软件功能规模测量方法功能点计数》在具体的功能点计数方面有较多的雷同之处。针对这一主要问题,标准编写组对原标准的结构进行了较大幅度的修改,重新编排后的标准内容更加突出重点,结构更加清晰。本标准着重阐述NESMA方法核心的应用程序功能点计数方法和项目功能点计数方法,并针对这两种方法所涉及的功能点分析的基本概念、通用统计准则及通用系统特征影响程度都作了具体阐述。
本标准与ISO/IEC 24570:2005的主要差异说明如下:
(1)原标准名称为“Software engineering- NESMA functional size measurement method version 2.1-Definitions and counting guidelines for the application of Function Point Analysis”,为与我国同类标准名称一致且突出本标准的核心内容,将本标准的名称改为《软件工程功能规模测量NESMA方法》;
(2) 原标准中的前言、介绍、第1 和2 章的内容因和本标准关系不大而未予采用;
(3) 原标准第3 章的内容是对功能点分析的概要介绍,为有助于读者对本标准的理解,基本予以采用并做适当修改;
(4) 原标准第4 章的内容和附录C有较大的雷同,且附录C则更加具有实用性,更能体现本标准的核心思想,因此本标准的第5~7 章主要采用附录C的内容;
(5) 原标准第5 章的内容从多个特定的视角给出了非常具体的功能点计数的通用统计准则,但由于其内容繁多,不利于体现本标准编制的核心思想,因此仅保留了和本标准关系密切的4.1~4.6 节;
(6) 原标准第6~11 章具体描述了软件功能规模的各组成部分的准则与《软件工程软件功能规模测量方法功能点计数》有一定的雷同,同时也非本标准的核心内容,因此未被采纳;
(7)原标准附录A的内容主要用于评估功能类型,与本标准的核心思想不相符,未予采纳;
(8) 原标准附录B的内容为词汇表,主要是对原标准中出现的重要术语给予定义和解释,本标准的部分术语定义也沿用了其定义;
(9) 原标准附录D的内容为通用系统特征的介绍,其对14 个通用系统特征和值调整因子作了详尽描述,本标准主要采用了其对通用系统特征的概要介绍以及值调整因子的算法,用其对每个通用系统特征的详细阐述内容修改采用为附录A。
上述涉及到标准内容见表1 所示。
5 结语
本标准充分研究了国际标准ISO/IEC 24570:2005及国内外相关标准,提出了一种切实可行的软件工程功能规模测量方法——NESMA方法,顺应了当前软件功能规模测量方法的发展现状和趋势,为实施软件功能规模测量标准化管理奠定了基础。
本标准为规范我国软件行业的功能规模测量方法提供了参考,丰富和完善了软件功能规模测量方法,对软件项目的工作量估算、成本预算编制具有指导意义,同时也是提高我国软件开发项目估算水平的需要。
本标准符合现有GB/T 18491.1-2001《信息技术软件测量功能规模测量第1部分:概念定义》中对于功能规模测量的概念定义,可在掌握功能点计数方法的基础上使用,并且可用于所有类型的软件项目开发。
摘要：介绍了电子行业标准《软件工程功能规模测量NESMA方法》的编制背景、制定意义和主要内容,重点分析了与非等效采用的国际标准ISO/IEC 24570:2005的主要差异,包括非核心内容的删减、规模测量过程方法性的概括和提炼、更加合理的章节内容重新编排等;同时对标准实施的产业化前景和预期收益进行了分析。
浅谈大规模定制的软件开发模式 第6篇
随着我国经济发展以及软件技术进步, 软件开发市场竞争日趋激烈。为了满足客户个性化定制需求, 适应软件市场业务变化, 软件开发模式亟需转变。然而由于我国软件行业起步晚, 不少的软件开发还处于手工劳动阶段, 软件开发模式往往是针对单一用户的具体需求, 由单个产品来组织的。大规模定制作为一种全新的生产模式, 在软件开发中逐渐得到重视。所谓软件大规模定制就是将个性定制软件产品的生产问题通过构件重组和过程重组, 或将部分转化为构件的规模复用问题。
1 面向大规模定制的软件模式
大规模定制 (Mass Customization, MC) 是一种将企业、客户、供应商、员工和环境融合起来, 通过系统的思想统筹, 利用整体优化的方式, 使企业的各种资源得到有效利用。同时在标准技术、信息技术等的支持下, 以客户个性化需求为导向, 向市场提供定制产品和服务的生产方式, 这种方式实现了生产的低成本、高质量和高效率。在大规模定制的思想指导下, 软件开发的软件产品部件要满足多样化的业务需求, 同时企业能够随着市场需求的变动不断调整业务, 软件产品体现出更强的柔性和可定制性。从软件产品的特殊性上看, 我们可以将软件开发模式分为标准成品软件开发模式和单个软件定向开发模式。就标准成品软件开发模式来说, 这种模式主要面向的是大规模客户群体, 软件产品的开发和销售体现出成本低、交货迅速等特点, 但是如果满足特殊客户需求的集成一级修改成本将会很高。就单个软件定向开发模式来说, 以客户需求为导向, 组织软件开发过程, 使软件产品充分满足客户需求。但这种软件开发模式往往需要投入较大的开发成本, 而且软件开发周期较长, 且可维护与可升级性较差。而在大规模定制的思想指导下形成的面向大规模定制软件开发模式, 能将标准成品软件开发模式和单个软件定向开发模式的优势结合起来, 不仅可以降低软件开发成本和周期, 而且能够快速响应客户个性化需求。面向大规模定制软件开发模式集合了领域工程、基于构件的软件工程和并行工程思想, 并借助系统理论, 从全局角度出发, 充分利用企业资源, 从而实现大规模软件生产, 同时满足个性化软件产品需求。
2 面向大规模定制的软件开发模式下的软件产品族
要实现面向大规模定制的软件开发模式, 就需要可定制的软件产品族模型。因此, 在应用面向大规模定制的软件开发模式中, 应注重对软件产品族结构的软件设计方法研究。在进行软件开发时, 不能单单设计某一个产品, 而需要从全局角度考虑, 需要同时完成一组产品的设计。换言之, 就是在进行软件产品设计时, 要对整个产品族进行综合设计, 设计出能够面向产品族, 且能够被定制的领域框架和可重用构件。与此同时, 需要采用并行工程的观点, 将影响软件定制的约束条件和机制考虑进来, 集成并行地进行产品族和定制过程设计, 使软件产品开发时间缩短, 降低软件开发成本, 并满足客户个性化需求。软件产品族是一系列相似产品的统一表达, 是一具体领域软件产品集合。一般说来, 软件产品族由领域框架、构建、定制过程等几部分组成。在软件产品族中, 从用户需求到软件产品最终成形, 需要建立业务模型、技术模型和实现模型。三个模型里的各层关系以及各模型之间是一个生成、推导和约束的关系。从业务模型来说, 主要是以市场需求为导向, 建立起业务对象、业务过程、业务服务等语意模型, 在软件产品族体系结构中, 建立起领域框架业务模型和构件业务模型。从技术模型来说, 建立起技术层面上的领域框架技术模型和构件技术模型。从实现模型上看, 建立起实现技术模型的物力系统描述, 从实现技术层面上, 建立起领域框架技术模型和构件技术模型。
3 面向大规模定制的软件开发模式下的软件产品线
面向大规模定制的软件开发模式的软件生产最终是通过软件产品线实现软件的生产。产品线系统 (Product Line Sy Stem) 是产品开发组织方式[5]。产品线是基于相同产品价格条件下提高软件开发企业的竞争力的一种方式。产品线的生产能力涉及的内容非常广泛, 不仅包括产品生产技术方法, 而且涉及经济、组织、管理、过程等诸多方面的内容, 只有将这些方面进行综合考虑, 才能建立起高效的产品线。由于一个产品线是在一组共同设计和标准下进行软件产品生产, 因此建立产品线, 要以生产的经济学为指导, 通过各种可复用软件构件, 如需求、构架、过程、方法等, 从而实现产品族可复用最大化。目前, 我国体现软件复用技术的是北大青鸟工程。该软件生产线系统是以构件-构架模式的软件开发技术及系统为基础从而解决软件开发问题。该生产线系统有利于软件工业化生产, 对促进软件产业规模效益具有重要意义。
4 结语
随着软件产业的发展, 面向大规模定制的软件开发模式, 已经成为软件企业竞争的“高地”, 面向大规模定制软件开发模式在软件工程中应用成为软件工作人员研究的重要课题。通过应用大规模定制的软件开发模式能使软件产品开发周期大大缩短, 减少软件产品开发投入, 增加软件企业经济效益, 提高企业竞争力。随着面向大规模定制的软件开发模式越来越成熟和完善, 我国的软件行业必将获得空前发展。
摘要：随着我国经济发展以及软件技术进步, 人们对软件产品的个性化需求越来越强烈。大规模定制作为一种全新的生产模式, 在软件开发中逐渐得到重视。本文就大规模定制的软件开发模式进行了浅显的探讨。
关键词：软件开发,大规模定制,开发模式
参考文献
[1]刘瑜, 张世混, 王立福, 杨芙清.基于构件的软件框架与角色扩展形态研究[J].软件学报, 201214 (8) :1364-1370
[2]李绪蓉, 徐焕良.面向业务构件的黑白盒混合的领域框架的设计与实现[Jl.小型微型计算机系统, 2011, 26 (l) :64-68
[3]吴卫东, 刘德仿.面向大规模定制的产品快速设计方法研究[J].组合机床与自动化加工技术.2012 (01) :178-179.
[4]戴若夷, 谭建荣, 李涛.面向大规模定制的广义需求建模方法及实现技术研究[J].计算机辅助设计与图形学学报.2012 (04) :105-107
软件规模 第7篇
关键词：分布式计算模式,CORBA软件体系结构,Agent
开放分布式计算模式广泛应用于目前的软件开发中,从小规模的企业软件的组建,到中大型跨区域、跨国际企业的软件构架,无处不见它的痕迹。在此,将基于这种计算模式的技术称为大规模软件(LargeScopeSoftware)构架技术[1]。
Internet/Web本身就是一个异构的分布式系统,这种异构环境不仅包含了不同的硬件,也包含了复杂多样的系统软件和应用软件。该系统的一个最大特点是在松散的基础上强调一致性和协同性。因此,在大规模软件构架中,充分利用面向对象的技术,以实现在分布环境下的软件重用。目前已形成3项主流技术,即OMG的公共对象请求代理(CORBA,Common ObjectRequestBrokerArchitecture)、Microsoft的ActiveX/DCOM(DistributedComponentObjectModel)和SUN公司的Java/RMI,其中以CORBA为代表。同时,由于大量信息的共享与网络带宽的限制,要求软件具有智能性的同时还应具有移动性,即靠移动的软件处理分布在网络环境下的数据和信息,争取保持数据原地不动,从而降低大量数据在网上传递带来的网络拥塞。以大规模软件体系结构为依托,结合软件Agent技术,将多个软件Agent对象整合于大规模软件体系结构框架之中,可能会成为未来大规模软件开发的主流模式[1,2]。
面向Internet/Web平台的大规模软件架构技术的核心是分布式对象技术,而构造模式又是分布式对象技术的核心,对构造模式的研究有其重要的应用价值。
1基于CORBA的分布式软件架构技术
1.1 CORBA/IIOP的体系结构
CORBA是对象管理小组(OMG)一个用来构造异构分布系统结构的技术规范,它定义了分布式对象如何实现互操作,目的是使基于对象的软件部件在分布异构环境下可重用、可移植和可互操作。它的底层和核心部分是对象请求代理(ORB)。COR-BA的实质是RPC与面向对象技术的有机结合。在CORBA中,每一个构件是一个对象,有一个基于面向对象的接口,内部代码实现可以是OO或非OO的语言,总线上的对象能够被任何其他对象所使用。从某种意义上说,CORBA是“对象总线”。CORBA提供了接口语言定义语言(IDL)到C、C++、Java、COBOL等语言的映射机制IDL编译器,它可以生成服务器方的Skeleton和客户方Stub代码,通过分别与客户端和服务器端的联编即可得到服务方和客户方的程序。对一个CORBA客户机来说,服务器的位置是透明的,客户机通过接口与服务器构件进行通信。CORBA同时提供了一系列的公共服务规范,其中包括名字服务、永久对象服务、生命周期服务、事务处理服务、对象事件服务和安全服务等,它们相当于一类用于部署企业级计算的公共构件。
最新的CORBA规范主要包含以下内容:ORB核心、OMG界面定义语言、语言映射、存根(Stub)和框架(Skeleton)、动态调用和仓库、对象适配器和ORB之间的互操作。图1描述了CORBA的主要组成部分和它们之间的关系。
1.2 CORBA各组成部分功能描述
1.2.1 IDL语言
对象的界面是用来说明对象所支持的操作类型。CORBA的对象界面由OMG IDL来定义。OMG IDL是一个纯说明性语言,不能用它直接去实现分布式应用。在具体应用时,需把IDL的特性映射为具体语言的实现。此外,OMG IDL编译器还根据界面描述来产生客户方的存根(Stub)和服务方的框架(Skeleton)。客户方根据存根发出对象服务请求;框架则把相应的请求交给CORBA对象实现。由于存根和框架都是通过对用户的界面定义进行编译而得,所以通过存根和框架的调用被通称为静态调用。
1.2.2 ORB/IIOP核心
ORB的任务是,把客户发出的请求传给目标对象,并把目标对象的执行结果返回客户。ORB提供了客户和目标对象之间的交互透明性。CORBA提供的IIOP(InternetInter-ORB Protocol)协议规定了位于不同系统上ORB间基于Internet的交互标准IIOP规范了传输语法(低级的数据表示方法)和ORB之间的消息格式,从而建立了ORB之间的基于面向连接(如TCP)或无连接(如UDP)传输协议的互操作性,实现了Internet上ORB之间的交互。
1.2.3客户程序(Client)
(1)IDL存根和动态激活API。客户IDL存根提供了访问对象服务的静态接口,这些由IDL编译器生成的预编译存根,对应于Client如何激活处于Server上的相应服务;另一方面,通过使用DII(DynamicInvocationInterface)提供的界面,客户可以动态激活API而实时地发现服务对象,并调用其方法与静态调用相比,DII允许应用程序在运行时访问在编译该应用程序时未知的对象。
(2)接口库(InterfaceRepository,IR)。接口库API允许用户获取和修改所有已注册构件接口的描述,它们支持的方法及这些方法所需的参数,即方法签名。IR负责存储、修改和管理对象接口定义,用户程序使用IR API存取和修改这些信息。IR中的信息可以被Client和Server共同使用。
1.2.4对象实现(Server)
ORB通过Server的IDL框架定位一个对象适配器,传输控制参数和转换控制给对象实现。
(1)静态框架(StaticSkeleton):静态框架在Server端,Server端输出的每个服务均通过该接口这些接口像Client存根一样,使用IDL编译器创建静态调用限定客户程序只能使用编译时能够确定的IDL接口。服务器通过回调(Callback)可以访问客户端的对象(这时客户端转换为服务器)。
(2)动态框架(DynamicSkeleton):动态框架接口(DSI)为服务程序提供了运行时的捆绑机制,它检查所接收的消息的参数以决定目标对象和方法。动态调用允许客户程序在运行时通过请求命名服务及查询接口仓库来获得目标对象引用、操作和属性名,以及要传递的参数,动态构造对远程对象的请求。
(3)对象适配器OA(ObjectAdapter):它是对象实现用来存取ORB所提供的服务的基本方式。它位于ORB核心通信服务的顶层,负责接收代表Server对象的服务请求。它为实例化的对象服务提供运行环境,接受客户请求并传送给服务对象。此外对象适配器还负责为服务对象分配对象ID,以及将对象类和实例化对象注册到对象实现库中。
(4)实现库IR(ImplementationRepository):IR包含了Server支持的类、被实例的对象和对象标志ID。这些信息供ORB定位和激活对象实现。通常情况下,对象实现的安装和对象实现的激活与执行相关机制的控制均是通过作用于实现库上的操作来完成的。
1.3 Agent/CORBA的对象式Web构造模型
CORBA技术与Agent技术互补性强,CORBA实现对象之间的互操作,而Agent可实现对象之间的协同。将二者结合起来,使CORBA对象之间不仅实现异地互操作,还使对象之间实现同一目标之下的协同。在Agent技术中利用CORBA实现Agent之间底层的互操作,使Agent系统实现真正的分布。另外,Agent系统利用CORBA提供的诸多服务,更好建立上层的协调机制,可以构造出高效、全新的大规模软件架构模式[3]。
1.3.1体系结构
Internet上复杂的资源群不是封装成单一的服务对象,是被构造成一个多Agent系统,各个Agent之间可以很好地协同,向外界提供复杂的信息或服务。引入Agent技术,并和CORBA技术融合,建立三层对象式Web体系结构。如图2所示,第一层是客户层,浏览器中的JavaApplet作为客户端代理;第二层是代理层,由相互联系的多个中介代理组成;第三层是服务层,由最终提供服务的一系列服务代理组成。服务代理根据其功能分成四种类型:服务协调代理是资源群对外交互的代理,它具有整个资源群的所有能力。它负责接收外界的资源请求,并协同资源群中的各个信息代理或软件代理完成复杂的操作,最终将结果返回给客户;信息代理是资源群中具体操作数据的代理;软件代理负责驱动相关的软件系统,完成一定的服务;远程服务代理是一种移动代理,附属于某个软件资源群,可以在客户与服务方之间移动[4,5]。
1.3.2中介代理连接方式与协同
每个中介代理都注册有多个服务代理的信息。中介代理之间也可以进行协作,定位用户需要的资源群。当中介代理接收到用户代理的请求后,首先在与该中介代理相连的所有服务代理中定位相应的服务代理,如果在本地没有找到,还会与其他的中介代理通信,找到所需的服务代理。这使整个系统资源共享的区域能够无限扩大,覆盖整个Internet。
1.3.3 Agent间的通信
在Agent通信方法的研究中,首先对KQML(KnowledgeQueryandManipulationLanguage)与FI-PA(FoundationforIntelligentPhysicalAgents)组织的ACL进行深入的分析,结合各种代理之间通信的具体要求,定义系统所需要的Agent通信语言集合,再结合CORBA的对象互动策略,如IDL接口定义等,将这些Agent通信语言映射为底层CORBA实现的具体方法。将Agent技术与CORBA技术融合,是实现分布、异构环境下软件协同的一种崭新且有效方法[3]。
2 CORBA应用的Java编程实现[6]
2.1 IDL接口创建(About.idl)
上面用OMG IDL描述一个CORBA对象,将其存为Show.idl。用一个IDL到Java的编译器编译这个IDL模块就会映射到Java接口。其中Moduel对应Java关键字Package。
2.2服务器端实现(ShowServer.java)
在服务器端(ShowServer的Main()方法)需完成以下任务:创建一个ORB实例;创建一个服务对象实例(CORBA About对象的实现)并通知ORB;获取一个命名上下文的CORBA对象引用,在该命名上下文中注册新的CORBA对象;将新对象注册在“About”名下;等待对新对象调用。其代码如下:
2.3客户端实现(ShowClient.java)
在客户端应用程序中需完成以下任务:创建一个ORB;获取一个指向命名上下文的引用;在命名上下文中查找“Show”并获得指向该CORBA对象的引用;调用对象的ShowName()操作并打印结果。其代码如下:
3结束语
在一个异构分布的复杂环境下构架大规模软件,体系结构的重要性显得更为突出。一般来说,虽然人们对软件体系结构的概念和研究内容等还没有达到共识,但总的研究概括起来大约建立在两个层面之上,即基于系统级的高级层面和基于实现级的低级层面。前者注重概念和系统级的抽象,而后者则注重软件工程过程的实现。对于大规模软件构架技术,基于高级层面的研究却显得更为重要,也应是目前大规模软件构架技术中首先要解决的问题。
参考文献
[1]王映辉,冯德民.大规模软件构架技术.北京:科学出版社,2003
[2]吴刚,王怀民,等.一个基于CORBA和移动智能体的分布式网管集成框架.计算机学报,2001;1(24):19—24
[3]Nwana H S.Software Agents:An Overview.http://agents.umbc.edu/introduction/ao/,2004—01—25
[4]郎波,李伟琴.对象式Web技术研究.北京航空航天大学学报,2001;4(27):452—455
[5]Orfali R.智能CORBA.陈章,译.北京:电子工业出版社,1999
软件规模 第8篇
1 企业业务体系的特点
企业业务体系属于庞大而复杂的工程对象,它的复杂性通常超出了一个人员或部门的能力所能控制的范围。因而在实际运行中它通常会被按照一定的工程方法进行划分,形成诸如研发、制造、采购、计划、市场、财务、人事、档案等业务子系统。业务体系的复杂性还表现在另一个重要的方面,那就是它始终处于或快或慢的变化之中,促成这种变化的因素同时来源于企业内部和外部。应用软件在企业中的作用主要可分为两个方面,一方面是作为企业级信息系统的基础和载体,固化和积淀企业中业已成熟的经营策略和业务逻辑;另一方面是及时地将企业中产生的创新思想和经营智慧纳入业务体系中,同时为新的创新和发展提供应用反馈和决策依据。
2 大规模企业级信息化软件系统的发展现状
中国企业信息化至今已走过了20多年的历程。20多年来,从最开始的会计电算化和办公自动化到后来的管理信息化,以及到今天的电子商务和电子政务,可以说,信息化观念已经被越来越多的企业所接受,信息技术已经在各行各业得到不同程度推广和应用。中国目前的企业信息化现状,有三个方面的特征值得我们关注:
2.1 应用总体上层次较低。
从企业信息化应用的总体格局来看,仍然以基础管理信息系统如财务、OA等为主,综合性管理信息系统如ERP应用偏少。根据2006年国家经贸委对百家重点企业信息化调查报告显示,百家重点企业中基础性管理信息系统已基本实施的为26.7%,部分实施的为81.3%,还未实施的只有2.2%。可见大部分企业主要还是停留在基础管理信息化阶段,已实施综合性管理系统的也绝大部分还未全面应用。
2.2 应用水平上参差不齐
从应用水平上来看,大中型企业信息化应用水平较高,其中财务应用信息化的达到70%以上(2006年国家经贸委百家重点企业信息化调查报告);而中小型企业信息化应用普遍偏低,59%中小企业没有配备计算机,建网站的不到1%。根据2006年CCID报告,已实现财务管理信息化的中小企业不过60万家左右,占1100万家中小企业总数的比例只有6.1%。可见不同规模企业应用信息化水平差距较大。
2.3 网络应用水平不高
大部分企业建设了自己的网页,但主要用于宣传,不能有效开展网上业务。要么仅仅建设了网络系统,而不重视后台管理系统的建设;要么前端与后台管理系统集成不够。根据2006年国家经贸委百家重点企业信息化调查显示,37%的企业已经开展了电子商务,29%的企业认为电子商务可使企业快捷地获取信息,25%的企业认为电子商务改善了企业形象,降低了成本;22%的企业认为电子商务使企业更新了观念并提高了工作效率;16%的企业认为电子商务扩大了企业的销售。百家企业中仅有13家企业统计出了网上交易额,究其原因,20%的企业认为信息化基础薄弱、人才缺乏是开展电子商务过程中遇到的突出问题。
3 大规模企业级信息化软件系统存在的问题
信息化软件系统在大规模企业中的作用主要可分为两个方面,一方面是作为企业级信息系统的基础和载体,固化和积淀企业中业已成熟的经营策略和业务逻辑;另一方面是及时地将企业中产生的创新思想和经营智慧纳入业务体系中,同时为新的创新和发展提供应用反馈和决策依据。
3.1 信息孤岛
在信息化软件系统服务于大规模企业业务的早期,它只是被用来辅助个人业务的执行,因而不至于形成一个企业级架构,而在MIS系统阶段,大规模企业开始参照传统的业务划分方式去构造一个个业务信息系统。如制造MIS、计划MIS、财务MIS、采购MIS等,这样的软件系统通常产生于特定的软件开发项目或商品化的软件产品,在整理需求时通常关注于企业中特定业务链的构造而较容易忽略业务链间的固有关联,因而会造成大规模企业中大量基础性的业务对象被重复管理且一致性得不到保证,使业务信息的有效性也大打折扣,实际表现为各部门、各子系统不能数据共享,导致信息技术的割裂应用和企业内信息梗阻。企业的业务信息被建设成一个个短缺和冗余并存且缺乏规范性和一致性的信息孤岛。信息孤岛影响企业信息化应用和持续建设,逐步成为信息化提升效率的重要瓶颈。“信息孤岛”的不良影响大致有以下几个方面:
3.1.1 系统间的业务协作由手工完成
信息不能及时、充分共享是信息孤岛的突出矛盾。如果企业中“信息孤岛”现象严重,系统之间既不能有效实现信息共享,又影响业务的顺利执行。由此所造成的业务协作困难,最终只得靠手工来完成。例如,销售部门需要及时掌握产品库存信息,并及时了解销售订单处理情况,又要随时知道产品价格变化情况,掌握销售回款情况。也就是说一个完整的销售涉及到销售、库存、财务、订单处理等,在这些系统相互独立的情况下,很多工作仍然需要借助手工来完成,无形中增加了工作量,最终可能又退回到全手工操作方式。
3.1.2 重复信息与信息不一致
彼此孤立的系统要顺利运行,必须对相同的信息重复输入,将一个系统中的统计结果和计算结果输入到另一个系统中,使得大量的信息资源不能充分发挥应有的作用,效率低下。由于信息来源的口径不一,不仅增加了不必要的额外的劳动,而且经常造成信息不一致、不正确,使得企业领导面对不同来源的报表中不一致的数据而无所适从,成为阻碍信息化进一步发展的障碍。在信息化系统中,不一致的数据往往是统计和计算出来的结果,不是简单的修改就能解决了的,面对牵一发而动全身的系统时,我们可能会束手无策。由于信息的一致性不能保证,自然也会影响到信息的正确性,降低我们对系统的信任。
3.1.3 缺乏完整的信息全貌
信息孤岛的存在难免导致一套系统一套账户和密码,每个需要操作计算机的人员要记住多个账户、登录口令,经常需要从一个系统退出再进入另一个系统,给操作带来不便。企业主管需要站在企业全局把握生产、经营情况,需要在产、供、销的一体化的基础上对企业人、财、物进行统筹管理,而孤立的信息系统无法有效地提供跨部门、跨系统的综合性的信息。企业管理者要求随时可得到市场、财务、人力资源等实时的信息,迅速调动、消化企业资源以反映市场需求。在信息孤岛普遍存在的情况下,各类数据不能形成有价值的信息,局部的信息不能提升为管理知识,决策支持只能是空谈。
3.2 集成性和一体化设计不足
根据我们对一些企业的调查,许多大规模企业在实施信息化软件系统时,由于各模块或子系统不能很好地集成设计,各模块或子系统所采用的技术方案的差异且缺乏完善而统一的规范和标准,企业的业务逻辑也经常遭到不合理的分割,造成重叠和不完整并存的状况,结果系统建成后无法一体化应用。许多企业对各子系统分开招标,产生这一问题的可能性更大
3.3 无法面对新的改变而不得不开发新的系统
很多企业在信息系统的规划上,都有意识或无意识地陷入了封闭规划的误区。比如在上财务系统时,很少去考虑今后与业务系统的衔接;在上ERP时,固执地坚守闭环概念,很少去考虑客户关系管理、供应链管理等未来的扩展应用。一旦有了新的需求,系统规划不得不跟着变,必须相应地修改软件;硬件或操作系统更新时,通常需要修改软件以适应新的环境。从而导致企业信息系统朝令夕改、无法与企业变革同步。
4 消除信息孤岛EAI成企业信息化的整合者
EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构,来联系横贯整个企业的异构系统、应用、数据源等,完成在企业内部的ERP、CRM、SCM、数据库、数据仓库,以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了EAI,企业就可以将企业核心应用和新的Internet解决方案结合在一起。EAI将进程、软件、标准和硬件联合起来,在两个或更多的企业系统之间实现无缝集成,使它们就像一个整体一样。尽管EAI常常表现为对一个商业实体(例如一家公司)的信息系统进行业务应用集成,但当在多个企业系统之间进行商务交易的时候,EAI也表现为不同公司实体之间的企业系统集成,围绕着EAI技术提出的RTE、APS、ESB等解决方案和技术架构层出不穷。(下转第8380页)(上接第8377页)
应用集成(EAI)是解决信息孤岛的基本途径,它可以分为四个层面:首先是数据层面的集成,共享或者合并来自于两个或更多应用的数据,具体包括数据共享,数据转化,数据迁移及数据复制等,而后是应用系统集成,使不同应用系统之间能够相互调用信息;然后是用户界面集成(界面重组),它将原先系统的终端窗口和PC的图形界面使用一个标准的界面(有代表性的例子是使用浏览器来替换。一般的,应用程序终端窗口的功能可以一对一地映射到一个基于浏览器的图形用户界面,面向用户形成一个新的统一的表示层。最后是业务流程整合———优化原有的业务流程,并通过流程把所有应用、数据管理起来,使之贯穿众多应用系统、数据、用户和合作伙伴,这是最理想的层次。
目前,国内的应用集成更多地处于数据层面的集成。数据集成经常采用数据库中间件与XML-RDBMS中间件完成。应用系统集成和业务流程整合的实现方法为:API调用、业务组件调用以及目前最新的基于服务功能调用三种方式实现。在技术实现上,有微软的COM、DCOM、COM+,OMG的CORBA,以及Java的EJB组件标准。用户界面集成将对带有API或没带API的应用进行打包处理,使之可以被以组件为标准的最新应用(如Web应用)直接调用传统意义上的应用集成存有很大的客户化程度,提供得更多的是咨询和服务,它不能被称为是一种产品。对于行业客户来说,除非一个行业已经有自己的协议标准,否则也无法实现行业化的解决方案。
5 采用面向服务的体系结构SOA
Web服务一种作为炙手可热的技术,应用到企业的IT系统和商业流程之中,并给企业带来直接的经济效益,一直以来得到了国内外企业管理者的推崇。而在近两年,伴随着企业需求的不断变化,一种被誉为下一代Web服务的技术架构,再一次引起业内关注,这就是SOA(Service-Oriented Architecture,面向服务架构)。SOA对需要使用信息技术解决关键业务问题的企业(包括希望减少冗余架构、创建跨客户和员工系统的公共业务接口的企业;需要基于角色和工作流对用户提供个性化信息的业务的企业;希望通过Internet实现跨区销售、升级销售和经由移动设备的访问来提升客户服务的组织)很有价值。
面向服务的体系结构是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。使得软件开发人员能快速开发、集成和重用应用。更为重要的是,SOA是一种企业架构,因此,它是从企业的需求开始的。但是,SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说,创建一个业务敏捷的架构意味着创建这样一个IT架构,它可以满足当前还未知的业务需求。因此基于这种软件框架,系统能在业务发生变化之后,动态响应新的需求,快速重新装配各种软件构件和服务。
6 结束语
市场在变,企业的需求在变,市场环境下的企业必然要求有一个随需而变的信息系统软件,来辅助企业决策,提高效率。企业也意识到信息技术和软件技术是达到这个目的重要的技术手段。EAI、SOA、软件构件技术应用是随需而变的大规模企业级信息系统软件技术手段,通过对先进软件工程理论和软件开发技术的合理运用,企业将长期得到保证。
参考文献
[1]于岫.消除信息孤岛EAI成企业信息化的整合者[EB/OL].(2006-06-28).http://www.topoint.com.cn/.
[2]许正文.如何选择最适合的企业信息化解决方案[EB/OL].(2006-06-28).http://se.csai.cn/.
[3]涂智寿.利用EAI技术创造企业群的协同效应[M].北京:机械工业出版社,2005.
[4]龚晓庆.统一建模语言UML和Rational统一过程RUP[M].北京:机械工业出版社,2005.