软件开发与维护管理规范(1)

软件开发与维护管理规范(1)
软件开发与维护管理规范(1)

软件开发与维护管理规范

1目的

通过规范软件的开发与维护过程,达到提高软件质量,降低维护成本的目的。

2 范围

适用于新产品的软件开发设计以及定型产品的改进升级。

3 职责与权限

3.1 研发中心负责:

a) 编制软件开发过程的实施、协调和控制工作;

b) 编制各阶段的技术文件;

c) 组织软件的测试、验收、升级和维护工作。

3.2 各部门参与软件开发过程中有关的设计评审。

4 内容

4.1 软件项目的开发实施过程管理要求

4.1.1 软件项目实施过程总体要求

本部分主要要求工程师制定软件开发工作计划,对过程进行控制,一般包括以下的内容。a)工程师提交软件开发工作大纲,项目组织者对工作大纲进行评审,并提出整改意见。

b)通过评审后,工程师根据整改意见完善工作大纲,经过项目经理认可后组织项目组进行软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行,在开发过程中,工程师需分阶段提交相关文档。

c)在软件开发工作完成后,工程师应向项目组提交完整的软件文档,相关人员组织验收组对软件进行验收审查。

4.1.2 软件项目实施变更要求

在开发过程中,需求或设计不可避免地需要发生变更,相关变更必须提交《软件变更申请》经过项目组书面同意方可进行。在需求或设计发生变更时,需要对原有文档进行修改,并提供完整的变更记录,以使变更处于可控制的状态。

4.1.3 软件项目实施里程碑控制

本部分主要对软件开发过程中的重要节点进行控制。

项目组将分四个阶段进行把关,召开审查会。

a)需求分析(结合原型进行审查)确认;

b)概要设计+数据库设计;

c)预验收(样机测试时);

d)正式验收(产品定型后)。

4.2 软件开发

软件开发必须严格按照软件工程的要求进行。开发过程包括工程师的活动和任务。此过程由软件需求分析、概要设计、详细设计、编码、测试、验收、鉴定等活动组成。

4.3 软件的需求分析

4.3.1 需求分析

4.3.1.1需求分析要求开发人员准确理解用户的需求,进行细致的调查分析,将用户非形式的需求陈述转化为完整的需求定义,再由需求定义转化到相应的形式功能规约《软件需求规格说明书》的过程。

4.3.1.2 在《软件需求规格说明书》必须描述的基本问题是:功能、性能、强加于实现的设计限制、属性、外部接口。

4.3.2 需求报告评审

在软件需求分析工作完成后,软件工程师应向项目组提交《软件需求规格说明书》。项目组组织有关人员(系统客户和系统开发人员等)对需求进行评审,以决定软件需求是否完善和恰当。项目组严格验证这些需求的正确性,一般从一致性,完整性,现实性,有效性四个方面进行验证。评审完成后,就可以进入软件的设计阶段。

4.4 软件的概要设计

4.4.1 概要设计

概要设计也称为系统设计,需要确定软件的总体结构,应该由哪些模块组成,以及模块与模块之间的接口关系,软件系统主要的数据结构和出错处理设计等,同时还要制定测试方案,形成概要设计说明书,为软件的详细设计提供基础。在概要设计时一般从以下几方面来考虑,

遵循以下的流程。

4.4.3 概要设计和需求分析、详细设计之间的关系和区别

需求分析不涉及具体的技术实现,而概要设计注重于从宏观上和框架上来描述采用何种技术手段、方法来实现这些需求。详细设计相对概要设计更注重于微观上和框架内的设计,是编码的依据。概要设计是指导详细设计的依据。

4.4.4 概要设计的评审

在软件概要设计工作完成后,软件工程师应向项目组提交《软件概要设计》。评审通过后,即可进入详细设计阶段。

4.5 软件的详细设计

4.5.1详细设计

在概要设计的基础上,工程师需要进行软件系统的详细设计。在详细设计中,描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系,需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑,以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细,能够根据详细设计报告进行编码。4.5.2 特例

如果软件系统比较简单,层次较少,可以不必进行专门的详细设计,而和概要设计结合起来。

4.5.3 数据库设计

如果软件产品需要使用到数据库,软件的详细设计应包括对数据库的设计。数据库设计应在软件的需求分析、软件概要设计完成之后、详细设计的其它工作之前进行,编写《数据库设计说明书》。

4.5.4 详细设计的评审

在软件详细设计完成后,软件工程师应向项目组提交《数据库设计说明书》和《软件详细设计说明书》。评审通过后,即可进入软件编码阶段。

4.6 软件的编码

4.6.1 软件编码

在软件编码阶段,工程师根据《软件详细设计说明书》中对数据结构、算法分析和模块实现等方面的设计要求,开始具体的编写程序工作,分别实现各模块的功能,从而实现对目标系

统的功能、性能、接口、界面等方面的要求。

作为软件工程中的一个阶段,编码是对设计的进一步具体化,因此,程序的质量主要取决于软件设计的质量。但程序设计语言的选择以及编码风格也对程序的可靠性,可读性,可测试性和可维护性产生深远的影响。

