信息系统获取、开发及维护程序
电算化常考的信息系统开发流程
电算化常考的信息系统开发流程信息系统开发是指利用计算机技术、软硬件设备和网络资源将人员、设备、方法等各种资源有机地结合起来，依据特定的规范和要求，开发和构建符合用户需求的信息处理系统。
在电算化领域中，信息系统开发流程是一种管理方法，它以一系列步骤和活动的形式，指导和推进信息系统的开发工作。
本文将重点介绍电算化常考的信息系统开发流程。
1. 需求分析阶段需求分析阶段是信息系统开发的起点，也是最为重要的阶段之一。
在这个阶段中，开发团队与用户充分沟通，获取用户需求，明确系统的功能、性能和约束条件。
需求分析的目标是确保开发出的信息系统能够满足用户的实际需求。
- 用户需求调研：通过对用户进行访谈、问卷调查等方式，了解用户的真实需求，包括功能需求、业务需求、技术需求等。
- 需求规格说明：将用户需求转化为详细、清晰、可验证的需求规格说明书，包括用例模型、数据流程图、活动图等。
- 需求确认与评审：与用户进行多次确认和评审，确保需求规格说明书的准确性和完整性。
2. 概要设计阶段概要设计阶段是在需求分析阶段的基础上，进行系统整体架构设计的过程。
在这个阶段，开发团队将用户需求转化为系统的高层设计方案，包括系统的模块划分、数据结构设计、接口设计等。
- 系统结构设计：确定系统的整体结构，包括客户端、服务器、数据库等组成部分，以及它们之间的关系和交互方式。
- 模块划分与功能设计：将系统功能划分为若干个模块，每个模块具有独立的功能和职责，并进行详细的功能设计。
- 数据库设计：设计系统所需的数据库模型，包括表结构、关系、索引等。
3. 详细设计阶段详细设计阶段是在概要设计阶段基础上，对系统的各个模块进行详细设计的过程。
在这个阶段，开发团队将概要设计中的概念转化为具体的实现方案。
- 接口设计：定义系统模块之间的接口规范，确保各模块能够协同工作。
- 算法设计：设计系统中涉及的算法和计算模型，确保系统能够高效地处理各种业务逻辑。
- 界面设计：设计系统的用户界面，使其直观、易用、良好的用户体验。
信息系统开发过程
信息系统开发过程信息系统开发是指根据特定的需求和目标，采取一系列的工程方法和技术手段，设计、实现和维护信息系统的过程。
在信息化时代，信息系统对于企业的发展至关重要，因此，了解信息系统开发过程的各个环节和步骤是非常必要的。
一、需求分析阶段需求分析阶段是信息系统开发的第一步，也是最为关键的一步。
在这个阶段中，开发团队必须与用户进行充分的沟通和交流，了解用户的真实需求和期望。
通过需求调研、访谈和观察等方式，确定系统需求，明确系统功能和性能指标，并进行需求文档的编写。
同时，需求分析人员还需要考虑系统的可行性，包括技术可行性、经济可行性和操作可行性等。
二、概要设计阶段在需求分析阶段确定系统需求后，下一步是进行概要设计。
概要设计是指在需求的基础上，对系统的总体结构和模块进行设计，包括系统的架构、模块划分和模块之间的关系等。
概要设计的结果是制定概要设计文档，为后续的详细设计和编码提供指导。
三、详细设计阶段详细设计阶段是在概要设计的基础上，对系统的具体功能和模块进行详细的设计。
在这个阶段，需要针对每个模块进行详细的设计，包括设计模式的选择、算法的设计和数据结构的定义等。
详细设计的结果是制定详细设计文档，为编码和测试提供依据。
四、编码与单元测试阶段在详细设计完成后，开发人员开始进行编码工作。
编码是将设计文档中的设计思路转化为代码的过程，开发人员需要按照编码规范和设计要求，使用合适的编程语言和开发工具，进行代码的编写。
完成编码后，需要进行单元测试，确保编写的代码符合设计要求，并且能够达到预期的功能。
五、集成测试阶段在单元测试通过后，系统进入集成测试阶段。
在这个阶段，各个模块被逐步地组合在一起进行测试，检查模块之间的接口是否正常，是否能够协同工作。
通过集成测试，可以发现并解决系统的集成问题，确保整个系统的功能正常。
六、系统测试阶段系统测试是对整个系统进行全面的测试和验证。
在这个阶段，需要执行各种测试案例，验证系统的功能、性能和稳定性等。
信息系统的开发与管理
信息系统的开发与管理信息系统在现代社会中起着至关重要的作用。
它们帮助组织管理海量的数据、优化业务流程，并提供决策支持。
信息系统的开发与管理是一个复杂的过程，涉及多个环节和关键要素。
本文将探讨信息系统的开发与管理，从需求分析到系统维护，全面阐述这一过程的重要性和有效性。
1. 需求分析在信息系统的开发过程中，需求分析是至关重要的一步。
它确保系统能够满足用户的需求并解决问题。
需求分析包括对用户需求的调研和分析，明确系统功能和性能的要求。
此外，需求分析还考虑系统与其他系统的接口和数据交换。
只有深入了解并满足用户需求，才能开发出高质量的信息系统。
2. 系统设计系统设计是信息系统开发过程中的关键环节。
在这一阶段，开发团队将根据需求分析的结果，设计出符合要求的系统结构和架构。
系统设计涉及到技术选择、数据库设计、用户界面设计等方面。
合理的系统设计能够保证系统的可靠性、安全性和可扩展性。
3. 编码与测试在系统设计完成后，开发团队将开始编写代码并进行测试。
编码是将系统设计转化为实际可执行的程序代码的过程。
编码的质量和效率对系统的最终性能和用户体验有着重要影响。
在编码完成后，测试团队将对系统进行功能测试、性能测试和安全性测试，确保系统的稳定运行和满足用户需求。
4. 系统部署系统部署是将开发完成的系统投入使用的过程。
在这一阶段，开发团队需要配置服务器、安装软件并进行系统的初步调试。
系统部署还包括将系统数据从旧系统迁移到新系统中，确保数据的完整性和连续性。
正确的系统部署能够保障用户顺利过渡到新系统并获得良好的使用体验。
5. 系统维护系统维护是信息系统开发与管理的一个重要环节。
它包括对系统的日常监控、故障排除和改进。
保持系统的稳定性和安全性是系统维护的首要任务。
同时，根据用户的反馈和需求变化，开发团队需要及时对系统进行更新和优化，以提供更好的服务和用户体验。
信息系统的开发与管理需要多方面的专业知识和技能。
同时，团队合作和沟通也是成功的关键。
信息系统开发与项目安全管理规定
信息系统开发与项目安全管理规定第一章总则第一条为规范科技发展部信息系统开发相关安全控制，保障信息系统本身的安全性以及开发、测试和投产过程的安全性，规范信息系统获取、开发与维护过程中的职责定义与流程管理，特制定本规定。
第二条本规定适用于科技发展部范围内的信息系统获取、开发、实施、投产各过程及项目实施的管理。
第二章组织与职责第三条科技发展部风险管理组负责制定相关规定，并监督各部门落实情况。
第四条各部门安全组负责监督和检查本规定在本部门的落实情况。
第五条项目需求部门除提出功能需求外还负责在相关部门的协助下提出系统安全需求。
第六条项目建设部门承担具体信息系统设计、开发实施，负责进行系统安全需求分析。
保证系统设计、开发、测试、验收和投产实施阶段满足项目安全需求和现有的系统安全标准和规范。
组织系统安全需求、设计和投产评审。
第三章信息系统开发与项目安全管理规定第七条信息系统建设项目各阶段（尤其是需求设计、测试及投产等重要阶段）评审时，评审内容必须包括相应的安全要求，具体要求参见附件2：信息安全功能设计检查列表。
第八条系统安全评审时，应提交相应安全设计、实现或验证材料，对于评审中发现的问题相关责任部门应及时整改。
第九条对于公共可用系统及重要信息数据的完整性应进行保护，以防止未经授权的修改。
同时，网上公开信息的修改发布遵循业务部门的相关管理规定，只有经过授权流程后才能修改相应信息。
第十条安全需求分析（一）在项目的计划阶段，项目需求部门与项目建设部门讨论并明确系统安全需求分析，作为项目需求分析报告的组成部分。
（二）项目需求部门与项目建设部门应对系统进行风险分析，考虑业务处理相关流程的安全技术控制需求、生产系统及其相关在线系统运行过程中的安全要求，在满足相关法律、法规及规章、技术规范和标准等约束条件下，确定系统的安全需求。
（三）系统安全保护遵循适度保护的原则，需满足以下基本要求，同时实施与业务安全等级要求相应的安全机制：1.采取必要的技术手段，建立适当的安全管理控制机制，保证数据信息在处理、存储和传输过程中的完整性和安全性，防止数据信息被非法使用、篡改和复制。
iso27001控制域
iso27001控制域ISO 27001控制域是国际标准化组织（ISO）制定的信息安全管理体系（ISMS）的核心要素之一。
该标准规定了一个包含14个控制域和114个控制措施的框架，用于保护组织的信息资产及相关资源。
1. 安全政策（A.5）安全政策是组织制定和实施信息安全管理体系的基础。
它应明确规定信息安全目标、责任和权限，确保管理层对信息安全的重视，并为整个组织提供一个明确的方向。
2. 组织（A.6）组织控制域主要关注信息安全管理体系的建立和维护。
其中包括确定信息安全角色和责任、分配资源、制定安全规章制度以及开展内部审核和管理评审等。
3. 人力资源安全（A.7）人力资源安全控制域旨在确保组织的员工和相关方对信息安全的意识和责任。
它包括招聘、培训、绩效评估和合同管理等方面的控制措施，以确保员工在信息安全方面具备必要的能力和素质。
4. 资产管理（A.8）资产管理控制域关注组织的信息资产及其相关资源的保护。
该控制域要求组织对信息资产进行分类、标记、归档和备份，以确保其安全性和可用性。
5. 访问控制（A.9）访问控制控制域旨在防止未经授权的访问和使用信息资产。
它包括对物理和逻辑访问进行控制，确保只有授权的人员能够获得相应的权限和资源。
6. 密码策略（A.10）密码策略控制域重点关注密码的保护和管理。
该控制域要求组织制定密码策略，包括设定密码复杂度、定期更换密码、禁止共享密码等，以确保密码的安全性。
7. 物理与环境安全（A.11）物理与环境安全控制域要求组织采取适当的措施，保护信息资产免受物理和环境威胁。
这包括控制访问、防火墙、监控设备和灾难恢复计划等。
8. 通信与运营管理（A.12）通信与运营管理控制域关注组织的通信和运营过程的安全性。
它包括网络安全、电子邮件安全、供应商关系管理等，以确保组织的信息通信和运营过程的安全性。
9. 系统获取、开发和维护（A.13）系统获取、开发和维护控制域要求组织在系统开发和维护过程中考虑信息安全。
信息系统采购、开发和维护制度
信息系统采购、开发和维护制度11.1 系统安全需求11.1.1 系统的安全需求分析与范围第243条在系统开发的整个过程（特别是在系统需求阶段）都必须考虑安全需求，包括但不限于：1)系统架构2)用户认证3)访问控制和授权4)事务处理的机密性和完整性5)日志记录功能6)系统配臵7)法律法规和兼容性要求8)系统恢复第244条在系统的需求和设计阶段，需要对系统进行安全方面的评审。
第245条应该在开发的整个周期对安全需求实施的正确性进行阶段性检查，以确保其对应的安全措施按照要求被定义、设计、部署和测试。
第246条在使用商业软件或软件包前，必须按照上述安全需求进行评估。
对于软件的安全控制要求应该在评估之前定义好。
第247条软件必须通过用户的正式验收后才能投入生产。
软件在正式使用前必须经过安全方面的测试，测试内容必须包括所有设计文档中的安全要求。
第248条为了对用户的操作进行检查和审计，系统必须提供日志记录功能。
系统应提供只有日志审计人员可以访问的用来查看日志记录的审计接口。
日志文件必须设臵严格的访问控制，包括系统管理员、日志审核员在内所有角色都只能有查看权限。
11.2 应用系统中的安全11.2.1 数据输入的验证第249条所有接受数据输入的入口必须有相应的验证处理，包括但不限于：1)数据的长度2)数据的类型3)数据的范围4)字符的限制第250条根据业务需要，对于按照纸面信息输入的数据，系统应该提供“数据在输入被确认”之后才能提交的功能。
第251条系统应该对错误的输入数据提供有帮助的提示信息。
必须对数据输入验证功能进行全面的测试，以保证其正确性和有效性。
系统在使用过程中，应该明确定义参与数据输入各环节所有相关人员的职责。
11.2.2 内部处理的控制第252条应用系统的设计应该考虑以下因素，防止正确输入的数据因错误处理或人为因素等遭到破坏：1)程序应该有处理的校验机制2)程序应该有相应的例外处理机制3)对于有先后执行顺序的程序或程序模块，内部必须有执行顺序的限制机制第253条控制措施的选择应根据应用的性质和数据受损对业务造成的影响而定，可选择的措施包括但不限于：1)会话或批处理控制措施，在事务更新后协调相关数据文件的一致性2)验证系统生成数据的正确性3)检查数据完整性，特别是在计算机之间传输的数据4)计算记录和文件的哈希值以便验证5)确保程序以正确的顺序运行，在出现故障时终止，在问题解决前暂停处理11.2.3 消息验证第254条对需要确保消息内容完整性的应用（例如电子交易）应该使用消息验证。
软件资产分级管理制度
软件资产分级管理制度目录一、软件资产等级分类及责任部门 (2)二、管理部门职责： (2)三、软件资产使用监管单位： (3)四、管理制度 (3)引用文件： (3)软件资产分级管理制度一、软件资产等级分类及责任部门1、非脚本源代码(一级)：运行前需要先编译的源代码。
由源代码管理人员和研发部开发人员共同承担安全管理责任。
标记为S1。
2、脚本源代码(二级)：运行前不需要先编译的源代码的源代码。
由源代码管理人员、测试部测试人员，研发部开发人员共同承担安全管理责任。
标记为S2。
3、编译执行程序(二级)：一级源代码经编译后生成的可运行程序、组件或库文件。
由源代码管理人员、测试部测试人员和研发部开发人员共同承担安全管理责任。
标记为S2。
4、集成软件(三级):由组件、库文件、可执行程序、配置文件等通过特定组合配置生成的可运行的软件系统或平台。
由源代码管理人员、服务部、测试部共同承担安全管理责任。
标记为S3。
5、第三方组件（四级）：由第三方提供的用于集成或二次开发用的组件、库文件或其他相关程序及代码。
由源代码管理人员、测试部测试人员，服务部系统服务人员、研发部开发人员共同承担安全管理责任。
标记为S4。
6、其他软件（四级）:不属于以上类别的软件。
二、管理部门职责：1、信息安全管理工作小组1)制定源代码安全管理规范。
2)对外部借阅软件资产进行审批。
2、源代码管理岗1)制定源代码开发及安全管理制度2)外部借阅记录表管理,记录借阅时间，借阅原因，借阅单位，借阅单位经手人，审批人，借出单位经手人，预期归还时间表，实际归还时间，归还时完好性及完整性描述。
3)部署软件开发管理工具，SVN(Subversion是一种版本管理控制系统)、VSS(Visual SourceSafe 是一种源代码控制系统)、SCM(Software Configuration Management软件配置管理)。
4)管理和分配开发者权限，控制授权开发人员、测试人员、软件配置人员可访问的程序存放目录。
BS7799 安全 标准简介
BS7799 标准简介BS7799是英国标准协会(British Standards Institute，BSI)于1995年2月制定的信息安全标准，1999年5月，BSI对BS 7799进行了修订改版，发展成为后来最主要的一个版本，2000年1月，BS 7799内容中的第一部分被ISO采纳，正式成为ISO/IEC 17799标准。
BS7799分两个部分第一部分，也就是纳入到ISO/IEC 17799:2000标准的部分，是信息安全管理实施细则(Code of Practice for Information Security Management)，主要供负责信息安全系统开发的人员作为参考使用，其中分十个标题，定义了127个安全控制。
BS7799-1:1999（ISO/IEC 17799:2000）中的十个内容标题分别是·安全策略Security policy·资产和资源的组织Organization of assets and resources·人员安全Personnel security·物理和环境安全Physical and environmental security·通信和操作管理Communication and operation management·访问控制Access control·系统开发和维护System development and maintenance·业务连续性管理Business continuity management·符合性Compliance第二部分，是建立信息安全管理体系(ISMS)的一套规范(Specification for Information Security Management Systems)，其中详细说明了建立、实施和维护信息安全管理系统的要求，指出实施机构应该遵循的风险评估标准，当然，如果要得到BSI最终的认证(对依据BS7799-2建立的ISMS进行认证)，还有一系列相应的注册认证过程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
信息系统获取、开发与维护程序
1.目的
为确保安全成为所开发的信息系统一个有机组成部分，保证开发过程安全，特制定本程序。
2.范围
2.1适用于本公司所有信息系统的开发活动中，信息系统内在安全性的管理。
本程序作为软件开发项目管理规定的补充，而不是作为软件开发项目管理
的整体规范。
2.2开发过程中所形成的需求分析文档、设计文档、软件代码、测试文档等技
术信息的管理应遵从信息资产密级管理的有关规定，本程序不在另行规定。
3.术语及定义
无
4.引用文件
4.1下列文件中的条款通过本规定的引用而成为本规定的条款。
凡是注日期的
引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用
于本标准，然而，鼓励各部门研究是否可使用这些文件的最新版本。
凡是
不注日期的引用文件，其最新版本适用于本标准。
4.2ISO/IEC 27001:2005 信息技术-安全技术-信息安全管理体系要求
4.3ISO/IEC 17799:2005 信息技术-安全技术-信息安全管理实施细则
4.4信息资产密级管理规定
5.职责和权限
开发部是信息系统开发过程中的安全管理部门,负责保证开发过程安全。
6.工作程序
6.1控制措施-对信息系统进行安全性需求分析与相关规格说明
6.1.1目标：在描述新系统或改进原有系统的业务需求时，应收集、分析
系统在安全性方面的需求，并在系统需求规格说明书详细描述。
6.1.2安全性需求包括两方面的内容，一是对系统本身的安全需求，如系
统具备数据通信加密、用户身份鉴别等功能，在确定安全要求时，
要考虑系统中的自动安全控制和支持人工安全控制的要求；二是对
系统设计开发过程本身也要进行控制，例如在不同的设计开发阶段
的评审与验证，确保对程序源代码的保护、对设计人员的控制等。
6.1.3安全要求在软件开发生命周期中的分布如下图所示：
6.1.4在使用新的应用程序或增强现有的应用程序时必须做安全性影响分
析, 由信息系统项目经理提交安全需求分析。
内容可包括以下项：
1)确认需要保护的资产。
2)评估这些资产需要采取什么安全控制措施。
3)考虑是否在系统中加入自动安全控制措施还是建立人工安全控制
措施。
4)在软硬件采购时，应尽量使用经过专业评估和认证的产品。
6.2在应用中建立安全措施
6.2.1控制措施-输入数据验证
6.2.1.1控制描述-输入应用系统的数据应加以验证，以确保数据是正
确的。
6.2.1.2实施指南-应该校验应用于业务交易、常备数据和参数表的输
入信息。
需要考虑下列（但不仅限于）内容：
1)输入校验，诸如边界校验或者限制特定输入数据范围的域，以检
测下列错误：
a)范围之外的值；
b)数据字段中的无效字符；
c)丢失或不完整的数据；
d)超过数据的上下容量限制；
e)未授权的或矛盾的控制数据；
f)业务流程、系统安全运行、法规政策等方面所要求的数据校
验；
2)定期评审关键字段或数据文件的内容，以证实其有效性和完整
性；
3)检查硬拷贝输入文档是否有任何未授权的变更（输入文档的所有
变更均应予以授权）；
4)对输入数据验证错误后的处理程序；
5)测试输入数据合理性的程序；
6)定义在数据输入过程中所涉及的全部人员的职责。
7)创建在数据输入过程中所涉及的活动的日志。
8)其它信息-适当时，可以考虑对输入数据进行自动检查和验证，
以减少出错的风险和预防包括缓冲区溢出和代码注入等普通的
攻击。
6.2.2控制措施-内部处理的控制
6.2.2.1控制描述-应用中需要验证检查由于处理错误或故意行为造
成的信息讹误。
6.2.2.2实施指南-应用系统的设计与实现应尽量减少处理故障时对
数据完整性的损坏。
需要考虑下列（但不仅限于）内容：
1)通过添加、修改和删除功能实现数据变更；
2)防止程序以错误次序运行；
3)使用适当的程序恢复故障，以确保数据的正确处理；
4)防范利用缓冲区超出/溢出进行的攻击。
6.2.2.3应准备适当的检查列表，将检查活动文档化，并应保证检查
结果的安全。
需要考虑下列（但不仅限于）检查例子：
1)验证系统生成的输入数据；
2)检查在中央计算机和远程计算机之间所下载或上载的数据或
软件的完整性、真实性或者其他任何安全特性；
3)记录文件字节大小；
4)检查以确保应用程序在正确时刻运行；
5)检查以确保程序以正确的次序运行并且在发生故障时终止，
以及在问题解决之前，停止进一步的处理；
6)创建处理时所涉及的活动的日志。
6.2.2.4其它信息-正确输入的数据可能被硬件错误、处理错误和故意
的行为所破坏。
所需的验证检查取决于应用系统的性质和毁
坏数据对业务的影响。
6.2.3控制措施-消息完整性
6.2.2.5控制描述-应用中应该识别确保消息真实性和保护消息完整
性的要求，实施适当的控制措施。
6.2.2.6实施指南-应进行安全风险的评估以判定是否需要消息完整
性验证，并确定最合适的实施方法。
6.2.2.7其它信息-密码技术可被用作一种合适的实现消息鉴别的手
段。
6.2.4控制措施-输出数据验证
6.2.4.1控制措施-从应用系统输出的数据应加以验证，以确保对所存
储信息的处理是正确的且适于当前运行环境的。
6.2.4.2实施指南-输出验证可以包括（但不仅限于）以下内容：
1)合理性检查，以测试输出数据是否合理；
2)调节控制措施的数量，以确保处理所有数据；
3)为读者或后续的处理系统提供足够的信息，以确定信息的准
确性、完备性、精确性和分类；
4)对输出数据验证结果进行处理程序；
5)定义在数据输出过程中所涉及的全部人员的职责。
6)创建在数据输出验证过程中活动的日志。
6.2.4.3其它信息-一般来说，系统和应用是在假设已经进行了适当的
验证、确认和测试的条件下构建的，其输出总是正确的。
然
而，这种假设并不总是有效；例如，已经过测试的系统仍可
能在某些环境下产生不正确的输出。
6.3开发和支持过程中的安全
6.3.1系统测试数据的保护
6.3.1.1控制措施-测试数据应认真地加以选择、保护和控制。
6.3.1.2实施指南-应避免使用包含个人信息或其它敏感信息的运行
数据库用于测试。
如果测试使用了个人或其他敏感信息，那
么在使用之前应去除或修改所有的敏感细节和内容。
当用于
测试时，应使用下列（但不仅限于）指南保护运行数据：
1)应用于运行应用系统的访问控制程序，还应用于测试应用系统；
2)运行信息每次被拷贝到测试应用系统时应有独立的授权；
3)在测试完成之后，应立即从测试应用系统清除运行信息；
4)应记录运行信息的拷贝和使用日志以提供审核踪迹。
6.3.1.3其它信息-系统验收测试常常要求相当多的尽可能接近运行
数据的测试数据。
6.3.2对程序源代码的访问控制
6.3.2.1控制措施-应限制访问程序源代码。
6.3.2.2实施指南-对程序源代码和相关事项（诸如设计、说明书、确
认计划和验证计划）的访问应严格控制，以防引入非授权功
能和避免无意识的变更。
对于程序源代码的保存，通过代码
集中存储控制来实现，放在公司统一的配置管理库中。
应考
虑下列（但不仅限于）指南：
1)若有可能，在运行系统中不应保留源程序库；
2)程序源代码和配置管理库应进行规范管理；
3)应限制支持人员访问配置管理库；
4)更新配置项，向程序员发布程序源码应在获得适当的授权
5)应维护对配置库所有访问的审核日志；
6)维护配置库应该有规范的制度。
6.3.2.3其它信息-程序源代码是由程序员编写的代码，经编译（和链
接）后产生可执行代码。
特定程序语言不能正式区分源代码
和可执行代码，这是因为可执行代码是在它们被激活时产生
的。
6.3.3外包软件开发
6.3.3.1控制措施-组织应管理和监视外包软件的开发。
6.3.3.2实施指南-在外包软件开发时，应考虑下列（但不仅限于）各
点：
1)许可证安排、代码所有权和知识产权；
2)所完成工作的质量和准确性的认证；
3)第三方发生故障时的契约安排；
4)审核所完成的工作质量和准确性的访问权；
5)代码质量和安全功能的合同要求；
6)在安装前，测试恶意代码和特洛伊木马。
7.相关支持文件
8.记录
9.附录。