文档介绍：计算机软件维护论文计算机软件论文
摘要:国内大多数公司在外包软件维护项目过程中,由于信息不对称、软件工作可见性差、人员变动大,普遍存在着无法对外包厂商进行有效管理、工作量无法估算和监控、维护风险大等问题。根据多年外包公司管理经验,针对代码维护频繁、质量要求严格的软件维护项目提出了一种维护项目管理方法,从流程管理上进行有效的监控,在提高维护质量的同时从控制工作量的角度控制维护费用,取得了较好的效果。
关键词:软件;维护;项目管理
正文:
二、项目内容
本项目中的维护任务主要指为保障信息系统正常运行提供支持服务,配合业务变更对软件系统进行维护等,包括软件功能变更等开发维护、日常运维支持和一些临时性工作需求。根据风险控制等管理需要,将维护工作分为以下五类,不同的工作类别采用不同的管理手段。(1)新增功能。在业务模块中添加新的业务功能或操作。(2)功能变更。对已上线使用的业务功能进行修改、完善和功能扩充或变更、下线操作。以上两类一般需要修改源代码,明确需求后,经过严格的变更影响分析,按照开发流程实施,经过测试后上线。(3)辅助性操作。分为数据相关和非数据相关两个部分,不涉及代码的修改,用于支持用户更好地开展工作或者进行开发的辅助工作。数据相关工作主要是配合用户的临时需求进行数据统计、回溯等工作;非数据相关工作包括用户账户开设、培训、应用软件安装等事务性工作。(4)常规操作。周期性的系统运维工作,包括日常例行检查、日常维护操作等。(5)应急处理。对各类因系统故障、软件功能缺陷等突发事件处理和应对,确保系统尽快提供服务,避免对业务的开展造成影响。
三、维护工作管理
根据合同中约定,对外部厂商主要从派出人员、提供工作量两个方面进行控制。派出人员出勤率和人员素质等比较容易考核,本文不做详细介绍。不同的维护工作采用不同的工作量估算和审核过程,一般遵循明确需求,外包厂商项目经理估算工作量,用户项目经理审核计划工作量,外包厂商编写计划,实施并登记实际工作量,用户项目经理审核实际耗费工作量的大致过程,根据维护工作类别不同需要遵循各自的工作量审核步骤。新增功能、变更功能由于工作复杂,且周期长,采用“维护工作申请单”记录需求和相关的审批流程,详细估算维护工作量,并用项目日报逐日记录实际发生的工作量;辅助性操作和常规操作一般单次维护工作量小且周期短,仅用项目日报记录工作量,采用定时抽查核准的方法评估工作量;常规操作使用“操作记录单”,记录操作日志和实际花费时间;应急处理由于事情紧急,一般不预先估计工作量,采用事后确认的方法记录工作量。以占工作量比重最大、审核最严格的新增、变更工作类别为例进行介绍。
3•1 利益相关者在该项目管理中主要涉及以下几类利益相关者: (1)用户代表。作为需求方和信息系统使用人员的代表,提出日常维护需求,负责维护需求提出、确认,系统变更后验收和使用。(2)用户项目经理。出资人代表,代表上海证券交易所对项目进行总体协调和管理,负责合同相关事项管理。(3)技术负责人。用户方信息系统的技术负责人,是信息系统的系统管理员、数据库管理员、业务系统技术代表的统称,协助用户项目经理对外包厂商提出的技术方案、工作量进行评估把关和批准,协同评估变更影响分析,批准变更。(4)外包厂商项目经理。外包厂商项目组负责人,与用户项目经理、用户代表、技术负责人等有关人员协调,组织维护组成员高质量地完成维护工作。(5)维护组。由外包厂商派出,维护工作实际执行人,在外包厂商项目经理组织下完成各项代码维护和辅助工作。
3•2 生命周期模型为了便于对维护项目进行管理,鉴于维护变更周期短、频率高、每次变化小且需求容易把握的特点,每个阶段工作完成通过评审后,一般很少重新返回到上一阶段。参照线性顺序模型[1](瀑布模型)制定了符合项目运行日常需要的软件维护项目生命周期模型,每一项软件维护工作均遵循该模型。(1)需求调研和分析。完成需求调查、变更影响分析、风险评估及维护工作量估计等工作,以批准变更作为标准。复杂的变更需求需要提交技术方案。(2)概要设计。软件架构和接口设计。(3)详细设计。各软件模块的实现方法。(4)编码和单元测试。编写代码,测试模块的准确性。(5)集成测试和系统测试。测试和验证变更是否符合需求,对系统进行回归测试。(6)发布和验收测试。批准上线,上线实施,上线后验证。其中,概要设计、详细设计、编码和单元测试、集成测试和系统测试主要由维护组完成;需求调研和分析阶段、发布和验收测试由双方共同完成。
3•3 项目流程控制项目流程是为产出预期成果(产品或服务)而将人员、材料、能源、设备和信息结合成为工作活动的逻辑构成。制定合理的流程,可以明确各工作活动内容、活动的参与人、入口和出口准则及度量考核数据等内容,从流程制定中明确工作要点,在活动中积累数据