软件开发辅助工具建议方案文档格式.docx
《软件开发辅助工具建议方案文档格式.docx》由会员分享，可在线阅读，更多相关《软件开发辅助工具建议方案文档格式.docx（10页珍藏版）》请在冰豆网上搜索。
2.1VisualSourceSafe6.0（VSS6）的简单工作原理
VisualSourceSafe6.0（简称VSS6）解决了软件开发小组长期所面临的版本管理问题，它可能有效地帮助项目开发组的负责人对项目程序进行管理，将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。
开发组的成员不能对该数据库中的文件进行直接的修改，而是由该版本管理器将该项目的源程序或是子项目的源程序拷贝到各个成员自己的工作目录下进行调试和修改，然后将修改后的项目文件作Checkin提交给VSS，由它进行综合更新。
VSS也支持多个项目之间文件的快速高效的共享。
当某个成员向VSS中添加文件时，该文件将会被备份到数据库中，以便所有的成员都能共享该文件。
而且每个成员对所有的项目文件所作的修改都将被记录到数据库中，从而使得修改的恢复和撤销在任何时刻，任何位置都成为可能。
小组的成员可能得到该项目的最新版本，对它进行修改，并保存一个新的版本。
VSS的项目组织管理使得开发小组的协调变得简单容易且很直观，当一个和一组文件发放给另一个成员，小组，Web站点或是任何其他的地址，VSS确保他们之间的真正共享及所选的一组文件的不同版本的安全性。
现在，越来越多的开发者可以通过他们的开发环境来访问VSS的功能。
而且VSS可以很容易地与MicrosoftAccess、VisualBasic、VisualC++、VisualFoxPro和其他的开发工具集成在一起，一旦VSS集成到开发环境中，就可以象控件一样使用，能够很好地体现出VSS的易用性和强大功能。
2.2版本管理
VSS能够维护一个文件的多个版本，包括一个从不同版本之间进行修改的记录。
版本控制包括如下方面：
•组内协调：
在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行修改，这样可以防止文件被其他成员的修改意外更新。
当然，VSS管理员可以改变此缺省设置以允许对单个文件同时有多个Checkout，并且仍禁止对他人的修改进行覆盖。
•版本跟踪：
对老版本的源代码和其他文件进行归档和跟踪，而且这些版本能够被重新得到以便进行bug跟踪或其他目的。
•跨平台开发：
支持同一代码在跨多个开发平台时的版本控制。
•重用或面向对象代码：
跟踪哪些程序使用了哪些代码可被重用的模块。
2.3版本跟踪
VSS提供版本控制和历史服务，以保证一个文件的每个版本都是可恢复的。
VSS用日期/时间戳来记录文件是何时被Checkout或是何时被修改的，它主要有三种方法来跟踪文件和项目的版本：
•版本号：
这是由VSS维护的内部数码，用户对它没有控制权。
每个文件和项目的每个版本都有一个版本号，这些版本号总是一个整数且是递增的。
•标签：
这些是用户赋给某个项目或文件的某个版本的一个字符串，可以是任何格式的长度不超过31字符的字符串。
•日期/时间戳：
它给出了一个文件何时最后被修改的信息，或者是一个文件何时被Checkin。
VSS同时支持12小时和24小时的时间格式。
2.4VSS6的一些具体优势
简单列一下VSS6的一些具体的优势
•归档和恢复：
在VSS6中这两个操作是在一个用户界面友好的VSS管理员wizard中进行的，而在以前的版本中，它们只能通过命令行来实现。
•移动文件：
当用户移动文件时，VSS6自动将该文件共享到一个新的项目中，并在原项目中将其删除。
在新项目中，该文件的属性是共享的。
•多个项目之间的差异比较：
该功能允许用户在不同的项目之间进行差异比较。
•单个文件的展开：
在以前的版本中，VSS只能展开一个目录（文件夹），在VSS6中，同时可以展开一个文件。
•快速提取：
由于VSS6在性能上的提高，现在的文件提取速度比以往VSS版本的快两倍左右。
•历史信息过滤：
VSS6支持查看那些没有标签的文件和项目的历史。
•清除临时文件夹选项：
该新功能可使用户很方便地清除临时文件夹。
•检查外部的超连接：
在VSS的较早的版本中，只有内部的超连接和项目内的跳转才得到检查，VSS6允许用户检查项目之外的超连接和跳转。
•创建打开VSS数据库的快捷键：
用户可以使用VSSExplorer中该新功能创建一个打开某个特定VSS数据库的桌面快捷键。
•HTML格式的帮助：
VSS的以往版本使用的是WinHelp格式。
2.5实施建议
2.5.1建立配置管理环境并对配置库进行分类
建议建立了三个库，分别是开发库，受控库，产品库，均由配置员来管理维护
开发库：
（机器名：
IP：
）
存放状态为初始、开发的配置项，以及各种记录
受控库：
其中受控库中按目录可以区分基线及非基线内容
存放状态为受控的配置项以及基线内容，同时存放各类工作文档。
产品库：
存放产品内容
2.5.2配置库权限划分
基本原则：
开发库权限放开给程序员，由指定程序员ADD/CHECKOUT/CHECKOUTIN；
其他成员拥有READ权限
修改原则：
一旦开发库的内容有放置到受控库，则相应的开发库中内容权限为：
管理员拥有管理权限，其他人员均改为READ权限
其他原则：
公共程序部分如SCCB组长觉得有必要，可以明确并缩小其权限范围
简单列写如下表
结构目录
描述
责任人
相关人员
权限
开发库
存放初始、开发的配置项
配置管理员
指定开发人员
其他成员
配置管理员：
R/C/A/D
指定开发人员：
R/C/A
其他成员：
R
受控库
存放基线和非基线的受控内容
产品库
注：
权限：
R-Read；
C-Checkout/Checkin；
A-Add/Rename/Delete；
D-Destroy
2.5.3备份和恢复流程
数据备份要求
•完整备份VSS安装目录下的data目录、user目录、srcsafe.ini、user.txt文件。
采用不同服务器硬盘备份（或光盘备份）。
同时填写《软件配置库备份记录》，进行记录备份日期、软件配置备份范围/对象、备份介质、备份人、备注等信息的填写。
•开发库的备份一般每周一次完整备份。
•受控库一般每周做一次增量备份，每月做一次完整备份。
数据恢复要求
•有最近备份的一份完整备份，同时有完整备份后的增量备份；
数据恢复流程
根据最近的一份完整备份作为基础恢复VSS库，搭建完后，再将增量备份用导入的方式加入，（同时注意其他方式的校验，如任务单、FTP环境内容等。
）
2.5.4版本管理
版本控制流程图
流程图说明
程序员在每次下班前必须将手头修改好的程序CheckIn一次，保证开发库的及时性，有效性。
开发库中的内容如经过评审/阶段性评审，则移埴到受控库，相应开发库中的内容将删除，如需要修改则在受控库中按照更改的规程进行。
（基线也存放于受控库中）
在受控库的内容需要发生变更时，提交变更内容到测试路径。
④工程现场发现的问题必须由工程人员经过现场测试并体现在测试报告后，连同问题单一并提交给测试人员。
⑤受控库中的内容在适当时间（如运行已稳定、版本需要做更新、补丁发布等），生成产品，入产品库受控。
2.6方案分析
2.6.1优势：
1、提供统一的任务提交平台，利于组间合作，使得开发小组的协调变得简单容易且很直观。
2、文件权限可控制
3、能够维护一个文件的多个版本，包括一个不同版本之间进行修改的记录。
4、提供版本控制和历史服务，以保证一个文件的每个版本都是可恢复的。
2.6.2劣势：
1、不能体现任务分配的情况。
2、不能对问题缺陷进行归类，不利于缺陷分析。
3方案二：
开发软件工具协助管理
3.1流程分析
3.1.1开发辅助工具流程图
开发辅助工具流程图
3.1.2流程分析
①项目经理任务分配
•项目经理直接任务分配
•开发经理任务分配
•组长任务分配
②设计人员或资深人员任务分配
•设计人员分配设计任务或开发任务
③开发人员任务反馈
④设计人员或资深人员审核，移交测试
•任务审核通过，移交测试；
•任务审核发现问题，返回开发修改
⑤测试经理任务分配
⑥测试发现问题，缺陷记录，返回开发修改
⑦测试通过，移入受控库，并从开发库删除相应记录
⑧版本发布
3.1.3版本管理
使用开发辅助工具进行软件管理，同样需要VSS工具协助进行。
版本管理在VSS工具中实现。
3.2方案分析
3.2.1优势
1、可以体现项目任务的分配；
2、可定制缺陷分类
3、直观体现对同一模块的缺陷分析
3.2.2缺陷：
1、需要VSS提供支持平台
2、需辅助工具开发和维护工作量
4、方案三：
使用TD工具进行协助
此方式只是了解有一些项目组在使用，可以协助进行缺陷记录，具体情况不清晰。
5、一些建议
上面的三种方案，可供项目组选择。
如果项目组倾向于只是提供一个统一的任务提交平台，防止因为人员变动引起的项目变动，那使用VSS工具来协助管理，短期内能够满足要求。
如果希望能进一步进行一些辅助的缺陷分析和记录，可以使用自己开发辅助工具或者使用TD来进行。
在人力比较紧张，且流程较简单的情况下，建议还是使用现成的工具来协助开发，可以省去开发和维护辅助工具的工作量
在项目过程中，计划这块的工作还是需要加强一些，计划划分的粒度尽可能再做一些细化。
项目的管理很大程度会受计划的支配和约束。
如果计划制定的太粗，会对项目期望方向造成影响。
工作量的划分粒度，在3－5天之内的计划划分是比较合理的。
如果计划的跨度大于5天，甚至有些达到一个月的计划，就需要再进行工作分解。
可以按照一个短期项目来分解，从需求、设计、模块开发等小的粒度来划分，这种对项目的整体把握也能够加强，不会让一些不可估计的工作量影响项目的整体进展。
在制定计划时，需要注意，计划不是一层不变的。
阶段结束时，计划都应该进行细化和调整。
在偏差不大的情况下，可能只是做工作方式和小范围的进度调整。
在计划与实际偏差较大的情况下，最好能进行一些必要统计和分析，一些偏差较大的项，需要重新估计。
避免后续的工作会与项目期望偏离越来越大。
对于评审通过的需求和概设，需要形成基线来管理。
形成基线后，任何随意的修改都将不被允许。
这样确保了项目的起点是正确的，后续的工作才会正确。
在确定基线时，需要注意：
基线的内容是通过评审的，没有问题的基线。
因为基线一旦发生变动，影响的范围会非常广，所有后续的工作都将受到影响。
因此，在确认基线时，评审上应严格把关，尽量确保不正确或是不能实现的需求不会流入后续的设计和开发环节。
测试和质量监督方面的工作职责需要进行明确。
对于不属于测试和质量监督范畴的内容，需要对应的设计人员和项目组内对应方面的专家对其合格程度进行把握。
单纯从测试和质量监督方面来把关，一些隐蔽问题会难以发现。
问题隐藏的越久，对项目造成的损失就会越大。
因此，在提交测试和质检之间，最好能在项目组内部做一些必要的审核，辅助软件质量的提升。
升级会员 