反復型

ウィキペディア小見出し辞書

反復型

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/09/07 09:26 UTC 版)

「ソフトウェア開発方法論」の記事における「反復型」の解説

反復型開発はプロジェクトを小さな部分に分割し、開発工程中の修正を容易にし、プロジェクトのリスクを低減させる。 基本原則は次の通り。 ウォーターフォールを小規模に何度も繰り返す。一回のウォーターフォールはシステム内の小さな部分を完成させるものである。 全体の要求仕様は反復を行う前に定義される。

反復型

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/05/16 06:41 UTC 版)

「ソフトウェア開発工程」の記事における「反復型」の解説

詳細は「反復型開発」を参照 反復型開発は、ソフトウェアを徐々に開発していく手法であり、問題点や前提の間違いを早期に検出して大きな問題となるのを防ぐ。反復型開発はパッケージでない商用ソフトウェア開発で好まれる。というのも、自分がソフトウェアに何を求めているかをうまく定義できない顧客の要求にも応えて開発していくことが可能だからである。 アジャイルソフトウェア開発は反復型開発からの派生手法である。アジャイルでは、従来よりも軽量で人間中心の視点を導入した。アジャイルでは計画よりもフィードバックを重視する。フィードバックは主にテスト（評価）と開発途中のソフトウェアを外部にリリースすることで得られる。 アジャイルソフトウェア開発は従来の方法論よりも効率的と思われる。少ない工数でより多くの機能を開発でき、品質の高いソフトウェアを開発できる。しかし、ビジネス的観点から見ると、長期的計画を立てるのが困難であるという問題がある。基本的に、必要な機能は開発されるが、それが何時になるのかは不明である。 エクストリーム・プログラミング（XP）は最も有名なアジャイル的手法である。XPでは工程が非常に短いステップに分割される。ウォーターフォール・モデルでは数ヶ月から数年かかる工程を1日から1週間の工程に分割するのである。まず、自動化されたテストを書き、その工程でのゴールを定める。次に2人のプログラマーによってコーディングを行い、全部のテストをパスした段階でその工程が完了する。設計とアーキテクチャはリファクタリングによって生み出され、コーディングの後に完成する。設計はコーディング担当者が行う。設計とコードの統合を行う段階は他のアジャイルソフトウェア開発と同様である。不完全だが機能するシステムがユーザーに配布・評価される。その後葉次に重要と思われる部分に関するテストが書かれ、次のサイクルが開始される。 反復型開発には独自の利点があるが、ソフトウェアアーキテクトはさらに信頼できるソフトウェア開発基盤を生み出そうとしている。そのような開発モデルの基盤には最前線の現場の分析とプロトタイピングが必要である。開発モデルは特定の設計パターンや実体関連図（ERD）に依存していることが多い。反復型開発はコストおよび品質で有利な長期的戦略を採用することにより、事前の基盤を必要としない。 反復型開発への批判は、これらの手法が顧客に対してソフトウェア開発に深く関わること、すなわち開発者的スキルと経験を要求することを問題にする。また、そうでなければこの手法のコストは増大する。それは「どういう家が欲しいか決めかねているなら、試しに私どもに建てさせて気に入るかどうか見てみてください。もし気に入らなかったら、取り壊して立て直します」と言っているようなものである。この批評は、反復型開発の要点を取り違えている。反復型開発では顧客からフィードバックを得るのに家全体を建てる必要はない。従来型の開発手法で実際の開発が始まる前に行っている要求分析と開発完了後に行っている評価を、反復型開発では全工程に分散させていると見ることができる。 実際、アジャイルのコミュニティでは要求仕様を固定せずにソフトウェアを改良していくという点で曲折があった。従来の手法ではこれは許されず、商業的にもナンセンスである。アジャイル的手法ではアーキテクチャの変更を迫るような新たな要求について、顧客が対価を支払わない場合、アジャイル的にプロジェクトは終了させられる。 これらの手法はウェブベースの技術の発展と共に開発されてきた。したがって、アーキテクチャとソリューションの機能のほとんどがアプリケーションのバックボーンに選ばれた技術で実現されていると仮定すると（つまり、ミドルウェアで実現されている。）、これらの手法は実際には保守ライフサイクルと同義である。 リファクタリングは、設計を慎重に行って文書化することの代替案としてアジャイル・コミュニティが提案したものである。アーキテクチャ上の問題に対するリエンジニアリングへの代替案は提案されていない。どちらも比較するとコストがかかる。既存のコードへのリファクタリングを1回通して行うと 10% から 15% のコスト増となると言われている。しかし、この値に再評価やリグレッションテストも含んでいるかどうかは不明である。もちろん、既存のアーキテクチャを捨ててしまう方がさらにコストがかかる。実際、アジャイル的手法を利用した開発ではコスト問題に悩んでいるという調査結果がある(Software Development at Microsoft Observed)。ここでは、基本設計の管理よりもプログラミング担当者らによる定常的なリバースエンジニアリングが強調されている点に注意されたい。 テスト駆動開発（TDD）はアジャイル的手法から生まれた便利な手法だが、同時に問題もはらんでいる。TDDではコードを書く前にそのコードに関する単体テストを書く必要がある。したがって、まずどういうコードを書くかを考え、それを書く前にその単体テストを書けるほど十分に詳細を決定しなければならない。アジャイルソフトウェア開発では簡単な設計からコードを書くのであるから、TDDをアジャイル的でない開発工程モデルに取り入れることはアジャイル的なものとは正反対となる。