2010年12月2日 星期四

CRC卡

物件導向分析-指定責任

n在指定責任步驟是指定類別的責任,並且列出需要哪些類別共同合作才能完成指定的責任。
n我們可以使用CRC卡來完成此步驟的工作,CRC卡是Kent Beck和Ward Cunningham發展出的技術,CRC代表類別(Class)、責任(Responsibilities)和合作(Collaborators)。

1.什麼是CRC card?

CRC (Class-Responsibility-Collaborator) Card是目前比較流行的面向對象分析建模方法。 在CRC建模中,用戶、設計者、開發人員都有參與,完成對整個面向對象工程的設計。

CRC卡是一個標準索引卡集合,包括三個部分:類名、類的職責、類的協作關係,每一張卡片表示一個類。

  • 類 代表一系列對象的集合,這些對像是對系統設計的抽象建模,可以是一個人、一件物品等等,類名寫在整個CRC卡的最上方。
  • 職責 包括這個類對自身信息的了解,以及這些信息將如何運用。 諸如,一個人,他知道他的電話號碼、地址、性別等屬性,並且他知道他可以說話、行走的行為能力。 這個部分在CRC卡的左邊。
  • 協作 指代另一個類,我們通過這個類獲取我們想要的信息或者相關操作。 這個部分在CRC卡的右邊。

image

CRC卡片的背面往往記載著這個類的詳細描述和在CEC設計中的一些注意事項。

2.如何使用CRC卡組織團隊成員?

我們可以使用CRC卡完成設計團隊成員的組織工作,但是需要限制在6人以下以提高效率,否則可能會增加溝通成本。 我們的成員組成一般有以下三類,職責、人數建議、及其特徵描述如下:

  • 用戶
    • 人數:3-5
    • 特徵:
      • 豐富的行業知識
      • 清晰的業務流程
      • 邏輯思維和良好溝通
      • 對系統設計感興趣
  • OO設計人員
    • 人數:1-2
    • 特徵:
      • 通曉CRC建模流程和方法
      • 通曉OO設計思路和方法
      • 有實際開發OO系統的經驗
  • 項目協調人
    • 人數:1
    • 特徵:
      • 良好的會議溝通和管理技巧
      • 通曉CRC建模流程和方法

3.CRC分析流程

1)準備工作:

召集人員,拿到相關業務流程的需求——Statement of work,SOW工作陳述,從SOW中提煉出需求,以項目符號列表的形式表示每一個特定的需求。

2)CRC卡的建立:

a.類對應於名詞,讀完需求分析後,你可以劃出一些名詞作為類設計的切入點。 當然,要習慣於迭代的方式,一開始列出的名詞並不見得都要最終設計為一個類,而後續可能因為可用性等需要設計額外的類。

b.我們可以通過這個名詞列表進行一一篩選分析,適當把握抽象與具體的關係,比如一個司機、一個秘書、一個經理可能都能抽象為人這個類,但是在第一輪迭代中,若無明顯的需求,我們可以先暫時不用去考慮。 對於普通的一般的關係,我們可以考慮超類的設計,也可以考慮通過構造函數重載完成。

c.在設計中,我們要注意目標之一是保證可擴展性,重構也是我們要考慮的一個隱性需求。

d.通過第一輪迭代我們就找出了我們需要關注的類。 接著我們需要明確類的職責。 職責的一個切入點是動詞,從動詞的列表中就可以得到職責初步列表,然後就行迭代。 在這個過程中,並不是每一個動詞都會成為一個職責,幾個動詞可能組成一個職責,最終選擇的一些職責可能並沒有出現在最初的職責中,對於共享的職責我們要特殊標識,以便在後續的詳細設計中特殊處理(比如Java中的接口)。

e.在完成類的職責分析後我們開始根據這些職責及其交互關係明確協作關係,我們此時可以通過用例場景(系統對用戶請求或事件作出響應時完成的一個事務或相關操作序列),對於每一個用例,明確交換的對象和消息。 在這個過程中,參與的人可以通過角色扮演的方式,既活躍了氣氛,又能在溝通交互中體現每一個類職責與協作。

f.完成CRC後就可以通過UML完成正式的初步設計了。

http://blog.csdn.net/gnuhpc/archive/2010/07/08/5720833.aspx

