我对文档化开发过程的理解

[tsrt]

软件需求说明书
                                
编写的初衷和目的
我是在一家小公司做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

[tsrt]

任务概述 ：
通过编写这个软件，也希望能规范自己在编码时候的思路和方法。尽量让自己少出错

软件功能：
功能分好多模块，因为是初稿，所以我列下我现在整理的模块：
1． 项目分析模块（这个模块的使用者主要是项目经理级）
这个模块和需求分析不太一样，因为考虑到公司基本都直接编写需求分析，所以就没有设置需求分析模块。
此模块就是对当前项目规模、参与人员等的一个大概介绍，以便方便检索以往类似项目。
2． 需求追踪模块 （系统分析员）
本来我感觉这个模块可以和进度跟踪模块或者质量审核模块放一起，但是考虑每个项目的需求更改一般都很频繁且对项目成败有直接影响，我就觉得应该单独放，这样可以根据以往的项目经验了解类似项目一般都会有什么样的需求更改，以便提前做准备。
3． 概要设计模块 （这个模块的使用者主要是项目经理，4． 开发员也适用）
说大白话就是项目的架构，说多了大家会说我乱忽悠人。就是对此项目模块的设计，一看就是项目经理、架构师干的活。也是我一直渴望的职业。这个模块里要写到自己采用的架构、分出来的模块、这个架构的优点和采用这个架构的依据等等。
5． 子模块设计模块 （主要使用者：负责相应子模块的开发人员）
分配到普通开发人员手里的模块任务。也是我现在做的工作。这里主要写的是开发人员在写程序时候的思路、函数方法的设计、函数方法的思路、封装的设计、采用的技术、数据结构等等，当然必须包括这么做的原因。要求很详细，有点类似流程图和UML但是要比他们详细，让其他人看到你的描述不用看代码就知道你代码里都有什么东西。这个和印度的思维模式有点相似，一开始可能觉得麻烦、烦琐，但是我觉得等适应了就会发觉其中的好处，你程序出了故障，起码会成倍效率的修订。当写的程序有几十上百个文件的时候，你不能迅速的想起任何一个文件是怎么写的，还是需要去翻翻代码的。据说微软做MFC的开发人员都不知道他们曾经写过什么函数。
6． BUG收集模块 （此模块适用于模块开发人员）
类似现在流行的BUG报告文件，我在这里把他们和子模块紧密结合起来了。要能方便的了解到相应模块都碰到过什么BUG。
7． 测试模块 （测试人员）
这里测试的BUG是整个项目级的或者不轻易被发现的BUG，比“BUG收集模块”里的BUG高1个级别，比如单个模块运行的时候正常，整合就出现的BUG。项目经理、架构师等关心的BUG。
8． 进度跟踪模块 （项目经理或相关人员）
项目经理、管理层按预定的进度来检查各个子模块是否按计划实施。
9． 质量审核模块 （测试等相关人员）
子模块的质量评测
10． 项目总结模块 （项目经理）
交付任务后，对项目做的总结，包括项目的评价和员工的评价
上面是我对各模块的大概总结，下面我详细说各模块要实现的功能：
项目分析模块
1 项目描述：包括项目名称、项目规模、项目提供商
2 项目功能描述：要实现的总体功能
3 参与人员：人数、名字、技术水平
4 预计完成时间、交付期、接项目日期
5 要求的软件质量
6 与此项目类似的以往的项目经验
7 根据以往项目经验和新项目的特别预期做出的承诺（日期、质量、费用等）
8 参考资源
9 备注：上面没有涉及到的，以及随笔
此模块主要是在项目进行前填写完毕
需求追踪模块
1 项目运行中更改的需求的详细信息 以及应对之策
2 是否考虑到此需求的变更
3 是否采取应对此需求变更的措施
4 引发此需求变更的原因
5 是否采用了应对需求变更的策略
5 教训：针对出现的需求变更所吸取到的教训
6 备注
概要设计模块
1 采用的架构以及依据
2 备用架构
3 项目中可能设计到的新/旧技术
4 模块设计：项目中所有出现的模块以及之间的联系
说明各个模块/子程序的设计考虑以及各模块的意义
5 接口设计：包括用户接口：想用户提供的接口；内部接口：系统内部个模块之间的接口；外部接口：提供给外界程序的接口
要求写出接口详细的名称 参数类型，返回数值类型和返回值的意义
6 运行设计：包括：1。运行模块组合：对系统施加不同的外界运行控制时，所引起的各种不同的模块组合；2。运行控制：模块运行方法和操作步骤3。运行时间：各模块所占据的资源和时间
7 说明所有可能出现的错误以及故障情况，系统输出信息的形式、含义和处理
9 应急措施：防止出错采取的措施
8 项目计划：各模块完成的时间
10 系统维护设计
子模块设计模块
1 简介说明设计此模块的设计考虑、功能、整体思路、工作人员
日程安排、预计完成时间
预计进度、实际进度、延迟/提前原因
2 写出本模块内每个函数的名称、变量、标示符、返回值、参数类型
3 对各函数的简要说明以及目的意义、特点（是否并发、是否常驻内存等）
4 函数的功能：采用 输入-----处理---输出的形式说明
5 性能：对该程序的性能要求如：精度、灵活度、时间性等的要求
6 输入项：给出每个输入的特性：名称、标识、数据类型、格式、有效范围、数量、频度、保密条件
7 输出项：给出每个输出特性
8 算法：详细说明本程序的算法，具体计算公式和计算步骤
9 流程逻辑 说明本程序的逻辑思路流程
10 接口：说明本程序所涉及到的上一层模块和下一层模块字程序，说明参数复值和利用方式。说明和本程序直接相关联的数据结构
11 存储分配
12 测试计划：对本程序所进行的单体测试计划，包括对测试技术要求的输入数据、预期结果、实际结果以及差异
13 进度安排、人员职责、设备
14 未解决的问题描述
15 备注
BUG收集模块
此模块类似网络上流行的BUGFREE软件，主要描述出各模块每天碰到的BUG以及解决的情况。包括：BUG所在模块名称、BUG的错误等级、BUG描述、BUG分类、BUG操作碰到的人员名称、解决人的名称、解决思路、滞留时间（BUG存在时间）、备注

进度跟踪模块
1检查模块时候是否发现与要求产生差异
2 产生差异的原因、此差异是否对程序进度有危险 如何变更
3 如何调整差异 是否需要更改计划
4 工作计划
5 预计进度及修订、实际进度及修订
5 备注

[tsrt]

因为我对软件工程了解很少 所以请大家多批评

[tuti]

CMM在小公司是行不通的, 还是去研究一下"极限编程"会对你跟有帮助

[tsrt]

先不说大小公司拉
就说我这个思路把

[tuti]

CMM的思路都是死路一条.无数实践都证明了这点.
你可以找些有CMM经历的人问问.

[liu9822]

呵呵
看了！有点意思

[Frank6600]

写得非常好！
继续加油！

[FengSC]

管理的目的不是让程序员更有创造性，而是把软件开发这一非常有创造性的工作，变成和折火材盒一样的简单、机械，这样公司就不会依靠少数的开发人员，换句话说，可以少发工资，你不干，换个人一样的干。悲哀啊，我也是从程序员走过来的，现在要这么残酷的对待那帮年轻人。。。。。。

[yishiwang]

建议你看下xp,真的


-----------------------------------------------
www.yishiwang.com 国外项目网站汇总

[qiangpipi]

顶FengSC(小猪快跑)
CMM在中国是不需要的,我们有的是人

XP不是不要文档,XP不是什么规范都没有.为什么有XP或者AGILE?他们会比正常开发快?快在哪?合理性.所有的工作都以合理为基本原则.
规范和先进的理念一定要学习,但是工作和现实生活也绝对不能放弃.早晚会找到这两者最好的契合点.坚持

[susanadams]

回复上面提到的对XP和Agile开发模式的说法：“为什么有XP或者AGILE?他们会比正常开发快?快在哪?合理性.所有的工作都以合理为基本原则.”
不能同意，agile模式就一定快于传统模式，其实从时效看来，传统瀑布式或许更快，这个以后有机会我们说。
agile模式最重要的特点是灵活，灵活应对需求变化和团队适应能力强。agile模式带来一种风险下放的成功模式。

[Frank6600]

> CMM在中国是不需要的,我们有的是人

今天在《新结婚时代》看到一句台词：

是，中国有的是「人」，但中国缺「人才」。

[wesley0423]

不错。有启发.

[hatest]

对于单位自己内部开发系统,用xp不错,因为需求可以慢慢来呀,对外做项目,用xp?需求永远完不了,死跷跷...