软件测试工程师的职责

软件测试工程师的职责（精选12篇）

软件测试工程师的职责 篇1

摘要：当前软件测试工程师绩效考核存在的问题主要表现在:考核定位模糊并存在偏差, 重考核、轻管理, 重结果、轻过程, 考核主体单一, 企业管理者没有承担起绩效管理的责任, 绩效考核指标不全、标准不明。测试工程师绩效考核要明确考核的目标, 突出测试人员在考核中的主体地位, 构建一体化绩效管理体系。

关键词：测试工程师,绩效管理,体系

软件测试工程师绩效考核是IT企业根据发展战略和使命要求, 对测试工程师的工作业绩进行考察和评估, 包括工作行为和工作效果。随着中国软件业的迅猛发展, 软件产品的质量控制与质量管理正逐渐成为企业生存与发展的核心。为了保证软件在出厂时的“健康状态”, 几乎所有的IT企业在软件产品发布前都需要大量的质量检测工作。测试工程师作为软件质量控制中的重要一环, 其绩效考核成为企业了解测试人员队伍状况, 监控测试人员工作过程的重要手段。

软件测试工程师绩效考核是IT企业人力资源管理的中心环节, 是测试人员薪酬、晋升、人事调整、职称评定等决策的基础, 并且为企业制定测试人员的培训、开发计划及长期职业生涯发展规划提供依据。测试工程师绩效考核的有效性直接影响到人力资源制度的激励效果和企业管理的公平性, 并对测试人员的工作满意度有重要影响。然而, 现实的绩效考核工作往往不尽如人愿。许多测试工程师遇到考核时深感不安, 产生焦虑, 害怕甚至反对考核;很多测试人员认为考核是走过场, 抱着无所谓态度。理论上的必要性和重要性与现实中的困惑形成强烈反差。为此, 我们有必要对测试工程师绩效考核存在的问题进行反思, 从而构建能满足企业和测试工程师共同发展的绩效管理体系。

一、软件测试工程师绩效考核存在的误区及其分析

(一) 考核定位模糊并存在偏差

考核定位, 就是通过绩效考核解决什么问题。考核定位模糊主要表现在考核缺乏明确的目的, 仅仅是为了考核而进行考核, 这样做的结果往往导致考核流于形式。考核定位偏差主要体现在片面看待考核的目标上, 对考核目的定位过于狭窄。目前许多IT企业绩效考核的目的仅仅是为了期末发奖金或津贴, 将考核定位于确定利益分配的依据和工具。

(二) 重绩效考核轻绩效管理

绩效考核和绩效管理既有本质上的区别, 又有一定联系。传统绩效考核以管理者为中心, 强调服从和外部控制, 着眼于过去, 注重成果, 是一种被动反应、事后解决问题的管理方法。现代绩效管理则以测试工程师为中心, 强调承诺和自我控制, 着眼于过去、现在和将来的有机统一, 是一种主动开发型、在过程中解决问题的管理系统。绩效管理是一个完整的系统, 绩效考核只是绩效管理中一个不可或缺的组成部分和环节, 绝不能将其等同于绩效管理。

(三) 重考核结果轻考核过程

绩效是工作成果与工作行为的统一。许多IT企业重视对绩效中的工作结果考核, 而忽视了绩效中的行为指标, 这表现在许多项目组重视项目完成进度而轻视测试过程, 重视项目的数量而轻视其质量, 尤其是轻视与测试工程师行为有关的工作动机、热情度、忠诚感等“周边绩效”考核点。这可能与企业受功利主义思想影响、追求短期利益有关, 或者可能与工作结果容易量化, 而行为不易评估有关。

许多项目组在项目初期给工程师布置测试任务和预期应完成的指标, 期末予以检查, 而对工程师完成任务和指标的过程不管不问, 既不对完成任务过程中出现的问题予以及时纠正, 也不对测试人员在工作中遇到困难和阻力时提供帮助和支持。这种秋后算账的做法容易造成管理者与被考核者的对立, 不利于测试人员的成长与进步。

(四) 考核主体单一

目前, 项目经理考核测试工程师已成为一种普遍运用的评价方式甚至是唯一的评价方式。项目经理考核有一定可信性, 但也存在一些弊端, 如测试人员一味地迎合项目经理的指令, 淡化了整个团队的沟通协作, 忽视一些测试人员不可控制因素的影响而造成考核不公正等。测试工程师在考核时处于一种被动地位, 或者消极被迫接受, 或者导致内部冲突升级。项目组也不重视同行专家的评估意见或根本不吸收同事参与考核。

(五) 绩效考核指标不全, 标准不明

考评项目和指标的选择是否恰当, 是否全面、相关, 定义是抽象含混还是具体明确, 对考核结果影响很大。如果绩效考核标准不明, 则不同的考核者可能对优、良、一般、差等绩效标准做出不同的解释, 从而造成考评者偏松或偏紧或趋中倾向, 造成考核结果的误差。以测试人员业绩考核为例, 业绩考核包括整体工作效率、工作结果、过程控制三项一级指标。其中, 工作结果可以分为测试用例的数量和质量、bug的数量和质量、测试自动化程度及收效等多项二级指标, 若不对这些定性指标给出明确定义, 则考评时易出现主观随意现象。因此, 界定应具体明确。如bug的数量和质量可定义为:提交bug的数量 (根据项目的不同而确定经验值) 、提交bug的时间段 (具体统计在测试的每个阶段) 、发现bug的比例等。

二、软件测试工程师绩效管理体系的构建

(一) 明确测试工程师绩效考核目标

Bevan和Thompson (1991) 认为绩效管理的主要目的是“促进人力资源管理不同组成部分的整合, 并使它们与公司的经营目标紧密联系在一起。”测试工程师绩效考核的目标, 一是为企业的发展服务, 支撑企业使命和战略的实现;二是服务于工程师个人需要及其职业进步。

(二) 构建一体化绩效管理体系

绩效管理就是根据组织的要求, 对雇员进行指导和支持, 使雇员尽可能地以更高的效率完成自己的工作。从狭义角度理解, 绩效管理系统由制定绩效计划, 持续的绩效沟通与绩效信息收集, 绩效考核, 绩效反馈、诊断与辅导等部分组成。从广义上讲, 绩效管理系统由绩效管理的影响力量、狭义的绩效管理系统、绩效管理的运用和目标等部分构成。

广义的绩效管理系统包括以下3部分:对影响测试工程师绩效的原因进行分析, 尤其是从企业内部的组织结构、领导方式、企业文化、招聘和聘任制度、岗位分析等方面探讨与测试工程师绩效有关的因素;狭义的绩效管理系统;绩效管理的目标, 包括绩效管理要达到的组织目标和测试工程师个人发展目标 (见图1) 。

制定绩效计划和考核目标的目的是为了清楚地说明企业期望测试工程师达到的结果以及为达到该结果所期望测试人员表现出来的行为和技能。管理者通过与被考核者协商, 共同制定与企业使命相关的具有挑战性、可实现性、具体明确且有时间限制的绩效计划。持续的、动态的绩效沟通就是管理者和被考核者共同工作, 以分享有关信息的过程。这些信息包括工作进展情况, 潜在的障碍和问题, 可能的解决措施以及管理者如何才能帮助被考核者。这些信息必须是有据可查、准确真实的且与绩效相关的信息。管理者可通过面谈, 向其他同事了解意见, 查看被考核者的工作记录等方式获取信息。绩效考核包括测评内容、何时测评、哪些人参加测评、测评方式及责任等。绩效诊断与辅导, 是管理者和被考核者双方合作, 共同寻找导致绩效低的原因, 以及帮助被考核者提高未来绩效的方法, 涉及处理矛盾、准备反馈面谈、解决问题和重新设定目标等内容。

(三) 实现测试工程师绩效考核主体的多元化

在传统的测试工程师绩效考核中, 将工程师排斥在外, 测试人员作为被考核者处于被动应考的地位, 被考核者与考评者的这种对立状态造成测试人员不认同、不支持考核, 使其考核失去应有价值。虽然测试工程师可能由于认知或自利性偏差 (根据归因理论, 测试人员可能将自己的成功归之于自身的能力与努力等内因, 而将其失败或绩效不理想归之于工作难度和机遇等外因;而对别人的成功与失败归因与自身归因相反) 和自我防御心理的原因, 测试工程师有高估自身的业绩, 而看不到或有意掩盖自身存在的问题的可能性, 但可以通过构建系统化的绩效管理系统, 明确绩效考核的目标, 管理者与被考核者的平等沟通, 以及通过考核主体的多元化 (除测试工程师本人外, 还有领导、同事、客户等) 等方法来避免这些弊端。

(四) 构建测试工程师绩效考核合理分工、各司其职的组织管理机构

对测试工程师的绩效管理是企业人力资源部和项目组的共同责任。人力资源部主要从事组织、指导和协调工作, 具体职责包括培训考核者、规范考核制度、制定各种考核表格、发放及统计等工作。考核由项目组具体组织实施, 包括测试工程师工作任务的安排、考核指标与内容的确定、考核方法与时间的确定、考核主体的组织、考核结果的反馈、绩效改进与提升等工作。项目经理首先应当是一名合格的人力资源管理者, 应把人力资源管理工作如激励、员工发展、绩效管理纳入企业的议事日程, 并构成企业管理者对项目经理考核的重要内容。当然, 这需要改变目前IT企业高度集中的人事管理体制, 将部分人事管理权由企业下放至项目组。

(五) 根据测试工程师的工作特征, 建立考核内容全面、结果与行为 (过程) 并重的绩效考核机制

