这次的对话较长，不过，我也不想拆成所谓的多篇来一起发表，赚点击数并没有什么意思，呵呵。有耐心的朋友可以一个一个看，没有耐心的朋友可以看看标题然后选择性的看。
对话
文档模板和阶段的输入输出
2007-05-23 11:36:58 伊达
青润，采用全程建模时候，所需要出的文档资料，都有哪些？有成型的模板吗？
2007-05-23 11:38:32 青润
模板我没有制作，但是有哪些文档是有一个基本描述的，比如我那次给你们做培训的培训ＰＰＴ里面就有．
2007-05-23 11:39:16 伊达
我们现在开发所用的文档，基本跟 国标的那种差不多，感觉和OO分析、设计差距较大。
2007-05-23 11:39:36 伊达
你上次给的文档，是基于RUP出的？
2007-05-23 11:39:58 青润
ｐｐｔ里面对每个阶段的文档都作了说明的，你没看到么？
2007-05-23 12:06:02 伊达
我再看看
2007-05-23 12:06:10 青润
好的．
2007-05-23 12:06:17 青润
如果没有找到，我再发给你．
伊达 2007-05-23 12:06:35
伊达 2007-05-23 12:06:48
正在看着 ，是这6篇吧？
青润 2007-05-23 12:06:51
对
伊达 2007-05-23 12:06:53
有更新吗？
青润 2007-05-23 12:07:03
最近应该没有什么新的更新．
青润 2007-05-23 12:07:14
我打算把这些上传到ｂｌｏｇ上，供大家下载
伊达 2007-05-23 12:08:33
里面提到的：“输入输出
需求调研工作没有具体工件的输入，因为它是整个工程活动的第一步。
需求调研的输出工件有：用户方相关业务规范文档、业务操作手册、用户房岗位职位说明书、调研记录和用户确认信息
”
青润 2007-05-23 12:08:49
对，就是这个内容．
伊达 2007-05-23 12:08:53
输出工件有：用户方相关业务规范文档、业务操作手册、用户方岗位职位说明书、调研记录和用户确认信息，这些有没有配套的模板？
青润 2007-05-23 12:09:06
模板我没有做，这个可能要大家自己做了． （注：其实我自己有一些定义的内容，但是，个人认为不同的项目对需求的要求都会有些不同，建议最好是根据项目的情况对每次的模板都要进行少量的调整和修改，这样才能最大限度地让模板能够符合用户的理解，毕竟需求在一个重要的侧面上是要让用户能够理解的）
青润 2007-05-23 12:09:22
用户方相关业务规范文档、业务操作手册
这两个是用户直接提供的
青润 2007-05-23 12:09:45
用户方岗位职位说明书
这个用户可能有，也可能需要我们自己来写，毕竟新的岗位会对原来的职责产生一定的冲击，和修改
伊达 2007-05-23 12:09:50
或者把这个文档要包括的要素(目录)写出来也可以
青润 2007-05-23 12:10:10
调研记录和用户确认信息
这两个的模板应该就不需要了，每个公司都必须有自己的调研记录信息的模板，用户确认信息，就看自己的本事了．
青润 2007-05-23 12:10:37
其实，最好的调研记录应该分为两个部分．
青润 2007-05-23 12:11:12
一个是调研录音，现在录音笔也很便宜了，买两个配给调研人员使用，让他们在调研的过程中作语音记录，也方面后续的整理．
伊达 2007-05-23 12:11:21
这些都有。类似于“可行性研究报告”“规划书”“需求说明书”“总体设计”“详细设计”“测试用例”等这些，最好有与‘全程建模’配套的模板，到时候能自动生成最好。
青润 2007-05-23 12:11:28
令一个是调研纪录，也就是整理出来的东西，这个就应该根据情况来说了．
伊达 2007-05-23 12:11:51
是的，录音比较重要，我们现在也给调研人员配了。
青润 2007-05-23 12:11:56
恩．
文档自动生成和模板定制
伊达 2007-05-23 12:12:22
rational 不是有个SODA工具，可以自动生成文档吗？
青润 2007-05-23 12:12:44
比如可行性研究报告，从来都是骗人性质的，只是为了给领导看的，实际意义不大．能做的都是大家认为有把握的，而不是没把握的东西．
而且，目前很多东西都是技术上很简单的，没有太多技术难度的产品．
青润 2007-05-23 12:12:51
ｓｏｄａ根本不好用，就不要考虑．
青润 2007-05-23 12:13:08
他们也是在定义好的模板基础上使用的，而如果遇到了模板里面没有的东西，一样不能使用．
伊达 2007-05-23 12:13:15
ｓｏｄａ里面的模板，能不能改造一下。
青润 2007-05-23 12:13:19
或者遇到了事先没有定义好的东西出现，照样出问题的．
青润 2007-05-23 12:13:42
ｓｏｄａ没有模板，
模板都是ｒｕｐ里面提供的，你可以考虑参考ｒｕｐ的模板自行裁减．
伊达 2007-05-23 12:13:48
最好把模型和文档能结合起来，不要出现两层皮的情况。到时候模型变了，文档还是旧的，就成没用的了
青润 2007-05-23 12:14:55
文档的数量其实越来越少，只有前期有一些，后面的都尽量使用模型文件了．
尤其是在不需要用户直接参与的阶段或者工作中，基本上不考虑纯文档的交接方式．
文档和模型
伊达 2007-05-23 12:15:19
你现在写项目文档怎么写？ 先做模型，然后根据模型内容整理成文档？
青润 2007-05-23 12:15:34
看什么阶段了．
青润 2007-05-23 12:15:50
需求阶段肯定还是先有文档的，模型只能逐步推出．
青润 2007-05-23 12:16:17
因为从用户方收集来的资料，都必须进行分析和整理，这些文档是第一步出现的，但同时模型就开始绘制了．
系统建议方案或者系统规划
伊达 2007-05-23 12:16:24
项目还未确定之前，用户只是有个大致的想法，这时候不是要出《系统建议方案》吗？
青润 2007-05-23 12:17:06
这种方案说实话，很多都是骗骗人而已，意义不是很大，用户如果想做，不写，也一样．
用户不想做，写得再好，也没人看．
青润 2007-05-23 12:17:43
我认为关键是让用户认为你有能力作，同时，用户也真的想做．
由这两点，然后再去配合一些简单的文档，效果可能更好．
伊达 2007-05-23 12:17:53
至少得有个东西，否则多家公司都来竞争，用户那边还想听汇报或者给上级领导汇报用
青润 2007-05-23 12:18:27
呵呵，既然是用户要给上面写的东西，那就不是我这个方法论里的东西了．那些都是表面文章的内容，找人写的丰富一些就是了．
青润 2007-05-23 12:18:37
这些东西对于实际项目的开发没有什么意义．呵呵
伊达 2007-05-23 12:19:13
有时候他们自己也要 把大致意思一说就让回去出个方案
伊达 2007-05-23 12:19:32
很多时候他们自己也不确定 范围多大。
青润 2007-05-23 12:19:37
是的
这是用户的一贯手法．你只要明白了，按照他的想法堆砌出来一个就是了．
青润 2007-05-23 12:19:47
当然，该务实的地方，还是必须要务实．
青润 2007-05-23 12:19:52
这样也就差不多了．
伊达 2007-05-23 12:20:05
呵呵
阶段结束标志和迭代
伊达 2007-05-23 12:20:18
全程建模各个阶段的结束标志，有吗？
伊达 2007-05-23 12:20:35
例如：需求阶段如何才算结束了？分析阶段如何才算结束了？
青润 2007-05-23 12:21:20
因为是迭代化开发的建议，因此没有明显的结束标志，主要还是看工件的完成情况，比如需求真的全部做完了，这个可能性不大．但是，需求模型完整了，我要求的东西都有了，就可以算是一个阶段点了，或者说是基线版本吧．
伊达 2007-05-23 12:23:31
因为以前很多开发过程，基本都是基于 瀑布形式的，所要求出的文档，也是 顺序进行的。例如以往在 需求阶段，完成了《需求说明书》和《demo》，并得到了用户的评审，就算需求阶段结束了。而采用迭代方式开发，感觉以前的 计划安排、文档、结束标志都有些混乱，得重新理顺了才行
青润 2007-05-23 12:24:37
呵呵，那是你用的还少，如果你能够明确出每一个迭代的产出和任务，那么，你的迭代就不是混乱的了，而是十分清晰的了．
如何使用基线
青润 2007-05-23 12:25:04
另外，记得要使用基线，这个很好的名称，定义好每一个基线，对于所有的开发人员都是一种鼓励和激励．
伊达 2007-05-23 12:25:33
基线是不是就是 一次迭代的结束产物？
青润 2007-05-23 12:25:46
不是的
伊达 2007-05-23 12:26:04
基线 具体是什么？
青润 2007-05-23 12:26:07
这个我记得培训的时候我说过，呵呵．
基线是针对一些已经稳定在各个阶段的版本的一次汇总．
青润 2007-05-23 12:26:39
甚至我们可以把基线当作一个阶段的任务完成来考虑，只是这个阶段完成的时候，各个功能的版本处在不同的开发阶段上而已．
青润 2007-05-23 12:27:30
比如，我们可以要求功能Ａ在第一次基线版本形成的时候处于代码编写完成的状态，而功能Ｂ处于测试完成状态，而功能Ｃ则处于需求调研完成状态．等等
青润 2007-05-23 12:27:54
一个迭代里面可以设定多个基线，但是，一般小项目一个迭代一条基线就足够了，不需要那么复杂．
伊达 2007-05-23 12:28:01
基线是基于什么来定的？
伊达 2007-05-23 12:28:08
根据 迭代 还是 根据用例？
青润 2007-05-23 12:28:14
都不是．
青润 2007-05-23 12:28:26
它是根据你的开发进行状态的计划来考虑得．
青润 2007-05-23 12:28:47
或者说，回退到这个基线的时候，你可以保证你的所有版本都是稳定可靠的．
基线与版本号
伊达 2007-05-23 12:29:48
那不相当于整个系统完成后的1.0版本的多个前身？
青润 2007-05-23 12:29:57
可以这么认为．
伊达 2007-05-23 12:30:37
相当于最终完成系统的 0.1版->0.2版->……->1.0版，类似于这样的？
青润 2007-05-23 12:30:52
对，这样认为也是没有问题的．呵呵
青润 2007-05-23 12:30:59
关键看你的管理者如何定义了．
青润 2007-05-23 12:31:57
在我的版本号码管理上，０．Ａ．Ｂ
Ａ就相当于基线
Ｂ相当于修订，而且不稳定的状态
伊达 2007-05-23 12:32:26
定义 基线，用户是否能认可？用户那边是否能看到该基线的具体的内容？
青润 2007-05-23 12:32:36
每一次稳定的状态，修改Ａ，不稳定状态下的每次修改都是Ｂ，而常规见到的ｂｕｉｌｄ次数，应该是整体构建的次数。
青润 2007-05-23 12:32:55
当然你可以让他们看到，也可以让他们看不到，具体的就看你如何管理了。
青润 2007-05-23 12:33:36
我认为让他们看到会更好一些。
就像我修订的电信集团的那个规范，
他们仅仅是看到了我的修订次数，就已经都认同了我的工作。
青润 2007-05-23 12:33:54
这其实是一种心理分析的对抗战术，而不是战略策略。呵呵
伊达 2007-05-23 12:35:24
A B的修改，都放在‘文档版本控制’里面就行了？
青润 2007-05-23 12:35:36
对
青润 2007-05-23 12:36:30
你把这些都放进去，让用户看到，让你的技术人员也能看到。同时将这些和配置管理工具里面的修订与提交内容配合，就可以统计工作量。
这都是对整个团队和公司有好处的保留。
伊达 2007-05-23 12:38:46
文档版本控制是针对整个系统，还是针对某个文稿？
青润 2007-05-23 12:39:32
版本管理对这两个都有效。
文档的版本管理肯定是针对文稿的
伊达 2007-05-23 12:39:54
哦
发表于 @ 2007年05月25日 09:57:00|评论(loading...)|收藏