BBS项目招募志愿人员加入

yining

本来是发了个帖子说明上传的办法的。但是论坛就是不让我贴上去。三传两传，把原文还弄丢了。所以实在没有办法。感谢base兄的总结。

yining

粗看了一下表的设计，有两点顾虑：

1。用户信息和用户权限放在一起，容易造成日后的功能升级困难。建议这部分还是放到以后再说。

2。用户表中的信息西湖过多。还是等细节设计之后再做好不好？

yining

看了一边base兄的总结，建议暂时把论题删除和用户删除两个用例去掉吧，原本没打算在第一版作。

yining

我做的系统设计，有一些数据设计。主要是根据以前那个帖子的归纳。再加上了Renderer的部分，和config文件的设想。请大家提意见。

fergio

我的email是luolh@eyou.com

base

我近来导入OOAD，时间不多，故也未曾花些时间来看一下了，因为要拼命学习再学习，年老矣，已不复当年勇喽

关于开发流程，简单来讲确实简单，然尔如果要真的开始布置一套系统的开发，却不再是那么简单的事情，主要问题在一个是规划时的边界界定（包括分析到模块），二个是工作过程中的协调，而第一个是第二个的基础，如果说边界不够清晰则在协调的时候会很麻烦，因为相互间的耦合性太强。

在协调者方面来讲，一是只擅长作设计，当然我们国内的PM一般都是从CODING开始做起，这种情况一般不多见，而且以国内目前的开发体系来讲，这种人要不就非常厉害，即可以协调得了组里的开发人员，要不就是最终流产；二是编码高手，但PM经验不足，这样子就会容易出现大包揽情况，怎么讲呢，就是比如是几个人的小组，协调者协调到最后，整个流程变成了一个人在做的事儿了。

其实对于开发及项目管理，几乎每个人都可以说一套出来，然而却不是都管用的，这也是我们与INDIA的开发最大的区别，我没有和IN人共事过，但据共事过的朋友讲，个人间的水平不相上下，但整体起来就差许多，也就是说，我们的开发大多还处在英雄时代，而没有进入到协同时代罢

偶发一些感慨，人人可批之，呵呵

开发流程，简言之：
1. 需求 这是系统开发的出发点，不管是针对客户还是自己
2. 分析 如果说用OOA的话，再加上UML的话，那么，这里面还要分许多出来
____2.1 问题域界定
________就是说要解决的问题核心是什么，以及以这个核心为中心的外围点又是什么，将问题点及相关点分开，以便于进行用例分析。
____2.2 用例分析
________通过上面的问题域界定，可以得到相关的Actor(就是与要进行开发的系统进行交互但不属于该系统的相关部分)，以及以各Actor为中心得到的Use Case(即Actor要进行的动作吧，当然不一定要将所有Actor都进行分析画图)
____2.3 用例细节分析
________或者感觉有点儿套路了吧，细节分析的时候就是使用Sequence，Collaboration等进行动作流程分析，得到Actor的请求动作及系统或是其他相关部分的响应及内部处理的一些细节，以及Object之间的关系分布，这样基本可以确定系统的动作，及Method
____这样其实应该有了个大体的开发思路了。其实，我自己一直也弄不清的是，系统本身的整体架构到底应该在哪一部分时候确定，现在我一般会在这里思考系统架构，因为我觉得在分析的差不多的时候，确实系统的整体架构是比较合适的，这样后面的类分析的时候才有比较有的放矢，但我同时也感觉到，使用的语言会对后面的设计产生很大的影响，这是对我一个问题。
3. 程序架构分析
____比如像B/S系统，比较流行的方式是MVC ModeII，然后分析下如何构建，包括像权限系统什么的，Cache机制等乱七八糟的。
4. 类分析
____其实经过上面的分析后，类已经比较完整的出现了,后面进行类的具体分析，这一部分是比较复杂的，要上下负责，而且要两面通，我现在在这里头有点儿痛，呵呵
5. 生成框架
6. 开发
7. 测试  测试要专人处理，如果可能的话，在开发的时候也要进行测试，这两种测试有区别在，不过像XP样的，提倡开发人同自己测试，在最小范围内迭代
8. 打包，发布

我写一点自己的理解在这里，因为看过及多类似的项目半途流产的，我自己也做过这样的事情，到现在还有项目挂在sourceforge那里

而现在这个BBS项目，大体思路和流程都有，但是如果说这众多人进行协同开发的话，如这样的处理方法，一般最终会失败的，这个失败不是说这个系统做不出来，而是说，达不到一种协同。

先写这少许，老朽要休息下了，体力不支呵，有谁要批评就写出来
我希望这个项目最终有非常清晰的分析设计编码打包发布的流程以及相关的文档，就是可以之为典范即可也。

毛老头曾讲过，“在内部要展开批评与自我批评”， 这是一种很好的习惯呵

另，Who can give me a Chinese document for Together? Thanks a lot. :-)

tankbig

我是个新手，但也想参加这个项目，不知能否给个机会，别外做到哪一步了，有我可以帮上忙的吗？我有自己的网站，可以供项目测试用www.honbao.com

luzhou

我报名参加，时间可以安排在周末，平时（主要是晚上）有空时也可以做做；
email：fencer_sailing@sohu.com

base

最初由 tankbig 发布
[B]我是个新手，但也想参加这个项目，不知能否给个机会，别外做到哪一步了，有我可以帮上忙的吗？我有自己的网站，可以供项目测试用www.honbao.com [/B]

一起研究下CVS好乎？：-）
我配置CVSWEB老不成功（WIN32），却亦不知为何，后面没时间来看了，需要PERL支持

yining

我的一点认识：

1。实际上，类分析并不是在架构分析之后出现的，而是在use case分析中就已经出现了。当然，在这个阶段中，我们所做的类实际上是一种high level地分析。和最后的细节设计阶段定型的类相比可能面目全非。但是，这个high level analysis是作用例分析的必不可少的基石。如果没有这个基础，整个系统设计，sequence diagram，collaboration diagram，就没有任何基础。系统架构设计也是在这个high level analysis的基础上进行的，而细节设计则是对这个high level analysis的一种细化。所以最终的产物，虽然和最初的high level analysis的结果相比差别很大，但还是有相似之处的。

但是从另一方面而言，人是个思维动物，而思维的一个最大的特征，就是跳跃性。所以，系统架构设计虽然在很大程度上取决于前面的用例分析，但是，却并不一定真的要等到用例分析做完了之后才能开始。一个有经验的设计人员在得到了项目之后，很可能脑子里已经有了一个或者几个系统架构设计的方案，所差的，只是需要结合具体的要求寻找一个最佳的解决方法。

至于类分析的方法，要看具体的开发团队而言。如果团队中的成员之间已经有相当的默契，而且大家都是比较熟练的开发人员，那么类分析的大部分完全可以交给程序员去做。反之，如果团队成员之间还没有太多的默契，而成员之间水平相差较大的话，架构设计和类分析之间的衔接就需要比较有技巧，要因人而异。