测试工程师作为专业人员和知识工作者, 在其需求和工作方面存在以下特征:追求工作自主, 不愿意受过多的外部控制;个人品性对测试工作及其事业影响很大;需求具有多样性和复杂性, 既追求较低层次的需要, 如生理、安全需要, 又追求较高层次的需要, 如受人尊重、自我实现的需要;工作具有分散性、个体性等。这些特征要求在测试工程师绩效考核时注意以下方面:一是绩效考核内容要全面, 德、知、能、勤、绩一样都不能少。测试工程师品德潜移默化影响其对测试工作的态度;知识包括测试工程师应掌握的专业技能及业务知识、个人素养;能力包括软件测试能力、沟通与团队协作等方面。二是测试工程师绩效考核坚持结果与行为 (过程) 考核并重。Brumbrach (1988) 认为“绩效指行为和结果。行为由从事工作的人表现出来, 将工作任务付诸实施。 (行为) 不仅仅是结果的工具, 行为本身也是结果, 是为完成工作任务所付出的脑力和体力的结果, 并且能与结果分开进行判断。”Borman和Motowidlo (1993) 认为行为绩效包括任务绩效和关系绩效 (周边绩效) 两个方面。任务绩效指正式工作职责和所规定的行为, 关系绩效指自发性行为或超职责行为。由于测试工程师工作的效果难以量化, 且具有滞后性和共同属性。因此, 在坚持完善目前通过测试工作量和测试用例等结果指标衡量测试工程师绩效的同时, 企业还要重视对测试人员行为, 包括团队合作行为的考核, 尤其要关注关系绩效的考核, 这对克服测试人员工作分散化, 形成合作的团队以及按质按量地完成项目组的目标有重大意义。

参考文献

[1]、张剑虹.绩效管理工作中的七个误区[J].企业改革与管理, 2003 (5) .

[2]、理查德.威廉姆斯.组织绩效管理[M].清华大学出版社, 2002.

[3]、陈雄政, 余凯成, 程文文.人力资源管理与开发高级教程[M].高等教育出版社, 2004.

软件测试工程师的职责 篇2

1.参与需求评审、用例设计、测试执行等工作;

2.完成对产品的功能、自动化测试，汇总测试执行情况，编制相关报告;

3.负责金融类项目的测试工作;

任职要求：

1.计算机及相关专业(统招专科以上)学历，7年以上工作经验;

2.了解软件生命周期、测试流程、设计方法和基本规范;

3.了解数据库，可以使用基本的sql语句辅助测试;

4.熟练使用QC、redmine等相关缺陷管理工具;

吞下“职场毒药” 的软件工程师 篇3

2007年1月，33岁的曾杰即将硕士研究生毕业，1月中旬，北京市人才中心组织了一场大型研究生就业专场招聘会，北京市各大用人单位纷纷到场揽才。

一家著名大型科技公司的招聘面试官黎莉时年43岁，是这家央企的副总工程师兼研发部主任。那天，她身穿黑色职业西服套装、略施粉黛，显得庄重大方。曾杰根据经验判断，这是一个严谨干练的领导，如果博得其好感，一定前途无量。

10年前，曾杰以优异成绩从西南一所大学毕业后，进入北京某航空科研所工作。2001年他在工作中与女同事王燕相识并结婚，之后跳槽到某著名软件公司担任了项目经理，并考上研究生。10年间历经职场磨砺，他积累了丰富的职场经验，尤其对很多“职场潜规则”了然于胸……

轮到曾杰面试时，他的学习成绩让黎莉感到满意。黎莉问曾杰对待遇有什么要求时，他直接问道：“如果应聘成功，我可以在您手下工作吗？”黎莉惊诧地说：“这很重要吗？”

曾杰自信地说：“士为知己者死，看得出您具有伯乐的眼光和卓越的领导能力，如果我能有幸成为您的部下，待遇和前程都不会成为问题！”

虽然是恭维之言，但曾杰说得淡定而真诚，让人觉得毫无拍马之嫌。黎莉也掩饰不住内心的喜悦：“小伙子，你很优秀！我真诚地希望你我能成为同事！”

果然，曾杰不久就被公司聘为软件分析师。入职后，黎莉则直接点将，把他要到了自己所在的部门。

进入公司后，曾杰对黎莉有了更多的了解，她是北京人，出生于一个高级知识分子家庭，作风严谨，工作敬业，研究成果多次获得国家大奖。得知这些，曾杰觉得在这样优秀、严厉的女上司手下工作，是自己的幸运！曾杰自有他的职场潜规则：忠于上司比忠于公司更重要。

从进入公司第一天起，曾杰就开始加班，整整一年下来，几乎每晚都要加班到10点钟才回家。曾杰心甘情愿的付出，也博得了黎莉的好感，有时出门办事，还叫上他一起去，经常将一些重要工作机会派给他去做。一时间，大家都觉得这个新来的研究生很受黎总器重，纷纷对他刮目相看……

曾杰的努力没有白费，2007年5月，公司接到为一个软件测试项目的任务，黎莉指派曾杰担任研发小组负责人。曾杰将做好的软件方案交上去，结果被黎莉否决了：“你这个软件不完善，漏洞很多，必须重做！”

曾杰感到非常窝火，他觉得自己的方案完美无缺，回来就跟研究小组发牢骚说：“我的方案是最好的，她有意刁难我。”曾杰一个同事知道黎莉工作上追求完美，建议他拿给其他有经验的老同志看一看。其他人看过该方案后，尽管觉得不太理想，但碍于同事面子不好直说，只是肯定曾杰有一定的想法，鼓励他重新做一套方案，也好在黎莉那里交差。

2刚愎自用惹上司，职场家庭四面楚歌

当曾杰跟小组成员再次拿出一套方案后，在内部会上讨论时，黎莉仍然不满意。曾杰遭到批评时全部门的人都在场，他顿感颜面扫地。气急之下，曾杰大声喊道：“这半年多来我辛辛苦苦加班加点为你卖命，你有没有一点恻隐之心？老子不干了！”说完，把方案重重摔在会议桌上。

黎莉也毫不示弱：“你要搞清楚，你加班加点工作是为了公司为了工作，不是为了我。你对组织的忠诚和对个人的忠诚，孰轻孰重？我跟你没有什么私人恩怨，我必须对客户负责，你这样的东西拿给客户，会砸了公司的牌子！”

两人争吵了十几分钟后，曾杰悲哀地发现，自以为恪守“忠于上司”的“职场潜规则”，最终却落得个当场出丑。他想到了换工作。但辞职意味着他和读研的妻子生存困难，犹豫过后，他决定留下来把手头的项目做完，希望继续得到黎莉的认可。

可等曾杰把项目做完之后才得知，黎莉已经将任务交给别人。得知此讯，做了无用功又受了冤枉气的曾杰一声不吭地回到办公室，把材料摔在桌子上，大声吼道：“独裁、霸道、瞎指挥！”

2008年1月，曾杰找到主管自己部门的领导，提出想去市场部工作。但那位领导语重心长地告诫他说：“身在职场，要搞好上下级以及内外部客户之间的关系，我觉得你是可造之才，好钢要用在刀刃上，跟着黎总好好学习吧。”

曾杰闻听此言，只好讪讪而退。黎莉见曾杰如此自负狭隘，就把他晾在了一边，再也不给他派重要任务。

2008年3月，曾杰的妻子怀孕了，生活压力陡然加大。妻子是北京一家航天科技公司的普通职员，月薪只有四千余元，而且正在读研究生，生活几乎全部靠曾杰。两人在北京这种大城市生活，还要养孩子，确实捉襟见肘。即便如此，他也不敢冒风险辞职去赚取无法预知的收入。

为了表达自己的愤怒，曾杰从此以照顾怀孕的妻子为由消极怠工，再也不去加班工作，以此抵抗黎莉的管理。

在郁闷和纠结中，2008年12月，曾杰的孩子呱呱落地。妻子住院生孩子花了一万多元，其中3000元是找朋友借的。窘迫之下，妻子帮曾杰找了个兼职项目，让他下班后加班加点干。

屋漏偏逢连夜雨，孩子出生后一直莫名其妙地拉稀，经常在深夜里哭闹，吵得曾杰睡不着觉。曾杰晚上熬夜干兼职到两三点，白天上班没精神，自然遭到黎莉更多的指责训斥。但曾杰都忍下了，因为他更热切等待年终奖早日发下来，以缓解燃眉之急！

2009年2月，眼看临近春节，曾杰终于听其他同事说年终奖到账了。可是他发现自己没有年终奖。曾杰去质问黎莉，黎莉说：“你今年业绩很差，没有年终奖，像你这样的还有好几个呢，又不止你一个人！”

曾杰当即就火了：“我没有成绩是你不给我机会，到头来你却怪我没努力，你太欺负人了！”“我给了你很多机会，是你自己能力差做不好！”黎莉也当仁不让。随后，两人大吵一场。当晚，曾杰喝了很多酒解闷。

半夜，曾杰半醉半醒地回到家，发现妻子和孩子都不在家，他倒头就睡了。半夜三点多，妻子抱着孩子头顶雪花扑进家门，一进门就抱怨说：“你说现在的医院有多黑，不就是孩子拉稀嘛，输了一瓶液，开了两盒药，就花了上千块！”原来孩子又病了，妻子抱着孩子去了医院。

软件测试工程师的职责 篇4

一、培养思路和措施

按照“卓越工程师”的有关要求，我们认为，软件测试工程师的“卓越”培养标准须包两个方面：一方面是专业标准，即具备从事计算机工程工作所需的人文与社会科学知识，特别是工程基础知识；掌握计算机科学基础理论知识和计算机系统分析、设计、实现、测试、维护、和管理的基本方法；掌握综合运用测试理论与技术，对计算机系统进行系统化的测试工程；熟悉信息系统项目的组织和管理过程，具备综合运用知识和技术进行工程项目组织、实施和管理的能力，能够解决实际工程问题；具有良好的工程职业道德和社会责任感。另一方面是行业标准，即具有国家“计算机技术与软件专业技术资格”中“软件评测师”要求的知识和技能；掌握ISTQ B国际软件测试工程师认证的知识体系结构；具有一项以上“职业资格证书”；拥有1年以上工程项目、企业实习等的工程实践经历。围绕上述培养标准，我们需要将工程教育理念贯穿于整个培养环节，以反映测试行业及相关软件工程技术的课程体系改革与能力训练为核心，优化和整合教学内容和课程体系，重点强化实践教学内容和革新教学评价体系，制定校内和企业两阶段相融合的过程化培养方案，培养学生的工程素质、职业素养和实践能力。为此，需要分别制定相应的校内培养方案和企业培养方案。

