人月神話

  • 因為溝通的時間,人力和工時互換是不成立的,別用人月來衡量工作規模大小
    溝通又可分為,訓練和相互交流
    訓練的成本可以是線性關係,但相互交流花的時間可多了
    所以為了趕上時程而增加的人力,通常不會只會讓進度更落後。

  • 系統設計的時候,保有概念整體性是很重要的原則
    寧可忽略掉新奇或更好的特色,來反映同一組設計理念

  • 系統的目的是使用便利性,所以功能概念複雜度比才是系統設計的最終測試標準
    好的設計不可以單獨偏重功能性,也不可只偏重簡單性

  • 產品測試小組代表顧客,就是為了挑出產品毛病存在
    隨著時間的投入,細心的產品測試人員將找出設計意圖並未正確傳達之處,也就是設計的決策沒有被正確了解或準確實作的地方
    基於這個理由,測試小組絕對有必要與設計意念傳達的過程相結合,並且必須在造其跟根設計的工作一起同時進行

  • 在大部分的專案中,第一次出爐的系統絕少是有用的
    因此,無需考慮是否要做一個試探性的系統,然後把他丟棄,因為這是必然的問題
    所以應該要預先規劃去做一個本來就要丟掉的試驗品
    在規劃時程的時候,把必然的一次失敗納入正式計劃之中。

  • 規劃軟體開發專案的文件

    1. 目標
    2. 產品規格
    3. 時程
    4. 預算
    5. 場地配置
    6. 組織編制圖
  • 為使用程式而寫的文件

    1. 目的
      • 程式主要功能為何?
      • 為什麼要寫這支程式?
    2. 環境
      • 程式要在哪種機器上跑?
      • 硬體和作業系統的組態該如何設定?
    3. 輸入值域與輸出值域
      • 程式輸入與輸出資料的合理範圍為何?
    4. 欲達成的功能與使用的演算法
      • 精確的說出程式到底要做什麼事情 ?
    5. 輸出入格式
      • 要精確而完整的描述
    6. 執行過程中的指示
      • 包括運行正常時,或因異常而終止時,在控制台或任何輸出裝置上應該要看得到的任何提示
    7. 選項
      • 使用者在功能上有哪些選擇彈性?
      • 這些選項該如何正確的加以指定?
    8. 執行時間
      • 對於某個工作,在某個組態所指定的空件大小限制之下,程式要花多少時間來完成?
    9. 輸出結果的精確度與檢驗方式
      • 預期的結果必須精確到什麼程度?
      • 跟這種精確度相搭配的檢驗方式為何?
      • 將文件維護的負擔剪到最小
  • 借助那些基於語言的要求而必須存在的語
    儘可能容納更多訊息在裡頭
    標籤、宣告、符號名稱都可以用來表達某些函意

  • 善用留白或固定格式來增加可讀性,表現出從屬和巢狀的關係

  • 以註解的形式在程式中加入一些註解
    但許多程式為了這個逐行加入註解,這更會讓人感到困惑

Share on: TwitterFacebookEmail

Comments

Do you like this article? What do your tink about it? Leave you comment below

comments powered by Disqus

Published

Read Time

1 min

Category

Book

Tags

Keep In Touch