请高人给出做系统分析的格式,从可行性研究到需求分析再到......各位系统分析员请指点100相送 (100分)

  • 主题发起人 主题发起人 zhilon
  • 开始时间 开始时间
hbezwwl:
给我也发一个
谢谢
 
这么多人要想呀,hbezwwl兄一定很辛苦的。我看干脆上传到playicq上吧。
micro@west163.com
 
我也想要。
kundyonline@163.com
 
谁有GB8567-88 国标的相关件啊,各位?
 
hbezwwl:
谢谢!我也一份!
fancy1004@eyou.com
 
也给我发一封啊!!多谢
del10192eyou.com
 
hbezwwl:
请给我发一份,非常感谢。
chinahklq@sina.com
 
如果大家到www.csdn.com在那里的论坛里专门有关于文档格式的专栏!自己随便看吧![:D]
 
http://www.21swe.com/rjwd/glwh.htm
都在这里了,国家标准。
 
软件需求说明书
来源: 自国家计算机标准和文件模板 作者:
  软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解, 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下:

1 引言
1.1编写目的
  说明编写这份软件需求说明书的目的,指出预期的读者。

1.2背景
  说明:
  a.待开发的软件系统的名称;
  b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;
  C.该软件系统同其他系统或其他机构的基本的相互来往关系。

1.3定义
  列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料
  列出用得着的参考资料,如:
  a.本项目的经核准的计划任务书或合同、上级机关的批文;
  b.属于本项目的其他已发表的文件;
  c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
2 任务概述

2.1目标
  叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|

2.2用户的特点
  列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束

2.3假定和约束
  列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。
3 需求规定

3.1对功能的规定
  用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行操作的用户数。

3.2对性能的规定
3.2.1精度
  说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
3.2.2时间特性要求
  说明对于该软件的时间特性要求,如对:
  a.响应时间;
  b.更新处理时间;
  c.数据的转换和传送时间;
  d.解题时间; 等的要求。
3.2.3灵活性
  说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:
  a.操作方式上的变化;
  b.运行环境的变化;
  c.同其他软件的接口的变化;
  d.精度和有效时限的变化;
  e.计划的变化或改进。
  对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

3.3输人输出要求
  解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。

3.4数据管理能力要求
  说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。

3.5故障处理要求
  列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

3.6其他专门要求
  如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4 运行环境规定

4.1设备
  列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:
  a.处理器型号及内存容量;
  b.外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;
  c.输入及输出设备的型号和数量,联机或脱机;
  d.数据通信设备的型号和数量;
  e.功能键及其他专用硬件

4.2支持软件
  列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等。

4.3 接口
  说明该软件同其他软件之间的接口、数据通信协议等。

4.4控制
  说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源。

 
软件工程是死的,可我们的大脑,我们开发的项目是活的,
大家在学习一些理论的同时多多思考,多多实践
关键要把结构理清楚
 
hbezwwl:
我也要一份
lyaip@etang.com
 
我有更详细的:
For Example;









项目名: XXXXXXXXXXXX
文档名: 项目管理计划
文档号: S-XXXX-PM-1001-V1.0/0001






编写者:
核审者:
批准者:
归档日期:

分 发 表
单 位 姓 名 份数 备 注



































修 订 表
版本号 发布日期 修改页号 备 注
1.0 始建

































目 录
1 概述 1
1.1 本文档的编写目的 1
1.2 标识 1
1.2.1 文档标识 1
1.2.2 缩略语和术语 1
1.3 与其它文档的关系 1
1.4 参考资料 1
2 项目管理 2
2.1 标准化的重要性 2
2.2 总体要求 2
2.3 项目分解 2
2.4 项目控制 3
3 人员配置 4
4 进度控制 4
5 文档管理 5
5.1 文档的类型 5
5.2 文档的组织 6
5.3 文档的版本号 6
5.4 文档的标识 7
5.5 文档的编写模板 7
5.6 关于《技术说明》 8
5.7 文档的控制 8
6 代码管理 9
6.1 注释规范 9
6.2 命名规范 10
6.3 编码规范 10
6.4 界面规范 12
6.5 代码包规范 12
6.5.1 代码包的版本号 12
6.5.2 代码包的标识 12
6.6 代码的控制 13
[图表目录]
表2.3 会议记录的格式 3
图3 项目的人员配置 4
表4 月度报告的格式 5
图5.2 项目的文档树 6
表5.3 项目的文档分类表 7
表6.5.2 项目的代码包分类表 13

1 概述
1.1 本文档的编写目的
本文档的适用对象是:XXXXXXXXXXXX系列之所有软件。
编写本文档的目的是说明:
1) 本项目的特点及其在项目管理上的特殊要求。
2) 贯穿项目开发全过程的管理体系,包括以下内容的原则或策略:项目分解、项目控制、人员配置、进度控制、文档管理、代码管理。
本文档是:
1) 编制XXXXXXXX所有软件开发过程中各阶段文档的依据之一。
2) 实施XXXXXXXX所有软件开发过程中各阶段活动的依据之一。
1.2 标识
1.2.1 文档标识
文档被批准的标识号为:
“S-XXXX-PM-1001-V1.0/0001”
文档的正式标题为:
XXXXXXXXXXXX
项目管理计划
1.2.2 缩略语和术语
文档中的缩略语和术语有:
1.3 与其它文档的关系
本文档是XXXXXXXXXXXX系列之所有文档的编制依据。
1.4 参考资料
[1] 94年版国际(ISO)质量管理和质量保证标准译文集─最新ISO 9000,中国电子技术标准研究所、中国电子质量体系认证中心,1994.10
2 项目管理
2.1 标准化的重要性
当一个项目遵守公用的标准时,会有以下优点:
1) 每个参与者可以了解关于项目的任何文档和代码,清楚项目的进度和技术状态。
2) 新人可以很快的适应环境。
3) 防止新接触项目的人出于节省时间的需要,自创一套风格自行其事。
4) 防止新接触项目的人一次次的犯同样的错误。
5) 在一致的环境下,人们可以减少犯错的机会。
6) 所有参与者有了一致的目标。
当然,遵循标准也有缺点:
1) 制定标准的人并不能清楚每一件事,所以标准通常是有缺陷的。
2) 标准并不能与每一个参与者的想法都一致。
3) 标准降低了创造力。
4) 标准强迫太多的格式和形式。
2.2 总体要求
XXXXXXXXXXXX系列具有以下特点:
1)
因此,对本项目的管理也有如下特点:
1)
2.3 项目分解
项目分解是从整体上明确和划分工作内容,目的是为制订项目进度和分配项目资源(人员/时间/物资)提供依据。
本项目的分解原则为:
1) 本项目将被分解为多个开发任务,如
2) 所有XXXX涉及到公共功能(如 )将被定义为独立开发任务。
3) 每个开发任务都将分解为多个开发阶段:项目规划、需求分析、软件设计、编码与测试、包装与培训。在每个开发任务的《软件开发计划》中将分别定义该任务在进度和人员方面的安排。
4) 每个开发阶段都将分解为多个开发活动:计划、分配、实施、交流(包括汇报、评估、检验、认可)。这些开发活动应遵循本项目的整体要求。
本项目的开发任务将在《项目开发计划》中予以具体定义。
2.4 项目控制
对于每个开发任务,项目小组都将实施以下控制手段:
1) 规范。本文档明确定义了整个项目应遵循的规范和标准,在每个任务开始和过程中,要求每个参与者都阅读、理解和应用。
2) 交流。项目的进度和技术状态将用会议和报告等方式进行检查、控制和监督,即:
(1) 周会。每周五组织一次正式会议,由任务的所有参与者参加,会议内容包括:任务进度和技术状态;需要解决和讨论的问题;本周遗留问题和下周工作安排;短期目标和其它一般信息的交流。任务的负责人应作会议记录。
(2) 月会。每月最后一个周五组织一次月会(与此时的周会合并),有整个项目组所有成员参加,会议内容包括:项目进度和技术状态;需要解决和讨论的问题;确定下月的目标。项目负责人应作会议记录。
(3) 临时技术会议。如果需要,任何任务参与者均可请求本任务组或整个项目组召开技术会议,以解决临时遇到的技术问题。
(4) 报告。每个任务的负责人每月月会后整理本任务的进度和技术状态,以邮件的方式发送给本任务的每个参与者和项目负责人;项目负责人每月月会后整理整个项目的进度和技术状态,以邮件的方式发送给本项目的每个参与者和上级管理者。
3) 配置管理。本项目定义专门的配置管理员角色,来统一管理本项目涉及到的所有文档和代码。
表2.3是一个会议记录的示例。
表2.3 会议记录的格式
编号 2001-9-5-S-XXXX 会议类别 任务周会(或项目月会)
项目名称 XXXXXXXXXXXX 任务名称 XXXXXXXX
与会者
填写日期 2001 年 9 月 5 日 填写人
分发对象
会议记录:
备注:
3 人员配置
当软件项目别分解以后,对人员进行配置时可采用两种策略:
1) 横向配置。对软件项目分解出的同一类活动,指定人员来专门实施。如,对项目中所有任务,一些人员专门进行项目规划和需求分析,一些人员专门设计和编码,一些人专门测试,一些人专门编写文档,等等。
2) 纵向配置。对软件项目分解出每个任务,分别指定不同的人员来完整实施所有活动。如,一些人员实施邮件XXXX的所有开发活动,一些人员实施日志XXXX的所有开发活动,等等。
本项目的适合用 配置策略,原因如下:
1)
本项目的人员配置如图3所示。
图3 项目的人员配置







