软件开发合同模板

软件开发合同模板2软件开发合同书

合同编号:

甲方：

乙方：

地址：

地址：

邮编：

邮编：

电话：

电话：

签订地点：

签订日期：

年月日

上述甲、乙双方，经友好协商全都，达成以下协议。双方申明，双方都已理解并认可了本合同的全部内容，同意担当各自应担当的权利和义务，忠实地履行本合同。

第一条

本合同技术开发工程的内容、工作进度与安排、数量、价款、交付和验收方式等由附件载明。

其次条

合同履行期限根据附件规定的工作进度打算，经双方协商全都，可以延长该期限（以下统称合同期限）。

第三条

甲方应向乙方供应必要的资料和帮助并派专人负责与乙方联络、协调。

第四条

乙方承诺在履行合同时不进展有损甲方形象、声誉等的行为。

第五条双方的根本权利和根本义务

5-1甲方的权利和义务

5-1-1

依据本合同工程的实际需要和乙方的要求供应帮助并供应有关的材料及图片等，甲方保证所供应的全部资料完整、真实、合法。

5-1-2

本合同标的的使用应当符合国家法律规定和社会公共利益。

5-1-3

对违反5-1-1和5-1-2的要求而进展的使用、操作所引起的问题以及产生的影响、后果担当全部责任。

5-1-4

按本合同商定支付费用

5-2乙方的权利和义务

5-2-1

根据甲方供应的材料按时完本钱合同规定的技术开发工作。

5-2-2

可以依据甲方的要求帮忙甲方举办培训和技术询问。

5-2-3

依合同收取费用。

第六条

甲方同意按双方商定的付款方式和时间准时向乙方支付合同费用，以及供应其他必要的帮忙。

第七条甲方承诺，向乙方供应的内容、资料等不会侵害任何第三方的权利；若发生侵害第三方的权利的情形，由甲方担当全部责任。因甲方在使用本合同标的时给第三人造成损害的，由甲方自行担当责任。

第八条

甲方同意，本合同的签署意味着甲方授权乙方在履行本合同时可以使用甲方的名称、商标、域名、企业标志等，但此等使用不能损害甲方的利益。

第九条

乙方若不能按时供应软件产品，其责任由乙方担当。

第十条

本合同标的及相关作品、程序、文件源码的版权属乙方全部，但乙方授予甲方排他的使用权。未经乙方许可，甲方不得公布文件源码，不得复制、传播、出售或者许可他人使用标的作品及其程序等。乙方可以在业务范围内使用这些作品。

第十一条

甲方不能按时支付合同费用，导致的工期延误，其责任由甲方担当。

第十二条

双方当事人应当保守在履行本合同过程中获知的对方商业隐秘。

第十三条

双方应本着诚恳信用的原则履行本合同。任何一方在履行中采纳欺诈、胁迫或者暴力的手段，另一方可以解除本合同并有权要求对方赔偿损失。

任何一方在履行中发觉或者有证据说明对方已经、正在或将要违约，可以中止履行本合同，但应准时通知对方。若对方连续不履行、履行不当或者违反本合同，该方可以解除本合同并要求对方赔偿损失。

第十四条

本合同签订后，经双方当事人协商全都，可以对本合同有关条款进展变更或者补充但应当以书面形式确认。上述文件一经签署，即具有法律效力并成为本合同的有效组成局部。

第十五条

本合同附件为本合同不行分割的一局部，与合同正文具有同等法律效力。

第十六条

任意一方欲提前解除本合同，应提前通知对方。甲方提前解除合同的，无权要求乙方返还第六条的费用并应对乙方患病的损失担当赔偿责任；乙方无故解除合同的，除返还甲方全部已支付费用外，还应支付甲方合同总金额的30％作为赔偿。本合同其他条款对合同的解除另有商定的，从其商定。

第十七条

任何一方没有行使其权利或没有就对方的违约行为实行任何行动，不应被视为是对权利的放弃或对追究违约责任或义务的放弃。任何一方放弃针对对方的任何权利，或放弃追究对方的任何过失，不应视为对任何其他权利或追究任何其他过失的放弃。前款权利不因本合同的终止、撤消、无效而消逝。

第十八条

任何一方违反本合同，给对方造成损失的，还应赔偿损失。在本合同其他条款对违约有详细商定时，从其商定。

第十九条

