2007年2月4日 星期日
[學習] 麻省理工學院的「開放式課程網頁」
這是一個免費、開放的教育資源，供給全世界各地的機構、學生和自學者使用。開放式課程系統代表麻省理工學院提升知識和教育水準的願景，並且為二十一世紀的世界服務。這個網站的目的正與麻省理工學院對於追求卓越、創意和領導的價值觀不謀而合。
[Book] Writing Solid Code
程式設計的箴言──擷取自《Writing Solid Code》
1. 啟動所有編譯器中的預警功能。
2. 利用lint找出那些編譯器所找不到的錯誤。
3. 如果您有單元測試工具，請好好利用。
4. 請同時保有“偵錯版”及“上市版”。
5. 請利用assert維護巨集來確認函式引數的正確性。
6. 避免讓程式產生未定義的行為，不然就在這些地方加上維護敘述，以免有人誤用了這些未定義的結果。
7. 適時地加上註解，以免浪費別人的時間來看懂您的維護敘述。
8. 不要直接利用假設的狀況，否則請加上維護敘述來檢查這些條件。
9. 利用維護敘述找出不該在正常情況下發生的現象。
10. 不要為求包容意外的狀況而忽略了潛在的錯誤。
11. 利用不同的演算法來協助您確認程式的結果。
12. 避免產生隨機行為，並且讓錯誤無所遁形。
13. 清除不能使用的記憶體空間，以免誤用了它的資料而不自知。
14. 程式中如果有些行為太少發生了，就強迫它多發生幾次。
15. 多保留一些系統資訊，有助於進行更嚴謹的除錯。
16. 徹底建立子系統的檢查程序，並且盡可能地去使用它。
17. 小心地設計測試條件，從各種可行的方法中慎選最好的。
18. 致力寫出無形的，而且完整的測試。
19. 不要以發行時的標準來苛求偵錯版本，偵錯能力是必須犧牲速度及程式大小換來的。
20. 不要等到錯誤發生，才被迫去逐步追蹤程式。
21. 逐步追蹤您的程式。
22. 逐步追蹤程式的時候，請多注意資料的流向及內容。
23. 以原始程式指令為單位無法知道所有執行的細節，面對重要的程式碼最好以組合語言指令為單位來逐步測試。
24. 讓程式的介面為程式師把關，使他們不至於忽略錯誤的情況，更不要因為傳回值的設計不良而造成錯誤。
25. 不時地檢查、並且去除函式介面裡的缺失。
26. 不要以一個函式來包含多項功能；盡可能讓每一個函式只完成一項獨立的功能，這樣有助於我們做更完整的引數檢查。
27. 清楚地定義函式的引數，不要弄得模稜兩可。
28. 確定函式的輸入值都是正確的，以避免函式傳回“輸入錯誤”的訊息。
29. 讓一般的程式師都能由函式的定義看出函式的呼叫方法，並且避免使用布林值來當引數。
30. 用註解來強調函式中潛在的危機。
31. 利用定義明確的資料型別。
32. 隨時注意變數會不會產生溢位或不足位的現象。
33. 寫程式的時候要盡量依照原始的設計，任何無心的偏差都可能造成始料未及的錯誤。
34. 盡量使每一個步驟都只用一段程式來完成。
35. 盡量不用if敘述來處理例外的狀況。
36. 避免層層疊疊的使用?:運算子。
37. 盡量使同一類的特殊狀況只用一段程式處理──將相同的條件敘述合成一條。
38. 避免採用程式語言的危險慣例。
39. 若非必要，不要任意將不同類的運算混在一個式子裡。萬一必須將不同的運算放在一起使用，就用括號來標明運算的順序。
40. 避免呼叫會傳回錯誤碼的函式。
41. 不屬於自己的記憶體，就不要使用。
42. 不要去使用已經被我們釋放的記憶體空間。
43. 不要把用來傳輸出結果的記憶體拿來當成作業時的暫存空間。
44. 不要以 static（或整體性）的空間來傳資料。
45. 不要讓我們的函式變成“寄生蟲”。
46. 不要濫用程式語言的特性。
47. 將 Ｃ 的原始程式寫短，編譯出來的執行碼不見得就會有效率。
48. 寫程式要盡量讓一般人看懂。
49. 錯誤不會自己“跑掉”。
50. 發現錯誤立即修正，莫待將來付出更慘痛的代價。
51. 不能只是解除錯誤的表象，要除掉病因才能真正解決問題。
52. 除非為了讓軟體更成功，非修改不可。否則不要隨便“整理”程式。
53. 不要增添沒有必要的功能。
54. 任何一項功能都要付出代價。
55. 不要容許沒有必要的彈性。
56. 不要盲目地從一堆“嘗試”中去找答案；將時間用來找尋“最正確”的方法。
57. 每完成一小部份，就先回頭測試一遍。不管進度是不是落後，一定要徹底地將程式測試過。
58. 不能只靠測試小組來除錯。
59. 不要錯怪測試人員存心找麻煩。
60. 建立自己適用的優先順序，並確實地依照這個標準來做取捨。
61. 不要讓同一個錯誤有再次出現的機會。
好了，總共六十一條，終於整理出來了，希望對各位有所幫助。想要知道更詳盡內容的話，強力建議諸位直接去翻閱本書。
http://yukuan.blogspot.com/2001/01/writing-solid-code.html
1. 啟動所有編譯器中的預警功能。
2. 利用lint找出那些編譯器所找不到的錯誤。
3. 如果您有單元測試工具，請好好利用。
4. 請同時保有“偵錯版”及“上市版”。
5. 請利用assert維護巨集來確認函式引數的正確性。
6. 避免讓程式產生未定義的行為，不然就在這些地方加上維護敘述，以免有人誤用了這些未定義的結果。
7. 適時地加上註解，以免浪費別人的時間來看懂您的維護敘述。
8. 不要直接利用假設的狀況，否則請加上維護敘述來檢查這些條件。
9. 利用維護敘述找出不該在正常情況下發生的現象。
10. 不要為求包容意外的狀況而忽略了潛在的錯誤。
11. 利用不同的演算法來協助您確認程式的結果。
12. 避免產生隨機行為，並且讓錯誤無所遁形。
13. 清除不能使用的記憶體空間，以免誤用了它的資料而不自知。
14. 程式中如果有些行為太少發生了，就強迫它多發生幾次。
15. 多保留一些系統資訊，有助於進行更嚴謹的除錯。
16. 徹底建立子系統的檢查程序，並且盡可能地去使用它。
17. 小心地設計測試條件，從各種可行的方法中慎選最好的。
18. 致力寫出無形的，而且完整的測試。
19. 不要以發行時的標準來苛求偵錯版本，偵錯能力是必須犧牲速度及程式大小換來的。
20. 不要等到錯誤發生，才被迫去逐步追蹤程式。
21. 逐步追蹤您的程式。
22. 逐步追蹤程式的時候，請多注意資料的流向及內容。
23. 以原始程式指令為單位無法知道所有執行的細節，面對重要的程式碼最好以組合語言指令為單位來逐步測試。
24. 讓程式的介面為程式師把關，使他們不至於忽略錯誤的情況，更不要因為傳回值的設計不良而造成錯誤。
25. 不時地檢查、並且去除函式介面裡的缺失。
26. 不要以一個函式來包含多項功能；盡可能讓每一個函式只完成一項獨立的功能，這樣有助於我們做更完整的引數檢查。
27. 清楚地定義函式的引數，不要弄得模稜兩可。
28. 確定函式的輸入值都是正確的，以避免函式傳回“輸入錯誤”的訊息。
29. 讓一般的程式師都能由函式的定義看出函式的呼叫方法，並且避免使用布林值來當引數。
30. 用註解來強調函式中潛在的危機。
31. 利用定義明確的資料型別。
32. 隨時注意變數會不會產生溢位或不足位的現象。
33. 寫程式的時候要盡量依照原始的設計，任何無心的偏差都可能造成始料未及的錯誤。
34. 盡量使每一個步驟都只用一段程式來完成。
35. 盡量不用if敘述來處理例外的狀況。
36. 避免層層疊疊的使用?:運算子。
37. 盡量使同一類的特殊狀況只用一段程式處理──將相同的條件敘述合成一條。
38. 避免採用程式語言的危險慣例。
39. 若非必要，不要任意將不同類的運算混在一個式子裡。萬一必須將不同的運算放在一起使用，就用括號來標明運算的順序。
40. 避免呼叫會傳回錯誤碼的函式。
41. 不屬於自己的記憶體，就不要使用。
42. 不要去使用已經被我們釋放的記憶體空間。
43. 不要把用來傳輸出結果的記憶體拿來當成作業時的暫存空間。
44. 不要以 static（或整體性）的空間來傳資料。
45. 不要讓我們的函式變成“寄生蟲”。
46. 不要濫用程式語言的特性。
47. 將 Ｃ 的原始程式寫短，編譯出來的執行碼不見得就會有效率。
48. 寫程式要盡量讓一般人看懂。
49. 錯誤不會自己“跑掉”。
50. 發現錯誤立即修正，莫待將來付出更慘痛的代價。
51. 不能只是解除錯誤的表象，要除掉病因才能真正解決問題。
52. 除非為了讓軟體更成功，非修改不可。否則不要隨便“整理”程式。
53. 不要增添沒有必要的功能。
54. 任何一項功能都要付出代價。
55. 不要容許沒有必要的彈性。
56. 不要盲目地從一堆“嘗試”中去找答案；將時間用來找尋“最正確”的方法。
57. 每完成一小部份，就先回頭測試一遍。不管進度是不是落後，一定要徹底地將程式測試過。
58. 不能只靠測試小組來除錯。
59. 不要錯怪測試人員存心找麻煩。
60. 建立自己適用的優先順序，並確實地依照這個標準來做取捨。
61. 不要讓同一個錯誤有再次出現的機會。
好了，總共六十一條，終於整理出來了，希望對各位有所幫助。想要知道更詳盡內容的話，強力建議諸位直接去翻閱本書。
http://yukuan.blogspot.com/2001/01/writing-solid-code.html
[Book] Practice of Programming
Table of Contents (事前的良好習慣,比日後發生問題來的好)
1. Style.
Names.
Expressions and Statements.
Consistency and Idioms.
Function Macros.
Magic Numbers.
Comments.
Why Bother?
2. Algorithms and Data Structures.
Searching.
Sorting.
Libraries.
A Java Quicksort.
O-Notation.
Growing Arrays.
Lists.
Trees.
Hash Tables.
Summary.
3. Design and Implementation.
The Markov Chain Algorithm.
Data Structure Alternatives.
Building the Data Structure in C.
Generating Output.
Java.
C++.
Awk and Perl.
Performance.
Lessons.
4. Interfaces.
Comma-Separated Values.
A Prototype Library.
A Library for Others.
A C++ Implementation.
Interface Principles.
Resource Management.
Abort, Retry, Fail?
User Interfaces.
5. Debugging.
Debuggers.
Good Clues, Easy Bugs.
No Clues, Hard Bugs.
Last Resorts.
Non-reproducible Bugs.
Debugging Tools.
Other People's Bugs.
Summary.
6. Testing.
Test as You Write the Code.
Systematic Testing.
Test Automation.
Test Scaffolds.
Stress Tests.
Tips for Testing.
Who Does the Testing?
Testing the Markov Program.
Summary.
7. Performance.
A Bottleneck.
Timing and Profiling.
Strategies for Speed.
Tuning the Code.
Space Efficiency.
Estimation.
Summary.
8. Portability.
Language.
Headers and Libraries.
Program Organization.
Isolation.
Data Exchange.
Byte Order.
Portability and Upgrade.
Internationalization.
Summary.
9. Notation.
Formatting Data.
Regular Expressions.
Programmable Tools.
Interpreters, Compilers, and Virtual Machines.
Programs that Write Programs.
Using Macros to Generate Code.
Compiling on the Fly.
Epilogue.
Appendix: Collected Rules.
Index. 020161586XT04062001
1. Style.
Names.
Expressions and Statements.
Consistency and Idioms.
Function Macros.
Magic Numbers.
Comments.
Why Bother?
2. Algorithms and Data Structures.
Searching.
Sorting.
Libraries.
A Java Quicksort.
O-Notation.
Growing Arrays.
Lists.
Trees.
Hash Tables.
Summary.
3. Design and Implementation.
The Markov Chain Algorithm.
Data Structure Alternatives.
Building the Data Structure in C.
Generating Output.
Java.
C++.
Awk and Perl.
Performance.
Lessons.
4. Interfaces.
Comma-Separated Values.
A Prototype Library.
A Library for Others.
A C++ Implementation.
Interface Principles.
Resource Management.
Abort, Retry, Fail?
User Interfaces.
5. Debugging.
Debuggers.
Good Clues, Easy Bugs.
No Clues, Hard Bugs.
Last Resorts.
Non-reproducible Bugs.
Debugging Tools.
Other People's Bugs.
Summary.
6. Testing.
Test as You Write the Code.
Systematic Testing.
Test Automation.
Test Scaffolds.
Stress Tests.
Tips for Testing.
Who Does the Testing?
Testing the Markov Program.
Summary.
7. Performance.
A Bottleneck.
Timing and Profiling.
Strategies for Speed.
Tuning the Code.
Space Efficiency.
Estimation.
Summary.
8. Portability.
Language.
Headers and Libraries.
Program Organization.
Isolation.
Data Exchange.
Byte Order.
Portability and Upgrade.
Internationalization.
Summary.
9. Notation.
Formatting Data.
Regular Expressions.
Programmable Tools.
Interpreters, Compilers, and Virtual Machines.
Programs that Write Programs.
Using Macros to Generate Code.
Compiling on the Fly.
Epilogue.
Appendix: Collected Rules.
Index. 020161586XT04062001
數位學習-財團法人自強工業科學基金會
財團法人自強工業科學基金會
http://edu.tcfst.org.tw/E_learning/semiconductor.asp?etype=de14
http://edu.tcfst.org.tw/E_learning/semiconductor.asp?etype=de12
http://edu.tcfst.org.tw/E_learning/semiconductor.asp?etype=de14
http://edu.tcfst.org.tw/E_learning/semiconductor.asp?etype=de12
Driver Development
This section provides links to helpful resources for Driver Development.
Architecture Independent Articles
- Introduction to Device Drivers
- Linux Driver Model
- Device Classes
- Basic Char Driver
- Basic Open / Close Functions
- Basic Read / Write Functions
- Basic Driver Completion
- Basic Driver Configure and Build
- Advanced Device Driver Topics
- Network Device Drivers
- uClinux 2.6.x Kernel API
- Basic Block Drivers
- Block IO Subsystem
- IO Schedulers
- Kernel Objects
2007年2月3日 星期六
CMMI / TSP / PSP為相輔相成的機制
CMMI / TSP / PSP為相輔相成的機制
財團法人資訊工業策進會 林栩傑 整理
一、前言
CMMI是一個致力於組織流程改善的架構，由於CMMI並未提供有關實施CMMI各流程領域所需的知識和技能，因此美國Carnegie Mellon大學軟體工程研究所(CMU/SEI) 以W. S. Humphrey為首主持研究開發了個人軟體流程PSP（Personal software process）和團隊軟體流程TSP(Team Software Process)，形成CMMI/PSP/TSP體系。根據近年來國際軟體流程理論與實踐的發展，目前著重在CMMI、PSP和TSP以及ISO軟體流程標準等方面的研究工作，根據專家學者建議，軟體流程的改善應該從三方面著手進行：
n 能力成熟度整合模式CMMI(Capability Maturity Model Integrated)
n 個人軟體流程PSP (Personal Software Process)
n 團隊軟體流程TSP(Team Software Process)
二、CMMI、PSP、TSP為相輔相成的機制
CMMI、PSP和TSP組成的軟體流程架構
n CMMI是流程改善的第一步，它可評鑑組織的能力、識別優先改善需求和追蹤改善進展的管理方式。企業只有開始CMMI改善後，才能接受需要規劃的事實，認識到品質的重要性，才能注重對員工經常進行培訓，合理分配專案人員，並且建立起有效的專案小組。然而，其實施的成功與否與組織內部有關人員的積極參與密不可分。
n PSP能夠指導程式設計師如何確保自己的工作品質，估計和規劃自己的工作，度量和追蹤個人的表現，管理自己的軟體流程和品質。經過PSP學習和實踐的正規訓練，程式設計師們能夠在他們參與的專案工作之中充分運用PSP，從而有助於CMMI目標的實現。
n TSP結合了CMMI的管理方法和PSP的工程技術，告訴程式設計師如何將個人流程結合進團隊軟體流程，並將後者與組織的整個管理系統相聯繫；告訴管理層如何支援和授權專案小組，堅持高品質的工作，並且依據資料進行建構管理，向組織展示如何應用CMMI的原則和PSP的技能去生產高品質的產品。
n CMMI/TSP/PSP代表了目前國際上軟體流程工程研究方面最先進的成果，它們對促進軟體產業的科學化管理，與提高軟體生產力意義重大。
n 要使一個軟體流程對軟體生產的改善真正有所幫助，其架構應是由CMMI、TSP和PSP組成的一個完整體系，即從組織、團隊和個人三個層次進行良好的軟體工程管理模式。換言之，單獨實施CMMI，無法真正做到能力成熟度的升級，只有將CMMI與PSP和TSP有效的結合，才能發揮最大的效力。
三、PSP概述
個人軟體流程（Personal Software Process ,PSP）是在1995年由美國Carnegie Mellon大學軟體工程研究所(CMU/SEI) Watts s. Humphrey領導開發；W. S. Humphrey同時也是SEI研發CMMI團隊的主持人。PSP是一種可用於控制、管理和改進個人工作方式的自我改善過程，是一個包括軟體發展表格、說明的結構化架構。 PSP為基於個人和小型團隊軟體流程的最佳化提供了具體有效的途徑，如制訂計畫、控制品質、其他人合作等等。在軟體設計階段， PSP的著眼點在於軟體缺失的預防，其具體辦法是強化設計的準則，而不是設計方法的選擇。根據對大陸參加PSP培訓的104位元軟體人員統計資料，在應用了PSP後軟體中總缺失減少了58.0％，在測試階段發現的缺失減少了71.0％，生產效率提高了20.0％。PSP的研究結果還發現，絕大多數軟體缺失是由於對問題的錯誤理解或簡單的錯誤所造成的，很少是因為技術問題而產生的。而且根據多年來的軟體工程統計資料發現，如果在設計階段埋下一個缺失，則這個缺失在程式設計階段引會發3到5個新的缺失，要修復這些缺失所花的費用要比修復這個設計缺失所花的費用增加了相當的成本。因此實施PSP為確保軟體品質的一個重要途徑，尤其是要提高軟體設計的品質。
3.1 PSP的現況
n 從1993年開始，美國、歐洲、澳洲等地已先後有20多所大學開設PSP課程。
n 在產業界，PSP也先後被Motorola、 HP、 AIS等公司採用，以Navy and Marine Corps為例，使用PSP進行以CMM為基礎的流程改善，從成熟度第一級到第四級只花30個月，而大部分的機構需要72個月的時間。SEI協助ABB導入PSP，在第一個應用PSP的專案中，交付時程提前6.9%，系統測試每千行只發現44個缺失，比原先系統減少10倍缺失。
n 中國大陸北航軟體工程研究所於1997年開始，在北航電腦科學與工程系率先開辦了PSP課程，並成立PSP的實驗應用。
3.2 PSP的內容
PSP與工程的技術（程式設計語言、工具或者設計方法等）沒有直接的關係，幾乎能應用到所有軟體工程的工作中。PSP能提供：
1. 個人軟體流程原則的說明
2. 程式設計師作出準確的計畫
3. 程式設計師在改善產品品質所需採取的步驟
4. 度量個人軟體流程改善的基準
5. 流程的改變對程式設計師能力的影響
3.3 PSP的效益
n 使用由下而上的方法來改進流程，讓每個程式設計師了解流程改進的原則，使其了解如何有效生產高品質的軟體
n 為個人和小型團隊軟體流程最佳化提供了具體有效的途徑。彌補在實施CMMI各流程領域所需知識與技能的空白。
n 幫助程式設計師在個人的基礎上運用流程的原則，借助PSP提供的度量和分析工具，瞭解自己的技能水準，控制和管理自己的工作方式，使自己日常工作的估計、規畫和預測更加準確更有效率，進而改進個人的工作表現，提高個人的工作品質和產量。
四、總結
CMMI如同軟體廠商的一面鏡子，用來衡量組織以反映出組織發展的水準及能力，改進軟體發展流程。建議組織在推動流程改善的同時，以CMMI為基礎架構，從PSP先做起，然後在此基礎上逐漸轉換到TSP，循序漸進以確保基礎的穩定，對於日後CMMI高成熟度的提升有正面的幫助。
訂閱：
文章 (Atom)