软件开发员岗位职责范本

篇2：ERP软件开发工程师岗位说明书

erp软件开发工程师是指专门负责erp软件的开发、维护以及管理等工作的技术人员。

erp软件开发工程师岗位职责

1、开发、维护erp软件系统,并参与系统测试;

2、分析、修改和设计项目,整理系统结构;

3、根据用户需求对系统做二次开发。

erp软件开发工程师岗位要求

1、计算机、软件工程、信息管理类专业大学大专及以上学历;

2、具有一定的软件研发经验,熟悉工作流程;

3、具备良好的专业知识储备,能熟练掌握sql数据库的使用,并熟练掌握任意一种或多种开发工具;

4、热爱软件开发和实施工作,工作严谨负责;

5、具有良好的沟通协调能力,能倾听他人的意见;

6、具有良好英文阅读能力和文本书写能力;

7、具有良好的身体素质和心理素质,抗压能力强;

8、具有良好的团队合作意识。

erp软件开发工程师关键技能

专业能力erp系统htmloffice办公

个人能力责任感理解能力开发经验

erp软件开发工程师升职空间

首先,erp软件开发工程师→系统分析员/需求工程师/算法应用开发工程师/高级软件工程师;

其次,erp软件开发工程师→it项目经理/技术经理;

最后,erp软件开发工程师→erp咨询顾问。

erp软件开发工程师薪情概况

应届毕业生$3300.00

1年经验$3400.00

2年经验$3800.00

3年经验$5100.00

erp软件开发工程师工作内容

1、erp平台维护与需求变更开发;

2、参与架构设计,并负责详细设计和编码;

3、综合运营平台系统的开发,深入了解业务,如erp、供应链系统;

4、对erp系统进行小范围的修改和二次开发;

5、协助erp系统的整体规划和实施;

6、协助用户的使用培训和指导。

篇3：职位说明书－嵌入式系统软件开发（单片机DLCDSP）

岗位描述:

1、主要从事芯片(cpu,layer2/3switch,ge-pon,vdsl,wirelesslan)功能的调查,芯片质量的测试、评估工作;

2、硬件相关驱动程序、网络协议、嵌入式系统软件抽象层等方面的软件开发;

3、负责智能设备软件设计与开发;

4、负责wince驱动开发。

任职资格:

1、本科学历以上,3年以上实际工作经验,25岁-30岁;

2、能运用英语进行会话;

3、有嵌入式系统软件(bsp,driver等低层)的开发经验(embeddedos:real-timelinu*,v*works,nuclears等);

4、有在uni*系统下用c语言进行开发的经验且实际工作使用3年以上;

5、有芯片功能的调查,芯片质量的测试、评估工作经验。

篇4：软件开发工程师职责范本

篇一:软件开发工程师职责

1、软件的程序设计与代码编写。

2、有关技术方案、文档的编写,软件单元的测试。

3、根据项目具体要求,承担开发任务,按计划完成任务目标。

4、配合系统分析人员完成软件系统以及模块的需求调研、需求分析。

5、独立完成软件系统及模块的编码。

6、协助测试人员完成软件系统及模块的测试。

7、负责编制与项目相关的技术文档。

8、根据项目具体要求,承担大型网站设计与开发。

9、部分软件功能模块设计和软件界面美化。

10、协助测试试人员完成软件系统及模块的测试。

篇二:软件开发工程师职责

1、mes程序的设计与开发;

2、适应性维护工作;

3、提高生产的效率,保障系统的稳定性及可靠性;

4、掌握生产流程,优化生产控制;

5、跟踪it技术进展,做好技术储备。

篇三:软件开发工程师职责

1.负责开发项目的系统分析、研发与组织实施

2.负责开发符合系统要求的软件内容

3.修改以有的系统方案,以维持优良的操作性能及正常的信息沟通

4.mes程序的设计与开发;

5.提高生产的效率,保障系统的稳定性及可靠性

6.适应性维护工作

7.掌握生产流程,优化生产控制

8.提供技术指导,促进系统操作技术和译码编程的有效使用

9.跟踪it技术进展,做好技术储备

10.推广完善公司系统,完成项目接口、开发工作

11.协助相关应用软件的安装调试工作

篇四:软件开发工程师职责

1、理解业务:理解用户业务,了解用户需求,明确用户要做什么,只有理解业务才有能力将业务转化为软件产品。

