计算机行业论文范文

前言：我们精心挑选了数篇优质计算机行业论文文章，供您阅读参考。期待这些文章能为您带来启发，助您在写作的道路上更上一层楼。

第1篇

在领悟SWEBOK基本精神，认真学习GSwE2009及《规范》的基础上，针对一般行业院校硕士生培养目标是以培养从事行业软件开发及项目管理工作的软件工程和信息化应用人才为主的现状，笔者建立计算机科学与技术专业民航特色的高级软件工程教学大纲，见表1。表1的教学大纲设计兼顾SWEBOK及GSwE2009的核心知识体系，对SWEBOK的核心知识覆盖率达到76%，对GSwE2009覆盖率达到63.6%。然而，不管是SWEBOK还是GSwE2009，其核心知识点都是针对整个专业课程体系而设置，SWEBOK的《规范》建议494学时的最小核心学时数，GSwE2009则建议270学时的核心学时及200学时的交流学时，要在36学时内完成上述核心知识的详细讲授，显然不可能。因此，表1的设计本着宏观上抓概念、抓流程，微观上抓工具、抓编程的基本思想，在教学手段上，采用课内外一体化教学模式，要求学生在课下完成所有仿照案例的完整开发过程；在教学方法上，以案例推动软件过程概念及软件编码的学习，以工具熟悉软件过程管理及软件质量管理。要求通过该课程的学习，学生能熟练掌握软件开发过程的宏观概念，最终交付项目计划报告、基于MSProject的软件项目过程管理文档、经过3次迭代的原形软件及相关需求分析和软件设计文档，完成课程总结报告。

2民航特色的教学案例设计

教学案例设计是高级软件工程实施的核心内容之一，考虑到选课的大部分研究生已经具备基本的编程能力，但缺少软件过程管理的相关概念，结合中国民航大学特色及研究生就业趋向，笔者参考国际研究生教育现状[5]及文献[6]的模式，开发了一套基于民航航材管理业务的教学案例，用以完成课内教学。该教学案例以某航空公司航材管理系统为背景，采用敏捷开发思想进行过程管理，循序渐进，分3次迭代完成简单的原型系统开发。第1次迭代在介绍航空公司航材管理需求的基础上，建立系统的业务环境图，结合需求分析方法，利用ROSE工具建立业务用例及业务术语表。进一步地，缩小系统范围，只针对高价周转件的增删改查操作建立领域对象模型，包括领域用例模型、用例术语表、领域类模型，同时完成基本的编程实现。第2次迭代首先讲述体系结构设计的基本方法，基于MVC框架建立更适合信息系统开发的体系结构框架——PCMEF（表示—控制—中介者—实体—基础）[6]。在此基础上进一步细化第1次迭代需求，功能上增加高价周转件的供货方管理、合同管理功能；其次建立用例模型和用例文档，采用序列图、通信图、交互图等描述事务处理流程，进行概念类设计，对第1次迭代的设计按照PCMEF框架完成体系结构重构，完成用户界面设计，最终编码实现。第3次迭代增加高价周转件使用统计报表、机型使用记录、考虑机务维修周期的周转件库存管理等功能，设计上重点考虑数据库的安全性与完整性设计，同时基于JavaEJB体系结构建立业务组件，完成较高水平的软件编程；编写测试用例，完成整体测试。在上述3次迭代完成后，要求学生写出项目总结。笔者所在学院拥有一个行业特色鲜明的民航信息系统仿真实验室，该实验室目前拥有民航机务维修仿真实验系统、机场信息仿真实验系统、航空公司运行控制仿真系统、民航全球分销仿真实验系统等行业主流信息系统的仿真平台。学生在前序课程学习中，对这些信息系统的基本功能和相关业务已经有了一定程度的了解。

3教学组织与管理

3.1项目驱动教学法课程教学借鉴CDIO的教学思想，在讲授完软件过程模型及软件建模语言后，将学生每5人分组，每个人承担不同的角色，角色包括甲方需求提供人员、乙方项目经理、乙方质量保证人员、乙方编程人员（2人）。在整个学习过程中，经过一定时间后，每个人的角色可以互换。在讲授完案例1后，教师可以要求学生结合某个民航信息系统仿真系统，选择感兴趣的民航业务领域，分组完成项目计划任务书并使用MSProject完成项目的进度安排、人员分工、虚拟费用预算等。进一步地，使用Rose工具进行需求分析及UML建模，完成用例图、术语表、类图等分析设计，最后进行第1次迭代的编码并编写测试用例完成测试。在讲授完案例2后，教师可以要求学生在功能扩展的基础上，采用PCMEF模式对第1次迭代程序进行重构并完成编码与测试工作，同时要求项目经理使用MSProject，跟踪和检查项目实际进度与虚拟费用预算，进行适当调整。本次学习重点在于体系结构设计、增量模式开发思想。在讲授完案例3后，教师可以要求学生继续扩展功能，重点进行数据库与业务组件设计。

