<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[プロセス管理]]></title><description><![CDATA[プロセス管理]]></description><link>http://www.isummary.jp/category/77</link><generator>RSS for Node</generator><lastBuildDate>Fri, 13 Mar 2026 05:38:45 GMT</lastBuildDate><atom:link href="http://www.isummary.jp/category/77.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 06 Jul 2019 05:46:16 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[ウォータフォールモデル]]></title><description><![CDATA[<p>ウォータフォールモデルは、古くから利用されているシステム開発モデルで、ほとんどの開発プロジェクトでこのモデルが使用されるほど広く普及していました。 
<br />このモデルは、ソフトウェアの各開発工程を上流から下流まで段階的に区切りながら、流れ落ちる滝のように見立てています。<br /></p>
特徴<a class="anchorjs-link " href="http://se.insidekb.jp/doku.php/36/16#%E7%89%B9%E5%BE%B4"></a>
<p>ウォータフォールモデルは、原則的に手前の工程に遡ることができないので、以下のような特徴をもっております。</p>
開発工程を明確に区切って、各工程毎に厳密な確認と検証を行う各工程の成果物を文書にきちんと纏めて、そのアウトプットを次の工程のインプットにする
利点<a class="anchorjs-link " href="http://se.insidekb.jp/doku.php/36/16#%E5%88%A9%E7%82%B9"></a>
<p>ウォータフォールモデルの利点は、管理と工数見積もりがやりやすいところです。</p>
開発管理がやりやすく、特に大規模なソフトウェア開発に適している工数見積もりがやりやすい、特に人月ベースの契約受注プロジェクトに適している業務コンサルタント、システムエンジニア、プログラマ、テスタによる分業体制が確立しているため、
参加者が担う役割は固定的で考える事が少ない要員の調達が比較的に容易に行えるため、特に労働集約型ビジネスモデルに適している
欠点<a class="anchorjs-link " href="http://se.insidekb.jp/doku.php/36/16#%E6%AC%A0%E7%82%B9"></a>
<p>ウォータフォールモデルの欠点は、コストが高く品質管理がしにくいところです。</p>
ソフトウェアの実物を見られるようになるまでの時間が長い設計と設計の成果物の検証とも机上レベルでしかできず、品質が担保しにくい問題の早期発見が難しく、遅れるほど解決のコストが大きくなる価値が少ないドキュメント作成にもやたら工数がかかる
<p>このためウォータフォールモデルを採用するほとんどの開発プロジェクトでは、前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、後戻りが発生する場合は変更管理によって公式に決定し、後戻りや横展開を確実にフォローするように工夫しております。</p>]]></description><link>http://www.isummary.jp/topic/42/ウォータフォールモデル</link><guid isPermaLink="true">http://www.isummary.jp/topic/42/ウォータフォールモデル</guid><dc:creator><![CDATA[峯文]]></dc:creator><pubDate>Sat, 06 Jul 2019 05:46:16 GMT</pubDate></item></channel></rss>