（一）校内培养工作思路

首先，在人才培养模式上进行改革。在大学一年级结束时，通过双向选择的方式，为每个学生确定“工程教育导师组”。导师组由高校教师、企业高级工程师和一线工程师组成。在毕业总学分限定条件下，导师组为学生量身定制个性化的3～8学期的教学计划，在专业和课程选择上给予学生更大的自主权和选择权。将工程过程管理的思想应用于人才培养过程，采取动态的、滚动的、竞争的人才培养运行机制。在测试工程师的专业课程中，要求有1/3课程采用双语教学，1/3课程由企业人员授课；要求80%以上的专业课程中理论讲授与实验实践教学比例逐步达到1:1～1:2（专业基础课理论与实验实践教学的课时比为1∶1，工程教育和专业选修课为1∶2）。

其次，优化课程体系结构，理论教学与实践教学有机衔接，课程设置以工程实践能力和创新能力培养为主线，适当减少课程理论教学学时数，增加实践教学学时数和实践部分的学分比例，注重工程系统的思维训练。在教学中注重先进性、实用性、实践性和研究性课程的建设，促进教学内容向应用研究型转变、教学方法向培养能力型转变、教学手段向综合立体型转变。在专业课程中大力推进问题型、项目型、案例型、研究型、CD IO（构思、设计、实现、运作）式等教学方式，按照《软件工程知识体系指南》（SW EBO K）和ISTQ B测试认证知识体系[3]为参考进行课程内容改革和建设。

第三，进一步整合和改造包含基础性实践、设计型实践和综合/创新型实践课程在内的多层次实践教学体系，重点建立技能综合训练实验课程，加大综合性实验和创新性实验的开设力度，要求学生完成综合性的、较有规模的软件的测试分析、设计、实现和管理。

最后，改革以理论考试为主评价学生能力的评价体系，建设多元化工程教育评价体系，将学生的工程能力分解为工程技能、工程素质、工程活动和工程成果多维要素，建立对各个要素的细分量化评价指标集。教学评价要将过程考核与结果考核相结合，逐渐加大过程性评价的比重，引导教师从考核学习成绩向评价学习成效转变，引导学生从注重考试结果向注重学习过程转变。校外培养环节考核由学校和企业共同进行，标准与正式员工相近或相同。丰富考核方式，包括笔试、面试、工程实践成果的数量统计、书面总结材料及质量评定、专业汇报和答辩、能力和素质的评价等。

（二）企业培养思路

企业学习环节是“卓越工程师”培养计划的重要教学环节，企业学习阶段的学习效果是关系到整个培养工作成败的一个关键因素。在企业学习期间，学生的主要任务是基于已有的理论知识和专业技术培养解决实际工程问题的技能。企业培养方案应由校企双方共同研究制定，其中对学生在企业学习阶段的培养目标、培养标准、实践条件、教学安排、师资力量等方面做出明确的规定，要明确学生在企业培养阶段要达到的目标。企业学习阶段方案应当包含在企业完成的认识实习、生产实习、毕业实习、毕业设计等实践环节，学生接受近似企业员工的管理，要求学生累计1年时间在企业完成测试相关的课程设计、工程项目实训和毕业设计。企业学习主要采用面向主题的方法来组织学习活动，从各个面向主题的学习活动中获得对理论和技能的提升，从而反过来完善自身的理论体系和实践技能。培养方案需要精心设置企业学习阶段训练项目和训练内容，制订企业学习阶段各周的训练项目及明确的训练内容、训练时间、训练要求和考核办法，使学生在企业学习阶段的学习任务安排落到实处，保证企业学习阶段的教学质量。表2展示了我们设计的一个以主题导向的企业培养参考方案。

企业阶段的学习考核由学校和企业共同进行，考核内容除了知识和技能之外，还重点考察工作态度、创新能力、团队协作精神、实际操作能力、专业实践成果等工程能力和素质的评价等。进一步地，我们还考虑结合行业优势和地域优势，与合适的软件企业合作建设“工程教育实践中心”，以项目工程为载体，以项目研究为核心，更加密切地与企业进行产学研培养工程师，使学校教师、企业人员和学生在更好的平台上发挥主观能动性并形成合力。

二、结束语

“卓越工程师”的培养具有面向新形势的鲜明特点，主要体现在深化行业企业参与培养的程度、按照行业标准培养工程人才、强调学生的工程能力和创新能力等方面[4]，这对高校在人才培养模式、课程教学体系、实践教学、产学研结合等各项工作都提出了新的要求和挑战。本文对软件测试卓越工程师的人才培养思路和方案进行了探讨，指出需要转变人才培养模式，在教学内容和课程体系改革上突出内容整合性和知识应用性，构建适应测试工程技术的教学内容，进一步完善“知识、能力、素质”一体化的工程人才培养模式，增强学生的实践能力、工程素质和创新能力。我们以期由此拓展到更广的计算机工程师的培养工作中，更重要的是在以后的培养实践中进一步落实和完善培养方案，为学生具有卓越的工程能力和素质提供良好的培育平台。

摘要：本文以软件测试工程师为切入点, 探讨在计算机专业本科生推进卓越计划的实施措施, 重点是要转变教学观念, 改革课程教学体系、强化工程能力培训、注重校企联合培养复合化工程人才。面向“卓越工程师”培养计划的要求, 以软件测试工程师为例, 在明确卓越测试工程师培养标准的基础上, 提出校内和企业两阶段相融合的培养方案, 包括人才培养模式、课程体系、实践教学、教学评价和企业培养等方面的改革工作思路和具体措施。

关键词：卓越工程师,软件测试,人才培养

参考文献

[1]龚克.转变观念, 大胆试验, 建立卓越工程师教育培养的中国模式[J].中国高等教育, 2010, (18) :10-12.

[2]黄爱明.国内软件测试现状及对策研究[J].中国管理信息化, 2007, 10 (2) :42-43.

[3]http://www.istqb.org.

软件测试工程师的基本职责 篇5

◆负责软件系统技术方案和主程序框架的制定，芯片的选型设计;

◆根据软件需求完成程序代码的设计，调试，测试以及联机操作;

◆负责PIC、ARM等单片机软件开发以及相关的CPLD/FPGA程序设计;

◆协助生产的合同定制机的开发工作;

软件测试工程师的职责 篇6

关键词 信息工程监理 风险管理 需求管理

中图分类号：TP3 文献标识码：A

1信息工程监理概述

1.1 信息工程监理

信息产业部颁发的《信息工程监理暂时规定》中指出，信息工程监理是指依法设立且具备相应资质的信息工程监理方，受到建设方委托，依据国家有关法律法规、技术标准和信息工程监理合同，对信息工程项目实施的监督管理。根据国内信息工程监理的实践情况，信息工程涵盖网络工程、软件工程、计算机工程、通信工程、结构化布线工程、系统集成工程以及有关计算机和信息化建设的工程及项目。

1.2 信息工程监理的产生和发展

随着社会的发展与科技水平的进步，信息化将成为企业的发展趋势。在“以信息化带动工作化”的发展战略下，利用信息化走高科技、低消费、少污染、高效益的新型工业化路线成为实现现代化的必然选择。信息工程监理是随着信息工程的发展而出现的新事物，最早的信息工程监理来源于传统的建筑工程监理，随后结合信息工程自身的特点，加以改进，并逐步发展。

1.3 信息工程监理现状与问题

目前通过“三控两管一协调”的监理理论对信息工程进行监理，通过质量控制、进度控制、资金控制，合同管理与信息管理，以及组织协调对信息工程监理取得了一定的成绩，然而还存在一些问题。大多数建设方自身并不具备对信息工程建设的监督管理能力，这就使得建设方与承建方的信息严重不对称，因此很难保证信息工程建设的质量与效果。

1.4 信息工程监理与软件工程

由于“软件危机”的产生，迫使人们研究改变软件开发的技术手段和管理方法，从此进入了软件工程时代。信息工程监理的目标与软件工程相似，都是为了更好地开发与维护软件。因此，信息工程监理可以参考软件工程的理论与方法，逐步系统化、条理化。

2基于软件工程方法的信息工程监理

2.1 基于软件工程方法的信息工程监理的内涵

借鉴软件工程的理论，尤其是其阶段的划分以及工具的使用，丰富了信息工程监理的理论与方法。在“三控两管一协调”的基础上增加了 “风险管理”与“需求管理”，使之成为“三控四管一协调”。 通过借鉴软件工程的方法，信息工程监理理论得到了丰富与完善。信息工程监理框架分为四部分，分别是监理对象、监理内容、监理阶段以及监理的支撑要素等。

2.2 质量控制

质量控制在“三控”中位于首位，是进度控制、资金控制的基础。只有先做好质量控制，才能保证项目的质量。然而目前的质量控制没有细分控制点，质量控制的效果不是很理想。因此，借鉴软件工程方法，通过审査文档、审查测试、审查用户手册、组织评审、招标监督等对信息工程进行质量控制。

2.3 进度控制

进度控制是对项目进度实施与项目进度变更所进行的管理控制工作。在信息工程项目的实施过程中，往往进度是最难控制的。借鉴软件工程中进度控制的理论与方法，对信息工程监理中的进度控制进行调整，调整后的进度控制主要任务是项目设计阶段的计划审核、项目施工阶段的进度检测与纠偏等。

3信息工程监理中的风险管理和需求管理

风险管理。风险管理通过前期识别风险，然后再将风险标识出来，进而进行风险预测，并采取措施规避风险。

需求管理。需求管理对于整个项目而言，是非常重要的前期工作。需求管理也会直接影响到质量控制、风险管理等。

