机房收费系统合作了大半年，老孟和森森走了，给我留下了一堆代码，一个半拉数据库，还有一堆我自己都看不透的文档。莫名其妙的我就从小组员直接变成了项目组长，刚开始我以为很简单，因为我觉得前期我们也很激情，在系统设计想法是一堆一堆的，比如业务逻辑架空问题，数据访问如何优化问题上我们都提出自己的很多想法。但是当我重新建立信心捡起来的时候，我发现原来我在软件工程方面忽略了好多问题，我经过一段时间的查询资料分析发现：项目尤其是在需求和分析这两个方面没有意识，导致系统从一开始就进入了设计阶段。
所以，我就想针对前两个问题，找出我想要的答案，简单的来讲，就是找出自己一套解决方法，及时这套方法存在着大量的不成熟，或者可能走入了误区，我还是觉得我应该记录下来，去总结，回顾我到底做了什么。
在这里，要感谢王泽，无私愿意帮助我完成合作。所以这篇博客里面的方式你应该是最熟悉的，希望以后能够一起分享项目经验。
下面是我的机房收费系统的解决方案：
其实这是一件我觉得很好笑的问题，因为项目的可行性在机房合作项目里面我觉得一般很难用可行性分析的。但是，当人员出现大幅度的调整的时候，或者说只剩下我一个人的时候我需要重新评估，我是否需要新的人员帮我归整留下的东西好让我更好的规划我的下一阶段到底需要干些什么。所以我和老师申请了王泽来协助我。（当然，我事先寻求了王泽同志的同意=-=）
曾经我发现项目业务流程很多时候决定了用例的获取问题。到后来，我才警觉地发现，项目一开始最好从组织结构开始，分析清楚了参与该项目的部门结构才能够对于参与用户进行确定。
如果你的项目从一开始就选择从业务流程作为开始，然后顺藤摸瓜找出业务流程中每一步骤的参与部门或者参与角色，并只是关系项目是如何走入下一步骤（包括期间的数据的流向），我可能认为你可能还是在面向流程分析里面。回到我的机房收费系统里面来，我找了好久也不知道这个的组织结构，我觉得这可能是我的一个遗憾，如果有人知道请告诉我。
但是唯一好处是能够确定用户角色：管理员，操作员，一般用户。
关于需求如何获取我也不大想说了，博客地址（你的第一张图是用例图么？）：http://blog.csdn.net/u013065023/article/details/47086749简单说一下思路
1. 活动图4. 用例建模
1.对于用例的关系。我认为画用例图的时候要注意extend和include这两个关系。一般来讲我不是特别建议用include，因为这会破坏用例的完整性。如果使用extend这个关系，并不妨碍用例的完整性，因为是拓展关系。
2.不是搭建完所有的用例才继续往下做，事实上，当你分析出一个用例（用例描述）的时候，就继续往下进行。
3. 用例描述是用例图的关键。很多人以为在用例模型中，或许用例图是关键，事实上恰恰相反。用例描述包含了很多东西。
在我的机房里面，下面是我的用例描述（一份文档，一份图），主要是关于关于用例描述主要是对于正常流：
测试用例就是根据我上面的正常流和替代流来写的，直接上图吧。
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/u013065023/article/details/48092843
