编写规范的技计划书..docx

1、前言本文档主要描写对该计划的前期阐述，说明其重要性与操作过程的前期计划。着重点描述未来《本公司软件测试规范操作手册》的深度与可操作性等问题。2、为什么要编写此规范手册首先从公司的现状来看，我们公司是刚刚起步的新软件开发公司，目前的开发主项目《xxxxx管系统》已经接近尾声。虽然属于延迟完成项目，但是却给我们带来很多可以总结的经验和教训。比如开发流程，开发文档的编写。并在此方面做了很多积极的探索。2.1分析我们公司目前软件项目在开发管理过程中的现状：存在问题一、目前的《XXX管系统》项目仍然过分分依赖少数个人的作用,没有建立起协同作战的氛围,没有科学的软件开发管理流程; 技术上只重视系统和数据库、开发工具的选择,而忽视开发规范化过程,需求变更频繁，导致即使使用同类规程,也由于可操作性差而搁浅。存在问题二、开发管理没有适时跟进。我们是一家新的软件公司，领导和项目负责人对具体的开发过程理解有限。对每一个开发过程中需要把握的结果尺度不够。片面的讲究时间效应。导致项目开发没有必要的前期可以参考的完成标准就盲目对项目进行赶进度。虽然大多按时完成任务，但不久又发现问题出现。比如：报警系统，前期客户就明确提出要求有这个功能，我们没有对该功能进行必要的分析和设计，只是在项目代码开发进行到最后阶段，才想起来后补加该功能。补加的报警功能没有明确的需要实现目的，只是根据客户的口头描述来开发，没有在前期设计时进行必要的功能流程与设计界面可操作性。幸运的是，负责该功能开发的员工处理能力比较好，很快开发出该功能的基本流程功能（如设置，修改，显示，反查等功能）。但是后来暴露的问题确实让我们应该总结的，比如等待时间，界面和整体软件的协调性，很多用户不愿意使用，以及没有上下级利用该功能进行沟通的能力等。虽然这些属于软件开发的规范流程问题，但是开发过程中对测试的忽略是很多功能没有延时和失败的根本原因。存在问题三、项目之间沟通规范性差。各个开发人员各自开发,编写的代码不仅风格各异,而且编码和设计脱节（实际上没有可以参考的相关的设计文档）。本来开发中错误在所难免, 进展早一点完成功能和晚一点的完成功能，但是因为代码开发的不规范性，别人很难对其他员工开发的代码进行快速的理解与修改。系统升级，需要修改程序，没人能看到及时更新的文档，尽管有一堆代码库，但是后来的程序员都没办法分析明白程序结构。存在问题四、接上，文档与程序严重脱节。软件产品是公司的宝贵财富,代码的重用率是相当高的,如何建好知识库,用好知识库对公司优质高效开发产品,具有重大的影响。前人留下的程序既无像样的文档(即使留下了文档 ,其与源程序也严重脱节),开发风格又不统一,就像一堆垃圾,要开发人员到垃圾中去捡破烂,从这个角度上看,开发人员的要求是合理的。存在问题五、测试工作不规范。仍然停留在业务与技术人员做测试的底水平上，传统的开发方式中。测试工作只是在我们们的一种主观愿望测试中,根本无法提出具体的测试要求,加之开发人员的遮丑,测试工作往往是只看功能点的结果，不看全局。测试结果既无法考核又无法量化,当然更无法对以后的开发工作起指导作用。存在问题六、没有成功进行项目开发的版本控制，不同的开发时间有不同的版本，但是可能就会有不同的开发人员就有不同的版本，最后由项目负责人合并的时候，变成另一个新版本。不同时期的更改都在记录在几个骨干人物的脑袋里。开发人员要手工地保持多份不同的拷贝,即使是相同的问题,但由于在不同时期提出,由不同人解决,其做法也不同,程序的可维护性越来越差。久而久之,最后连自已都分不清楚了,代码的相互覆盖现象时有发生,且这苦水还无法倾诉,因为可能怕别人笑话,甚至别人问起,还得想法搪塞,可谓费尽苦心。存在问题七、没有规范的测试说明文档，更没有规范的测试用例（其实跟本就没有）。测试人员没有具体的可以依赖的测试用例和操作步骤，无从做起。项目负责人没有提供必要的可指导的实施工作经验，没有前期的技术设计文档。所有的测试工作只能按照后期的操作说明书进行。只能进行测试工作中最简单的功能测试。对潜在的bug跟本无法预见，更不能对程序的性能提出测试结果。2.2寻求解决之道首先要说明的是，我的这个文档最终的完成后，也无法完全解决以上和以及没有列上的问题，我们是一个新软件公司，很多方面都在探索之中，我最大的愿望是越做越好。而不是越来越差，我想这也是全体员工与领导的愿望。2.2.1人员安排：我们公司的人力有限，不考虑未来数月要离开公司的人员情况。以目前的员工规模为19人，我们只算一个小型的软件开发公司。分为行政二人（经理和助理），研发组10人（如果说算部门的话也可以，只能是自我安慰一下算了。其中包括软件测试人员）。其他就是技术支持与美工组。未来的测试人员必须要独立出来，因为如果测试人员属于开发组负责人管辖的话，怎么能保证其结果