企业信息系统开发工作标准.docx
《企业信息系统开发工作标准.docx》由会员分享,可在线阅读,更多相关《企业信息系统开发工作标准.docx(23页珍藏版)》请在冰豆网上搜索。
企业信息系统开发工作标准
北京xx集团信息系统开发工作标准
(A-0)
一、总则
1.目的和作用
为加强公司信息系统开发过程的管控力度,进一步提高系统开发的质量和水平,根据公司《信息系统建设管理办法》及相关规定,制定本标准。
2.适用范围
本标准是公司范围内信息系统开发的指导性文件。
本标准适用于公司范围内企业管理信息系统的开发工作,包括不同类型、不同规模的城市事业部、控股公司所建立的不同系统。
公司所属子公司、下属分公司或分支机构(以下简称所属机构)、控股公司在贯彻执行本标准过程中可根据自身的特点对标准的有关内容进行适当的调整和补充。
本标准所推荐的文档,在使用过程中可根据实际情况进行选择和调整。
3.主要内容
根据管理信息系统开发特点,将系统开发工作划分为:
项目启动、项目计划、项目执行、项目结束四个阶段。
也对建设方与开发方在各阶段的工作内容、文档要求等做出了相应的技术及管理约定。
同时,对于不同信息系统间进行集成时的数据接口开发工作也规定了相应的技术标准。
4.规范性引用文档
GB/T8566-2007《信息技术软件生存周期过程》
GB/T8567-2006《计算机软件文档编制规范》
二、术语定义
1.企业管理信息系统
企业管理信息系统是综合利用计算机技术、通信技术、管理科学,对企业内外部管理信息进行收集、加工、存储、传输、维护和使用,辅助企业的各级管理人员控制、决策及趋势预测,以实现企业管理目标的计算机系统。
2.信息系统开发周期
根据信息系统项目开发的管理特点,科学地将开发周期分为项目启动、项目计划、项目执行、项目结束四个阶段,内容上涵盖可行性分析、需求分析、总体设计、详细设计、编码、测试、验收等工作。
3.系统测试
针对整个信息系统,即将已经确认的软件系统、计算机硬件、外设、网络等相关元素结合在一起进行测试,目的是验证系统是否满足需求规格的定义,找出与需求规格不符或与之矛盾之处,从而提出解决方案的过程。
4.数据接口
软件开发商向用户或者第三方提供的一系列的数据标准规范,其作用是进行不同软件系统间特定数据的交流及转换。
其形式可以是经过封装的应用程序的接口函数,也可以是一些固定格式的数据文件,或是数据库的某种具体形式。
三、系统开发工作
1.系统开发周期
信息化项目系统开发周期应分为启动、计划、执行、结束四个阶段(如下图)。
各阶段工作应按顺序依次完成。
建设方应对每个阶段工作任务完成情况进行验收确认,原则上不允许在未对上一阶段成果进行确认与验证的情况下,进入下一阶段。
可根据项目实际情况对此阶段划分进行调整。
2.启动阶段
2.1项目启动阶段,建设方首先应进行目标系统的领域研究工作,对项目进行可行性研究,从而明确信息系统开发建设目标,同时确定系统开发项目工作的范围,评估所需资源、风险、预算等条件。
具体工作如图2.1所示.
图2.1启动阶段工作任务及文档
2.2在系统开发之前,建设方应对所开发系统的行业领域状况进行背景研究工作,为项目论证提供依据,研究内容应包括:
(1)开发系统所在领域的现状和前景;
(2)开发系统普遍采用的商业模式和业务流程;
(3)行业内各开发商的现状;
(4)开发系统的特性和复杂度。
2.3建设方应基于商业和技术等因素,对目标系统进行可行性论证,确定项目是否开展。
论证的内容包括:
(1)商业可行性;
(2)技术可行性;
(3)与行业内类似系统的比较;
(4)与本单位已有系统的集成可行性;
(5)开发的成本和风险;
(6)项目开发的总体方案。
具体内容请参考附件1《项目可行性分析报告》。
对于重大或复杂项目,建设方可酌情聘请专业信息化咨询方介入,协助把控项目论证及以后各阶段的具体工作。
2.4项目启动阶段,建设方应组织各相关方对项目的目标范围进行确认,形成《项目开发大纲》向开发方交底,并为项目开发的计划阶段做准备。
《项目开发大纲》的内容如表2.4所示。
表2.4
内容
说明
概述
明确系统目的。
核心功能
描述系统每个核心功能。
一般功能
描述系统通用的非核心功能。
相关方
基于建设方管理模式,明确系统开发所涉及到的各个相关方(如主责部门、需求部门、咨询方、开发方等)。
项目需求
描述总体的项目需求。
项目风险
对可预见的风险进行分析,并提出规避风险的主要措施。
项目回报
系统上线后的成果性预测。
结论
将上述所有部分联系起来,明确项目的需求和风险,确定项目可以最终成功的论点与论据。
3.计划阶段
3.1项目计划阶段,建设方应与开发方一起确定项目的功能范围、质量与进度目标,开发方评估每项工作的工作量及所需资源;双方在此基础上共同制定整体的项目管理计划,应包括:
项目开发计划、风险管理计划、质量保证计划及开发进度计划。
具体工作如图3.1所示。
图3.1计划阶段工作内容及文档
3.2在计划阶段,建设方应要求开发方对项目的规模、工作量等进行评估,并进行确认。
开发方应出具工作量评估报告。
评估的内容包括:
(1)模块数量、复杂度、质量目标;
(2)输入、输出和对外接口数量与复杂度;
(3)重要功能点;
(4)开发工作量(人/月或人/天);
(5)进度与里程碑;
(6)进度风险。
3.3开发方出具的《项目开发计划》内容见下表3.3。
表3.3
内容
说明
概述
描述系统目标、功能、平台、客户、大体进度和开发职责。
系统功能
建设方概述系统的功能,包括这些功能的附加信息,以便开发方根据这些的信息来了解并实现需求。
项目成员
确定软件工程职能角色,以及分配到这些角色的人员数量。
系统开发过程
概述这个项目中所应用的软件开发过程。
系统开发方法
概述这个项目中所应用的软件工程方法和技术。
进度和工作量
描述整个项目进度和工作量,明确标明各里程碑和关键结点的工作成果。
可用甘特图等工具图展示。
软件工具
列出将使用的每一项软件工具,以及该工具所支持的任务。
项目支持
硬件支持--明确所需的硬件,包括需要移动、获取或升级的硬件。
软件支持--明确所需的软件,包括需要获取、安装或升级的软件。
人力支持--明确建设方哪些人员为开发方的哪项任务提供支持。
3.4建设方与开发方应共同制定《风险管理计划》,主要内容包括风险识别、风险分析、化解方案等,详见表3.4:
内容
说明
概述
用文字和图表概述风险管理任务的总体执行流程。
风险识别
详细说明“风险识别”任务的实施细节和各项工作的负责人。
风险分析
确定风险优先级,明确“风险分析”实施细节和各项工作的负责人。
风险化解方案
描述当风险发生时,化解工作的操作规范和流程。
风险监控
详细说明风险监控任务的实施细节和各项工作的负责人。
3.5建设方与开发方共同制定《质量保证计划》,内容见下表3.5.
表3.5
内容
说明
概述
简单说明编写的目的、适用范围以及对相关人员的要求等。
软件开发过程
详细说明这个项目中所应用的软件开发过程。
软件工程方法
详细说明这个项目中所应用的软件工程方法和技术。
工作规范
对软件工程方法中的各种工作任务进行规范,明确执行的时间、流程和准则等。
这些工作任务规范包括但不限于:
---需求分析、架构设计、详细设计、编码和测试、验收等常规开发活动规范;
---工作例会、进度会议、审查会议等会议规范;
---方案评审、技术评审、质量评审等评审工作规范;
---系统规模评估、进度评估、缺陷评估、测试覆盖率评估等评估工作规范;
---技能培训、资料收集、客户沟通等其他工作。
3.6建设方应重点审查开发方提交的《开发进度计划》,主要内容包括工作任务项、任务描述、开始时间、完成时间、工作量、责任人、交付成果等。
详见附件2《项目开发进度计划表》。
4.执行阶段
4.1项目执行阶段,建设方应根据项目管理计划配合开发方完成需求规格说明,监督开发方按照需求实现具体功能,并在过程中协调一切所需资源,如人员、设备、费用、技术、信息等,同时跟踪各项工作的完成质量,把控项目整体进度。
具体工作如图4.1所示。
图4.1执行阶段工作内容及文档
4.2开发方应以建设方《项目开发大纲》等需求文档为依据,进行详细的需求梳理,直到细化的程度可以开展架构设计及界面原型设计工作,形成《需求规格说明书》,内容见表4.2。
《需求规格说明书》的编制方式可根据实际情况进行调整或扩充,但必须包含以下内容:
表4.2
内容
说明
业务需求
归纳描述建设方提出的业务内容、必须实现的功能、需要达到的性能及质量等要求。
功能需求
根据上述建设方列出的业务需求,详细列出开发商必须实现的功能。
性能需求
(1)描述对运行速度、容量、并发性能的要求。
(2)描述对资源的利用率的要求。
(3)描述对外界输入的反馈速度和准确性的要求。
(4)描述对差错的负荷能力的要求。
系统需求
(1)描述目标系统必须适应的运行环境的要求(包括运行平台、网络及其他硬件要求)。
(2)描述与其他系统兼容的要求(包括与操作系统、数据库、浏览器及其他已有应用软件的兼容要求)。
(3)描述与外部其他系统和组件的接口要求。
质量需求
(1)约定对建设方重要的质量标志(可靠性、效率性、灵活性、安全性、互操作性、稳定性、健全性、可用性)。
(2)约定对开发方重要的质量标志(可维护性、可扩展性、重复使用性、可测试性)。
其他需求
不属于上述需求范围的,但受到其他因素影响的要求,如:
--国家或地区的任何特别的标准。
--软件使用界面的特别要求。
--与知识产权有关的要求。
--软件所面对的市场和行业的规范。
--建设方的特别要求等。
需求规格说明书的具体内容,可参考附件3《需求规格说明书模版》。
4.3开发方应主导完成系统总体设计,并应在第一时间完成系统原型实施工作,以验证设计思路的可行性,同时提交《系统原型设计概要》文档,内容主要包括设计的理念、核心功能的设计与实现及与类似系统界面的对比等。
开发方应与建设方一起对原型的界面设计及核心功能等进行开会讨论及确认。
4.4开发方根据需求分析及系统原型设计所确定的系统核心功能进行系统详细设计。
对于重要的功能、算法、公共模块和外部接口等,建设方应要求开发方必须以模块设计说明书的形式进行详细描述,内容包括系统核心模块功能名称、设计思想、设计图表(类图、流程图等)、要点描述(包、接口、类、方法、算法、设计模式)及测试方式等。
4.5开发方在系统编程阶段应遵守行业编码规范,应充分考虑异常情况和临界条件,并对测试中产生的BUG进行记录。
4.6开发方在系统编程过程中应以功能增量的方式执行阶段的开发任务,每个阶段结束后应发布软件中间版本。
阶段周期一般不超过两星期。
对于每一个中间版本,由开发方负责主导测试工作,建设方配合参与,做到问题早发现早解决。
测试发现的问题应留待下一周期中间版本解决。
对每一中间版本的测试工作,开发方应总结形成《中间版本测试报告》的内容包括:
(1)测试用例汇总(用例数量、通过的用例数量、未通过的用例数量等);
(2)BUG汇总表(BUG描述、BUG状态等);
(3)测试计划执行情况等。
4.7项目执行过程中出现的多种变更,如:
需求变更、设计变更等,建设方与开发方应共同评估变更风险及制定解决方案,并对变更处理过程进行跟踪,最后形成变更处理报告,具体格式及内容请参考附件4《变更处理报告》。
5.结束阶段
5.1系统开发的结束阶段,建设方应确保开发方所提交的目标系统达到需求的要求,进行整体测试与验收,归档各种项目文档,对整个项目过程进行总结等工作,具体工作如图5.1所示。
图5.1结束阶段工作内容和文档
5.2系统正式发布之前,建设方必须组织自身相关人