問題タブ [change-management]

私は現在、小さな CRUD アプリケーションを設計しています。彼らのデータベースは非常に混乱しており、今後 6 か月から 1 年の間に頻繁に変更されます。私のデータレイヤーに何をお勧めしますか:

1) ORM (もしそうなら、どれ?)

2) Linq2Sql

3) ストアド プロシージャ

4) パラメータ化されたクエリ

テーブルを置き換えたり、列を頻繁に追加/削除したりできる、十分に動的な（高速かつ簡単な）ソリューションが本当に必要です。

注: 私は ORM の経験があまりなく (SubSonic は少しだけ)、一般的にストアド プロシージャを使用する傾向があるため、おそらくそれが適しているでしょう。上記の状況が許されるのであれば、Ling2Sql または NHibernate を学びたいと思っています。

最近、「プロジェクトの失敗」について上司とちょっとした議論をしました。3年後、コードベースを新しいプラットフォームに移行するプロジェクト（1.5年間行っていたプロジェクトですが、チームリーダーは数か月しかいませんでした）が稼働しました。彼は、私の会社とクライアントの両方の上級管理職（私はあなたがよく耳にする神々しいコンサルタントの一人です。私の関与は「アプリケーションアウトソーシング」です）とともに、プロジェクトが成功したと宣言しました。私が見つけた古いプレゼンテーションでは、元のスケジュールと比較して、展開の遅延は数か月で測定するのが最適であり、数年で測定できる可能性があることを示していることに同意しませんでした。プロジェクトの失敗について私が知っていることと、失敗率の背後にある研究と統計について説明しました。彼は、それはすべて学界であり、彼が主導したプロジェクトは失敗しなかったと答えました。

このようなコンサルティングは他のプロジェクトとは異なるかもしれませんが、時間通り、予算内、または完全な機能で提供できなかったという汚名を避けるために、これはより美しい名前に包まれた失敗のようです。私の会社が最大の予算内でプロジェクトを完了するために無料で何時間もの仕事を与えたと彼が説明したという事実は多くを語っています。

だから私はあなたにこれを尋ねます：

• 変更管理とは何ですか？それはプロジェクトにどのように適用されますか？
• 「変更管理」はどこで終わり、「プロジェクトの失敗」はどこから始まりますか？

---

@ shog9：
特にこの場合、私はコンサルタントを代表しているので、私はコンサルタントとの非難ゲームについて質問していませんでした。必要な機能が最終的に実装されたかどうかに関係なく、プロジェクトが「失敗」したと見なされる時期についての見解を探していました。
「これは実際には私たちが思っていたよりも少し複雑で、もう1週間になるでしょう」と、「プロジェクトの失敗」との違いを探しています。ただし、失敗を定義したいと思います。違いもありますか？このマイナーレベルのスケジュールのずれは、統計的な「プロジェクトの失敗」を構成しますか？

私の組織の主なプロジェクトは月曜日に開始されました。それがここに来て 3 日目でした。ここに来てほぼ 1 週間経ちましたが、アプリケーションのメンテナンスと「いつか」開始されるフェーズ 2 の準備のための変更管理計画を作成する任務を負っています。私たちは Microsoft ショップですが、オープンマインドです。

CM テクニック、特にこれに役立つツールに関する提案を探しています。私は ITIL に精通しており、その CM の概念をこのプロジェクトにどのように適用できるかを検討してきましたが、確かに、これは私が慣れ親しんでいるよりもはるかに小さいものです (< 100 ユーザー対数千ユーザー)。ITIL をこのような小さなプロジェクトに切り詰めることができるかどうか、またはどのようにすればよいか、正確にはわかりません。あるいは、私の考えが小さすぎるのかもしれません。

あなたの組織は、システム レベルでの変更をどのように管理していますか? それはあなたのために働きますか？どうすれば改善できますか？

さらに明確にするために、おそらくオープンソースまたはアジャイルの世界から、CM プロセスとツールを推奨できる人はいますか?