需要说明的是,以上只是角色的定义,一个实际的开发者可能充当其中的多个角色。
本项目的人员配置将在《项目开发计划》中予以具体定义,每个任务的人员配置将在相应的《软件开发计划》中具体定义。
4 进度控制
在不同的粒度上,存在进度控制:
1) 项目的进度控制。由项目负责人实施。实施手段包括:制订项目计划、组织月会、整理《项目月度报告》。
2) 任务的进度控制。由任务负责人实施。实施手段包括:制订任务计划、组织周会、整理《任务周进度报告》。任务的进度控制以项目的进度控制为前提。
3) 阶段的进度控制。由活动的实践者实施。实施手段包括:遵循任务计划、参加周会。阶段的进度控制以任务的进度控制为前提
表格4是一个月度报告的示例。(周进度报告具有相同格式)
表4 月度报告的格式
编号 2001-9-S-XXXX
项目名称 XXXXXXXXXXXX 任务名称 XXXXXXXX
项目负责人 任务负责人
填写日期 2001 年 9 月 28 日 报告日期 2001 年 9 月 30 日
本月进度与状态:(注:O=Open ;P=Progressing ;C=Closed)
序号 活动或事件 状态 起止时间 说明







下月工作计划
序号 活动或事件 参与者 起止时间 说明





备注:
每个任务的开发进度将在相应的《软件开发计划》中具体定义。
5 文档管理
5.1 文档的类型
本项目包括如下几类文档;
1) 项目管理文档。包括:本文档(《项目管理计划》)、《项目开发计划》、《项目月度报告》(含《任务月度报告》)
2) 软件开发文档。包括:《软件开发计划》、《软件需求规格说明》、《软件设计说明》。
3) 软件配置管理文档。包括《软件配置管理报告》
4) 软件测试文档。包括:《软件测试计划》、《软件测试报告》、《软件验收报告》。
5) 产品资料。包括:《用户手册》、《技术说明》。
5.2 文档的组织
为便于分类和查询,本项目的文档将按树形结构组织。图5.2给出了本项目树形文档结构。

图5.2 项目的文档树













5.3 文档的版本号
本项目文档的版本号由以圆点隔开的两个数字组成,第一个数字表示出版号,第二个数字表示该版的修订号。具体用法如下:
1) 当文档初版时,版本号为 V1.0;
2) 当文档被局部修订时,出版号不变,修订号增1。例如,对初版文档作了第一次修订,则版本号为 V1.1;
3) 当文档被全面改写或局部修订累积较多导致文档发生全局变化时,出版号增1。例如,在 V1.5 版的基础上作了一次全面修订,则新版本号为 V2.0。
5.4 文档的标识
本项目所产生的文档都有唯一、特定的编码,其构成如下:
S-任务标识-文档类型-文档树中的编号-版本号/序号
其中:
1) S:本项目的标识,表明本项目是“XXXX”( Server)。
2) 任务标识:少于八个字母,简要标识本任务,如邮件XXXX可以是“XXXX”,标准XXXX是“STANDARD”。适用于整个项目的文档,此标识为“XXXX”。
3) 文档类型:取自表5.3的两位字母编码。
4) 文档树中的编号:四位数字字母编码,对应于该文档在文档树中的位置。
5) 版本号:本文档的版本号。
6) 序号:四位数字编码,指明该文档在项目文档库的总序号。

