このページをはてなブックマークに追加このページを含むはてなブックマーク このページをlivedoor クリップに追加このページを含むlivedoor クリップ

目次

ソフトウェアプロセス

  • プロセスの改善はソフトウェア組織の利益のためだけではなく、そこで働く才能ある人を救うことになる。
    • プロセスが混沌としているがために才能ある人にしわ寄せが集まると、将来に必要な自己啓発も学習も新たなチャレンジもその人から奪ってしまうことになるからである。
  • 上流工程の作業では、ユーザーをヒアリングして、ドキュメントを作成してレビューする仕事がほとんどである。
    • ドキュメントの品質が低ければ、プロジェクトに大きな影響を与えることを自覚しなくてはいけない。
  • 下流工程はオフショアが進んでおり、ドキュメントなしに開発を委託するのは困難である。
    • 日本人ではない相手に、正確に用件を伝えるためにはドキュメントが必要である。

ソフトウェアプロセスモデルの種類

ウォータフォールモデル

 基本計画(要求定義書)、外部設計・機能設計(機能設計書)、内部設計(詳細設計所)、プログラム設計(プログラム設計書)、プログラミング(ソースプログラム)、テスト(テスト仕様書)の順に開発を行う手法。次の工程にエラーを持ち越さないように、各工程でデザインレビューを行い、生産物を次の工程の入力として引き渡す。

 また、ウォータフォールモデルのメリットとデメリットは次が挙げられる。

  • メリット
    • 全体から細部、外部から内部、設計から開発へ進むので全体的な把握がしやすく、大規模開発に適する。
    • 工程順にシステム開発を行うため、スケジュールの決定や人員計画などの資源配分・工数管理・責任の明確化は容易である。つまり、分業化が容易。
  • デメリット
    • 開発に時間がかかる。
    • 工程順に開発を行うため、一般的に後戻りができない。
    • 万一後戻りが生じれば、時間的・工数的ロスが大きく、効率が著しく低下する。
    • 仕様が不明確な場合や、複雑で理解しにくいものには不向きである。
    • 要求仕様との差が開発終了間際で発見されることも多い。

プロトタイプモデル(プロトタイピング)

 開発初期に短期間で暫定的に動作可能な試作品を完成し、要求仕様の確認・評価、ユーザーインタフェースの確定や性能確認を行い、後続段階での仕様変更による手戻りを防ぐ手法。

 プロトタイプの種類によって次の2つに分類できる。

  • 使い捨て型
    • 簡単な試作品目的だけのプロトタイプを作成し、改めて本格的なシステムを開発する。
  • 改良型(積み上げ型)
    • 洗練度の高いプロトタイプを作成し、改良を繰り返しながら最終的なシステムを開発する。

 また、プロトタイピングのメリットとデメリットは次が挙げられる。

  • メリット
    • 試作品や雛形に基づいてユーザーと開発者が機能・操作性などを確認してから本格的なシステム開発を行うので、利用部門と開発部門との認識・解釈のずれや曖昧さを取り除くことができる。
    • ユーザーのシステムに関する興味や関心が深くなり、運用への移行がスムーズに行われ、結果としてユーザーニーズに合ったシステムができる。
    • 開発者も段階的に経験を積むことにより、能力向上と自信の強化が図れる。
    • ユーザーが説明しにくく、開発者が理解し難いシステム開発に適しているほか、プロトタイプに基づく正確な見積もりができる。
  • デメリット
    • 試作品を簡単に作成できるツールが必要である。

ラピッドプロトタイピング

 ツールによる超短期でプロトタイプ作成を繰り返す手法。

成長モデル

  • =エボリューショナルモデル
  • 早期に核となる小さなシステムを開発し、その後、機能の追加ややんこうなどの開発を繰り返しながら、成長させていくプロセスモデルである。
  • ウォータフォールモデルは要求仕様の変更に柔軟に対処できないという最大の欠点があった。それを解決するようにしたのが成長モデルである。
  • 成長モデルは、利用者の要求仕様の変更がある度に、ソフトウェア開発工程を繰り返し行う。何度も繰り返すことにより、ソフトウェアプロセスが成長していく。

 また、成長モデルのメリットとデメリットは次が挙げられる。

  • メリット
    • 変更の要求に対応するので、ソフトウェア開発の実際場面にのっとっている。
  • デメリット
    • 完成するまでに何度も繰り返すので、開発工数や費用の見積もりが困難であるなど、開発管理がしづらい。

スパイラルモデル

 独立性の高いサブシステムごとにシステム設計、プログラミング、テストの工程を繰り返しながら、徐々に開発範囲を拡大し、改良を加えて全体を完成させる手法。各サブシステムの要求定義や外部使用の明確化・確認のためにプロトタイプを使用し、その後ウォータフォールモデルで開発を行う。つまり、ウォータフォールモデルと成長モデルの利点を取り入れていることになる。当面必要なシステムが早期に利用可能となる。

 また、スパイラルモデルのメリットとデメリットは次が挙げられる。

  • メリット
  • 顧客の要求と最終実装が乖離しないという特長を持つ。
    • 開発の最初の段階にプロトタイプモデルを活用すると、利用者に使いやすいソフトウェアの開発が容易になる。
    • サブシステム毎に順次開発していくので、後戻りも起こりにくく、また一度に多くの要員を必要としない。
    • 技術者の確保がやりやすい。
    • ユーザー要求やニーズが反映されやすく、さらに開発者とユーザー両者の開発・運用経験が次の開発に活かされる。
  • デメリット
    • 開発フェーズを独立したサブシステム単位にする必要がある。

インクリメンタルモデル

  • システムを独立性の高いいくつかのサブシステムに分割して、サブシステムごとに順次開発、リリースしていくプロセスモデルである。サブシステムの開発が並列進行する点が、スパイラルモデルと異なる。
  • 最初にシステム全体の要求定義を行い、要求された機能をいくつかに分割して段階的にリリースするので,すべての機能がそろっていなくても、最初のリリースからシステムの動作の確認をすることができる。

エボリューショナルモデル

 システム全体のプロトタイプを最初に作り、それをバージョンアップしていく。スパイラルモデルは、部分毎にプロトタイプ、バージョンアップとしながら全体を作っていくので、この点で異なる。

契約モデル

 ソフトウェア開発工程を作業ごとに分割し、それぞれ発注側と受注側で契約を交わしながら開発を進めていく手法。発注者からは、仕様・技術情報・納期などの発注内容を示す。一方、受注者は、提案書・開発の成果物などを提出する。この手続きを形式的な契機にして、互いに取り交わしてソフトウェア開発をしていく。

 契約モデルでは、ソフトウェアの分割が容易になり、開発管理もしやすい。

参考文献

  • 『ソフトウェア開発技術者 合格エッセンシャルハンドブック』
  • 『平成12年度 【要点・重点】短期集中速攻対策 第1種』
  • 『The BUG』
  • 『SEの文章術』