软件开发管理制度.docx

软件开发管理制度.docx

《软件开发管理制度.docx》由会员分享，可在线阅读，更多相关《软件开发管理制度.docx（10页珍藏版）》请在冰点文库上搜索。

软件开发管理制度

软件开发管理制度

第一条为了规范应用软件系统开发过程，明确定义应用软件系统开发过程必须遵守的安全管理规定，保障信息系统符合规定的安全要求，防止系统中重要数据丢失、修改或滥用，确保信息系统安全、持续地运行，特制定本办法。

第二条本办法适用于XXXXXXX局应用系统开发过程，可能包括内部开发或者委托外部单位开发。

第三条应用系统开发总体原则：

1）应用系统开发应当从业务需求的角度出发，不能盲目追求系统先进性而忽略了系统的实用性。

2）开发的方法和管理必须规范化、合理化、制度化。

只有采用了规范化合理化、制度化的开发管理方法，才能确保开发的质量和进度。

3）确保系统开发环境与生产环境相隔离，内部测试由开发人员自行搭建环境，模拟测试必须到专用的测试环境进行测试。

4）确保开发进度和开发质量。

5）应用系统开发必须具有一定的前瞻性，符合主流系统的发展方向。

6）开发人员应提高和加强安全意识，确保机密信息和关键技术不会泄漏。

7）充分利用现有的资源。

第四条应用系统开发人员职责分配管理规范：

1）在应用系统开发的过程中，应当明确不同人员的身份、扎口、职责。

建议在应用系统开发过程中具体分以下的三种角色：

a）项目负责人员：

确保在整个系统开发的各个阶段都实施了相关的安全措施，同时在整个系统开发的过程中负责整个项目的开发安全管理。

b）系统开发人员：

根据业务需求确保开发的系统能够满足业务上的需求和相应的安全上的需求，同时满足系统质量上和进度上的要求。

c）系统审计人员：

应由局信息中心相关人员承担。

并对整个开发的过程进行审核和监督，确保开发的质量和开发的安全。

第五条开发人员授权管理规范：

1）开发人员授权由局信息中心领导进行授予。

2）根据该人员在整个开发项目中所负责的开发内容授予其相应的权限和承担的责任。

3）开发人员必须负责其开发内容的保密性，不得私自将开发的相关信息泄漏出去。

4）根据人员权限和责任的大小确认是否需要签署相关的保密协议。

5）在日常工作中记录人员的开发相关的日志信息。

6）人员一旦离职或调动岗位应立即收回或调整其相应的权限。

第六条应用系统开发变更管理：

1）开发人员必须确认所有的需要更改的应用系统、信息、数据库和相关的硬件设备。

2）确认更改的原因（业务上的具体流程和具体的需求或开发上的需求）。

3）在正式的实施之前，更改的方案必须经过评审并通过正式的批准

4）确保授权的用户在实施之前确认并接受更改的内容。

5）确保在实施的过程中，尽量减少对现行系统的影响。

6）确保建立的文件系统在完成各项更改时得到修改，旧文件被很好的归档或处置。

7）保证所有系统升级的版本的控制。

8）确保用户使用手册作相应的必要的更改。

9）确保更改的实施选择了适当的时机以确保更改的实施不会干扰正常的系统运行。

第七条技术可行性分析：

1）根据业务上提出的需求，从技术开发的角度分析现有的技术手段和技术能力是否可以达到业务上要求的系统功能，通常可以从三个方面进行分析：

a）技术能力分析：

指我局内的系统开发队伍是否有足够的软件开发的技术能力来完成系统开发的任务，或第三方外包的开发单位是否具有开发应用系统的技术能力。

b）计算机软件和硬件分析：

指我局现有的软件和硬件的性能或配置是否足够满足系统开发的要求。

c）管理能力分析：

指现有的技术开发管理制度和管理流程是否成熟且标准化，是否足够系统运行的要求。

2）需求可行性分析：

系统的开发来源于业务上的需求，因此需要对该需求进行可行性分析，以判断需求是否明确，是否符合实际，是否在一定的时间范围内可实现的。

