引述 :『The CNC machining center is designed and constructed to provide quick power delivery, speed, acurancy and stability during the machining work. 』

引述 :『意諾新(InnoCentive)的運作方式和eBay有點像。公司（和非營利組織）被稱為「提問者Seeker」，在意諾新網站上發表研發問題(Challenge)，而「解答者Solver」提交他們的解決方案，以爭取從5000美元（約16萬新台幣）到100萬美元（約3800萬新台幣）不等的金錢報酬。』

引述 :『閻紀宇／綜合十八日外電報導 　人類發展科技工程的潛力無比雄厚，成果日新月異，然而工程師與科學家永遠面臨尚未解決或即將出現的挑戰，而且成敗往往攸關全人類的福祉。美國國家工程學院（NAE）去年召集18位專家學者、社會領袖與企業家，經過一年的腦力激盪，在18日提出14項「科技工程大挑戰」，為21世紀的工程師與科學家設定戮力以赴的目標。 　14項挑戰關係人類生存 　這14項大挑戰分別是：讓太陽能成為高經濟效益的能源、研發核融合發電、研發二氧化碳封存技術、處理氮循環問題、提供潔淨的水資源、修復與改善都市基礎設施、推動醫療資訊學研究、開發更理想的藥物與療法、對大腦進行反向工程、防範核子恐怖行動、確保網際網路世界的安全、讓虛擬實境日新月異、讓個人化學習更上層樓、開發科學探索的新工具。 　國家工程學院院長、麻省理工學院榮譽校長查爾斯．韋斯特表示：「這些挑戰有一部分關係到人類是否能在地球上繼續生存，一部分會讓我們更能抵擋人為與自然的威脅，每一項都能夠增進全球民眾的生活品質。」 　參與委員皆一時之選 　擬定14項大挑戰的委員都是一時之選，包括Google共同創辦人佩吉、基因科技先驅文特、美國前國防部長裴利、發明大師凱曼與科茲威爾、來自台灣的新加坡生物工程與奈米科技研究院（IBN）院長應儀如等人。國家工程學院也歡迎一般民眾到網站「http://www.engineeringchallenges.org」表達對於科技創新的看法。 　委員會指出，從終結石器時代的冶金術、開啟大航海時代的造船技術、工業革命到資訊革命，自古以來科技工程就是人類文明最重要的推手之一，21世紀自然也不例外。然而展望未來，人類仍然在四大領域面臨挑戰，有待科技工程協助，這四大領域是：文明的永續發展、醫療健康、人為與自然的威脅、生活樂趣與教育。 　開發新能源勢在必行 　地球資源有限，開發新能源勢在必行。太陽能雖然取之不盡，又不傷害環境，但如何以合乎經濟效益的方式收集、轉化與儲存太陽能，對工程師而言仍然是一大挑戰。核融合發電的情形類似，前景看好，潛力無限，但技術與經濟效益的門檻尚未跨越。 　在可預見的未來，高污染的化石燃料仍將是人類能源的主力，排放的二氧化碳將繼續荼毒全球氣候，將這種溫室氣體地下封存是可行方案之一，相關技術近來頗有進展。氮循環的污染危機較不為人知，但同樣嚴重。肥料的廣泛使用與高溫工業燃燒，大幅破壞自然界的氮循環，造成酸雨、霾害、飲用水污染等可怕後果，亟待解決。 　水資源的短缺和污染，導致許多地區民眾的生存岌岌可危，個人用水與農業灌溉都面臨無水可用的窘境，海水淡化的新技術可以派上用場，但地區性的水資源淨化科技可能更為實用。此外，全球人口分布都市化的趨勢已無可阻遏，因此改善都市基礎設施也是當務之急。 　醫藥健康和水一樣，與每個人的生活息息相關。儘管上個世紀醫學進展神速，但瘧疾之類的古老病魔依舊陰魂不散，多種新出現的惡疾也來勢洶洶。 　因此醫藥界必須全力研發更有效的藥物與療法，開發能夠針對個人特質的「個人化醫療」。大腦的角色尤其重要，對大腦進行「反向工程」不僅有助於醫療研究，還能為電腦人工智慧指點迷津。 　營造更安全的生活空間 　民生基本需求之外，工程師與科學家還要設法防範核子恐怖行動、遏阻網際網路世界的犯罪行為，為人類營造一個更安全、更便利、互動更密切的生活空間。教育娛樂和科學探索也是人類文明不可或缺的動力，科技工程可望開創層出不窮的新境界。 　最後委員會提醒工程師與科學家，他們不僅要全心全力面對挑戰、克服難關，也要盡可能突破政治與經濟的藩籬，讓世界各地的民眾都能享受科技工程帶來的福祉。唯有如此，人類文明才有可能生生不息、漸入佳境。 』

