機房收費系統（合作版）總結——技術篇（一）

標籤：解決方案   軟體工程   經驗   合作   uml   

背景：

    

    機房收費系統合作了大半年，老孟和森森走了，給我留下了一堆代碼，一個半拉資料庫，還有一堆我自己都看不透的文檔。莫名其妙的我就從小組員直接變成了項目組長，剛開始我以為很簡單，因為我覺得前期我們也很激情，在系統設計想法是一堆一堆的，比如商務邏輯架空問題，資料訪問如何最佳化問題上我們都提出自己的很多想法。但是當我重建立立信心撿起來的時候，我發現原來我在軟體工程方面忽略了好多問題，我經過一段時間的查詢資料分析發現：項目尤其是在需求和分析這兩個方面沒有意識，導致系統從一開始就進入了設計階段。

    所以，我就想針對前兩個問題，找出我想要的答案，簡單的來講，就是找出自己一套解決方案，及時這套方法存在著大量的不成熟，或者可能走入了誤區，我還是覺得我應該記錄下來，去總結，回顧我到底做了什麼。

    在這裡，要感謝王澤，無私願意協助我完成合作。所以這篇部落格裡面的方式你應該是最熟悉的，希望以後能夠一起分享項目經驗。
   下面是我的機房收費系統的解決方案：

一、需求（一）項目的可行性：針對人員大幅度調整的問題

其實這是一件我覺得很好笑的問題，因為項目的可行性在機房合作項目裡面我覺得一般很難用可行性分析的。但是，當人員出現大幅度的調整的時候，或者說只剩下我一個人的時候我需要重新評估，我是否需要新的人員幫我歸整留下的東西好讓我更好的規劃我的下一階段到底需要幹些什麼。所以我和老師申請了王澤來協助我。（當然，我事先尋求了王澤同志的同意=-=）

（二）組織圖的重要性：組織圖決定了使用者角色的重要性。

    曾經我發現項目商務程序很多時候決定了用例的擷取問題。到後來，我才警覺地發現，項目一開始最好從組織圖開始，分析清楚了參與該項目的部門結構才能夠對於參與使用者進行確定。

    如果你的項目從一開始就選擇從商務程序作為開始，然後順藤摸瓜找出商務程序中每一步驟的參與部門或者參與角色，並只是關係項目是如何走入下一步驟（包括期間的資料的流向），我可能認為你可能還是在面向流程分析裡面。
    我會建議你在分析需求的時候，先弄清有多少個工作部門和崗位，然後找到每一個崗位業務代表，問他們：你平時都做一些什嗎？這件事情是交給誰辦的？做了你需要通知和傳達給誰？需要填寫什麼表格嗎？

回到我的機房收費系統裡面來，我找了好久也不知道這個的組織圖，我覺得這可能是我的一個遺憾，如果有人知道請告訴我。

    但是唯一好處是能夠確定使用者角色：管理員，操作員，一般使用者。

（三）需求到底如何擷取：部落格已經寫完。

關於需求如何擷取我也不大想說了，部落格地址（你的第一張圖是使用案例圖嗎？）：http://blog.csdn.net/u013065023/article/details/47086749簡單說一下思路

1. 活動圖表
2. 業務分析圖
3. 擷取用例表格

4. 用例建模

（四）用例與用例描述的重要性：

1.對於用例的關係。我認為畫使用案例圖的時候要注意extend和include這兩個關係。一般來講我不是特別建議用include，因為這會破壞用例的完整性。如果使用extend這個關係，並不妨礙用例的完整性，因為是拓展關係。

2.不是搭建完所有的用例才繼續往下做，事實上，當你分析出一個用例（用例描述）的時候，就繼續往下進行。

3. 用例描述是使用案例圖的關鍵。很多人以為在用例模型中，或許使用案例圖是關鍵，事實上恰恰相反。用例描述包含了很多東西。

在我的機房裡面，下面是我的用例描述（一份文檔，一份圖），主要是關於關於用例描述主要是對於正常流：

（五）測試案例來驗證

測試案例就是根據我上面的正常流和替代流來寫的，直接吧。

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。

機房收費系統（合作版）總結——技術篇（一）