3.2成绩评定在课程进展的每个阶段，教师展示实际软件公司的文档范例，要求每组提交该次迭代的相关文档，进行软件演示并答辩。答辩内容包括项目计划制订、人员分工、虚拟成本、进度偏差分析、预算偏差分析、程序设计技术、缺陷分析等。评委由教师及各组项目经理组成。成绩评定包含文档规范性、设计合理性、实现正确性、项目过程管理执行情况4项内容。课程整体结束前，由3次迭代的评定成绩取均值作为小组平均成绩，最后小组项目经理和教师共同依据小组中个人对项目的贡献以及小组均值打分，将其作为个人成绩。

4结语

第2篇

【摘要】

    本文以某通信公司的业务报表系统开发为例，讨论了软件需求分析工具与方法的选用。我们认为，软件需求分析是软件工程中重要的一步，直接关系到后继工程的进行以及最终的产品能否满足用户的需求，因此在整个工程中起着关键性的作用。采用适当的工具，有可能显著减少需求阶段的错误，也可大幅度提高需求分析的质量和工作效率。当然工具的选用应当与实际的项目相结合，充分地发挥工具的作用。本文结合我们工作的实际经历，简要讨论了开发系统时所选用的工具及其应用，选用时所考虑的原则以及所碰到的问题。在文中也结合多种开发方法（即传统的瀑布法、信息工程法、面向对象的方法）的比较，指出各种方法的不足之处，说明我们所采用的工具对软件需求分析所起的作用，以及相应产生的效果。

【正文】

    我在某市一家通信公司工作，作为一名技术骨于，受领导委托，参与了开发本公司的业务报表系统，我担任系统的需求分析、总体设计和部分代码的编写工作。

    我所在的企业作为一家通信运营公司，分为总部、省级公司和地市级分公司三级，各级公司之间都有数据报表的要求。但是，每一个地市分公司因所处的地方不同，经营环境不同，所面临的问题也不一样，因此形成了各具特色的数据报表（除地市分公司向省公司汇报的之外）。公司又分设了许多部门，这些部门也都会需要数据，作为分析决策的依据。因此，了解各个部门的需求就成了业务报表系统的关键。

    在调研的过程中，我选用了一种工具叫Play CASE，可以从网上免费下载，有很强的功能。下面就介绍一下，在需求分析阶段，我是如何使用这一工具的。

    第一步，了解业务组织结构。公司内部的数据实际上是在部门之间流动的。业务部门需要知道在本地覆盖区内各基站的话务量、当天的话务量（即话务量的时空分布）。财务部门需要知道本月各类用户的话费收入、预交款收入、与其他电信运营商的网间结算等。计划部门需要各部门的分析数据。计费部门需要提供本月的账革统计数据、话单统计数据分布（比如分别按照基站分布、时段分布以及按用户类别分布）、预交款统计数据、当前的欠费总额分布、催缴情况等等。这些部门时常为了数据而产生了大量无谓的争议。在使用Play CASE工具时，先要将这些部门录入到Play CASE的“业务部门”中．构成了一个信息源的接收点（或发送点）；而Play CASE通过图示表示了这些部门的关系，并转换成了相应的软件结构。实际上，这是一种系统建模的方法，即把业务系统中的各个组织转变为软件功能中的各个结构。这样，在需求分析阶段，明确哪些部门需要数据，从而保证了需求分析对整个公司的全面性，而不会忽略掉某一个部门，导致需求分析的不完整。

    第二步，了解各个业务部门中的业务流程，使之通过Play CASE转换成软件的运行过程，这是一种动态建模的方法。在上一步的基础上，追踪各个部门的行为，录入到Play CASE中，并以形式化的语言描述各过程。对于复杂的过程，该工具还提供了进一步细化的方法，并且形成了业务流程图和业务状态图。根据这些流程图、状态图与实际业务部门的业务相结合比较，还是较为吻合的。在此步的实施过程中，运用了动态建模技术，使各部门业务流程的情况在软件的运行过程反映出来，从而保证了需求分析阶段中运行过程的描述能真实地反映实际情况，防止在后继的程序编写过程中，可能会经常发生的一类情况：程序员因为没有理解业务流程而出现“闭门造车”的现象，从软件的功能角度上保证了软件的正确性。

    第三步，将业务数据转变为软件数据，这一步工作实际上就是收集各部门所需要的数据。分析各部门需要的数据都有哪些；以及数据是如何转换的，这可以归入“功能建模”的范畴。将这些相应数据录入到Play CASE中，选定所属的部门。这时就自动地建立了DFD图（数据流程图），数据字典，省去了人工建立时的很大麻烦。

    第四步，将业务上的数据关系转变成软件中的数据关系。这里采用了面向对象的方法，把业务部门所需要的数据看作一个实体，部门间的数据关系就是实体之间的关系。比如：经营部门所需要的用户资料、用户话费，实际上就是用户这一实体与账单这一实体间的关系。Play CASE提供了构件（不过我觉得是部件更为合适一些），来表示对应的数据，并提供了三种构件的表示关系即组装关系、分类关系与相连关系。这三类关系基本上反映出了现实世界中的业务数据之间的关系。例如现实世界中的用户资料与用户话费，在Play CASE中，可将用户构件与账单构件用相连关系表示。这种方法，实际上是借鉴了OOA面向对象的分析方法中的类、聚集、继承、封装等概念，能较好地反映出现实中的业务；同时，这一步的工作也为总体设计中数据库的概念模式设计奠定了很好的基础。

    经历了上述四个步骤以后，利用Play CASE工具自动生成了软件需求规格说明书、初步的DFD图和业务流程图，为下一步的总体设计打好了基础。

    使用Play CASE工具，使需求分析既能继承传统的结构化分析方法，又能吸收面向对象设计方法的优点。比如能把业务流程转变成为运行过程，业务组织转变成了软件的结构等都体现了这一点。而在运行过程中，对复杂过程的细分以及追踪则反映了传统方法中的自上到下分解的分析思想，这对于解决复杂系统的分析是很有帮助的。

    通过使用，我觉得这个工具还是很不错的。因为它实际将以下四个方面的问题结合起来了：软件、业务、开发人员和用户。对于用户而言，Play CASE用图形化的方式显示出业务流程，使用户了解业务在软件中的运行过程，提供了将来验收软件时的依据。对于开发人员来说，使开发人员能更清楚地了解业务流程，不会再发生“因为不理解用户的需求而出现的闭门造车情况，从而导致开发出来的产品不符合用户需要”的现象。因此，Play CASE所自动提供的需求说明书能够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理解。

    使用Play CASE工具后，使我们的需求分析取得了很好的效果，不但能自动地提供许多结果，如需求说明书等；还使需求的质量有了很大的提高，受到领导的赞扬（领导不是学计算机的，但对公司的业务十分熟悉）；在后继的设计与维护工作中，我们感到工作似乎轻松了很多。

