アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性 - プログラマの思索

アジャイル開発はソフトウェアの品質特性のうち、機能性と信頼性の問題点をすり替えることによって、ソフトウェア開発特有の特徴をうまく取り入れているように思える。 考えたことをメモ書き。 【参考】 ソフトウェア品質特性(ISO/IEC9126)の解説 ソフトウェア品質特性について ISO 9126 - Wikipedia 品質改善.com - 品質特性とは アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索 【1】ソフトウェアの品質を話す時、普通は、機能性と信頼性が暗黙のうちに前提にされている。 仕様書に書かれた機能がシステムに反映されていてそもそも使えるのか、そして、システムの障害が少なくて安定稼働しているか、という点。 ウォーターフォール型開発では、詳細な仕様書を作り、手戻り作業がない前提でシステムを作り始める。 一括請負契約が理由でもあるが、外部設計で決定した仕様に基づい

[mak_in]

WaterFallは障害故障間隔（MTBF）を長くすることによって稼働率を高める、アジャイルでは障害修復時間(MTTR)を短くすることによって稼働率を高める という視点は面白い

[northlight]

ウォーターフォールは障害故障間隔(MTBF)の最大化、アジャイルは障害修復時間(MTTR)の最小化で稼働率を高める。前者は、一度作ったものを基本的には変更なしに動かし続けるハードウェアの発想。

[nobeans]

"機能性の問題を「全ての仕様が反映されているか」から「必要な機能が実装されているか」、信頼性の問題を「いかに壊れないシステムを作るか」から「いかに素早く直せるシステムにするか」に置き換えた"

[tiadeen2]

アジャイルはテスト手法が洗練されている場合に使えるもので、逆に言えばテスト手法がアレゲなプロジェクトでプラクティスを取り入れてもそれほど効果ない…くらいの勢いで読んだ

[tsuyok]

「機能性の問題を「全ての仕様が反映されているか」から「必要な機能が実装されているか」、信頼性の問題を「いかに壊れないシステムを作るか」から「いかに素早く直せるシステムにするか」に置き換えた」

[t-wada]

"機能性の問題を「全ての仕様が反映されているか」から「必要な機能が実装されているか」、信頼性の問題を「いかに壊れないシステムを作るか」から「いかに素早く直せるシステムにするか」に置き換えた"

[PaulYamamoto]

”最近の技術革新のおかげで、壊れないシステムを作るよりも、素早く問題修復できる仕組みが実現されたことで、逆転の発想が可能になったとも言える。”

[indication]

仕様凍結の考え方の違い

[cloud5414]

なるほどね。確かに流行のシステムはこんな感じだわ。

[tinsep19]

アジャイル開発は機能性の問題を「全ての仕様が反映されているか」から「必要な機能が実装されているか」信頼性の問題を「いかに壊れないシステムを作るか」から「いかに素早く直せるシステムにするか」に置き換えた