ソフトウェア開発工程とは? わかりやすく解説

Weblio 辞書 > 辞書・百科事典 > ウィキペディア小見出し辞書 > ソフトウェア開発工程の意味・解説 

ソフトウェア開発工程

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2023/09/09 20:17 UTC 版)

ソフトウェア開発工程(ソフトウェアかいはつこうてい、: 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) (村上/日本語訳. ソフトウェア設計とは何か?)

外部リンク


ソフトウェア開発工程

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/02/22 21:52 UTC 版)

ソフトウェアプロジェクト管理」の記事における「ソフトウェア開発工程」の解説

ソフトウェア開発工程は、主にソフトウェア開発における生産側の視点関係している。これは、ソフトウェアツールのような技術側の視点とは対照的である。ソフトウェア開発工程は、主にソフトウェア開発管理支援するために存在するのであり、ビジネス上の関心事取り組む方向性とは異なる。多くのソフトウェア開発工程群を、一般的なプロジェクト管理工程群と似た方法遂行することができる。例を示す。 リスク管理は、リスクの測定リスクアセスメント行い、そのリスク管理する戦略構築する過程である。一般的には戦略として、他の人々リスク移管するリスク回避するリスク負の効果低減する特定のリスクのすべてもしくは一部分受け入れる、などが採用されるソフトウェアプロジェクト管理におけるリスク管理は、プロジェクト開始するためのビジネスケースに始まる。プロジェクト開始時のリスク管理には、費用便益分析危機管理計画 (コンティンジェンシープラン) として知られているプロジェクト失敗からの後退オプション群のリストが、含まれるリスク管理サブセットとして、「機会管理」が注目されつつある。機会管理は、潜在的リスクにはその結果として非建設的な影響よりもむしろ建設的な影響があるとすることを除くと、リスク管理と同じ意味である。リスク管理同一方法理論基づいてプロジェクト制御するが、非建設的な用語である「リスク」よりも「機会」という用語を使うことにより、プロジェクトチームが、自分たちのプロジェクトリスク登録簿から得られる蓋然的建設的な結果注目するのを支援する建設的な結果とは、スピンオフプロジェクトや、意外な果実自由に使える余剰資源などである。 要求管理は、要求同定し顧客から聞き出し文書化し、分析し追跡し優先順位づけし、顧客合意する過程であり、要求の変更制御する過程であり、また利害関係者 (ステイクホルダ) とコミュニケーションする過程である。新しく構築するコンピュータシステムもしくは代替するコンピュータシステムの、要求分析工程を含む要求管理は、ソフトウェア開発では重要な作業である。実際には、ビジネスアナリストもしくはソフトウェア開発者顧客ニーズ要求同定する。彼らはこうして要求同定し、そして解決方法 (ソリューション) を設計する変更管理は、プロジェクトスコープ対す変更同定し文書化し、分析し優先順位づけし、顧客合意する過程であり、変更制御する過程であり、また利害関係者コミュニケーションする過程である。新しスコープもしくは代替スコープ変更波及分析は、変更部分要求分析を含む。変更波及分析は、ソフトウェア開発では重要な作業である。実際には、ビジネスアナリストもしくはソフトウェア開発者顧客ニーズ要求同定する。彼らはこうして要求同定し、そして解決方法 (ソリューション) を再設計もしくは変更する理論的には、個々変更ソフトウェアプロジェクト予定経費影響する。そのため当然に変更に対してはその承認前に管理一環としてリスク便益分析が行われる。 ソフトウェア構成管理は、プロジェクトスコープそれ自身、すなわち現に存在するソフトウェア製品同定し文書化する過程である。付随するすべての製品すべての変更の管理含まれる。それにより、製品変更について利害関係者とのコミュニケーションができるようになる一般的にはバージョン管理命名規約過程を含む。 リリース管理は、ソフトウェアリリースについて同定し文書化し、優先順位づけし、顧客合意する過程であり、リリーススケジュール制御する過程であり、リリースについて利害関係者コミュニケーションする過程である。多くソフトウェアプロジェクトでは、ソフトウェアリリースするために、3つのソフトウェア環境利用する。すなわち開発環境テスト環境、および本稼働環境 (プロダクション環境) である。非常に大規模なプロジェクトでは、地理的に分散したチームが、利用者リリースする前に自分たちの成果物統合する必要がある単体テストシステムテストおよび統合テストなどと呼ばれるテストのための環境別途用意され、そして利用者受け入れテスト向けにリリースされるリリース管理サブセットとして、データ管理注目されつつある。利用者になじみのあるデータに基づくテストができるのは、明らかに利用者だけである。そして「現実の」データは本稼働環境 (プロダクション環境) と呼ばれる環境にのみ存在する。そのためプログラマたちが自分たちの成果物テストするためには、多く場合「ダミーデータ」や「データスタブ」を作る必要がある慣習的に、この目的には以前のバージョンの本稼働環境システム使われてきた。しかし企業ソフトウェア開発のための外部協力者信頼しすぎているとの理由から、本稼働環境データ開発チーム渡さないこともある。複合的な環境では、全体的なソフトウェアリリーススケジュールと同様に、テストリリーススケジュールにしたがってテスト環境間で移行されるデータ作られることがある

※この「ソフトウェア開発工程」の解説は、「ソフトウェアプロジェクト管理」の解説の一部です。
「ソフトウェア開発工程」を含む「ソフトウェアプロジェクト管理」の記事については、「ソフトウェアプロジェクト管理」の概要を参照ください。

ウィキペディア小見出し辞書の「ソフトウェア開発工程」の項目はプログラムで機械的に意味や本文を生成しているため、不適切な項目が含まれていることもあります。ご了承くださいませ。 お問い合わせ


英和和英テキスト翻訳>> Weblio翻訳
英語⇒日本語日本語⇒英語
  

辞書ショートカット

すべての辞書の索引

「ソフトウェア開発工程」の関連用語

ソフトウェア開発工程のお隣キーワード
検索ランキング

   

英語⇒日本語
日本語⇒英語
   



ソフトウェア開発工程のページの著作権
Weblio 辞書 情報提供元は 参加元一覧 にて確認できます。

   
ウィキペディアウィキペディア
All text is available under the terms of the GNU Free Documentation License.
この記事は、ウィキペディアのソフトウェア開発工程 (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。 Weblio辞書に掲載されているウィキペディアの記事も、全てGNU Free Documentation Licenseの元に提供されております。
ウィキペディアウィキペディア
Text is available under GNU Free Documentation License (GFDL).
Weblio辞書に掲載されている「ウィキペディア小見出し辞書」の記事は、Wikipediaのソフトウェアプロジェクト管理 (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。

©2025 GRAS Group, Inc.RSS