2009年10月15日

Criteria for Selecting a Methodology - 選擇開發模型的標準

選擇開發模型的標準

(1) Clarity of User Requirements - 清晰的使用者需求
(2) Familiarity with Technology - 使用技術的嫻熟
(3) System Complexity -  系統複雜度
(4) System Reliability - 系統可靠度
(5) Short Time Schedules - 短暫的開發時程
(6) Schedules Visibility - 計畫表的可見度（計畫是否按照時程進行）



*1 系統分析與設計的同時，就要發展測試計畫，藉由每個階段的測試，獲得較高的系統可靠度
*2 藉由系統雛形做溝通，因此獲得較清楚的使用者需求
*3 因缺乏系統基礎性的考量 （Ex：系統架構，安全，控制上的考量）
*4 因最後會重新撰寫程式，較其他模型適合引進不成熟的技術
*5 系統建立之前，可確定問題，產生比較可靠的系統，而且不忽略基本的基礎架構，安全，控制的需求
*6 因最後需重新撰寫程式，因此耗時較多
*7 因此方法需要使用者，在發展系統時一起工作 ，因此獲得較清楚的使用者需求
*8 因其適用於小專案，複雜度通常不高
*9 因此方法需要使用者，在發展系統時一起工作，客戶需與程式設計師一起定義需求，測試，而這一點常常很難遵守



On 沒有留言:
At：

Extreme programming(XP) - 終極程式


定義：

強調使用者滿意，分工合作
XP 的核心價值：溝通，簡化，回饋，勇氣
三個進行步驟
      (1) 做出 User Stories （使用者故事：用來描述系統該如何做）
      (2) Coding （寫程式）
      (3) Test （測試）
適用小專案（程式設計師 10 人以內）
最後整合所有小系統 -> 完成
沒有回溯線

優點：

XP projects deliver results sooner than even the RAD approaches
比 RAD 的方法更快能產生系統

缺點：

1.  It is not advised for mission-critical
重要的資訊系統多會長時間使用，因此使用 XP 方法的效用受到質疑


2. Since little analysis and design documentation is produced with XP, there is only code documentation
在分析與設計階段，使用 XP 方法，產生的文件很少，只有程式文件而已，因此要維護 XP 所建構的資訊系統幾乎不可能


3. Methodology requires considerable on-site user input, something that is frequently difficult to obtain
此方法需要使用者，在發展系統時一起工作
(1) 定義需求
(2) 客戶測試
這一點常常很難遵守



On 沒有留言:
At：

Throwaway Prototyping - 丟棄雛形法


定義：

當用來做系統雛形的軟體與最系統完成的軟體不一樣時，就要用丟棄雛形法
多了一個整體性分析與整體性的設計可以兼顧系統基礎架構，安全，控制上的問題
Design Prototype 只是一個工作系統而不是最後可執行的系統
此系統雛形可能有很多個（子系統），此多個系統雛形的目的除了與使用者溝通外，主要目的是用來降低風險（確保使用者的需求有被執行）

優點：

1. Using prototypes to refine key issues before a system is built
系統建立之前，可確定問題，產生比較可靠的系統


2. 不忽略基本的基礎架構，安全，控制的需求

缺點：

It may take longer to deliver the final system compared with system prototyping
會比雛形法花更多的時間（因為要做整體性的分析與設計，而且要重新撰寫程式，所以花費較多間）



On 沒有留言:
At：

System Prototyping - 雛形法


定義：

透過系統雛形使使用者初步了解系統
透過軟體工具的幫忙，讓系統分析師與使用者可以在系統分析與設計階段，藉由系統雛形做溝通，以便直接快速的了解使用者的需求
最後的系統是由系統雛形直接寫程式產生的
System Prototype 與 System 的系統軟體通常差不多

優點：

1. Very quickly provides a system for users to evaluate
使用者可以很快拿到一個可以評估的系統，透過此系統雛形使用者可以了解此系統是否為需要的，以便做修正


2. Reassures users that progress is being made
讓使用者可以放心，系統是根據其意見來做改進的

缺點：

1. Is the lack of careful, methodical analysis prior to making design and implementation decisions
缺少系統化的方法來進行分析工作


2. Fundamental deign limitations that are a direct result of an inadequate understanding of the system's true requirements early in the project
缺乏系統基礎性的考量（Ex：系統架構，安全，控制上的考量）



On 1 則留言:
At：

2009年10月9日

。 & Free Life

&


Free


Life
On 沒有留言:
At：

2009年10月8日

Iterative Development - 反覆式開發法


定義：

Version 可直接給使用者測試，系統可先上線
功能累加 Version 1 （基本基礎功能） -> Version 2 （功能增加） -> Version 3 （功能完整）
外面的整合分析階段，要分析出哪些是基本需求，以便在第一個版本中包含進去
第一個版本的系統要包含最重要及最基本的需求

優點：

1. To the user quickly so that business value is provided
使用者可以比較快速拿到一個可用的系統


2. Since user are working with the system, important additional requirements may be identified and incorporated into subsequent versions
使用者比較容易找到額外的重要需求，以便在下一個版本中實現

缺點：

1. The chief disadvantage of iterative development is that users begin to work with a system that is intentionally incomplete
使用者在中間階段拿到的不是完整的系統


2. Most critical requirements of the system will be available in the early versions and must be patient with the repeated introduction of new system versions
如果不能在第一版本中包含最基本與最重要的功能，系統會發生問題



On 沒有留言:
At：

V-model - 軟體測試管理模型


定義：

以程式設計為主的方法
主張在系統分析與設計的同時，就要發展測試計畫
每個階段要產生可接受的測試設計
因為沒有 planning 而被視為軟體測試管理模型，而非一個系統開發模型
在台灣，一般是大型專案會用 V-model 來作系統的驗證與確認
為了解決 Waterfall 到很晚才發現錯誤而又很難回溯解決的問題

優點：

1. The V-model is simple and straightforward
簡單易懂


2. Improves the overall quality of systems through its emphasis on early development of test plans
因為在較早時點（系統分析階段）就引進測試計畫，所以可以改善系統品質（其他是系統程式設計完成時才做測試計畫）

缺點：

1. It's still suffers from the rigidity of the waterfall development process
還是有 Waterfall 方法死板的問題（不太允許回溯）


2. Is not always appropriate for the dynamic nature of the business environment
並不能完全適用於變化莫測的企業環境

On 沒有留言:
At：
訂閱： 文章 (Atom)