プログラマのアナリストの比率

"良い​​仕様は、プログラミングツールやテクニックよりもはるかに優れたプログラマの生産性を向上させます。"

- ブライスの法則

はじめに

システム開発の面では、1960年代と1970年代初期の間に次のいずれかのシステムアナリストまたはプログラマーであった。期間。時点では、プログラマが（少なくとも2:1）よりもかなり多くのアナリストがあった。これは、コンピューティングは単に企業の世界で独自に入ってくるし、その全体でシステムを見なかった周りの人が残ったという事実に、部分的には、したことによるものです。しかし、次のような、これはプログラミングのブームの年となり、そこにプログラムがコンピュータへの人々の悲鳴が必要であった。あなたは可能性だけについて右あなた自身のチケットCOBOL、FORTRAN、またはPL / 1を知っている。給与はよかった、あなたは単にあなたが知っていることによってあなたの雇用者を脅すことができる（あなたが解雇されるように殺人事件のようなものをコミットしなければならなかった）。プログラミングに重点を置いては、作者が故に、CASEの動き（コンピュータ支援ソフトウェア工学）はその後まもなく続いた1970年代後半の構造化プログラミングの動き、の誕生を、プログラマの生産性を高めるために膨大な書籍を飛び出したように素晴らしいとなった。

プログラミングは身長で成長している間に、システム分析では、急激な減少であった。そのようなシステム管理（ASM）の協会など業界団体は何に彼らのメンバーシップの先細りになるを見て、彼らのドアを閉じるには、強制された。古いシステムアナリストの最後のいずれか引退か、1980年代に企業が放牧に出しました。新しい役職は、このようなソフトウェアエンジニアとアナリスト/プログラマーとして、浮上した。強調は、プログラミングではなく、システム分析にあったように、この後者のタイトルは誤った名称のビットです。

プログラミングが優れているが、顕著なボイドは、その全体のシステムを見ることができる人々の用語で表示されるようになった。良いプログラムを書くことは一つですが、システム全体を形成するために他のプログラムとのインターフェイスにそれを取得すると、まったく別のものです。世紀の変わり目で、業界が始めた "エンタープライズ·アーキテクチャ"、 "ビジネスプロセス"、 "ビジネス·ルール"、 "ビジネス分析"などさらに、新しい会議、見本市グループ、および役職などの話をし始めた出現します。今日では、プログラマがありふれたものとみなされ、真のアナリストの株式が増加しているされています。

このすべては、システム理論を再発明しようとする業界の指標である。システム分析、システム分析であるとして、現実には何も新しいものはここにはありません。企業が再びこれらの概念と肩書きを実装するとしてではなく、彼らは他の情報技術の機能、およびそれらの関係に収まるところに、ビット不確かである。

特性

システムアナリストは、これらの日多くの名前によって行く;例えば、ビジネスアナリスト、エンタープライズアーキテクト、システムエンジニア（私の個人的な好み）などがそれにもかかわらず、我々は使命ビジネスの情報要件を検討することであると設計者について話しているそれらを満たすためのトータルシステムソリューションを提供します。さらに、アナリストは、ソフトウェア要件を指定するための責任があると、次のような、プログラミングスタッフとの仲介者と見なされます。アナリストの個人的な特性は、プログラマよりもかなり異なっています。プログラマは、より内向的および技術に焦点を当てた傾向にある一方、アナリストは、より多くのビジネス指向の外向的になる傾向があります。アナリストは、効果的にエンドユーザーとプログラミングスタッフの両方で動作するように（口頭および文書による）良いコミュニケーション能力を持っています。彼らは、インタビューを実施し、プレゼンテーション（セールスマン）を作成する方法を知っています。さらに、彼らはそれの一部だけとは対照的に、より大きな画像を見て、起業家精神を持っている傾向にあります。

