编写的初衷和目的
我是在一家小公司做VC开发的，这里没有协作没有架构也没有软件工程，纯粹是玩个人英雄主义，工作效率和项目成功率很低，当然工作很轻松。我是个不安分守己的人，在做了一个程序后，突然发现自己的效率很低下，代码也很难看，没有封装，没有计划，碰到问题了随时会推翻以前写的东西，思路也是想到那里写到那里。在做完后我就总结经验教训，突然发现把程序开发过程文档化可以很大的提高效率。于是我翻阅了一些文档和不少网络上关于印度开发的文章，也了解了下CMM，感觉文档化是我的一个解决办法，后来经过我的进一步考虑发现文档化的作用不只是仅仅这样，他能够把我们开发人员那些看不到的虚拟化的项目经验实体化的表达出来，这样不但能很大的提高效率 对企业对个人对程序员来说这些资产会产生无法估计的价值。能够避免很多弯路。在下面功能的描述上我会详细说我添加这些功能时候的原因。
我粗略的看了看CMM，因为我觉得CMM主要是针对管理阶层说的，对企业有用，所以我就看看他的思想。CMM的目的就是实现软件过程的改进（SPI），从而提升软件组织的核心竞争力，取得竞争优势。说白了就是建立系统、全面、规范、正确的项目文档，利用不断积累的以往经验来对现在的项目加以判断，因为这样的判断不是靠想象的，是利用以往的经验为依据所以很大的降低失败率。我听说印度大公司都起码有几屋子的历史文档，当他们公司要对一个项目做判定的时候就拿出相似的旧项目来做依据下判断，因此极少出错。
了解后我就想，这些文档对公司对项目很有用，但是对我们这些单个的程序员有什么用呢（除了项目经理）？我们最关注的就是自己的经验，这些这些文档里是很少的。况且公司基本不可能给我们看这些文档。于是我就想，要是我们这些开发人员能把自己的思路和程序文档化，对公司来说，一个软件因为被文档化了，那么不管这些开发人员去了哪里 都不会对这个软件的维护带来一丝的困难，这无疑对软件的升级和维护是个大福音，况且现在人员流动也太频繁。企业要维护的时候，只要翻出当时程序思路的文档，代码不用翻看就能够确定哪些地方出了问题，极大提高生产率。对我们开发人员来说，当我们接到项目后，去翻阅以往公司类似项目的程序思路文档，不但可以迅速对自己的项目有整体印象，还会知道那些容易出问题，如何避免，如何编写，因为这些都很明确的标在了文档中。再说无聊的时候翻翻，前人的经验就可以迅速的成为自己的经验，不用非做了这样的项目才会了解。
在通过CMML3公司的员工，会发觉其实他们每天都在做这样的事。每天填写表格，我无缘欣赏他们填写的表格到底是什么样子，很想看看。但是在绝大多数公司，这些都没有实现。中软公司--纯软件公司，有3000员工，在中国算是电子商务前10强的，我了解到他们也没有实现文档化，最多写个周报罢了，不过听说他们在开始实施文档化了，可能也想冲CMM认证把，毕竟做外包有CMM认证就是金招牌。听说化为在2001/12过了CMM4 。现在不知道过没过CMM5。我就是把CMM的思想放到了我们开发人员中。因为我是个新手，所以大多数上都是理论，所以请前辈们订正。
我觉得制定了相应的文档制度后，就必须执行，可能一开始觉得麻烦，根本没必要，但是时间长了就习惯了，就会发觉出其中的价值。我1开始也是很轻视编写文档的。
说实话，我只是很无耻的把各位前辈的关于项目的经验和各种渠道得来的关于项目开发的经验总结到一起罢了。希望大家给我指点 ，不要嘲笑我。
此需求分析提供给自己和对此项目有兴趣的人员观看。此需求分析说明书描述了想要实现的功能和这些功能可能会起到的作用。
目的：编写此软件是副，主要是想通过这个软件了解软件工程和养成程序文档化的习惯 背景
项目名称：开发人员经验累积系统
愿望：要是这个项目真的有用，渴望能在INTERNET上搭建个服务器，所有的程序员共享自己的项目信息，这样就没有什么新老手的区别了把。幻想ING。。。。。。。。
任务提出者：本人
开发者：未确定，如果大家有兴趣可以一同来做
用户：企业单位（我们单个程序员实在没用，不能自己积累给自己看把呵呵，再说也有限）
使用语言：VC6.0 C/S结构 参考资料
CMM的各种说明文档
计算机软件产品开发文件编制指南GB 8567-88
计算机软件需求说明编制指南GB 9386-88
计算机软件测试文件编制指南GB 9385-88
计算机软件配置管理计划规范GB/T 12505-90
计算机软件质量保证计划规范GB/T 12504-90
计算机软件可靠性和可维护性管理GB/T 14394-93
质量管理和质量保证标准 第三部分GB/T 19000 3 94
任务概述 ：
通过编写这个软件，也希望能规范自己在编码时候的思路和方法。尽量让自己少出错 软件功能：
功能分好多模块，因为是初稿，所以我列下我现在整理的模块：
1．项目分析模块（这个模块的使用者主要是项目经理级）
这个模块和需求分析不太一样，因为考虑到公司基本都直接编写需求分析，所以就没有设置需求分析模块。
此模块就是对当前项目规模、参与人员等的一个大概介绍，以便方便检索以往类似项目。
2．需求追踪模块 （系统分析员）
本来我感觉这个模块可以和进度跟踪模块或者质量审核模块放一起，但是考虑每个项目的需求更改一般都很频繁且对项目成败有直接影响，我就觉得应该单独放，这样可以根据以往的项目经验了解类似项目一般都会有什么样的需求更改，以便提前做准备。
3．概要设计模块 （这个模块的使用者主要是项目经理，4．开发员也适用）
说大白话就是项目的架构，说多了大家会说我乱忽悠人。就是对此项目模块的设计，一看就是项目经理、架构师干的活。也是我一直渴望的职业。这个模块里要写到自己采用的架构、分出来的模块、这个架构的优点和采用这个架构的依据等等。
5．子模块设计模块 （主要使用者：负责相应子模块的开发人员）
分配到普通开发人员手里的模块任务。也是我现在做的工作。这里主要写的是开发人员在写程序时候的思路、函数方法的设计、函数方法的思路、封装的设计、采用的技术、数据结构等等，当然必须包括这么做的原因。要求很详细，有点类似流程图和UML但是要比他们详细，让其他人看到你的描述不用看代码就知道你代码里都有什么东西。这个和印度的思维模式有点相似，一开始可能觉得麻烦、烦琐，但是我觉得等适应了就会发觉其中的好处，你程序出了故障，起码会成倍效率的修订。当写的程序有几十上百个文件的时候，你不能迅速的想起任何一个文件是怎么写的，还是需要去翻翻代码的。据说微软做MFC的开发人员都不知道他们曾经写过什么函数。
6．BUG收集模块 （此模块适用于模块开发人员）
类似现在流行的BUG报告文件，我在这里把他们和子模块紧密结合起来了。要能方便的了解到相应模块都碰到过什么BUG。
7．测试模块 （测试人员）
这里测试的BUG是整个项目级的或者不轻易被发现的BUG，比“BUG收集模块”里的BUG高1个级别，比如单个模块运行的时候正常，整合就出现的BUG。项目经理、架构师等关心的BUG。
8．进度跟踪模块 （项目经理或相关人员）
项目经理、管理层按预定的进度来检查各个子模块是否按计划实施。
9．质量审核模块 （测试等相关人员）
子模块的质量评测
10．项目总结模块 （项目经理）
交付任务后，对项目做的总结，包括项目的评价和员工的评价
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
Re:[分享] 实现软件开发过程中文档化的思路
[回复于 2006/11/6]
