システム開発会社

システム開発会社（Software Development Process）とは、ソフトウェア製品の開発の構造を意味する。ソフトウェアライフサイクル、ソフトウェア開発プロセス、ソフトウェアプロセスもほぼ同義語である。開発工程にはいくつかのモデルがあり、開発工程内の各種タスク・活動のための手法を提案している。

プロセスとメタプロセス

ソフトウェア開発組織の巨大化とともに開発工程に関する方法論が提案されるようになってきた。アメリカでは軍需での契約を獲得する条件としてプロセスモデルに基づいた評価が行われるため、それが方法論の発達を促したとも言える。ISO 12207 はプロジェクトのライフサイクルを選択・実装・監視する手法に関する標準規格である。

能力成熟度モデル(CMM) は主要なモデルの1つである。独自のアセスメントにより組織が自身で定義したプロセスにどれだけ忠実に従っているかを測る。このとき、そのプロセスの品質そのものやソフトウェア製品の品質は関与しない。CMM は徐々に拡張され能力成熟度モデル統合(CMMI) となった。ISO 9000 は形式的に構成されたプロセスとその文書に関する標準規格である。

ISO 15504 は、ソフトウェアプロセスのアセスメントのためのフレームワークであり、Software Process Improvement Capability Determination (SPICE) とも呼ばれる。この標準規格はプロセスを比較するための明確なモデルとなっている。SPICE も CMM や CMMI と同様に使われている。それは、ソフトウェア開発を管理/制御/誘導/監視するためのプロセスのモデルである。このモデルを使って、ソフトウェア開発において組織やプロジェクトチームが実際何をしているのかを測る。その情報を元に弱点を検出し、それを克服するよう改善する。同時に長所も探し出して、それを組織やチーム全体の共通の慣習にして継続させるようにしていく。

シックス・シグマはプロセス管理の方法論の一種であり、統計分析により企業の経営品質を測定し、それを向上させる。製造やサービスのプロセスでの問題点を検出して排除するのに使われる。最大許容欠陥発生率は百万回につき 3.4回である。しかし、シックス・シグマは製造業を対象としているため、ソフトウェア開発に適用するにはさらに研究が必要である。

開発工程

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

開発工程モデル

ここ数十年のソフトウェア工学の目標のひとつとして、反復可能かつ予測可能な開発工程の方法論を見出し、生産性と品質を向上させるということが挙げられる。一部の人々はソフトウェア開発の一見して手に負えないタスクを体系化し、形式化しようとしてきた。他の人々はソフトウェア開発にプロジェクトマネジメント手法を適用した。プロジェクトマネジメントを適用しなければ、ソフトウェアプロジェクトは簡単に納期に遅れたり、予算を超過したりする。多くのソフトウェアプロジェクトは実際に機能/コスト/納期に問題を抱えており、プロジェクトマネジメントの困難さを証明している。

形式手法

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

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

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

形式手法は開発工程に様々な形で入り込んできつつある（例えば、OCL、JML、モデル駆動型アーキテクチャなど）。

データベース設計

クリス・デイトなどの人々は、関係データベースによるデータベース設計の基盤となるいくつかの原理を提唱している。

＜直交設計の原理 (Principle of Orthogonal Design, POOD)<ref>＞
・Database - D. McGoveran とクリス・デイト
・Database - D. McGoveran とクリス・デイト
・David

この原理を簡単に述べると、関係データベースでは、同一の事実を表現するために複数の関係が定義されてはならない。ただ一つの関係で定義しなければならない。データベースの正規化の文脈では、直交設計の原理は、制御できないほど冗長化した記憶域、およびデータベース上のあいまいな表現を、排除する。
＜正規化の原理 (Principle of Full Normalization, POFN)<ref>Date, C. J. ほか (2006) pp.182-183 、一部改変</ref>＞
* 第5正規形 (5NF) でない関係は第5正規形の射影の集合に分解される (正規化される) 。
* 分解は無損失である。
* 分解は従属性 (関数従属性・多値従属性・結合従属性) を維持する。
* 復元プロセスではすべての射影が必要である。
* 分解はすべての関係が第5正規形になった時点で終了する。

フリーズ

フリーズ（）とも言い、コンピュータまたはソフトウェアが何らかの原因によって応答しなくなる状態を示す。日本語では「固まる」という言い換え方もある。

ユーザーからの入力に対して、コンピュータが何らかの反応はするがそれが期待されたものではない（間違っている）ときは、「誤動作」というのが普通であり、「フリーズする」とは言わない。
また、Windows 2000やWindows XP、Windows VistaなどのWindows NT系OSではアプリケーションがフリーズすると、ウィンドウ部分の先端に「(応答なし)」と表示され、アプリケーションのアイコンがウィンドウの形に変わることがある。

フリーズの原因はさまざまである。例えばソフトウェアやデバイスドライバのバグ、物理メモリのエラーやCPUの熱暴走などの物理的な問題が挙げられる。

OSによっては、任意のアプリケーションを強制終了する機能を備えている。この機能を用いることで、フリーズしたアプリケーションを強制終了することができる。MS-DOSやWindows 3.1などの古いOSではこの機能を備えていないために、アプリケーションがフリーズした場合、コンピュータの再起動が必要となる。

LinuxカーネルやMac OS Xにおけるカーネルパニックもフリーズの一種である。

ユースケース

ソフトウェア開発工程によっては単純なユースケースだけを要求定義に使用すればよい場合もある。しかし、場合によってはより詳細なユースケースが必要なこともある。プロジェクトの規模が大きければ大きいほど、ユースケースの詳細さが求められる傾向がある。

ユースケースの詳細さのレベルはプロジェクトの段階によっても異なる。最初のユースケースは要約程度でよいが、開発工程が進むに従って、より詳細なユースケースが必要となってくる。このためユースケースに要求されるものは異なってくる。当初はユーザーの観点でビジネス上の要求をまとめるための要約レベルのユースケースでよい。しかし、開発が進むと開発者は設計の指針として詳細なユースケースを必要とするようになってくる。

ラショナル統一プロセスでは、要約ユースケースをユースケース図として描き、コメントとして略式の記述を入れ、さらにイベントの流れについて詳細な記述を加えていく。これらを1つのユースケースツール（つまり、UMLツールなど）で入力できる場合もあるし、もちろん別々にテキストエディタで書くことも可能である。

RAD

RAD, rad

・rad - ラジアン
・rad - 放射線における吸収線量の古い単位「ラド」。0.01グレイ。
・RAD (計算機プログラミング環境) - 計算機プログラミング環境。
・国家労働奉仕団 (Reichsarbeitsdienst, RAD) - ナチスの組織。
・RADWIMPS - 日本のロックバンド。

ca:RAD
de:Rad (Begriffsklarung)
el:Ραντ
en:RAD
eo:RAD
es:Rad
et:Rad
fr:RAD
hr:Rad
it:RAD
nl:Rad
pl:Rad
ru:Рад
sh:Rad
sv:Rad

プロセスとメタプロセスソフトウェア開発組...