軟件项目文档管理与版本控制的初步报告.docVIP

软件项目文档管理与版本控制的初步报告 一、现阶段的问题： 版本与文档管理中常见或可能存在的现象： Item 1. 项目的逻辑结构不严谨 Item 2.多人修改同一个文件 Item 3.用户权限混乱或无权限控制 Item 4.上传文档的命名随意 Item 5.从服务器上获取最近版本时的疏忽 二、文档与版本管理衡量标准：效率与质量（软件的一致性、冗余程度等） 三、解决方向： 1、项目文档、文件夹结构化分类管理 2、文档命名规范化 3、操作权限控制 4、注意服务器唯一有效版本，本地备份辅助 四、初步解决办法 创建文档储存库，基于工具的资料库或是一个共享目录里建立的简单的“文件夹/文件”结构。 1、管理范围：开发库、项目文档、产品库、构建库 1） 开发库包括：A、源代码B、执行程序 2）文档管理： A、项目文档包括——可行性研究报告(愿景)，项目开发计划(立项)，需求(说明书)， 评审，软件设计说明书，开发进度月报，测试，相关开发文档，参考资料，文档模板，用户（操作）手册，项目开发总结报告 B、相关设备 C、参考资料（开发人员与客户会谈的材料，参考文献，项目结束归档时电子邮件 3）产品库 2、建立规范的目录体系 目录体系结构图如下： 3、版本与文档命名规则 1）版本V1.0至版本V2.0之间可少设过渡版本，变更量积累之一定量或阶段之后再进行版本变更。对于计划性文档、技术文档和用户文档，其版本按修改的先后顺序确定，新生成的文档第一次发行是第一版，修改后第二次发行是第二版，以此类推。 2）建立规范的文档与版本命名规则，文档控制级别为中、低的文档是不需要进行版本控制的，这些文档大都是临时性的、一次性的、中间性的文档，比如：需求调研报告，会议纪要，项目报告等。文档 控制级别为高的文档要进行版本控制。如：用户需求说明书，概要设计说明书，用户手册等，无论修改有多少次，都要求留版本记录，尤其是项目产品。 ① 控制级别高的文档命名： 《项目编号_文档名与版本号_日期_作者》， 如《SPMS_需求说明书V1.0_YYMMDD_李明》 ② 控制级别为中、低的文档命名： 《项目编号_文档名_日期_作者》，如《SPMS_第六周问题报告_YYMMDD_李明》 3）最终完成的软件版本用二位符号表示：“ s.xy”，含义如下： ① “ y ” 为第二次版本号，表示纠正错误时的版本升级，用一位数字表示：“ 1-9 ” 对上一次产品或项目的缺陷做修正，第二次版本号增加； ②“ x ” 为第一次版本号，表示增加功能时的版本升级，用一位数字表示：“ 1-9 ” ，与上一产品或项目相比，功能进行了小量的增加或修正时，第一次版本号增加，第二次版本号为零，第二版本号为零时可以省略不写； ③“ s ” 为主版本号，用一位数字表示：“ 1-9 ” ，对产品作重大调整，或与已发行的上一产品相比，在功能与性能上有较大改善时主版本号增加，次版本号为零，产品或项目概念全新，第一次完成，版本号为1.0。 4、人员职责与维护、更新 文档管理的人员可以由一个或多个团队成员兼职担任，有经验最好，职责包括： 建立、管理和执行文档标准并监控它们的状态； 确认并解决文档库中存在的问题； 确定对哪些文件进行存档或对哪些旧文件（如每周的状态情况报告在三个月以后可能就会作废）进行定期、阶段性的清理； 创建资料库的访问规则、权限； 定期对资料库进行检查，并对文档管理流程进行评估，应当确保文档管理流程工作正常而且符合公司、项目组和利益相关方的需求； 5、关于项目开发与测试等其他人员，同样需要注意文档提交、