問題タブ [sdlc]

開発チームのシニアとして、私はチームのためにより洗練されたプロセスを生成するのを手伝うように頼まれました.現在、各フェーズの境界と出力が何であるかについて標準化されていないSDLC /ウォーターフォール方式に漠然と従っています（「ここで.いくつかの要件があります。コーディングしてください!")。

アジャイルなどのさまざまな方法論の議論に入ることなく (私は好きですが、おそらくそれを持ち出す方法について別のスレッドを開始するでしょう)、開発者が関与する SDLC フェーズを形式化するための優れたリソースはありますか? アイデアはプロセスを標準化することであるため、一般的に必要とされる特定の手順やドキュメントのアイデアについて議論することをお勧めします。

このトピックに関する標準的なウィキペディアの記事とその枝を熟読しました。それらは全体的な概要を示していますが、私たちが従うべき一般的なプロセスを引き出したいと思います。ビッグバン アプローチを回避するための段階的な手順も役立ちます。

チームのほとんどはカウボーイ コーダーであり、唯一の公式の成果物はコード自体の最終結果です。設計、ドキュメンテーション、および業界がすでに受け入れているその他の多くのステップと成果物があるので、それが私が求めているものです。

製品は、リリースではなく機能として開発および提供されます。つまり、機能が完了すると、ステージングにプッシュされてから本番環境にプッシュされます。開発中の複数の機能があり、配信タイムラインが重複している可能性があります。そのため、いつでも開発データベースとソース管理には開発中の複数の機能があります。機能が完成したら、機能固有のコードとデータベースの変更のみをステージングにプッシュしたいと考えています。このプロセスは、次の理由により、エラーが発生しやすく、時間がかかることがわかっています。

• 特定の機能の DB エンティティは独立していませんが、依存しており、他の機能と絡み合っています。そのため、機能に固有のエンティティを分離するのは時間がかかり、達成が困難な場合もあります。それを行うより良い方法はありますか？
• サーバー側のコードでは、同様に機能固有のコードを分離することは、データベースと同じくらい面倒です。DB の上にレイヤー化された .NET Entity Framework と、事前に生成されたビューなどの他のパフォーマンスの最適化を使用して、機能ベースの開発をデプロイするより良い方法はありますか?

開発環境は、SQL Server 2008、.NET、ソース管理用の SVN を備えた Entity Framework で構成されています。

ここでの機能という用語は、FDD アジャイル モデルとは関係ありません。

似たような経験をした人はいますか？

どうもありがとう！

こんにちは、私はasp.net Webサイトを作成しています.SDLC Straitegyに従っているので、どの図を描く必要がありますか.

新しいASP.Netサイトに取り組んでいます。私たちが行った最後の主要なサイトは、従来のASPでした。そこで使用した手順は、最初にHTMLを完成させ、次にASPコードで「それを実現する」ことでした。

ASP.Netの世界では、これはどのように機能しますか？つまり、マークアップの多くが実際にサーバーコントロールによって生成されている場合、設計者はどのように作業を行うのでしょうか。

また、ASP.NetMVCを潜在的な軽量の代替手段として検討しています。

デザイナーと協力し、彼らの仕事をコードと統合するという観点から、両方のシナリオで人々にとって何が最も効果的であったかを知ることに非常に興味があります。

更新：私はここで尋ねていたものを洗練しました。まったく同じ質問ではありませんが、これはおそらくそれとマージできるように十分に似ています。それらをマージする方法についてのアドバイスをいただければ幸いです。

SDLC のさまざまな段階で使用できるさまざまな UML ダイアグラムは何ですか? SDLC のさまざまな段階ごとに可能な UML ダイアグラムのマッピングを探しています。

これが重複している場合は申し訳ありませんが、質問の検索用語はかなり一般的です。

私は小さな（っぽい）開発会社で働いています。私は小さいと言っていますが、会社は実際にはかなりの規模です。ただし、これまでのほとんどの作業は請負業者を中心に編成されていたため、フルタイムの開発者は私が 2 人目にすぎません。

私は、社内のプロジェクト プロセスとポリシー (SCM や単体テストなどの明白なもの) を定義する立場にあります。方法論は、私がまとめているドキュメントの範囲外ですが、私たちをより無駄のない (そしておそらくアジャイル?) 方向に推し進めたいと思っています。

良い実践の推奨事項はたくさんあるように感じますが、私の文書を私が望むスピリット ガイドにするための十分な確固たる動機はありません。ドキュメントを「原則」と「推奨事項」に分けました。おすすめは簡単に出てきました。SCM を使用し、定期的にスケジュールされた 1 ステップのビルドに努め、最初に単体テストを行い、作業を進めながら文書化します。ただし、これらの推奨事項を通知するはずの原則をリストするのは大雑把です。

私は、「ツールは私たちのために働く。決してツールのために働くべきではない」と、「退屈はすべての悪の根源」と読みたい QA を目的とした漠然とした条項 (これは過度に手作業でした) を思いつきました。 .

このドキュメントによって、社内で良いスタートを切る機会を逃したくはありません。欠けている原則は何ですか？

編集 4/15 -

このドキュメントの範囲について、私はあいまいだったかもしれません。今のところ、共同開発者と私が従う予定のポリシーです。これまでのところ、ローカル ツール、ソース管理などの選択、および開発で従う一般的なプロセス (ビルド、デプロイ、継続的インテグレーションを使用するかどうかなど) は自由に決定されています。

理想的には、この文書がさらなるプロセス改善の基礎となるモデルになることも望んでいます。私は主に QA について考えており、おそらくプロジェクト管理をより軽くて反復的なものに向けて微調整しています。

既存のJavaコードがあり、それに基づいて設計ドキュメントを作成する必要があります。

手始めに、全体的なプロセスに役立つ入力/出力パラメーターを持つすべての関数を取得できたとしても。

注：プロシージャ、関数、またはクラスに関するドキュメントはありません。

少なくとも最後のではなく。このフェーズに必要な時間を短縮する優れたツールがあれば教えてください。現在のように、私たちはすべてのフローと関連するものを書きます。

新しいビルドを作成して本番環境にリリースするプロセスは、SDLCの重要なステップですが、多くの場合、後付けとして残され、会社ごとに大きく異なります。

私は、人々が組織内でこのプロセスに対して行った改善を共有し、私たち全員が「痛みを軽減する」ための措置を講じることができるようになることを望んでいます。

ですから、問題は、リリースプロセスの苦痛で時間のかかる部分を1つ特定し、それを改善するために何をしたかということです。

私の例：以前の雇用主では、すべての開発者が1つの一般的な開発データベースでデータベースを変更しました。次に、リリース時期になると、RedgateのSQL Compareを使用して、DevデータベースとQAデータベースの違いから巨大なスクリプトを生成しました。

これはかなりうまく機能しますが、このアプローチの問題は次のとおりです。

1. Devデータベースのすべての変更が含まれ、そのうちのいくつかはまだ「進行中」である可能性があります。
2. 開発者が競合する変更を行うことがありました（リリースが本番環境に入るまで気付かれませんでした）
3. スクリプトを作成して検証するのは、時間のかかる手動のプロセスでした（つまり、検証するということは、問題1や2などの問題を取り除くことを試みてください）。
4. スクリプトに問題があった場合（たとえば、スクリプト内にあるがまだ実行されていない外部キーレコードに依存するレコードの作成など、実行の順序）、スクリプトを「微調整」してスムーズに実行するのに時間がかかりました。 。
5. これは、継続的インテグレーションにとって理想的なシナリオではありません。

したがって、解決策は次のとおりです。-

1. データベースへのすべての変更のポリシーを適用するには、スクリプトを作成する必要があります。
2. スクリプトの正しい実行順序を確保するには、命名規則が重要でした。
3. ツールを作成/使用して、リリース時にスクリプトを実行します。
4. 開発者は、データベースの独自のコピーを開発しました（したがって、「お互いに足を踏み入れる」ことはもうありませんでした）

このプロセスを開始した後の次のリリースは、問題が少なく、はるかに高速でした。実際、見つかった問題は、スクリプトを作成しないなど、人々が「ルールを破った」ことによるものだけでした。

QAへのリリースに関する問題が修正された後、本番環境へのリリースの時期になると、非常にスムーズになりました。

他のいくつかの変更（CIの導入など）を適用しましたが、これが最も重要であり、全体として、リリース時間を約3時間から最大10〜15分に短縮しました。

私たちの投資家は SDLC を望んでいます。私はこれまでに本を書いたことがなく、本を買いに行ったり、それらについて学ぶのに多くの時間を費やしたりするのに十分な時間がありません. 私が彼らについて聞いたところによると、それらは要件 (何をする必要があるか) で構成されており、リストが作成されています。これは正しいです？

更新：

この記事は、物事を簡単な言葉で非常に迅速に説明するのに本当に役立ちます. SDLC をすぐに作成する必要があるとは思いません。私の場合、他に選択肢はありません。

すべてのカスタム レガシー ソフトウェアは変更が必要です。ユーザーはそう言います。場合によっては、1 つまたは 2 つの機能を追加し、コードの一部を変更したり、コントロールを追加したり、その他のマイナーなアップグレード タスクに必要なすべてを追加したりする必要があります。エラーが発生しやすい VB5 デスクトップ ソリューションを捨てて、すべてをリッチな Web 2.0 ASP.NET MVC アプリケーションとして書き直そうとする場合もあります。ただし、多くの場合、従来の機能に対する変更の範囲は、これら 2 つの両極端の間のどこかにあります。

既存のアプリケーションをアップグレードするか、ゼロから始めるかを決定する際に使用する経験則は何ですか?