2005年12月29日

作者:不详  来源:uml.org.cn  http://www.csai.cn 2005年09月08日 

    目前,china.com主页日常更新的有五方面内容:"头条链接"、"频道精选"、"专题特集"、 "图片推荐"和"精彩推荐"。

    一、头条链接

    头条链接数量为9条,推荐内容以时事新闻为主,约占6-8条,若有重要的体育、娱乐、IT等新闻,也可在该位置推荐。推荐数量和选择性由新闻部决定。推荐邮箱:news@sz.china.com。

    二、频道精选

    1. 推荐内容要紧扣频道名称,应尽量避免和其他频道内容的冲突。真正做到体现频道本色。
    2. 推荐内容要符合社会、政治以及道德舆论主流,尽量避免有损党和政府形象、血腥暴力、色情低俗的内容。
    3. 推荐内容一定要注明信息来源(即便是网友原创也要注明),并保证不牵扯版权问题。
    4. 推荐内容的标题字数限制在16字以内。链接必须是终极页面的URL。
    5. 一定要等推荐内容镜像到北京才可发送邮件推荐。
    6. 推荐内容发送到统一邮箱:best@sz.china.com。

    三、专题特集
    专题特集推荐内容是各频道制作的较大型的专题或专栏。在主页陈列的时间一般较长。专题页面的数量通常不少于10页。

    推荐"专题特集"的程序:

    专题制作编辑(填写"专题推荐申请表")→频道监制(审核签字)→网页设计部主管(审核签字)→策划总监或资讯总监(审核签字)→首页编辑→添加到主页完成。

    四、图片推荐

    频道精选右侧为"图片推荐"位置。更新频率为每日或半日。图片也应不涉及版权问题(严禁推荐带有色情和政治丑化色彩的图片)。另外,推荐内容要有一定时效性和独特性。

    推荐直接发送到邮箱best@sz.china.com,包含要素为图片(质量要清晰,高160X宽120~140),文字说明标题,终极页面URL。

    五、关于"精彩推荐"

    "精彩推荐"是在原有"专题特辑"中分离出的一个推荐区。其更新频率原则上为三至五天。和"专题特集"不同之处在于,它推荐的范围更广泛,精彩推荐可以是新闻的追踪报道等,页面数量在5页以上。

    推荐直接发送到邮箱best@sz.china.com,包含要素推荐标题(标题字数限制在10个字以内),终极页面URL。

    请各频道监制和编辑有意识的维护china.com主页形象,认真斟酌、推荐本频道优秀内容。

作者:不详  来源:uml.org.cn  http://www.csai.cn 2005年09月08日 

    为了更好地规范管理我公司网站软件开发工作,让软件开发人员准确、快速地理解各种软件开发需求,便于与编辑部门沟通,提高工作效率,公司其他部门在提出网站相关的软件开发需求时,须填写《网站软件开发需求表》,提交软件开发部经理。

    下面是《网站软件开发需求表》中"要求实现的功能"一栏需要填写的内容:

    1客户端

    1.1客户端程序流程图。

    1.2依据流程图逐一说明各步骤实现的功能及相关的页面。

    1.3页面(包括程序执行后返回的页面)的用途、相互之间的关系,页面的图片、文字及相关联结。如果已经有HTML页面,必须一并提供。

    1.4具体说明每个页面需要实现的功能:

    (1) 列出通过表单提交的数据项,数据类型(数字、字符),数据长度。标明必填(选)项和非必填(选)项。(由用户选择输入的数据项,必须提供可选择的内容。)

    (2) 查询(统计)使用的条件,查询条件的组合方式。

    (3) 查询结果显示的数据项,显示效果(如分页显示,每页显示的记录数等)。

    (4) 提供给用户使用的数据维护功能。(如数据的更新、删除等)

    1.5发送E-mail的格式、条件、内容,发件人,收件人。

    1.6涉及分类的,必须提供相关的分类系统(分类方法、内容)。

    1.7文件上传、下载的执行条件、操作权限,文件的类型、大小范围。

    1.8如果要求页面管理与程序管理分别独立,则需要提供HTML页面存放的地址(完整的URL地址)。

    1.9可参考的站点URL。

    2管理端

    2.1管理端程序流程图。

    2.2依据流程图逐一说明各步骤实现的功能。

    2.3按以下方式,对每个功能模块的实现提出具体要求:

    (1) 列出通过表单提交的数据项,数据类型(数字、字符),数据长度。标明必填(选)项和非必填(选)项。(选择输入的数据项,必须提供可选择的内容。)

    (2)查询(统计)使用的条件,查询条件的组合方式。

    (3)查询结果显示的数据项,显示效果(如分页显示,每页显示的记录数等)。

    (4)需要管理端维护(如更新、删除等)的数据项。

    2.4发送E-mail的格式、条件、内容,发件人,收件人。

    2.5涉及分类的,必须提供相关的分类系统(分类方法、内容)。

    2.6文件上传、下载的执行条件、操作权限,文件的类型、大小范围。

    2.7数据库及文件的备份。

作者:不详  来源:uml.org.cn  http://www.csai.cn 2005年09月08日 

    1数据库使用规范

    1.1服务器上有关数据库的一切操作只能由服务器管理人员进行。

    1.2程序中访问数据库时使用统一的用户、统一的连接文件访问数据库。

    1.3原则上每一个频道只能建一个库,库名与各频道的英文名称相一致,库中再包含若干表。比较大的、重点的栏目可以考虑单独建库,库名与栏目的英文名称相一致。

    1.4命名:

    (1) 数据库、表、字段、索引、视图等一系列与数据库相关的名称必须全部使用与内容相关的英文单词命名(尽量避免使用汉语拼音),对于一个单词难以表达的,可以考虑用多个单词加下划线(_)连接(不能超过四个单词)命名。

    (2) 所有的名称必须统一使用英文小写字母。

    (3) 所有的名称起始和结尾不能使用下划线(_)。

    (4) 所有的名称不能包含26个英文小写字母和下划线(_)以外的其他字符。

    1.5不再使用的数据库、表应删除,在删除之前必须备份(包括结构和内容)。

    2 文档规范

    所有的项目必须有相关的文档说明(可以是电子文档)。文档应包含如下内容:

    (1)项目名称。
    (2)项目小组名单,项目负责人。
    (3)项目开发起始时间和结束时间。
    (4)项目内容描述。
    (5)项目位置。(在哪个频道、哪个栏目)
    (6)与项目有关的程序文件名(含路径名),文件内容及实现的功能描述。
    (7)完整的程序流程图。
    (8)数据库、表、视图、索引的名称,用途。字段的名称、类型、长度、用途,必须附上相关的SQL语句。

    3源代码与页面嵌套规范

    3.1源代码:

    (1) 使用自定义变量(包括全局变量、局部变量)之前必须先声明变量,并用注释语句标明变量的类型、用途。
    (2)自定义函数必须用注释语句标明函数的用途、参数的数据类型、意义,返回值的类型。
    (3)程序中重要的过程或代码较长的过程应使用注释语句标明该过程的起始行和结束行,并注明该过程的功能。
    (5) 所有的注释文字一律使用简体中文。

    3.2 HTML页面嵌套:

    (1) 网页设计部设计的HTML页面以<table></table>嵌套的方式确定用于动态显示程序执行结果的位置、宽度、行数(或高度)等,并在相应位置予以文字说明。页面中与程序无关的图片、文字、联结等必须使用完整的URL。
    (2) 软件开发人员和编辑人员可以根据情况协商,将页面文件及图片与程序独立存放在各自的服务器上,页面改版和修改程序独立进行。
    (3) 使用include技术将分割开的HTML页面分别嵌入程序代码中,要求做到修改HTML页面时无须改写程序,而修改程序时不会影响HTML页面效果,将页面改版和修改程序两项工作分别独立。
    (4) 页面和程序嵌套以后不能破坏原HTML页面的整体显示效果,字体、字号、颜色等应尽量保持原HTML页面的风格。
    (5) 动态生成的页面的各项指标(如图片大小、页面宽度、高度、页面文件的字节数等)应符合本公司网页设计方面的要求。

    4测试规范(软件部分)

    对于较大的项目应成立相应的测试小组,小组成员由软件开发人员、网页设计人员、技术人员、编辑人员组成。测试过程应参照网页设计部为该项目提供的原HTML页面进行。测试内容包括以下几点:

    (1) 页面宽度、高度(行数)。
    (2) 页面文字、图片、色彩是否风格统一。
    (3)页面的图片显示是否正常、有无变形。
    (4)弹出页面的效果。
    (5)页面的联接是否正确。
    (6)动态生成的页面是否符合以上几个方面的要求,页面大小(字节数,包括页面的图片、*.js、*.css、*.class等相关文件)是否符合网页设计的要求。
    (7) 软件方面的功能是否实现。如数据库的查询、修改、删除,文件的上传、下载等操作是否正常。
    (8) 测试结束后,根据《软件开发需求书》在《测试报告》上如实填写测试结果,包括测试通过的、未通过的,指出出错的页面和相关的程序文件,并附上测试中出现的错误信息。

作者:不详  来源:uml.net.cn  http://www.csai.cn 2005年08月17日 

作者: 审核: 审批:

更改记录

日期

修改章节

修改

类型 *

修改描述

修改人

版本

                             
                             
                             

    * 修改类型分为 A - ADDED M - MODIFIED D – DELETED

 

    子合同验收报告

    

更改记录

日期

修改章节

修改类型 *

修改描述

修改人

版本

                             

    * 修改类型分为 A - ADDED M - MODIFIED D – DELETED

    文档编号 :

项目名称: (文档所属的项目的名称,《项目计划》或《立项报告》保持一致)

拟制: (项目组接口人签名和日期)

审核: (项目经理签名和日期)

(子合同经理签名和日期)

SQA : //

批准: (总经理签名和日期)

项目代号: (和《项目计划》或《立项报告》保持一致,不需有代号的可以填 // )

收文: (总经理,主管研发总经理,项目经理, SQA 角色,子合同经理)

产品版本: (和《项目计划》或《立项报告》保持一致,不需有代号的可以填 // )

抄送: (其他参加会议的人)

子合同项目名称:

子商名称:

    目的: 将子合同产品的测试和验收结果进行汇总,总结本次子合同的经验。

    背景、备注: (本文件的背景;本文档其他条目无法涵盖但认为有必要写明的内容都可以放在此处)

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

    参考: (合同,产品测试和评审报告, SQA 评价报告, SCM 评价报告)

      验收结果汇总

验收产品名称

计划交付时间

实际交付时间

通过测试 / 评审的时间

测试 / 评审意见

项目组意见

                             

    二  验收结论

    ( 在此给出总体性的结论,如哪些产品通过验收,哪些产品没有通过验收 )

    三  存在的问题与解决计划

    ( 列出存在的问题、解决的方法和计划 )

    四  对子商的评价

    1 . 分数对照表

A+

A

A-

B+

B

B-

C+

C

C-

D

100

95

90

85

80

75

70

65

60

50

    2 . 评分结果汇总
    

产品质量 (40%)

进度

(30%)

配合和沟通

(20%)

性能价格比

(10%)

综合分数

评分人

                        

评语

                        

分数

                        

    备注:

    •  如果没有一个细化的评分表,则由评分人以 A 、 B 、 C 的形式给出分数。

    •  如果本项目是由多个子商共同,则需要在上表中列出每个子商及其负责的工作,并对每个子商分别给出评分。

    3 .评分说明

    (在此给出评分的具体说明,如评分人、对应的验收产品等)

    (如果某项产品的评分高于 A- (含)或低于 C- ,则必须给出相应的说明)

    产品质量评分

验收的产品

分数

比重

评分人

评语

可执行产品

(70%)

    

%

(测试角色给出)

    

源源代码

(20%)

    

%

(源代码评价与测试人员给出评价)

    

XXX 文档 *

( 10% )

    

%

(文档评价人员给出评价)

    
                  

总 分

    

100%

         

    备注:

    •  如果没有一个细化的评分表,则由评分人以 A 、 B 、 C 的形式给出分数。

    •  对于文档,需要给出具体的文档名称。

    •  验收的产品名称和数量可以根据实际情况进行调整。

    •  所有验收产品的比重必须等于 100% 。

    •  如果本项目是由多个子商共同,则需要对每个子商分别给出评分。

    五  后续活动安排

    (在此安排后续的活动,如果没有,可以以“ // ”表示)

作者:不详  来源:uml.org.cn  http://www.csai.cn 2005年09月22日 

    更改记录

日期

修改章节

修改类型 *

修改描述

修改人

版本

                       

    * 修改类型分为 A - ADDED M - MODIFIED D – DELETED

    文档编号:

项目名称:

拟制: ( 子合同项目 team leader 签字和日期 )

审核: (项目经理签字和日期)

(子合同经理签字和日期)

SQA : //

批准: ( 研发主管签字和日期 )

项目代号:

收文: (研发主管,项目经理, SQA ,子合同经理)

产品版本:

抄送: //

    目的:规范技术协作项目的合同条款,维护公司和项目组的利益,为子合同跟踪打好基础。

    背景、备注:

    定义:

    参考:

 



软件开发委托协议(个人)

    甲方:             (委托方)

    地址:

    邮编:

    电话:

    乙方:北京天理软件研发中心(开发方)

    地址:北京市海淀区上地信息产业基地

    邮编: 100085

    电话:

    负责人:

    甲方委托乙方,乙方接受甲方委托,开发 软件产品,双方就合作事宜达成如下协议:

      合作方式

    乙方根据甲方的要求定制开发软件产品,并向甲方提供技术培训;甲方向乙方支付费用。

      软件内容要求及验收标准:

    1   依据本合同约定,甲方委托乙方开发的软件产品为:

    2  总体设计原则:

    3   软件的构成及功能需求、验收标准以经甲方确认的《 软件需求说明书》(见附件一)为准。 (《软件需求说明书》通常应包括软件的 功能描述、验收标准、验收期限、验收方法、产品缺陷的确认和补救 等内容,可以根据委托项目的特点予以增减。例如,我方的详细设计已经完成,只需要承包方编写代码,此时就不需要 功能描述 )

      工作进度:

    乙方应按本合同所附的《 软件开发进度计划》(见附件二)完成工作进度:

      费用支付

    1   本项目总费用为 元,双方同意以下列第 种方式付款

    ( 1)现金 (2)支票 (3)其他方式

    2   付款期限:

    在乙方按本合同第三条规定的时间表完成工作进度并验收合格的前提下,甲方将按如下日期向乙方支付:

    (1) 后 日内首付合同总额的 %,金额 元;

    (2) 后 日内支付合同总额的 %,金额 元;

    (3) 后 日内支付合同总额的 %,金额 元 ;

    (4) 后支付最后一笔,即总额的 %,金额 元。

    3   付款地点:双方同意付款地点为

    4   上述费用包含甲方应当向乙方支付的的所有费用,乙方承担所得税,并由甲方代扣。

      双方权利和义务

    1   如系统设计存在缺陷,导致整个系统无法正常运行,甲方保留追回所有投入的权利;

    2   如设计缺陷导致部分功能无法正常运行,乙方应在甲方要求的时间内解决问题,如问题不能按期解决,导致影响甲方正常使用 ,甲方有权扣除部分费用;

    3   系统设计必须完全符合甲方设计要求,否则甲方有权拒付款项(设计要求见附件一);

    4   乙方需协助甲方安装调试,直至甲方验收合格;

    5   乙方负责为甲方培训 、 人员各 名,甲方接受培训的人员应达到熟练操作并能解决简单问题的程度;

    6   乙方应亲自完成本开发项目的全部工作,未经甲方书面许可,乙方不得将本项目的全部或部分转委托给任何第三方。

    7   乙方必须在交付使用时作出该系统技术升级、功能扩展的计划,升级、扩展所用费用由 承担(或另议);

    8   系统维护:

    方案一:系统验收合格并交付使用后,乙方负责免费维修 个月。系统出现紧急问题,乙方应现场解决。乙方人员应于甲方发出书面维修通知后 日/小时内到达现场,因乙方迟延造成的甲方损失,由乙方承担。

    方案二:系统验收合格并交付使用后,乙方负责提供 人天工作量的免费维修。系统出现紧急问题,乙方应现场解决。乙方人员应于甲方发出书面维修通知后 日/小时内到达现场,因乙方迟延造成的甲方损失,由乙方承担。

      知识产权条款

    1   因本协议产生的开发成果(包括源代码、系统技术文档、软件、数据等)由甲方享有知识产权。未经甲方书面许可,乙方不得许可第三方阅读、使用或复制。

    2   乙方保证其开发成果及其开发过程不侵犯第三人的知识产权,如第三方以该产品侵犯知识产权为由提起诉讼,乙方将以自己的费用解决问题,并赔偿因此给甲方造成的损失。

    3   乙方对本协议有关内容及产品的研制过程负有保密义务,保密期限为自合同签订之日起

年。具体保密义务以本协议附件 三 为准。

      协议的补充、变更、终止

    1   协议的补充、变更、修改:如因业务发展需要对本协议现有内容进行补充、变更、修改,由双方或任何一方提出补充、变更、修改的建议和方案,经双方协商并达成统一意见后,以书面形式确认,并由双方签字盖章后补充为本协议的附件,与本协议具有同等法律效力。

    2   协议的终止:

    方案一:本协议在履行过程中,如有任何一方要求暂时停止或终止本协议的执行,应提前一个月向对方以书面形式提出,经双方协商并达成一致意见后,方可执行。

    方案二:本协议在履行过程中,如因乙方不能正确协议义务而导致项目开发受到严重影响,甲方有权单方解除合同,提前 天以书面形式通知乙方。

      违约责任

    1   乙方应按附件一所列的时间按时完成工作进度 ,如乙方迟延完成工作进度,每迟延一日,甲方有权扣除合同总金额的 %作为违约金。迟延超过 天,影响甲方正常使用的,甲方有权单方终止合同,乙方应于甲方终止合同 日内返还甲方已支付的款项。

    2   乙方应保证开发完成的产品达到本协议约定的性能要求,如因产品不能达到约定的功能而影响甲方正常使用,甲方有权酌情(或按不能使用的时间长短)扣除开发费用;给甲方造成其他损失的,乙方应予赔偿。

    3   如乙方擅自中断开发,甲方有权终止合同。乙方应自甲方发出书面通知起 日内返还甲方已支付的全部费用,给甲方造成其他损失的,应予赔偿。

    4   如乙方未经甲方书面许可将本项目的全部或部分转委托给第三方,甲方有权立即解除合同。乙方应在甲方发出书面通知起 日内返还甲方已支付的费用,并应向甲方支付相当于合同总金额 %的违约金。

    5   乙方提交的工作成果验收合格后,甲方应按时履行付款义务,如甲方无正当理由迟延付款,每迟延一日,应向乙方支付迟延支付部分金额的 %作为违约金。

      管辖:

    本合同在履行过程中如发生争议,由当事人双方协商解决。协商不成,双方同意由甲方所在地法院管辖。

      其他:

    1   本合同附件如下:

    附件一:《 软件需求说明书》

    附件二:《 软件开发进度计划》

    附件三:《保密协议》

    ……

    本合同附件与正文具有同等效力。

    2   本合同一式 份,自双方签字之日起生效。

    甲方:                 乙方:北京天理软件研发中心

    (盖章)                (盖章)

    签字:                    签字:

    日期:                    日期:

    签约地点:



    附件一: 软件需求说明书

    (列出产品的功能和验收标准)

    (列出要求提交的其他产品和相应的验收标准。产品可以包括源代码、设计说明书、使用说明书、在线帮助等)

    附件二: 软件开发进度计划

    (划分项目工作,指出各部分的进度时间表及对应的人力、物力需求,从而给出总的费用和项目开发时间。)

    (从技术角度列出里程碑、里程碑产品及相应的验收标准。)

    (指出关键路径)

    一.里程碑设置

    里程碑设置

里程碑时间

计划提交的产品

产品要求

计划通过评审 / 测试的时间

   

项目方案计划书

       
   

可执行产品

       
   

测试报告

       
   

源代码

       

    (注释:可以不以表格的形式给出)

    在此设置项目开发的里程碑,作为项目进度的标志。

    甲方保证在收到已方提交的产品后以最快的速度安排人员进行相应的评审、测试,并将评审的结果通知乙方。若乙方提交的产品不符合双方约定的标准,则乙方不得进入下面阶段的开发工作,由此造成的工期延误由乙方完全负责。

    二.项目跟踪

    为了能够让甲方很好地掌握乙方的进展情况,乙方承诺在每周五下午用电子邮件给甲方发送《周状态报告》。

    《每周状态报告》通常包含:

    技术风险;

    缺陷统计;

    增加、修改和删除的代码行数;

    计划的、已经编码的、已经通过代码评审的模块;

    其它表明软件研发状态的指标。

作者:不详  来源:dlbii.gov.cn  http://www.csai.cn 2005年08月19日 

    1 范围

    本标准为那些对软件或基于软件的产品的开发负有职责的管理者提供软件文档的管理指南。本标准的目的在于协助管理者在他们的机构中产生有效的文档。

    本标准涉及策略、标准、规程、资源和计划,管理者必须关注这些内容,以便有效地管理软件文档。

    本标准期望应用于各种类型的软件,从简单的程序到复杂的软件系统。并期望覆盖各种类型的软件文档,作用于软件生存期的各个阶段。

    不论项目的大小,软件文档管理的原则是一致的。对于小项目,可以不采用本标准中规定的有关细节。管理者可剪裁这些内容以满足他们的特殊需要。

    本标准是针对文档编制管理而提出的,不涉及软件文档的内容和编排。

    2 引用标准

    下列标准所包含的条文,通过在本标准中引用而构成为本标准的条文。本标准出版时,所示版本均为有效,所有标准都会被修订,使用本标准的各方应探讨使用下列标准最新版本的可能性。

    GB 8566-88 计算机软件开发规范

    GB 8567-88 计算机软件产品开发文件编制指南

    GB/T 11457-1995 软件工程术语

    3 定义

    本标准采用下列定义,其他定义见 GB/T 11457 。

    3.1 文档 document

    一种数据媒体和其上所记录的数据。它具有永久性并可以由人或机器阅读。通常仅用于描述人工可读的内容。例如,技术文件、设计文件、版本说明文件。

    3.2 文档(集);文档编制 documentation

    一个或多个相关文档的集合。

    3.3 文档计划 documentation plan

    一个描述文档编制工作方法的管理用文档。该计划主要描述要编制什么类型的文档,这些文档的内容是什么,何时编写,由谁编写,如何编写,以及什么是影响期望结果的可用资源和外界因素。

    3.4 文档等级 level of documentation

    对所需文档的一个说明,它指出文档的范围、内容、格式及质量,可以根据项目、费用、预期用途、作用范围或其他因素选择文档等级。

    3.5 软件产品 software product

    软件开发过程的结果,并推出供用户使用的软件实体。

    4 软件文档的作用

    a) 管理依据;

    b) 任务之间联系的凭证;

    c) 质量保证;

    d) 培训与参考;

    e) 软件维护支持;

    f) 历史档案。

    4.1 管理依据

    在软件开过过程中,管理者必须了解开发进度、存在的问题和预期目标。每一阶段计划安排的定期报告提供了项目的可见性。定期报告还提醒各级管理者注意该部门对项目承担的责任以及该部门效率的重要性。开发文档规定若干个检查点和进度表,使管理者可以评定项目的进度,如果开发文档有遗漏,不完善,或内容陈旧,则管理者将失去跟踪和控制项目的重要依据。

    4.2 任务之间联系的凭证

    大多数软件开发项目通常被划分成若干个任务,并由不同的小组去完成。学科方面的专家建立项目,分析员阐述系统需求,设计员为程序员制定总体设计,程序员编制详细的程序代码,质量保证专家和审查员评价整个系统性能和功能的完整性,负责维护的程序员改进各种操作或增强某些功能。

    这些人员需要的互相联系是通过文档资料的复制、分发和引用而实现的,因而,任务之间的联系是文档的一个重要功能。大多数系统开发方法为任务的联系规定了一些正式文档。分析员向设计员提供正式需求规格说明,设计员向程序员提供正式设计规格说明,等等。

    4.3 质量保证

    那些负责软件质量保证和评估系统性能的人员需要程序规格说明、测试和评估计划、测试该系统用的各种质量标准以及关于期望系统完成什么功能和系统怎样实现这些功能的清晰说明;必须制订测试计划和测试规程,并报告测试结果;他们还必须说明和评估完全、控制、计算、检验例行程序及其他控制技术。这些文档的提供可满足质量保证人员和审查人员上述工作的需要。

    4.4 培训与参考

    软件文档的另一个功能是使系统管理员、操作员、用户、管理者和其他有关人员了解系统如何工作,以及为了达到他们的各自的目的,如何使用系统。

    4.5 软件维护支持

    维护人员需要软件系统的详细说明以帮助他们熟悉系统,找出并修正错误,改进系统以适应用户需求的变化或适应系统环境的变化。

    4.6 历史档案

    软件文档可用作未来项目的一种资源。通常文档记载系统的开发历史,可使有关系统结构的基本思想为以后的项目利用。系统开发人员通过审阅以前的系统以查明什么部分已试验过了,什么部分运行得很好,什么部分因某种原因难以运行而被排除。良好的系统文档有助于把程序移植和转移到各种新的系统环境中。

    5 管理者的作用

    管理者严格要求软件开发人员和编制组完成文档编制,并且在策略、标准、规程、资源分配和编制计划方面给予支持。

    a) 管理者对文档工作的责任。管理者要认识到正式或非正式文档都是重要的,还要认识到文档工作必须包括文档计划、编写、修改、形成、分发和维护等各个方面。

    b) 管理者对文档工作的支持。管理者应为编写文档的人员提供指导和实际鼓励,并使各种资源有效地用于文档开发。

    c) 管理者的主要职责:

    1 ) 建立编制、登记、出版系统文档和软件文档的各种策略;

    2 ) 把文档计划作为整个开发工作的一个组成部分;

    3 ) 建立确定文档质量、测试质量和评审质量的各种方法的规程;

    4 ) 为文档的各个方面 确定和准备各种标准和指南;

    5 ) 积极支持文档工作以形成在开发工作中自觉编制文档的团队风气;

    6 ) 不断检查已建立起来的过程,以保证符合策略和各种规程并遵守有关标准和指南。

    通常,项目管理者在项目开发前应决定如下事项:

    要求哪些类型的文档;

    提供多少种文档;

    文档包含的内容;

    达到何种级别的质量水平;

    何时产生何种文档;

    如何保存、维护文档以及如何进行通信。

    如果一个软件合同是有效的,应要求文档满足所接受的标准,并规定所提供的文档类型、每种文档的质量水平以及评审和通过的规程。

    6 制订文档编制策略

    文档策略是由上级(资深)管理者新任务并支持的,对下级开发单位或开发人员提供指导。策略规定主要的方向不是做什么或如何做的详细说明。

    一般说来,文档编制策略陈述要明确,并通告到每个人且理解它,进而使策略被他们贯彻实施。

    支持有效文档策略的基本条件:

    a) 文档需要覆盖整个软件生存期

    在项目早期几个阶段就要求有文档,而且在贯穿软件开发过程中必须是可用的和可维护的。在开发完成后,文档应满足软件的使用、维护、增强、转换或传输。

    b) 文档应是可管理的

    指导和控制文档的获得维护,管理者和发行专家应准备文档产品、进度、可靠性、资源,质量保证和评审规程的详细计划大纲。

    c) 文档应适合于它的读者

    读者可能是管理者、分析员、无计算机经验的专业人员、维护人员、文书人员等。根据任务的执行,他们要求不同的材料表示和不同的详细程度。针对不同的读者,发行专家应负责设计不同类型的文档。

    d) 文档效应应贯穿到软件的整个开发过程中

    在软件开发的整个过程中,应充分体现文档的作用和限制,即文档应指导全部开发过程。

    e) 文档标准应被标识和使用

    应尽可能地采纳现行的标准,若没有合适的现行标准,必要时应研制适用的标准或指南。

    f) 应规定支持工具

    工具有助于开发和维护软件产品,包括文档。因此尽可能地使用工具是经济的、可行的。

    附录 A 中的检查表为制定策略条款或评估现有策略条款的有效性和完整性提供帮助。

    7 制订文档编制标准和指南

    在一个机构内部,应采用一些标准和指南:

    ——软件生存期模型;

    ——文档类型和相互关系;

    ——文档质量。

    这些标准和指南决定如何实现文档任务,将提供一些准则以评价机构内所产生的软件文档的完整性、可用性和适合性。

    尽可能地采用现行的国家和国际标准,若现行的标准不适用,机构应制订自己的标准。

    7.1 选择软件生存期模型

    现有的一些软件生存期模型,对于不同的阶段有不同的词汇,从软件文档的观点来看,采用哪种模型都无关紧要,只要阶段和相应的文档是清晰定义的、已计划的,并且对于任何具体软件项目是能遵循的。因此,管理者应选择一个软件生存期模型并保证该模型在他们机构内是适用的。

    管理者将会发现所进行的阶段和相应任务的定义有助于监控软件项目的进展。相应于特定阶段生成的文档可用作该阶段的评审、通过和完成的检验点,而这种检验应在下一阶段开始前进行。

    7.2 规定文档类型和内容

    下面给出软件文档主要类型的大纲,这个大纲不是详尽的或最后的,但适合作为主要类型软件文档的检验表。而管理者应规定何时定义他们的标准文档类型。

    软件文档归入如下三种类别:

    a) 开发文档——描述开发过程本身;

    b) 产品文档——描述开发过程的产物;

    c) 管理文档——记录项目管理的信息。

    7.2.1 开发文档

    开发文档是描述软件开发过程,包括软件需求、软件设计、软件测试、保证软件质量的一类文档,开发文档也包括软件的详细技术描述(程序逻辑、程序间相互关系、数据格式和存储等)。

    开发文档起到如下五种作用:

    a) 它们是软件开发过程中包含的所有阶段之间的通信工具,它们记录生成软件需求、设计、编码和测试的详细规定和说明;

    b) 它们描述开发小组的职责。通过规定软件、主题事项、文档编制、质量保证人员以及包含在开发过程中任何其他事项的角色来定义做直截了当、如何做和何时做;

    c) 它们用作检验点而允许管理者评定开发进度。如果开发文档丢失、不完整或过时,管理者将失去跟踪和控制软件项目的一个重要工具;

    d) 它们形成了维护人员所要求的基本的软件支持文档。而这些支持文档可作为产品文档的一部分;

    e) 它们记录软件开发的历史。

    基本的开发文档是:

    ——可行性研究和项目任务书;

    ——需求规格说明;

    ——功能规格说明;

    ——设计规格说明,包括程序和数据规格说明;

    ——开发计划;

    ——软件集成和测试计划;

    ——质量保证计划、标准、进度;

    安全和测试信息。

    7.2.2 产品文档

    产品文档规定关于软件产品的使用、维护、增强、转换和传输的信息。

    产品的文档起到如下三种作用:

    a) 为使用和运行软件产品的任何人规定培训和参考信息;

    b) 使得那些未参加开发本软件的程序员维护它;

    c) 促进软件产品的市场流通或提高可接受性。

    产品文档用于下列类型的读者:

    ——用户 ——他们利用软件输入数据、检索信息和解决问题;

    ——运行者 ——他们在计算机系统上运行软件;

    ——维护人员 ——他们维护、增强或变更软件。

    产品文档包括如下内容:

    ——用于管理者的指南和资料,他们监督软件的使用;

    ——宣传资料 通告软件产品的可用性并详细说明它的功能、运行环境等;

    ——一般信息 对任何有兴趣的人描述软件产品。

    基本的产品文档包括:

    ——培训手册;

    ——参考手册和用户指南;

    ——软件支持手册;

    ——产品手册和信息广告。

    7.2.3 管理文档

    这种文档建立在项目管理信息的基础上,诸如:

    ——开发过程的每个阶段的进度和进度变更的记录;

    ——软件变更情况的记录;

    ——相对于开发的判定记录;

    ——职责定义。

    这种文档从管理的角度规定涉及软件生存的信息。

    相关文档的详细规定和编写格式见 GB 8567 。

    7.3 确定文档的质量等级

    仅仅依据规章、传统的做法或合同的要求去制作文档是不够的。管理者还必须确定文档的质量要求以及如何达到和保证质量要求。

    质量要求的确定取决于可得到的资源、项目的大小和风险,可以对该产品的每个文档的格式及详细程度作出明确的规定。

    每个文档的质量必须在文档计划期间就有明确的规定。文档的质量可以按文档的形式和列出的要坟划分为四级。

    最低限度文档( 1 级文档) 1 级文档适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。

    内部文档( 2 级文档) 2 级文档可用于在精心研究后被认为似乎没有与其他用户共享资源的专用程序。除 1 级文档提供的信息外, 2 级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。

    工作文档( 3 级文档) 3 级文档适合于由同一单位内若干人联合开发的程序,或可被其他单位使用的程序。

    正式文档( 4 级文档) 4 级文档适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质(如工资计算)的程序需要 4 级文档。 4 级文档遵守 GB 8567 的有关规定。

    质量方面需要考虑的问题即要包含文档的结构,也要包含文档的内容。文档内容可以根据正确性、完整性和明确性来判断。而文档结构由各个组成部分的顺序和总体安排的简单性来测定。要达到这四个质量等级,需要的投入和资源逐级增加,质量保证机构必须处于适当的行政地位以保证达到期望的质量等级。

    8 文档编制计划

    文档计划可以是整个项目计划的一部分或是一个独立的文档。应该编写文档计划并把它分发给全体开发组成员,作为文档重要性的具体依据和管理部门文档工作责任的备忘录。

    对于小的、非正式的项目,文档计划可能只有一页纸;对于较大的项目,文档计划可能是一个综合性的正式文档,这样的文档计划应遵循各项严格的标准及正规的评审和批准过程。

    编制计划的工作应及早开始,对计划的评审应贯穿项目的全过程。如同任何别的计划一样,文档计划指出未来的各项活动,当需要修改时必须加以修改。导致对计划作适当修改的常规评审应作为该项目工作的一部分,所有与该计划有关的人员都应得到文档计划。

    文档计划一般包括以下几方面内容:

    a) 列出应编制文档的目录;

    b) 提示编制文档应参考的标准;

    c) 指定文档管理员;

    d) 提供编制文档所需要的条件,落实文档编写人员、所需经费以及编制工具等;

    e) 明确保证文档质量的方法,为了确保文档内容的正确性、合理性,应采取一定的措施,如评审、鉴定等等;

    f) 绘制进度表,以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。

    附录 B 中的检查表为制定一个文档计划或评估现有文档计划的完整性提供帮助。

    此外,文档计划规定每个文档要达到的质量等级,以及为了达到期望的结果必须考虑哪些外部因素。

    文档计划还确定该计划和文档的分发,并且明确叙述与文档工作的所有人员的职责。