2010年12月1日 星期三

要徑法(Critical Path Method)

note-要徑法(Critical Path Method)

1.

尋找出專案計劃的要徑(Critical Path),以便對在要徑上的各項作業,做有效的控制。

2.

要徑法即為C.P.M.
將一個工程的各種作業項目
依照所需工期及相互因果次序關係
製成網狀圖
再將網狀圖的各種流程之中
將其中一個需要最多工期的選為要徑(C.P.M.)
再根據此要徑推算及調整其他作業項目開工的進度
以作為一個工程完工的最佳工期
並為趕工計畫的依據
不過用此法的前提是
各個工程項目的作業時間較能確定的情況


3.

(B) 時程管理由作業定義、作業排序、作業需時估算、時程發展、及時程控制五階段所組成;並以
要徑法為中心思想
(C) 利用網圖上最長的路徑來控制專案的進行
(D) 為專案管理中時程管理的技術之一

什麼是關鍵路徑

  在項目管理中,關鍵路徑是指網路終端元素的元素的序列,該序列具有最長的總工期並決定了整個項目的最短完成時間。

  關鍵路徑的工期決定了整個項目的工期。任何關鍵路徑上的終端元素的延遲將直接影響項目的預期完成時間(例如在關鍵路徑上沒有浮動時間)。

  一個項目可以有多個,並行的關鍵路徑。另一個總工期比關鍵路徑的總工期略少的一條並行路徑被稱為次關鍵路徑。

  最初,關鍵路徑方法只考慮終端元素之間的邏輯依賴關係。關鍵鏈方法中增加了資源約束。

  關鍵路徑方法是由杜邦公司發明的。

關鍵路線的特點

  關鍵路線具有以下特點:

  1、關鍵路線上的活動的持續時間決定項目的工期,關鍵路線上所有活動的持續時間加起來就是項目的工期。

  2、關鍵路線上的任何一個活動都是關鍵活動,其中任何一個活動的延遲都會導致整個項目完成時間的延遲。

  3、關鍵路線是從始點到終點的項目路線中耗時最長的路線,因此要想縮短項目的工期,必須在關鍵路線上想辦法,反之,若關鍵路線耗時延長,則整個項目的完工期就會延長。

  4、關鍵路線的耗時是可以完成項目的最短的時間量。

  5、關鍵路線上的活動是總時差最小的活動。

探尋關鍵路徑[1]

  用頂點表示事件,弧表示活動,弧上的權值表示活動持續的時間的有向圖叫AOE(Activity On Edge Network)網 。AOE網常用於估算工程完成時間。例如:

  圖1 是一個網。其中有9個事件v1,v2,…,v9;11項活動a1,a2,…,a11。每個事件表示在它之前的活動已經完成,在它之後的活動可以開始。如 v1表示整個工程開始,v9 表示整個工程結束。V5表示活動,a4和a5已經完成,活動a7和a8可以開始。與每個活動相聯繫的權表示完成該活動所需的時間。如活動a1需要6天時間可以完成。

Image:AOE网图1.jpg

  1)AOV 網具有的性質

  • 只有在某頂點所代表的事件發生後,從該頂點出發的各有向邊所代表的活動才能開始。
  • 只有在進入某一頂點的各有向邊所代表的活動都已經結束,該頂點所代表的事件才能發生。
  • 表示實際工程計劃的AOE網應該是無環的,並且存在唯一的入度過為0的開始頂點和唯一的出度為0的完成頂點。

  2)由事件vj的最早發生時間和最晚發生時間的定義,可以採取如下步驟求得關鍵活動:

  A、從開始頂點 v 1 出發 , 令 ve(1)=0, 按拓樸有序序列求其餘各頂點的可能最早發生時間。

  • Ve(k)=max{ve(j)+dut()} ( 1.1 )
  • j ∈ T

  其中T是以頂點vk為尾的所有弧的頭頂點的集合(2 ≤ k ≤ n) 。

  如果得到的拓樸有序序列中頂點的個數小於網中頂點個數n,則說明網中有環,不能求出關鍵路徑,演算法結束。

  B、從完成頂點 v n 出發,令vl(n)=ve(n),按逆拓樸有序求其餘各頂點的允許的最晚發生時間:

  • vl(j)=min{vl(k)-dut()}
  • k ∈ S

  其中 S 是以頂點vj是頭的所有弧的尾頂點集合(1 ≤ j ≤ n-1) 。

  C、求每一項活動ai(1 ≤ i ≤ m)的最早開始時間e(i)=ve(j);最晚開始時間:

  • l(i)=vl(k)-dut()

  若某條弧滿足 e(i)=l(i) ,則它是關鍵活動。

  對於圖1所示的 AOE 網,按以上步驟的計算結果見表1,可得到a1 , a4 , a7 , a8 , a10 , a11 是關鍵活動。

