新疆软件开发

本站首页 软件开发 成功案例 公司新闻 公司简介 客服中心 软件技术 网站建设
  您现在的位置: 新疆二域软件开发公司 >> 开发语言 >> 文章正文

组件式软件系统分析与设计

1.      系统理论
根据波尔丁氏(Kenneth E. Boulding)的通用系统理论:任何系统分为静态结构系统、简单动态系统、控制机构或自动操作系统、开放系统、原生社会系统、动物系统、人类系统、人类社会层级及超越系统层级由内而外共九种层级;每一层级均有其特殊功能而且外层系统包含有其内层系统,而且具有内层所没有的特性。
根据系统特性可区分为封闭系统与开放系统两大类;各类系统都由静态系统与动态系统均衡的关系组成,现代信息系统的进步都是架构在这些理论基础上建立。
软件工程的研究与发展,从传统的结构化系统分析设计方法建置系统,演变到对象导向分析设计建置系统。无疑的都是在尝试与寻找,如何用最有系统与最有效率的方法,在复杂的计算机逻辑运算世界与捉摸不定的使用需求中,去建置一套应用系统。
然而从软件公司所经验的软件开发过程中得知,软件一直无法做到像硬件般,运用模块化设计,能够利用大量生产,带来人力与时间成本降低。且软件制作内容,仍然过于偏重个人的设计技巧与艺术,软件人才的去留,深深影响着软件的生命。
一个共同推论是,硬件的制程技术观念可引用在软件开发上,比照硬件零件组装之软件工厂概念已在技术的标准上,达到某种程度的成就。OMG组织所定义的CORBA软件组件标准就是系统开发产出过程中零件与运作平台的标准。引用零件的观念,再用与组装的技术才能实现出它的成效。零件本身可以经由外包或采购,达到半成品的再用。在市场机制运作下,您都可以用最实惠的价格取得市场上历炼后最优秀的软件组件植入您的系统。透过有效的软件组件组装制程技术,可以在最短的时间内开发出系统。且由于系统开发走向标准化,软件人员的技术技巧,将大部份展现于软件组件本身,系统结构本身则因标准化得以定型。尔后软件的维护工作可能就如同修车般,只需更换零件或维修配件即可。
本文主要目的即在阐述传统结构式系统分析与设计及组件式系统分析设计与开发进行开发应用系统过程中之标准与工作指引,使软件组件在开发过程中有所依循,开发后得以在规则的模式下运作。组件标准与组件运作平台采Microsoft DCOM标准,系统采多层式架构设计同Microsoft DNA(Distributed interNet Applications Architecture)架构。