作者: 邓子云  来源:银行科技网  http://www.csai.cn 2005年10月18日 

                            _________项目开发计划

    1. 概述

    1.1 编写目的

    本文档是__________(开发单位名称)根据__________ 项目 的初步需求,并对_______ 项目 的各项需求进行全面分析之后,做出的软件开发计划,可供支持项目组内部及信息技术部内部的研发工作。

    1.2 项目背景

    系统名称: [ 列出系统名称 ]

    英文名称: [ 列出系统英文名称 ]

    产品代号: [ 列出系统产品代号 ]

    委托单位: [ 列出委托单位 ]

    开发单位: [ 列出开发单位 ]

    开发日期: [ 开始时间 ---- 预计收尾完工时间 ]

    版权信息: [Version X.X]

    1.3 定义

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

    1.4 参考资料

    [ 逐条列出所参考的文档名称与作者。 ]

    2. 项目过程定义

    2 .1软件开发生命周期模型

    [ 列出采用的软件开发生命周期模型,并说明采用的理由。 ]

    2 .2 开发工具与平台

    [ 列出采用的开发工具、操作系统及平台软件。 ]

    3 .计划

    3.3 资源计划

    [ 逐项列出项目开发过程中所需的各种资源。 ]

    3.4 关键计算机资源估计

    [ 逐条列出所需各种计算机资源的类型、配置及数量等内容。 ]

    4. 项目管理

    4.1 人员与角色

    [ 逐项列出项目组的角色分配及已可供调配的人员。 ]

    4.2 人员计划

    [ 逐条列出本项目所需各种角色人员的起始与结束时间,人数,技能方面的要求等内容。 ]

    4.3 风险管理计划

    [ 逐条列出各项风险的影响因素、发生概率、严重性、负责人、预期日期、预防及补救方案等内容。 ]

    4.4 培训计划

    [ 逐条列出主题(技能、领域、工具、方法)、人数、计划日期、提供者等内容。 ]

    4.5 成本估计

    [ 逐条列出成本的类型及金额,并计算估计的总本。 ]

    5. 进度跟踪

    5.1 项目会议

    [ 列出项目会议组织的办法。 ]

    5.2 项目里程碑

    [ 列出项目里程碑,即 项目进度的关键点 。 ]

    5.3 进度表

    [ 给出项目进度表。 ]

    5.4 人员任务分配

    [ 给出人员任务分配表,包括了任务内容、开始时间、完成时间、工时估计等内容。 ]

    附:

    [ 给出用 MS Project 制作的项目计划 MPP]

