システム開発会社
システム開発会社（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、モデル駆動型アーキテクチャなど）。
システム開発会社おすすめ関連サイト