4.6.2 编程规范及要求

为了提高编程实现的质量,软件的程序设计必须遵照国家颁布的相关编程规范。主要内容包括:规范化的程序内部文档、数据结构的详细说明、清晰的语句结构、编码规范。编码规范的内容包括命名规范、界面规范、提示及帮助信息规范、热键定义等。

在软件编码的同时应进行单元测试。

4.7 软件的测试

软件测试流程如下。

a)制定《测试方案》

根据《软件需求规格说明书》和软件的详细设计制定《测试方案》。

b)制定《测试用例》设计

是以发现错误为目的而精心设计的一组测试数据,测试用例={输入数据+期望结构}。测试用例将用于之后的测试。

c) 编写《测试报告》。

4.8软件的鉴定验收

4.8.1 软件的鉴定验收

在软件开发完成后,为了确保软件是按照需求分析的要求进行开发的,保证软件产品的质量,需要对软件产品进行鉴定验收。

4.8.2 验收具体内容

验收内容应该包括:文档检查、软件一致性检查、软件系统测试与测试结果评审等几项工作。文档检查检查工程师提交的文档必须齐全,质量是否过关。验收需要对软件代码进行检查,以确保其符合规范,并检查其一致性。

4.9软件升级

4.9.1 优化系统

软件优化、升级的变更流程需填写《软件变更申请表》,经评审、批准后方可执行。

4.9.2 报废处理

软件报废流程需填写《软件报废申请表》,提交副总经理审批后方可执行。

4.10软件维护

4.10.1 软件数据库管理

如果软件项目具有数据库,需要制定计划对数据库进行日常的维护。

4.10.2 故障分析解决

产品交付后出现软件问题的,由售后技术支持人员或者研发人员对出现问题的地方进行故障分析,记录故障,填写《软件故障记录表》,并对软件进行维护修改。

5 相关文件

5.1 《设计变更控制程序》

6 记录表单

6.1 《软件需求规格说明书》

6.2 《软件测试说明书》

6.3 《软件概要设计》

6.4 《UI规划书》

6.5 《软件详细设计说明书》

6.6 《数据库设计说明书》

6.7 《测试方案》

6.8 《测试用例》

6.9 《测试报告》

6.10 《软件变更表》

6.11 《软件报废申请表》

6.12 《软件故障记录表》

6.13 《软件评审表》

系统开发安全管理办法

系统开发安全管理办法

文档说明(一)变更信息 (二)文档审核人

目录 第一章目的 (4) 第二章适用范围 (4) 第三章术语、定义、缩略语 (4) 第四章组织与职责 (4) 第五章安全需求 (5) 第六章安全设计 (5) 第七章安全编码 (5) 第八章安全测试 (6) 第九章安全上线 (6) 第十章开发外包 (7) 第十一章附则 (7)

第一章目的 第一条为规范本单位的应用系统开发过程,提升交付系统的安全性,有效降低安全风险,特制定本管理办法。 第二条系统开发安全管理是指在系统开发阶段,建立若干安全的开发流程,对其进行有效管理,将符合安全需求的安全机制与措施在应用系统中实现,提高交付系统的安全性,减少后续安全更正和维护所产生的成本。 第二章适用范围 第三条本管理办法中应用系统开发安全管理涉及的过程包括:安全需求分析、安全设计、安全编码、安全测试、安全上线、以及应用系统开发外包的安全管理。 第四条本管理办法适用于应用系统开发类项目,以及与项目相关的项目管理人员、项目实施人员。 第三章术语、定义、缩略语 第五条安全需求是指为保障应用系统安全,满足应用系统合规性需求和敏感信息保护需求,而针对应用系统提出的一系列安全要求。 第四章组织与职责 第六条应用系统开发安全管理的统一归口管理部门是技术部,职责包括:

(一)总体负责应用系统开发类项目开发安全管理; (二)组织制定安全开发相关规章制度、流程、实施细则; (三)执行安全需求分析、安全设计、安全编码、安全测试、安全上线的实施工作; (四)参与开发人员安全技能培训。 第五章安全需求 第七条应用系统需求分析阶段必须进行安全需求分析。 第八条安全需求分析应该明确应用系统的业务安全需求,合规性需求以及敏感信息保护需求。 第九条安全需求确定后,应该进行安全需求评审,得到安全需求相关各方的认可。 第六章安全设计 第十条应用系统设计阶段必须进行安全设计。 第十一条安全设计应该明确系统安全逻辑架构,数据安全架构和部署环境安全架构。 第十二条安全设计应该满足系统的安全需求,能够直接指导系统安全功能的编码工作。 第十三条安全设计确定后,应该进行安全设计评审。 第七章安全编码 第十四条应用系统编码前,应该制定安全编码规范,明确代码编写的原则和要求,同时应对开发人员进行安全编码培训。

(国内标准)GB-软件开发主要文档编写规范

231 GB 8567-88软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件编制指南》GB 8567-88中主要软件文档的编写说明,供编写时参考。这些文档主要是:可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、可行性研究报告 l 引言 1.1 编写目的 说明:说明本可行性研究报告的编写目的,指出预期的读者。 1.2 背景 说明: a .所建议开发的软件系统的名称。 b .本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c .该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料,如: a .本项目的经核准的计划任务书或合同、上级机关的批文。 b .属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料,包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前提,如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求,如: a .功能。 b .性能。 c .输出如报告、文件或数据,对每项输出要说明其特征,如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据的来源、类型、数量、数据的组织以及提供的频度。 e .处理流程和数据流程。用图表的方式表示出最基本的数据流程和处理流程,并输之以叙述。 f. 在安全与保密方面的要求。 g. 同本系统相连接的其他系统。 h. 完成期限。 2.2 目标 说明所建议系统的主要开发目标,如: a. 人力与设备费用的减少。 b. 处理速度的提高。 c. 控制精度或生产能力的提高。

软件项目维护方案

软件项目维护方案 软件项目维护方案 1. 项目背景及目标 1.1. 项目背景在国家政策的指导和帮助下,信息化也越来越发挥出十分重要的作用。XXXX不断加大信息化管理工作力度,积极实施“上网工程”,大力推进全市局域网建设,加快办公自动化系统进程,信息技术在改革中发挥了重要的支撑作用,为充分发挥政府公共职能,促进依法理财、科学理财,提供了重要的信息技术保障。近年来建设各系统随着数据量的逐年增加,陆续出现了性能问题,有必要进行数据库系统的升级及性能优化,以确保应用系统的正常运行,为单位员工提供更好的信息服务。 1.2. 项目目标● 对各系统数据库进行补丁升级服务,安装补丁前制定详细的升级计划和应急回退计划。 ● 完成各系统数据库的性能调优工作。 ● 各业务持续性得到有效的保证。 2. 需求分析 XXXXXXX项目,我公司有多年的行业经验。具有对运维服务对象进行适时监测、指标分析、和及时修复的能力。 Oracle 产品日常运行维护项目主要从如下几个方面进行: (1). 每天对ORACLE数据库的运行状态,日志文件,备份情况,数据库的空间使用情况,系统资源的使用情况进行查看,发现并解决问题。 (2). 每周对数据库

对象的空间扩展情况,数据的增长情况进行监控,对数据库做健康查看,对数据库对象的状态做查看。 (3). 查看表空间碎片,提出下一步空间管理计划。对ORACLE数据库状态进行一次全面查看。(4)由于这些数据库系统承载着XXXX非常重要的业务系统数据,所以在日常维护中需要非常仔细,每周、每月、每季都需要有相应的巡检记录,需要详细记载以下一些内容: n 监控数据库对象的空间扩展情况 n 监控数据量的增长情况 n 系统健康查看,查看以下内容: n 数据库对象有效性查看n 查看是否有危害到安全策略的问题。 n 查看 alert、Sqlnet 等日志并归档报错日志 n 分析表和索引 n 查看对数据库会产生危害的增长速度 n 查看表空间碎片 n 数据库性能调整n 预测数据库将来的性能 n 调整和维护工作 n 后续空间 3. 整体运行维护服务方案 3.1. Lifekeeper维护 3.1.1. 验证 LifeKeeper 的安装查看已经安装的LifeKeeper软件包,可以使用命令: rpm –qa|grep stee 3.1.2. 启动 LifeKeeper a) 启动LifeKeeper 服务器进程如果当前您的系统没有运行 LifeKeeper 则在所有服务器上以root用户身份输入如下命令 # /opt/LifeKeeper/bin/lkstart b) 启动LifeKeeper GUI服务器进程同样以root用户运行命令# /opt/LifeKeeper/bin/lkGUIserver start 注意:以上命令只需运行一次,以后每次系统重新启动时,LifeKeeper会自动运行上述进程 3.1.3. 有关的LifeKeeper软件的其它管理任务 a) 停止 LifeKeeper 服务如

软件版本管理规范标准[详]

软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容,使软件项目版本管理流程化并规化,确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 2.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于: 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划

上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划: ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中,项目部的目录结构: |–projectA |–src (保存该项目的源程序) |–doc (保存项目相关文档) |–000.项目管理(保存项目过程管理相关文档) |–010.项目计划(保存项目计划相关文档) |–020.项目需求(保存项目需求相关文档) |–030.系统设计(保存项目设计相关文档) |–030.系统测试(保存项目代码测试相关文档) |–040.系统实施(保存项目部署实施相关文档) |–050.系统运维(保存项目运维文档,包括培训、用户手册等) |–060.技术资料(保存项目技术文档,包括第三方技术资料等)

软件开发管理制度

软件开发管理制度 版本:V1.0 2013年1月

第一节总则 第一条为规自有软件研发以及外包软件的管理工作,特制定本制度。本制度适用于公司总公司软件研发与管理,分公司参照执行。 第二条本制度中软件开发指新系统开发和现有系统重大改造。 第三条本制度中自行开发是指主要依赖公司自身的管理、业务和技术力量进行系统设计、软件开发、集成和相关的技术支持工作,一般仅向外购置有关的硬件 设备和支撑软件平台;合作开发是公司与专业IT公司(合作商)共同协作完 成IT应用的项目实施和技术支持工作,一般形式是公司负责提供业务框架, 合作商提供技术框架,双组成开发团队进行项目实施,IT系统的日常支持由 IT技术中心和合作商共同承担,IT技术中心负责部(一级)支持,合作商负 责外部(二级)支持;外包开发是指将IT应用项目的设计、开发、集成、培 训等任务承包给某家专业公司(可以是专业的IT公司或咨询公司等),由该 公司(承包商)负责应用项目的实施。 第四条软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、合作开发管理和结项管理。软件工程涉及需求管 理、系统设计、系统实现、系统测试、用户接受测试、试运行、系统验收、 系统上线和数据迁移。 第五条除特别指定,本制度中项目组包括业务组(或需求提出组)、IT组(可能包括网络管理员和合作开发商)。 第二节立项管理 第六条提出开发需求的信息技术部门参与公司层面立项,进行立项的技术可行性分析,编写《立项分析报告》(附件一),开展前期筹备工作。《立项分析报 告》应明确项目的围和边界。 第七条应用系统主要使用部门将《立项分析报告》上交公司总裁室进行立项审批,以保证系统项目与公司整体策略相一致。 第八条《立项分析报告》得到批准后,成立项目组(如果是外包开发,则成立外包商项目组;如果是合作开发,则与外包商共同成立合作开发项目组,以下统 称“项目组”),项目组应包括业务组(由公司相关业务部门组成)和IT组 (自行开发为办公室网络管理员;外包开发为外包商成员;合作开发为网络

软件开发文档规范

附2: 软件文档编写向导 文档分类 项目包括如下几类文档: 项目管理文档。包括:《软件项目计划》、《项目进度报告》、《项目开发总结报告》 软件开发文档。包括:《需求规格说明》、《概要设计说明》、《详细设计说明》、《测试计划》、《软件测试分析报告》。 产品文档。包括:《用户操作手册》《演示文件》。 软件项目计划 (Software Project Plan) 一?引言 1?编写目的(阐明编写软件计划的目的,指出读者对象。) 2?项目背景(可包括:(1 )项目委托单位、开发单位和主管部门;(2)该软件系统与 其他系统的关系。) 3?定义(列出本文档中用到的专门术语的定义和缩略词的原文。) 4?参考资料(可包括:文档所引用的资料、规范等;列出资料的作者、标题、编号、发 表日期、出版单位或资料来源。) 二?项目概述 1.工作内容(简要说明项目的各项主要工作,介绍所开发软件的功能性能等?若不编写可行性研究报告,则应在本节给出较详细的介绍。) 2.条件与限制(阐明为完成项目应具备的条件开发单位已具备的条件以及尚需创造的 条件?必要时还应说明用户及分合同承包者承担的工作完成期限及其它条件与限制。) 3.产品 (1)程序(列出应交付的程序名称使用的语言及存储形式。) (2)文档(列出应交付的文档。) (3 )运行环境(应包括硬件环境软件环境。) 4?服务(阐明开发单位可向用户提供的服务?如人员培训安装保修维护和其他运行支持。 5.验收标准

三.实施计划 1.任务分解(任务的划分及各项任务的负责人。) 2?进度(按阶段完成的项目,用图表说明开始时间完成时间。) 3?预算 4?关键问题(说明可能影响项目的关键问题,如设备条件技术难点或其他风险因素,并说明对策。) 四.人员组织及分工 五.交付期限 六.专题计划要点(如测试计划等。) 项目开发进度报告 一.报告时间及所处的开发阶段 二.给出进度 1.本周的主要活动 2.实际进展与计划比较 三.所用工时(按不同层次人员分别计时。) 四.所有机时 五.工作遇到的问题及采取的对策 六.本周完成的成果 七.下周的工作计划 八.特殊问题 项目开发总结报告 一.引言 1.编写目的(阐明编写总结报告的目的,指明读者对象。) 2.项目背景(说明项目的来源、委托单位、开发单位及主管部门。) 3.定义(列出报告中用到的专门术语定义和缩写词的原意。) 4.参考资料(列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括: (1 )项目开发计划;(2 )需求规格说明书;(3 )概要设计说明书;(4 )详细设计说明

软件维护及使用管理规定

软件维护及使用管理规 定 IMB standardization office【IMB 5AB- IMBK 08- IMB 2C】

日常办公软件及特殊软件维护及使用管理办法 1、目的:为有效使用及管理计算机软件资源,并确保公司计算机软件的合法使用,避免人员因使用非法软件,影响公司声誉或造成计算机病毒侵害,影响日常工作正常进行,特制定本办法。 2、适用范围:本办法适用于本公司软件使用的相关信息作业管理。 一、软件安装及使用 1.公司的各类计算机软件,应依据着作版权者为限,并统一由信息 技术部负责安装保管,信息管理软件及其它专用软件,需填制 《IT资源申请单》(见附表info-03)进行申请,获准后方可安 装。 2.严禁个人私自在公司计算机上安装未获授权、非授权公司使用或 超过使用授权数量的软件,未经授权或同意,使用者不得擅自在 计算机内安装任何软件或信息,经授权同意者始得于计算机内安 装合法授权的软件或信息。 3.各部门软件分配使用后,保管人或使用人职务变动或离职时,应 移交其保管或使用的软件,并办理交接。 4.禁止员工使用会干扰或破坏网络上其它使用者或节点的软件系 统,此种干扰与破坏如散布计算机病毒、尝试侵入未经授权的计 算机系统、或其它类似的情形者皆在禁止范围内。

5.网络上存取到的任何资源,若其拥有权属个人或非公司所有,除 非已经正式开放或已获授权使用,否则禁止滥用或复制使用这些 资源。 6.禁止员工使用非法软件,或私人拥有的计算机软件安装使用于公 司计算机上,也不得将公司合法软件私自拷贝、借于他人或私自 将软件带回家中,如因此触犯着作权,则该员工应负刑事及民事 全部责任,各部门应妥善保管正版软件,防止软件授权外泄或被 非法使用。 二、软件的相关维护升级管理 7.为使软件在计算机中发挥应有的效用,并避免非法软件流入公 司,信息技术部可定期或不定期稽查,如发现使用非法计算机软 件者,除提报于公司外,并追究相应责任。 8.软件管理人员应依据软件本身需求定期备份数据,对于软件数据 进行的更新操作必须存档相关数据文件和审批文件。 9.信息技术部对于购入的合法软件由专门人员分类保管。软件保管 人对软件负保管之责,软件使用者如有使用不当,造成损毁或遗 失,应负赔偿责任。 10.借用或归还软件,须直接联系软件管理人员,不可私自转借, 并不得委任借还。借用软件若有遗失或不正常使用导致损坏,无 法正常使用,借用人应负责赔偿。(正常使用的毁损不在此限, 但须交回原借用的光盘或磁盘)。

软件配置管理规范流程模板

软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

软件系统安全规范

一、引言 1.1目的 随着计算机应用的广泛普及,计算机安全已成为衡量计算机系统性能的一个重要指标。 计算机系统安全包含两部分内容,一是保证系统正常运行,避免各种非故意的错误与损坏;二是防止系统及数据被非法利用或破坏。两者虽有很大不同,但又相互联系,无论从管理上还是从技术上都难以截然分开,因此,计算机系统安全是一个综合性的系统工程。 本规范对涉及计算机系统安、全的各主要环节做了具体的说明,以便计算机系统的设计、安装、运行及监察部门有一个衡量系统安全的依据。 1.2范围 本规范是一份指导性文件,适用于国家各部门的计算机系统。 在弓I用本规范时,要根据各单位的实际情况,选择适当的范围,不强求全面采用。 二、安全组织与管理 2.1安全机构 2.1.1单位最高领导必须主管计算机安全工作。 2.1.2建立安全组织: 2.1.2.1安全组织由单位主要领导人领导,不能隶属于计算机运行或应用部门。 2.1.2.2安全组织由管理、系统分析、软件、硬件、保卫、审计、人事、通信等有关方面人员组成。 2.1.2.3安全负责人负责安全组织的具体工作。 2.1.2.4安全组织的任务是根据本单位的实际情况定期做风险分析,提出相应的对策并监督实施。 2.1.3安全负责人制: 2.1.3.I确定安全负责人对本单位的计算机安全负全部责任。 2.1.3.2只有安全负责人或其指定的专人才有权存取和修改系统授权表及系统特权口令。 2.1.3.3安全负责人要审阅每天的违章报告,控制台操作记录、系统日志、系统报警记录、系统活动统计、警卫报告、加班报表及其他与安全有关的材料。2.1.3.4安全负责人负责制定安全培训计划。 2.1.3.5若终端分布在不同地点,则各地都应有地区安全负责人,可设专职,也可以兼任,并接受中心安全负责人的领导。 2.1.3.6各部门发现违章行为,应向中心安全负责人报告,系统中发现违章行为要通知各地有关安全负责人。 2.1.4计算机系统的建设应与计算机安全工作同步进行。 2.2人事管理 2.2.1人员审查:必须根据计算机系统所定的密级确定审查标准。如:处理机要信息的系统,接触系统的所有工作人员必须按机要人员的标准进行审查。

软件开发过程管理规范

软件开发过程管理规范文件管理序列号:[K8UY-K9IO69-O6M243-OL889-F88688]

0 引言 如果要提高软件开发人员的开发质量,必须有相应的考核制度,有了制度后才能推动开发人员想方设法改善自已的开发质量。目前研发对软件开发的过程缺乏细粒度的度量,所以不能依据有效的度量数据来考核开发人员的工作绩效,大部份只是凭考核人主观意志来考核,不能形成对被考核人有效的说服力。此绩效考核办法旨在结合实际情况合理客观地评价开发效率和质量。 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价,用评价的结果指导软件的开发过程,不断地提高软件开发质量水平,并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1)技术文档:主要包括:可行性分析报告、需求分析报告、软件功能规格说明、开发计划、系统设计报告、测试文档、用户手册、总结报告等; 2)计算机程序。 3 度量数据的来源 1)项目计划; 2)评审报告; 3)测试报告; 4)问题报告; 5)软件维护记录; 4 质量度量

4.1 度量指标 主要根据各类软件项检查表的检查指标来确定,例如,软件需求规格说明书检查表(见附录1),有10个检查指标,则根据具体项目检查侧重点不同,可从中选择相应的检查指标作为度量指标。 4.2 质量等级 1)软件项的质量等级的确定根据度量综合指标进行。 2)度量综合指标计算公式为:Total = ∑QiMi。 3)其中i=1,2,...n代表指标数量; 4)Q代表度量的指标; 5)M代表度量的指标Q在整个指标体系中所占的权重系数,对不同的开发项目可能不同,此系数根据开发的不同着重点给出。 度量指标权重系数表: 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 1.0 6)质量评价:一般地,根据度量综合指标值,有以下评分标准。 质量评价计分标准表 序号得分质量评价

软件三库管理规范

软件三库管理规范-标准化文件发布号:(9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

1目的范围 规定了公司软件开发库、受控库、产品库(以下简称三库)的管理规范。 2参考文献 《软件三库管理制度》 3术语和定义 GitLab:一个仓库管理系统,使用Git作为代码管理工具,并在此基础上搭建起来的web服务。 Jenkins:基于Java开发的一种持续集成平台,用于监控持续重复的工作。 SPM:公司研发部开发的持续集成工具,用于集成软件部署包。 Releaser:公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS:公司研发部基于开源代码改进的测试用例管理系统,用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4职责 4.1软件三库管理职责 软件开发库由项目组管理,软件受控库由研发部管理,软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识; b)熟悉研制项目的配置管理; c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立,按照软件项目分配仓库。 项目组长任仓库Master,负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer,负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter,负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立,按照软件项目分配仓库。