在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。

  ◇ 可行性分析报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。查看模板

  ◇ 项目开发计划:为软件项目实施方案制订出具体计划,应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。

  ◇ 软件需求说明书(软件规格说明书):对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的,也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求,为生成和维护系统数据文件做好准备。查看模板

  ◇ 概要设计说明书:该说明书是概要实际阶段的工作成果,它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计提供基础。查看模板

  ◇ 详细设计说明书:着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。查看模板

  ◇ 用户操作手册:本手册详细描述软件的功能、性能和用户界面,使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识,特别是操作方法的具体细节。查看模板

  ◇ 测试计划:为做好集成测试和验收测试,需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。

  ◇ 测试分析报告:测试工作完成以后,应提交测试计划执行情况的说明,对测试结果加以分析,并提出测试的结论意见。

  ◇ 开发进度月报:该月报系软件人员按月向管理部门提交的项目进展情况报告,报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。

  ◇ 项目开发总结报告:软件项目开发完成以后,应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力,此外,还需对开发工作做出评价,总结出经验和教训。

  ◇ 软件维护手册:主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明,便于软件的维护。

  ◇ 软件问题报告:指出软件问题的登记情况,如日期、发现人、状态、问题所属模块等,为软件修改提供准备文档。

  ◇ 软件修改报告:软件产品投入运行以后,发现了需对其进行修正、更改等问题,应将存在的问题、修改的考虑以及修改的影响作出详细的描述,提交审批。