第3篇

【摘要】

基于Web技术的数据库应用是当前应用的一个热点，在用户数目与通信负荷很大的场合，提高Web服务器性能是一个迫切的课题。本文从笔者参与某个银行系统项目开发的经历出发，阐述了提高Web服务器的性能应渗入到项目论证、选型、开发、运行和管理的各个环节，只有各个环节都能充分考虑到性能与质量的需要，系统的性能才是真正可保证的和可扩充的。

文章从系统的实际运行与相应的经验出发，阐述了性能改进方面的一些具体措施。

比如：在本文中讨论了Web服务器平台的选型考虑；Web服务器的配置管理；应用系统本身的优化与预先设计系统时可扩性的性能保障等具体内容。

通过技术上的分析与改进，综合性地运用多类措施与手段，在实际系统中，Web服务器运行的性能得到了一定程度的保证。

【正文】

我所在的单位是把目标定位于金融领域开发IT应用的一家信息技术公司。随着金融电子化建设的发展和商业银行之间市场竞争的加剧，各主要商业银行不断通过信息技术提供新的金融产品，并且希望能整合市场渠道。比如主要的商业银行不断推出形形的网上银行服务。在这种背景下，本人参与了开发新一代网上银行产品，涉及到提供网上个人理财服务、网上外汇买卖服务、网上企业服务等具有市场竞争力的产品。作为项目开发的组织者之一和主要的技术骨干，在整个项目开发过程中始终要处于第一线，从而在改进Web服务器性能、提高整个网上平台系统性能方面收获良多，在本文中简要讨论如下，希望与读者们共享经验。在Web服务器配置与优化方面，我有如下几方面主要的体会：

第一方面是Web服务器选型考虑。

在Web服务器选型及网上平台搭建之初，我们就已充分考虑整个网上平台的性能及可扩展性问题。这一考虑为该系统的稳定性及扩展性能力方面打下了坚实的基础。

