問題タブ [sdlc]

これは正確な回答を伴う質問ではありません (厳密に言えば、回答は投票で取得するのが最善ですが、その機能は利用できません) が、私はその回答に本当に興味があるので、とにかく質問します.

キャリアの中で、ブラウンフィールド開発と比較してグリーンフィールド開発に費やした時間はどれくらいですか?

過去 10 年間で、グリーンフィールドに 20%、ブラウンフィールドに 80% を費やしたと見積もっています。これは典型的なものですか？

現在のデータベース開発環境では、ビルド プロセスを自動化して、svn create database スクリプトからすべての SQL コードをチェックし、それらをさまざまな開発/qa データベースに適用しています。

これはすべて順調で、以前に比べて大幅に改善されていますが、スクリプトの再実行に問題があります。システムに悪影響を与えることなくスクリプトを何度も実行できるため、手順の変更などの一部のスクリプトでは明らかにこれは問題ではありません。現在、メタデータを追加し、create/alter table ステートメントなどのステートメントを実行するために、オブジェクトが存在するかどうかを確認して確認するコードを追加し、存在する場合は実行しないようにします。

私たちの問題は、スクリプトを実行するのに実際には 1 回しか実行できないことです。スクリプトが実行されると、オブジェクトは環境内にあり、システムはスクリプトを再度実行しません。デプロイ後に何かを変更する必要がある場合、更新スクリプトに対して更新スクリプトを実行し、すべてが正しい順序で行われ、すべての PK が環境間で整列することを期待するという困難なプロセスがあります (データベースは、 "特別な"）。

データベースを削除して最初からプロセスを開始する以外に (最後の最新リリース)、これに対するより洗練された解決策はありますか?

私の質問は、どのタイプのプロジェクトにどのバージョン命名スキームを使用する必要があるかということです。

非常に一般的なのは major.minor.fix ですが、これでも数字が 4 になることがあります (つまり、Firefox 2.0.0.16)。一部のモデルでは、奇数が開発者バージョン、偶数が安定版リリースを示します。また、-dev3、-rc1、SP2 など、あらゆる種類の追加機能が混在する可能性があります。

あるスキームを別のスキームより優先する理由はありますか? また、異なるタイプのプロジェクト (つまり、オープン ソースとクローズド ソース) には異なるバージョン命名スキームを使用する必要がありますか?

ウィキペディアのシステム開発ライフ サイクルのページで言及されています。

これを管理するために、ウォーターフォール、ファウンテン、スパイラル、ビルドと修正、ラピッド プロトタイピング、インクリメンタル、同期と安定化など、多くのシステム開発ライフ サイクル (SDLC) モデルが作成されています。

Google でいくつかのことを見つけましたが、それらは漠然としていて、クリックしてくれなかったように感じました。おそらく、ここの誰かからの説明がより明確になるかもしれません。

開発チームのメンバーに「良い」コードを書いて彼らのコードにコメントを追加するように動機付けるために実施している方法/システムはありますか？「良い」は主観的な用語であり、良いコードの1つの測定値としてのコードの保守性の測定に関する以前の質問に関連していることを認識しています。

また、テスト環境と本番環境の間でそれらをどのように同期させますか？

データベーステーブルのインデックスに関しては、データベースをクエリするコードを作成する上で不可欠な部分であるというのが私の哲学です。インデックスへの影響を分析せずに、新しいクエリを導入したり、クエリを変更したりすることはできません。

そのため、すべての環境間でインデックスの同期を維持するために最善を尽くしていますが、正直なところ、これを自動化することはあまりうまくいっていません。これは一種の無計画な手動プロセスです。

定期的にインデックスの統計を確認し、不要なインデックスを削除します。私は通常、削除スクリプトを作成して、それを他の環境にコピーして戻すことでこれを行います。

しかし、あちこちでインデックスが作成され、通常のプロセスの外で削除され、違いがどこにあるかを確認するのは非常に困難です。

私が本当に役立つことの1つは、次のような単純な数値のインデックス名を使用することです。

ここで、tはテーブルの短い省略形です。関係するすべての列を巧みに利用しようとすると、インデックスのメンテナンスが不可能になります。

そのようなインデックスを区別するのは難しすぎます。

インデックス管理をソース管理と開発ライフサイクルに統合するための本当に良い方法を持っている人はいますか？

私は、アジャイルはスパイラル モデルのもう 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. 競合他社を合併/買収/競合他社に買収されたので、競合他社の方が優れています。

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