2.      传统结构化软件系统分析与设计
2.1.  系统发展(Development)
系统发展分为规划(Planning)、设计(Design)和实施(Implementation)。须考虑未来资料量增加、企业的成长与扩充、科技的进步与系统整合性以便设计一个有弹性、可动态调整且易于维护的系统。
系统的三大基本要素:
1.    输入(Input Data)
2.    处理与控制(Process Logic & Control)
3.    输出(Output Information)
系统规划通常采用由上而下的作业方式,其做法先从整体企业目标开始,探讨企业营运特性,企业组织建立关系,数据处理应用逻辑,达到信息系统架构建立完成档案设计工作。而信息管理的顺序却是与前相反由个别档案资料的输入一直到达成企业营运目标为止。
2.1.1.系统规划(Planning):
系统要做什么(What)?
初步研究:定义问题的范围与建立系统可以解决问题、满足需求、运用新科技、增加系统效能。
可行性研究:定义问题需求范围、搜集资料、组织管理者与使用者需求。订立阶段计划、订立组织人力计划、订立推动计划、订立维护管理计划、订立教育训练计划、订立文件制作计划、订立经费计划、订立其它配合措施。
2.1.2.系统分析(System Analysis)
系统分析,系利用系统方法或技术,建立系统观念性架构,探讨研究问题的特性,并提出具体和可行性方案的实际过程。广义定义为一种有组织的方式来解决问题,达成目的。是一门研究如何建立系统来解决问题的科学。
系统分析的运作结果,是由资料的输入,经过组合与处理,而输出有意义的信息,提供与辅助管理者进行决策。
良好系统具备的特性:整合性(Integertion)、使用者易操作性、管理能力强性、实用性、资料量处理需求、符合组织风格、达成最大成本效益、考量使用人员因素、结合外在科技、法规、经济、社会等因素、弹性的组织变更及企业成长需求。
系统分析师(System Analyst)为运用各项分析工具,整理所获得的信息,找出一个最适合的方法解决问题的人员。须具备专业知识的能力,对系统的输、出入与处理的软、硬件与对数据库的特性知识深入了解,也具有程序设计撰写的能力,同时要具有系统企业领域知识(如财务、贸易、生产制造等)。
在规划中由需求访谈,可以获得管理者与使用者的各项企业行为需求与组织问题的特征与本质,了解决策者讯息需求的关键性信息及优先级。由企业诊断可以获知现行系统的作业程序与运作状况,找出现行系统不足所在及未来需求的扩充性,了解问题发生的原因与理由,进行企业的改造(BPR)。再由需求访谈与企业诊断结果进行提出各种可行性分析与研究报告,提出改善现行系统方案与解决各项问题的处理方法。当然各种问题不一定完全可由计算机系统可以解决问题,某些部分需要靠组织变革、组织章程变更及流程改造来解决问题。
2.1.3.可行性分析
可行性分析报告要获得高层管理人员支持,定义明确的问题描述与确认的目标方向,讲求实事求是的效果,正确的评估所需资源,最佳生产品质,选择适当的信息科技与设备。在可行性目标上还要对系统中要求弹性与可维护性(Flexibility & Maintainability),时程与成本(Schedule & Cost),效率(Efficiency),实时响应(Quick Response),整合性(Integration),安全性(Security),可靠性(Reliability),简易性(Simplicity),兼容性(Compatibility)。
可行性研究建议案提出方式:
1.      提出最佳方案的二元建议方式(Binary recommendations)。
2.      提出多个方案进行假设不同与说明选择的假设建议方式(Choose recommendations)。
3.      依据成本考量系统弹性反映速度维护容易等因素各与加权做量化分数的价值建议方式(Value recommendations)
系统分析工具(一幅图画胜过千言万语)。将系统所需处理步骤使用流程图(Flowchart)表现。
1.      流程图(Flow Char):以逻辑图标处理过程,表示作业每一个步骤以足以表示特性的符号来代表。绘制原则:由上而下,由左而右;图标明确,工作起始确定明白,每一个步骤动作描述清楚,排好各种工作顺序,流程工作范围清楚,分支要用连接符号表示,使用标准的流程图符号。
2.      系统流程图(System Flow Chart):绘制系统整体工作流程者称之为系统流程图。
3.      功能流程图(Functional Flow Diagrams):绘制组织间各个作业间资料流动的关系。
4.      数据流程图(Data Flow Diagrams):绘制数据间数据的储存、转换、流程与输出、入。
5.      文件流程图(Paperwork Flow Chart):绘制系统中各类文件或表格产生及纪录其流动的情形。
6.      程序流程图(Process Flow Chart):绘制一个系统中各个工作的程序与步骤。
7.      甘特图(Gantt Chart):用以绘制表现工作排程进度,以时间做中心,一般用于项目的规划及阶段性排程。
8.      组织图(Organization Diagram):用以表现组织内各部门功能间的关系与各组织间从属关系,包含组织的名称与部门间关系与组织各成员信息。
9.      数据字典(Data Dictionary):定义各种资料的说明,使得数据流程图(DFD)更易于阅读。
系统设计(System design)结合执行活动工作程序与设备资源来完成系统使用者所要求的目标,可以令系统达到最大、最佳、与满足需求的功能。考虑每一个独立程序的随机关系-与其它程序间产生互动的关系、循序关系-各程序间的前后顺序关系和时间关系-各程序在不同时间期间所存在的关系。
2.2.  系统设计(Design)
如何完成这一个系统(How)?
系统大体设计:依据系统需求、系统功能来定义系统的输入、输出与处理程序。
系统细部设计:依据大体设计定义输入规格输出规格与处理程序规格。
进行程序撰写与设计。
进行程序的测试与正确性。
2.2.1.结构化设计(Structure Design)
结构化设计(Structure Design)采用由上而下渐进且合乎逻辑思维的方式进行设计,建立起层次关系的结构,细分各层的问题逐一探讨解决其问题的设计模式。
资料输入方式的决定考量是采用批次性输入(Batch Input),还是采用实时性输入(Online Input),一般常态异动式日常作业大都采用实时性输入方式,进行统计或结帐式作业可采用批次性输入方式。
编码设计:制定编码原则,采用数字、文字、文数字或符号;主键(Prime Key)唯一键值的规划设计,采用循序键或存取键,关联键值的规划设计,索引键值或复合索引键值(Index Key)的规划设计,编码长度,避免混淆字形,同音异字等。
资料输出的设计,精确、时效与适切性,窗体的设计,考量用纸大小、份数、传递方式、颜色、字体大小、主标题说明、次标题说明、编号方式、分页考量、页首信息、页尾信息、上下左右空间关系、复写字段功能、打印机功能与格式。图表的设计,图形特性选择、表现方式、颜色或条纹区隔、尺标刻度的计算、多维空间的建立、图形标示及图例说明。
成本效益评估:系统使用环境考量,网际网络、局域网络、企业网络、单机使用等;使用硬设备的成本考量,服务器、终端计算机、个人计算机、备份设备、安全机制与管理;软件工具的成本考量,工具软件、应用软件、数据库软件、操作系统;维护管理的成本考量,训练使用、维护费用、管理人员薪资、更新版本费用等等。透过计划需求书(RFP Request for Proposal)提出所需系统的软硬件信息需求,具备有功能需求规格,评估程序与建议,各项软硬件及厂商的介绍与说明。考量硬件的兼容性、成本、可靠度、普遍性;软件的适用性、成本、品质;厂商的经验与规模、技术能力、人员素质、财务状况、教育与训练、服务满意度等等。分析系统的顾问咨询成本,期初建置成本,转换成本,每期维护成本,后续发展成本,操作使用成本,教育训练成本,初期评估成本等等。
2.3.  实施(Implementation)
系统安装与使用训练
系统实施
1.  系统环境安装
2.  使用手册
1.    系统简介
2.    软硬件配备要求。
3.    功能特色说明。
4.    功能画面使用指引与说明。
5.    常见应用范例说明。
6.    常见问题回答。
3.  应用系统建置
循序式档案(Sequential files)、索引循序式档案(Index Sequential files)、直接存取式档案(Random access files/Direct access files)和
分割式档案(Partitioned files)。
4.      系统上线转换
1.      直接转换(Direct Conversion)或称一次转换:直接使用新系统。
2.      并行转换(Parallel Conversion):新旧系统并行一段时间后,再更换成新系统。
3.      模块转换(Modular Conversion):依照模块间关系逐个模块进行替换成新系统。
4.      渐层转换(Phase in):和模块转换很像,但具有新旧转换接口同时承接旧系统信息,对新系统而言增加许多负担,但对于使用者确可不间断及变动旧有所有作业。
 