4总结与展望

4.1 总结

本论文引入软件工程的思想，软件工程方法把整个软件生产过程大致分为需求分析阶段、设计阶段、实现阶段、确认阶段、支持阶段。信息工程监理借鉴软件工程的思想，分阶段的对信息工程进行监理，从而细化监理内容，更好地保障工程项目的顺利进行。

4.2 展望

信息工程涵盖范围极广，包含计算机工程、网络工程、通信工程、结构化布线工程、智能大厦工程、软件工程、系统集成工程以及有关计算机和信息化建设的工程。由于受时间、研究条件等的限制，本论文研究象具有一定的局限性，本论文的结论在信息工程的其他领域是否也具有可行性、能否推广是值得研究的。在分阶段对项目进行质量控制、进度控制、资金控制方面，没有十分科学的方法与行业规范，没有进行深入研究。可以在今后的研究中，从以下几方面来完善此课题：一是可以选择信息工程涵盖的其它领域进行研究。二是可以更深入地研究分阶段的质量控制、进度控制、资金控制的方法与措施。三是可以将更多成熟的测试、评价等量化技术应用到信息工程监理中。

参考文献

[1] 肖维.浅析我国的信息化建设[M].科学出版社，2009.

[2] 宋振晖.信息系统工程监理知识体系[M].电子工业出版社，2010.

[3] 白思俊.现代项目管理[M].机械工业出版社，2011.

[4] 仲家骅.项目管理理论方法及应用[M].电子工业出版社，2008.

软件测试工程师的职责 篇7

软件工程 (Software Engineering, 简称为SE) 是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言, 数据库, 软件开发工具, 系统平台, 标准, 设计模式等方面。

在现代社会中, 软件应用于多个方面。典型的软件比如有电子邮件, 嵌入式系统, 人机界面, 办公套件, 操作系统, 编译器, 数据库, 游戏等。同时, 各个行业几乎都有计算机软件的应用, 比如工业, 农业, 银行, 航空, 政府部门等。这些应用促进了经济和社会的发展, 使得人们的工作更加高效, 同时提高了生活质量。软件工程师是对应用软件创造软件的人们的统称, 软件工程师按照所处的领域不同可以分为系统分析员, 软件设计师, 系统架构师, 程序员, 测试员等等。人们也常常用程序员来泛指各种软件工程师。软件工程没有一个权威的定义, 比较认可的定义为:软件工程是一门交叉学科, 它是解决软件问题的工程, 是对软件开发、运作、维护的系统化的、有规律的、可定量的研究方法。软件工程有明确的目标。那就是研制开发与生产出具有良好的软件质量和费用合算的产品。软件质量可用六个特性来评价:功能性、可靠性、易使用性、高效率性、可维护性、易移植性。软件工程不同于一般工程, 具体表现在以下几点。

(1) 软件是逻辑产品而不是实物产品, 所以费用集中在研制开发上而不在生产上。软件不会用坏、磨损、老化, 但有一个过时的问题。

(2) 由于软件是逻辑产品, 使得它的功能只能依赖于硬件和软件的运行环境以及人们对它的操作, 才能得以体现。

(3) 软件产品的功能比一般产品的功能复杂得多。

(4) 软件设计比一般产品复杂得多。具体表现在:功能的多样性, 实现的多样性。推动软件工程发展的原动力是提高软件质量和软件开发的生产效率。

2. 传统软件工程

传统软件工程采用面向过程, 即结构化程序设计方法, 即有很多成功的例子, 例如DOS操作系统, 也有很多失败的例子, 例如美国阿波罗登月飞行计划的软件错误。因为传统软件工程不能驾驭复杂系统的开发, 曾经一度产生了软件危机。面对越来越复杂的软件系统, 传统软件工程已经不能胜任, 在实践中, 人们呼唤能适应复杂系统开发的软件工程方法学和软件

开发技术的诞生, 面向对象软件工程应运而生。进入20世纪90年代以来, Internet飞速发展, 人们碰到了另一个难题, 快节奏地开发基于Web的大型应用程序, 面向对象软件工程及其技术已经不能胜任, 人们尝试利用基于构件的技术来解决, 于是诞生了CORBA、COM及COM+、J2EE及EJB等基于构件的技术和软件开发方法。然而, 今天的构件技术离人们追求的目标——软件工厂还相差甚远。面向过程的优点:面向过程的思维方法是符合人类认识规律的, 因为人们解决问题, 总是一步一步进行的, 其中, 有顺序, 条件和循环, 利用这三大结构, 可以解决世界上的任何问题。这些方法是优秀的, 被面向对象和面向构件所吸收, 成为类或构件内部实现的有力工具。面向过程的缺点:着眼于细节不能很好地从宏观上把握系统。

3. 面向对象软件工程

面向对象软件工程是运用面向对象方法, 符合人类认识规律的一种软件工程。20世纪60年代后期出现了面向对象的编程语言, 2 0世纪7 0年代初Xerox公司推出了Smailtalk语言。奠定了面向对象程序设计的基础, 1980年出现的Smatltalk-80标志着面向对象程序设计进入了实用阶段。自20世纪80年代中期起, 人们注重于面向对象分析和设计的研究, 逐步形成了面向对象软件工程方法学。典型的方法有ECoad和E.Your Don的面向对象分析和设计, GBooch的面向对象开发方法, J.Rumbaugh等人提出的对象建模技术 (OMT) , Jacobson的面向对象软件工程等。20世纪90年代中期, 由GBooth, J.Rumbaugh、Jacobson等人发起, 在Booch方法、OMT方法、OOSE方法的基础上推出了统一的建模语言 (UML) , 1997年被国际对象组织 (OMG) 确定为标准的建模语言。面向对象方法的出现受到了计算机软件界的亲睐, 并成为20世纪90年代的主流开发方法。面向对象方法的优点如下。

(1) 从认知学的角度来看, 面向对象方法符合人们对客观世界的认识规律很长一段时间里, 我们分析、设计、实现一个软件系统的过程与我们认识一个系统的过程存在着差异。例如结构化方法分析的结果是数据流图, 设计的结果是模块结构, 实现的结果是由程序模块组成的源程序。

(2) 开发的软件系统易于维护, 其体系结构易于理解、扩充和修改面向对象方法开发的软件系统由对象类组成, 对象的封装性很好地体现了抽象和信息隐蔽的特征。

(3) 面向对象方法中的继承机制有力支持软件的复用.

4. 构件软件工程的概念模型

构件和基于构件的方法是电子商务革命的驱动力, 它们是Interne时代开发企业级解决方案的方法。在任何行业中, 复杂情况通常是通过很多关键概念来解决的。这些概念是通过抽象、分解、选代、细化等方法来表达的。其中的关键是分解技术——把一个较大的问题分解成较小的、可管理的单元, 这样每一个单元都是可以单独处理的, 这个技术是软件工程的许多方法的核心。这些方法可以称为结构化设计, 模块化编程, 面向对象程序设计, 基于构件的程序设计, 它们产生的单元称为模块、包、对象或构件。基于构件软件开发是历史发展的必然, 基于构件的软件开发 (Component Based Software Development) , 简称CBD。基于构件的软件工程 (Component Based Software Engineering) , 简称CBSE。CBD追求的目标是软件的“即插即用”。回顾经典的工业化革命, 不难得出一些有益的启示:功能再复杂的产品都是由大量标准的零件 (领域构件) 组成, 零件在生产线上装配成一个产品, 所有零件在产品中共同发挥作用。分工越细致, 专业生产的程度越高, 总体生产效率就越高。把这些启示运用于软件开发, 那就是:标准的零件就是软件生产的构件, 构件在软件生产线上通过集成得到新开发的软件。

参考文献

[1]贾岩.基于构件的软件工程技术研究[J].科技资讯, 2011, (06)

[2]陈大宾.结构加固与改造方法评述[J].科技风, 2009, (08)

[3]吴亮, 谢忠.分布式构件化WebGIS的研究与实现[J].科技进步与对策, 2003, (S1)

软件测试工程师的职责 篇8

黑盒测试图发现以下类型的错误: (1)不正确或一遗漏的功能;(2)接口错误;(3)数据结构或外部数据库访问错误;(4)行为或性能错误;(5)初始化和终止错误。黑盒测试与白盒测试的不同之处是,黑盒测试应用于测试的后期阶段, 而白盒测试是应用工程测试的早期执行。 由于黑盒测试侧重于信息域因此不需要考虑控制结构。设计黑盒测试需要回答以下几个问题:1. 如何测试成功的有效性? 2. 如何测试系统的行为和性能? 3. 哪种类型的输入会产生好的测试用例? 4. 系统是否对特定的输入值特别敏感? 5. 如何分离数据类的边界? 6. 系统能承受什么样的数据速率和数据量? 7. 特定类型的数据组合会对系统运行产生什么样的影响?

黑盒测试的方法

一、基于图的黑盒测试方法:此类黑盒测试方法的第一步是理解软件中建模的对象及这些对象间的关系。这一步一旦完成,下一步就是定义一系列验证“所有对象之间具有预期关系”的测试。即软件测试首先是创建重要对象及其关系图,然后设计覆盖图的以系列测试用例,使得图中的每个对象和关系都测试到,并发现错误。为了完成这些步骤,软件工程师首先要创建图,其中结点表示对象,连接表示对象间的关系,结点权值描述结点的属性,连接权值描述连接的某些特征。