因不行抗力或者其他意外大事，或者使得本合同的履行不行能、不必要或者无意义的，任一方均可以解除本合同。患病不行抗力、意外大事的一方全部或局部不能履行本合同、解除或拖延履行本合同的，应将大事状况以书面形式通知另一方并向另一方提交相应的证明。

本合同所称不行抗力、意外大事是指不能预见、不能克制并不能避开且对一方当事人造成重大影响的客观大事，包括但不限于自然灾难如洪水、地震、火灾和风暴等以及社会大事如战斗、*、政府行为等。

其次十条

订立本合同所依据的客观状况发生重大变化，致使本合同无法履行的，经双方协商同意，可以变更本合同相关内容或者终止合同的履行。

其次十一条

一方变更通讯地址或者联系方式，应准时将变更后的地址、联系方式通知另一方，否则变更方应对此造成的一切后果担当责任。

其次十二条

双方当事人对本合同的订立、解释、履行、效力等发生争议的，应友好协商解决；协商不成的，双方同意向合同签订地的仲裁委员会提交仲裁并承受其仲裁规章。

本合同的终止、撤消、无效不应影响前款商定的效力。

其次十三条

本合同的订立、解释、履行、效力和争议的解决等均适用中华人民共和国法律。对本合同的理解与解释应依据原意并结合本合同目的进展。

其次十四条

假如本合同任何条款依据现行法律被确定为无效或无法实施，本合同的其他全部条款将连续有效。此种状况下，双方将以有效的商定替换该商定，且该有效商定应尽可能接近原商定和本合同相应的精神和宗旨。

其次十五条

本合同经双方授权代表签字并盖章，自签订日起生效。

其次十六条

本合同一式两份，双方当事人各执一份，具有同等法律效力。

甲方（盖章）

乙方（盖章）

授权代表签字

授权代表签字

附件：开发建立工程工作进度与安排、数量、价款、交付和验收方式

一、开发工程内容

甲方向乙方开发______________________软件（单机版/网络版）____套。

二、合同金额及付款方式

1.本合同金额总计：人民币元。

2．付款方式

本合同签订后3日内，甲方向乙方支付合同金额的

％，即

元，验收之后5日内支付合同金额的

%,即

元,剩余合同金额的

%即

元作为软件质量保证金，于软件正常运行（即验收）

天后支付。

三、完成及验收时间：

完成时间：乙方收到材料、图片及甲方根据本附件规定先行支付的款项后开头软件的开发。开发时间为____个月。即从______年___月___日起至______年___月___日止。经双方协商全都，可以延长或缩短该期限。

验收期限：甲方在接到乙方允许验收通知后日内完成工程的验收,并确认。

四、验收标准和验收后修改补充

1、甲方验收软件的标准以双方合拟的合同附件“功能说明书”作为通过的依据。

2、验收合格，甲方应以书面方式签收，但甲方在乙方交付工作成果后一周内未书面签收也未提出异议的，视为甲方验收合格。

3、甲方在软件使用过程中，假如要增加合同附件（功能说明书）之外的其它功能，则要另行支付乙方开发费用；如属软件本身质量问题，乙方免费为甲方修正。

4、软件的培训费用已包括在本软件开发合同书的合同金额内。

五、合同期限

本合同有效期为*年*月*日至*年*月*日。

篇2：配置治理规划样例(软件开发)

软件配置治理规划

【用户名称】

神州数码信息系统有限公司

密级：一般**工程

软件配置治理规划

V0.1

文档编号：

工程名称：

编

写：

编写日期：

审

核：

审核日期：

批

准：

批准日期：

修订文档历史记录

日期

版本

说明

2023-7-12

V0.1

第一次编写

2023-7-8

V1.0

修改

目

录

1

前言5

1.1

目标5

1.2

适用范围5

1.3

术语与简写5

1.4

参考文件5

组织构造和职责5

2.1

CCB成员及职责5

2.2

配置治理组6

配置治理工具、技术和方法6

3.1

配置治理工具6

3.2

配置治理策略6

配置治理库7

4.1

配置库构造7

4.2

配置库权限7

4.3

基线配置项7

4.4

其他配置项8

4.4.1

治理文档或过程记录8

4.4.2

工程环境9

5

文件命名与版本掌握9

5.1

文件命名标准9

5.1.1

基线命名标准9

5.1.2

其他配置项命名标准10

5.2

版本标识10

6

变更治理11

6.1

变更缘由11

6.2

变更流程12

6.3

变更跟踪14

7

版本制作与公布流程16

8

安全与备份16

8.1

备份16

8.2

安全防护17

9