3）投资可行性分析：

根据业务需求和技术手段的分析，确认根据业务需求和技术手段需要多少的投资才可以实现，确认投资的数额是不是在可控制和可承受的范围内。

4）影响可行性分析：

新系统开发和投入运营会不会造成社会影响，以及造成的社会影响有多少等；新系统开发和投入运营是否会对现有的系统造成不良影响。

第八条在可行性分析阶段，同样必须从身份认证、系统权限、数据加密和系统审计等几个方面进行系统安全需求分析，并且提交相关安全需求分析报告，报告应该包括以下内容：

1）安全需求计划应该能够达到期望的安全水平。

其中包括了成本的预估，完成各个安全相关流程所需的时间。

2）所有的有关应用系统的更新或改进都必须是基于业务需求的，并且是有业务事件支持的。

这里的业务需求不仅仅包括了系统的功能、性能、开发费用、开发周期等内容，还要明确系统的安全要求。

3）安全开发需求分析计划应该由开发项目负责人和我局内部安全管理员共同商议决定。

4）系统的更新或改进都必须进行详细的需求定义、需求分析以及测试评估以保证不会对业务造成任何的影响。

5）业务需求是系统更新和改动的基础，因此必须清晰明确的定义业务的需求，绝对不允许在业务需求未经过业务部门领导和主要负责人员的认可的情况下进行开发。

第九条在技术可行性分析阶段，同样建议考虑系统的容量规划，容量规划是指确定系统的总体规模，性能和系统弹性。

容量规划的具体内容可能有所不同，应考虑以下方面：

1）系统的预期存储容量和在给定的周期里面获取生成和存储的数据量。

2）在线进程的数量和估计可能的占用资源。

3）对于系统和网络的响应时间和性能的要求。

4）系统弹性要求和设计使用率、峰值、槽值和平均值等

5）安全措施例如加密解密数据对系统的影响。

6）24x7运作要求和可接受的系统宕机次数。

第十条通用代码安全规范：

1）输入验证：

a）在客户机/服务器环境下，应进行服务端的验证而不是客户端的验证（例如基于JavaScript的验证）。

b）在实际的校验中，输入校验应首先定义一个有效（可接受）的字符集，然后检查每个数据的字符是否在有效范围内。

如果输入中包含无效的字符，应用程序应该返回错误页面并说明输入中包含无效字符。

c）边界检查（例如字符串的最大长度）应该在字符有效性检查以前进行。

d）从环境变量获得的数据也需要进行验证。

同时避免在环境变量中存放敏感数据（例如密码）。

2）SQL语句安全：

如果应用程序需要连接后端数据库，必须使用存储过程不得在代码中使用SQL语句。

3）注释代码安全：

当应用程序在实际环境中开始应用时，应该删除所有的注释代码。

4）错误消息安全：

所有为用户显示的错误信息都不应该暴露任何关于系统、网络或应用程序的敏感信息。

如果可能的话，最好使用包含编号的一般的错误信息，这种信息只有开发人员或支持人员才能理解。

一般的错误信息的例子是“发生了错误（代码1234），请您与系统维护部门联系。

”

5）URL内容安全：

对于web应用，不要在URL上暴露任何重要信息。

6）路径变量安全：

设置PATH为一个已知的值，而不是仅仅使用启动时的缺省值。

第十一条开发人员技术要求：

1）开发人员应该有能力防止开发过程中的缓冲器溢出错误。

2）在整个开发的过程中必须完整地、持续地进行代码错误处理所规定的流程。

3）错误问题报告应该越通俗越好，不应该在其中包含任何系统细节问题。

4）应该对重要的敏感信息进行加密保护。

5）应该使用一些相对复杂的加密和密钥生成机制。

6）应该单独编写安全性设计说明概要。

第十二条程序库管理规范：

1）程序库的修改、更新由开发人员提出申请，由我局信息系统项目管理人员进行审批，并由开发人员进行汇总登记（附件一、信息系统开发程序库变更记录表）。

2）管理开发工具：

a）严格管理在开发设备上存放开发工具的目录；