1 引言
1.1编写目的
  说明编写这份用户手册的目的,指出预期的读者。
1.2背景
  说明:
  a.这份用户手册所描述的软件系统的名称;
  b.该软件项目的任务提出者、开发者、用户(或首批用户)及安装此软件的计算中心。
1.3定义
  列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
  列出有用的参考资料,如:
  a.项目的经核准的计划任务书或合同、上级机关的批文;
  b.属于本项目的其他已发表文件;
  c.本文件中各处引用的文件、资料,包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够取得这些文件资料的来源。
2 用途
2.1功能
  结合本软件的开发目的逐项地说明本软件所具有各项功能以及它们的极限范围。
2.2性能
2.2.1精度
  逐项说明对各项输入数据的精度要求和本软件输出数据达到的精度,包括传输中的精度要求。
2.2.2时间特性
  定量地说明本软件的时间特性,如响应时间,更新处理时间,数据传输、转换时间,计算时间等。
2.2.3灵活性
  说明本软件所具有的灵活性,即当用户需求(如对操作方式、运行环境、结果精度、时间特性等的要求)有某些变化时,本软件的适应能力。
2. 3 安 全保密
  说明本软件在安全、保密方面的设计考虑和实际达到的能力。
3 运行环境
3.1 硬设备
  列出为运行本软件所要求的硬设备的最小配置,如:
  a.处理机的型号、内存容量;
  b.所要求的外存储器、媒体、记录格式、设备的型号和台数、联机/脱机;
  c. I/O设备(联机/脱机?);
  d.数据传输设备和转换设备的型号、台数。
