(一)思考為一種人人都能培養的技能
(1)我們必須將負面思考放在該有的位置上，作為整體思考的一部分，但將創造性、建設性和計畫性思考擺在負面思考之前。
- 12月 10 週五 201011:54
第十二講 期末總整理 和 成立一個思考俱樂部
(一)思考為一種人人都能培養的技能
(1)我們必須將負面思考放在該有的位置上，作為整體思考的一部分，但將創造性、建設性和計畫性思考擺在負面思考之前。
- 12月 09 週四 201009:40
軟體專案管理第十一週課程心得_Organizational Structure and Project
Organizational Structure and Project
第八組三位同學分別報告了【軟體專案管理】的第十章 專案組織與團隊運作與第十一章 軟體人力資源管理，雖然負責的範圍遠大於其他的分組，但是報告的書本與期刊內容卻是一樣完整與精彩。說實在的，肥蝦對於專案管理中的人力資源管理與溝通管理向來較為weakness，當然一方面因為自己對於人資管理較為缺乏興趣；另一方面也是肥蝦的主觀意識過於強烈，對於傾聽他人的發言與意見，會因為自我的主觀意見與認知，直接給予對方相當直接的反應，也是肥蝦一直被批評為太”機車”的原因之一。(另一個重要原因是肥蝦對於文件的要求較坊間的”陋俗”多一些！)
- 12月 09 週四 201009:20
軟體專案管理第十週課程心得_QP, QA, QC and SV&V
品質規劃(Quality
Planning)、品質保證(Quality Assurance)與品質控制(Quality Control)在台灣的工作環境中，除非有一定規模或一定制度的公司，遵循一定的品質作業規則，不然很難體會軟體專案中品質管理的程序與作業。最最簡單的一個問句：「您們工作團隊，是否有程式撰寫作業準則或者變數編碼規則？」這也是國珍與東豪同學對於軟體專案品質管理的疑問？我們是否真正的重視與落實品質管理？還是它只是一個空頭的名詞，以讓公司可向客戶多爭取點專案的經費？
【軟體專案管理】書本上將軟體品質定義為：軟體產品整體的功能和特性滿足既定需求的能力。更白話一點的說，就像日本的Mint(經營情報研究會)所著，周明憲所譯的【軟體工程實務】所寫的：「(1)正確的運作。(2)不會當機。(3)容易使用。(4)回應快速。(5)易於維護。(6)易於移轉。」這些要求可概括的區分為功能性與非功能性的要求；就過程而言，就如Deutach與Willis(1988)所分別的程序品質(Process Quality)與產品品質(Product Quality)。
目前，對於專案一般認知的”triple
constraint” - scope, schedule, cost，目前很多的討論與研究中已經把”quality”或”performance”抽離出來成為第四個constraint。就肥蝦的觀點，原本的專案管理三角形(Project Management Triangle)，可以畫成下圖：
Planning)、品質保證(Quality Assurance)與品質控制(Quality Control)在台灣的工作環境中，除非有一定規模或一定制度的公司，遵循一定的品質作業規則，不然很難體會軟體專案中品質管理的程序與作業。最最簡單的一個問句：「您們工作團隊，是否有程式撰寫作業準則或者變數編碼規則？」這也是國珍與東豪同學對於軟體專案品質管理的疑問？我們是否真正的重視與落實品質管理？還是它只是一個空頭的名詞，以讓公司可向客戶多爭取點專案的經費？
【軟體專案管理】書本上將軟體品質定義為：軟體產品整體的功能和特性滿足既定需求的能力。更白話一點的說，就像日本的Mint(經營情報研究會)所著，周明憲所譯的【軟體工程實務】所寫的：「(1)正確的運作。(2)不會當機。(3)容易使用。(4)回應快速。(5)易於維護。(6)易於移轉。」這些要求可概括的區分為功能性與非功能性的要求；就過程而言，就如Deutach與Willis(1988)所分別的程序品質(Process Quality)與產品品質(Product Quality)。
目前，對於專案一般認知的”triple
constraint” - scope, schedule, cost，目前很多的討論與研究中已經把”quality”或”performance”抽離出來成為第四個constraint。就肥蝦的觀點，原本的專案管理三角形(Project Management Triangle)，可以畫成下圖：
- 11月 24 週三 201017:18
軟體專案管理第九週課程心得之一_Software PMIS's Functions
Software PMIS’s Functions
一個良好的專案管理資訊系統應該具備哪些功能？李老師於第六組同學報告完後，請同學大家分組討論後提出每個人的想法！經由大家的腦力激盪(Brainstorming)提出了一些想法，肥蝦摘要整理如下：
- 11月 24 週三 201016:44
練習練習再練習－第十一講 我是一個思考者
無用之用，無思之思
(一)思隨意轉，思考的焦點可大可小
- 11月 16 週二 201009:57
軟體專案管理第八週課程心得之二_EVM計算式簡介
上週軟體專案管理實務課程，第五組的炯佑同學特別上網找了有關於Earned Value Management的一些公式。肥蝦此處只是將PMBOK 2008上的有關公式整理一下，並且對於課堂上所舉出解釋EVM的圖形提出自己的看法；另外對於此次新加入的EAC預測計算式，也提出肥蝦的初步構想。
(1)PMBOK 2008計算公式
Performance Measurement Analysis
Term Name
Short Name
Definition
Formula
Planned Value
PV
PV is the budgeted cost for the work scheduled to
be completed on an activity or WBS component up to a given point in time.
Earned Value
EV
EV is the budgeted amount for the work actually
completed on the schedule activity or WBS component during a given time
period.
Actual Cost
AC
AC is the total cost incurred in accomplished
work on the schedule activity or WBS component during a given time period.
Budget at Completion
BAC
Cost Variance
CV
CV=EV-AC
Schedule Variance
SV
SV=EV-PV
Cost Performance Index
CPI
CPI=EV/AC
Cumulative Cost Performance Index
CPIC
The cumulative cost performance index is widely
used to forcast project costs at completion.
CPIC equals the sum of the periodic earned value (EVC) divided by the
sum of the individual actual costs(ACC)
CPIC=EVC/ACC
Schedule Performance Index
SPI
SPI=EV/PV
- 11月 16 週二 201009:52
軟體專案管理第八週課程心得之一_Project M&C in PMBOK, CMMI
第五組志偉同學在介紹第七章監督與控制第一節導論之時，列示了書本上對於專案控制的定義－「比較、分析實際專案進度與規劃專案進度的差異，進而評估可能的備選方案，並且採取必要的行動。」針對專案監督與控制的定義，肥蝦對於書本的定義竊為過於含混，雖然標明了監控在於比較分析專案(管理)計畫所設定的基準(Baselines)與實際進行作業狀況的差異；但是對於其他必要的活動述及甚少，僅說明了：「進而評估可能的備選方案，並且採取必要的行動。」實在非常的不明確。因此，以下就Monitoring and Controlling在PMBOK與CMMI-DEV的說明中加以進一步說明。
在PMBOK 2008年版中的3.6節對於專案的監督與控制有著簡要的說明，而該程序群組中則包含了42個PMBOK所定義流程中的10個。此外，在CMMI-DEV
Version 1.2管理級(Managed)中的專案管理中也強調了專案監控(PMC - Project
Monitoring and Control)的流程與目標。因此，肥蝦將手中現有PMBOK與CMMI-DEV的資料與認知摘要如后，並且簡要說明對於兩者的異同，最後則重點的說明肥蝦的心得。
- 11月 16 週二 201009:49
軟體專案管理第七週課程心得之一_Case study of the CIO's straits
『CIO的困境』案例心得分享
【軟體專案管理實務】第四組的彥宇與誌源同學非常好心的從哈佛商業評論雜誌中捉取了一個洋案例－【CIO的困境：誘騙加入 未必持久】－供同學們課堂分組討論；課後並印發同文中四位洋專家的建議供大家參考醒思。肥蝦此組中的錦崇同學現任某大型連鎖賣場的資訊主管，對於該案例的情境實是感同身受，因此由他上場發表高見。其實每組同學的發言都切合要點，句句也都是真知灼見，授課的李老師也發表了三點意見帶領學生一窺其中的堂奧。不意，因為肥蝦老是愛在課堂上暨每週繳交的報告中亂放炮，所以李師”鷹”明的要肥蝦於下週課堂發表自己的看法。唉！怪也只能怪自己蝦嘴太”貝戈戈”了。
首先，肥蝦來交待一下這個案例：
- 11月 02 週二 201016:27
軟體專案管理第六週課程心得-簡介FP vs UCP
Function Points and Use Case Points簡介
本週「軟體專案管理實務」志中師弟所報告的【5.5軟體成本的估算方法】，書本中雖然列舉了專家判斷法、類比法、參數模式、功能點分析法、理論模式。但肥蝦以為，現行臺灣業界估算軟體的方法，應該還是以所謂的專家判斷法－老闆就是專家－為多，就算專案經理或者專案辦公室有著十八般武藝，到最後就是要呼應：「老闆是對的，老闆萬歲！」現今大多的專案，都是主事者先概估一下專案的複雜程度，以及所需要產生的畫面與報表數量，進而換算為天數，人天的價格先以軟協建議價格計算，再來跟甲方討價還價。具有規模的公司，或者(為)通過CMMI的公司，在Level 2中就必須導入或使用有一個業界間所認可的方法，如功能點法。但為了搶標，一開始要依據RFP的內容去估算成本，只怕還沒估算完個大概，投標截止日就過了。唉~~手拿著關刀，騎坐木馬，過五關！
- 11月 02 週二 201015:06
軟體專案管理第五週課程心得-PP in PMBOK,CMMI
Project Planning In 【軟體專案管理】, PMBOK,
CMMI
軟體專案規劃進行的步驟！在探討這議題之前，肥蝦以為要先瞭解專案規劃要做什麼？專案規劃重點就如Scot
Berkun所著"Making Things Happen"(中譯：讓事情發生)第在回答兩個問題：「我們需要做什麼？」「我們要怎麼做？」再進一步簡化，「我們需要做什麼？」可定義為『需求搜集(Collect Requirements)』；「我們要怎麼做？」可視為『設計或指定規格』。光這個What跟How兩字，就是一門非常大的學問，但非常可惜地，如協助進行搜集需求的需求工程(Requirements Engineering)，這在國外已日臻發達的領域，在台灣則還在起步，目前學校或坊間有教授此課程的單位還在少數。在【軟體專案管理】一書中除了在第四章中的第三、四節簡要說明外，也在第八章中的第二節稍有敘述，但相較於其它探討需求工程或軟體系統開發的專門書籍則是明顯不足。
CMMI
軟體專案規劃進行的步驟！在探討這議題之前，肥蝦以為要先瞭解專案規劃要做什麼？專案規劃重點就如Scot
Berkun所著"Making Things Happen"(中譯：讓事情發生)第在回答兩個問題：「我們需要做什麼？」「我們要怎麼做？」再進一步簡化，「我們需要做什麼？」可定義為『需求搜集(Collect Requirements)』；「我們要怎麼做？」可視為『設計或指定規格』。光這個What跟How兩字，就是一門非常大的學問，但非常可惜地，如協助進行搜集需求的需求工程(Requirements Engineering)，這在國外已日臻發達的領域，在台灣則還在起步，目前學校或坊間有教授此課程的單位還在少數。在【軟體專案管理】一書中除了在第四章中的第三、四節簡要說明外，也在第八章中的第二節稍有敘述，但相較於其它探討需求工程或軟體系統開發的專門書籍則是明顯不足。
資管在職碩班課程 (2)