一个文档编码的例子为:
S-XXXX-SP-2101-V1.0/0015
表5.3 项目的文档分类表
文 档 类 型 编码 编号 注 释
项目管理 项目管理计划 PM 1001 Project Management
项目开发计划 PP 1002 Project Plan
项目月度报告 PR 1003 Project Report
软件开发 软件开发计划 SP 2N01 Software Plan
软件需求规格说明 SA 2N02 Software Anlaysis
软件设计说明 SD 2N03 Software Design
软件配置管理 软件配置管理报告 CR 3001 Configration Report
软件测试 软件测试计划 TP 4N01 Testing Plan
软件测试报告 TR 4N02 Tesing Report
软件验收报告 TV 4003 Software Verification
产品文档 用户手册 RU 5N01 User guide
技术说明 RT 5N02 Technical Notes
本项目中所有文档的标识清单将在《项目开发计划》中予以具体定义。
5.5 文档的编写模板
本项目中所有任务的文档将按照统一的模板(格式和内容的约定)来编写,包括:
1) 《模板-软件开发计划》
2) 《模板-软件需求规格说明》
3) 《模板-软件设计说明》
4) 《模板-技术说明》
文档的模板均保存在配置管理员处,并由其分发给文档的编写者。
需要说明的是,文档模板是本项目在文档结构和版式上的统一约定,对于具体文档,编写者可以根据需要添加章节,原则上不要删除章节(可以写“本章/节无内容”)。当文档模板不符合编写者要求时,编写者应与项目组长联系以决定文档的编写标准。
5.6 关于《技术说明》
在 产品包中,应包含一份《技术说明》,以详细说明本产品的代码来源和修改情况。
在《技术说明》中,应包含如下内容:
1) 代码包的清单,格式为:
代码包名 来源 版本 功能的描述




其中,“来源”可以是:下载的网络地址、“拷贝”、“创建”
2) 代码文件的清单,格式为:
代码包名 文件名 状态 修改者/作者 最后修改时间




其中,“状态”可以是:“修改”、“删除”、“创建”、“原样”
3) 约定标识修改代码的方式。在本项目中,所有任务的《技术说明》统一约定做如下说明:“以patch的方式修改别人的代码”。
5.7 文档的控制
本项目的文档将由配置管理员实施统一配置管理。配置管理员在文档管理方面的主要职责如下:
1) 文档库建立。配置管理员建立文档库,以便快速查询。配置管理员负责编写本项目的《软件配置管理报告》。
2) 文档归档。所有内、外部文档都应交付配置管理员归档,配置管理员依据文档编码方法为文档分配一个唯一编码,在登记入库后,将其置于自己的控制之下。
3) 内部文档标准监督。所有正式的内部文档都要按照相应的模板来编制。配置管理员在接收时内部文档时应检查编写/填写是否符合标准,如不符,有权要求责任者重新编/填写。
4) 外部文档接收。所有与项目有关的文件资料应统一由配置管理员保存或复印,并与内部文档一样归入项目组的文档库。
5) 文档分发。文档归档后,管理员应根据由项目组长拟定的分发名单将文档分发给有关人员。
6) 文档模板的管理。配置管理员保存和分发文档模板。当文档模板发生修改时,管理员应立即分发给所有文档编写者,并且说明修改的位置。
7) 文档借阅。项目组成员需查阅文档或资料时,应向配置管理员办理借阅手续,暂时不用的文档或资料应及时归还以提高文档资料的利用率。
6 代码管理
6.1 注释规范
1) 为了显示方面的兼容性,代码的注释均使用英文。
2) 对于可注释对象(如窗口、菜单、变量等),在对象的注释中,标明其完整的名称及其用途。
3) 对于自己创建的代码文件(如函数、脚本),在文件开头,一般编写如下注释:
/******************************************************
文件名
文件主要作用
文件作者
公司名称(XXXX)
编写日期
修改记录(如果有)
文件包含的主要内容(函数名、参数、返回值)
代码符合GPL等协议(如果是)
******************************************************/
4) 对于代码段(如分支、循环、功能块),需要就近书写注释以说明代码段的功能。但是应避免对代码过细的描述。