某银行原有的一些网上产品由于开发较早，故而采用的是老式的HTTP Server+CGI程序调用的方式。这时，每一客户请求需要对应于后端系统的系统进程来运行CGI程序来处理，系统的开销相当大，系统的扩展能力也很差，性能已不能满足业务处理的需要，故而在为此银行系统具体选型的时候，我们一开始就否决了这种方案。

通过市场上同类产品的比较选择，我们选择了国际商业机器有限公司IBM的Web Sphere产品系列作为该行网上银行系统的建立平台。作出这样选择是因为Web Sphere基于使HTTP Server和应用服务器相分离的整体架构，同时支持JSP、Servlet和企业组Java Bean等轻量级线程规范，所有的请求对应于应用服务器上的处理线程，系统的开销低、效率非常高，同时Web Sphere整个体系结构相当的灵活，为适应扩展需要可以作不同的横向和纵向扩展，从而可以满足各银行未来的扩展需要。

正是因为在一开始选型的时候我们就已考虑到未来的扩展需要，整个系统在接下来的几次性能改进方面，我们大体上都能相对顺利地达到了预期目标。

第二方面是Web服务器的性能配置。

在一开始系统上线的时候，由于系统的负荷不是很大，为了节省系统总拥有成本TCO投资，我们在一台较低配置的IBM RS6000上投产了该系统。整个系统的HTTP服务器、应用服务器、通信服务器等均位于该台机器上，由于初始投产时用户不多，所以系统的性能基本上能令人接受。

但随着业务的发展和用户访问量的增大，我们发现该服务器的响应变慢，系统的CPU利用率和内外存交换显著增大。经过跟踪，我们发现关键原因之一是系统的内存不足的缘故。由于网上服务器把大量用户的会话信息保存在内存中供给应用系统使用，当内存不足时，大量Session信息被迫交换至硬盘，大量CPU时间消耗在等候内外存的交换上，系统效率迅速下降。

鉴于这种情况，我们把该服务器的内存由2GB扩充为4GB，同时相应调整用户会话信息的保存时间，这样整个系统的效率又回到较为理想的状况。

由于新应用的不断投产及数据库操作的日益增加，我们后来逐渐监控到系统的数据库处于繁忙状态，系统的错误日志也记录下了供应用服务器使用的数据库连接处出现资源不足的情况。在这种背景下，我们认为整个系统由于硬件配置所限，应该进行横向扩展，因此我们把数据库服务器分离出来，配置到另一较高性能的服务器上，相应定义的数据库资源也大幅增加，这样整个系统的性能又处于较为理想的状况。

第三方面是对应用系统进行相应的优化以提高性能。

Web服务器配置及相应的硬件扩展不失为解决系统性能问题的一条捷径，但应用系统的优化也是应该重点加以考虑的，毕竟它能够在投入较少的情况下提高系统的运用效率。

在开发的初期，我们就已经十分注意系统的利用效率，比如提醒程序员尽量不要利用用户会话信息(Session）来传递大的对象，对于内存要注意回收等。同时，通过内部的交流会推广与介绍一些小的、有用的编程技巧来提高开发人员的水平，通过代码的抽查，希望能在早期就发现问题等。

在系统运行期间，我们通过监控发现，应用服务器所基于的Java虚拟机，其内存堆的空闲空间有不断下降的趋势，每隔若干天导致空间消耗殆尽、无法分配新对象空间，从而导致系统重启。在排除了系统本身问题的原因外，我们确定为应用系统的开发有问题。通过从网上万载IBM公司检测Java虚拟机的相关工具对JVM进行监控后终于发现系统内部存在着不能回收内存的对象，再通过查找相应的程序发现在该程序中有“环状”的对象引用，从而导致对象使用后不能被垃圾收集器所回收。这个问题的解决过程虽然十分艰苦，但由于该问题不能通过升级硬件或增加资源配置而得到根本解决，会给系统带来很大的隐患。所以，整个过程的分析与解决是完全值得的，更何况通过查找故障原因的过程，给整个项目组上了生动的一堂软件质量保证课，对项目组的质量意识起了很大的促进作用。

所以说改进Web服务器的性能井不单纯是系统管理方面的工作，它渗透到开发以及

系统运行等一系列环节中。

第四方面预先考虑未来的扩展与性能需要。

随着系统的发展及成熟，考虑到用户访问量的不断上升，为了预留系统的发展空间，我们最近又对整个系统作了一个系统性的升级。通过引入多台HTTP服务器及应用服务器并行工作提高整个系统吞吐量及单点故障克服能力。由于在一开始选型的时候就已经充分考虑到动态负载均衡及横向扩展方面的需要，这一项的升级无需对整个系统的体系结构作根本的变革，对应用程序来说，更是没有造成任何影响。