.net下具体怎么实施面向对象的软件工程(OOA/OOD/OOP)啊！
这学期有软件工程的课程，看了很多书，看的那叫一个天昏地暗，日月无光啊。
本来还能写出来个小管理系统，现在搞的再也不知道怎么写好了。
唉！
什么Case工具,Rose工具,UML,RUP，XP，用例驱动，还有什么CMM??，还有一大堆文档模板。这些东西该怎么组织啊？
这些东西能有效的协助，继而更好的进行软件开发吗?
现在我有一个模糊的框架，以用例的形式写出，望大家指正指正啊，我叩首了！
用例：实施软件工程
目标：使用面向对象的分析、设计，用vs2005环境 + C#编码，来实施一个传说中的软件工程。
级别：白云/黑土/故乡/黄河
主执行者：俺和俺的无知同学,以下简称为“MyTeam”。最终用户
项目相关人员和利益：令俺们能明显的感觉出实施软件工程相对于以前的随意性编码的优越性(我们将随意性编码美其名曰为：“矫健地”软件开发)，令最终用户欢欣雀跃。
前置条件：对最终用户游说完毕，最终用户勉强同意MyTeam做此软件系统(以及其低贱之价格)。D版VS2005 team suit 已安装就绪。
最小保证：最终用户不至于呕吐到PC旁
成功保证：项目成功，并获得最终用户认可，令软件工程老师(幕后黑手级执行者)感动不以，泪流满面。
触发事件：该帖结贴
主成功场景：
1.MyTeam对最终用户进行访谈，记录缺乏耐心之用户对业务逻辑的口头描述
2.MyTeam整理用户业务逻辑描述，撰写业务用例(海平面级/用户级/白盒)。
3.MyTeam将撰写完毕的业务用例show给最终用户查看，并得到最终用户的认可。
4.MyTeam根据该业务用例进行可行性分析，估算项目所需人/月，以及项目成本。
5.MyTeam绞尽脑汁，将业务用例进化为系统用例(概要/风筝级/黑盒)。
6.MyTeam根据该系统用例进行功能划分(划分为n个增量)、进行具体人员安排。
7.MyTeam开始对该系统的第1个增量进行较详细系统用例设计(不断扩展其子用例，子子用例...)
8.MyTeam在一批经过详细设计的系统用例中，寻觅类。
9.MyTeam根据系统用例确定类的关系、成员、以及对应的操作。
10.MyTeam使用VS.net类关系图完成类的设计
11.MyTeam根据系统用例来完成类之间的消息传递。
12.MyTeam推选出公认的编码专家(牵扯到C#的编程技巧，.net framework中类库的熟悉程度)，完成类的具体编码实现。
13.MyTeam根据用例中各个场景路径对该增量功能进行测试
14.该增量开发完毕，返回步骤7，开始下一增量。
15.所有增量开发完毕，根据系统用例(概要/风筝级/黑盒)进行功能合并。
16.MyTeam四处搜罗图标、美图、美化界面。
17.软件工程实施完毕，交付使用。
18.用户使用较满意，MyTeam收取开发费用
19.MyTeam集体挥霍费用
20.MyTeam对挥霍之剩余费用进行分赃。
扩展：
1a.最终用户业务繁忙，未联系上：
1a1.MyTeam诅咒最终用户，并伺机再次联系。
3a.最终用户自称留洋多年，阅读中文较困难：
2a1.MyTeam将业务用例绘制为UML小人椭圆图(摘要),加上mm公关对最终用户进行中国式英语解说。
3b.最终用户不认可业务用例中的部分逻辑：
3a1.MyTeam集体不爽，质问最终用户哪里不妥？
3a2.MyTeam根据用户比手划脚之蹩脚形容，重新整理业务用例
4a.业务用例太复杂，导致项目所需时间过长、成本过高:
4a1.MyTeam与最终用户进行交涉，要求缩减业务或增加软件开发费用
6a.系统用例较多，逻辑较复杂：
6a1.MyTeam使用UML包图对系统用例进行划分
9a.部分用例内部场景复杂，交互较多：
9a1.MyTeam对此用例绘制UML序列图，以协助设计
11a.一些类消息传递频繁，牵扯对象较多：
11a1.MyTeam绘制UML协作图，以协助设计
12a.具体类状态丰富，变幻莫测：
12a1.编码专家使用UML状态图协助设计
12b.具体类功能丰富，调用系统底层功能：
12b1.编码专家一筹莫展，到csdn/.net版块大喊help.
12c.具体类之具体方法牵扯到复杂数学算法：
12c1.编码专家登陆搜索引擎，搜索此算法，拷贝修改之。
13a.MyTeam时间紧迫，无暇分身进行测试：
13a1.将测试留给最终用户吧，主会保佑他的。
15a.接口设计极差，部分增量无法进行合并：
15a1.MyTeam集体鄙视编码专家，要求其昼夜不停修改代码，使之能成功合并。
16a.MyTeam部分成员在搜罗图标，美图之时浏览“成人教育”网站。
16a1.MyTeam负责人扬言扣除该成员部分应得之开发费用,并仔细询问该成员浏览其网站具体网址，以及该网站之会员帐号。
18a.用户使用最终软件产品，发现和自己想象中的完全不是一回事儿，天壤之别！：
18a1.项目失败，MyTeam集体痛哭……
相关信息：
用例驱动、迭代增量开发。使用面向对象方法(OOA/OOD/OOP)。
以上实施方案一定有很多地方不妥，希望高手们不吝指正，并强烈要求有过项目经验的前辈高人以用例的方式写出更好的实施方案。
问题点数：100、回复次数：2Top
1 楼xvhfeng（ProLogic）回复于 2006-05-02 23:43:30 得分 50
你管那么多了，上有政策，下还有政策，我觉得uml图还是要画的，只要画2个就可以了，user case和class，文档还是要写的，一个数据库设计文档（其实用pd可以生成，不用写，修改一下就能用）。一个解决方案文档，一个系统详细设计文档，就这么多就应该可以了，然后还要建立一个备忘录，在软件开发过程中肯定会遇到问题的，把修改的地方写在备忘录上，ok了，等写完了程序teams一人一篇文档，就over了！用户手册一定要设计数据库的那个人写，因为他对数据库的限制对清楚！我们teams经常就是这样做的，但是我们还有一个就是一般用vs2003，用borland together它会根据程序生成class的uml的，呵呵，比较方便。至于程序的构架基本也是根据模板生成的，一般是三层构架的！这样能大大的节约开发时间，如果一个系统在分析和设计的时候考虑成熟的话，编码只要大概2周就搞定了！Top
2 楼frank_lee_cn（Frank）回复于 2006-05-03 00:35:29 得分 50
呵，你的用例写得真好玩。
不过，一点用处也没有。
不知道你为什么要把它写成用例形式。Top
