目录1. 前言1
1.1 目的1
1.2 术语1
1.3 参考文献1
1.4 版本说明和修改历史1
2. 软件文档1
2.1 文档的定义及作用1
2.2 软件文档的分类2
2.3 软件文档的制作与软件生存周期之间的关系3 2.4 文档的使用者3
3. 文档编制格式规范4
3.1 文档编码规则4
3.2 文档组成格式4
3.2.1 封面4
3.2.2 目录6
3.2.3 版本更新说明6
3.2.4 文件内容6
3.2.5 正文格式6
3.3 文档制作工具7
4. 文档管理规范7
4.1 文档管理岗位职责7
4.2 文档的制作7
4.2.1 文档的分类、编码与标识8
4.2.2 文档的作者、修改者和打字者8
4.3 文档的收集8
4.4 文档的配置8
4.5 文档的控制8
4.6 文档的修改管理9
4.7 文档的借阅和复制管理制度9
4.8 文档的保密性9
5. 技术文档的质量评价10
1.前言
1.1 目的
软件开发的不同阶段都会产生大量的文档。为了加强管理、提高工作效率，充分借鉴前人的经验，对文档进行规范化管理是很有必要的。它对于保管在开发中形成的文档，为公司积累宝贵的技术知识的财富，为今后的软件开发工作提供第一手的宝贵资料起着重要的作用。
为了规范创智集团工程项目的开发工作，根据国家标准局制定的有关软件开发和开发文件的规范标准，结合公司的实际，制定本规范。
1.2 术语
略。
1.3 参考文献
1)《1998计算机软件工程规范----国家标准》中国标准出版社1998年
6月第一版。
2)《软件工程概论》郑人杰等清华大学出版社1998年4月第一版。
3)《实用软件工程》郑人杰等清华大学出版社1997年4月第二版。
4)《创智软件园文档管理规范》创智（湖南）软件园有限公司1996年
5月。
5)《创智软件园软件开发管理规范》创智（湖南）软件园有限公司1995
年12月。
1.4 版本说明和修改历史
本规范是在公司原有文档规范的基础上，于1999年05月份修订而成，具体的修订人员为孙继纲、赵海等。
2.软件文档
2.1 文档的定义及作用
文档（document）是指某种数据媒体和其中所记录的数据。它具有永久性，
并可以由人或机器阅读，通常仅用于描述人工可读的东西。
正确地制作和使用软件文档，可以获得如下的便利：
●提高软件开发过程的能见度。
●提高开发效率。
●作为开发人员在一定阶段的工作成果和结束标志。
●记录开发过程中的有关信息，便于协调以后的软件、开发、使用和
维护。
●便于潜在用户了解软件的功能、性能等各项指标，为他们选购符合
自己需要的软件提供依据。
2.2 软件文档的分类
对于软件文档的分类有多种方法。
从形式上分为两类：
●开发过程中可以填写的各种图表，可称之为工作表格。
●应编制的技术资料或技术管理资料，可称之为文档或文件。
按照软件文档的产生和使用范围可以分为三类：
●开发文档：软件开发过程中，作为软件开发人员前一阶段工作成果
的体现和后一阶段工作依据的文档。包括可行性研究、项目开发计
划、需求说明、数据说明、概要设计和详细设计。
●管理文档：软件开发过程中，由软件开发人员制定的需提交管理人
员的一些工作计划和工作报告，包括项目开发计划、测试计划、测
试报告、开发进度月报及项目开发总结。
●用户文档：软件开发人员为用户准备的有关该软件使用、操作、维
护的资料，包括用户手册、操作手册、维护修改建议、需求说明。
按照计算机软件产品开发文件编制指南的国家标准（GB8567-88）的要求，在一项计算机软件的开发过程中，一般地说，应该产生14种文件：
●可行性研究报告。
●项目开发计划。
●软件需求说明书。
●数据要求说明书。
●概要设计说明书。
●详细设计说明书。
●数据库设计说明书。
●用户手册。
●操作手册。
●模块开发卷宗。
●测试计划。
●测试分析报告。
●开发进度月报。
●项目开发总结报告。
2.3 软件文档的制作与软件生存周期之间的关系
一般而言，计算机软件生存周期可以分为六个阶段：
●可行性与计划研究阶段。
●需求分析阶段。
●设计阶段。
●实现阶段。
●测试阶段。
●运行与维护阶段。
2.4 文档的使用者
对于软件文档的使用人员而言，与其所承担的工作有关，具体情况如下所示。
管理人员：
●可行性研究报告。
●项目开发计划书。
●模块开发卷宗。
●开发进度月报。
●项目开发总结报告。
开发人员：
●可行性研究报告。
●项目开发计划书。
●需求分析说明书。
●概要设计说明书
●详细设计说明书
●数据库设计说明书。
●测试计划。
●测试分析报告。
维护人员：
●设计说明书。
●测试分析报告。
●模块开发卷宗。
●
最终用户：
●系统安装手册。
●用户手册。
●系统维护手册。
●系统功能说明书
3.文档编制格式规范
3.1 文档编码规则
公司所有的技术文档，都必须具有一个唯一的系列号，格式为：
PRS-PID-XX：
1)“PRS”：创智标识符（Company Flag)。
2)“PID”：项目代号。
3)“XX”：文档标识号，参见《软件开发配置管理规程》。
例如，文件号：PRS-PowerOffice-MD-01-1.0.0
表示：该文件由本公司产品PowerOffice，MD表示是管理文档，001表示是项目开发计划书，版本号1.0.0表示是PowerOffice产品1.0.0版。
3.2 文档组成格式
公司所有文档（仅一页的文件可按单页文档格式组织）由封面、目录（Content Table)、版本更新说明书（Rivision)、文件内容等组成，如图所示
图1文档组成档式
3.2.1封面
封面组成可划分为：
1. 文档号：DOC.NO. 文档系列号 (文档文件名)
字体: Arial , 小四, 加粗
例：DOC.NO. PRS-PID-XX (Facedoc.doc)
2. 项目名称: 中文字体: 黑体, 三号字体, 加粗
英文字体: Arial , 三号字体, 加粗
例：创智文档规范
3. 文档名称: 中文字体：黑体, 一号字体, 加粗
英文字体：Arial, 一号字体, 加粗
例：工程技术项目文档规范
4.密级：英文字体: Arial, 小四字体, 加粗
划分为五类，采用下列关键词
Top Confidential
High Confidential
Confidential
Normal
General
●Top Confidential：绝密
产品文档
●High Confidential：机密
规范、指南
●Confidential：秘密
计划、管理
●Normal：普通
工作岗位有关
●General：明文
可以在社会上广为流传
例 : Normal
5. 版本号：关键词为 Version 用 Arial 字体, 大小为小四号
例: Version V1.0.0
6. 完成日期：用Arial 字体, 大小为小四号
例: 1994.11.14.
7. 作者：Written By……用 Arial 字体,大小为小四号, 加粗
例: Written By POWERISE
8. 公司LOGO: 用 USABLack 字体,大小为四号, 加粗。
例: POWERISE
9.公司名称及版权生效年份:
关键词为：创智软件园有限公司
Powerise Software.Inc.
版权生效年限：关键词为（C）公历年号
中文字体: 黑体, 四号, 加粗
例: 创智软件园有限公司 (C)1994,1999
注：此处填写产品已经经过的年份，如PowerLCMS,copyrights(C)1996,1998.英文字体: Arial , 四号, 加粗
例: Powerise Software.Inc.(C)1994,1995
10. 版权申明：字体为: Arial , 小四, 加粗
例: All Right Reserved
各项安排如下图,样板范例可参见本文档的封面：
3.2.2目录
可采用手工编制或使用文档编制 Microsoft Word 的自动生成目录的功能产生文档目录。
3.2.3版本更新说明
关键词为：Revision 内容划分为：日期(Date)、理由(Reason)、更新者(Revisor)。(首版可省略该节)
3.2.4文件内容
文件内容每一页必须包含下列三项，缺一不可：
●页首，在页首中部自动填入‘标题1’的名称。
●页脚，在页脚左部填入创智标徽POWERISE，右部填入页号。
●正文。
如下图所示，具体设置可复制本文作模块。
3.2.5正文格式
标题一：宋体、小三、粗体，左对齐；
标题二：黑体、四号、粗体，左对齐；
标题三：宋体、小四号、粗体，左对齐；
标题四：黑体、小四号、正常体，左对齐；
标题五：黑体、五号、粗体，左对齐；
正文：宋体、小四号、正常体，左对齐。
以上行距为单倍行距。
3.3 文档制作工具
使用何种文档制作工具，原则上没有限制，但必需考虑到文档交流的方便性问题。因此，如果在文档的交流方面，因为文档制作工具的使用差异造成工作上的不便，文档制作者本人应该设法解决。
用于交流和上交的文档登记说明上，应注明所使用的文档制作工具。4.文档管理规范
4.1 文档管理岗位职责
产生文档的单位包括：开发部的项目组和配置测试中心的配置测试组。
项目组的职责：
●编写开发计划书，评审/审查通过后，向配置测试组提交，进入配置
管理。
●编写阶段开发计划书、技术文档，经过评审/审查后，向配置测试组
提交，进入配置管理。
●编写阶段总结报告，向配置测试组提交，进入配置管理。
配置测试组的职责：
●编写配置测试评审计划书，评审/审查通过后，进入配置管理。
●编写阶段计划书、配置、测试和评审文档，经过评审/审查后，进入
配置管理。
●收集项目组的管理文档和技术文档
●执行阶段计划书、配置、测试和评审，经过评审/审查后，进入配置
管理。
●编写阶段总结报告，进入配置管理。
4.2 文档的制作
任何软件开发技术文档的作者必须严格按照《软件开发技术文档管理规范》来制作。
技术文档的制作可以由作者本人完成，这就要求各开发人员学习文档的制作规范，按规范进行文档编写。
技术文档也可以由作者本人手工书写，交秘书来打字完成，但技术文档的作者必须进行校对工作。
4.2.1文档的分类、编码与标识
参见《软件开发配置管理规程》
4.2.2文档的作者、修改者和打字者
对此管理的目的是明确文档的来源，使整个开发的流程清晰可查。以便今后可就某个技术细节找到相应的人（作者）进行更进一步的探讨和学习。也便于对某个项目的工作任务作出合理的安排。
每本文档在形成时，在封面就须写清楚文档的第一作者及其合作者。如果文档进行了修改、改版，在版本更新说明中，还必须写清修改人。
在对文档进行登记归档时也必须如实记录作者。其中有第一作者，修改者。同时记录打印人和定稿打印的日期。
4.3 文档的收集
技术文档的收集包括2种方式。一种是作者将完成的合乎规范的技术文档主动交配置测试中心关于本项目指定的配置测试工程师进行配置管理。一种是配置测试中心关于本项目的配置测试工程师，根据项目阶段任务和阶段成果的安排，在适当的时候向相关的文档制作者收集技术文档，进行配置管理和版本控制。
4.4 文档的配置
与项目有关的管理文档和技术文档的管理最终统一归口于软件配置测试中心的配置管理组。技术文档的管理方式是按部门、部门下面的项目组、项目组的不同阶段加以配置管理和版本控制例如：
以上只是管理的一种形式，它是根据部门来分类。另外还可以根据其它特征来分类。这些特征有时间、作者、部门、项目、文档类别等。具体采用什么样的特征可根据具体情况进行适当的分类。
在对文档进行管理时，必须对每一份正式的文档进行详细的登记。登记时的原则是：手续严密、格式清晰醒目、简化适用、登记项目完整详尽。这样在对文档进行管理时便于查找文档和检查文档的运转情况。一般采用簿式登记，以便清晰可查。
4.5 文档的控制
为保持文档和程序产品的一致性，保持各种文件之间的一致性和文件的安全性，需要对文档进行控制，具体表现在：
应该有文档管理员集中保管本项目现有全部文档的主文本两套，由其负责保管
●每一份提交给文档管理人员的文档必需具有编写人、审核人和批准
人的签字
●两套文本的内容一致，其中一套可以出借，另一套绝对不可以出借
●文档的借阅和归还必需有出借和注销的手续
●项目组种的个人文档必需和整个项目的主文档的内容和版本一致
●一份文档如果被新文档更新，原文件必需注销
4.6 文档的修改管理
在项目开发过程中，项目组内部的任何人都可以提议对开发工作的文件成果进行修改，但必需遵循如下的步骤：
●提议：项目组内部任何一个人都可以填写修改建议表，提出对文档
的修改建议
●评议：由项目负责人或项目负责人制定指定的人员对文档修改提议
进行评议，包括审查该项修改的必要性、影响范围、研究进行修改
的方法、步骤和实施计划
●审核：由项目负责人进行审核，包括合适修改的目的和要求、核实
修改活动将带来的影响、审核修改活动计划是否可行
●批准：由开发单位的部门负责人进行批准，主要是决断修改工作中
各项活动的先后顺序及各自完成日期，以保证整个开发工作按园丁
计划日期完成
●实施：由项目负责人按已批准的修改活动计划，安排各项修改活动
的负责人进行修改，建立修改记录、产生新的文件以取代原有文档，
最后把文档交付文档管理员，并奋发给有关的持有者
4.7 文档的借阅和复制管理制度
技术文档的借阅包括3种情况。一种是在软件开发部门内部的技术文档借阅。一种是项目组内部的文档借阅，一种是已经配置管理于配置测试中心的技术文档的借阅。
对于部门内部的技术文档借阅，申请人必须拥有部门经理的签名许可。
对于项目组内部的技术文档借阅，申请人必须拥有项目经理或总设计师的签名许可。
对于配置测试中心特定技术文档的借阅，必须拥有主管技术副总裁或技术总监的签名许可。
4.8 文档的保密性
对于任何一种技术文档，必须按密级进行管理，技术文档的密级在制作规范中已经说明。借阅制度如下：
●明文（General）：可以自由借阅，只要办理一下借阅手续即可。出借的
文档要登记文档份数，文件名，借阅人，预期归还时间。如须长期使用，
要保留复印件；
●普通（Normal）：只有本公司特定岗位的技术人员才可以使用的文档。
●秘密（Confidential）：管理类计划和总结文档
●机密（High Confidential）：管理规程、编写规范等文档。
●绝密（Top Confidential）：产品文档。
借出的文档要定期催还，因丢失文件、泄密造成的后果由借阅人承担。
关于技术文档的复制（拷贝和或打印）工作，必须依照上述的借阅制度进行。
5.技术文档的质量评价
高质量的文档应当体现在以下几个方面：
●规范性：符合公司关于相关类型的文档制作规范
●针对性：文档编制以前应当分清读者对象。按不同的类型、不同层
次的读者，决定怎样适应他们的需要
●精确性：文档的行文应当十分准确，不能出现多义性的描述
●清晰性：文档编写应力求简明，如有可能，配以适当的图表，以增
强其清晰性。
●完整性：任何一个文档都应当是完整的、独立的，应自成体系。
●灵活性：各个不同软件项目，其规模和复杂程度有着许多实际差别，
不能一律看待
学会低调，取舍间必有得失，不用太计较。学着踏实而务实，越努力越幸运。
软件开发过程管理规范文件管理序列号：[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）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价
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.目的 确保我局与管理体系运行有关的各岗位员工活动所依据的文件均为有效版本，防止使用作废的文件,对文件要求的相关记录进行控制，保证管理体系运行的有效性和可追溯性。 2.适用范围 适用于我局所有与管理体系运行有关的文件和资料的控制。 3.主要职责 3.1质量管理部负责组织管理体系文件的编制、修订、发放和回收等工作，负责 法律 法规、技术标准的备案管理。 3.2各部门、单位及项目部负责职责范围内文件的编制、修订、发放、回收、保管工作，对形成的记录进行控制。 3.3办公室负责公文的管理和科技档案的保管。 4.工作内容及要求 4.1文件的分类 文件分为管理文件、法律法规、技术标准、工程文件和公文。 4.1.1管理文件 管理文件包括： a)管理手册 b)管理目标 c)管理制度 d)支持性文件 e)管理过程中所形成的记录 4.1.2法律法规：适用的法律及地方法规及相关行政规章。 4.1.3技术标准：适用于施工生产及各项管理的标准及规范。
4.1.4工程文件：项目在投标及施工过程中产生的文件、记录和相关部门发来的有关工程的文件。 4.1.5公文：单位在对内实施管理和对外交往过程中，形成的具有管理效力或请示商洽工作性的规范体式文书。见《河北省水利工程局公文处理实施办法》。4.2文件的编制、评审、批准 4.2.1《管理手册》由质量管理部编写，管理者代表审核，局长批准；管理制度由各主管职能部门编写，质量管理部组织审核，管理者代表批准，质量管理部进行发放。 4.2.2法律法规及技术标准：局质量管理部和总工办分别负责建立全局的《法律法规清单》和《技术标准有效版本目录清单》，各部门、单位、项目部需要从中识别出符合自身工作需求的法律法规和技术标准，并综合其他途径获取的相关规定和标准来建立本部门、单位、项目部的《法律法规清单》和《技术标准有效版本目录清单》。 4.2.3工程文件：项目部要做好文件的编制、审批、发放、落实。需要归档的在工程结束后按照工程档案管理要求随竣工资料入档管理。未入档的有价值的文件、记录资料应由项目所辖单位自行保管至其没有使用价值为止。 4.2.4文件标识应保持唯一性，可以是编号或其他方式，如利用计算机进行管理记录，应按系统软件的要求或相应规定录入。 4.2.5当我局的组织结构、操作流程等发生改变或适用的法律法规和标准发生变化时，应对原文件重新进行评审、修改、批准，并保留评审记录。 4.3文件的收发过程中要做好收发文记录。发文时不能只发放到中层领导为止，要做到下沉一级，使有需要人员均能获得相应文件。 4.4文件的修订 4.4.1《管理手册》由质量管理部进行修订，经管理者代表审核，局长批准；管理制度的修订由原编制部门负责，管理者代表批准。文件修订时应由提出修订要求的人员填写《文件更改审批表》，说明更改理由，按原审批程序进行文件更改的审批。 4.4.2法律法规和技术标准如有最新版本，各部门应及时更新。
【最新资料,Word版，可自由编辑！】
目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (4) 2.技术过程规范部分 (4) 2.1 概述 (4) 2.2 业务建模阶段 (4) 2.3 需求阶段 (6) 2.4 分析设计阶段 (8) 2.5 实现阶段 (10) 3.管理过程规范部分 (11) 3.1 概述 (11) 3.2 接受项目 (12) 3.3 重新评估项目范围和风险（对于较大项目） (12) 3.4 制定开发计划 (13) 3.5 迭代开发管理 (13) 3.6 监控项目的实施 (14) 3.7 结束项目 (15)
软件开发过程规范 前言 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。
附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 ）详细设计说明
研发系统文件管理规范 1目的 建立并执行研发系统文件要求和管理的规定，确保研发系统文件管理工作规范、统一、有效，符合公司文件管理程序要求。 2适用范围 适用于研发系统开发文档、技术文件、程序文件、管理工作文件、指南文件的管理。 3术语和定义 无。 4职责与权限 研发管理部负责产品开发文档、技术文档、管理工作文件、指南文件及其它文件的归口管理，研发系统相关部门配合。 5内容及流程 研发系统文件包括产品开发文档、技术文档、程序文件、管理工作文件、指南文件及其它文件等。结构如下图：
研发系统文件编号及版本参考《研发系统文件编号及版本规定》。 5.1研发系统管理文件 5.1.1管理工作文件及指南文件的编写、审核、批准 5.1.1.1研发系统程序文件、管理工作文件、指南文件由技术委员会依据质量体系要求，规划研 发系统程序文件及各级工作文件，研发管理组织相关部门编写，文件编号由编写者向质管QA助理申请。编写需使用公司统一的文件模板。程序文件、管理工作文件经研发系统内部预审后，提交质管部按组织公司涉及部门评审、会签，文件经管理者代表批准后在OA上发布生效。 5.1.1.2研发系统级指南文件由研发管理部组织评审，各产品线及部门级指南文件由编写人所在 部门技术秘书负责组织评审。指南文件提交文件编写者主管部门经理审核，部门所属产品线负责人批准，研发管理部发布生效。生效后的文件电子档抄送质管部及相关部门备案。 5.1.2管理工作文件及指南文件的更改、升版 5.1.2.1程序文件、管理工作文件的更改及升版按《管理工作文件的控制办法》执行。 5.1.2.2研发指南文件的更改升版，由编写人提前知会研发管理部后进行，升版后文件按首版评 审方式审核、批准发布。 5.1.3程序文件、管理工作文件及指南文件的发布生效方式及文件共享路径 5.1.3.1管理工作文件的生效发布由质管部在公司OA-办公系统的通知栏内进行发布；工作指南 文件由研发管理部通过QQ信息发布，同时在研发系统信息平台http://vss2/default.aspx 发布备查。 5.1.3.2程序文件、管理工作文件及工作指南文件在以下路径电子文件共享：\\VSS2\研发管理\工 作文件。 5.2技术文件 产品技术文件分设计文件及工艺文件以及支持产品生产、检验的工装夹具、设备仪器文件。根据项目研发现状，我们对技术文件分别进行研发过程的受控管理及样机文件（开发样机、工程样机）质管受控管理。 5.2.1研发过程技术文件管理控制 5.2.1.1分类 研发过程技术文件分机械类过程技术文件和硬件板卡过程技术文件，其中： 机械类过程技术文件：机械零件图（C类）；
文档编号：_________ _________ 文档名称：____________ 项目名称：____________ 项目负责人：____________ 编写：___________ ____年__月__日 校对：___________ ____年__月__日 审核：___________ ____年__月__日 批准：___________ ____年__月__日
开发单位：传讯网络信息 ________________________ 系统规格说明 一、系统功能和目标： 随着因特网的不断普及，国的用户数呈指数级增长。作为因特网最为常用的电子系统越来越受到人们的喜爱，为了满足不断增长的信息交换的需要，各行各业都希望有自己的系统。传讯网络信息自主设计开发了适合中国国情的免费电子系统，用以解决这一日益突出的问题。CHINATION 免费电子系统是专为免费电子服务商、企业集团设计的电子系统。 Chination免费电子系统的设计目标是立足于一个高度集成的、功能强大、技术先进的电子系统。高度集成意味着本系统将把硬盘软件集成在一起。系统是基于LINUX下的，硬盘和软件的集成使得系统具有绝对的安装优势。功能强大意味着系统的实用性，功能的全面性，系统的安全性和可靠性。技术先进意味着将最新版本的LDAP，IMAP，POSTFIX，MYSQL，APACHE和PHP的巧妙结合。 本系统要实现的主要功能有：
1．用户申请注册功能。用户通过申请可以得到一个自己命名的信箱，容量大小为10M。 2．用户忘记密码处理功能。用户忘记密码可以通过注册时设置的密码提示问题来重设密码。 3．用户收功能。它包括SMTP收、POP3取和WWW读三种方式。 4．用户发功能。它包括SMTP发、WWW直接发送、暗送、抄送、定时发送。 5．用户信件处理功能。系统初始设置4个文件夹来分类处理信件：收件箱、发件箱、草稿箱和垃圾箱。用户还可以自己建立新的文件夹。信件在各个信箱之间可以相互移动。 6．用户查找功能。用户可以使用查找功能通过查找信件主题或信件容来找到自己需要的信件。 7．用户信箱配置设置。它包括个人资料更改、密码更改、参数设置、POP3服务器设置、过滤器设置、自动转信、定时发信、签名设置。 8．管理员管理用户和信箱功能。包括输入（增删改）、查询、统计、报表。系统性能参数设置。 9．广播功能。它用于公司定期向一定的用户发送信息，由于一般的用户数有一定数量，所以必须用数据库管。 二、可行性分析 1．技术可行性 本软件拟决定最终在分布式系统上来运行。硬件方面，由于传讯网络信息是国外多家公司并行处理产品的代理商，而且自己本身拥有ALPHA机等先进设备，所以有足够能力开发出先进的电子系统。软件方面，我们拟采用以下几种软件： 1）操作系统用LINUX。Linux作为一个优秀的网络操作系统，它的发行版本中集成了大量的网络应用软件，如Web服务器(apache)、Ftp服务器(wu-ftp)、服务器(sendmail+imap4)、SQL数据库(postgresql)等，可以快速的构建Intranet环境，并且也有精致的收发程序(metamail)和强大的Web 服务器端开发工具(PHP4)。当你配置好sendmail并激活imapd后，你的Linux用户都可以使用Outlook等客户端软件进行收发，只要通过将它们集中进行应用，便可以实现一个简单的Webmail 服务器的功能。但是随着自由软件的不断开发，要构架一个好的电子系统，就面临着软件选择是否适当、性能是否比别人好的问题。下面列出我们所使用的软件。 2）本系统壳软件用imap。有几种方法可以构造电子系统的壳：共享文件系统的策略，基于局域网的专用协议，X.400P7协议和因特网消息存取协议。而基于INTERNET的协议主要有：POP (Post Office Protocol), DMSP (Distributed Mail System Protocol), 和IMAP (Internet Message Access Protocol).POP是最原始，最为人们所知的一种。DMSP仅局限于一个简单应用——PCMAIL，它的优点主要在于对脱机状态操作的支持。IMAP不但继承了POP和DMSP的优点，而且超越了他们的缺点，提供了三种状态下对远程信箱的访问：在线、不连接和脱机状态。在脱机状态，可以发送到一个共享的服务器，但是客户并不是马上全部把它们COPY过去之后在服务器上删掉它们，
1、需求分析是怎样做的？（自己理解着说） 需求分析是构建软件系统的一个重要过程。 一般，把需求类型分成三个类型： 1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。 2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。 3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。 4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。 客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。 总结： 良好的需求分析是软件成功的基础。以上是作者对需求分析工作实践的一次小结以及综合性的思考，是对需求分析本身所做的一次分析。在此基础上，作者提出了逆向沟通的设想，即系统分析员主动进行沟通，提出指导性意见。当软件融合了客户和系统分析员双方智慧，其质量将会进一步得以提高。 2、 6周 （比较合理的代码行数是多少，如果多了，我是怎么切割的）500行，例如：实现数据3、如何将用户登录的信息保存？ 用户登陆页面将每个用户的信息使用session保存下来,例如: session.setAttribute("UserID","ytang"); 如果用到用户的登陆信息，再从session根据session.getAttribute("userID")所存储的信息例如在项目1中的应用 4．软件项目开发流程应该是什么样子的？ 1。需求分析和获取； 2。界面的设计和修改，直到用户可以接受； 3。后台数据库的建立，做成几张表，写几个存储过程； 4。前台模块的编写和调试； 5。项目的实施和维护；
技术文件管理制度
技术文件管理制度 一、目的 为保持已有技术工艺文件的完整性，统一技术文件的管理标准，确保所编制和管理的技术文件是正确、有效和一致的；有效控制技术文件，使之能完全指导生产，以保证质量和生产正常进行，避免混乱，为使公司的技术文件得到有效的控制，确保生产现场所用的技术文件为最新有效版本。根据公司的实际情况，特制定本制度。 二、适用范围 本制度适用于公司所涉及到的所有技术文件，包括：设计文件、产品图样、工艺图样和工艺文件等技术文件，也包括一定范围的外来标准和客户提供的图样等。 三、职权和职责 1.技术研发中心技术部是技术文件的归口管理部门，负责技术文件的编制、审核，并负责所有技术文件编号、发放、回收、归档，以及文件更改、作废的处理。 2.技术文件的编制和管理；技术研发中心技术部负责人负责编制，技术研发中心总监审核，由总经理批准。 3.生产用工艺文件，如工艺路线单、工序卡、过程卡、工艺图纸、作业指导书，由制造中心各生产部专人编制，完成后送技术研发中心技术部负责人审核，由技术研发中心总监批准。 4.外来图样、标准由负责人识别、核对，经技术研发中心总监审核报总经理批准。 四、管理标准和管理要求 1.技术文件是公司的核心机密，是公司进行生产和管理工作共同的依据，是公司在同行中保持一定竞争力的有力保障。公司的技术文件属于公司所有，每一位员工都有义务和责任保证技术文件的完整性、一致性以及保密性。 2.技术文件的定义 技术文件是指公司的产品设计图纸、工艺文件，操作规范、客户提供的图纸图样、各种技术标准、技术通知以及技术培训资料等。 3.技术文件包括：设计文件、结构：或生产；图纸、产品图样、工艺文件、技术标准、外来标准和图样，生产设备操作规程等。 4.技术文件管理包括：技术文件发放、复制借阅、修改、重新发放、收回、作废、外来文件的识别和使用等。 5.技术文件的分类
软件开发文档模板 1 可行性研究报告 可行性研究报告的编写目的是：说明该软件开发项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能先择的各种方案；说明论证所选定的方案。可行性研究报告的编写内容要求如下： 1.1 引言 1.1.1 编写目的 1.1.2 背景 1.1.3 定义 1.1.4 参考资料 1.2 可行性研究的前提 1.2.1 要求 1.2.2 目标 1.2.3 条件、假定和限制 1.2.4 进行可行性研究的方法 1.2.5 评价尺度 1.3 对现有系统的分析 1.3.1 数据流程和处理流程 1.3.2 工作负荷 1.3.3 费用开支 1.3.4 人员 1.3.5 设备 1.3.6 局限性 1.4 所建议的系统 1.4.1 对所建议系统的说明 1.4.2 数据流程各处理流程 1.4.3 改进之处 1.4.4 影响 1.4.4.1 对象设备的影响 1.4.4.2 对软件的影响 1.4.4.3 对用户单位机构的影响 1.4.4.4 对系统动行的影响 1.4.4.5 对开发的影响 1.4.4.6 对地点和设施的影响 1.4.4.7 对经费开支的影响 1.4.5 局限性 1.4.6 技术条件方面的可行性 1.5 可选择其他系统方案 1.5.1 可选择的系统方案 1 1.5.2 可选择的系统方案 2 …… 1.6 投资及收益分析 1.6.1 支出 1.6.1.1 基本建设投资
1.6.1.2 其他一次性支出 1.6.1.3 非一次性支出 1.6.2 收益 1.6. 2.1 一次性收益 1.6. 2.2 非一次性收益 1.6. 2.3 不可定量的收益 1.6.3 收益/投资比 1.6.4 投资回收周期 1.6.5 敏感性分析 1.7 社会条件方面的可行性 1.7.1 法律方面的可行性 1.7.2 使用方面的可行性 1.8 结论 2 项目开发计划 编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度所需经费预算、所需软、硬件条件等问题作出安排记载下来，以便根据本计划开展和检查本项目的开发工作。编制内容要求如下： 2.1 引言 2.1.1 编写目的 2.1.2 背景 2.1.3 定义 2.1.4 参考资料 2.2 项目概述 2.2.1 工作内容 2.2.2 主要参加人员 2.2.3 产品及成果 2.2. 3.1 程序 2.2. 3.2 文件 2.2. 3.3 服务 2.2. 3.4 非移交产品 2.2.4 验收标准 2.2.5 完成项目的最迟期限 2.2.6 本计划的审查者与批准者 2.3 实施总计划 2.3.1 工作任务的分解 2.3.2 接口人员 2.3.3 进度 2.3.4 预算 2.3.5 关键问题 2.4 支持条件 2.4.1 计算机系统支持 2.4.2 需要用户承担的工作 2.4.3 需由外单位提供的条件 2.5 专题计划要点
标准的软件开发过程 软件开发的标准过程包括六个阶段，而六个阶段需要编写的各类文件达14种之多，在每个阶段需要编写哪些文件，以及这些文件的主要内容见下： 1.可行性与计划研究阶段 可行性研究报告：在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。 项目开发计划：编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开发工作。 2.需求分析阶段 软件需求说明书：软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。内容包括对功能的规定对性能的规定等。 数据要求说明书：数据要求说明书的编制目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。 初步的用户手册：用户手册的编制是要使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。使用户（或潜在用户）通过本手册能够了解该软件的用途，并且能够确定在什么情况下，如何使用它。 3.设计阶段 概要设计说明书：概要设计说明书又可称系统设计说明书，这里所说的系统是指程序系统。 编制的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计。运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
详细设计说明书：详细设计说明书又可称程序设计说明书。编制目的是说明一个软件系统各个层次中的每一个程序（每个模块或子程序）的设计考虑，如果一个软件系统比较简单，层次很少，本文件可以不单独编写，有关内容合并入概要设计说明书。 数据库设计说明书：数据库设计说明书的编制目的是对于设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。 测试计划初稿：这里所说的测试，主要是指整个程序系统的组装测试和确认测试。本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。4.实现阶段 模块开发卷宗（开始编写）：模块开发卷宗是在模块开发过程中逐步编写出来的，每完成一个模块或一组密切相关的模块的复审时编写一份，应该把所有的模块开发卷宗汇集在一起。 编写的目的是记录和汇总低层次开发的进度和结果，以便于对整个模块开发工作的管理和复审，并为将来的维护提供非常有用的技术信息。 用户手册完工 操作手册：操作手册的编制是为了向操作人员提供该软件每一个运行的具体过程和有关知识，包括操作方法的细节。 测试计划终稿： 5.测试阶段 模块开发卷宗(此阶段内必须完成) 测试分析报告：测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。 项目开发总结报告：项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。
武汉新英赛研发管理 第一节 软件研发岗位职责 一、软件研发部经理岗位职责 软件研发部经理在总经理或主管副总的领导下, 全面负责软件研发部的日常管理， 组织 开展软件研发与测试工作，完成企业研发目标和经营目标。其具体职责如表 二、高级研发工程师岗位职责 高级研发工程师参与建立研发工作标准与规范，协助部门经理组织完成软件研发工作, 管理软件研发项目，改良升级进行软件。其具体职责如表 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.文件领用者，因文件丢失或者损坏需要领用新文件时，到行政部填写《文件处理单》，经常务副总审核、批准后方可领用。 4.文件管理者、文件持有者要派专人管理文件，并保持文字清晰，外来借阅者需填写《文件借阅登记表》，经常务总经理批准后方可借阅。 5.作废文件销毁时，由该部门填写《文件处理单》，由总经理审核、批准后统一销毁。需要留用的加盖“作废留用章”后方可保留。 6.质量记录的格式和内容由使用部门设计，行政管理部门审查批准，统一编号控制。质量记录表需要更改时，仍由原审批部门审批。
7.质量记录填写：要求个部门质量记录填写人员在填写时要及时、完整、自己清楚、数据准确、使用中性笔或者圆珠笔笔填写。质量记录原则上不准更改，如有失误或者计算错误时，在改动处划改并签名。 8.质量记录的`借阅：外来人员借阅质量记录经常务副总批准后办理借阅手续借阅，公司人员经行政部部长批准后，办理借阅手续。 9.质量记录的管理和保存：质量记录由本部门制定专人负责保管，注意防潮、防腐、防盗、防火、防蛀、保存期按《质量记录清单》的要求实施。 10.各类质量记录由各部门指定专人手机、分类并装订，行政部负责归档并规定期限保存。 11.质量记录销毁：对于超过保存期的质量记录，由行政部和使用部门负责签字，包常务副总审核批准后，进行销毁并填写《质量记录销毁清单》，需要保留的记录加盖“作废保留”章后由行政部统一保存。
开发文档介绍 软件开发文档是软件开发使用和维护过程中的必备资料。它能提高软件开发的效率，保证软件的质量，而且在软件的使用过程中有指导，帮助，解惑的作用，尤其在维护工作中，文档是不可或缺的资料。 软件文档可以分为开发文档和产品文档两大类。 开发文档包括：《功能要求》、《投标方案》、《需求分析》、《技术分析》、《系统分析》、《数据库文档》、《功能函数文档》、《界面文档》、《编译手册》、《QA 文档》、《项目总结》等。产品文档包括：《产品简介》、《产品演示》、《疑问解答》、《功能介绍》、《技术白皮书》、《评测报告》。用户文档《安装手册》、《使用手册》、《维护手册》、《用户报告》、《销售培训》等。 开发文档 1. 《功能要求》-- 来源于客户要求和市场调查，是软件开发中最早期的一个环节。 客户提出一个模糊的功能概念，或者要求解决一个实际问题，或者参照同类软件的一个功能。有软件经验的客户还会提供比较详细的技术规范书，把他们的要求全部列表书写在文档中，必要时加以图表解说。这份文档是需求分析的基础。 2. 《投标方案》-- 根据用户的功能要求，经过与招标方沟通和确认，技术人员开 始书写《投标方案》，方案书一般包括以下几个重要的章节：前言-- 项目背景、公司背景和业务、技术人员结构、公司的成功案例介绍等。需求分析-- 项目要求、软件结构、功能列表、功能描述、注意事项等。技术方案-- 总体要求和指导思想、技术解决方案、软件开发平台、网络结构体系等。项目管理-- 描述公司的软件开发流程、工程实施服务、组织和人员分工、开发进度控制、软件质量保证、项目验收和人员培训、软件资料文档等。技术支持-- 公司的技术支持和服务介绍、服务宗旨和目标、服务级别和响应时间、技术服务区域、技术服务期限、授权用户联系人等。系统报价-- 软、硬件平台报价列表、软件开发费用、系统维护费用等。项目进度-- 整个项目的进度计划，包括签署合同、项目启动、需求分析、系统分析、程序开发、测试维护、系统集成、用户验收、用户培训等步骤的时间规划。 3. 《需求分析》-- 包括产品概述、主要概念、操作流程、功能列表和解说、注意 事项、系统环境等。以《功能要求》为基础，进行详细的功能分析( 包括客户提出的要求和根据开发经验建议的功能) ，列出本产品是什么，有什么特殊的概念，包括哪些功能分类，需要具备什么功能，该功能的操作如何，实现的时候该注意什么细节，客户有什么要求，系统运行环境的要求等。这里的功能描述跟以后的使用手册是一致的。 4. 《技术分析》-- 包括技术选型、技术比较、开发人员、关键技术问题的解决、 技术风险、技术升级方向、技术方案评价，竞争对手技术分析等。以《需求分析》为基础，进行详细的技术分析( 产品的性能和实现方法) ，列出本项目需要使用什么技术方案，为什么，有哪些技术问题要解决，估计开发期间会碰到什么困难，技术方案以后如何升级，对本项目的技术有什么评价等。 5. 《系统分析》-- 包括功能实现、模块组成、功能流程图、函数接口、数据字典、 软件开发需要考虑的各种问题等。以《需求分析》为基础，进行详细的系统分析( 产
软件开发与维护管理规范 1 目的通过规范软件的开发与维护过程，达到提高软件质量，降低维护成本的目的。 2 范围适用于新产品的软件开发设计以及定型产品的改进升级。 3 职责与权限 研发中心负责： a)编制软件开发过程的实施、协调和控制工作； b)编制各阶段的技术文件； c)组织软件的测试、验收、升级和维护工作。 各部门参与软件开发过程中有关的设计评审。 4 内容 软件项目的开发实施过程管理要求 软件项目实施过程总体要求 本部分主要要求工程师制定软件开发工作计划，对过程进行控制，一般包括以下的内容。a) 工程师提交软件开发工作大纲，项目组织者对工作大纲进行评审，并提出整改意见。 b)通过评审后，工程师根据整改意见完善工作大纲，经过项目经理认可后组织项目组进行 软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行，在开发过程中，工程师需分阶段提交相关文档。 c)在软件开发工作完成后，工程师应向项目组提交完整的软件文档，相关人员组织验收组对软件进行验收审查。 软件项目实施变更要求在开发过程中，需求或设计不可避免地需要发生变更，相关变更必须提交《软件变更申请》经过项目组书面同意方可进行。在需求或设计发生变更时，需要对原有文档进行修改，并提供完整的变更记录，以使变更处于可控制的状态。 软件项目实施里程碑控制本部分主要对软件开发过程中的重要节点进行控制。项目组将分四个阶段进行把关，召开审查会。 a）需求分析（结合原型进行审查）确认；
b）概要设计+数据库设计； c）预验收（样机测试时）； d）正式验收（产品定型后）。 软件开发 软件开发必须严格按照软件工程的要求进行。开发过程包括工程师的活动和任务。此过程由软件需求分析、概要设计、详细设计、编码、测试、验收、鉴定等活动组成。 软件的需求分析 需求分析 需求分析要求开发人员准确理解用户的需求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约《软件需求规格说明书》的过程。 在《软件需求规格说明书》必须描述的基本问题是：功能、性能、强加于实现的设计限制、属性、外部接口。 需求报告评审在软件需求分析工作完成后，软件工程师应向项目组提交《软件需求规格说明书》。项目组组织有关人员（系统客户和系统开发人员等）对需求进行评审，以决定软件需求是否完善和恰当。项目组严格验证这些需求的正确性，一般从一致性，完整性，现实性，有效性四个方面进行验证。评审完成后，就可以进入软件的设计阶段。 软件的概要设计 概要设计 概要设计也称为系统设计，需要确定软件的总体结构，应该由哪些模块组成，以及模块与模块之间的接口关系，软件系统主要的数据结构和出错处理设计等，同时还要制定测试方案，形成概要设计说明书，为软件的详细设计提供基础。在概要设计时一般从以下几方面来考虑，遵循以下的流程。 概要设计和需求分析、详细设计之间的关系和区别需求分析不涉及具体的技术实现，而概要设计注重于从宏观上和框架上来描述采用何种技术手段、方法来实现这些需求。详细设计相对概要设计更注重于微观上和框架内的设计，是编码的依据。概要设计是指导详细设计的依据。 概要设计的评审 在软件概要设计工作完成后，软件工程师应向项目组提交《软件概要设计》。评审通过后，即可进入详细设
软件开发文档模板库 1 可行性研究报告 可行性研究报告的编写目的是：说明该软件开发项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能先择的各种方案；说明论证所选定的方案。 可行性研究报告的编写内容要求如下： 1.1 引言 1.1.1 编写目的 1.1.2 背景 1.1.3 定义 1.1.4 参考资料 1.2 可行性研究的前提 1.2.1 要求 1.2.2 目标 1.2.3 条件、假定和限制 1.2.4 进行可行性研究的方法 1.2.5 评价尺度 1.3 对现有系统的分析 1.3.1 数据流程和处理流程 1.3.2 工作负荷 1.3.3 费用开支 1.3.4 人员 1.3.5 设备 1.3.6 局限性 1.4 所建议的系统 1.4.1 对所建议系统的说明 1.4.2 数据流程各处理流程 1.4.3 改进之处 1.4.4 影响 1.4.4.1 对象设备的影响 1.4.4.2 对软件的影响 1.4.4.3 对用户单位机构的影响 1.4.4.4 对系统动行的影响 1.4.4.5 对开发的影响 1.4.4.6 对地点和设施的影响 1.4.4.7 对经费开支的影响 1.4.5 局限性 1.4.6 技术条件方面的可行性 1.5 可选择其他系统方案 1.5.1 可选择的系统方案1
1.5.2 可选择的系统方案2 …… 1.6 投资及收益分析 1.6.1 支出 1.6.1.1 基本建设投资 1.6.1.2 其他一次性支出 1.6.1.3 非一次性支出 1.6.2 收益 1.6. 2.1 一次性收益 1.6. 2.2 非一次性收益 1.6. 2.3 不可定量的收益 1.6.3 收益/投资比 1.6.4 投资回收周期 1.6.5 敏感性分析 1.7 社会条件方面的可行性 1.7.1 法律方面的可行性 1.7.2 使用方面的可行性 1.8 结论 2 项目开发计划 编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度所需经费预算、所需软、硬件条件等问题作出安排记载下来，以便根据本计划开展和检查本项目的开发工作。编制内容要求如下： 2.1 引言 2.1.1 编写目的 2.1.2 背景 2.1.3 定义 2.1.4 参考资料 2.2 项目概述 2.2.1 工作内容 2.2.2 主要参加人员 2.2.3 产品及成果 2.2. 3.1 程序 2.2. 3.2 文件 2.2. 3.3 服务 2.2. 3.4 非移交产品 2.2.4 验收标准 2.2.5 完成项目的最迟期限 2.2.6 本计划的审查者与批准者 2.3 实施总计划 2.3.1 工作任务的分解 2.3.2 接口人员 2.3.3 进度 2.3.4 预算 2.3.5 关键问题
软件项目开发和管理规范 本文阐述软件项目开发和管理的流程规范，作为软件项目开发的高级指引，本规范定义了软件开发的各个阶段以及每个阶段的工作活动和工件，但不对活动和工件的细节作过多规定。在项目开发过程中，每个项目根据自身的需要确定这些活动和工件的细节。 项目阶段 图2-1 项目开发的五个阶段 ?启动阶段 这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结项目工作的范围、所需资源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。 ?计划阶段 这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。 ?执行阶段
这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。 ?控制阶段 这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题，如：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。 ?结束阶段 这个阶段的工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。 阶段完成标志 在项目开发过程中，当一个阶段完成后才会开展下一个阶段的工作；另外，“某个阶段完成”通常被定义为项目的一个里程碑，里程碑标识了项目的进度，它是项目开发和控制的重要参考，对整个项目有重要的意义。因此，“确证某个阶段是否已经完成”的工作非常有重要。 ?每一个阶段的结束以它特定任务的完成为象征 只有当某个阶段中被规定的所有工作任务都完成了，这个阶段才算真正结束，整个项目才可以进入到下一个阶段中去。反过来说，要是阶段中某个任务没有全部完成，按照项目的定义，整个阶段就不能算是完成，因此项目就不能进入到下一个阶段去。 ?衡量阶段结束的工作结果必须是实在的交付品 阶段中的任务是否完成是透过任务活动中产生的交付品来体现的，交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如：某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束，都应该有这样的实质性东西的完成作为象征。 ?跨阶段的进程以阶段结尾的合格验证和审核来决定 当一个阶段结束时，在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证，并检查这一阶段的工作质量和效率，由此判断是否可以进入到下一个阶段。这些检验象征了一个阶段的结尾终点，表示项目的进程离开了上一个阶段而进入了下一个阶段。