問題タブ [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. 競合他社を合併/買収/競合他社に買収されたので、競合他社の方が優れています。

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

リソースが限られているプロジェクトを示すいくつかのマーカーを特定しようとしています。

私の経験では、誰かがクライアントにソリューションを売りたがっていたため、プロジェクトは「限られたリソース」のプロジェクトになります。その結果、予算は厳しくなり、機能は選別され、SDLC プロセスは最小限に抑えられます。これらの近道は、会社が利益を上げたり、損益分岐点に達したりする可能性があるように行われます。

これは、限られたリソースのプロジェクトと密接に関連しているのを私が見たもののリストです。

• QAに割り当てられる最小限の時間
• 仕様外の作業に対する厳格な官僚的プロセス
• 変更リクエストの予算が少ないか、存在しない可能性があります
• 開発に時間を費やすことを支持して、形式化されたプロセスは廃止されます
• コンテンツ チェックのような付加価値 QA に費やす時間はありません (たとえば、テキストの文法やスペルの誤り)。
• クライアントのコンテンツ管理またはデータ入力を行うことはできません
• 「十分な」コーディング ソリューションを使用する必要がある
• 廊下でのユーザビリティ テストのための時間の余裕はありません。
• ユーザー ドキュメントやマニュアルを作成するための予算がありません。
• 通常、コーディング前に技術研究を行う時間はありません
• リスク分析文書を作成する時間がない
• プロジェクト スケジュールの代わりに、生産チェックリストを使用することもできます。
• プログラマーがプロジェクト スケジュールの「実際の」時間と推定時間を埋める時間ではありません。
• クライアントに提供される進捗状況の更新は、あまり頻繁ではないか、非常に基本的なものである可能性があります
• クライアントのビジネス ドメインの理解に費やす時間が減る
• プログラマーは、無給の残業をしなければならない場合があります。
• プロジェクトの事後分析に割り当てられた時間はありません

リソースが限られているプロジェクトには、他にどのような確かな兆候がありますか?

===

編集

私は例でいくつかの混乱を解消しようとします. つまり、クライアントには、プロジェクトの費用が 20,000 ドルになるという提案/見積もりが渡されます。その後、クライアントが戻ってきて、「申し訳ありませんが、私の予算は最大 16,000 ドルです」と言います。上司は「提案を16,000ドルにしてください。この仕事が欲しい」と言います。

したがって、実際には、本来あるべき予算よりも少ない予算でプロジェクトを実行する必要があります。ばかげている境界があります。クライアントが「私の予算は 4,000 ドルです」と言った場合、それを実行することはできません。

はい、予算が限られていると、最初からプロジェクトを受け入れるのが悪いビジネス上の決定 (つまり、運命のプロジェクト) であるほどばかげたものになることがあります。

予算が無制限のプロジェクトなどないことは理解しています。多くの場合、ビジネスパーソンは、プロジェクトを実施するかどうかを決定します (ビジネスパーソンは、多くの場合、プロジェクトマネージャーではありません)。