IT肥蝦-經濟&科技&專案管理

(一)思考為一種人人都能培養的技能

(1)我們必須將負面思考放在該有的位置上，作為整體思考的一部分，但將創造性、建設性和計畫性思考擺在負面思考之前。

Organizational Structure and Project

品質規劃(Quality Planning)、品質保證(Quality Assurance)與品質控制(Quality Control)在台灣的工作環境中，除非有一定規模或一定制度的公司，遵循一定的品質作業規則，不然很難體會軟體專案中品質管理的程序與作業。最最簡單的一個問句：「您們工作團隊，是否有程式撰寫作業準則或者變數編碼規則？」這也是國珍與東豪同學對於軟體專案品質管理的疑問？我們是否真正的重視與落實品質管理？還是它只是一個空頭的名詞，以讓公司可向客戶多爭取點專案的經費？

【軟體專案管理】書本上將軟體品質定義為：軟體產品整體的功能和特性滿足既定需求的能力。更白話一點的說，就像日本的Mint(經營情報研究會)所著，周明憲所譯的【軟體工程實務】所寫的：「(1)正確的運作。(2)不會當機。(3)容易使用。(4)回應快速。(5)易於維護。(6)易於移轉。」這些要求可概括的區分為功能性與非功能性的要求；就過程而言，就如Deutach與Willis(1988)所分別的程序品質(Process Quality)與產品品質(Product Quality)。

Software PMIS’s Functions

上週軟體專案管理實務課程，第五組的炯佑同學特別上網找了有關於Earned Value Management的一些公式。肥蝦此處只是將PMBOK 2008上的有關公式整理一下，並且對於課堂上所舉出解釋EVM的圖形提出自己的看法；另外對於此次新加入的EAC預測計算式，也提出肥蝦的初步構想。

(1)PMBOK 2008計算公式

第五組志偉同學在介紹第七章監督與控制第一節導論之時，列示了書本上對於專案控制的定義－「比較、分析實際專案進度與規劃專案進度的差異，進而評估可能的備選方案，並且採取必要的行動。」針對專案監督與控制的定義，肥蝦對於書本的定義竊為過於含混，雖然標明了監控在於比較分析專案(管理)計畫所設定的基準(Baselines)與實際進行作業狀況的差異；但是對於其他必要的活動述及甚少，僅說明了：「進而評估可能的備選方案，並且採取必要的行動。」實在非常的不明確。因此，以下就Monitoring and Controlling在PMBOK與CMMI-DEV的說明中加以進一步說明。

『CIO的困境』案例心得分享

【軟體專案管理實務】第四組的彥宇與誌源同學非常好心的從哈佛商業評論雜誌中捉取了一個洋案例－【CIO的困境：誘騙加入 未必持久】－供同學們課堂分組討論；課後並印發同文中四位洋專家的建議供大家參考醒思。肥蝦此組中的錦崇同學現任某大型連鎖賣場的資訊主管，對於該案例的情境實是感同身受，因此由他上場發表高見。其實每組同學的發言都切合要點，句句也都是真知灼見，授課的李老師也發表了三點意見帶領學生一窺其中的堂奧。不意，因為肥蝦老是愛在課堂上暨每週繳交的報告中亂放炮，所以李師”鷹”明的要肥蝦於下週課堂發表自己的看法。唉！怪也只能怪自己蝦嘴太”貝戈戈”了。

Function Points and Use Case Points簡介

Project Planning In 【軟體專案管理】, PMBOK, CMMI