2、软件设计:根据用户需求和计算机软件、硬件的发展,采用成熟的技术实现应用系统的概要设计和详细设计。这是高级程序员的职责,也是我们努力的目标。

3、编码:根据设计方案编写、调试代码。这是最基本的要求。

4、测试:通过单元测试、集成测试等软件测试手段,查找、更正软件中存在的缺陷。目前,单元测试一般有开发人员完成,集成测试则由测试人员完成。

5、维护:软件交付客户后,还要参与软件的维护工作,及时解决客户使用中遇到的问题。

6、参加各种会议,参与评审:软件是多人合作的行业,与同事进行沟通交流是必备的能力。

篇五:软件开发工程师职责

1、指导程序员的工作;、

2、参与软件工程系统的设计、开发、测试等过程;

3、协助工程管理人保证项目的质量;

4、负责工程中主要功能的代码实现;

5、解决工程中的关键问题和技术难题;

6、协调各个程序员的工作,并能与其它软件工程师协作工作。

篇5：软件开发职责流程

1.传统开发流程的问题

传统的软件开发流程是一个文档驱动的流程,它将整个软件开发过程划分为顺序相接的几个阶段,每个阶段都必需完成全部规定的任务(文档)后才能够进入下一个阶段。如必须完成全部的系统需求规格说明书之后才能够进入概要设计阶段,编码必需在系统设计完成之后才能够进行。这就意味着只有当所有的系统模块全部开发完成之后,我们才进行系统集成,对于一个由上百个模块组的复杂系统来说,这是一个非常艰巨而漫长的工作。

随着我们所开发的软件项目越来越复杂,传统的瀑布型开发流程不断地暴露出以下问题:

需求或设计中的错误往往只有到了项目后期才能够被发现例如:系统交付客户之后才发现原先对于需求的理解是错误的,系统设计中的问题要到测试阶段才能被发现。

对于项目风险的控制能力较弱项目风险在项目开发较晚的时候才能够真正降低,往往是经过系统测试之后,才能确定该设计是否能够真正满足系统需求。

软件项目常常延期完成或开发费用超出预算项目开发进度往往会被意外发生的问题所打乱,需要进行返工或其他一些额外的开发周期,造成项目延期或费用超支。

项目管理人员专注于文档的完成和审核来估计项目的进展情况所以项目经理对于项目状态的估计往往是不准确的,当他回答系统已完成了80%的开发任务时,剩下20%的开发任务实际上消耗的是整个项目80%的开发资源。

在传统的瀑布模型中,需求和设计中的问题是无法在项目开发的前期被检测出来的,只有当第一次系统集成时,这些设计缺陷才会在测试中暴露出来,从而导致一系列的返工:重新设计、编码、测试,进而导致项目的延期和开发成本的上升。

2.采用迭代化开发控制项目风险

为了解决传统软件开发流程中的问题,我们建议采用迭代化的开发方法来取代瀑布模型。在瀑布模型中,我们要完成的是整个软件系统开发这个大目标。在迭代化的方法中,我们将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标,这些小目标都有一个定义明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而所从事的一系列开发活动,在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划,整个迭代过程包含了需求、设计、实施(编码)、部署、测试等各种类型的开发活动,迭代完成之后需要对迭代完成的结果进行评估,并以此为依据来制定下一次迭代的目标。

与传统的瀑布式开发模型相比较,迭代化开发具有以下特点:

允许变更需求

需求总是会变化,这是事实。给项目带来麻烦的常常主要是需求变化和需求"蠕变",它们会导致延期交付、工期延误、客户不满意、开发人员受挫。通过向用户演示迭代所产生的部分系统功能,我们可以尽早地收集用户对于系统的反馈,及时改正对于用户需求的理解偏差,从而保证开发出来的系统真正地解决客户的问题。

逐步集成元素

在传统的项目开发中,由于要求一下子集成系统中所有的模块,集成阶段往往要占到整个项目很大比例的工作量(最高可达40%),这一阶段的工作经常是不确定并且非常棘手。在迭代式方法中,集成可以说是连续不断的,每一次迭代都会增量式集成一些新的系统功能,要集成的元素都比过去少得多,所以工作量和难度都是比较低的。

尽早降低风险