二、等价类划分的黑盒测试方法:此类黑盒测试方法是将程序的输入划分为若干个数据类,从中生成测试用例。理想的测试用例可以单独发现一类错误(如: 所有字符数据处理不正确),否则在观察搭配一般的错误之前需要运行许多测试用例。等价类划分的测试用例设计是基于对输入条件的等价类进行评估。若对象可以由具有对称性、传递性和自反性的关系连接,则存在等价类。等价类表示输入条件的一组有效的或无效的状态。通常情况下,输入条件要么是一个特定值、一个数据域、一组相关的值,要么是一个布尔条件。可以根据下述指导原则定义等价类: 1. 若输入条件指定一个范围,则可以定义一个有效等价类和两个无效等价类;2. 若输入条件需要特定的值,则可以定义一个有效等价类和两个无效等价类;3. 若输入条件指定集合的某个元素,则可以定义一个有效等级类和一个无效等级类;4. 若输入条件为布尔值,则可以定义一个有效等价类和一个无效等价类。通过运用设计等价类的指导原则,可以为每个输入域数据对象设计测试用例并执行。选择测试用例以便一次测试一个等价类的可能的属性。

三、在软件工程中大量错误发生在输入域的边界处,而不是发生在输入域的“中间”。这是将边界值分析(boundary value analysis, BVA)作为一种测试技术的原因。BVA不仅仅侧重于输入条件,也从输入域中导出测试用例。BVA的指导原则和等价划分的指导原则很类似。BVA的指导原则包含:1. 若输入条件指定为一组值,则测试用例应当包括a和b,略大于或小于a和b ;2. 若输入条件指定为一组值,则测试用例应当执行其中的最大值和最小值,以及略大于或略小于最大值和最小值;3. 指导原则1和2也适用于输入条件;4. 若内部程序数据结构有预定义的边界值,一定要设计测试用例,在其边界处测试数据结构。很多软件工程师在进行软件过程中会在某些时候凭直觉完成BVA,若是在边界测试时运用BVA的指导原则,边界测试会更加完全,从而更有可能发现一些错误。

四、许多传统的应用系统程序的输入域是相对有限的。即,输入参数的数量不多,且每个参数可取的值有明确的界定。当这些数量非常小时,则可能考虑每个输入排列,并对所有输入域进行测试。 然而,随着输入值数量的增加及每个数据项的离散值数量增加,我就需要正交数据组测试(orthogonal array testing)。正交数据组测试可以应用于输入域相对较小,对于发现区域错误(region fault)尤其有效,即有关软件构件内部错误逻辑的一类错误。为了说明正交数据组测试与更传统的“一次一个输入项”方法之间的区别, 考虑有3个输入项X、Y和Z的系统。每个输入项有3个不同的离散值。这样可能有33=27个测试用例。Phadke提出了一种几何观点,来组织与X、Y和Z相关的测试用例。一次一个输入项可能沿着每个输入轴在顺序上有变化。这就导致相对有限的输入域覆盖率。而当使用正交数据组测试时,创建测试用例的一个L9正交数组。L9正交数组具有“平衡特性”,即测试用例(黑点)均匀地分散在整个测试域中,整个输入域的测试覆盖会更完全。

软件测试工程师的职责 篇9

1 软件工程实验装置的设计

程序必须与终端用户搭配:

一般说来, 它需要接受一个或几个用户的输入, 然后以电子和/或书面的形式产生输出。一般情况下, 用户也必须从程序本身或随程序的书面文件学会使用程序。

程序将有可能和其他程序相互作用, 因此需要“内部接口”或兼容组件将它和其他程序联接

近几年来, 随着对集成应用程序的需求增多和面向目标的编程已成为一项准则, 这个程序单元越来越重要。最后, 程序人员必须编写执行程序的实际源代码, 并且这个源码必须被翻译成在计算机上运行的目标码。不可能界定程序编写的“顺序”。虽然人们可以自然地推定程序员可能从“顶部”开始并一路向下工作——对程序提出想法, 然后设计它的结构和界面, 并且最后以代码完成这些设计决定——然而事情并不总是按这个路线进行的[2]。

2 软件工程实验装置应用的项目

关于编写计算机程序步骤的一个最重要的事实是:它是迭代的。大部分程序不是以直线型构造编写的。程序设计表现为一系列的“反馈循环”, 其中程序的每一阶段影响到所有其他阶段。因此编写代码可能揭示出一些需要重新考虑程序的基本结构问题。用“a测试版软件”让一些试用用户可以指出已完成程序的一些缺陷, 而且也可以鉴定所期望的性能以便要求程序全部或部分重写;即使在程序已经编写“完成”并出售以后, 改写的过程仍在继续。大部分公司对它们的程序制定出一系列的修订版或最新版;当然消费者对购买第一版本的新产品往往非常谨慎。无论计算机程序是如何编写的, 它们都是功能性的。程序的设计是为一个或多个目的服务的, 并在很大程度上通过它们完成任务的好坏得以评定。由于计算机指令的功能仅是完成确定的任务, 制定程序结构时, 最令人关心的是以最有效的方式满足用户的需要。在这个框架下, 效率的概念是广泛的。效率可以是以下一项或几项:1) 代码效率——信息处理速度最快;2) 存储效率——使用求解技巧和寻址方法使完成期望任务所需的存储量最小;3) 输入/输出效率——计算机与外部硬件没备 (如键盘和打印机) 的用户之间的信息传送质量和速度最优;4) 稳定性——程序必须便于维护、升级、适应新的硬件平台。软件工程界力争以较低的成本开发出更“有效”和更可靠的程序编写方法。当然, 这并不是说, 用于完成相同目标的程序设计包含相同的代码。无数的因素可能导致不同的程序之间, 在“低”级源码方面以及在较高级的程序设计和用户界面方面, 形成显著的变化。如同对效率的考虑在很大程度上支配编程一样, 我们将看到, 这种变化对知识产权的影响也是很大的[3]。

由于用户的基数大, 更多的程序人员编写在DOS和Windows上运行的程序;更多的用户部分地采用微软系统, 因为所有的程序是为此编写的。1994年, DOS和Windows占有个人计算机操作系统市场的80%, 尽管该系统具有封闭性, 并且还存在一些具有竞争优势的系统。在具有显著网络外部性的市场中, 应考虑的重要事项是:计算机厂商是否有正确的动机去开发或采纳兼容性的产品, 并借此扩大既有网络。经济学家证实, 计算机厂商可能宁愿采用不兼容的产品标准, 虽然他们采纳兼容的产品将增加净社会财富[4]。

3 实验软件装置的实例分析

实验装置的软件有三部分, 第一部分是控制软件, 主要是控制系统的扫描、功能、数据的采集等;第二部分是数据处理部分, 用来对曲线做处理, 如曲线的平滑、四则运算等;第三部分专门用于黑体实验, 前两部分很好理解, 重点介绍第三部分[5]。

3.1 建立传递函数曲线

任何型号的光谱仪在记录辐射光源的能量时都受光谱仪的各种光学元件以及接收器件在不同波长处的响应系数影响, 习惯称之为传递函数。为扣除其影响, 系统提供一个标准的溴钨灯光源, 其能量曲线是经过标定的。另外在软件内存储了一条该标准光源在2940K时的能量线。当需要建立传递函数时, 请按下列顺序操作:

1) 将标准光源电流调整为“溴钨灯的色温”表中色温为2940K时电流所在位置;

2) 预热20min后, 在系统上记录该条件下全波段图谱。该光谱曲线包含了传递函数的影响;

3) 点击“验证黑体辐射定律”菜单, 选“计算传递函数”命令, 将该光谱曲线与已知的光源能量曲线相除, 即得到传递函数曲线, 并自动保存。

3.2 软件的设计与编写

根据实验软件装置的要求, 对所需要的功能进行实现与设计, 从而达到预期的应用果酱。

4 结论

总之, 如何完善软件装置平台系统功能、拓展其应用, 基于应用中发现的待改进的问题和学生的反馈意见, 改进该实验软件装置系统, 并请学生参与到装置的建设中, 力争使其在提高学生的综合素质和能力方面发挥更大的作用。

摘要：软件工程技术综合实验装置既包括各种自动控制技术的基础实践环节训练、又包括复合多种控制技术的综合性实践环节训练。软件工程技术综合实验装置是本书配套的综合控制技术实训装置, 结合多年工程与教学实践经验设计了多达近几十个实验, 可以在阅读本书的同时, 结合各种实验设计, 进一步理解和掌握各种自动控制新技术。本文主要探讨软件工程实验软件装置的应用。

关键词：软件工程,实验软件装置,控制

参考文献

[1]张慧, 邢培振.基于企业网双核心高可用性应用方案研究[J].中州大学学报, 2012 (4) :118-119.

[2]许小东, 吴军强.基于Multi-Agent的过程化教学系统模型的研究[J].嘉兴学院学报, 2012 (6) :201-202.

[3]施伟, 王硕苹, 郭鸣, 等.跨平台移动应用中间适配层设计与实现[J].计算机工程与应用, 2012 (10) :187-188.

[4]徐耀丽, 康慕宁, 齐万华.Ajax技术在远程教育平台中的应用研究[J].计算机与现代化, 2012 (12) :179-180.

软件测试工程师的职责 篇10

关键词：软件工程监理,软件产业,影响

信息技术已经逐渐成为先进科学的代名词, 互联网也在现代社会发展中发挥着越来越重要的作用, 软件是信息技术和互联网发展最重要的部分。一个企业只有掌握了最先进的软件技术, 才能在这个竞争激烈的社会中占据最有利的位置, 并不断地向着前方进步。现如今, 很多企业都看到了发展软件行业的美好前景, 争相挤入软件生产的行列。也正是因为软件所带来的利益对企业有着极大的吸引力, 才造成了如今市场中的软件生产企业良莠不齐, 所出产的软件质量也未必都能够达到应有的标准, 虽然软件的生产速度逐渐加快, 然而, 却未能满足用户的需求。一些企业生产软件所聘用的人才并不具备应有的强硬的知识和能力, 或者对软件生产的监管力度不够, 造成了软件的开发、生产不规范, 而这些软件进入市场, 被用户所使用, 就为用户造成了一些不便, 甚至是损失。因此, 软件工程监理工作就显得尤为重要。只有依靠软件工程监理的作用, 才能保证软件企业开发出更多符合用户要求、质量达标的软件。

一、软件产业市场结构受软件工程监理的影响