3.      组件式软件系统分析与设计
3.1.  组件分析方式
对象导向系统分析设计方法是一套以重复使用为基础的系统分析、设计及程序制作一气呵成的方法,
对象导向技术的观点来看,我们认为所要模塑的真实世界是由对象所组成的,真实世界的运作是由个对象成员之间的互动而成,因此先天上用这样方法去模塑真实世界将比用结构化方法来的稳定,而且在与客户交谈时也比较容易得到客户的认同,因为我们所谈的是客户心中的真实世界,而抽象的方式就功能面来探讨模塑系统。
现今各式各样的对象导向分析(OOA),目前较著名的方法理有Object Modeling、Technique、Booch Method、Function/Mellor Method及Use Case等等。这些方法除了Use Case以外,其它的方法大体上都是对象模型(Object Modeling)为主,再辅以动态模型(Dynamic Model)及功能模型。其中对象模型是用来述真实世界的静态关系,所谈的内容是对象.对象及对象之间的关系,如组成关系、继丞关系或其它各式关系。
动态模型通常是描述系统动态行为,所谈的内容通常先用脚本(Scenario)描述物作对外界刺激的反应及各对象之间的动关系,并用事件追踪图(Event Trace Diagram)追纵各个对象之间的动态行为,或用态图描述单一对象对外界刺激的反应。功能模型则用功能观点来看系统,与传统的结构化方法的DFD相同。
分析阶段描述系统要做什么,设计阶段考虑如何才能满足客户的需求。
第一阶段是需求收集阶段,我们利用使用个案进行需求搜集工具。
第二阶段是系统分析阶段,依据第一阶段的使用个案依据原则找出可能的类别,再用一套筛选原则找出适合的原则,利用对象图进行系统的领域模型及应用程序塑模工作,以使用状态图来描素系统的动态行为。
第三阶段是系统架构设计,考虑整个架构设计,如何分割系统,使用整体运作能够顾虑到结构性、执行效率与扩充性等,此时可产出商业对象(Business Object)、应用程序对象与技术对象等。
第四阶段为设计阶段,考虑如何设计系统接口,如何将对象图对应到数据库上,如何设计所需的算法,如何选用可再用的对象等等。
第五阶段可依据第一阶段的使用个案进行程序测试个案制作。
第六阶段将使用个案的测试结果结合系统架构设计可以编制成使用手册,符合再用的需求。
运用CASE工具UML(Unify Modeling Language),结合了Use Case,OMT和Booch Method三者的精华成为设计分析更好的方法。
使用组件再用模版之优点
提供多样化的客户端选择,如Internet BUI(Browser User Interface)或是Windows GUI(Graphics User Interface)。可透过Internet由远程使用系统,使用弹性度大,不受空间与时间限制;充份运用Internet降低联机成本;软件组件同时提供ActiveX使系统执行于局域网络,与DCOM版本使系统执行于广域网络;使用者可透过参数化的系统设定,让系统容易维护、调整与使用;系统由组件组装而成,易于与其它组件化系统整合;进行跨地域性的信息整合,并且缩短信息撷取时程,提升企业竞争力;资料维护方式,简单易维护;报表查询方式,迅速易调整;业务交易方式,弹性易扩增。组件再用,软件量产。
3.3.  组件化应用系统架构
3.3.1.多层式组件化应用软件开发平台 (eMAX Framework)建构
应用系统架构:为支持组织特定功能之信息系统(OrgManager),而应用系统架构则为协助提供组织所需信息之应用系统模式,他显示了应用系统、资料与其相互关系,依据业务作业模式界定出组织未来计算机作业之功能与范围,以作为设定系统发展优先级之基础。应分析现行信息系统之功能与数据文件,考虑应用系统架构的可行性,以免重复开发应用系统而浪费人力与物力。应用系统建构要求:
1.      系统是属于多层式软件架构(Muti-Tier),将软件予以切割成展现层(View Layer)、网络层(Net Layer)、处理层(Control Layer)、分封层(Encapsulation Layer)与资料层(Data Layer)。
2.      系统可运作于多层次(Muti-Tier)的硬件环境中,建置多形网络结构如:展示层、控制层、资料层透过局域网络连结。展示层透过网际网络与控制层、资料层连结。展示层、控制层透过网际网络与资料层连结。
3.      系统可于网际网络(Internet)下运作。
4.      系统是由软件组件组装而成
5.      系统是开放性架构(Open System)提供业务组件随插即用,窗口图形使用者接口(Graphic User Interface)与浏览器接口(Browser)。View Manager是窗口画面的编辑器,它内建的组件纲要信息(Meta Information)能力,可以让所有产生的作业画面在不经过编译(Compile)的情形下,随编即用。
6.      Web Manager是网页画面编辑器,则是透过数据库的资料纲要机制,以最快速的方式自动产生ASP、XML、XSL等档案,让网页可以很容易的连结到应用逻辑层中的作业组件。
7.      其支持多国、多点、多公司、多语言、多单位、多币别及多网域、多服务器等应用系统在架构面及使用面的复杂需求,同时也支持网际网络B2B、B2C电子商务交易、异步资料更新远程资料存取及工作流程(Work Flow)管理等应用面的延伸需求,而在客户导向的e世代里如何面对快速变迁的使用者需求,eMAX Framework提供了动态企业塑型(DEM Dynamic Enterprise Modeling)能力,让使用者可以很容易的动态调整或产生报表、企业逻辑、操作画面及程序,甚至可以完全不必透过软件商厂,即完成客制化的目的。
3.3.2.eMAX Framework的驱动引擎:
eMAX Framework目前提供了三个可以同时并存的驱动引擎:
1.          AcroFrame:
负责上述多层式组件化应用系统架构的建置及运作,应用系统的激活程序是eMAX.exe。
2.          AcroBrowser:
是一个可以从浏览器下载并自动安装的组件,它取代了AcroFrame中的激活程序eMAX.exe。使用者可以直接透过浏览器执行在AcroFrame中设计好的应用系统,无需再安装任何其它客户端程序。
3.          AcroWorkFlow:
是一个工作流程引擎,包括Server Agent、Worklist Agent、Instance Agent,可以将AcroFrame中的应用作业如订单作业循环、采购作业循环等由人工驱动改为流程驱动。由于是多层式组件化的应用系统架构,无需因为架设了工作流程引擎而重新设计应用程序。
3.3.3.领域分析
领域工程主要目的即在于可再用性,包含了软件设计架构的再用、软件开发流程的再用、文件的再用及领域知识的再用。
随着软件的应用与企业的经营越来越紧密,为了提身企业的竞争力,必须可实时反映政府的法规,提供市场的需求服务性,增加企业的安全性,提供实时的多样化的分析,满足企业集中式与多点多厂分布式的管理需求,弹性功能增加即最小变动达成功能的特性,随插即用的技术成熟,以对象导向技术开发的软件组件技术机制因此而生。
领域工程方法进行领域分析、制定领域架构规格、实做出领域组件、制定领域再用程序规格、维护及修正扩充领域组件。
对象导向设计(OOP)的目的其实就是将对象导向分析出来的对象与对象间的互动方式,用程序设计出来,最重要的是将对象的类别(Class)撰写出来,然后将个体间互动方式利用对象及其方法撰写出来,如此即可完成一个应用系统。
eMAX领域范围包含企业资源规划系统(eERP)、电子商店系统(eStore)、电子商城系统(eMall)以及电子联盟系统(eAlliance)等。eERP的应用范围包含配销、生产、财务管理及企业决策等领域,其可满足多组织企业内库存、采购(包含进口)、销售(包含出口)、生产、物料需求、产能规划、财务、会计以及主管决策等管理领域的需求。eStore和eMall则为B2C最佳解决方案。至于eAlliance则可满足企业B2B的需求。
依据业务需求进行可行性分析
1.      技术可行性(Technical Feasibility)
2.      经济可行性(Economic Feasibility)
3.      推动可行性(Motivational Feasibility)
4.      时程可行性(Schedule Feasibility)
5.      操作可行性(Operation Feasibility)
应用分析项目
1.      响应时间
2.      危机时间(可容忍时间)
3.      使用率
4.      使用者数
5.      复杂度
6.      一致性
资料实体分析项目
1.      时效性
2.      分割性
3.      必要性
4.      变动性
5.      共享性
6.      安全性(AuthorityManager)
3.3.4.应用系统架构(Application Architecture)
为了让组件得以在一定的规则下运作,特针对信息管理系统三大应用范围将组件运作架构加以定义:
(1)基本资料维护类:统归一般性基本资料如员工,公司,部门等资料之基本资料之新增,删除,修改,查询,停用,复用功能均规于此类。系统可开发DM(DataMaintenance)组件统筹基本资料维护工作,其中搭配Table Manager及DataDictionaryManager组件工具负责掌握数据域位,型态,栏宽与多语言控制;搭配TM(TransactionManager)组件负责将SQL指令执行于指定的数据库。数据维护逻辑:
1.      取得数据域位,型态,栏宽等纲要信息。
2.      显示编辑窗口。
3.      使用者由编辑窗口输入资料,或以泛查输入。
4.      系统检视输入资料。
5.      依作业动作取得SQL指令公式,并锁定资料。
6.      结合SQL指令公式与输入之资料取得完整SQL作业指令。
7.      执行SQL作业指令。
(2)业务交易类:统归以填具单据进行数据库异动交易者归于此类。业务交易逻辑架构经分析后可得,交易单据单头与单身之数据域位,型态,栏宽。使用者输入单据资料。.将输入单据资料包装成一单据参数封包。依作业动作取得相关子系统BSO组件。依事务交易代码,呼叫相关BPE组件群,依序处理单据参数封包以完成事务交易。撰写BPE订定交易规则流程:
1.      取得单据单头与单身之数据域位,型态,栏宽等纲要资料。
2.      显示编辑窗口。
3.      使用者输入单据资料。
4.      系统检视输入单据资料。
5.      依作业动作处理单据参数以完成业务交易。
(3)报表查询类:统归以查询条件取得数据库资料以进行资料浏览,报表打印或转文件者均归为此类。系统可开发QM(QueryManager)组件统筹资料查询工作,其中搭配ReportManager组件工具进行报表查询逻辑架构。设定报表查询SQL:
1.      取得查询项目之查询条件数据域位,型态,栏宽等纲要资料。
2.      使用者输入查询条件资料。
3.      系统检视查询条件资料。
4.      依查询条件资料进行查询。
5.      取得查询结果并显示。
3.4.  组件开发系统程序
以组件方式开发系统,其程序仍不跳脱需求分析,系统分析与系统设计三大步骤,只是多引用了对象导向系统分析设计中之循环渐进(Spiral)观念,随时修正分析设计结果,并以各式模版原则组装组件以规范组件运作。
项目之推行,建议先以开发共通组件,再以领域组件与使用接口平行开发方式进行,较能获得较佳之人力与时间成本掌控。关于项目的分工,会较以往容易。当组件规格与组装模版底定,组件的开发与使用接口的开发便可分头并行,视适当时间会合组装成系统。
项目基本成员,建议以项目经理,系统分析师,组件设计师,使用界面设计师与数据库管理师搭配进行。
3.4.1.需求分析
领域分析
了解与熟悉所开发系统之应用范围。
数据字典(DataDictionaryManager)专门用语建立:建立系统开发过程中之标准用词,做为尔后系统开发与设计过程中之标准用语,此标准用语另可作为数据库字段,作业画面之标准用词语。
领域模型
收集与了解领域资料。
记录专门用语。
1.收集系统用词。
2.统一用词。
3.建立标准型别。
4.建立继承字词。
5.建立字词,设定型别与继承字词。
6.建立字词别名。
与使用者访谈,了解所开发系统与相关环境关联。
绘制领域模型。
使用个案分析(Use Case)
收集与记录使用者需求。根据使用者或客户之需求描述,使用自然的语言来记录使用者期望的状况,进而了解与分析使用者的真正需求。
1.      使用者访谈。
2.      找出领域使用个案。
3.      找出系统使用个案。
4.      记录领域使用个案。
5.      记录系统使用个案。
6.      绘制使用个案图。
作业画面分析
规范最终使用接口之作业画面,以做为与使用者确认最终产出之依据。
1.      依使用个案制作作业画面初版。
2.      与使用者访谈,搭配使用个案,修订作业画面。
3.      与使用者确认作业画面。
3.4.2.系统分析
数据库分析(Database)
建立系统数据库,以储存系统资料。产出数据库关联图,数据库,表格。
1.      分析资料表格与资料表格关联。
2.      建立实体数据库。
3.      建立实体表格,定义字段。
4.      设定数据库使用者,表格使用权限。
共通服务组件(CSO)分析
找出系统会使用到的共通服务,并归纳出相关负责组件。产出共通服务组件清单,共通服务组件建构管理
1.根据系统使用个案,找出共通服务需求。
2.根据共通服务需求,依现行架构找出共通服务组件。
3.拟出共通服务组件清单。
4.拟出共通服务组件建构管理。
业务组件分析(BSO Business Service Object,BPE Business Process Edit)
找出系统会使用到的业务服务,并归纳出相关负责组件。服务接口由业务服务组件(Business Service Component)负责, 服务项目由业务处理组件(Business Process Component)提供。产出业务组件清单,业务组件建构管理
1.          依作业画面找出所有业务服务需求。
2.          依子系统区分,定义业务服务组件(BSO)。
3.          依业务服务需求定义业务处理组件(BPE)。
4.          拟出业务组件清单。
5.          拟出业务组件建构管理。
3.4.3.系统设计
共通服务组件(CSO Command Service Object)设计
设计共通服务组件服务界面(interface),产出共通服务组件技术规格。
1.          依需求设计共通服务组件服务界面。
2.          撰写共通服务组件技术规格。
业务组件(BSO,BPE)设计
设计业务服务组件与业务处理组件服务界面(interface),产出业务服务组件技术规格,业务处理组件技术规格。
1.          设计业务服务组件与业务处理组件组件服务界面
2.        撰写业务服务组件与业务处理组件组件技术规格
3.4.4.系统建置
共通函式建置
规范共通函式建构所在,规定引用路径,以进行撰写共通函式程序让所有程序引用。产出共通函式建置规范,共通函式使用手册。
1.          规定共通函式建构所在路径。
2.          规定引用原则与引用设定程序。
3.          传写与发布共通函式建置规范。
4.          撰写共通函式程序。
5.          共通函式测试。
6.          撰写共通函式使用手册。
共通服务组件(CSO)建置
规范共通服务组件设计程序,命名原则以完成共通服务组件。产出共通服务组件发布规范。根据共通服务组件清单,建置规范与设计规格进行建置,发布共通服务组件。
业务组件(BSO,BPE) 建置
规范业务服务组件与业务处理组件设计程序,命名原则以完成业务服务组件与业务处理组件。产出业务服务组件与业务处理组件发布规范。根据业务服务组件与业务处理组件组件清单,建置规范与设计规格进行建置。发布业务服务组件与业务处理组件组件。
定义业务作业(BPA-Business Process Action)是由那些业务处理组件(BPO- Business Process Object)的方法(Method)组合而成。自动产生编译式业务处理组件的主体程序代码,并支持直接于作业编辑器上用不同语言撰写解译式业务处理组件程序代码。
协力厂商组件安装(3rd Party Component)
规范管理所有外购组件,让系统所有程序引用。产出外购组件安装规定,外购组件之合法使用文件,规定外购组件建构路径,规定外购组件安装引用程序,保存外购组件合法使用文件。
主画面模版建置(System Manager & View Manager)
规范系统主画面功能布置与子窗口激活原则,以做为程序设计人员依循。主画面模版技术指引,决定主画面运作模式,决定主画面画面布置,决定子窗口激活方式,使用共通服务组件开发模版窗口与程序丛集,撰写主画面模版技术指引。
GUI模版建置
规范系统内所有基本资料之操作模式,所有交易操作模式,以做为程序设计人员依循。产出基本资料维护作业模版技术指引,分析基本资料维护作业共通性质,使用共通服务组件开发模版窗口与程序丛集,撰写基本资料维护作业模版技术指引。业务交易作业模版技术指引,分析业务交易作业共通性质,使用共通服务组件开发模版窗口与程序丛集,撰写业务交易作业模版技术指引。
WEB模版建置
规范系统内网页之操作模式,透过Web Manager是做网页画面编辑器,透过数据库的资料纲要机制,自动产生ASP、XML、XSL等档案。
报表查询作业模版建置
规范系统内所有查询操作模式,以做为程序设计人员依循。产出查询作业模版技术指引,分析查询作业共通性质,使用共通服务组件开发模版窗口与程序丛集,撰写查询作业模版技术指引。
其它作业模版建置
视应用系统需要,规范系统内所需作业之操作模式,以做为程序设计人员依循。产出其它作业模版技术指引,分析其它作业共通性质,使用共通服务组件开发模版窗口与程序丛集,撰写其它作业模版技术指引。
3.4.5.系统分发
将建置完成的系统,分发至使用者执行。
安装程序:将所需分发的档案包装成安装程序。
1.  测试数据库是否连通
2.  设定系统参数Registry
3.  安装软件组件
4.  安装系统主程序
使用手册:
1.  系统简介
2.  软硬件配备要求。
3.  功能特色说明。
4.  功能画面使用指引与说明。
5.  常见应用范例说明。
6.  常见问题回答。