配置状态公布17

15

1

前言

1.1

目标

本规划是信息平台工程配置治理活动的基准，对信息平台工程的配置治理活动进展筹划。

1.2

适用范围

本规划是信息平台工程整体规划的一局部，适用于信息平台工程的配置治理活动。

1.3

术语与简写

CCB：变更掌握委员会

SQA：质量保证

SCM：配置治理

1.4

参考文件

DCG-SCM-P-01-配置治理标准。

组织构造和职责

2.1

CCB成员及职责

工程内部CCB成员：章某（CCB组长）、陈、小伟、小明、玲玲。

CCB组职责：打算CCB成员中对变更确认审批级别，协调CCB成员对变更达成全都，并确认变更的结果。

工程总监

章某：负责对工程的总体调控。

工程经理

小伟：负责对工程中规划的变更等进展确认，并对变更所涉及的资源变更进展评估，负责变更的执行。

需求调研

陈：负责工程的整体需求。

技术经理

小明：负责工程技术支持及工程的运行。

SCM人员

玲玲：负责变更，配置库日常治理和权限掌握。

测试经理

？：负责评估变更中测试方面的问题。

SQA

人员

？：过程审计。

2.2

配置治理组

配置治理员

：负责搭建配置库，制定并执行配置治理规划、培训工程组成员、执行日常配置治理工作。

配置治理工具、技术和方法

3.1

配置治理工具

效劳器IP地址：

//00

文档治理

配置治理工具：SVN

配置库名称：WS

源代码治理

配置治理工具：SVN

配置库名称：WS

配置治理库

4.1

配置库构造

配置库分为工作库、受控库和基线库。

工作库：存储工程的全部工作产品中间结果，即正处于开发中的代码和编写中的文档，其内容可能进展频繁的修改。

受控库：存储工程的全部预备生成基线的工作成果，待评审的文档、部署程序的中间版本、以及工程治理类文档等。

基线库：存储工程的全部基线化了的工作成果，评审通过的阶段产出物、具有路标性质的对外公布版本等。

4.2

配置库权限

工作库：工程组全部成员均有读写权限。

受控库：配置治理员和工程经理有读写权限，其他工程组成员有只读权限。

基线库：配置治理员有读写权限，其他人员经授权可调阅。

（注：共通代码由专人治理）

4.3

基线配置项

基线类别

基线配置项名称

基线配置项的位置

备注

需求基线

工程数据交换标准

软件需求规格说明书

工作说明书

工程启动报告

设计基线

概要设计说明书

编码基线

各公布版本

测试基线

系统测试用例

系统出场测试报告

验收基线

系统初验报告

系统终验报告

4.4

其他配置项

4.4.1

治理文档或过程记录

配置项名称

配置项的位置

备注

治理文档

工程周报

客户周报

会议纪要

业务联系单

评审规划

评审记录

培训记录

4.4.2

工程环境

配置项名称

配置项的位置

备注

环境

开发效劳器

测试效劳器

测试治理效劳器

配置效劳器

00

内网

5

文件命名与版本掌握

5.1

文件命名标准

5.1.1

基线命名标准

[工程名称]+[子系统名]+[文档名称]+[V*.y]（版本号）

工程名称定义为：信息平台（英文缩写：WS）

子系统名：若没有子系统可以省略

举例：信息平台-工作说明书V1.0；

5.1.2

其他配置项命名标准

n

与时间相关的文档命名：

[工程名称][文档名称][

yyyymmdd]（注：其中假如是周报yyyymmdd以完毕日期为准）

备注：yyyymmdd为“年月日”时间格式

举例：信息平台-工程周报20230607；

（完毕日期）

信息平台-会议纪要20230602；

n

与时间没有直接关系的文档命名：

直接以[工程名称][文档名称]命名。

举例：信息平台初验阶段报告；

信息平台工程总结报告；

5.2

版本标识

文档公布的版本遵循*.y（主版本.副版本）形式：

1、

版本标识定义原则

n

版本标识必需唯一标识不同的版本；

n

版本标识必需反映不同级别版本的层次关系；例如采纳*.y（主版本.从版本）的定义规章

n

必需定义不同级别版本号增加的规章。

2、

版本设置规章

n

新起草编写的文件定为V0.1版；逐步完善还没有通过评审的文件版本升级为V0.y版；

n

通过内部正式审批的文件版本升级为V1.0版，可对外公布；

n

称为内部基准的文件如有少量修改，可升级为V1.*版；

