软件维护岗位职责.docx
《软件维护岗位职责.docx》由会员分享，可在线阅读，更多相关《软件维护岗位职责.docx（13页珍藏版）》请在冰豆网上搜索。
软件维护岗位职责
软件维护岗位职责
软件维护人员职位概要及运维人员岗位职责软件维护人员职位职责：
全面负责公司业务有关的程序的开发和维护工作，对项目负责，负责公司项目的想象设计，编码、内部测试的组织和实施，按照标准流程对技术开发的代码和文档进行管理，及时完成上级交派的各项技术开发任务。
1．全面负责技术开发工作，并严格按照公司的标准流程进行开发和代码管理等工作；2．掌握必要的技术开发技能，满足日常开发工作的需求；3．建立标准的技术开发流程，方便公司对技术开发进行更好的管理；4．负责更换，维护公司已有软件或设备，解决在日常遇到的各类技术问题；5．良好的学习能力，不断的提高自身业务水平；6．恪守保密原则，不将公司内部机密外泄或用于其它不合法的用途，提交可供审核评定的工作成果，保证公司软件系统的正常使用，积极完成上级领导制定的其他开发任务。
运维管理人员岗位职责
1、机房硬件维护1.1环境要求A.服务器机房内必须保持整洁,不得放置无关的设备、物品；B.每日检查服务器机房的温度和湿度，一般情况下必须保持恒温、恒湿；C.服务器机房不能放置食品和水，不得在服务器机房内就餐；D.每日定时检查机房配电情况，如发现异常情况需通知相关负责人进行处理；E.一般情况下，无关人员不得进入服务器机房。
1.2开关机A.一般情况下，服务器不得随意关机，在以下情况
下，可以关机，需通知相关负责人，并尽量安排在晚上下班以后。
（1）.安装必要的服务
（2）.安装必要的软件（3）.正常的维护需要（4）.服务器在出现严重故障非重起不能解决时，通过邮件或电话方式通知相关负责人B.服务器在得到UPS停电通知时，必须在30分钟内关闭；C.服务器出现严重的硬件故障时，应立即通知网络用户并立即关机，同时通知相关负责人处理；D.服务器在开机时必须确认UPS供电是否正常。
2.软件环境
2、安装环境2.1软件安装A.软件安装需要安装在指定的目录下；B.软件安装操作如需要重启服务器，需要通知相关负责人，通知内容包括：
操作原因，操作可能造成的影响，操作时间等信息，得到批准后方能进行安装、重启服务器；C．严禁在服务器中私自安装与公司业务无关的软件，如私自安装软件造成公司业务受损，将追究个人的法律责任；日志检查与备份2.2日志检查与备份A.每天定时检查一次每台服务器的日志文件，如发现有“严重错误”的，必须立即检查并排除故障；B.所有日志需定时备份，每天应进行增量备份，每周需进行全备份一次。
C.备份文件夹统一为：
WindowsD:
\\\\DataBack\\\\下，文件名格式为：
01DD（日）MM（月）YY（年）2.3文件、磁盘检查每天检查每个服务器的磁盘情况，如果发现磁盘的使用容量超过70%以上时A．应及时删除不必要的文件腾出磁盘空间，必要时提报申购新的磁
盘；B.定时检查服务器相关文档，严禁存放违规的软件及资料，一旦发现，立即通知当事人，并要求解释，如果情节严重时，应去除该用户的访问权限，保留现场，同时通知相关负责人进行下一步处理；C.每月进行一次磁盘文件整理2.4.文件备份管理A.重要文件需进行定时备份；B.服务器重要数据，每周备份一次；C.每月进行一次备份检查。
2.5.服务器管理与故障收集A.服务器的故障包括：
软件故障，硬件故障，网站故障，黑客入侵与攻击，其他不可预料的未知故障等B.故障记录：
建立服务器故障日志数据库，对发现的各种故障现象进行详细记录，记录内容包括：
故障发生的时间，故障现象，故障位置，故障分析，故障原因，故障记录人员应尽快以书面或者电话或者其他相关形式
C.对于维护人员不能尽快处理的故障，尽快通知相关负责人并发布公告，自己保留相关记录存档。
D．需要对服务器进行软件改动和服务改动等更新申请时需要对相关负责人提交邮件申请，待主管人员批准后由专门的人员进行操作，并对操作记录进行登记备查。
E、各类故障处理流程首先检查网络状况，联系网络运维人员。
检查网络状况，如有必要，对服务器进行重启。
核查网络是否异常，登陆服务器检查服务器运行情况，如有必要，对服务器进行重启。
检查E10000信号是否正常，如出现异常，联系服务
端运维人员并与提供E10000线的部门人员取得联系询问具体问题是物理线路不通还是其他施工操作的问题。
高级java工程师
任职要求：
1、计算机相关专业大专以上学历，三年以上的java或android开发经验；
2、具有一定的编程能力，会使用Eclipse开发工具；
3、熟悉openGL优先；
4、熟悉android开发优先，会androidsdk使用，编译调试；熟悉android组件；
4、热爱软件开发工作，工作细致认真，有耐心；
5、具备较强的逻辑分析及学习能力，有良好的团队合作意识，有强烈的责任心和积极主动的工作态度，较强的沟通能力
驱动工程师
任职要求：
1）有从事过linux,android系统开发经验者优先；
2）熟练掌握一种CPU的体系结构，具有较强的分析和理解源代码的能力，熟悉ARM优先；
3）具备硬件开发能力者优先，能够分析和优化驱动的性能,针对特定硬件扬长避短；
4）能够独立完成驱动的功能开发任务，精通至少两种驱动，包括3G，LCD,Audio,Video,Memory,USB,Powermanager等；
5）精通3G/网络/通信开发者优先；
6）能够读写英文技术资料；
7）具备良好的沟通能力和团队合作意识，熟悉项目管理流程，能承受一定的工作压力；
测试工程师
任职要求：
计算机、通讯、电子等相关专业大专以上学历，1年以上软件测试或Android系统软件测试经验；
熟悉软件测试流程与测试方法；较强的文档撰写能力；
性格稳重，态度端正，工作严谨细致，责任心强；
善于分析思考,有较强的自学能力，有较好的团队合作意识。
高级（自动化）测试工程师
任职要求：
计算机相关专业本科以上学历，三年以上的软件开发或测试经验；
具有一定编程能力，至少熟悉一门语言，C或者java优先；
了解手机、平板电脑应用行业，熟悉Android,symbian、BlackBerry、WindowsMobile、iOS、ＭTK等任一平台，Ａndroid优先；
熟悉软件测试流程与测试方法，较强的技术文档撰写能力；
具有自动测试工具和性能测试工具的应用研究经验，Ａndroid平台相关经验优先；热爱软件测试工作，工作细致认真，有耐心；
具备较强的逻辑分析及学习能力，有良好的团队合作意识，有强烈的责任心和积极主动的工作态度，较强的沟通能力和表达能力。
有协议测试经验、有接口测试经验、有性能测试经验优先。
第8章软件维护
8.1软件维护的基本概念
教学难点：
软件维护的副作用和困难。
教学方法：
课堂讲授+讨论。
教学要求：
理解软件维护类型和策略，了解软件维护的成本，理解软件维护的副作用和困难。
思考题：
1）由于业务变化而修改软件是哪种类型的软件维护？
2）如何处理控制软件维护的副作用？
3）软件维护成本和软件开发成本哪个通常更高？
8.1.1软件维护类型
软件维护活动类型总起来大概有四种：
纠错性维护；适应性维护；完善性维护或增强；预防性维护或再工程。
除此四类维护活动外，还有一些其它类型的维护活动，如：
支援性维护（如用户的培训等）。
8.1.2软件维护策略
针对以上几种类型的维护，我们可以采取一些维护策略，以控制维护成本。
1、改正性维护
在开发过程中要生成100%可靠无误的软件通常是不太现实的，但通过使用一些新技术，可以大大减少进行改正性维护的需要。
2、适应性维护
运行环境的变化是不可避免的，但可以控制。
进行配置管理。
把硬件、操作系统和其他相关环境因素的可能变化进行配置管理。
修改局部化。
把因环境变化而必须修改的程序局部于某些程序模块中。
使用例行程序包等。
例如使用内部程序列表等，可为维护性修改程序提供方便。
3、完善性维护
利用前两类维护中列举的方法，可以减少此类维护。
另外，使用功能强且易于使用的工具和通过用户使用系统原型模型完整地确定系统需求等可以减少完善性维护的工作量。
4、预防性维护
可通过采用提前实现或软件重用等手段或技术来减少此类维护活动的工作量。
5、支援性维护
可通过提供最新用户文档或联机用户文档，进行适当的用户培训或设立专门的维护人员等方式来减少此类维护活动。
8.1.3软件维护成本
软件维护活动所花费的工作量占软件整个生存期工作量的70%以上。
影响软件维护工作量的因素有很多，就软件系本身而言，有以下几个方面：
1、系统的大小
系统的大小可用源程序语句数、模块数、输入/输出文件数，数据库所占字节数及预定义的用户报表数等来度量。
系统越大，功能就越复杂，理解并掌握起来就越困难。
因此维护工作量也就越大。
2、程序设计语言
语言的功能越强，生成程序所需的指令或语句数就越少，并且程序的可读性也越好。
一般地，语言越高级越容易被人们所理解和掌握。
因此，程序设计语言越高级，相应维护工作量也就减少。
3、系统年龄
系统越老，修改维护经历的次数就越多，从而结构也就越来越乱。
而且老系统会存在没有文档或文档较少或文档与程序代码不一致等现象。
同时，有可能老系统的开发人员已经离开，维护人员又经常更换，等等。
这些使得老系统比新系统需要更多的维护工作量。
4、数据库技术的应用
使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可减少生成用户报表应用软件的维护工作量。
5、软件开发新技术的运用
在软件开发时，使用能使软件结构比较稳定的分析与设计技术，以及程序设计技术，如面向对象技术、构件技术、可视化程序设计技术等，可以减少大量的工作量。
除此之外，应用的类型、任务的难度等对维护工作量都有影响。
8.1.4软件维护的副作用
所谓软件维护的副作用，就是指由于修改程序而导致的错误或其它不需要的活动。
Freedman和Weinberg定义了三类主要副作用，即：
修改代码的副作用、修改数据的副作用和修改文档资料的副作用。
为了控制因修改而引起的副作用，在修改时应做到：
1、按模块把修改分组；
2、自顶向下地安排所修改模块的顺序；
3、每次修改一个模块；
4、对于每个修改了的模块，在安排修改下一个模块之前，要确定这个修改的副作用。
可以使用交叉引用表、存储映象表、执行流程跟踪等。
8.1.5软件维护的困难
下面列出的是与软件维护有关的困难：
理解别人的程序困难，且困难程度随软件配置成分的减少而迅速增加。
需要维护的软件往往存在文档资料不全，甚至有文档也不易理解并和程序代码可能不一致。
当前，有些软件的文档是在代码形成后为了应付所谓的鉴定而突击出来的。
大多数软件在开发时没有考虑到将来的维护。
软件维护被人们看成是一种没有创造性的工作，往往不能引起人们的重视。
部分人认为，维护别人的程序不如开发新的程序。
显然，如果在软件定义和软件开发时期，重视采用软件工程思想，那么上述问题可以至少部分地解决。
当然，软件工程也不是万应灵药，软件工程也是在实践中不断地向前发展的。
8.2软件维护过程
教学内容：
软件维护的组织机构、维护申请、维护工作流程及评价。
教学重点：
维护组织机构及工作流程。
教学难点：
维护评价。
教学方法：
课堂讲授+讨论。
教学要求：
理解软件维护组织机构的作用，了解维护申请，熟悉软件维护流程，了解软件维护评价。
思考题：
1）软件维护记录的作用是什么？
2）软件维护组织有哪些角色？
其作用是什么？
8.2.1?
维护组织
通常，软件维护工作并不需要保持一个正式的组织机构。
但是，委派一个非专门的维护管理员负责维护工作是绝对必要的。
维护管理员、修改批准人员和系统管理员等分别代表了维护工作的某个职责范围。
维护管理员、修改批准人员可以是指定的某个人，也可以是一个包括管理人员、高级技术人员等在内的小组。
在维护活动开始之前就明确维护责任是必要的，这样可以大大减少维护过程中可能出现的混乱。
?
8.2.2维护申请
所有维护申请应按规定的方式提出。
维护组织通常提供维护申请表（MaintenanceRequestForm，简写为MRF），由申请维护的用户填写。
如果是改正性的维护，用户必须完整地说明出错的情况，如输入数据，全部输出信息以及其他有关材料。
如果申请的是适应性或完善性维护，则应提出一个简短的需求说明书。
维护申请表是由软件维护组织外部提交的文档，它是计划维护活动的基础。
软件维护组织内部应相应地做出软件修改报告（SoftwareChangeReport，简写为SCR），内容包括：
（1）为满足MRF要求所需工作量；
（2）维护要求的性质；
（3）维护申请的优先次序；（4）预计修改后的状况。
在进一步安排维护工作之前，应将软件修改报告提交给修改批准人员批准。
8.2.3维护工作流程
维护请求引起的工作流程：
（1）首先，要判明维护类型。
当用户和维护管理人员存在不同意见时应协商解决。
（2）对改正性维护请求，从评价错误的严重性开始。
如果存在严重错误，则应在系统管理员的指导下分派人员立即进行维护工作；否则，就同其它开发任务一起，统一安排工作时间。
（3）对适应性和完善性维护请求，应先确定请求的优先次序。
如果某项请求的优先次序非常高，就应立即开始维护工作；否则，就同其它开发任务一起，统一安排工作时间。
尽管维护请求的类型不同，但都需要进行同样的技术工作：
修改软件需求说明、修改软件设计、设计评审、对代码作必要的修改、单元测试、集成测试（回归测试）、确认测试等等。
为了正确、有效地修改源程序，通常需要经历以下三个步骤：
1）分析和理解程序；2）修改程序；3）重新验证程序。
8.2.4维护记录与评价
如果对维护不保存记录或保存不充分，那么就无法对软件使用的完好程度进行评价，也无法对维护技术的有效性进行评价。
Swanson提出了下述内容：
⑴程序标识；
⑵源程序语句数；
⑶机器代码指令数；
⑷使用的程序设计语言；
⑸程序交付日期；
⑹程序交付以来的运行次数；⑺自交付以来程序失效的次数；
⑻程序变动的层次和标识；
⑼因程序变动而增加的语句数；
⑽因程序变动而删除的语句数；⑾每项修改耗费的人时数；
⑿程序修改日期；
⒀软件工程师名字；
⒁维护请求表的标识；⒂维护类型；
⒃维护开始与结束日期；
⒄累计用于维护的人时数；
⒅与完成的维护相联系的效益。
将上述18项数据作为维护数据库的基础，可以从以下7个方面度量维护工作：
⑴程序运行失败的平均数；
⑵用于每类维护活动的总人时数；
⑶平均每个程序、每种语言、每种维护类型所做的程序变动数；⑷维护过程中增加或删除一个源程序语句平均花费的人时数；⑸维护每种语言所花费的工作量（平均人时数）；⑹一张维护申请表的平均周转时间；⑺不同维护类型所占百分比。
?
8.3软件可维护性
教学内容：
影响软件可维护性的三个属性、软件可维护性度量、提高可维护性的方法。
教学重点：
提高可维护性的方法。
教学难点：
软件可维护性度量。
教学方法：
课堂讲授+讨论。
教学要求：
理解软件可维护性的三个软件属性，了解定量的软件可维护性度量，掌握提高软件可维护性的方法。
思考题：
8.3.1影响软件可维护性的软件属性
定性地说，软件可维护性又取决于软件的三个属性，即：
可理解性、可修改性与可测试性。
1、可理解性
软件可理解性表现为人们通过阅读源代码和相关文档，理解软件的结构、接口、功能和内部过程的容易程度。
模块化和结构化设计、文档、程序设计语言等都对软件的可理解性有较大的影响。
而且，软件越复杂，理解也就越困难。
2、可测试性
可测试性代表一个软件容易被测试的程度。
它一方面与源代码有关，要求程序易理解；另一方面，要求有齐全的测试文档，包括开发时期用过的测试用例与结果。
3、可修改性
可修改性表明程序容易修改的程度。
一般来说，模块设计的内聚、耦合、局部化、作用域/控制域等因素都会影响软件的可修改性。
模块抽象和信息隐蔽愈好，模块的独立性愈高，则修改中出错的机会也就愈少。
?
?
8.3.2软件可维护性的定量度量
1979年，T.Gilb建议把维护过程中各种活动耗费的时间记下来，以此来间接度量软件的可维护性。
记录的时间如下：
⑴问题识别的时间；
⑵因管理活动拖延的时间；⑶收集维护工具的时间；
⑷分析、诊断问题的时间；⑸修改规格说明的时间；
⑹具体的改错或修改的时间；⑺局部测试的时间；
⑻集成或回归测试的时间；⑼维护评审的时间；
⑽分发与恢复运行的时间。
显然，以上10项表明了一个维护过程所包含的全部活动。
可以粗略地认为，这个周期越短，维护就越容易。
8.3.3提高可维护性的方法
软件的可维护性对于延长软件的寿命具有决定性的意义。
因此，不仅维护人员应重视软件的可维护性，软件开发人员也要为减少今后的维护工作量而努力。
为了提高软件的可维护性，可以从以下几个方面着手：
（1）建立明确的软件质量目标和优先级；
（2）使用提高软件质量的技术和工具；（3）进行明确的质量保证审查；（4）选择可维护的程序设计语言；（5）改进程序文档；
（6）开发时考虑到维护。
8.4软件再工程技术
教学内容：
逆向工程、正向工程、重构、成本/效益分析、再工程风险分析。
教学重点：
逆向工程、正向工程、重构。
教学难点：
再工程成本/效益分析、风险分析。
教学方法：
课堂讲授+讨论。
教学要求：
理解逆向工程和正向工程，掌握重构，了解再工程成本/效益分析和风险分析。
思考题：
软件重构的目标是什么？
重构的对象有哪些？
8.4.1逆向工程
术语“逆向工程”源自硬件领域，是一种通过对产品的实际样本进行检查分析，得出一个或多个关于这个产品的设计和制造规格的活动。
软件的逆向工程与此类似，通过对程序的分析，导出更高抽象层次的表示，如从现存的程序中抽取数据、体系结构、过程的设计信息等，是一个设计恢复过程。
逆向工程过程所抽取的信息，一方面可以提供给软件工程师以便在任何维护活动中使用这些信息；另一方面可以用来重构原来的系统，使新系统更易维护。
?
?
8.4.2重构
软件重构是对源代码和/或数据进行修改，使其易于理解或维护，以适应将来的变更。
通常，重构并不修改整个软件程序的体系结构，趋向于关注模块的细节。
如果重构扩展到模块边界之外并涉及软件体系结构，则重构变成了正向工程。
软件重构中代码重构的目标是生成可提供相同功能但质量更高的程序。
需要代码重构的模块往往以难于理解、测试和维护的方式编码。
为此，用重构工具分析源代码，标注出和结构化程序设计概念相违背的部分，然后重构此代码，复审和测试生成的重构代码，更新代码的内部文档。
8.4.3正向工程
正向工程也称为改造，用从现存软件恢复设计中得到的信息去重构现存系统，以改善其整体质量。
在大多数情况下，被再工程的软件需重新实现现存系统的功能，并加入新功能和/或改善整体性能。
正向工程过程将应用软件工程的原则、概念和方法来重建现存应用。
由于软件的原型（现存系统）已经存在，正向工程的生产率将远高于平均水平；同时，又由于用户已对该软件有经验，因而正向工程过程可以很容易地确定新的需求和变化的方向。
这些优越性使得再工程比重新开发更有吸引力。
8.4.4再工程成本/效益分析
再工程花费时间，并占用资源。
因此，一个组织试图再工程某现存应用之前，有必要进行成本/效益分析。
Sneed提出了再工程的成本/效益分析模型，涉及以下几个参数：
P1：
当前对某应用的年维护成本P2：
当前某应用的年运行成本P3：
当前某应用的年收益
P4：
再工程后预期年维护成本P5：
再工程后预期运行成本P6：
再工程后预期业务收益P7：
估计的再工程成本P8：
估计的再工程日程
P9：
再工程风险因子（名义上P9=1.0）L：
期望的系统生命期（以年为单位）
则有：
①和未执行再工程的持续维护相关的成本：
Cmaint=[p3-（p1+p2）]*L②和再工程相关的成本：
Creeng=[p6-（p4+p5）*（L-p8）-（p7*p9）]③再工程的整体收益：
Cbenefit=Creeng-Cmaint
8.4.5再工程风险分析
再工程和其它软件工程活动一样可能会遇到风险，作为软件管理人员必须在工程活动之前对再工程风险进行分析，以提供对策，防范风险带来的损失。
再工程风险主要有以下几个方面：
（1）过程风险：
未进行再工程成本/效益分析或在规定的时间内未达到成本/效益要求；对再工程项目的人力投入缺乏管理；对再工程方案实施缺乏监督等等。
（2）应用领域风险：
再工程项目缺少本地应用领域专家支持；对源程序中体现的业务知识不熟悉；等等。
（3）技术风险：
恢复设计得到的信息无用或未被充分利用；逆向工程得到的成果不可分享；缺乏再工程技术支持；等等。
8.5小结
软件维护是软件生存周期的最后一个阶段，也是成本最高的阶段。
软件维护阶段越长，软件的生存周期也就越长。
软件工程学的一个主要目的便是提高软件的可维护性，降低软件维护的代价。
软件维护不同于硬件维护，通常有四种类型：
改正性维护、适应性维护、完善性维护和预防性维护。
软件维护大多要涉及到软件设计内容的修改，从而要重视软件维护的副作用，对软件维护要有正式的组织，制定规范化的过程，实行严格的维护评价。
软件再工程是提高软件可维护性的一类重要的软件工程活动。
同软件开发相比，软件再工程不是从编制规格说明开始，而是从原有的软件出发，通过一系列再工程活动，得到更易维护的新系统。
升级会员 