所谓的市场结构, 实际上可以这样理解, 产品的质量优劣以及成本高低而造成的市场竞争力对于市场行情的影响, 市场结构对于产业组织的竞争性质有着根本的决定作用。市场结构不但直接决定了产业内的市场行为, 同时, 也在很大程度上影响着市场绩效。而市场结构又包括了市场集中度、市场中产品的经济效益和规模以及产品的质量和类型等多个方面。软件工程建立工作对于软件产业的市场有着巨大的影响, 也就意味着, 对于市场结构中的这几个方面的影响也非常深远。

(一) 软件产业市场集中度受软件工程监理的影响。

市场的供需关系既与企业的生产有关, 又与用户的需求不可分割, 从市场的整体状况来看, 依旧是供应决定需求。而由于我国的软件产业相对来说还是一个新兴的产业, 不但企业在生产和销售软件方面没有足够的经验, 许多用户也不知道该如何从市场中获得自己所需要的产品, 这就导致了我国软件产业市场的集中度分布不合理。一方面我国的软件产业市场较为分散, 基本上只存在于一些科学技术较为发达的的确, 软件的应用也只是运用在一些高端设备中, 并且一些较为常用的软件都是由几家大的软件企业所开发出来的;另一方面我国的软件开发技术与一些先进的国家相比来说还存在许多不足之处, 因此, 当引进相同类型的国外软件时, 一些国产软件在市场中就会失去竞争力。这些都是导致我国软件产业市场集中度低下的原因。而通过软件工程监理工作来对软件的开发和市场销售进行监管和调控, 就会大大改善这一状况。

(二) 软件产业的经济效益和规模受软件工程监理的影响。

我国的软件开发企业还没有形成足够大的规模, 市场上所出现的软件大多数都由一些中小型企业研究开发出来。企业规模不够大, 在这个竞争力极强的市场中难以站稳脚步, 一旦市场出现动荡, 最先遇到风险的就将会是这些中小型企业。且由于我国的软件企业还处在发展阶段, 其开发出来的软件并非十全十美, 需要不断地进行改进。如果软件工程监理不能发挥其足够的影响力, 那么软件的开发研究就达不到国际化的水准。如此以来, 这些国产的软件必然会受到一些国外软件的冲击, 不但企业难以进步, 发展壮大为更大的规模, 取得不了应有的经济效益, 用户对于软件的使用也将会受到极大的限制。而软件工程监理工作, 就是为了能够提高我国软件企业的生产规模, 使其开发研究走向标准化, 扩大企业规模, 增强企业竞争力, 使其开发研究的软件能过得到用户的认可, 获得更高的经济效益。

(三) 软件产业产品的质量和类型受软件工程监理的影响。

一个软件企业能否开发研究出高质量的软件, 取决于企业是否具有软件开发方面的专业型人才, 同时, 软件工程监理对于软件开发的质量也有着掌控把关的作用。另外, 企业所开发研究出的软件类型是否普遍适用于大多数用户, 也会受到软件工程监理的影响。目前, 我国一些软件开发企业所生产出来的软件, 技术含量不足, 难以形成强大的市场竞争力, 而企业对于用户的服务质量也难以达到用户的期望程度。再加上在不同的地区、不同的行业、不同的人群, 对于软件的使用需求不同, 企业在开发软件时需要考虑到这些因素, 才能够开发研究出高质量、合适类型的软件。而软件工程监理工作, 就是要洞悉这些情况, 并向企业管理者反映, 从而决定软件企业的发展方向。

二、软件产业市场行为受软件工程监理的影响

软件企业会根据自身的软件开发特点、软件的竞争力在市场中做出相应的活跃行为。而软件产业的市场行为又与市场结构有着密不可分的关系。因此, 软件工程监理也会在很大程度上影响软件企业的市场行为。

(一) 企业软件生产创新能力受软件工程监理的影响。

一个软件开发企业是否能够不断地发展, 不但受到其自身说具备的人才、管理、经费等方面的影响, 更重要的一点是这个企业是否具有强大的创新能力。尤其是软件行业, 其接触的都是社会中最为先进的技术, 如果没有足够的创新能力, 就会被日新月异的软件市场所抛弃。随着软件行业的不断发展, 越来越多的软件企业开始意识到创新能力的重要性, 并且在开发研究中不断地提高其创新能力。软件工程监理工作, 能够平衡企业对于软件开发方面所投入的资金、所聘用的专业人才等各种事项, 使企业增大对于创新能力的重视程度, 从而提高整个企业的创新能力, 开发研究出更为先进的软件。这样, 该软件企业才能够在市场中占有一席之地。

(二) 企业软件生产的标准及规范度受软件工程监理的影响。

软件企业要想能够使自身所开发研究出来的软件能够符合用户的要求, 并在市场中取得更大的竞争力, 那么就必须有一个明确的生产标准。企业在研究开发软件的过程中, 需要极强的技术含量, 更需要有一个规范的开发研究过程。软件工程监理的出现, 能够帮助企业对软件开发所使用的技术标准、开发过程中的操作规范进行把关, 使企业所投入的人力物力能够发挥到更大的作用, 提高企业的生产效率, 降低企业中软件开发中的成本。现在的软件市场情况极为复杂, 不但是企业开始逐渐重视软件开发的标准和规范, 国家政府部门也开始参与对于软件开发的调控。为了加快我国的软件开发, 保证软件开发的质量, 软件工程监理开始集合企业与政府等多方面的力量, 为软件的开发制定一个合理的、规范的标准, 保障软件开发能够与国际接轨。

三、软件企业产业的绩效受软件工程监理的影响

我国软件产业的现状是, 企业的生产规模还不够强大, 难以形成能与国外软件行业竞争的力量, 软件开发技术与国际标准也有一定的差距。要想扩大软件产业的规模, 加快软件研究的技术进步, 就必须依赖软件工程监理工作的强大影响力。

(一) 软件企业产业规模经济性受软件工程监理的影响。

就目前来看, 我国众多软件开发企业规模较小, 且未能形成强大的凝聚力, 没能站在统一战线上进行软件的研究开发, 如此一来, 依靠单个的软件企业难以形成足够的竞争力与一些国外企业抗衡。软件企业的规模经济性也难以令人满意。软件工程监理工作, 就是要对这些方面进行管理和调节。一方面软件工程监理工作能够推动软件企业将服务的方向由单一的软件开发向多种服务并重的方向发展;另一方面软件工程监理工作能够加大对企业自身的管理, 提高其在市场中抵御风险的能力, 使企业能够在激烈的市场竞争中站稳脚跟。另外, 软件工程监理工作能够通过对软件质量和开发方向的监管, 使企业开发出更符合用户和市场需求的软件, 增强软件产业的规模经济性。

(二) 软件企业技术进步受软件工程监理的影响。

我国目前所使用的一些较为先进的软件, 都是从国外引进的, 而我国自主研究开发的软件, 其技术含量还未能完全达到市场的需求。而我国的软件开发要想具备较强的技术, 就要依靠软件工程监理来对其进行管理。软件工程监理工作能够督促软件开发人员不断地提高自身素质, 增加工作经验, 从而提高整个软件企业的技术水平, 加快软件开发的技术进步。

参考文献

[1]马红.论中国软件产业的质量保证体系[J].电子标准化与质量, 2001.5.

[2]陶长琪.试论信息产业结构和组织的演进[J].江西财经大学学报, 2000.6.

试论软件工程的应用 篇11

关键词：软件工程；需求

中图分类号：TP311.52 文献标识码：A文章编号：1007-9599(2012)02-0000-02

The Application of Software Engineering

Nan Yahui

(Shanxi Lvliang University,Luliang033000,China)

Abstract:Here we mainly through the analysis of the problems in the software development process,further analysis of the introduction of the concept of software engineering processes being here,and summarized the three most important aspects of software development using software engineering.Software development is basically dependent on the individual skills of the developers did not follow the theory,principles and methods,but also the lack of effective management;the complexity of the software contains errors of difficult to control the extent of developer.

Keywords:Software engineering;Demand

一、软件工程的起源

相当长一段时间我们发现，特别是60年代以来，计算机普及的趋势越发的明显，我们传统产业中的软件开发所面临的问题域的复杂性得到了突出的爆发，这就是我们在很大程度上凸显系统的规模和复杂度空前扩大。与以前的开发模式不同，原来的软件开发在很大程度上是依赖开发人员的个人技能，在这个流程之中我们很难发现遵循原理、原则和方法，与此同时我们也可以发现其中管理的落后；这就是使我们的软件开发中的难度很大的难控性。

二、需求分析是软件开发的关键

我们在软件开发这一工作流程中，工作中对我们最为关键的就是需求分析的工作，所谓的需求分析就是体现我们的委托人对软件应用的要求，客户对软件的要求决定了软件的开发程序。这就会使我们在很多的流程之下，在这一流程之后我们不难发现的问题就是与实际要求差距还是较为明显，在最差的情况下甚至失去了其存在的价值。究其根本原因在我我们的基础工作没有做好，就是我们所说的需求分析问题。现行的需求分析还存在着很多的弊端，在这里我们发现一部分开发者在进行需求调查时，需要我们的委托人，或者说我们的客户提供应用模型和原始数据，在很大程度上绝大部分用户往往不知道应该提供什么，这就出现了需求的提出和客户真正的需求偏离的问题，也就为我们的软件开发从根本上买下了隐患。这就要求我们建立全新的需求调研流程，适应客户新的需求。

（一）我们提倡委托人与开发小组面对面交流

（二）软件开发小组需要组织具体人员，亲自到合作单位开展调研，其最适合的调研范围是每人负责3至4各部门。其调研的主要工作：1.通过调研表哥了解调研信息；2.针对调研信息开展统计工作，并在此基础上展开调研的数据分析。

（三）我们需要对于调研数据进行优化分析，并在此基础上得出我们需要的结论，对数据的使用优中选优，及时提出不符合调研标准的数据内容，需要明确的是：数据的具体部门分析的差异性，需要我们分清楚部门的差异，便于我们统计工作的展开，这类数据也要注意剔除掉。针对于汇总表的制作更为关键，检查报表上所需要的数据是否在数据调查表中有遗漏；需要针对不同的部门予以划分。