迭代化开发的主要指导原则就是以架构为中心,在早期的迭代中所要解决的主要问题就是尽快确定系统架构,通过几次迭代来尽快地设计出能够满足核心需求的系统架构,这样可以迅速降低整个项目的风险。等到系统架构稳定之后,项目的风险就比较低了,这个时候再去实现系统中尚未完成的功能,进而完成整个项目。

有助于提高团队的士气

开发人员通过每次迭代都可以在短期内看到自己的工作成果,从而有助于他们增强信心,更好地完成开发任务。而在非迭代式开发中,开发人员只有在项目接近尾声时才能看到开发的结果,在此之前的相当长时间,大家还是在不确定性中摸索前近。

生成更高质量的产品

每次迭代都会产生一个可运行的系统,通过对这个可运行系统进行测试,我们在早期的迭代中就可以及时发现缺陷并改正,性能上的瓶颈也可以尽早发现并处理。因为在每次迭代中总是不断地纠正错误,我们可以得到更高质量的产品。

保证项目开发进度

每次迭代结束时都会进行评估,来判断该次迭代有没有达到预定的目标。项目经理可以很清楚地知道有哪些需求已经实现了,并且比较准确地估计项目的状态,对项目的开发进度进行必要的调整,保证项目按时完成。

容许产品进行战术改变

迭代化的开发具有更大的灵活性,在迭代过程中可以随时根据业务情况或市场环境来对产品的开发进行调整。例如为了同现有的同类产品竞争,可以决定采用抢先竞争对手一步的方法,提前发布一个功能简化的产品。

迭代流程自身可在进行过程中得到改进和精炼

一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况,而且还要分析组织和流程本身有什么待改进之处,以便在下次迭代中更好地完成任务。

迭代化方法解决的主要是对于风险的控制问题,从下图可以看出,传统的开发流程中系统的风险要到项目开发的后期(主要是测试阶段)才能够被真正降低。而迭代化开发中的风险,可以在项目开发的早期通过几次迭代来尽快地解决掉。在早期的迭代中一旦遇到问题,如某一个迭代没有完成预定的目标,我们还可以及时调整开发进度以保证项目按时完成。一般到了项目开发的后期(风险受控阶段),由于大部分高风险的因素(如需求、架构、性能等)都已经解决,这时候只需要投入更多的资源去实现剩余的需求即可。这个阶段的项目开发具有很强的可控性,从而保证我们按时交付一个高质量的软件系统。

迭代化开发不是一种高深的软件工程理论,它提供了一种控制项目风险的非常有效的机制。在日常的工作我们也经常地应用到这一基本思想,如对于一个非常大型的工程项目,我们经常会把它分为几期来分步实施,从而把复杂的问题分解为相对容易解决的小问题,并且能够在较短周期内看到部分系统实现的效果,通过尽早暴露问题来帮助我们及早调整我们的开发资源,加强项目进度的可控程度,保证项目的按时完成。

3.管理迭代化的软件项目

当我们在实际工作中实践迭代化思想时,Rational统一开发流程RUP(RationalUnifiedProcess)可以给予我们实践的指导。RUP是一个通用的软件流程框架,它是一个以架构为中心、用例驱动的迭代化软件开发流程。RUP是从几千个软件项目的实践经验中总结出来的,对于实际的项目具有很强的指导意义,是软件开发行业事实上的行业标准。

3.1软件开发的四个阶段

在RUP中,我们把软件开发生命周期划分为四个阶段,每个阶段的结束标志就是一个主要的里程碑(如下图所示)。

这四个阶段主要是为了达到以下阶段性的目标里程碑:

先启(Inception):确定项目开发的目标和范围

精化(Elaboration):确定系统架构和明确需求

构建(Construction):实现剩余的系统功能

产品化(Transition):完成软件的产品化工作,将系统移交给客户

每个目标里程碑都是一个商业上的决策点,如先启阶段结束之后,我们就要决定这个项目是否可行、是否要继续做这个项目。每一个阶段都是由里程碑来决定的,判断一个阶段是否结束的标志就是看项目当前的状态是否满足里碑中所规定的条件。

从这种阶段划分模式中可以看出,项目的主要风险集中在前两个阶段。在精化阶段中经过几次迭代后,我们要为系统建立一个稳定的架构,在此之后再实现更多的系统需求时,不再需要对该架构进行修改。同时,在精化阶段中,我们通过迭代来不断地收集用户的需求反馈,便得系统的需求逐步地明确和完整。

3.2关于开发资源的分配

