ソフトウェア開発プロセス
[Wikipedia|▼Menu]
文書化は外部インターフェイスにとっては最も重要である。
トレーニングとサポート
ソフトウェアプロジェクトの失敗の最大の要因は、そのソフトウェアを最終的に使用する人の育成を全く考えていないことにある。人々は不慣れな環境や領域に進むことには抵抗を示すものである。従ってソフトウェアを配備する段階では、実際にそのソフトウェアを使用する人を対象にトレーニングを行うことが重要である。また、実際に使ってみることでユーザーから問題点や疑問点が多数上げられてくる。それらが次のソフトウェアの開発への入力となる。
保守
ソフトウェアの保守と改良は初期の開発よりも長期に渡り、手間もかかる。本来の設計に馴染まないコードを追加しなければならなくなるだけでなく、既存のソフトウェアがどう動作しているのかを理解するだけでも多大な労力を必要とする。ソフトウェア開発の3分の2は保守作業であると言われているが、この統計は誤解を生みやすい。バグの修正は保守作業のほんの一部である。保守作業の大部分は既存のソフトウェアに新たな機能を組み込むことであり、それは別の新たな開発とみなされることが多い。同様に土木・建築でも保守作業が全体の3分の2を占めると言われている。
管理プロセス

ソフトウェアを完成へ向け加工していくプロセスに加え、そのプロセスを管理(マネジメント)するプロセスを管理プロセスと呼ぶ。開発プロセスにおいても管理プロセスが含まれる。
製造工程

ソフトウェア開発には製造 (manufacturing) 工程が事実上存在しない。そのほとんどが設計工程に属する[1]

製造業では企画・設計・製造のプロセスが見出され、製造工程では量産とその最適化(カイゼン)がおこなわれる[2]。しかしソフトウェアは複製コストがゼロであり、コピー・アンド・ペーストで製造が完了するためこの工程が事実上存在しない[3]。もしソフトウェアデータが複製できないとしたら、作業員による完成コードの写経とテスト実行によりソフトウェアは1つずつ量産されるはずであり、これはまさに製造工程である。実際にはコピペでこの工程を丸々スキップできる、すなわち製造工程が存在しない。

ソフトウェアが頻繁に変更されることもこれを示唆している。製造業において製造工程(製造ライン)の全面的変更は極めて稀であり、するとしてもそれは作業員の役割ではない。一方ソフトウェア開発ではリファクタリングをはじめとしたソフトウェア内部の変更が推奨され、それはプログラマーの役割である。頻繁な変更が実作業者におこなわれるのは開発/設計段階であり、すなわちコーディング含むソフトウェア開発は製造工程でなく設計工程に属している[4]
開発工程モデル

ソフトウェア開発プロセスモデルが開発工程モデルである。様々なソフトウェアライフサイクルで共通してみられるいくつかのモデルが存在する。それぞれのモデルには特徴があり、実際の開発ではプロジェクトに応じたモデルを含むソフトウェア開発方法論の選択が重要である。
ウォーターフォール・モデル詳細は「ウォーターフォール・モデル」を参照

ウォーターフォール・モデルでは、開発者は上述の工程(局面、フェーズ)を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し(単体テスト→システムテストの順)、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土台を変更できないというのと同じ考え方である。

ウォーターフォール・モデルでは上流工程での間違いや仕様変更を後から訂正・反映することを考慮していないと考えられがちだが、これは誤解である。これは要求管理に変更制御を含めるかどうかという問題である。

この手法は特に大規模なシステム開発や危険の大きいプロジェクト(軍需関係の契約など)で使われている。各工程ごとに契約・入札が行われる場合もある。

大規模なシステム開発ではサブシステム化も併用し、各サブシステムで時期をずらしてウォーターフォール・モデルを採用する事で、先行するサブシステムで発見した問題を後続のサブシステムでは早い段階の工程で取り入れたり、各工程の要員(設計者・プログラマ・テスターなど)や主要イベント(プロジェクト立ち上げ・レビュー・検収・研修・本番稼動など)の平準化を図る場合も多い。また各工程の内部では後述のスパイラルモデル反復型開発を組み合わせる場合もある。

ウォーターフォールの問題は、要求分析と要求管理についての技術的未熟さから生じることが多い。さらに言えば、開発工程の弱点の把握不足と開発者が問題を理解せずにコーディングを開始してしまうことからも問題が生じる。また、しばしば省略されがちな工程として顧客と開発者の間での共同レビューがある。開発者は危険を承知で設計を進めて開発するが、その設計は最終的には Critical Design Review(最終設計審査)というマイルストーンでチェックを受けることになる。この手法への批判はソフトウェア工学者よりも実際の技術者から出てくることが多い。批判者はWISCY(Why Isn't Someone coding yet?)アプローチなどを信奉している。
反復型詳細は「反復型開発」を参照

反復型開発は、ソフトウェアを徐々に開発していく手法であり、問題点や前提の間違いを早期に検出して大きな問題となるのを防ぐ。反復型開発はパッケージでない商用ソフトウェア開発で好まれる。というのも、自分がソフトウェアに何を求めているかをうまく定義できない顧客の要求にも応えて開発していくことが可能だからである。

アジャイルソフトウェア開発は反復型開発からの派生手法である。アジャイルでは、従来よりも軽量で人間中心の視点を導入した。アジャイルでは計画よりもフィードバックを重視する。フィードバックは主にテスト(評価)と開発途中のソフトウェアを外部にリリースすることで得られる。

アジャイルソフトウェア開発は従来の方法論よりも効率的と思われる。少ない工数でより多くの機能を開発でき、品質の高いソフトウェアを開発できる。しかし、ビジネス的観点から見ると、長期的計画を立てるのが困難であるという問題がある。基本的に、必要な機能は開発されるが、それが何時になるのかは不明である。

エクストリーム・プログラミング(XP)は最も有名なアジャイル的手法である。XPでは工程が非常に短いステップに分割される。ウォーターフォール・モデルでは数ヶ月から数年かかる工程を1日から1週間の工程に分割するのである。まず、自動化されたテストを書き、その工程でのゴールを定める。次に2人のプログラマーによってコーディングを行い、全部のテストをパスした段階でその工程が完了する。設計とアーキテクチャはリファクタリングによって生み出され、コーディングの後に完成する。


次ページ
記事の検索
おまかせリスト
▼オプションを表示
ブックマーク登録
mixiチェック!
Twitterに投稿
オプション/リンク一覧
話題のニュース
列車運行情報
暇つぶしWikipedia

Size:35 KB
出典: フリー百科事典『ウィキペディア(Wikipedia)
担当:undef