b）只有指定的人员经过适当的管理授权后才可以访问开发工具服务器；

3）访问控制：

a）严格开发环境的安全管理，防止XX的人进入开发环境。

b）严格管理开发用途的计算机，只有指定的人员才可以访问开发用的计算机设备。

c）严格开发系统的认证管理，建立严格的基于人员职责的授权等级制度，用口令或其他身份识别技术确认访问者身份。

4）源代码管理：

a）必须严格管理在开发系统中存放源代码的目录。

b）只有指定的人员如程序库管理员经过适当的管理授权后才可以访问源代码库，对源代码库的访问必须结合进行严格的访问控制技术手段。

c）各项应用应当指定相应的管理员。

d）非开发人员严禁自由地访问源代码库。

e）源代码库和开发工具服务器应尽量分开存放并且分开管理。

f）源代码库和运行的应用系统应尽量分开存放且分开管理。

g）源代码库的更新和向开发人员发布的源代码应当由指定的管理员根据一定的授权进行，不得私自自行更新或发放。

h）应当保存所有对源代码库进行访问读取或修改的日志记录，以便于日后审计。

第十三条开发版本管理规范：

1）版本程序管理：

a）对于程序清单必须进行严格的控制并且及时地进行更新。

b）对应用系统开发源代码的打印的资料、电子版本或者是相关的报告都必须进行控制，纸质的文件应当保存在一个安全的环境下，如保险柜等。

电子文档则应有一定的加密措施。

2）版本升级管理：

a）当软件的版本由于更新，修改等操作需要升级时必须先向局信息中心相关负责人员提交申请。

b）应用系统软件版本升级测试，对升级的应用系统进行测试，确认系统的各种安全特性。

c）需确认当前的版本为最新的版本，旧的版本需进行归档，不得随意丢弃或删除。

d）制定相关的升级计划，确保将系统升级对业务的影响降至最低。

3）版本控制管理：

a）开发人员必须对版本变更进行管理，符合相关变更管理规定。

b）防止不同版本的覆盖的情况。

c）版本变更时需要在更新的版本中记录变更的详细描述。

d）版本的更改只允许指定的人员进行操作。

e）开发人员记录所有的版本变更的日志并由开发管理人员进行审核，记录包括了更改日期，更改前版本号，更改后版本号，更改人等信息（附件二、信息系统开发版本变更记录表）。

第十四条开发检查管理规范：

1）系统开发中的相关日志文件应根据开发周期定期审核。

2）开发人员权限应定期检查。

3）应有防御后门代码或隐藏通道的控制措施，如对源代码进行检查，安装相关检查工具等。

第十五条按照第三方管理规定对开发外包安全进行管理。

第十六条应用系统的安全性测试规范：

1）必须有详细的测试计划，包括测试范围，测试方法和测试工具。

2）在测试的过程中详细的描述每个和测试方案相关的测试步骤和测试数据，将所有的测试数据进行整理归档，对出错的记录进行分析，确认问题产生的原因并编写问题报告。

3）应用系统上线前必须经过安全性测试。

第十七条测试数据通用要求：

1）任何测试数据必须妥善保管和处理，不得随意丢弃和泄露。

2）为了防止数据泄漏和敏感系统的滥用，一般情况下要求使用虚构数据进行测试。

3）当处于测试目的而使用真实的敏感的数据时，可以采用以下措施保护测试数据的安全：

a）对测试的系统进行严格的访问控制。

只允许小部分的测试人员进行测试。

且对于测试的人员按需要签订保密协议。

b）将真实的运行信息复制到测试系统时应有单独授权过程。

c）测试完成后，应当立即将相关数据从测试的应用系统中删除。

d）记录下测试数据的复制、使用和删除的情况，以便于审查追踪。

第十八条可以根据ISO9000认证体系，软件开发能力成熟度模型（CMM）标准确认系统是否已经达到一定的质量要求。

第十九条新系统的培训要求：

1）对所有的用户和技术人员提供关于新系统功能和操作方面的培训。

必须保证所有的技术和业务用户接受关于新系统或者系统改进的培训；

2）培训同样应包括安全性方面的培训。