Image:AOE网表1.jpg

  3)求出 AOE 網中所有關鍵活動後,只要刪去AOE網中所有的非關鍵活動,即可得到 AOE 網的關鍵路徑。

  這時從開始頂點到達完成頂點的所有路徑都是關鍵路徑。一個AOE網的關鍵路徑可以不止一條,如圖7.21的AOE網中有二條關鍵路徑,(v1, v2, v5, v7 , v9 ) 和 (v1 , v2 , v5 , v8 , v9 )它們的路徑長度都是16 。如圖2所示:

Image:AOE网图2.jpg

  註意:並不是加快任何一個關鍵活動都可以縮短整個工程完成的時間,只有加快那些包括在所有的關鍵路徑上的關鍵活動才能達到這個目的。只有在不改變AOE網的關鍵路徑的前提下,加快包含在關鍵路徑上的關鍵活動才可以縮短整個工程的完成時間。

關鍵路徑(Critical Path)

參 __ 要徑法(Critical Path)。關鍵路線

a) 要徑是完成專案的作業組合中總寬裕時間為0的路徑。

b) 是把每一階段,最長的時間的作業連接起來的路線, 稱之為” Critical Path 關鍵的路線。

c) 要徑路線 (關鍵路線)(Critical Path)__ 表示在關鍵路線的每一作業, 影響整個計劃進度是否落後或提前的關鍵。它有delay 一定影響後續作業 ,以及整個計劃進度的delay 。




貳 __ WBS ( work Breakdown Structure),工作展開分解結構

a) WBS 的意思是把整個計畫作業展開成一流程圖( work flow chart ) , 以及把工作細分化的意思。

b) WBS 是系統地把工作依功能別 或性質別,來分類展開,而每一類別的工作再往一直地下展開 , 展開到最小單位作業。

c) 整個計畫展開的越仔細 , 表示越能掌握每一作業、每一次系統的進度。 可以一目了然地chec k ,整個作業流程 是否有遺漏 與利於check 整個作業進度 。

d) 每一系統或每一作業都用箭頭表示前後關係順序。 即前一作業未完成, 後一作業就無法進行。(串聯作業)

e) 同步工程 ___ 同時作業, 即表示兩作業之間沒有前後關係 可以同時並行進行。 (並行作業 )

f) x 軸是表示時間 , y軸 是表示作業關係的流程圖 。 用箭頭來表示作業的方向 與先後順序關係。

http://tw.myblog.yahoo.com/w58go/article?mid=150&prev=151&next=148