アナリストは、エンドユーザーのビジネス上の問題を理解し、ユーザーの部門の操作に親密である。言い換えれば、アナリストは、快適にエンドユーザーの立場に歩くことができます。彼らは適切に仕事をしている場合は、アナリストは、優秀な候補者は、管理階層の責任を負うことになります。アナリストは何年もの減少であったので、しかし、これはかなりの時間起きていない。私は主要な管理職を卒業したシステムアナリストのことを聞いた最後の時間は、1970年代後半Armco鋼の社長兼COOを作られたダン·ブーンだった。

システム分析が正しく行われている場合、アナリストは、アプリケーションの割り当てのために良い仕様を提供すべきであるとして、プログラマの生産性が向上します。システムアナリスト、かなりの時間が存在しない場合にエンドユーザーが望んでいる第二推測する必要があり、プログラマが失われます。必然的に、これは何度も何度もソフトウェアを介して書き換えにつながる。などのシステムアナリストによって提供された良好なデータと処理の仕様は、任意のプログラミングツールやテクニックよりもはるかに優れたプログラマの生産性を向上します。これにより、プログラマは良いシステム分析の受益者であることを意味します。

これは、開発組織内のプログラマにシステムアナリストの比率がどうあるべきか、興味深い点をもたらしますか？率直に言って、私は、プログラマの2倍として、多くのアナリストがあるはずと信じています。先行作業に集中することにより、プログラミングが簡素化されています。私はプロジェクトの努力の総量を表す次のような三角形を使用して、ポイントを説明しましょう​​（余談として、私は私の考えを共有し、日本で私の顧客からこれを拾った）、次を参照してください。

http://www.phmainstreet.com/mba/blog/ss060724.jpg~~V

左の三角形は、プログラマの数は、システム·アナリストに2回ありますそれによって伝統的なアプローチを表しています。このアプローチの下では、かなり多くの時間が十分に定義されている要件を満たすためにソフトウェアを生産に費やされます。それは多くの時間は、プロジェクトを完了するために必要な手段として、三角形の底から日本のポイントは、実際には底なしです。プログラマに倍多くのアナリストが存在し、右側の三角形と比較します。このシナリオでは、より多くの時間が、問題を分析するシステムを設計し、より良いプログラミングの仕様を生産に費やされます。したがって、プログラマは実行する必要があるとより生産的仕事に取り掛かることができるもの第二推測する必要はありません。

右図の問題は、しかしシステム分析、経営への漠然とした概念を幾分であると考えられているということです。プログラミングは、他の一方で、より具体的な人々が把握しやすいです。次のいずれかのコードを記述し、プログラムを生成するかはそうではありません。したがって、管理の考え方では、システム分析をショートカットするので、傾斜をコーディングしている限り、あなたが生産されていないことです。これは、システム分析は、1980年代に崩壊した主な理由です。それは経営陣がシステムの分析の必要性を高く評価するように訓練を提供する必要がありますなぜ、これが。率直に言って、私はそれが適切に彼らに提示されている場合は管理が非常に協力することができます発見した。

結論

あなたはそれらのシステムアナリスト、ビジネスアナリスト、システムエンジニア、またはエンタープライズアーキテクトと呼ぶかどうか、それが企業に再導入されているこの重要な機能を表示するには非常に励みになります。私に関する限り、それは避けられなかった。私は、企業が最終的には、単に優れたプログラミングツールやテクニックを使用してシステムの問題を満たすことができません考え出したと思います。

我々はまた、例えば、システム管理（ASM）のための協会のようなグループを置き換えるために関連する業界団体の復活を見て始めている。

ビジネスアナリシスの国際研究所

IIBAは、ASMが認証を含む、中断したところを拾っているように見えます。 ASMが開発し、数年前認定システムプロフェッショナル（CSP）の認証を提供する一方、IIBAは、同様のものを作成しようとしています。

このすべては、業界のシステム理論を改革しようとしているかの指標である。このようなシステムで作業がよく、1980年代まで知られていたのに対し、それはプログラミングに重点が原因で過去20年間忘れられていた。幸いなことに、企業は最終的にシステムの仕事の重要性を実現していて、順番に自分の家を取得しようとしている。私は周りに何が起こって、推測が来る。...