信息管理与信息安全管理程序.docx

. . 1目的 明确公司信息化及信息资源管理要求,对内外部信息及信息系统进行有效管理,以确保各部门( 单位 ) 和岗位能及时、安全地识别、获取并有效运用、保存所需信息。 2适用范围 适用于公司信息化管理及信息收集、整理、转换、传输、利用与发布管理。 3术语和定义 3.1信息 有意义的数据、消息。公司的信息包括管理体系所涉及的质量、环境、职业健康安全、测量、标准 化、内部控制、三基等和生产经营管理中所有信息。 3.2企业信息化 建立先进的管理理念,应用先进的计算机网络技术,整合、提升企业现有的生产、经营、设计、制 造、管理方式,及时为企业各级人员的决策提供准确而有效的数据信息,以便对需求做出迅速的反应, 其本质是加强企业的“核心竞争力” 。 3.3信息披露 指公司以报告、报道、网络等形式,向总部、地方政府报告或向社会公众公开披露生产经营管理相 关信息的过程。 3.4 ERP 企业资源规划 3.5 MES 制造执行系统 3.6LIMS 实验室信息管理系统 3.7IT 信息技术 4职责 4.1信息化工作领导小组负责对公司信息化管理工作进行指导和监督、检查,对重大问题进行决策, 定期听取有关信息化管理的工作汇报,协调解决信息化过程中存在的有关问题。 4.2 ERP支持中心负责公司ERP系统运行、维护管理,每月召开ERP例会,分析总结系统运行情况, 协调处理有关问题,及时向总部支持中心上报月报、年报。 4.3信息中心是公司信息化工作的归口管理部门,主要职责: a) 负责制定并组织实施本程序及配套规章制度,对各部门( 单位 ) 信息化工作进行业务指导和督促; b)负责信息化建设管理,组织进行信息技术项目前期管理,编制信息建设专业发展规划并组织实施; c) 负责统一规划、组织、整合和管理公司信息资源系统,为各部门( 单位 ) 信息采集、整理、汇总和 发布等环节提供技术支持;对Internet用户、电子邮箱进行设置管理;统一管理分公司互联网出口; d) 负责计算机网络系统、信息门户和各类信息应用系统的安全运行和维护及计算机基础设施、计算

软件研发管理制度

武汉新英赛研发管理 第一节 软件研发岗位职责 一、软件研发部经理岗位职责 软件研发部经理在总经理或主管副总的领导下, 全面负责软件研发部的日常管理, 组织 开展软件研发与测试工作,完成企业研发目标和经营目标。其具体职责如表 二、高级研发工程师岗位职责 高级研发工程师参与建立研发工作标准与规范,协助部门经理组织完成软件研发工作, 管理软件研发项目,改良升级进行软件。其具体职责如表 8-1所示。 8-2所示。

表8-2 高级研发工程师岗位职责 三、软件研发工程师岗位职责 软件研发工程师协助高级工程师进行软件的设计与开发,收集整理相关行业信息与资料,为软件产品决策提供依据。其具体职责如表8-3所示。

