1

少し前に、別の質問が（おそらく都市の物語）統計に言及しました

...ソフトウェアの平均寿命は約3年です

当時、私は次の理由を思いついた（そしておそらくもっと良い理由があると確信している）：

  1. 新しい主要システム（ERP、CRMなど）が実装され、古いアプリを置き換える「統合」モジュールがあります。

  2. 同じですが、統合されたアプリはありませんが、既存のアプリは適応できません（人々が去り、テクノロジーが変更され、現在のITポリシーが変更され、ユーザーは既存のアプリを気に入らない）。

  3. 基本アプリを取得した会社が、ニーズに合わせてカスタマイズするために姿を消しました。

  4. または、あなたはもう彼らとうまくやっていけません。

  5. 既存のアプリのテクノロジーは「時代遅れ」です（フレームワークベンダー/マイクロソフト/コンサルタント/業界の専門家/経営陣の耳を持つ新しいITマネージャーによると）。

  6. 「段階的に廃止されており（Windows 95 / Windows 98 / Windows 2000 / Windows XP / NT）、アプリにマッチングテクノロジーが必要です。」

  7. 「（アプリバージョンn）から多くのことを学び、2回目/3回目/4回目/n+1回目はもっとうまくいくでしょう。」

  8. 開発者/ITマネージャー/部門VP/コンサルティング会社の仕事の正当化。

  9. ユーザーはそれを嫌います。

  10. 競合他社を合併/買収/競合他社に買収されたので、競合他社の方が優れています。

これらのいくつかは避けられないものです（例えば、あなたの会社が買収されるなど）が、全体として、これは確かに避ける必要のあるスメッシングです。あなたの組織は意図的にこの症候群と戦っていますか？どのような効果的な戦略をお勧めしますか？

4

5 に答える 5

3

そのため、アプリケーションは簡単に拡張できる必要があり、すべての流行語を簡単に追加できる必要があります。

しっかりした基本コードがあれば、流行語のほとんどは UI (Vista Controls、Ajax、.net、ASP.net 3.5) に関連しています...

バックエンドでCOBOLを実行している可能性があります（私はしません）。

  1. 新しい主要なシステムが実装されました - あなたにできることは何もありません。
  2. 現在の IT ポリシーが変更されました。 - アプリは適応可能である必要があります。
  3. ユーザーは既存のアプリを好きではない/嫌いです - なぜですか? ほとんどの場合、UI の表面的な変更でこれを修正できます。
  4. ニーズに合わせてカスタマイズするための基本アプリを入手した会社は姿を消しました。-私はそれをしません。自分で書きたいと思います。
  5. 既存のアプリのテクノロジは「時代遅れ」です (フレームワーク ベンダー/マイクロソフト/コンサルタント/業界の専門家/経営陣の耳を持つ新しい IT マネージャーによると) - 上記と同様に、バックエンドがしっかりしている場合は、従う必要があります。これらはフロントエンドにあります。
  6. 「私たちは (Windows 95/Windows 98/Windows 2000/Windows XP/NT) を段階的に廃止しており、アプリに対応するテクノロジが必要です」. - 簡単な互換性テストとマイナーな UI 要素がこれを解決します。

また、インハウス アプリと商用アプリを比較すると、これは異なるとも言えます。インハウス アプリを実行している場合は、変更によって仕事が保証されます (自分が何をしているかを理解している場合)。商用アプリを開発している場合、変化はより多くのお金を稼ぐ機会であり、新機能は既存のクライアントやバズワードを探している新しいクライアントからのアップグレードをもたらします。これらのバズワードは、競合他社と比較して有利になる可能性があります。

于 2009-01-29T22:15:41.087 に答える
1

現在私が書いているソフトウェアの平均寿命はおそらく数日です。(私は多くのスクリプトを書いているので、異常かもしれません。;-) しかし、私が使用しているコア システムは、おそらく 15 ～ 20 年前のものです。基盤となる OS は約 30 年前のものです。古いソフトウェアでも新しいソフトウェアでも、本質的に問題はありません。実際、ソフトウェアは、新しい用途に適応できる場合に最も古くなります。

機能部品間に抽象化のレイヤーがあると、システム内の機能を簡単に置き換えることができます。たとえば、システムでいくつかの異なるテープ ライブラリを使用してきましたが、将来的にはディスク アーカイブを使用することを検討しています。システムの「アーカイブ」部分は抽象化レイヤーの背後にあるため、システムの残りの部分を置き換えることなく、かなり簡単に置き換えることができます。

可能であれば、標準部品を使用することも最善です。そうすれば、何らかの制限に遭遇した場合、他の人が同じ問題を抱えている可能性が高くなり、誰かが修正を思いつく可能性が高くなります.

于 2009-01-29T22:34:00.317 に答える
0

ほとんどの企業は5年間それを達成していません。彼らのソフトウェアの実装は、それほど長く続くとは期待されていません。

于 2009-10-11T01:28:11.650 に答える
0

要件を収集し、誰かが「状況 X は常にケースであり、例外はありません」と言った場合は、それを構成可能にします。例外なく常に変化します。

于 2009-01-30T01:34:12.280 に答える
0
  • 継続的な改善 - 便利な機能を定期的に追加する
  • 新しいバージョンには致命的なバグはありません - テスト、テスト、テスト...
  • クライアントに親切にし、敬意を持って接してください (ほとんどのユーザーは実際に 3 年ごとに ERP を変更することを望んでいないため、クライアントと良好な関係があれば、クライアントはあなたの味方になります)
  • 新しいテクノロジーを最新の状態に保ち、必要に応じてアプリケーションに統合します
于 2009-01-29T22:32:03.583 に答える