（四）我们的软件开发需要根据客户提供的数据、管理的流程予以确认，并在此基础上形成文字材料，并反馈给相关的部门，予以确认。

（五）反馈之后我们的职能部门需要制作一个DEMO演示程序；这个延时的界面在很大程度上基本的演示了我们需要实现的功能，该程序只是大概反映出功能调用、界面等，这是跟需要我们的客户提供修改意见。

（六）根据用户意见进行修改并形成交付用户审阅的需求分析文件。

三、系统功能确定力求准确

我們的软件设计需要很好地完成客户对软件功能的要求，我们在设计系统功能时，需要明确是否完成需求的实现；我们需要注意的是，我们容易出现的问题是我们的设计人员在满足委托人需求的同时，对于其它伴随的需求的漠视。这些功能恰是客户主题需要得以实现的关键部分，客户却在他的需求表述中没能很好的体现，这类要求我们称为“系统需求”。比如说在用户提出的要求中，一般情况下我们的数据要求以编码方式实现存储时，这样的客户需求就是是要求我们要有一个或多个数据关系表（TABLE）存放编码和编码所对应的内容信息，这就是要求我们的技术人员在实施编程时确定系统功能时，就应在在我们的工作中要有一套管理功能对这些数据关系表实现维护。我们从另外一个角度来分析一下，我们的技术人员在实现这一功能时需要对用户一些自己说不清楚的，然而我们的编程技术上比较复杂的功能要求持着谨慎的态度。我们具体来说一下，一般情况下MIS系统的需求中都提出“决策库”的要求，我们的委托人一般意义上会让我们的技术人员“决策库”具有动态、自动、

模糊等决策比较功能，提的要求标准非常高，而结合他们自身的管理究竟如何实现这些功能，参与决策的信息是那些数据，其计算公式如何则一点也说不清楚。在这种情况下一定要慎重，必要时双方协商决定。概要设计文件完成后，开发单位的技术总负责人应严格审查其中的功能及如何实现这些功能的描述。如果出现不清楚的描述或根本不可能实现的功能，则属于设计质量不合格。

四、软件文档规范化

我们的编程人员在很多时候在编程的不同阶段，在每一个过程中我们会产生不同的文档，文档是我们变成流程中的结果。我们在这一流程中实现的文档不是在软件开发之后，是在这流编程的流程之中。这就要求我们的软甲工作人员需要在流程中实现文档的生成。我们的软件开发的过程中，各个阶段之间的转移就是要通过文档来实现的。我们这里着重说一下重大项目的软件开发，我们的工作人员需要有清晰的文档语言，文档是相互协调的最清晰语言。文档也是软件测试的根据。不论大的软件公司还是软件开发工作室，都要依据自己的工作，制定软件文档规范，以此来要求开发人员生产出高品质的软件产品，这是非常必要的。这需要我们的软件编程人员把流程规范化，形成书面的材料也就是我们所说的文档形式。文档必须严格地与各阶段的工作一致，准确地反映工作实际，文档修改时，还要保持文档本身前后阶段的一致。

我们现在的软件工作人员在很多方面需要在传统的软件工程方法采用结构化程序对它进行设计技术，通常意义上讲我们的软件程序开发是一种有效的方法，但将它推广至大规模的系统开发中往往会失效。相对于传统的软件工程方法，面向对象的软件工程方法带来了全新的一种风格，具有相当顽强的生命力，并以相当惊人的速度发展壮大，各个领域逐渐地采用这种新的软件工程方法来取代原有的传统方法，同时也取得了辉煌的成就。一直以来，人们梦寐以求软件工厂的实现，软件工程师希望能到软件市场购买各种软件的“集成电路”来“即插即用”，利用它们拼装新的软件系统，而不是一行一行地在自己并不内行的领域低水平地重复他人开发的软件已经实现了的功能。采用基于组件的软件开发技术，二进制组件可以被不同的应用程序使用，使软件组件真正能够成为“工业零件”，从而能极大地提高软件生产率。

参考文献：

[1]邹宗华,蒋进,唐晓晖,顾茵莉,何雁,李彬.多频道、多品牌字幕机综合应用案例分析及病毒隔离创新机制[J].现代电视技术,2010,10

[2]黄琨,王婉秋,方守恩.道路安全审计辅助软件设计分析[J].上海公路,2010,03

[3]秦永菊,张东旭.提高中小企业信息化效率的途径分析[J].生产力研究,2010,10

[4]张欣.我的地盘我做主[J].中国计算机用户,2006,33

软件测试工程师的职责 篇12

GIS工程学来源于系统工程学, 软件工程学和地理信息科学的结合。系统学、系统工程学、软件工程学、地理信息科学都是其理论基石。GIS设计是利用软件工程的思想, 结合GIS软件开发的特点和开发目标, 制定GIS软件开发的项目计划, 并对软件的用户需求和可行性进行分析, 从而设计软件的技术实现方案, 最后对软件进行实施和维护。

2 软件工程

在了解软件工程之前先介绍软件危机, 它是一种现象, 是落后的软件生产方式无法满足迅速增长的计算机软件需求, 从而导致软件开发与维护过程中出现的一系列严重问题的现象。

软件工程是多学科、跨学科的一门学科, 它借鉴了传统工程学的原理和方法, 同时应用了计算机科学、数学、工程科学和管理科学的很多理论与知识, 以求高效地开发高质量软件。从20世纪60年代软件工程学的产生到现在, 软件工程演变了三代。分别是20世纪70年代以结构化分析、结构化设计和结构化编程的第一代软件工程又称传统软件工程;20世纪80年代以研究面向对象分析和设计的第二代软件工程又称对象工程;20世纪90年代以组件技术的研究发展而来的第三代软件工程又称组件工程。软件工程代与代之间没有鸿沟, 他们不仅交叉重叠, 也携手并进。

3 软件过程模型以及其在GIS设计的作用

软件过程是按照软件项目的进度、成本和质量要求, 开发和维护软件所必需的一系列有序活动的集合。软件工程模型是按照工程化的思想设计提出的指导策略, 是一个覆盖整个软件生存周期全部活动和任务的结构框架, 这个框架给出了软件开发活动各阶段之间的关系, 相应的工作方法与步骤。

3.1 瀑布模型

瀑布模型 (Waterfall Model) 又称生存周期模型。是由W.Royce于1970年提出来的, 也称为软件生存周期模型。其核心思想是按工序将问题化简, 采用结构化的分析与设计方法, 将逻辑实现与物理实现分开。

3.1.1 瀑布模型的原理

瀑布模型是一种线性模型, 软件开发的各项活动严格按照线性方式进行, 每一项开发活动均以上一项的活动结果为输入对象, 实施该项活动应完成的内容, 给出该项活动的工作结果作为输出传给下一项活动, 对该项活动实施的工作进行评审。若工作得到确认, 则继续进行下一项活动, 否则返回前项, 甚至更前项的活动进行返工。

3.1.2 瀑布模型在GIS设计的作用

由于瀑布模型是一种以文档作为驱动的模型;阶段之间存在有序性和依赖性;将逻辑设计与物理设计清楚的划分开, 尽可能的推迟程序的物理实现;具有质量保证的观点;清晰的提供了软件开发的基本框架的特点使其在软件工程中占有重要地位。

瀑布模型一般适用于功能完整、性能明确、无重大变化的GIS软件系统的开发。但同时也应注意瀑布模型因为过早的考虑程序实现, 常常导致大量返工;它的阶段间的依赖特征会导致工作中发生“阻塞”状态, 如果大的错误在软件生存周期的后期才发现, 将导致灾难性的后果;它各阶段之间的大量规范化文档和严密评审增加了项目工作量;缺乏灵活性, 特别是无法解决软件需求不明确或不准确的问题, 因此其应用具有一定局限性。

3.2 快速原型模型

快速原型模型 (Prototyping Model) 是在用户不能给出完整、准确的需求说明, 或者开发者不能确定算法的有效性、操作系统的适用性或人机交互形式等许多情况下, 根据用户的一组基本需求, 快速建造一个可运行的软件, 然后进行评估。同时也使开发者对将要完成的目标有更好的理解, 再进一步精化、调整原型, 使其满足用户的要求。

3.2.1 快速原型模型基本原理

快速原型模型从需求分析开始, 软件开发者和用户一起定义软件的总目标, 说明需求, 并规划出定义的区域, 然后快速设计软件中对用户可见部分的表示。快速设计导致了原型的建造, 原型由用户评估, 并进一步求精, 逐步调整原型使之满足用户需求, 这个过程是迭代的。详细过程:第一步, 弄清用户的基本信息需求;第二步, 开发初始原型系统;第三步, 用原型系统完善用户/设计者的需求;第四步, 修改和完善原型系统。

3.2.2 快速原型模型在GIS设计的应用

由于快速原型模型使系统更易维护、用户交互更友好;能得到良好的需求定义, 比传统的生存周期法好很多, 使开发者与用户充分交流, 以改进原先设想的、不尽合理的系统;可降低总体开发费用, 节约开发时间。

快速原型模型比较适合低风险和柔性较大的GIS软件系统的开发。但同时也应注意避免对于开发者不熟悉的领域把次要部分当作主要框架 (模型效应) ;原型的迭代不收敛于开发者预先的目标;它不太适合嵌入式软件、实时控制软件、科技数值计算软件的开发。

3.3 螺旋模型

螺旋模型 (Spriral Model) 是B.Boehm于1988年提出的。螺旋模型将瀑布模型与原型的迭代特征结合起来, 并加入两种模型均忽略了风险分析, 弥补了两者的不足。

3.3.1 螺旋模型的基本原理