以下介绍一个注释技巧。
有时需要注释大段的测试代码,最简单的方法就是使用if (0)块: (其中的代码永远不会被执行)
function example()
{
great looking code
if (0) {
lots of code
}
more code
}
你不能使用/**/,因为注释内部不能包含注释,而大段的程序中可能回已经包含了注释,不是么?
6.2 命名规范
以下是一般的命名规则:
1) 名字应该能够标识事物的特性。
2) 名字尽量不使用缩写,除非它是众所周知的。
3) 名字可以有两个或三个单词组成,但不应多于三个。
4) 在名字中,多个单词之间可以用空格(如果允许)、下划杠(如果允许)或大写第一个字母(其它字母小写)来分隔。例如:main page 、IsSuperUser、function_user_jugdement。
5) 用前缀或后缀来区分不同类别的名字。例如:function_user_management,table_user_definition、page_login。在本项目中,约定:尽量使用前缀而不是后缀。
6) 名字中的单词尽量使用名词,如有动词,也尽量放在后面。例如:function_user_delete(而不是function_delete_user)。
在具体任务开发中,如果有特定的命名约定,则在相应的软件开发计划中予以明确定义。
6.3 编码规范
以下是一般的编码规则:
1) 错误检查规则。
(1) 编程中要考虑函数的各种执行情况,尽可能处理所有流程情况。
(2) 检查所有的系统调用的错误信息,除非要忽略错误。
(3) 将函数分两类:一类为与屏幕的显示无关, 另一类与屏幕的显示有关。对于与屏幕显示无关的函数,函数通过返回值来报告错误。 对于与屏幕显示有关的函数,函数要负责向用户发出警告,并进行错误处理。
(4) 错误处理代码一般放在函数末尾。
(5) 对于通用的错误处理,可建立通用的错误处理函数,处理常见的通用的错误。
2) 大括号规则。将大括号放置在关键词下方的同列处,例如:
if ($condition) while ($condition)
{ {
... ...
} }
3) 缩进规则。使用三到四个空格为每层次缩进。例如:
function func()
{
if (something bad)
{
if (another thing bad)
{
while (more input)
{
}
}
}
}
4) 小括号规则。
(1) 不要把小括号和关键词(if 、while等)紧贴在一起,要用空格隔开它们。
(2) 不要把小括号和函数名紧贴在一起。
(3) 除非必要,不要在Return返回语句中使用小括号。
因为关键字不是函数,如果小括号紧贴着函数名和关键字,二者很容易被看成是一体的。
5) If then
else
规则。如果你有用到else
if 语句的话,通常最好有一个else
块以用于处理未处理到的其他情况。可以的话放一个记录信息注释在else
处,即使在else
没有任何的动作。其格式为:
if (条件1) // 注释
{
}
else
if (条件2) // 注释
{
}
else
// 注释
{
}
6) 比较规则。总是将恒量放在等号/不等号的左边。一个原因是假如你在等式中漏了一个等号,语法检查器会为你报错。第二个原因是你能立刻找到数值而不是在你的表达式的末端找到它。例如:
if ( 6 == $errorNum ) ...
7) Case规则。default case总应该存在,如果不允许到达,则应该保证:若到达了就会触发一个错误。
8) 对齐规则。变量的申明和初始化都应对齐。例如:
int count;
int i,j;
float f1,f1;
count = 0;
i = 1;
float = 0.3;
9) 单语句规则。除非这些语句有很密切的联系,否则每行只写一个语句。
10) 单一功能规则。原则上,一个程序单元(函数、例程、方法)只完成一项功能。
11) 简单功能规则。原则上,一个程序单元的代码应该限制在一页内(25~30行)。
12) 明确条件规则。不要采用缺省值测试非零值。例如:使用“if ( 0 != f( ) )”而不用“if ( f( ) )”。
13) 选用FALSE规则。大部分函数在错误时返回FALSE、0或NO之类的值,但在正确时返回值就不定了(不能用一个固定的TRUE、1或YES来代表),因此检测一个布尔值时应该用FALSE、0、NO之类的不等式来代替。例如:使用“if ( FALSE != f( ) )”而不用“if (TRUE == f( ) )”。
14) 独立赋值规则。嵌入式赋值不利于理解程序,同时可能回造成意想不到的副作用,应尽量编写独立的赋值语句。例如:使用“a = b + c ;
e = a + d;”而不用“e = ( a = b + c ) + d ”。
15) 定义常量规则。对于代码中引用的常量(尤其是数字),应该define成一个大写的名字,在代码中引用名字而不直接引用值。
16) 模块化规则。某一功能,如果重复实现三遍以上,即应考虑模块化,将它写成通用函数。并向小组成员发布。同时要尽可能利用其它人的现成模块。
17) 交流规则。共享别人的工作成果,向别人提供自己的工作成果。
在具体任务开发中,如果有其它的编码规则,则在相应的软件开发计划中予以明确定义。
6.4 界面规范
在本项目中,“系统管理”将被定义为一个开发任务,所有功能XXXX的管理界面将被统一在这个任务中,故界面的规范将在此任务的软件开发计划中定义。
6.5 代码包规范
本项目中,每个任务在完成一个稳定的版本后,都应打包并且归档。代码打包的规范如下。
6.5.1 代码包的版本号
本项目中,代码包的版本号由圆点隔开的两个数字组成,第一个数字表示发行号,第二个数字表示该版的修改号。具体用法如下:
1) 当代码包初版时,版本号为 V1.00;
2) 当代码包被局部修改时,发行号不变,修改号增1。例如,对初版代码包作了第一次修订,则版本号为 V1.01;
3) 当代码包有重要修改或局部修订累积较多导致代码包发生全局变化时,发行号增1。例如,在 V1.15 版的基础上作了一次全面修改,则新版本号为 V2.00。
6.5.2 代码包的标识
本项目所产生的代码包都有唯一、特定的编码,其构成如下:
S-任务标识-代码包类型-版本号/序号
其中:
1) S:本项目的标识,表明本项目是“XXXX”( Function Server)。
2) 任务标识:少于八个字母,简要标识本任务,如邮件XXXX可以是“XXXX”,标准XXXX是“STANDARD”。适用于整个项目的文档,此标识为“XXXX”。
3) 代码包类型:取自表6.5.2的两位字母编码。
4) 版本号:本代码包的版本号。
5) 序号:四位数字编码,指明该代码包在项目代码库的总序号。