作者:陈器中 | 文章来源:未知 | 更新时间:2007-11-4 13:40:03

  • 上一篇文章:

  • 下一篇文章:

  • 相关文章:
    软件开发过程中的性能设计
    软件技术
    · 开发语言
    · Java技术
    · .Net技术
    · 数据库开发
    最新文章  
    ·搜集整理的asp.net的验证方
    ·各种FOR循环结构的整理
    ·软件项目开发中应该考虑那
    ·搜集整理的javascript sel
    ·软件开发中项目经理有那些
    ·学习如何在Lambda表达式进
    ·C++基础知识:结构体数据的
    ·C#实现短信发送程序的例子
    ·sun最近修补了一部分java的
    ·rss定制的另外一种实现方式
    ·delphi实现利用arp欺骗来实
    ·基础学习:基于WF的流程框
    ·网络编程中怎样得知一次数
    ·如何逆序输出单链表?
    ·软件开发过程中的性能设计
    关于我们 | 软件开发 | 下载试用 | 客服中心 | 联系我们 | 友情链接 | 网站地图 | 新疆电子地图 | RSS订阅
    版权所有 © 2016 新疆二域软件开发网 www.k8w.net All Rights Reserved 新ICP备14003571号
    新疆软件开发总机:0991-4842803、4811639.
    客服QQ:596589785 ;地址:新疆乌鲁木齐北京中路华联大厦A-5C 邮编:830000