關於部落格
  • 28489

    累積人氣

  • 9

    今日人氣

    1

    追蹤人氣

【書摘】人月神話:軟體專案管理之道

配合性,軟體架構設計沒有一定的原則與真理,必須配合人的制度,介面期望,時代變遷以及與其他領域的介接。
可變動性,上線後修改頻率相對較高,即便是完美的產品,數年後也要修改以迎合新的硬體或是制度。
隱含性,需求概念無法如幾何表示圖般(如:室內設計圖)完整揭露,使系統設計矛盾之處無法查覺。


2)附屬性(Accident)工作:泛指系統設計實作時經歷的程序。


這多年來,軟體開發環境的進步,讓附屬性工作的工作量已大幅降低,但本質性工作的困難度,卻因為它的特性而無法有效解決。不過換言之,程式設計人員將可以投入更多的心力在解決複雜概念結構


對於軟體專案開發,書中有以下建議:
1)利用大眾市場,買現成元件避免重複開發。
  慎選可塑性高的元件。


2)使用雛型法,快速製作原型。
  請捨棄完全不可行的「瀑布模型」!因為在軟體專案中,沒有完整又沒有矛盾的規格,後期的除錯很有可能是規格上的除錯!在撰寫的過程中,反覆修正錯誤的架構是必然的事,但是在瀑布模型裡,系統測試是在專案後期,此時才發現規格上的矛盾是極為危險的,但卻已經耗近開發成本,卻又交貨在即!


3)建立軟體元件庫,持續使用、測試,並擴充功能。
  據調查,設計人員會不自覺的累積自己的元件庫。(重複程度佔30%),以小組為單位其重用程度可高達75%,所以建立組織內部的元件知識庫,是可行的!絕大部分無法有效實施,是因為組織接受度不佳!完整的元件庫,前期投入成本高,有效回收多半是同類型專案的第五個專案。而且需要大量的測試,以及完整的文件。


4)持續尋覓並培養年輕一代的概念設計人員。
  好的首席程式設計師,和好的管理者一樣重要!請注意,資深不代表有潛力!需要老手協助培訓,安排較高規格的正式教育,並安排機會獨立設計,或是擔任技術領導。
  另外,也需要資深老手協助規劃明日之星的職業生涯。


軟體專案要成功,人的品質以及對於人的組織與管理,遠比他們的使用的工具或技術來的更重要!
也就是說,社會性問題遠大於技術性問題!



一邊看,一邊寫下書摘。
專案經驗與人生歷練不同,感受也有所不同。
不過,期望台灣軟體專案管理實務可以做得更好,我們這些後生小輩受教了!

對了,懶得看書的,可以先翻翻紀念版的第十八章,可以說是前幾章的書摘了!^__^




相簿設定
標籤設定
相簿狀態