第一篇
開版囉 ，我決定離棄那個服務很冏的無名。投向google的懷抱，我想辜狗的自由度和親和力應該是很有未來的吧。
軟體、硬體、韌體規格書與設計書
重新體會這個方式的意涵， 不得不說江老師還是有過人之處。 不論是在現實面上因為實驗室人力流動的因素而當成 1.交接文件 2. 按圖施工重現的操作流程 3.抽象思維具體化的軟體框架 這個簡單的範本算是盡力在處理機電整合時對於交界面模糊地帶的分層概念。 設計前，先寫文件 或許對許多人來說這個先後順序讓人坐立難安： 對電子或軟體掌握度不高的人來說，是一個相當痛苦的要求，卻迫使他們思考； 對於已經具有相當掌握能力的人來說，卻幫助他們將腦中的層次架構意念具體浮現。 在學校當中能夠進行這種練習，不失為一個痛苦、無聊但是卻能激發一個工程師 掌握系統的自覺。 當有一天我發現某個機構部門自始至終從未和電子部門的交界下一個定義之時， 我接下來預言的實作面會發生的組裝錯誤全部不幸言中。 當我隔壁的純軟工程師問我為何不停的檢視其他交界和模糊的部份，我居然很自然的脫口而出： 因為工程師必須懂系統啊! 用於系統廠的專案規劃來說 設計書的每一個章節都非常實用，訂出大的方向流程 ： 可以用於和主管解釋、和其他function討論、 或是貼在投影片上讓大老闆覺得他在主持一個新產品開發會議。 可以在還沒著手方向還沒做錯之前，針對大方向進行修改。 這時候的修改是最省力也必須最慬慎的部份了。 再來逐漸從抽象層漸漸進到實體層、無論是狀態機、方塊圖，最後到具體實現。 化為要項、有助於評估成功率、實現方式與cost。 最後再加上一個詳細的操作組裝方式， 一動一動的步驟，非常適合交給廉價勞力的產線，提出最高成功率的操作文件。
留言