一个代码包编码的例子为:
S-XXXX-RA-V1.02/0029
表6.5.2 项目的代码包分类表
类 型 编码 注 释
rpm包 源码 RS Source in rpm
二进制代码 RE Execution in rpm
tar.gz包 源码 TS Source in tar.gz
二进制代码 TE Execution in tar.gz
源码 + 二进制代码 TA Source &
Excution in tar.gz
本项目中所有代码包的标识清单将在《项目开发计划》中予以具体定义。
6.6 代码的控制
本项目的代码将由配置管理员实施统一配置管理。配置管理员在代码管理方面的主要职责如下:
1) 代码库/目录的建立。配置管理员建立文档库目录,以便快速查询。配置管理员负责编写本项目的《软件配置管理报告》。
2) 代码归档。所有代码在完成一个稳定的版本后,都应打包后交付配置管理员归档,配置管理员依据代码包的命名规范为代码包分配一个唯一名称,在登记入库后,将其置于自己的控制之下。
3) 代码管理规范的监督。所有归档的代码包都要按照遵循本文档的代码管理规范。配置管理员在接收时代码包时应检查其是否符合规范,如不符,有权要求责任者重新打包。
4) 外来代码的获得。任务需要的外来代码包应统一由配置管理员来下载、复制、保存和分发,并与内部代码一样归入项目组的代码库。
5) 代码分发。代码归档后,管理员应根据由项目组长拟定的分发名单将代码分发给有关人员。
6) 代码的引用。项目组成员需引用外来代码或其他成员的代码时,应向配置管理员申请,而不应自己下载或从别处复制。
 
多谢各位了!!
 

Similar threads

S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
D
回复
0
查看
1K
DelphiTeacher的专栏
D
后退
顶部