5

この質問には多くの意見が寄せられる可能性がありますが、私が知りたいのは、私と私の会社が販売する製品の寿命を判断するのに役立つ一連の尺度です.

CMS システムを販売しており、このシステムを使用していくつかのサブ製品を作成しています。

  • ウェブサイト
  • 提案作成者
  • マーケティング キャンペーン トラッカー

道路計画 (2010 年と 2011 年) を開始する準備ができており、アプリケーションの寿命がいつ終了するかを把握しようとしています。非常によく設計されたアプリケーション(私たちのアプリケーションが適切に設計されているとは思いません)は寿命を迎える必要はないと考える人もいるかもしれませんが、私たちが使用しているこのアプリは少なくとも 6 ～ 7 年前にさかのぼり、ドキュメントはほとんどありません（実生活）。現時点では、コア機能の変更方法を知っているのは 1 人だけです (恐ろしい)。

ご意見をお聞かせください、

ジオ

ありがとうございます！このトピックに関するご意見、ご感想、ご感想をお待ちしております。

以下のリストで、ポストバックの質問のいくつかに対処します

  • 製品のコア機能を維持できる開発者が 1 人います。(唯一無二)
  • 特定のポイントまで機能を増やすことができる開発者が 2 人います。どちらの開発者も、コア製品の制限によって制約を受けており、両方ともその制限内で作業する必要があります。
  • 非常に重要な注意事項です。当社が廃棄を検討している製品は、大部分が請負業者によって製造されています。請負業者は、コア機能を維持できる唯一の開発者です。請負業者のフレームワークの上でのみ開発します。

すべての回答を読みながら、回答を追加し続けます。

4

8 に答える 8

7

アプリケーションは非常によく設計されているため、アプリケーションを廃止してこれまでに行ったすべての投資を無駄にしたくない場合があります。

ここに私の提案があります：

  • ジュニア開発者をこの現在の開発者に参加させます。
  • ジュニア開発者の将来の更新のほとんどをダンプします (シニア開発者の支援を受けて)
  • 後輩開発者に自分の仕事の文書化を依頼する
  • 上級開発者にドキュメントのレビューを依頼する

しばらくすると、このアプリケーションをサポートできる別の人がいて、それも文書化されます。これで、非常によく設計された独自のアプリケーションを自分の手で強制終了する必要がなくなります。

.

以下のJeffereyの提案でこのソリューションを拡張します（「時々、書き直すことは良い投資です。」）

現在のアプリケーションを削除して書き直したい場合でも、既存のシステムを文書化し、それに基づいて新しいシステムの要件を作成する必要があります。

現在および提案されているシステムのドキュメントを使用して、コンポーネントをモジュールごとに段階的にアップグレード (書き換え) できるかどうかを確認したい場合があります。これは、アプリケーションが非常に適切に設計されている場合に可能です。

あなたの（ジオ）コメントによると

Geo の組織には、以下のビジネス要件を実装し、彼のコードのサポートと使用に対してライセンス料を支払っているカスタム サードパーティ (1 人だけの契約開発者との) CMS アプリケーションがあります。

  • CMS のビジネス要件
  • ウェブサイト
  • 提案作成者
  • マーケティング キャンペーン トラッカー

これが私の提案です

  • このプロジェクトの詳細なユース ケース ドキュメントをモジュールごとに作成します。開発者はこれを行うことができます。または、同じことを別のビジネスアナリストに任せるのが理想的です。
  • 上級開発者を雇って、オープンソース CMS が要件 (Joomla、Drupal など) のすべてまたはほとんどを処理できるかどうかを評価します。
  • ここで最も重要なことは、既存のデータを新しいシステムに移行できることです。これを行うには、既存の契約開発者の助けが必要になる場合があります。
  • 新しいシステムを使用するには、業務プロセスまたはワークフローを更新する必要がある場合があります。
  • オープン ソース CMS を使用して実装できないモジュールは、カスタム Web サイトを使用して実装する必要がある場合があります。

その多くは、既存の契約開発者とのビジネス関係およびライセンス契約にも依存します。あなたが直面しているのは、シナリオのベンダー ロックです。このベンダー ロックインの状況を解消するためのソリューションをさらに調査することをお勧めします。

于 2010-01-20T22:19:09.167 に答える
3

これは私の意見ですが、これがあなたが販売している製品である場合、すべてはビジネスの見通しに帰着します。商品が売れない場合は、ドロップしてください。製品に将来性がある場合は、それに投資し、リファクタリング、書き直し、またはしなければならないことは何でもして、できる限り最高のソフトウェアにします。忠実な顧客や強力なブランドがある場合は、保護する価値があります。

すべてを別のテクノロジーで書き直すことは、現在のソフトウェアがコピー可能な優れた設計を持ち、強力なブランドを持ち、それが正しく実行できる場合に、良い投資になる場合があります。

于 2010-01-20T22:26:06.887 に答える
2

システムの寿命を延ばす唯一の種類のドキュメントは、テストスイート、自己診断ツール、コードコメント、インターフェイスなどの宣言型コントラクト、自動生成されたドキュメントなど、システムの寿命が変化しても一貫性を保つものです。

マニュアル、開発者ガイド、アーキテクチャドキュメント、データ形式など、その他の手動で管理されるドキュメントアーティファクトは、ドキュメントの量に比例して古くなる傾向があります。これらを維持するためのコストをすでに考慮していない限り、これらをアプリケーションの平均寿命を延ばす要因としては数えません。

アプリケーションを確実に維持するために開発者の冗長性を「提供」できない場合、ドキュメントを最新の状態に保つ余裕はありません。ドキュメントの欠如は、実際には、おそらく無意識のうちに引き受けることを決定した技術的負債です。より長いライフサイクルが要件である場合、そのコストはその要件を満たすことを考慮に入れる必要があります。

