システム開発のことならシステム開発 online
人間が行なってきた経営事業の情報処理を、コンピュータプログラムを用いてシステム化する事が現在、主に言われるシステム開発の一つである。当初は、事務作業や単純作業の効率化が目標であったが、次第に経営活動自体に深く関与するようになり、経営改革や組織と表裏一体になりつつある。 なおシステム開発の広義は、企業や団体・組織の仕組み作りにあり、それらに見合った業務の整順化や効率化を図る事である。
20世紀後半にシステム開発が急速に進んだ結果、世の中の様々な活動にシステムが利用されるようになった。その結果、システム上の不備が社会へ甚大な被害をもたらす現象が散見されるようになった。現状では、システムが完全に問題なく作動する保証は出来ないため、フェールセーフ（障害は出るが被害は最小になる仕組み）が求められている。
ここ数十年のソフトウェア工学の目標のひとつとして、反復可能かつ予測可能な開発工程の方法論を見出し、生産性と品質を向上させるということが挙げられる。一部の人々はソフトウェア開発の一見して手に負えないタスクを体系化し、形式化しようとしてきた。他の人々はソフトウェア開発にプロジェクトマネジメント手法を適用した。プロジェクトマネジメントを適用しなければ、ソフトウェアプロジェクトは簡単に納期に遅れたり、予算を超過したりする。多くのソフトウェアプロジェクトは実際に機能/コスト/納期に問題を抱えており、プロジェクトマネジメントの困難さを証明している。
最もよく知られた古い開発工程モデルはウォーターフォール・モデルである。このモデルでは、開発者は上述の工程を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し（単体テスト→システムテストの順）、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土台を変更できないというのと同じ考え方である。
ウォーターフォール・モデルでは上流工程での間違いを後から訂正することを考慮していないと考えられがちだが、これは誤解である。これは要求管理に変更制御を含めるかどうかという問題である。
この手法は危険の大きいプロジェクト（例えば軍需関係の契約）で使われる。ウォーターフォールの問題は、要求分析と要求管理についての技術的未熟さから生じることが多い。さらに言えば、開発工程の弱点の把握不足と開発者が問題を理解せずにコーディングを開始してしまうことからも問題が生じる。
また、しばしば省略されがちな工程として顧客と開発者の間での共同レビューがある。開発者は危険を承知で設計を進めて開発するが、その設計は最終的には Critical Design Review（最終設計審査）というマイルストーンでチェックを受けることになる。
この手法への批判はソフトウェア工学者よりも実際の技術者から出てくることが多い。批判者は WISCY（Why Isn't Someone coding yet ?）アプローチなどを信奉している。
反復型開発は、ソフトウェアを徐々に開発していく手法であり、問題点や前提の間違いを早期に検出して大きな問題となるのを防ぐ。反復型開発はパッケージでない商用ソフトウェア開発で好まれる。というのも、自分がソフトウェアに何を求めているかをうまく定義できない顧客の要求にも応えて開発していくことが可能だからである。
アジャイルソフトウェア開発は反復型開発からの派生手法である。アジャイルでは、従来よりも軽量で人間中心の視点を導入した。アジャイルでは計画よりもフィードバックを重視する。フィードバックは主にテスト（評価）と開発途中のソフトウェアを外部にリリースすることで得られる。
アジャイルソフトウェア開発は従来の方法論よりも効率的と思われる。少ない工数でより多くの機能を開発でき、品質の高いソフトウェアを開発できる。しかし、ビジネス的観点から見ると、長期的計画を立てるのが困難であるという問題がある。基本的に、必要な機能は開発されるが、それが何時になるのかは不明である。
エクストリーム・プログラミング(XP)は最も有名なアジャイル的手法である。XPでは工程が非常に短いステップに分割される。ウォーターフォール・モデルでは数ヶ月から数年かかる工程を1日から1週間の工程に分割するのである。まず、自動化されたテストを書き、その工程でのゴールを定める。次に（2人のプログラマにより）コーディングを行い、全部のテストをパスした段階でその工程が完了する。設計とアーキテクチャはリファクタリングによって生み出され、コーディングの後に完成する。設計はコーディング担当者が行う。設計とコードの統合を行う段階は他のアジャイルソフトウェア開発と同様である。不完全だが機能するシステムがユーザー（あるいはその一部、開発チームもユーザーの一部である）に配布され、評価される。その後、次に重要と思われる部分に関するテストが書かれ、次のサイクルが開始される。
反復型開発には独自の利点があるが、ソフトウェアアーキテクトはさらに信頼できるソフトウェア開発基盤を生み出そうとしている。そのような開発モデルの基盤には最前線の現場の分析とプロトタイピングが必要である。開発モデルは特定の設計パターンや実体関連図（ERD）に依存していることが多い。反復型開発はコストおよび品質で有利な長期的戦略を採用することにより、事前の基盤を必要としない。
反復型開発への批判は、これらの手法が顧客に対してソフトウェア開発に深く関わること、すなわち開発者的スキルと経験を要求することを問題にする。また、そうでなければこの手法のコストは増大する。それは「どういう家が欲しいか決めかねているなら、試しに私どもに建てさせて気に入るかどうか見てみてください。もし気に入らなかったら、取り壊して立て直します」と言っているようなものである。この批評は、反復型開発の要点を取り違えている。反復型開発では顧客からフィードバックを得るのに家全体を建てる必要はない。従来型の開発手法で実際の開発が始まる前に行っている要求分析と開発完了後に行っている評価を、反復型開発では全工程に分散させていると見ることができる。
実際、アジャイルのコミュニティでは要求仕様を固定せずにソフトウェアを改良していくという点で曲折があった。従来の手法ではこれは許されず、商業的にもナンセンスである。アジャイル的手法ではアーキテクチャの変更を迫るような新たな要求について、顧客が対価を支払わない場合、アジャイル的にプロジェクトは終了させられる。
これらの手法はウェブベースの技術の発展と共に開発されてきた。したがって、アーキテクチャとソリューションの機能のほとんどがアプリケーションのバックボーンに選ばれた技術で実現されていると仮定すると（つまり、ミドルウェアで実現されている）、これらの手法は実際には保守ライフサイクルと同義である。
リファクタリングは、設計を慎重に行って文書化することの代替案としてアジャイル・コミュニティが提案したものである。アーキテクチャ上の問題に対するリエンジニアリングへの代替案は提案されていない。どちらも比較するとコストがかかる。既存のコードへのリファクタリングを1回通して行うと 10% から 15% のコスト増となると言われている。しかし、この値に再評価やリグレッションテストも含んでいるかどうかは不明である。もちろん、既存のアーキテクチャを捨ててしまう方がさらにコストがかかる。実際、アジャイル的手法を利用した開発ではコスト問題に悩んでいるという調査結果がある(Software Development at Microsoft Observed)。ここでは、基本設計の管理よりもプログラミング担当者らによる定常的なリバースエンジニアリングが強調されている点に注意されたい。
テスト駆動開発（TDD）はアジャイル的手法から生まれた便利な手法だが、同時に問題もはらんでいる。TDD ではコードを書く前にそのコードに関する単体テストを書く必要がある。したがって、まずどういうコードを書くかを考え、それを書く前にその単体テストを書けるほど十分に詳細を決定しなければならない。アジャイルソフトウェア開発では簡単な設計からコードを書くのであるから、TDD をアジャイル的でない開発工程モデルに取り入れることはアジャイル的なものとは正反対となる。
形式手法は要求/仕様記述/設計段階でのソフトウェア（およびハードウェア）問題への数学的対処法である。形式手法の例として、B-Method、ペトリネット、RAISE、VDM などがある。形式仕様記述もZ記法など様々な手法がある。より一般化すれば、有限状態機械のシステムを設計することでオートマトン理論を応用してアプリケーションの動作を解明する。
有限状態機械(FSM) に基づいた方法論で実行可能ソフトウェアの仕様記述ができ、従来的なコーディング工程を省くことができる（仮想有限状態機械およびイベント駆動有限状態機械）。
形式手法はアビオニクスソフトウェアなどの安全性が重要とされるソフトウェアでよく採用されている。DO178Bなどのソフトウェアの安全性保証標準規格では、形式手法の採用が義務付けられている（レベルAの場合）。
形式手法は開発工程に様々な形で入り込んできつつある（例えば、OCL、JML、モデル駆動型アーキテクチャなど）。