第二十条撰写新系统和系统改进的文档：

1）所有新系统和系统改进都必须有充分的、最新的文档支持。

2）必须保证新系统和系统改进有详实的文档。

第二十一条项目组应设文档管理员（兼），负责保管、整理项目实施各阶段形成的文档，由文档管理员对所有开发文档使用进行记录（附件三、信息系统开发文档使用记录表）。

第二十二条项目组应将整理后的文档交由局信息中心存档。

第二十三条安全性测试：

1）应制定研发、运行与验收等过程中的安全测试与验收大纲，在项目实施完成后，由局信息中心及开发人员共同组织测试小组进行测试。

在测试大纲中应至少包括以下安全性测试和评估要求：

a）配置管理：

建议使用配置管理系统，并提供配置管理文档；

b）交付程序：

应将系统及其交付给用户的程序文档化；

c）安全功能测试：

对系统的安全功能进行测试，以保证其符合详细设计并对详细设计进行检查，保证其符合概要设计以及总体安全方案；

d）系统管理员指南：

应提供如何安全地管理系统和如何高效地利用系统安全功能的优点、保护功能等详细信息；

e）系统用户指南：

必须包含两方面的内容：

一是，它必须解释些用户可见的安全功能的用途以及如何使用它们，这样用户可以持续有效地保护他们的信息；二是，它必须解释在维护系统的安全时用户所能起的作用；

f）安全功能强度评估：

功能强度分析应说明以概率或排列机制（如，口令字或哈希函数）实现的系统安全功能。

g）脆弱性分析：

应对新系统进行脆弱性测试，包括工具或人工测试。

2）测试完成后，测试小组应提交测试报告，其中应包括安全性测试和评估的结果。

第二十四条安全试运行：

1）试运行阶段应有安全措施来维护系统安全，包括但不限于：

a）监测系统的安全性能，包括事故报告；

b）进行用户安全培训，并对培训进行总结；

c）监测新发现的对系统安全的攻击、系统所受威胁的变化以及其它与安全风险有关的因素；

d）监测系统的备份支持，支持与系统安全有关的维护培训；

e）评估系统改动对安全造成的影响；

f）监测系统物理和功能配置。

2）在试运行情况报告中应对上述工作做总结性描述。

第二十五条系统验收：

系统试运行过程结束后，可以组织由局信息中心与开发单位相关人员参加对项目进行的验收，验收应包括以下安全内容：

1）项目是否已达到项目任务书中制定的总体安全目标和安全指标，实现全部安全功能；

2）采用技术是否符合国家、行业有关安全技术标准及规范；

3）是否实现验收测评的安全性测试；

4）项目实施过程中的各种文档资料是否规范、齐全；

5）应由安全管理员对验收在安全性方面进行评价。

第二十六条系统上线后还应进行一段时间的监控和跟踪，系统的管理员负责监控和跟踪工作，具体应包括以下要求：

1）应对系统关键安全性能的变化情况进行监控，了解其变化的原因；

2）对系统安全事故的发生、应急、处理、恢复、总结进行全程跟踪，并有详细的记录；

3）对新发现的对系统安全的攻击进行监控，记录其发生的频率以及对系统的影响；

4）监控系统所受威胁的变化，评估其发生的可能性以及可能造成的影响；

5）监控并跟踪系统相关的备份情况；

6）监控运行程序的变化，并记录这些变化对系统安全的影响；

7）监控系统物理环境的变化情况，并记录这些变化对系统安全的影响；

8）监控安全配置的变化情况，并记录这些变化对系统安全的影响；

第二十七条为了保证本办法的时效性、可用性，必须根据相关审核规定进行评审和修订，修订后重新发布。

第二十八条本办法由局信息中心负责制定、解释和修改。

自发布之日起执行。

附件1：

信息系统开发程序库变更记录表

序号

变更内容

变更时间

修改人

批准人

附件2：

信息系统开发版本变更记录表

序号

变更时间

变更前版本号

变更后版本号

变更人

批准人

附件3：

信息系统开发文档使用记录表

序号

使用人员

所属部门

用途描述

备注