在Agile專案中如何進行效能工程

Performance Engineering in an Agile Project
http://www.infoq.com/news/2009/03/agile-performance-engineering

Mar 25, 2009
Posted by Vikas Hazrati
Published i InfoQ

效能工程是重要的軟體開發規範, 它確保應用程式有被適當的架構, 設計, 撰寫和測試, 來確保效能的穩定

然而, 在傳統的專案中, 效能工程的範圍僅侷限於效能測試, 也就是重點是超過24小時的條件下進行測試. 而不是去確定的工作量(workload)模式和改進處理的過程, 以得到更好的效能. Balasubramanian,P在此分享了他在scrum中如何進行效能測試的經驗 (http://projectmanagement.ittoolbox.com/research/performance-engineering-in-scrum-5892).

Balasubramanian 認為效能測, 應該包含以下活動:

- Collecting and validating the non functional requirements
- Developing the required models for analysis
- Developing a performance test strategy
- Reviewing the architecture and application code to ensure compliance to performance best practices.
- Reviewing the deployment of the application, and
- For pre-existing applications, reviewing the design and code to suggest appropriate tuning activities

並且他認為, 效能工程應該是Agile中重要的活動, 理由是

- It provides immediate feedback about the system in each sprint
- It is easy to develop a false impression about performance – This is particularly true in Agile projects where a lot of focus is on delivering business value in each iteration. This usually results in  diminished focus on the system quality attributes.
- Refactoring may introduce code that performs poorly.
- The goal is shippable, production quality code - Performance engineering helps in ensuring that the system is designed, built and validated against the required 'Quality of Service' requirements.

Balasubramanian 建議在Scrum中的效能工程, 應該把重點放在以下四個階段(http://hosteddocs.ittoolbox.com/bp073008.pdf):

I. 規劃階段

了解效能工程活動的需求和規劃

# 使用個案和效能 - 了解系統每個使用個案的品質
# 效能測試的策略 - 詳細列出校能測試範圍, 環境需求, 工具, 軟體版本費用, 量測指標, 和測試結果的格式
# 在產品backlog中列出效能工程的活動 - 這些活動包括工作量模塑, 效能測試, 效能評估等等, 應該是backlog的一部份, 不會被遺漏掉


II. 系統架構設計階段

除了系統功能和業務需求方面, 可以從系統品質方面來驗證受測系統的架構

# 架構評估 - 從效能的觀點 - 為了能著重於品質, 架構必須使用下列其中一種方法來評估:
    * Architecture Tradeoff Analysis Method (
www.sei.cmu.edu/ata/iceccs.pdf)
    * Cost Benefit Analysis Method (
www.sei.cmu.edu/news-at-sei/features/2002/1q02/feature-2-1q02.htm)
    * Active Reviews for Intermediate Design (
www.sei.cmu.edu/publications/documents/00.reports/00tn009.html)


III. Sprints

建立一些工作項目, 以用來產出高水準的軟體
# 代碼 -  除了編碼準則外, 應該要有些準則來述說如何達到好的效能
# 建立效能單元測試 - 開發人員應該撰寫單元測試, 去測試在sprint期間, 所開發的系統的效能. 雖然, 一開始獲益可能不大, 因為系統才剛開始. 但是, 隨著系統成熟度的成長, 效能單元測試會變得越來越有用
# 檢視設計和程式碼 - 使用像JProbe, FxCop這樣的工具, 來自動化執行程式的檢視, 以找出效能的問題.
# 找出要做的效能測試和自動化它 -
# 找出瓶頸並修復效能的問題 - 在sprint N找出的效能問題, 要在sprint N+1中被修復
# 效能工程的sprint - 最後, 團隊應該考慮每2~3個sprint中, 穿插一個效能功能的sprint. 像是效能測試, 效能評估, 能力預測(capacity projection)等, 都可以在sprint中被處理.


IV. 收尾階段(Closure Phase)

部署完整的系統到真正客戶的環境中(production environment)
# 建立效能監控系統 - 系統應該使用工具被監控, 像是JAMon, 來即時報告效能的問題.

為了要使這個流程能早點被採用, Scott Barber提供一些密技, 告訴大家在agile專案中, 要如何參予, 如何更有生產力
http://www.logigear.com/newsletter/explanation_of_performance_testing_on_an_agile_team-part-1.asp

Balasubramanian承認在任何專案中, 要建立效能工程會遭遇到很多挑戰. 最大的挑戰是心態的改變, 把重點放在系統品質的屬性(system quality attributes), 而不只是系統功能而已. 然而, 建立效能工程的實踐的回報, 是遠遠超過sprint一開始的投資.

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()