![見出し画像](https://assets.st-note.com/production/uploads/images/107635839/rectangle_large_type_2_e2caa73277986337bd53e539b8672e04.jpg?width=800)
繰り返すライフサイクル〜インクリメンタル開発/イテレーティブ開発
良い子のみんなー!
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
良い子のみんなは「推しの子」見てるかな?
僕は毎週の楽しみになってて、このままシーズン1の終わりまで行ったら「推しの子」ロスで立ち直れないかもしれないし、7月から何を目的に生きていけばいいのか分からなくなりそうだね。
いっそのことアイドルの子どもにでも生まれ変って別のライフサイクルへ移行したい!
良い子のみんなは素晴らしい生きがいを見つけて頑張って生き延びてね。
与太話はこの辺で本題のソフトウェア開発モデルの話をするよ。
インクリメンタル開発モデル
インクリメンタル(増分型)開発モデルは、システム全体を分割し、分割単位ごとに要件の確定、設計、構築、テストを行い、できた部分から追加、統合して作っていくよ。
![](https://assets.st-note.com/production/uploads/images/107636207/picture_pc_c4237cdf22517d697e65a73c7211f606.png?width=800)
ソフトウェアのフィーチャー(機能や特徴)が徐々に増加(インクリメント)していくモデルだね。
フィーチャーの増分や大きさは手法によって様々あるので実際の開発現場では機能A、Bを作って機能Cを作って完成させるとか、機能で分割するか機能の塊(モジュール)で分割するかを考える場合もあるんだ。
バンドで言えばボーカルがメロディだけ考えた物にギターパートを追加、ベース、ドラムでリズムを決めて一つの曲を作り上げる感じかも知れないね。
イテレーティブ開発モデル
イテレーティブ(反復型)開発モデルでは、グループにしたフィーチャー群を、一連のサイクル(多くの場合、固定された期間)の中で一緒に仕様化、設計、構築、テストをして、徐々にシステム全体の完成度を上げるモデルだよ。
![](https://assets.st-note.com/production/uploads/images/107636282/picture_pc_8f9ef99c2bb8a33c7bf46800968cb63a.png?width=800)
プロジェクトで決めた変更範囲に加えて、以前のイテレーションで開発したフィーチャーの変更を含める場合もあって、完成したソフトウェアが提供されるか、開発が中止になるまでイテレーションを継続するんだ。
バンドで言えば、ジャムセッションとかで全パートの大まかな曲を使って、個別パートの細かい部分を決めたりセッションを繰り返して完成させていくイメージになるんじゃないかな?
当然、メリットもデメリットもある
シーケンシャル開発モデルの弱点をカバーできる点はインクリメンタル開発、イテレーティブ開発のメリットだね。
メリット
・要求、要件に変更があった場合に、柔軟に対応ができる。
インクリメンタル開発であれば分割単位での見直しで済む。
イテレーティブ開発であればイテレーティブごとに全体の仕様見直しでカバーできる。
・ユーザーからのフィードバックを受けた改善がしやすい。
イテレーティブ開発はイテレーティブごとにステークホルダーに提供し、イテレーティブごとの要求を確認できる。
インクリメンタル開発はシステム全体の提供はできないが作成済み機能についての意見を取り入れることが可能となる。
・リスクや問題点の早期発見。
インクリメンタル、イテレーティブともに1サイクルごとの期間が短く、次のサイクルまでにリスクや問題点が検出しやすくなる。
デメリット
・計画、管理が複雑になる
短期間で要件定義からテストまで行うことが前提となるため、遅延した時は対策やリソース配分が難しい場合がある。
・テストが重複したり管理が複雑になる
特にイテレーティブ開発は最初にシステム全体で提供されるためテストの内容が各イテレーティブで重複する。
また、インクリメンタル開発では機能ごとのテストはできているが、追加された機能の影響を確認する為に同じテストを行うなどの重複があり、システム全体のテストはどのタイミングでどこまで確認するかなど管理も複雑化する。
ウォーターフォール開発も含めて、各モデルの特徴とメリット、デメリットから、どのタイミングでどんなテストをするかを考えていく必要なんだね。
その他の開発モデル
• ラショナル統一プロセス(RUP):各イテレーションは他と比べて長期(例えば 2~3 か月)に なる傾向にあり、フィーチャー増分は、関連するフィーチャーで構成するいくつかのグループなど、期間に対応して大きくなる傾向にある。
• スクラム:各イテレーションは他と比べて短期(例えば、数時間、数日、数週間)になる傾向に あり、フィーチャーの増分は、わずかな機能強化、および/またはいくつかの新しいフィーチャーなど、小さくなる傾向にある。
• カンバン:イテレーションの期間の長さが固定されているかどうかに関係なく実装できるので、 完了時に単一の機能強化やフィーチャーをリリースすることも、複数のフィーチャーをまとめて 一括してリリースすることもできる。
• スパイラル:増分を試行しながら追加する。増分は、後続の開発作業で大幅に作り直すことも破棄することもある。
開発モデルの種類については実際にお仕事で関わってみないと分かりにくい点は多いんだけど、各モデルの特徴や期間の目安なんかで区別して覚えてね。
もし良い子のみんなが既にIT業界のお仕事してるなら、自分の所属組織の偉い人に開発モデルは何かを聞いたり、どんなメリット、デメリットでその開発モデルを使っているのかを聞くと理解が深まるかもしれないね。
では、今回はこの辺で!
最後まで読んでくれた良い子のみんなー!
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか?