ソフトウェア開発工程

ソフトウェア開発工程
中心となる活動
パラダイムとモデル
ソフトウェア開発方法論とフレームワーク
開発支援
プラクティス
プログラミングツール
標準と機関
用語集

ソフトウェア開発工程（ソフトウェアかいはつこうてい、英: Software Development Process）はソフトウェアライフサイクルプロセスのうち、開発に関わるプロセスである。すなわち、ソフトウェアの構想から廃止までの流れのうち、開発部分をプロセスとして捉えたものである。ソフトウェア開発プロセスとも。

開発工程はいくつかのサブプロセスからなる。サブプロセスの種類と関係性を示す開発プロセスモデルが複数存在する。また開発工程とその中の各種タスク・活動のための方法論が提案されている。

サブプロセスモデル

[編集]

開発プロセスは何種類のもサブプロセスからなる。開発サブプロセスのモデルには様々な種類がある。規格としてISO 12207、能力成熟度モデル統合（CMMI）が挙げられる。以下は代表的なサブプロセス（モデル）である。

ソフトウェア要求分析
ソフトウェア製品を作るにあたっての最初のタスクは要求を引き出す・集めることである。顧客はソフトウェアに何をさせたいのかを知っているものである。しかし、その要求は不完全だったり、曖昧だったり、互いに矛盾していたりする。経験をつんだソフトウェア技術者はそれを聞き出して一貫性のある要求仕様に纏め上げる。
仕様記述
仕様記述は可能な限り厳密な方法で開発すべきソフトウェアを正確に記述するタスクである。安全性が重要なソフトウェアシステムでは、開発に先駆けて仕様記述を注意深く行うが、実際に最も成功している仕様記述とは、既存のアプリケーションを理解して改善するために書かれるものであろう。安定していなければならない外部インターフェイスにとって仕様記述は最も重要である。
ソフトウェアアーキテクチャ
ソフトウェアシステムのアーキテクチャとは、システムを抽象的に表現したものである。アーキテクチャはソフトウェアシステムが製品として要求に適合しているかを検証するのに使用される他、将来の追加要求に応えるためにも使用される。アーキテクチャ作成段階ではソフトウェアシステム間や他のソフトウェア製品間のインターフェイスも規定し、ハードウェアやオペレーティングシステムも規定する。
実装
設計からコードを作成する段階はソフトウェア開発において最も明白な工程であるが、必ずしも最大の工程とは限らない。
評価
特に複数の技術者が開発したコードを結合して行う評価はソフトウェア技術者が行う。
文書化
ソフトウェアの内部設計を文書化するタスクは重要だが、しばしば見過ごされている。これは将来の保守と改良に使用される。文書化は外部インターフェイスにとっては最も重要である。
トレーニングとサポート
ソフトウェアプロジェクトの失敗の最大の要因は、そのソフトウェアを最終的に使用する人の育成を全く考えていないことにある。人々は不慣れな環境や領域に進むことには抵抗を示すものである。従ってソフトウェアを配備する段階では、実際にそのソフトウェアを使用する人を対象にトレーニングを行うことが重要である。また、実際に使ってみることでユーザーから問題点や疑問点が多数上げられてくる。それらが次のソフトウェアの開発への入力となる。
保守
ソフトウェアの保守と改良は初期の開発よりも長期に渡り、手間もかかる。本来の設計に馴染まないコードを追加しなければならなくなるだけでなく、既存のソフトウェアがどう動作しているのかを理解するだけでも多大な労力を必要とする。ソフトウェア開発の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人のプログラマーによってコーディングを行い、全部のテストをパスした段階でその工程が完了する。設計とアーキテクチャはリファクタリングによって生み出され、コーディングの後に完成する。設計はコーディング担当者が行う。設計とコードの統合を行う段階は他のアジャイルソフトウェア開発と同様である。不完全だが機能するシステムがユーザー[注釈 1]に配布・評価される。その後葉次に重要と思われる部分に関するテストが書かれ、次のサイクルが開始される。

反復型開発には独自の利点があるが、ソフトウェアアーキテクトはさらに信頼できるソフトウェア開発基盤を生み出そうとしている。そのような開発モデルの基盤には最前線の現場の分析とプロトタイピングが必要である。開発モデルは特定の設計パターンや実体関連図（ERD）に依存していることが多い。反復型開発はコストおよび品質で有利な長期的戦略を採用することにより、事前の基盤を必要としない。

反復型開発への批判は、これらの手法が顧客に対してソフトウェア開発に深く関わること、すなわち開発者的スキルと経験を要求することを問題にする。また、そうでなければこの手法のコストは増大する。それは「どういう家が欲しいか決めかねているなら、試しに私どもに建てさせて気に入るかどうか見てみてください。もし気に入らなかったら、取り壊して立て直します」と言っているようなものである。この批評は、反復型開発の要点を取り違えている。反復型開発では顧客からフィードバックを得るのに家全体を建てる必要はない。従来型の開発手法で実際の開発が始まる前に行っている要求分析と開発完了後に行っている評価を、反復型開発では全工程に分散させていると見ることができる。

実際、アジャイルのコミュニティでは要求仕様を固定せずにソフトウェアを改良していくという点で曲折があった。従来の手法ではこれは許されず、商業的にもナンセンスである。アジャイル的手法ではアーキテクチャの変更を迫るような新たな要求について、顧客が対価を支払わない場合、アジャイル的にプロジェクトは終了させられる。

これらの手法はウェブベースの技術の発展と共に開発されてきた。したがって、アーキテクチャとソリューションの機能のほとんどがアプリケーションのバックボーンに選ばれた技術で実現されていると仮定すると（つまり、ミドルウェアで実現されている。）、これらの手法は実際には保守ライフサイクルと同義である。

リファクタリングは、設計を慎重に行って文書化することの代替案としてアジャイル・コミュニティが提案したものである。アーキテクチャ上の問題に対するリエンジニアリングへの代替案は提案されていない。どちらも比較するとコストがかかる。既存のコードへのリファクタリングを1回通して行うと 10% から 15% のコスト増となると言われている。しかし、この値に再評価やリグレッションテストも含んでいるかどうかは不明である。もちろん、既存のアーキテクチャを捨ててしまう方がさらにコストがかかる。実際、アジャイル的手法を利用した開発ではコスト問題に悩んでいるという調査結果がある(Software Development at Microsoft Observed)。ここでは、基本設計の管理よりもプログラミング担当者らによる定常的なリバースエンジニアリングが強調されている点に注意されたい。

テスト駆動開発（TDD）はアジャイル的手法から生まれた便利な手法だが、同時に問題もはらんでいる。TDDではコードを書く前にそのコードに関する単体テストを書く必要がある。したがって、まずどういうコードを書くかを考え、それを書く前にその単体テストを書けるほど十分に詳細を決定しなければならない。アジャイルソフトウェア開発では簡単な設計からコードを書くのであるから、TDDをアジャイル的でない開発工程モデルに取り入れることはアジャイル的なものとは正反対となる。

形式手法

[編集]

形式手法は要求/仕様記述/設計段階でのソフトウェア（およびハードウェア）問題への数学的対処法である。形式手法の例として、Bメソッド・ペトリネット・RAISE・VDMなどがある。形式仕様記述もZ記法など様々な手法がある。より一般化すれば、有限状態機械のシステムを設計することでオートマトン理論を応用してアプリケーションの動作を解明する。

有限状態機械（FSM）に基づいた方法論で実行可能ソフトウェアの仕様記述ができ、従来的なコーディング工程を省くことができる（仮想有限状態機械及びイベント駆動有限状態機械）。

形式手法はアビオニクスソフトウェアなどの安全性が重要とされるソフトウェアでよく採用されている。DO178Bなどのソフトウェアの安全性保証標準規格では、形式手法の採用が義務付けられている（レベルAの場合）。

形式手法は開発工程に様々な形で入り込んできつつある[注釈 2]。

評価

[編集]

良いプロセスは良い成果を生み出す。ゆえにプロセス管理が行われる。開発プロセスの評価規格としてはISO 15504や能力成熟度モデル統合（CMMI）が挙げられる。

歴史

[編集]

アメリカでは軍需での契約を獲得する条件としてプロセスモデルに基づいた評価が行われるため、それが方法論の発達を促したとも言える。

関連項目

[編集]

脚注

[編集]
[脚注の使い方]

注釈

[編集]
  1. ^ あるいはその一部で、開発チームもユーザーの一部である。
  2. ^ 例えばOCL・JML・モデル駆動型アーキテクチャなどがある。

出典

[編集]
  1. ^ "The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design." Jack W. Reeves. (1992). what is software design?. C++ Journal, Vol. 2, No. 2. (author's copy) (村上／日本語訳. ソフトウェア設計とは何か？)
  2. ^ "If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build lots of the product" Jack W. Reeves. (1992). what is software design?. C++ Journal, Vol. 2, No. 2. (author's copy) (村上／日本語訳. ソフトウェア設計とは何か？)
  3. ^ "the manufacturing team ... build the product ... programming is not about building software; programming is about designing software." Jack W. Reeves. (1992). what is software design?. C++ Journal, Vol. 2, No. 2. (author's copy) (村上／日本語訳. ソフトウェア設計とは何か？)
  4. ^ "no other modern industry would tolerate a rework rate of over 100% in its manufacturing process. A construction worker ... is soon out of a job. In software, ... code is ... revised or completely rewritten during testing and debugging. We accept this sort of refinement during a creative process like design, not as part of a manufacturing process." Jack W. Reeves. (1992). what is software design?. C++ Journal, Vol. 2, No. 2. (author's copy) (村上／日本語訳. ソフトウェア設計とは何か？)

外部リンク

[編集]
「https://ja.wikipedia.org/w/index.php?title=ソフトウェア開発工程&oldid=96883680」から取得