消えていく倉庫のことを聞いたことがありますか？ ある日、それは物理的な視点からではなく、よく知られている小売業者の自動化された流通システムの監視の目から消えました。 ソフトウェアの不具合により、倉庫の存在が何らかの形で消去されたため、倉庫に向かう商品は他の場所に再ルーティングされ、倉庫の商品は衰えました。 会社は財政難にあり、お金を節約するために他の倉庫を閉鎖していたので、”行方不明の”倉庫の従業員は静かにしていました。 三年間、何も到着しなかったか、残っていませんでした。 しかし、別のコンピュータシステムが給与を処理したため、従業員はまだ給料を得ていました。 ソフトウェアの不具合が最終的に明るみに出たとき、倉庫内の商品は売却され、上層部は従業員にエピソードについて何も言わないように言いました。
この話は、20年ほど情報技術業界の周りに浮かんでいます。 それはおそらく外典ですが、ビジネスの私たちにとっては、それは完全にもっともらしいです。 どうして？ このようなエピソードはいつも起こるからです。 たとえば、昨年10月、英国の大手食品小売業者J Sainsbury PLCは、自動化されたサプライチェーン管理システムへの5億2600万ドルの投資を償却しなければなりませんでした。 商品は会社のデポや倉庫に詰まっていて、多くの店舗に通じていなかったようです。 セインズベリーは、手動でその棚をストックするために約3000人の追加の事務員を雇うことを余儀なくされました。
これは、ゆがんで行ってITプロジェクトの長い、陰気な歴史の中で最新のものの一つに過ぎません。 ほとんどのIT専門家は、このような障害は、彼らが必要以上にはるかに頻繁に発生することに同意します。 多くはである何、失敗は普遍的に偏見がない:それらはあらゆる国で起こる;大きい会社および小さい;商業、非営利、および政府の組織;そして状態か評判 これらの失敗のビジネスと社会のコスト—無駄な納税者と株主のドルだけでなく、作ることができない投資の面で—今では年間数十億ドルになりまし
問題はユビキタスに成長するにつれて悪化するだけです。 今年、組織や政府は、世界中のITハードウェア、ソフトウェア、およびサービスに推定$1兆を費やすことになります。 開始されたITプロジェクトのうち、5から15パーセントは、絶望的に不十分として配信の前または直後に放棄されます。 他の多くは遅く、予算に到着するか、大規模な再加工が必要になります。 いくつかのITプロジェクトは、他の言葉で、本当に成功します。
最大の悲劇は、ソフトウェアの障害がほとんど予測可能で回避可能であるということです。 残念ながら、ほとんどの組織は、そのビューは、組織に害を与え、多分それを破壊するリスクにもかかわらず、緊急の問題として失敗を防ぐ表示されません。 この態度がなぜ持続するか理解することはちょうど学術の練習ではない;それはビジネスおよび社会のための途方もない含意を有する。
ソフトウェアはどこにでもあります。 それは私達がATMから現金を得、電話をかけ、そして私達の車を運転することを可能にするものがである。 典型的な携帯電話は現在、ソフトウェアコードの2万行が含まれています;2010年までにそれは可能性が高い10倍の数を持っています。 ゼネラルモーターズ(株) それまでにその車にはそれぞれ100万行のコードがあると推定しています。
平均的な企業は収益の約4—5％を情報技術に費やしており、金融—通信会社などIT依存度の高い企業は10％以上をitに費やしています。 言い換えれば、それは今、従業員のコスト以外の最大の企業費用の一つです。 そのお金の多くは、ハードウェアとソフトウェアのアップグレード、ソフトウェアライセンス料などに入りますが、大きな塊は、組織とその顧客のためのよ
政府もソフトウェアの大きな消費者です。 2003年、イギリスは100以上の主要な政府のITプロジェクトを進行中で、合計$20.3億ドルを持っていました。 2004年、米国政府は1200の民間のITプロジェクトをカタログ化し、60億ドル以上の費用がかかり、軍事ソフトウェアのための別の16億ドルを計上しました。
これらのプロジェクトのいずれかが1億ドル以上の費用がかかります。 現在の2つの例を挙げると、米国退役軍人省のコンピュータ近代化努力は35億ドルを実行すると予測されていますが、英国の国民保健サービスの健康記録を自動化すると、開発には143億ドル以上、展開には508億ドル以上の費用がかかる可能性があります。
このようなメガソフトウェアプロジェクトは、かつてはまれであったが、現在ではより小さなIT操作が”システムのシステム”に参加しているため、はるかに一般的である。「航空交通管制は、通信、気象、航法、およびその他のデータを提供する数十のネットワーク間の接続に依存しているため、その代表的な例です。 しかし、統合のトリックは、学術研究者がますますコンピュータサイエンス自体は、これらの大規模な複雑なシステムに照らして再考する必要があるかもしれないと信じている点に、多くのIT開発者を悩ませてきました。
プロジェクトが失敗すると、組織の見通しが危険にさらされます。 失敗が十分に大きければ、会社の全体の未来を盗むことができる。 ある恒星のメルトダウンでは、不十分な実装されたリソース計画システムは、FoxMeyer Drug Coを導いた。 テキサス州キャロルトンにある5億ドルの卸売医薬品流通会社は、1996年に破産に急落した。
FBIの仮想事件ファイルの大失敗が示しているように、政府におけるITの失敗は国家安全保障を損なう可能性があります。 エージェントが”ドットを接続”し、異種の知性をフォローアップできるようにすることを目的とした検索可能なデータベースである170万ドルのVCFシステムは、
失敗は経済成長と生活の質を妨げる可能性もあります。 戻る1981年に、米国連邦航空局は、その時代遅れの航空交通制御システムのアップグレードに検討し始めたが、交換を構築するための努力はすぐに問題だらけになりました。 機関が最終的にプロジェクトをあきらめた1994年までに、予測された費用は3倍になり、26億ドル以上が費やされ、予想された納期は数年遅れていた。 グリッドロックされたスカイウェイのために遅れているすべての飛行機の乗客はまだこのキャン; ちょうど米国の航空会社（乗客を気にしない）上のすべてのこれらの遅延の累積的な経済的影響はapproaches50億に近づきます。
世界的には、どれだけのソフトウェアプロジェクトが失敗したか、その結果としてどれだけのお金が無駄になったかを言うのは難しいです。 失敗をプロジェクトが配信される前または直後のプロジェクトの完全な放棄として定義し、保守的な失敗率5％を受け入れると、毎年数十億ドルが悪
例えば、2004年には、米国 政府はソフトウェアに60億ドルを費やしました（武器システムの組み込みソフトウェアを数えません）。5パーセントの故障率は、おそらく3億ドルが無駄になったことを意味します。 しかし、ITコンサルタントとして数十年後、予算が1,000万ドル以上のプロジェクトでは、失敗率は15〜20％であると確信しています。 政府と企業の両方の新しいソフトウェアプロジェクトへの総投資額を見ると、プロジェクトの失敗は少なくともU25億、おそらく7 75億ドルの費用がか
もちろん、その750億ドルは予算を超えたプロジェクトを反映していません—ほとんどのプロジェクトがそうしています。 また、それは遅れて配信されたプロジェクトを反映していません—大部分はそれです。 また、プロジェクトが放棄された後にやり直す必要がある機会コストや、繰り返し再加工する必要があるバグだらけのシステムのコストも考慮に
そして、あまりにも、不十分な実装されたシステムのためにサプライヤーを訴える怒りの顧客からの訴訟のコストがあります。 これらの追加費用をすべて加算すると、失敗し問題を抱えたソフトウェアの年間タブは、米国だけで600億ドルから700億ドルのどこかで保守的に実行 そのお金のために、スペースシャトルを100回打ち上げ、24衛星全地球測位システム全体を構築して展開し、ボーイング777をゼロから開発することができます。
なぜプロジェクトが頻繁に失敗するのですか？
:
- 非現実的または非現実的なプロジェクト目標
- 必要なリソースの不正確な見積もり
- システム要件が不適切に定義されている
- プロジェクトのステー>未熟な技術の使用
- プロジェクトの複雑さを処理できない
- ずさんな開発慣行
- 貧しいプロジェクト管理
- 利害関係者の政治
- 商業的圧力
ただ一つまたは二つの理由のために失敗します。 FBIのVCFプロジェクトは、上記の多くの問題に苦しんでいました。 ほとんどの失敗は、実際には、技術的、プロジェクト管理、およびビジネス上の意思決定の組み合わせにトレースすることができます。 各次元はプロジェクトの危険および問題を悪化させ、失敗の可能性を高める複雑な方法で他と相互に作用している。
シンプルなソフトウェア雑用を考える: 部品の発注、請求、出荷を自動化し、販売員が顧客の注文を入力し、価格と契約要件に対して自動的にチェックし、部品と請求書を倉庫から顧客に送
システムの要件には、四つの基本的なステップが指定されています。 まず、販売請求書を作成する販売プロセスがあります。 その請求書は、潜在的な販売の契約条件をレビューし、それらを承認する法的プロセスを通じて送信されます。 ラインの第三は、請求書を送信する財務プロセスに続いて、契約部品を送信する引当プロセスです。
販売のための最初のプロセスが書かれているように、プログラマは、会社がいくつかの州や国に支店を持っていても、すべての注文を会社の主な場所に置かれたかのように扱うとしましょう。 その間違いは、税金の計算方法、どのような契約が発行されるかなどに影響します。
省略が早く検出され、修正されるほど、より良い。 それは一種のセーターを編むようなものです。 あなたはそれを作った直後に逃したステッチを発見した場合は、単に糸のビットを解明し、上に移動することができます。 しかし、あなたが最後まで間違いをキャッチしない場合は、その1つのステッチをやり直すためにセーター全体を解明する必要があるかもしれません。
ソフトウェアコーダーが最終的なシステムテストまで、またはシステムがロールアウトされた後まで、エラーを修正するために発生したコストは、最初の販売プロセスに取り組んでいる間に間違いを発見した場合よりも何倍も大きくなる可能性があります。
そして、セーターの縫い目を逃したのとは異なり、この問題は正確に特定するのがはるかに困難です。 元のエラーが修正された後でも、他の計算やドキュメントを変更してから、すべてのステップを再テストする必要があります。
実際、研究によると、ソフトウェアの専門家は、基本的には初めて正しく行われる作業である付加価値作業と呼ぶものではなく、回避可能な手直しに約40-50%の時間を費やしていることが示されている。 ソフトウェアの一部がフィールドにそれを作ると、エラーを修正するコストは、それが開発段階であっただろうと同じくらい100倍になることができます。
エラーがたくさんある場合、リワークは嵐の中のディンギーのように、プロジェクトを沼に始めることができます。 さらに悪いことに、エラーを修正しようとすると、新しいエラーが発生することがよくあります。 それはあなたがそのディンギーを救済しているようなものですが、あなたはまた、漏れを作成しています。 あまりにも多くのエラーが生成された場合、システムを完了するために必要なコストと時間が非常に大きくなり、意味がありません。
簡単に言えば、ITプロジェクトは通常、リワークが予算化された付加価値のある作業を超えた場合に失敗します。 これは、2002年に自動化された顧客情報と請求システムを導入しようとしたときに、オーストラリア最大の水プロバイダーであるSydney Water Corp.に起こったことです。 オーストラリアの監査官の調査によると、プロジェクトを運命づけた要因の中には、計画と仕様が不十分であり、多数の変更要求と大幅な追加コストと遅延が発生した。 シドニー-ウォーターは61万ドル（33.2万ドル）を費やした後、プロジェクトを途中で中止した。
そのすべてが明白な質問につながります。
ソフトウェアプロジェクトの失敗は、飛行機の墜落事故と多くの共通点があります。 パイロットがクラッシュするつもりはないのと同じように、ソフトウェア開発者は失敗を目指していません。 商業飛行機が墜落する時に、調査官達は、天候、整備記録、パイロットの処分と訓練、および航空会社内の文化的要因のような、多くの要因を見ます。 同様に、ソフトウェア障害のルーツに到達するためには、ビジネス環境、技術管理、プロジェクト管理、および組織文化を調べる必要があります。
ビジネス要因の中でチーフは、競争とコストを削減する必要があります。 ますます、上級管理職は、IT部門が以前よりも少ないコストでより多くのことを行い、より速く行うことを期待しています。
政治的緊急事態はまた、ITプロジェクトのスケジュール、コスト、品質に大混乱をもたらす可能性があります。 デンバー国際空港が自動手荷物処理システムを展開しようとしたとき、州と地方の政治指導者は、プロジェクトを非現実的なスケジュールに次々と開催しました。 システムを時間通りに提供できなかったことは、1995年の空港の開港（当時は米国で最大）を遅らせ、財政的影響を何倍も悪化させた。
システムが完成した後も、確実に機能することはなく、荷物を噛んだり、荷物をシャトルするために使用されたカートが頻繁に脱線したりしました。 最終的には、空港のメインテナントであるユナイテッド航空がシステム請負業者を訴え、このエピソードは政治的便宜の危険性の証となった。
上層部のサポートの欠如は、IT事業を気にすることもできます。 これは、十分なお金と人材を割り当てることができないことから、ITプロジェクトと組織のビジネスとの関係を明確に確立しないことまで、色域を 2000年、ミシガン州トロイにある小売業者Kmart Corp.が設立された。、1ドルを発表した。販売、マーケティング、供給、物流システムをリンクすることを目的とした4億のIT近代化の努力は、ArkのベントンビルにあるライバルのWal-Mart Corp.との競争を向上させることを目的としていた。 しかし、ウォルマートはあまりにも手ごわいことを証明し、18ヶ月後、現金で縛られたKmartは近代化を削減し、すでに投資していた$130百万を償却しました。 4ヶ月後、それは破産を宣言しました;会社は今日も奮闘し続けています。
多くの場合、資金を得ることを熱望しているITプロジェクトマネージャーは、彼らのプロジェクトが何をするか、どのくらいの費用がかかり、いつ完了す ほとんどではないにしても、多くのソフトウェアプロジェクトは小さすぎる予算から始まります。 それが起こるとき、開発者は、通常、生産性を向上させようとする努力の範囲を減らすか、レビューとテストの段階で危険なショートカットを取ることによ これらはすべて、エラーと、最終的には失敗の可能性を高めます。
バジェットレンタカー、ヒルトン-ホテルズ、マリオット、アメリカン航空の親会社であるAMRのコンソーシアムが主導する最先端の旅行予約システムが 1992年、プロジェクトに三年半と$165百万、グループは二つの主な理由を挙げて、それを放棄しました：過度に楽観的な開発スケジュールと関連する技術的な難しさの過小評価。 これは、以前に非常に成功したSabre予約システムを構築したのと同じグループであり、過去のパフォーマンスが将来の結果を保証するものではないことを
墜落後、捜査員は天候を飛行機事故の要因とみなし、飛行機自体を見ている。 墜落の原因となった飛行機の設計に何かがありましたか？ それはあまりにも多くの重量を運んでいましたか？
ITプロジェクトの失敗では、システムの開発に使用されるハードウェアとソフトウェア、および開発慣行自体について、プロジェクトの技術コンポーネ 組織は、多くの場合、技術的な命令—競争力を得ることを期待して最新の技術を使用する制御不能な衝動のサイレンの歌に誘惑されています。 技術が速く、有望で素晴らしい新しい機能を変えて、屈することは容易である。 しかし、未熟な技術や未テストの技術を使用することは、失敗への確実なルートです。
1997年、4,000万ドルを費やした後、ワシントン州は運転免許証と車両登録を処理するITプロジェクトを停止した。 自動車関係者は、彼らが彼らの要件を満たしたシステムの実装に集中するのではなく、技術を追いかけることに巻き込まれたことを認めた。 1年前にFoxMeyer DrugをダウンさせたITの大失敗は、最先端のリソース計画システムを採用し、それを実現可能なことを超えて推進したことにも起因しています。
プロジェクトの規模は失敗の源泉です。 研究によると、大規模なプロジェクトは小規模なプロジェクトよりも3〜5倍頻繁に失敗することが示されています。 プロジェクトが大きくなればなるほど、静的要素(ソフトウェア、ハードウェアなどの個別の部分)と動的要素(ハードウェア、ソフトウェア、およびユーザー間の結合と相互作用、他のシステムへの接続など)の両方に複雑さが増します。 誰もが実際に全体のすべての相互作用部分を理解していないか、それらをテストする能力を持っていないので、複雑さが増すとエラーの可能性が高
ありのままだが真実：実際のサイズのITシステムを徹底的にテストすることは不可能です。 ロジャー-S. プレスマンは、この分野の古典的なテキストの一つであるソフトウェア工学の著書で、”徹底的なテストは特定の物流上の問題を提示する。…いくつかのネストされたパスと1つのループが20回未満で実行される小さな100行のプログラムでさえ、実行される可能性のあるパスの10から14のべき乗を必要とする場合があります。”これらの100兆パスのすべてをテストするために、彼は、それぞれがミリ秒で評価できると仮定すると、3170年かかるだろうと指摘しました。
すべてのITシステムは本質的に脆弱です。 大規模なレンガ造りの建物では、壁を崩壊させるために戦略的に配置されたレンガの数百を削除する必要があります。 しかし、100 000ラインのソフトウェアプログラムでは、大きな問題を引き起こすのに1つまたは2つの不良ラインしかかかりません。 1991年、ATandamp;Tの電話網の一部が廃止され、12万人の加入者がサービスを受けなくなり、すべてのコード行に誤った文字が1つあったためであった。
ずさんな開発プラクティスは、失敗の豊富な原因であり、ITプロジェクトのどの段階でもエラーを引き起こす可能性があります。 組織がソフトウェア開発の実践を評価するのを助けるために、米国 ピッツバーグにあるソフトウェア工学研究所は、能力成熟度モデル、またはCMMを作成しました。 これは、成熟度の増加の五つのレベルに対して、会社の慣行を評価します。 レベル1は、組織がアドホックで混沌とした開発慣行を使用していることを意味します。 レベル3は、会社がその慣行を特徴づけ、今それらを理解していることを意味します。 レベル5は、組織が適用されるプロセスと慣行の変化を定量的に理解することを意味します。
1月の時点で、2000近くの政府および商業団体がCMMレベルを自主的に報告していた。 半分以上がレベル1または2のいずれかであることを認識し、30％がレベル3であり、17％だけがレベル4または5に達していました。 あなたはこれが自己選択されたグループであることを認識したときの割合はさらに陰気です;明らかに,最悪のIT慣行を持つ企業は、CMMの評価に自分自身 （CMMは、ソフトウェア集約型システムを作成する組織の能力をより広範に評価することを目的としたCMM-Integrationに取って代わられています。）
未成熟なITプラクティスは、米国を運命づけました 内国歳入庁のmodernization4億の近代化の努力1997年、彼らはIRSの現在のplague8億の近代化を悩ませ続けています。 税法は複雑で、しばしば曖昧な法律に基づいており、常に変化しています。 IT開発者の観点から見ると、それは要件の悪夢です。 しかし、IRSは、社内と外部のプログラマの間のオープンな敵意、関与する仕事の笑える過小評価、および他の多くの悪い慣行によって助けられていません。
飛行機が墜落する直前のパイロットの行動は、常に研究者にとって大きな関心事である。 それは操縦者が技術の安全な操作に責任がある最終的な意思決定者であるのである。 同様に、プロジェクトマネージャーは、ソフトウェアプロジェクトで重要な役割を果たし、失敗につながるエラーの主要な原因となる可能性があります。
1986年、ロンドン証券取引所は株式取引を決済するためのシステムを自動化することを決定しました。 7年後、$600百万を費やした後、それは設計が過度に複雑で面倒だっただけでなく、プロジェクトの管理が、独自の上級管理者の一人の言葉を使用するために、”妄想”であったため、トーラスのシステムの開発を廃止しました。”調査が明らかにしたように、誰もがより多くの問題が現れたとしても、プロジェクトの真の状態を知りたいと思っていないように見えました,期限
ITプロジェクトマネージャーの最も重要な機能は、さまざまな活動にリソースを割り当てることです。 それを超えて、プロジェクトマネージャーは、プロジェクトの計画と推定、制御、組織、契約管理、品質管理、リスク管理、コミュニケーション、人事管理を担当してい
プロジェクトマネージャーによる悪い決定は、おそらく今日のソフトウェア障害の最大の原因です。 対照的に、技術的な管理が不十分であると、技術的なエラーが発生する可能性がありますが、それらは一般的に孤立して修正することができます。 しかし、プログラマーの雇用が少なすぎたり、間違ったタイプの契約を選んだりするなど、プロジェクト管理の決定が悪いと、大混乱を招く可能性があ 例えば、運命の旅行予約システムの開発者は、固定価格契約の使用によって部分的に妨げられたと主張している。 このような契約は、作業が日常的であることを前提としています。
プロジェクト管理の決定は、あいまいな知識や不完全な知識に基づくトレードオフを伴うため、しばしばトリッキーです。 ITプロジェクトの費用と時間を見積もることは、科学と同じくらいの芸術です。 プロジェクトが大きくなるか、より新しいほど、見積もりの正確さは低くなります。 それは、ITプロジェクトの推定値は、時間の25パーセントの真の価値の75パーセント以内で最高の状態であることを業界で実行中の冗談です。
貧しいプロジェクト管理は、ソフトウェアプロジェクトの終焉を早めることができる他の方法があります。 ニュートンスクエア、ペンシルベニア州のプロジェクト管理研究所による研究。、リスク管理は、すべての業界セクター全体のすべてのプロジェクト管理分野の中で最も実践されていないことを示し、IT業界よりも頻繁に適用される 効果的なリスク管理がなければ、ソフトウェア開発者は、何がうまくいかないのか、なぜうまくいかないのか、リスクを排除または軽減するために何 また、どのようなリスクが許容されるかを判断する方法もなく、トレードオフに関するプロジェクトの決定はほとんど不可能です。
悪いプロジェクト管理は、売上高を増加させる無愛想な雰囲気を作成する悪いコミュニケーションを含む他の多くの形態を取る;スタッフの訓練に投資していない;と定期的にプロジェクトの進捗状況を確認していません。 これらのいずれかが、ソフトウェアプロジェクトを脱線させるのに役立ちます。
飛行機事故後に捜査官が調べる最後の領域は組織環境である。 航空会社は強い安全文化を持っていますか、それとも何よりもフライトスケジュールを満たすことを強調していますか？ ITプロジェクトでは、オープン性、誠実さ、コミュニケーション、コラボレーションを大切にする組織は、リワークが圧倒的にならないように、間違いを早期に見つけて解決する傾向があります。
悪いソフトウェアの拷問された歴史を通して実行されるテーマがある場合、それは現実に直面する失敗です。 何度も、米国司法省の監察官、外部の専門家のパネル、および他の人たちは、定義されているようにVCFシステムは不可能であるとFBIの頭に語ったが、プロジ 同じ態度は、旅行予約システム、ロンドン証券取引所のトーラスシステム、およびFAAの航空交通管制プロジェクトの責任者の間に存在していました。
英国の国家監査局による最近の報告書では、政府のITプロジェクトの多くのケースが、とにかくまだ継続しないことが推奨されていることが判明した。 英国には、ITの失敗を防止することで起訴された政府部門さえありますが、報告書が指摘したように、部門が日常的に監督する機関の半分以上がその助言を無視しています。 私はこのタイプの行動を不合理なプロジェクトのエスカレーションと呼びます—成功の可能性が急速にゼロに近づいていることが明らかになった後 悲しいことに、そのような行動は決してユニークではありません。
最終的な分析では、大きなソフトウェア障害は、パイロットが経験の浅いが非常に発疹、テストされていない航空機で氷の嵐に飛んで、訓練とメンテ その後、捜査官の報告書を読むと、あなたは頭を振って、”そのような墜落は避けられなかったのではないでしょうか？”
だから、ソフトウェアプロジェクトが失敗する理由もよく知られており、無数の記事、レポート、書籍に十分に文書化されています。 しかし、失敗、ほぼ失敗、そして普通の古い悪いソフトウェアは私たちを悩ませ続けていますが、間違いを避けるために知られている慣行は敬遠され 品質の高いソフトウェアを時間通りに予算内で入手することは、ほとんどの組織では緊急の優先事項ではないようです。
それはOxford Health Plans Inc.にはないようでした。、Trumbull、Connで。、1997年。 同社の自動課金システムは、その一番下の行に不可欠であった、とまだそこの上級管理職は、その課金システムが現在のニーズを満たすことができるこ 請求書が数ヶ月遅れて送信されるなどの問題が発生したとしても、管理者はほとんど注意を払っていませんでした。 請求システムが効果的に崩壊したとき、同社は数千万ドルを失い、その株式は一日で68ドルから26ドルに低下し、企業価値は34億ドルを一掃しました。 株主は訴訟を起こし、いくつかの政府機関が会社を調査し、最終的に規制違反で$3百万の罰金を科されました。
悪いソフトウェアの経験によって焼かれる組織でさえ、彼らの過ちから学ぶことができないか、または不本意なようです。 2000年の報告書では、国防総省の諮問機関である米国防衛科学委員会は、国防総省から委託された様々な研究がソフトウェア開発を改善するための134の勧告を行っていたが、それらの勧告のうち21のみが行動していたと指摘した。 他の113はまだ有効であった、理事会は指摘したが、国防総省が防衛ソフトウェア開発の貧弱な状態について不平を言ったとしても、無視されていた！
イングランドのバースにあるソフトウェア開発会社Praxis High Integrity Systemsの経験が証明しているように、いくつかの組織はソフトウェアの品質を気にしています。 Praxisは、顧客が財政的にだけでなく、ITシステムの作成に積極的に参加するようにプロジェクトにコミットすることを要求しています。 同社はまた、顧客の要件を理解し、定義するために膨大な時間を費やしており、顧客が望むものとその理由を説明することに挑戦しています。 1行のコードを記述する前に、顧客とプラクシスの両方が、利用可能なリソースを考慮して、何が望まれ、何が実行可能であり、どのようなリスクが関与しているかについて合意します。
その後、Praxisはエラーの数を制限する厳密な開発アプローチを適用します。 このモデルの大きな利点の一つは、それが彼らのIT要件を明確にし、それらを適切に実装するために時間とお金を費やすの責任を受け入れることを不本意な多くの自称クライアントを除外することです。
あるレベルのソフトウェア障害は常に私たちと一緒になります。 確かに、技術的および経済的進歩を続けるためには、回避可能な失策とは対照的に、真の失敗が必要です。 しかし、今日発生する障害の多くは回避可能です。 そして、私たちの社会は、これまで以上に大きく、より統合され、より高価なITシステムに依存するようになると、失敗のコストは悲惨に高くなる可能性
今でも、次の偉大なソフトウェア大失敗がどこで起こるかに賭けをすることは可能です。 私の主要な候補者の一つは、米国政府のアメリカの健康情報コミュニティ、電子医療記録のためのデータ基準を定義しようとする官民のコラボレーション 基準が定義されると、ITシステムが構築され、全国の医療専門家が患者の記録をデジタルで入力できるようになり、医師、病院、保険会社、および他の医療専門家が患者の完全な病歴に瞬時にアクセスできるようになります。 医療専門家は、このようなシステムが患者ケアを改善し、年間推定$78億のコストを削減し、医療ミスを減らし、数万人の命を救うと信じています。
しかし、このアプローチは、ソフトウェアの実践と故障率が今日のように残っているならば、単なるパイプの夢です。 最も楽観的な見積もりでさえ、電子医療記録システムを作成するには、10年の努力、開発コストの320億ドル、営業費用の年間20億ドルが必要になります。 特に、ほとんどのIT専門家は、医療界がすべての専門企業の中で最もコンピュータに精通していないと考えているため、これは現実的なシナリオでは
患者と納税者は、最終的にこのようなboondogglesの開発、または失敗のための価格を支払うことになります。 今日のIT慣行を考えると、失敗は明確な可能性であり、それは前例のない大きさの損失になります。 しかし、その後、世界中の国々は、航空、国家安全保障、軍事など、同様の規模と影響力の多くのイニシアチブを検討しているか、すでに取り組んでいます。
電気、水道、交通、その他のインフラの重要な部分と同様に、それは急速に私たちの日常の存在に本質的になってきています。 数十年後には、大規模なIT障害は単なる高価な不便以上のものになります: それは私たちの生き方を危険にさらすでしょう。 ソフトウェアの障害を軽減する業界全体の変化がない場合、これらの非常に高価で複雑なシステムに賭けることを喜んでいるのはどれだけですか？
私たちはすでにソフトウェアをうまく行う方法を知っています。 それは最終的に私達が知っているものをに行動する時間であるかもしれない。