n

如有通过客户的评审，文件版本可升级为V2.0，以此类推。

代码公布的版本遵循*.y（主版本.副版本）形式：

Build为build挨次号，每build一次号码加1；永久不清零。

P为FAT挨次号，每提交FAT测试号码加1，FAT测试由公司人员测试。

Z为UAT挨次号，每提交UAT测试号码加1，UAT测试有用户或监理参与。

*,Y以用户确定为准。用户版本号增加时P和Z清零。

yyyyymmdd代表公布版本日期

分类

版本命名

基线存放路径

对内版本

YZWS_[子系统英文名]_yyyymmdd-####

信息平台版本公布/对内公布

测试版本

YZWS_FAT_[.[.][.]][Build

]_yyyymmdd

信息平台版本公布/测试版本

对外版本

YZWS_UAT_[.[.][.]][Build

]_yyyymmdd

信息平台版本公布/对外公布

YZWS_[.[.][.]][Build

]_yyyymmdd

6

变更治理

6.1

变更缘由

1、评审、审计、测试和验证发觉问题引起配置的配置项变更，配置项的版本需要更新。

更改源是《评审报告》、《集成测试分析报告》或《审计报告》。

2、客户、工程组填写的变更申请引起配置项变更，变更申请表是更改源。

3、消失以下状况时引起的配置项变更，不需要填写变更申请表：

规划级的文档更改——WBS规划；

《软件配置治理规划》、《软件质量保证规划》；

测试工具或测试脚本（不属于提交给用户）。

4、当工程范围发生变化、风险发生并且采纳了工程规划中没有指定的订正措施、工程规划与实际状况偏离20%以上、由内部与外部审计而导致的订正活动、工程规划中的任何修改条件满意等大事发生时，由工程经理组织相应的配置掌握委员会成员对要发生的变更进展评审

6.2

变更流程

1.

变更申请

1)

变更申请人通过多种渠道提出对配置项的变更恳求。驱动因素主要包括用户需求变更、评审、测试以及配置审计等。

2)

变更申请人负责填写《需求设计变更申请表》，并提交配置掌握委员会实施变更评估。

2.

变更评估

1)

针对变更申请人提交的变更恳求，配置掌握委员会在评估该变更的影响范围及对工程进度、本钱、质量等指标的影响程度后，打算是否实施该变更。

2)

配置掌握委员会将针对该变更做出的打算（承受或拒绝）通知变更申请人。

3.

变更实施

1)

变更申请获得批准后，配置掌握委员会将该变更安排给相应执行人实施。

2)

工程配置治理员将该变更涉及的全部配置项从配置库中签出并提交给变更执行人。

3)

变更执行人实施该变更；

4.

变更验证

1)

配置掌握委员会对变更后的工作产品进展验证，以确定变更是否正确完成。

2)

在变更完成并经过验证后，工程配置治理员将经批准的配置项签入配置库。

6.3

变更跟踪

1、

客户需求变更：

1)

与用户之间变更流程：工程组需要依据工程治理标准中的需求治理要求，结合工程用户实际状况制定需求变更流程，填写《需求设计变更申请表》并根据流程要求执行申请和审批过程，保存期间用户的签字确认文件。

2)

内部审批流程：10人天以内的变更工程经理确认，10人天以上，20人天以内需要工程总监确认，20人天以上的变更需要事业部总经理确认。配置治理员跟踪变更审批状态，维护《基线状态报告—变更跟踪表》。

3)

VP系统中的变更记录：工程需求负责人在VP系统中使用“范围—变更”页签录入需求变更的信息，同时更新维护“范围——范围矩阵”的范围信息和工作量信息，并发起需求变更流程，由工程经理以及工程总监进展审批。审批通过后，形成新的范围矩阵基准。

2、

预算变更：工程经理/客户经理

编写变更的《工作说明书》《工程预算表》，在VP工程治理系统中执行工程预算变更流程。

3、

工程经理变更：

1)

工程实施过程中，发生工程经理变更时，原工程经理填写《工程经理工作交接清单》与新工程经理逐项工作进展交接。

2)

新任工程经理根据工程经理任命流程进展述职和任命。

3)

工程经理变更时，工程总监负责与客户进展沟通。

7

版本制作与公布流程

8

安全与备份

8.1

备份

配置治理员每周整体备份一次配置库，保存4周以内的备份记录。

备份方式：刻盘或者异机备份

每月末提交一次配置库，存入组织级配置库（FTP上传或由QA