里程碑(milestone #)、查核點(checkpoints #)

在建立一個資訊系統時,應該注意一些基本的準則:

1. 固守著一套全面性的開發計畫

2. 讓使用者全程參與開發過程

3. 仔細聆聽使用者的意見

4. 將各主要里程碑製成時間表

5. 指出期間的各查核點

6. 保持彈性

7. 取得準確的成本效益資訊。

最佳的系統就是最符合使用者需求的系統。

標出主要的里程碑(milestone #)作為專案檢視及評估之用。

在這些里程碑,經理人及系統開發人員必須決定是否繼續執行本專案,或是重做某些工作,

甚至有必要回到前一階段,或是完全中斷本專案。


在SDLC模式中必須正式地評估每階段的產出及交付標的物。

在主要里程碑之間建立中間查核點(checkpoints #)以確保專案依計畫進行。

查核點的數目要恰當,太多則顯得繁複,而太少則無法收到監控的效果。



工作分解結構(Work Breakdown Structure,WBS)


WBS為細分專案所有必須執行的業務成樹狀構造,以利掌握專案全體的規模、成本、時程等的手法。

樹狀構造的最上層為專案的成果物,接著就是完成這些成果物需要哪些作業,再來就是執行這些作業又有哪些前置作業必須要做...如此一直細分到無法再細分為止。最後稱最下層的最小單位為「Work Package」。

作業結構分析之後,決定這些作業由誰負責?多少人力?何時開始?何時結束?等內容,即可完成專案的體制圖、時程表以及所需成本。這種方式,不僅可以較準確的預估整體專案的工數,在執行專案途中時亦容易掌握每個細項作業是否按照預定完成,不至於造成最後因專案時程大幅延宕、超過預算過多而使得專案失敗。

標準的專案管理理論「PMBOK」中,亦使用WBS手法細分出專案所有的作業項目。但是必須注意每項作業是否有遺漏、重複、不實、矛盾之處,投入的人員、設備是否妥當,預估的時程、工數是否正確,否則失去使用WBS的意義。


 工作分解結構(Work Breakdown Structure,簡稱WBS)跟因數分解是一個原理,就是把一個項目,按一定的原則分解,項目分解成任務,任務再分解成一項項工作,再把一項項工作分配到每個人的日常活動中,直到分解不下去為止。

  即:項目→任務→工作→日常活動

  工作分解結構(WBS,Work Breakdown Structure),以可交付成果為導向對項目要素進行的分組,它歸納和定義了項目的整個工作範圍,每下降一層代表對項目工作的更詳細定義。

  WBS總是處於計划過程的中心,也是制定進度計劃、資源需求、成本預算、風險管理計劃和採購計劃等的重要基礎。WBS同時也是控制項目變更的重要基礎。項目範圍是由WBS定義的,所以WBS也是一個項目的綜合工具。

        Image:工作分解结构.jpg

                工作分解結構


WBS的表示方式

  WBS可以由樹形的層次結構圖或者行首縮進的表格表示。

  在實際應用中,表格形式的WBS應用比較普遍,特別是在項目管理軟體中。

    Image:工作分解结构(分级的树型结构).jpg

      工作分解結構(分級的樹型結構)

  樹型結構圖的WBS層次清晰,非常直觀。結構性很強,但不是很容易修改,對於大的、複雜的項目也很難表示出項目的全景。由於主觀性,一般在小的,適中的項目中的較多。


魚骨圖(Cause & Effect/Fishbone Diagram)

魚骨圖(Fishbone Diagram)有許多不同稱謂。有人稱他為石川圖(Ishikawa Diagram),因為這方法是日本品管大師石川馨(Kaoru Ishikawa)所創。也有人稱為因果圖(Cause-and-Effect Diagram),因為

魚骨圖的魚頭通常表示某一特定結果(或問題),而組成此魚身的大骨,即是造成此結果之主要原因。

其他也可稱為樹狀圖(Tree Diagram),因為魚骨形狀與樹狀結構接近。然而,不論稱謂為何,魚骨圖都與問題解決思考流程脫不了關係,並且是一個簡單呈現結果與成因圖形表示法。

魚骨圖的使用很簡單,並且通常搭配腦力激盪法(Brain Storming)進行。首先在魚頭紀錄或寫下待解決之問題(例如不良率增加是一個問題),或是某一表徵觀測現象(例如公司營收下降)。之後,召開會議,並透過團體腦力激盪寫下大家認為造成此結果之主要原因。實際操作上,會議主持人可要求與會成員,每人先憑空想像3個原因,之後再經由小組成員系統化的分類這些原因。將相關原因歸納後之主原因即是大骨、子原因即是中骨、孫因素即是小骨。需要注意,魚骨圖繪製過程需將麥肯錫MECE原則牢記在心,見【麥肯錫的MECE與代數正交基底】,也就是說,各原因之間需要彼此獨立,且互無遺漏。

為了要將”原因”有系統的整理與分類,管理或是品質管理學上所應用的技巧可套入此架構,當成是思考與分類之基礎(亦即基底),包括Wikipedia建議之6M、8P與4S原則:

  • The 6 M's:Machine, Method, Materials, Measurement, Man and Mother Nature (Environment) (應用於製造業)
  • The 8 P's:Price, Promotion, People, Processes, Place / Plant, Policies, Procedures & Product (or Service) (應用於行政管理與服務業)
  • The 4 S's:Surroundings, Suppliers, Systems, Skills(應用於服務業)