螺旋模型可以看做是连接的弯曲了的线性模型。螺旋模型沿着螺线旋转, 在笛卡尔坐标的四个象限上分别表达了四个方面的活动, 即:制定计划, 确定软件目标, 选定实施方案, 弄清项目开发的限制条件;风险分析, 分析所选方案, 考虑如何识别和消除风险;实施工程, 实施软件开发;用户评估, 评价开发工作, 提出修正建议。

3.3.2 螺旋模型在GIS设计的应用

由于螺旋模型是一种风险驱动模型, 为项目管理人员及时调整管理决策提供了方便, 进而可降低开发风险;特别强调原型的可扩充性, 原型的进化贯穿了整个软件生存周期, 这将有助于目标软件的适应能力;原型可看做形式的可执行的需求规格说明书, 易于为用户和开发人员的共同理解。

螺旋模型支持需求不明确, 特别是较高风险的大型GIS软件系统的开发。但同时需要注意要求构造的原型的总体结构、算法、程序、测试方案应具有良好的可扩充性和可修改性;如果每次迭代的效率不高, 会导致迭代次数过多, 将会增加工作量和成本并有可能推迟提交时间;它要求开发队伍水平较高;它是出现较晚的新模型, 不如瀑布模型普及。

3.4 增量模型

增量模型 (Incremental Model) 融合了瀑布模型的基本成分和原型模型的迭代特征, 其实质就是分段的线性模型。

3.4.1 增量模型的基本原理

增量模型采用随着日程时间的进展而交错的线性序列, 每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时, 第一个增量往往是核心的产品, 也就是说第一个增量实现了基本的需求, 但很多补充的特征还没有发布。用户对每一个增量的使用和评估, 都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复, 直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

3.4.2 增量模型在GIS设计的应用

由于增量模型每次增量交付过程都可以总结经验和教训, 有利于后面的改进和进度控制;每个增量交付一个可操作的产品, 便于用户建立好模型做出反应, 易于控制用户需求;任务分配灵活, 将风险分布到几个更小的增量中, 降低了项目失败的风险。

增量模型适合初期的需求不够确定或需求会有变更的GIS软件系统开发。但同时需要注意至始至终需要用户亲密配合, 以免影响下一步进程;要避免把难题往后推, 首先完成的应该是高风险和最重要的部分;要避免退化为边做边改模型, 从而使软件的控制失去整体性;由于一些模块必须在另一个模块之前, 必须定义良好的接口。

3.5 面向对象的软件过程模型

传统的软件开发过程大多建立在软件生存周期概念的基础上, 螺旋模型、原型模型、增量模型等实际上都是从瀑布模型拓展或演变而来的, 通常把它们称为传统的软件过程模型。

面向对象的软件开发过程的重点放在软件生存周期的定义阶段。这是因为面向对象方法在开发早期就定义了一系列面向问题域的对象, 建立了对象模型。整个开发过程统一使用这些对象, 并不断地充实和扩展对象模型。

3.5.1 构件复用模型

面向对象技术将事物实体封装成包含数据和数据处理方法的对象, 并抽象为类。构件 (component, 也译为组件) 是软件系统中有价值的、几乎独立的并可替换的一个部分, 它在良好的定义体系结构语境内满足某项清晰的服务功能, 可以通过其他接口访问他的服务。经过适当的设计和实现的类也可以成为构件, 在基于构件的软件开发中, 软件由构件装配而成。

构件复用模型如图1-1所示, 它融合了螺旋模型的特征, 本质上是演化的, 并且支持软件开发的迭代方法, 它是利用预先包装好的软件构件的复用为驱动构造来应用程序。首先标识候选类, 通过检查应用程序操纵的数据及实现算法, 并将相关的算法和数据封装成一个类。把以往软件工程项目中创建的类存于一个类库或仓库中, 根具标识的类, 就可搜索该类库。如果该类存在, 就从类库中提取出来复用。如果该类不存在, 就采用面向对象方法开发它。以后就可以使用从库中提取的类及为了满足应用程序的特定要求而建造的新类。进而完成待开发应用程序的第一次迭代。过程流程后又回到螺旋, 最后进入构件组装迭代。

统一过程模型 (Rational Unifi ed Process, RUP) 具有较高知名度的原因之一恐怕是因为其提出者Rational软件公司聚集了面向对象领域三位杰出专家Booch、Rumbaugh和Jacobson, 同时它又是面向对象开发的行业标准语言——标准建模语言 (Unifi ed Modeling Language, UML) 的创立者, 是目前最有效的软件开发过程模型。

3.5.2. 1 统一过程模型的基本原理

统一过程首先建立了整个项目的不同阶段, 包括初始阶段、细化阶段、构造阶段、交付阶段。同时每个阶段中又保留了瀑布模型的活动, 这里称为工作流, 即从需求、分析到设计和实现、测试等活动。所以, 可以将其理解为一个二维坐标, 工作流是一个竖坐标, 阶段构成了横坐标。但是, 二维坐标不是统一过程的主要思想, 它的主要思想是每个竖坐标表示的活动可能会产生多次迭代, 每个迭代会随着横坐标 (阶段) 的进展而产生变更, 最终逐渐减少甚至消失, 如图1-2所示。四个阶段, 九个核心工作流, 十大要素。

3.5.2. 2 统一过程模型开发过程各个阶段的里程碑

RUP中软件生命周期在时间上被分解为四个顺序阶段, 每个阶段结束于一个主要里程碑。初始阶段结束时是第一个重要里程碑:生命周期目标里程碑。主要成果有:项目蓝图文档、初始的用例模型、初始的项目术语表、业务用例模型。细化阶段结束时是第二个重要的里程碑:生命周期结构里程碑。主要成果有:系统架构基线、UML静态模型、UML动态模型、UML用列模型、修订的风险评估、修订的用例、修订的项目计划、可执行的原型。构造阶段结束时是第三个重要的里程碑:初始功能里程碑。主要成果有:可运行的软件系统、UML模型、测试用例、用户手册、发布描述。在交付阶段的终点是第四个里程碑:产品发布里程碑。主要成果有:可运行的软件产品、用户手册、用户支持计划。

RUP十大要素包括:开发前景;项目计划;标识和减小风险;分配和跟踪任务;检查商业理由;设计组件构架;对产品进行增量式的构建和测试;验证和评价结果;管理和控制变化;提供用户支持。

3.5.2. 3 统一过程模型在GIS设计的应用

由于RUP中的每个阶段可以进一步分解为一次迭代。与瀑布模型比较, 统一软件过程模型具有降低了在一个增量上的开支风险;加快了整个开发工作的进度;迭代过程的这种模式使适应需求的变化更容易;它的迭代模型建立了简洁和清晰的过程结构, 为开发过程提供较大的通用性。

统一软件过程模型非常适合GIS软件系统的开发。但是我们需注意的是RUP只是一个开放过程, 并没有涵盖软件过程的全部内容, 例如它缺少关于软件运行和支持等方面的内容;没有支持多项目开发结构, 这在一定程度上降低了在开放组织内大范围实现重用的可能。

3.6 敏捷开发过程

“敏捷”一词意味着快速、简单、灵活。敏捷开发过程强调以人为本, 注重编程中人的自我特长发挥。强调软件开发的主体是程序, 文档是为软件开发服务的, 不是开发的主体。敏捷开发特别重视客户参与开发, 因为开发者不是客户业务的专家, 所以一定要客户来阐述实际的需求细节。编制周密的计划是为了最终软件的质量, 但是为了要适应客户需求的不断变化, 计划和设计要不断调整。

敏捷就是“快”, 要快就要充分发挥每个人的个性思维, 个性思维的增多会造成软件开发规范性、一致性和可复用性的下降, 因此把敏捷开发与传统的“瀑布式”开发有机地结合。支持敏捷开发过程的极限编程就是强调交流、简单、反馈和勇气。另外并不是所有的GIS软件项目都适合敏捷开发, 例如, 难以分解的大型GIS应用软件、需要分布式开发的应用GIS软件等不适合敏捷开发。

4 GIS设计的未来展望

至上世纪90年代GIS进入产业化的阶段发展以来, GIS已经是一个全球拥有超过十万开发人员和数十亿美元的产业。世界各国已经设计出大量实用化的地理信息系统, 常见的GIS软件已经超过400种。当今国内外GIS的重要发展趋势是将地理信息系统融入国家信息化和知识经济的主体, 为资源环境问题的研究提供高技术手段, 形成新的经济增长点, 提高国家的安全能力。为此在未来仍需要大力发展业务化的GIS运行系统, 提高GIS的应用水平和效益。

由于GIS软件不同于一般程序, 它的一个显著特点是规模庞大, 而且程序复杂性将随着程序规模的增加呈指数上升。因此现有的计算机软件工程方法也不完全的适用于GIS设计, 未来还需要工程师和系统分析人员在GIS项目工程实施过程中进行研究与探索, 努力发展适用的GIS软件开发方法。

摘要：GIS从20世纪60年代问世以来已经经沥了近60个春秋的飞速发展。但随着GIS软件数量的飞速增长和软件规模的扩大, GIS软件危机情况已日益严重, GIS设计也将面临更大的挑战。笔者结合软件工程学的理论和思想, 通过合理的选用软件过程模型来为GIS设计提供思路。

关键词：软件工程,GIS工程学,GIS设计,软件过程模型

参考文献

[1]李满春, 任建武, 陈刚, 周炎坤.GIS设计与实现[M].北京:科学出版社, 2006.

[2]李伟波, 刘永祥, 王庆春.软件工程[M].武昌:武汉大学出版社, 2010.

[3]刘光, 刘小东.地理信息系统二次开发实例教程[M].北京:科学出版社, 2004.

[4]吴洁明, 方英兰.软件工程实例教程[M].北京:清华大学出版社, 2010.

[5]俎晓芳.浅析统一软件开发过程与GIS软件开发[J].内江科技, 2006, 27 (6) :103-104.

[6]郭建文, 冯敏, 李新.统一软件过程与地理信息系统的应用开发[J].遥感技术与应用, 2003, 18 (6) 422-428.