引述 :『很有趣，這話題不斷延燒。所以又看到javaworld上的這位大師再度回覆：『PM就算是工程師出身，面對技術日益更新的情況下，如果PM認為對的時候，而主導專案開發時，試問當其意見跟專案開發主管相反時，專案開發該如何進行？如果把PM當做SA用，那萬一需求有錯時，而PM就是SA，專案人員該如何反應?直接說PM你錯了嗎 ?』 先研究一下比較簡單的這個部份。也就是PM是不是個不會犯錯的聖人，不能被team member指正錯誤。 我不知道有多少次在帶領專案時，就直接被工程師挑毛病說，你這樣做不好，如果是兼任SA時，也常常會因為需求沒有確定而被問倒。 如果PM一直在擺臭官架子，變成一個真理的象徵，這當然是很大的問題。 可是事實上，就算你兼任了SA，人家說你錯了，你也發現不對，那就去改過來嘛。有什麼好不能說的？ 如果這個專案有人有錯了，卻沒人敢指出來，有人發現問題，卻因為組織文化的問題，不敢說出來，這對這個專案是好事嗎？這個PM有盡到管理的責任嗎？ 人非聖賢，孰能無過。這又不是學校在考試，不能夠靠同學幫忙解答，要不然是算你做弊。你發現了一個潛在的問題，就是要提出來討論。我們一起做專案，就是在同一條船上，大家發現了潛在的問題，或是實際上的問題，盡早拿出來討論，我們盡早有因應修正的空間。』

引述 :『所謂的系統結構(System Structure)分析與設計(Analysis and Design)，係指如何正確、有效地分解設計範圍內系統的元素(Element，一般泛指物件(Object))，指派每一個物件所應有的屬性(attributes)與行為(behavior, 責任的分派)，抽象表達靜態類別之間的關係，動態組合物件在執行期間(run-time)的訊息(Message)傳遞，以履行系統的功能需求(ex. 來自於 Use Case 的功能分析)．．．。做好結構分析、捕捉有效的領域概念，以成為系統的主結構，才能建構出堅若磐石的軟體系統，來應付現實複雜系統的善變，甚而讓系統呈現有機的次序成長、生生不息。 如何找出問題領域(Problem)的概念具化成為企業物件(Business Object)、指派每一個物件應盡的責任，並以此來建構系統中的軟體規格模型，已是高階系統分析與設計人員最大的挑戰與應具備的本質學能。更為難的是，如何將企業物件配合現實面的平台，例如如何活用 J2EE Spring and Hibernate 系統框架。因為，現實上，物件的狀態(state)就是被永續(persistent)儲存在資料庫系統內，而在需要用到(企業邏輯的運算)的時候才被活化(activate)起來；同時因為物件共用的議題而需要 AP 應用伺服器的系統支援，包括交易(transaction)控管、安全性(security)、效能(performance)、分散(distribution)等議題的設計考量。兩個層次(高階概念性的分析設計；細部平台面的設計)，互補且缺一不可。 系統的內，也就在於分析所組成的內部結構元素，套現在 IT 的術語來說，也就是所謂的物件導向分析與設計(Object-Oriented analysis and design)。相對於系統的外，是著重在功能性的需求分析(也就是前一期內容所介紹如利用使用案例建構的需求模型)。兩者是互補—找出內部穩定的結構元素(物件,Object)，來應變外部的功能需求。 而系統的結構分析，正是現今軟體人員們最大的罩門所在。在速成短線的專案開發生態，軟體人員只會看到現在所看到的—找出一個一個的功能，快速地利用所提供的平台技術(如 .NET, J2EE)，疊床架屋的方式，Quick and Dirty 快速的給開發出來。不要以為利用 .NET 或 Java 等 OOP 語言，就是所謂的物件導向開發模式，這是兩回事，如果沒有用心地萃取具本質性(Essential)的物件(再一次強調，源自於問題領域的概念術語)，而只是看到一個功能就成為一個 Class，那麼，這樣的系統完全會受限於需求性的變動而導致震盪不穩，是不會具軟體系統的彈性(flexibility)、穩定性(stability)與延展性(extensibility)！』