私のプロジェクトの1つはMySQLのMyISAMエンジンを使用していますが、あちこちでトランザクションサポートが必要なため、InnoDBに変更することを検討しています。

• これを行う前に、何を確認または検討する必要がありますか？
• エンジンを変更するだけでいいですか、それともデータを準備する必要がありますか？

私は、データベースへの変更を追跡するソリューションの開発を任されています。

キャプチャする必要がある更新の場合:

• 更新日
• 古い値
• 新しい価値
• 影響を受ける分野
• 変化をしている人
• レコードID
• テーブルレコードは

削除の場合:

• 削除日
• 削除している人
• レコードのタイトル/説明/ID が削除されました。すべての変更を追跡しているテーブルには、タイトルまたは説明フィールドがあります。レコードが削除される前にこれをキャプチャしたいと思います。
• テーブルレコードがありました

インサートの場合:

• 挿入日
• 変化をしている人
• レコードID
• テーブルレコードは

私はこれを行うためのいくつかの方法を考えました：

• 更新/削除/挿入にストアド プロシージャを使用しています。一般的な「追跡」テーブルを作成します。すべてのデータをキャプチャするのに十分なフィールドがあります。次に、ストアド プロシージャごとに別の行を追加して、「レコードを追跡テーブルに挿入する」という効果を出します。
  • 欠点：すべての更新/削除/挿入がすべて同じテーブルでごちゃまぜになっている
  • 多くの NULL フィールド
  • バッチ更新/削除/挿入を追跡するにはどうすればよいですか? <----これは問題ではないかもしれません。私は実際にアプリケーションでこのようなことをしません。
  • 更新を行っているユーザーをキャプチャするにはどうすればよいですか。データベースは 1 つのアカウントしか認識しません。
  • 編集する既存のコードの多くを編集します。
• 最後に、更新/削除/挿入後に呼び出されるトリガーを作成できます。最初の解決策と同じ欠点の多くは次のとおりです。多くのコードを編集する必要があります。更新を追跡する方法がわかりません。トリガーを使用して最近更新されたレコードを表示する方法はないようです。

私は asp.net、C#、SQL Server 2005、iis6、windows 2003 を使用しています。予算がないので、悲しいことに、これを支援するものを購入できません。

回答ありがとうございます。

Clearcaseでは、特定のファイルセットの「ラベル」を生成し、常にそのラベルに戻って、ラベルを生成したときと同じようにすべてのファイルを再生成できます。

Subversionでこれを行うにはどうすればよいですか？Tortoiseフロントエンド[Windows]をSVNに使用していますが、この機能を実現する方法がわかりません。

データベースの変更、コード生成、そしてもちろんビルド、コミット、そしてその後の展開を含む、毎日のビルドを自動化しようとしています。現在、チームの各開発者は、DB の構造とデータの変更をそれぞれ 2 つのファイル (例: 6.029_Brady_Data.sql) に含めています。各構造とデータ ファイルにはバージョンのすべての変更が含まれますが、すべての変更は反復可能です。つまり、EXISTS チェックなどを使用して、必要に応じて毎日実行できます。

現在、基本的にすべての構造変更ファイルを連結し、すべての依存関係が解決されるまで繰り返し実行してから、データ変更ファイルで繰り返します。

数百のレポートで構成される大規模な ASP.NET プロジェクトがあります。すべての SQL クエリ (Oracle データベースに対して実行) を 3 つの Web サービスに移行中です。Web サービスは、コマンド、選択、およびレポート クエリによって分類されます。インターネットから切断されたいくつかの場所に、SQL*Server バックエンドを使用してプロジェクトのサブセットをデプロイする必要があります。したがって、データベースへのすべての接続と Web サービス内のクエリを使用すると、アプリケーションが管理しやすくなり、レポートのサブセットを取得でき、コードを変更する必要がなくなります。このプロジェクトは、Serena ChangeMan ソフトウェアを使用してソース管理されています。

