软件项目文档管理和版本控制初步报告.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、建立规范的目录体系 目录体系结构图如下： SVN开发库管理(m2m)项目一源码(FSU) SVN 开发库管理(m2m) 项目一源码(FSU) 项目二源码 项目二源码 项目文档管理(docs)项目三源码 项目文档管理(docs) 项目三源码 可行性研究报告(愿景) 可行性研究报告(愿景) 项目开发计划(立项) 项目开发计划(立项) 需求(说明书)项目一 需求(说明书) 项目一 评审 评审 软件设计说明书 软件设计说明书 开发进度月报 开发进度月报 测试 测试 测试计划 测试计划 缺陷变更与追踪 缺陷变更与追踪 测试用例设计 测试用例设计 测试分析总结 测试分析总结 相关开发文档 相关开发文档 参考资料 参考资料 参考文献、技术资料客户资料其他 参考文献、技术资料 客户资料 其他 文档模板 文档模板 用户（操作）手册项目二 用户（操作）手册 项目二 项目开发总结报告 项目开发总结报告 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 ” ，对产品作重大调整，或与已发行的上一产品相比，在功能与性能上有较大改善时主版本号增加，次版本号为零，产品或项目概念全新，第一