四、软件测试工程师岗位职责 软件测试工程师主要负责软件测试工作, 根据软件产品规格和测试需求,编写测试方案、测试用例、测试脚本软件等。其具体职责如表8-4所示。 第二节软件研发管理制度 六、软件研发费用管理制度 第1章总则 第1条目的。 为了加强软件研发费用管理,规范资金的使用,减少公司不必要的损失,根据公司的实

际情况,特制定本制度。 第2 条研发费用管理原则。 1.计划统筹安排原则。 2.节约使用、讲求经济效益原则。 第3 条职责分工。 1.公司财务部负责研发费用的审批和报销,并随时监督费用的使用情况。 2.软件研发部负责研发费用的预算与使用控制。 第2 章研发费用的来源及使用范围 第4 条研发费用的来源。 1.公司对重点研发产品的专项拨款。 2.公司成本列支的研发费用。 3.从其他方面筹措来用于研发的费用。 第5 条研发费用的使用范围。 1.研发活动直接消耗的材料、燃料和动力费用。 2.研发人员的工资、奖金、社会保险费、住房公积金等人工费用以及外聘研发人员的劳务费用。 3.用于研发活动的仪器、设备、房屋等固定资产的折旧费或租赁费以及相关固定资产的运行维护、维修等费用。 4.用于研发活动的软件、专利权、非专利技术等无形资产的摊销费用。 5.用于中间试验和产品试制的模具、工艺装备开发及制造费,设备调整及检验费,样品、样机及一般测试手段的购置费,试制产品的检验费等。 用。用。6.研发成果的论证、评审、验收、评估以及知识产权的申请费、注册费、代理费等费7.通过外包、合作研发等方式,委托其他单位、个人或与之合作进行研发而支付的费8.与研发活动直接相关的其他费用,包括技术图书资料费、资料翻译费、会议费、差 旅费、办公费、外事费、研发人员培训费、专家咨询费、高新科技研发保险费用等。 第3章研发费用的使用管理 第6 条专款专用。

软件开发与维护管理规范

软件开发与维护管理规范 1 目的通过规范软件的开发与维护过程,达到提高软件质量,降低维护成本的目的。 2 范围适用于新产品的软件开发设计以及定型产品的改进升级。 3 职责与权限 研发中心负责: a)编制软件开发过程的实施、协调和控制工作; b)编制各阶段的技术文件; c)组织软件的测试、验收、升级和维护工作。 各部门参与软件开发过程中有关的设计评审。 4 内容 软件项目的开发实施过程管理要求 软件项目实施过程总体要求 本部分主要要求工程师制定软件开发工作计划,对过程进行控制,一般包括以下的内容。a) 工程师提交软件开发工作大纲,项目组织者对工作大纲进行评审,并提出整改意见。 b)通过评审后,工程师根据整改意见完善工作大纲,经过项目经理认可后组织项目组进行 软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行,在开发过程中,工程师需分阶段提交相关文档。 c)在软件开发工作完成后,工程师应向项目组提交完整的软件文档,相关人员组织验收组对软件进行验收审查。 软件项目实施变更要求在开发过程中,需求或设计不可避免地需要发生变更,相关变更必须提交《软件变更申请》经过项目组书面同意方可进行。在需求或设计发生变更时,需要对原有文档进行修改,并提供完整的变更记录,以使变更处于可控制的状态。 软件项目实施里程碑控制本部分主要对软件开发过程中的重要节点进行控制。项目组将分四个阶段进行把关,召开审查会。 a)需求分析(结合原型进行审查)确认;

b)概要设计+数据库设计; c)预验收(样机测试时); d)正式验收(产品定型后)。 软件开发 软件开发必须严格按照软件工程的要求进行。开发过程包括工程师的活动和任务。此过程由软件需求分析、概要设计、详细设计、编码、测试、验收、鉴定等活动组成。 软件的需求分析 需求分析 需求分析要求开发人员准确理解用户的需求,进行细致的调查分析,将用户非形式的需求陈述转化为完整的需求定义,再由需求定义转化到相应的形式功能规约《软件需求规格说明书》的过程。 在《软件需求规格说明书》必须描述的基本问题是:功能、性能、强加于实现的设计限制、属性、外部接口。 需求报告评审在软件需求分析工作完成后,软件工程师应向项目组提交《软件需求规格说明书》。项目组组织有关人员(系统客户和系统开发人员等)对需求进行评审,以决定软件需求是否完善和恰当。项目组严格验证这些需求的正确性,一般从一致性,完整性,现实性,有效性四个方面进行验证。评审完成后,就可以进入软件的设计阶段。 软件的概要设计 概要设计 概要设计也称为系统设计,需要确定软件的总体结构,应该由哪些模块组成,以及模块与模块之间的接口关系,软件系统主要的数据结构和出错处理设计等,同时还要制定测试方案,形成概要设计说明书,为软件的详细设计提供基础。在概要设计时一般从以下几方面来考虑,遵循以下的流程。 概要设计和需求分析、详细设计之间的关系和区别需求分析不涉及具体的技术实现,而概要设计注重于从宏观上和框架上来描述采用何种技术手段、方法来实现这些需求。详细设计相对概要设计更注重于微观上和框架内的设计,是编码的依据。概要设计是指导详细设计的依据。 概要设计的评审 在软件概要设计工作完成后,软件工程师应向项目组提交《软件概要设计》。评审通过后,即可进入详细设