引述 :『專案遠景與目標：專案的背景有時候不見得所有成員都能夠明白，也因此造成專案成員對於工作的重要性上有了錯誤的認知，藉由明確的專案目標可以讓成員都擁有專案過程中取捨的依據。 1. 專案地圖：專案網站需要有一個區域是用來描述專案本身遵循的流程，以及專案運作的規則，以及組織的決策。再好的流程與制度都需要人員的徹底配合才能達到流程的效果。 2. 工作分派與工作進度管理：專案經理可以藉由專案網站來管理需求以及分派負責的工作人員，此外，更可以藉由統計與查詢來隨時監控專案目前的進度與狀況，可以提早發現專案潛在的危機（只要這個專案經理夠稱職的話），更可隨時藉由工作的狀態與處理時間來瞭解專案成員的工作狀況，以便即時調整成員的工作。 3. 專案重要訊息公布：隨時佈達專案的重要訊息，以及專案的重要時程或者重大異動，讓所有專案成員都能瞭解專案的狀態。 4. 專案文件控管：將專案的文件分門別類存檔，並且務必做好版本控管。這裡要提醒的是，專案的各式文件中，對於異動的原因以及採用的決策要予以記錄，我們往往可以發現，無論當初基於什麼理由做的變動，事後通常都是沒有人會記得的。 5. 變更管理：專案成員無論負責哪種類型的工作，只要對於專案的工作成果有重新發佈新版本時，都應該對相關人員做通知，以免造成專案成員彼此對於其他專案成員的工作造成影響卻不自知。專案的網站最好是具備成員再填寫工作紀錄時，能夠選擇發佈與否的功能，這類型的瑣碎行政工作最好都是能夠交由工具來協助，以免造成專案成員的負擔。 6. 知識分享：專案的開發過程中難免會遭遇一些困境，不論最後是採用了什麼樣的解決方案，若是不能提供出來讓其他人參考，就會造成不必要的時間成本不斷的產生，善用標準化流程以及知識分享是提高組織績效的利器。 以上是建構專案網站時可以參考的一些方向，當然，可以允許的話，專案網站也可以將專案運作過程中蒐集到的資訊量化，並且轉化為有意義的報表與資訊，以供管理人員評估與檢討專案的過程中的優缺點。在CMMI的成熟度Level 5的精神便是組織能夠藉由蒐集專案的量化績效來不斷調整專案的流程，最終讓專案流程能夠最佳化。』

引述 :『在軟體業界，我們常常會看到一個普遍的現象，有些人很會寫程式，然後做久了，薪水也差不多到了公司會給的頂端，所以老闆想了想告訴你，你要拿更多的薪水，就得要揹更高的責任，責任越大，薪水就越高。 接著就是這個很會寫程式的人，一開始當了專案主管，我們會發現這是一個很爛的主管。因為他可能會自己跳下去做所有的工作，他可能會傾向於自己解決所有的問題，他可能完全沒有在做專案經理人該做的工作。他只是一個更努力而缺乏方向的開發者而已。』

引述 :『Phil Haack寫了一篇探討開發人員產能差異的好文章。可能是因為自己瘋狂熱愛Coding，一直以來對許多客戶、專案經理、公司主管貶低開發人員價值的錯誤認知頗不以為然，於是，這類的文章讀來格外心有戚戚焉。 對開發人員的種種誤解中，我最痛恨的是以下幾種: 1) 為什麼寫一個線上購物網站要花五十萬? 我小姨子的同事唸高中的兒子說給他五萬元就可以搞一個! 2) 每年多少資管畢業生呀? 程式開發人員去街上抓就一大把，還怕找不到人? 3) 不過就寫程式唄! 找誰來寫還不都一樣? 你專案不是缺人，為什麼不叫隔壁組現在沒事的老王加入你的Team? (Darkthread定律: 連砸了三個案子的人，在撐著不離職前都會很涼) 4) 當黑手寫程式有什麼前途? 把系統分析做好，外包給老印、老中的Programmer才是王道! 別把時間花在這種低層次的工作上，你要學習如何成長.... 取得Phil的同意，我翻譯了原文並加上自己的詮釋，提供大家參考。』

引述 :『學生對軟體沒有概念，以為軟體就是寫程式，但寫程式只佔系統導入的15～20％，其他像需求文件或測試文件撰寫等，我們的學生都不會。結果是臺灣工程師工時最長，卻效率很低，生產力和美國太空總署噴射實驗室相比只有三分之一到二分之一。學術界研究也和產業界脫節，國科會跨領域計畫大多失敗，因為教授間缺乏合作，系統介面不清楚，一個計畫分成10個次系統，等於10個計畫，勢必難以整合。加上政府包案缺乏監控，結案沒有監控，品質好壞沒有追蹤。 』