于 2010-01-20T22:54:09.643 に答える
2

アプリケーションは、何のドキュメントもなしに出荷された瞬間に寿命を迎えました。今すぐ開発を始めて、元のシステムを知っている人を置き換えることを検討したいかもしれません。彼らが何の文書も作成せずに 6 年から 7 年を過ごした場合、彼らはあなたの会社に必要な人物ではありません。

于 2010-01-20T22:03:10.280 に答える
1

簡単に言うと、私は似たような状況にいます。

  • このアプリケーションがキャッシュカウのようなものであるが、会社が新しいアプリケーションを開発する余裕がない (または開発するつもりがない) 限り、顧客がより新しいシステムを購入することを決定する前に、そのアプリケーションが消滅することはありません。

  • (文書化された) 要件なしに書き直すことはほとんど不可能です。

  • 少なくとも専門部門の経験は、今後の開発に役立つ方法で文書化する必要があります。

  • このアプリケーションを維持する必要がある場合は、全体的な複雑さを軽減するために、モジュール間にインターフェイスを導入する必要があります。したがって、古いモジュールがどんなに乱雑であっても、新しい機能をプラグインする必要があるかどうかは気にしません。

于 2010-01-20T22:43:47.327 に答える
0

私は同様のプロセスを経ました。ほぼ8年間実行されていたWebアプリがありました。その時、私たちが想像していなかった方法でそれを拡張して、多くのメンテナンスが行われました。しかし、コアは良好で、それでも伸ばすことができました。

私たちを押しのけたのは、メンテナンスコストでした。適切なスキルセットを持つ人を見つけるのは8年前は簡単でした。今日、誰もそれらの環境で働きたがっていません。私たちでさえありません:)

分析の結果、12か月以内に同じ機能に置き換えることができ、この時間を費やすとすぐに成果が上がることがわかりました。

そのため、機能要件としてスクリーンショットを使用し、ルックアンドフィールを刷新し、さらに機能を向上させることができました。また、使用状況データを見て、ほとんどまたはまったく使用されていない部品を特定し、それらをトリミングし、使用された部品にさらに注意を向けました。

最終的に、私たちは成功しました。チームの全員が新しいテクノロジーに精通していたため、学習する必要がほとんどなかったことが一因です。その他の要因には、よく考えられた設計が含まれます。何かを書く前に、デザインだけで3か月を費やしたと思います。

最後の要因は、アプリがモジュール式であるということでした。そのため、短い納品スケジュールと各成果物間のダウンタイム/分析期間を組み合わせることができるように、十分に小さいサイズに分割することができました。これにより、すべての段階で正しい道を歩むことができました。

于 2010-01-21T00:42:03.317 に答える
0

これらは、システムが「生産終了」になる可能性があるかどうかを判断する際に考慮する可能性のある種類のものです。

このシステムが提供する機能は、安価で信頼性が高く、使いやすい形でエンドユーザーに提供されていますか? 今ではない場合、それはいつですか？したがって、この製品は長期的に実行可能ですか?

これは、製品へのインターフェースが扱いにくい、または「時代遅れの」プラットフォームを実行する必要があるため、顧客が回避するようなテクノロジで書かれていますか? たとえば、2010 年になっても VB6 はおそらく問題ありませんが、Win16 との互換性を要求することはおそらく問題ありません。

基礎となる技術プラットフォームを熟知している優秀な人材を妥当なコストで雇うことができますか? 古い技術では、プラットフォームを知っていても、それを行き止まりと見なし、それに取り組んでいる間にキャリアが停滞する場合は、割増の給料を要求する人がたくさんいるかもしれません.

あなたにとって重要な場合、開発プラットフォームはまだベンダーによってサポートされていますか? ベンダーが更新をやめた場合、実行できるハードウェアまたは OS に制約を受けることになりますか? 同様に、プラットフォームに更新が必要なセキュリティ ホールはありますか? ニッチなオープン ソース製品でさえ、これに悩まされる可能性があります。製品が人気を失い、コア開発者が新しいプロジェクトに移行すると、コミュニティによる修正が困難になる可能性があります。

サポートされている場合、ベンダーは古いプラットフォームをサポートするためにプレミアムを請求していますか? 今ではない場合、それまでにどのくらいかかりますか?

競争力を維持するためにエンドユーザーに豊富な機能を提供する現在のトレンドを利用するために、新しいテクノロジーを統合するのはどれほど難しいですか? あなたはこれを気にしますか？基本的にクローズド システムを実行している場合は問題にならない場合があります。

システム全体に波及する大規模な「ショットガン」の変更なしに、機能的な変更をリリースするのはどれほど難しいでしょうか? これは、そもそもシステムがどのようにモジュール化されるように設計されたかに帰着します。機能を市場に投入する点で競合他社よりも悪くなければ、おそらく問題ありません。

システムを書き直すコストはいくらですか? これは、販売収益を維持または増加させるためにどれだけ安くなるかを比較してどうですか? 全体を書き直すことは、経済的に実現可能ではないかもしれません。開発プラットフォームが健全であれば、リファクタリング アプローチをさらに試すことができます。ここで、優れたテスト スイートとドキュメントが役に立ちます。

于 2010-01-20T23:43:54.493 に答える
0

非常によく設計され、機能していても、ドキュメントがなく、その生涯を 1 人の人間に依存しているという事実は、製品が保守不可能な状態に陥っていることを意味します。これは良い兆候ではありません。製品が「生産終了」をはるかに過ぎていることに同意します

于 2010-01-20T22:10:03.473 に答える