版本管理制度

版本管理规范(草案) 研发部 2009-2-4

目录 文档类别使用对象....................................................... 错误!未定义书签。1.引言................................................................ 错误!未定义书签。 目的 .................................................................. 错误!未定义书签。 范围 .................................................................. 错误!未定义书签。 术语定义 .............................................................. 错误!未定义书签。 版序控制记录 .......................................................... 错误!未定义书签。 版本更新记录 .......................................................... 错误!未定义书签。2.版本管理............................................................ 错误!未定义书签。 2.1版本标识方法...................................................... 错误!未定义书签。 2.1.1正式版本..................................................... 错误!未定义书签。 2.2目录结构.......................................................... 错误!未定义书签。 2.3文档的存放........................................................ 错误!未定义书签。 当前版本和历史版本的存放 ........................................... 错误!未定义书签。 开发文档的存放 ..................................................... 错误!未定义书签。 源代码的存放 ....................................................... 错误!未定义书签。 SQL语句的存放...................................................... 错误!未定义书签。 发行文档的存放 ...................................................... 错误!未定义书签。 2.4权限控制管理...................................................... 错误!未定义书签。3.更新管理(版本升级) ................................................ 错误!未定义书签。 版本升级原则 ........................................................ 错误!未定义书签。 新版本的发布 ....................................................... 错误!未定义书签。4.备份管理............................................................ 错误!未定义书签。5.用户版本管理........................................................ 错误!未定义书签。6.研发部统一管理阶段性版本............................................. 错误!未定义书签。 阶段性版本的提交到研发部............................................... 错误!未定义书签。 阶段性版本的发布到公司网站上........................................... 错误!未定义书签。 各项目组新版本内部及时备份。........................................... 错误!未定义书签。7.版本工具的使用...................................................... 错误!未定义书签。 研发部采用SVN配置管理工具............................................. 错误!未定义书签。8.各项目组提交文档及源码以及规则....................................... 错误!未定义书签。 各项目组需要提交的文档................................................ 错误!未定义书签。 目前所管理的产品列表................................................... 错误!未定义书签。9.周报管理制度........................................................ 错误!未定义书签。10.风险管理制度....................................................... 错误!未定义书签。

安全合规-软件安全开发过程规范

安全开发过程规范 一、SDL简介 SDL security development lifecycle(安全开发生命周期),是微软提出的从安全角度指导软件开发过程的管理模式。SDL是一个安全保证的过程,起重点是软件开发,它在开发的所有阶段都引入了安全和隐私的原则。自2004年起,SDL一直都是微软在全公司实施的强制性策略。 二、SDL步骤图 SDL中的方法,试图从安全漏洞产生的根源上解决问题,通过对软件工程的控制,保证产品的安全性。 美国国家标准与技术研究所(NIST)估计,如果是在项目发布后在执行漏洞修复计划,其修复成本相当于在设计阶段执行修复的30倍 三、SDL的步骤包括: 阶段1:培训 开发团队的所有成员都必须接受适当的安全培训,了解相关的安全知识,培训对象包括开发人员、测试人员、项目经理、产品经理等。 阶段2:安全要求 在项目确立之前,需要提前与项目经理或者产品owner进行沟通,确定安全的要求和需要做的事情。确认项目计划和里程碑,尽量避免因为安全问题而导致项目延期发布。 阶段3:质量门/bug栏 质量门和bug栏用于确定安全和隐私质量的最低可接受级别。 Bug栏是应用于整个开发项目的质量门,用于定义安全漏洞的严重性阈值。例如,应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。Bug栏一经设定,便绝不能放松。 阶段4:安全和隐私风险评估 安全风险评估(SRA)和隐私风险评估(PRA)是一个必需的过程,必须包括以下信息: 1、(安全)项目的哪些部分在发布前需要威胁模型? 2、(安全)项目的哪些部分在发布前需要进行安全设计评析? 3、(安全)项目的哪些部分需要并不食欲项目团队且双方认可的小组进行渗透测试? 4、(安全)是否存在安全顾问认为有必要增加的测试或分析要求已缓解安全风险? 5、(安全)模糊测试要求的具体范围是什么? 6、(安全)隐私影响评级如何? 阶段5:设计要求 在设计阶段应仔细考虑安全和隐私问题,在项目初期确定好安全需求,尽可能避免安全引起的需求变更。 阶段6:减小攻击面 减小攻击面与威胁建模紧密相关,不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险,减小攻击面包括:关闭或限制对系统服务的访问,应用“最小权限原则”,以及尽可能进行分层防御。 阶段7:威胁建模 为项目或产品面临的威胁建立模型,明确可能来自的攻击有哪些方面。

软件版本管理规范19726

软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 2.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于: 项目总体计划 可行性研究报告 开发计划 需求说明书

需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。

配置库目录结构规划: ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中,项目内部的目录结构: |–projectA

相关文档
最新文档