3.2支持软件
  说明为运行本软件所需要的支持软件,如:
  a.操作系统的名称、版本号;
  b.程序语言的编译/汇编系统的名称和版本号;
  c.数据库管理系统的名称和版本号;
  d.其他支持软件。
3.3数据结构
  列出为支持本软件的运行所需要的数据库或数据文卷。
4 使用过程
  在本章,首先用图表的形式说明软件的功能同系统的输入源机构、输出接收机构之间的关系。
4. 1安装与初始化
  一步一步地说明为使用本软件而需进行的安装与初始化过程,包括程序的存储形式、安装与初始化过程中的全部操作命令、系统对这些命令的反应与答复。表征安装工作完成的测试实例等。如果有的话,还应说明安装过程中所需用到的专用软件。
4.2输入
  规定输入数据和参量的准备要求。
4.2.1输入数据的现实背景
  说明输入数据的现实背景,主要是
  a.情况–例如人员变动、库存’缺货;
  b.情况出现的频度–例如是周期性的、随机的、一项操作状态的函数.
  c.情况来源-一例如人事部门、仓库管理部门;
  d.输入媒体—例如键盘、穿孔卡片、磁带;
  e.限制–出于安全、保密考虑而对访问这些输入数据所加的限制;
  f.质量管理–例如对输入数据合理性的检验以及当输入数据有错误时应采取的措施,如建立出错情况的记录等;
  g.支配–例如如何确定输入数据是保留还是废弃,是否要分配给其他的接受者等。
