機房收費系統合作了大半年，老孟和森森走了，給我留下了一堆**，乙個半拉資料庫，還有一堆我自己都看不透的文件。莫名其妙的我就從小組員直接變成了專案組長，剛開始我以為很簡單，因為我覺得前期我們也很激情，在系統設計想法是一堆一堆的，比如業務邏輯架空問題，資料訪問如何優化問題上我們都提出自己的很多想法。但是當我重新建立信心撿起來的時候，我發現原來我在軟體工程方面忽略了好多問題，我經過一段時間的查詢資料分析發現：專案尤其是在需求和分析這兩個方面沒有意識，導致系統從一開始就進入了設計階段。
所以，我就想針對前兩個問題，找出我想要的答案，簡單的來講，就是找出自己一套解決方法，及時這套方法存在著大量的不成熟，或者可能走入了誤區，我還是覺得我應該記錄下來，去總結，回顧我到底做了什麼。
在這裡，要感謝王澤，無私願意幫助我完成合作。所以這篇部落格裡面的方式你應該是最熟悉的，希望以後能夠一起分享專案經驗。
下面是我的機房收費系統的解決方案：
其實這是一件我覺得很好笑的問題，因為專案的可行性在機房合作專案裡面我覺得一般很難用可行性分析的。但是，當人員出現大幅度的調整的時候，或者說只剩下我乙個人的時候我需要重新評估，我是否需要新的人員幫我歸整留下的東西好讓我更好的規劃我的下一階段到底需要幹些什麼。所以我和老師申請了王澤來協助我。（當然，我事先尋求了王澤同志的同意=-=）
曾經我發現專案業務流程很多時候決定了用例的獲取問題。到後來，我才警覺地發現，專案一開始最好從組織結構開始，分析清楚了參與該項目的部門結構才能夠對於參與使用者進行確定。
如果你的專案從一開始就選擇從業務流程作為開始，然後順藤摸瓜找出業務流程中每一步驟的參與部門或者參與角色，並只是關係專案是如何走入下一步驟（包括期間的資料的流向），我可能認為你可能還是在面向流程分析裡面。
我會建議你在分析需求的時候，先弄清有多少個工作部門和崗位，然後找到每乙個崗位業務代表，問他們：你平時都做一些什麼？這件事情是交給誰辦的？做了你需要通知和傳達給誰？需要填寫什麼**麼？
回到我的機房收費系統裡面來，我找了好久也不知道這個的組織結構，我覺得這可能是我的乙個遺憾，如果有人知道請告訴我。
但是唯一好處是能夠確定使用者角色：管理員，操作員，一般使用者。
關於需求如何獲取我也不大想說了，部落格位址（你的第一張圖是用例圖麼？）：簡單說一下思路
1. 活**
2. 業務分析圖
3. 獲取用例**
4. 用例建模
1.對於用例的關係。我認為畫用例圖的時候要注意extend和include這兩個關係。一般來講我不是特別建議用include，因為這會破壞用例的完整性。如果使用extend這個關係，並不妨礙用例的完整性，因為是拓展關係。
2.不是搭建完所有的用例才繼續往下做，事實上，當你分析出乙個用例（用例描述）的時候，就繼續往下進行。
3. 用例描述是用例圖的關鍵。很多人以為在用例模型中，或許用例圖是關鍵，事實上恰恰相反。用例描述包含了很多東西。
在我的機房裡面，下面是我的用例描述（乙份文件，乙份圖），主要是關於關於用例描述主要是對於正常流：
測試用例就是根據我上面的正常流和替代流來寫的，直接上圖吧。
機房收費系統（合作版）總結 技術篇（一）
機房收費系統合作了大半年，老孟和森森走了，給我留下了一堆 乙個半拉資料庫，還有一堆我自己都看不透的文件。莫名其妙的我就從小組員直接變成了專案組長，剛開始我以為很簡單，因為我覺得前期我們也很激情，在系統設計想法是一堆一堆的，比如業務邏輯架空問題，資料訪問如何優化問題上我們都提出自己的很多想法。但是當我...
機房收費系統合作版總結
歷時10多天的合作版機房收費系統終於要結束了。這次的合作開發機房收費系統是我學習軟體程式設計以來的第一次，所以，其中的感受也是頗多的。技術 既然是軟體開發，那就先從技術方面說起吧。以前總認為幾個人在一起合作開發一款軟體是一件很容易的事情。畢竟就那麼三兩個人，所以困難應該沒那麼多。可是，到了真正一起合...
機房收費系統合作版（七） 總結
歷經許很多多的磨難機房收費系統合作版最終告一段落了。在機房收費系統中的收穫我不能說自己收穫的太少了。由於相比之前不論什麼乙個階段的學習，這個階段是我收穫的最多，感悟最多的乙個階段。技術 初識框架，對它有一種莫名的好感，非常是喜歡。也從這個好框架中感受到了自己的與xs，lsh他們的差距。他們是搭這個架...