基于RUP风险驱动的迭代化开发模式,我们只需要在项目的先启阶段投入少量的资源,对项目的开发前景和商业可行性进行一些探索性的研究。在精化阶段再投入多一些的研发力量来实现一些与架构相关的核心需求,逐步地把系统架构搭建起来。等到这两个阶段结束之后,项目的一些主要风险和问题也得到了解决,这时候再投入整个团队进行全面的系统开发。等到产品化阶段,主要的开发任务已经全部完成,项目不再需要维持一个大规模的开发团队,开发资源也可以随之而减少。在项目开发周期中,开发资源的分配可以如下图所示。

这样安排可以最充分有效地利用公司的开发资源,缓解软件公司对于人力资源不断增长的需求,从而降低成本。另外一方面,由于前两个阶段(先启和精化)的风险较高,我们只是投入部分的资源,一旦发生返工或是项目目标的改变,我们也可以将资源浪费降到最低点。在传统的软件开发流程中,对于开发资源的分配基本上是贯穿整个项目周期而不变的,资源往往没有得到充分有效地利用。

基于这种资源分配模式,一个典型的项目在项目进度和所完成的工作量之间的关系可能如下表中的数据所示

先启

精化

构建

产品化

工作量

~5%

20%

65%

10%

进度

10%

30%

50%

10%

3.3迭代策略

关于迭代计划的安排,通常有以下四种典型的策略模式:

增量式(Incremental)

这种模式的特点是项目架构的风险较小(往往是开发一些重复性的项目),所以精化阶段只需要一个迭代。但项目的开发工作量较大,构建阶段需要有多次迭代来实现,每次迭代都在上一次迭代的基础上增加实现一部分的系统功能,通过迭代的进行而逐步实现整个系统的功能。

演进式(Evolutionary)

当项目架构的风险较大时(从未开发过类似项目),需要在精化阶段通过多次迭代来建立系统的架构,架构是通过多次迭代的探索,逐步演化而来的。当架构建立时,往往系统的功能也已经基本实现,所以构建阶段只需要一次迭代。

增量提交(IncrementalDelivery)

这种模式的特点产品化阶段的迭代较多,比较常见的例子是项目的难度并不大,但业务需求在不断地发生变化,所以需要通过迭代来不断地部署完成的系统;但同时又要不断地收集用户的反馈来完善系统需求,并通过后续的迭代来补充实现这些需求。应用这种策略时要求系统架构非常稳定,能够适应满足后续需求变化的要求。

单次迭代(GrandDesign)

传统的瀑布模型可以看作是迭代化开发的一个特例,整个开发流程只有一次迭代。但这种模式有一个固有的弱点,由于它对风险的控制能力较差,往往会在产品化阶段产生一些额外的迭代,造成项目的延误。

这几种迭代策略只是一些典型模式的代表,实际应用中应根据实际情况灵活应用,最常见的迭代计划往往是这几种模式的组合。

3.4制定项目开发计划

在迭代化的开发模式中,项目开发计划也是随着项目的进展而不断细化、调整并完善的。传统的项目开发计划是在项目早期制定的,项目经理总是试图在项目的一开始就制定一个非常详细完善的开发计划。与之相反,迭代开发模式认为在项目早期只需要制定一个比较粗略的开发计划,因为随着项目的进展,项目的状态在不断地发生变化,项目经理需要随时根据迭代的结果来对项目计划进行调整,并制定下一次迭代的详细计划。

在RUP中,我们把项目开发计划分为以下三部分:

项目计划

确定整个项目的开发目标和进度安排,包括每一个阶段的起止时间段。

阶段计划

当前阶段中包含有几个迭代,每一次迭代要达到的目标以及进度安排。

迭代计划

针对当前迭代的详细开发计划,包括开发活动以及相关资源的分配。

项目开发计划也是完全体现迭代化的思想,每次迭代中项目经理都会根据项目情况来不断地调整和细化项目开发计划。迭代计划是在对上一次迭代结果进行评估的基础上制定的,如果上一次迭代达到了预定的目标,那么当前迭代只需要解决剩下的问题;如果上一次迭代中留有一些问题还没有解决,则当前迭代还需要继续去解决这些问题。所以必须注意,迭代是不能重叠的,即你还没有完成当前迭代时,你决不能进入下一迭代,因为下一次迭代的计划是根据当前迭代的结果而制定的。