問題は、何人かのプログラマーがいて、彼ら全員が Web サービス ファイルをチェックアウトして自分の項目で作業する必要があることです。分岐を実装したばかりですが、徐々に悪夢になりつつあります。毎月の生産配送があり、毎月のビルドに入るはずのアイテムが翌月まで保留されることがあります. マージは手動プロセスになりました。

私はインターネット検索を実施しましたが、「ベスト プラクティス」の優れた Web サービス アーキテクチャのホワイト ページを見つけることができなかったことに驚いています。これらの問題に直面したに違いない大企業はたくさんあります。

大規模な開発グループのほとんどは分岐を使用していますか? Visual Studio Team System Database Edition は、アプリケーションがさまざまなデータベースに接続できるようにする標準コードを提供できることを読みました。Team System を購入するのが最善の方法ですか? または、これらの問題に対処するのに役立つドキュメントがどこにあるか知っている人はいますか?

ありがとう、ローリー

SQL Server Management Studio (SSMS) で「ツール ==> オプション ==> デザイナー ==> テーブルおよびデータベース デザイナー ==> 変更スクリプトの自動生成」を有効にします。データベース スキーマを変更するときは、スクリプトを保存します。アプリケーションを実行しているすべてのマシンにインストールされている DB 移行ツールのおかげで、次のソフトウェア バージョンの更新時にスキーマを同期できます。

最近、開発用コピーと一部の運用サーバーを SQL Server 2008 に切り替えました。ただし、数十台の SQL Server 2005 でソフトウェアを実際に実行しています。しばらくの間、これらをアップグレードする予定はありません。

問題は簡単です。SSMS によって生成されたスクリプトは、SQL Server 2005 で常に機能するとは限りません。SMSS は、コマンドに追加のメタデータを追加しています (たとえば、ロックのエスカレーションに関して)。2005 でスクリプトを作成するには、余分な情報を手動で削除する必要があります。そうしないと、スクリプトが実行されません。

SQL Server 2005 と互換性のあるスクリプトを生成するように SSMS を構成する方法はありますか? 余分な SQL を自動的に取り除くか、少なくともどのファイルに問題があるかを知らせるツールはありますか?

Steve Yegge の知恵にもかかわらず、ほとんどの開発者は、技術に詳しくない顧客から集められた要件に直面しています。顧客に対応し、要件を翻訳するプロジェクト マネージャーがいる場合もあれば、そうでない場合もあります。いずれにせよ、要件が変わることは避けられないことです。

「優れたプログラミング手法」を構成するもののほとんどは、変化する要件に耐えられるように適応可能なシステムを開発することに関係しています。YAGNI、DRY、疎結合などの原則がこれに貢献しています。アジャイルなどの反復的な開発プロセスも、動くターゲットを攻撃しようとする懸念に対処しようとします。もちろん、システムをテストすることで、変更を加える可能性が無限に高くなります。

それにもかかわらず、私たちの多くにとって、要件を変更すると、ソフトウェアの品質が損なわれるだけでなく、モチベーションが低下し、誰かを刺したくなるようです。

この質問は、恣意的または軽微な変更を思いとどまらせながら、必要な方法で要件を変更できるように顧客を管理する方法に関するものです。どのようにしますか？

• 開発者を顧客から隔離するプロジェクト マネージャーはいますか?
• 正式な変更管理プロセスはありますか? マネージャーを変更しますか？
• 顧客が本当に必要なときに釣り銭を手に入れるのはどれほど難しいですか?
• 逆に言えば、「軽薄」な場合、顧客はどの程度おつりを手に入れやすいのでしょうか?
• 変更のコストを説明する際、顧客にどの程度詳細に説明しますか?
• 変更のリクエストを受け取った後、顧客にこの情報をどのくらい迅速に提供できますか?
• プロセスを台無しにする要因は何ですか (例:顧客にノーと言えない PM は? )
• あなたにとって何が効果的ですか？