4.2.2输入格式
  说明对初始输入数据和参量的格式要求,包括语法规则和有关约定,如:
  a.长度-一例如字符数/行,字符数/项;
  b.格式基准–例如以左面的边沿为基准;
  c.标号–例如标记或标识符;
  d.顺序–例如各个数据项的次序及位置;
  e.标点–例如用来表示行、数据组等的开始或结束而使用的空格、斜线、星号、字符组等。
  f.词汇表–给出允许使用的字符组合的列表,禁止使用*的字符组合的列表等;
  g.省略和重复–给出用来表示输人元素可省略或重复的表示方式;
  h.控制–给出用来表示输入开始或结束的控制信息。
  H.4.2.3输入举例
  为每个完整的输入形式提供样本,包括:
  a.控制或首部–例如用来表示输入的种类和类型的信息,标识符输入日期,正文起点和对所用编码的规定;
  b.主体–输入数据的主体,包括数据文卷的输入表述部分;
  c.尾部–用来表示输入结束的控制信息,累计字符总数等;
  d.省略–指出哪些输入数据是可省略的;
  e.重复–指出哪些输入数据是重复的。
4.3输出 对每项输出作出说明.
4.3.1输出数据的现实背景,说明输出数据的现实背景,主要是:
  a.使用–这些输出数据是给谁的,用来干什么;
  b.使用频度–例如每周的、定期的或备查阅的;
  c.媒体–打印、CRI显示、磁带、卡片、磁盘,
  d.质量管理-一例如关于合理性检验、出错纠正的规定;
  e.支配–例如如何确定输出数据是保留还是废弃,是否要分配给其他接受者等。
4.3.2输出格式
  给出对每一类输出信息的解释,主要是:
  a.首部–如输出数据的标识符,输出日期和输出编号;
  b.主体–输出信息的主体,包括分栏标题;
  c.尾部–包括累计总数,结束标记。
4.3.3输出举例
  为每种输出类型提供例子。对例子中的每一项,说明:
  a.定义–每项输出信息的意义和用途;
  b.来源–是从特定的输入中抽出、从数据库文卷中取出、或从软件的计算过程中得到
  c.特性–输出的值域、计量单位、在什么情况下可缺省等。
4.4文卷查询
  这一条的编写针对具有查询能力的软件,内容包括:同数据库查询有关的初始化、准备、及处理所需 要的详细规定,说明查询的能力、方式,所使用的命令和所要求的控制规定。
4.5出错处理和恢复
  列出由软件产生的出错编码或条件以及应由用户承担的修改纠正工作。指出为了确保再启动和恢 复的能力,用户必须遵循的处理过程。
4.6终端操作
  当软件是在多终端系统上工作时,应编写本条,以说明终端的配置安排、连接步释、数据和参数输入 步骤以及控制规定.说明通过终端操作进行查询、检索、修改数据文卷的能力、语言、过程以及辅助性程 序等。

在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。

  ◇ 可行性分析报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。查看模板

  ◇ 项目开发计划:为软件项目实施方案制订出具体计划,应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。

  ◇ 软件需求说明书(软件规格说明书):对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的,也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求,为生成和维护系统数据文件做好准备。查看模板

  ◇ 概要设计说明书:该说明书是概要实际阶段的工作成果,它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计提供基础。查看模板

  ◇ 详细设计说明书:着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。查看模板

  ◇ 用户操作手册:本手册详细描述软件的功能、性能和用户界面,使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识,特别是操作方法的具体细节。查看模板

  ◇ 测试计划:为做好集成测试和验收测试,需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。

  ◇ 测试分析报告:测试工作完成以后,应提交测试计划执行情况的说明,对测试结果加以分析,并提出测试的结论意见。

  ◇ 开发进度月报:该月报系软件人员按月向管理部门提交的项目进展情况报告,报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。

  ◇ 项目开发总结报告:软件项目开发完成以后,应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力,此外,还需对开发工作做出评价,总结出经验和教训。

  ◇ 软件维护手册:主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明,便于软件的维护。

  ◇ 软件问题报告:指出软件问题的登记情况,如日期、发现人、状态、问题所属模块等,为软件修改提供准备文档。

  ◇ 软件修改报告:软件产品投入运行以后,发现了需对其进行修正、更改等问题,应将存在的问题、修改的考虑以及修改的影响作出详细的描述,提交审批。