UML - 工具

StarUML：
看起來功能還不錯，也不會像virtual visio看起來那麼複雜，免費的，但是，只能在windows下執行

ArgoUML：
用java寫成的
所以可以跨平台~還在嘗試中~不過，好像有空間的限制，若太多資料，要買的

bouml
也有各式平台，但是，中文好像有問題。

UML相關網址：
UML blog
鳥毅的Blog

軟體測試

參考資料：
金融資訊系統軟體測試概念(二)：測試類型及測試個案設計

發展計畫書&品質計畫書

計畫書的目標(發展計畫書&品質計畫書)
1. 安排發展的活動，使得可以成功且及時的完成專案，並且預估需要的人力和預算
2. 根據前項的預估 ，來召募人員和分配資料
3. 評估風險
4. 實作SQA (Software Quality Assurance)的活動
5. 提供給管理階層所要下決策需要的資料

發展計畫書的項目
1. Project products (專案會產生出什麼東西，和要給客戶什麼東西)

a. 計設的文件
b. 完成的軟體產品(完成的時間、安裝軟體的地點)
c. 訓練的文件(時間、地點)

2. Project interface (若與其它系統溝通，要定義的介面)

a. 與其它軟體的溝通介面
b. 與同專案的其它軟硬體溝通的介面
c. 與其它硬體溝通的介面

3. Project methodology and development tools for each phase (在每一個階段要使用的發展方法與發展工具)
4. Software development standards and procedures (發展的標準與程序)

列出所有要用到的軟體發展程序的標準

5. The mapping of the development process：發展程序的時程表

a. 估計每一個活動的時間
b. 每一個活動與其它活動的相關性(甘特圖)
c. 估計每一個活動所需要的專業資源

6. Project milestones (里程碑)

每一個里程碑要完成的時間和產品

7. Project staff organization (員工組織)

a. Organizational structure (組織架構)：參與的人員(包含承包商的人員)
b. Professional requirements (專業的需求)：像是CMMI的資格啦~
c. 每一個活動需要的人員數
d. Names of team leaders and team members：透過name了解這一個team主要是在做什麼事情

8. Development facilities (所需要的設備，包含軟硬體)
9. Development risks (研發所會遇到的風險)

a. Technological gaps (技術差距)
b. Staff shortages (人員不足)
c. Interdependence of organizational elements (組織之間互相的依賴)：像是承包商的進度會影響到主要的進度

10. Control methods (收集專案資料以便讓專案管理者了解情況)
11. Project cost estimation (估計專案需要的成本)

品值計畫書的項目
1. Quality goals (品質目標)：最好用量化來說明需要達到的水準，不要說錯誤要很低，要說在100年內只能出一次錯，這樣的量化。
2. Planned review activities (計畫審查活動)：包含design reviews (DRs)、design inspections、code inspections...

a. 審查活動的範圍
b. 審查活動的類型
c. 審查活動的排程
d. 審查活動的細節
e. 誰要負責審查活動

3. Planned software tests (軟體測試計畫)

a. 單元測試、整合測試、完整系統測試
b. 軟體測試的型態，包含電腦規範、用軟體來測試
c. 測試活動的時間排程
d. 特定的程序要實現
e. 誰負責測試活動

4. Planned acceptance tests for externally developed software (對額外要用到的軟體作可靠度測試)

a. 購買的軟體
b. 承包商所開發出來的軟體
c. 客戶提供的軟體

5. Configuration management (建構管理)：必須說明要整個專案控制進度使用的軟體和程序是什麼

「問題」：小專案是否要development plans and quality plans？
1. 若根本不需要的專案，像是15天就可以完成的專案就不需要。
2. 依據此專案是若失敗是否會損失很大；若不會很大，則不需要計畫書；若會損失很大，則需要計畫書
3. 某一些專案計畫書是責任也是義務

小專案所需要注意的事項
The development plan:

a. Project products, indicating "deliverables"
b. Project benchmarks
c. Development risks
d. Estimates of project costs

The quality plan:

a. Quality goals

若設計給公司內部使用的系統，是否需要計畫書？
優點：

a. 避免被否絕預算
b. 避免對其它公司的專案、造成傷害
c. 避免對公司的決策出現錯誤

對內部員工的好處：

1. 比較能按照進度日完成，且比較不容易被否絕這一個提案
2. 若會延遲可以提早知道；並且可以早一點嘗試解決問題
3. 較少對內部造成傷害

對組織的好處：

1. 降低市場損失的風險
2. 降低因延遲使得公司被起訴的風險
3. 降低損壞公司的名聲
4. 降低增加預算的風險

Software quality factors：軟體品質因子

McCall's factor model
提出十一個軟體品質的因素

分成三大項，每一項分成多個小項
Product operation factors：
Correctness
輸出是精確的、輸出的資訊完整的、資訊具有時效性、資訊具有可用性、coding的standard和文件的standard
Reliability
處理錯誤使得系統可以提供服務、定出可以容忍的錯誤率
Efficiency
要完成所有功能所需要硬體、在硬體上可以發揮最大的效能、所需的硬體的花費
Integrity
系統的安全性、不能讓user拿到不該拿的資料、確定使用者有哪一些權利(write、read...)
Usability
當訓練新的使用者時，所需要花費的時間

Product revision factors：
Maintainability
由user與工程師去尋找bug和解決bug的努力
是否有模組架構與撰寫程式標準和撰寫文件
Flexibility
系統最好可以適用在多數類似的使用者身上
Testability
提供一些結果與記錄檔
在開始系統之前，提供一些記錄檔與報告
自動提供錯誤的訊息記錄
Product transition factors：
Portability
系統可以在不同的作業環境與硬體上執行
Reusability
設計新的系統可以使用多少舊系統的元件
可以節省資源，較短的時間，並且提供較高的模組品質
Interoperability
建立接口，可以跟讓不同的系統溝通
明確指出輸出的標準結構

What is software quality?

軟體的特性：
1. 複雜性
2. 不可見的

軟體的三種錯誤
1. error：程式的語法錯誤或是與客戶之間的需求的邏輯錯誤。有並不是所有的error都會變成fault，有一些時候這一些誤錯的程式碼並不會影響到到程式的功能性。
2. fault：程式錯誤，但尚未被觸發或是永遠不會達成的條件。換句話說，fault就是沒有被觸發的failure(像是有一些功能使用者完全不會用到)。
3. failure：導致出來的結果錯誤或中斷軟體運作



9種導至軟體出現的錯誤
1. Faulty requirements definition
2. Client-developer communication failures
3. Deliberate deviations from software requirements
4. Logical design errors
5. Coding error
6. Non-compliance with documentation and coding instructions
7. Shortcomings of testing process
8. User interface and procedure errors
9. Documentation errors