業界におけるソフトウェア開発ライフサイクル
地元の大学で「要件分析と設計」というモジュールを受講しています。共通モジュールと言います（ソフトウェア開発ライフサイクル（SDLC）とUML）。しかし、実際に（厳密に）業界で実践されているのではないかと思います。
たとえば、ドメインクラス図は、（設計クラスからの）追加のものではなく、厳密に分析または発見フェーズからの出力になりますか？技術的な実装についても少し考えると思いますか？そうしないと、後で元のドメインクラス図とは非常に異なる設計クラス図になる可能性がありますか？
また、イニシエーション、ディスカバリー、デザインなどの図が何であるかを思い出すのも難しいと思います。さらに、これらのフェーズはSDLCによって異なると思いますか？ですから、役に立つと思うときに、通常は図を作成します。それは間違った方法ですか？
業界内の慣行とSDLCは、会社ごとに（または同じ会社内のチームごとに）大幅に異なります。あなたの説明から、あなたの大学で教えられたSDLCは、よりフォーマルでヘビー級の非 アジャイル プロセスであるように思えます。そのようなプロセスに従う多くのプロジェクトがあります（異なる用語、ツール、およびアーティファクトを使用します。たとえば、純粋なテキストを含む分析の結果として長いWord文書を生成するプロジェクトもあれば、UML図を使用するものもあれば、まったく異なる表記法の図を使用するものもあります。 。）。また、形式化されたプロセスがゼロに近いレベルのロットもあります。そして、これらの2つの両極端の間の何か。
つまり、肝心なのは、これを実行するための正しい方法は1つではないということです。具体的なプロジェクトチームで作業を開始すると、とにかく彼らの地域の慣習やプロセスを学び、順守するようになります（大学で教えたものとはかなり異なる可能性があります）。
ただし、SDLCを選択/形成する機会がある場合は、実用的であることをお勧めします。あなた（rチーム）にとって効果的なものを使用し、定期的に発生する問題/問題を反省し、それに応じてプロセス/ツールを適応させます。出発点として、式典が少ない開発者指向のアジャイルメソッドのいくつかを調査することをお勧めします。
これらでは、さまざまなフェーズが厳密に分離されていません。完全な要件/設計を事前に作成することはできないことは認められています。先ほど触れたように、実際には、ドメインモデルの可能な設計と、設計の可能な実装について事前に検討します。また、早いプロトタイプを作成して、いくつかの仮定を早い段階で検証することもできます。また、設計中には要件に対する新しい質問と洞察が得られ、実装中には設計を変更および改良する新しい認識が得られます。
これらは私の経験にすぎません。SDLCに厳密に従っている会社で働いたことはありません。私は多くの企業でSDLCを使用してきたhad SDLCですが、リモートでフォローしている会社はありません。
ITグループはビジネスとともに有機的に成長する傾向があり、ソフトウェアを迅速にリリースし、顧客の要求に応えます。最終的に、ITは複数の管理層とCTOを持つのに「十分に大きく」なります（ITは現在「重要」です）。
それから何かがうまくいきません-顧客からの圧力の下で、ITは重要なアプリケーションのバグのあるバージョンを出荷し、最終的な収益に影響を与えます。より広いビジネスは反応します：「どうやってそれを起こさせますか？」
問題を修正した後、ITが対応していると見なして、それが二度と起こらないようにする必要があります。したがって、彼らは政策と官僚制度を導入し、SDLCは文書化されています。 SDLCは、ITが高品質のソフトウェアを予定どおりに納品する能力を改善することを実際に意図したものではなく、次の理事会でCXOを満足させることを目的としています。したがって、CFOやCMO、そして誰もが持ち込もうとする外部アナリストを感動させるように設計された、輝きと華やかさがいっぱいです。関係者全員が、それは時間の浪費であり、追跡されないことを知っていますが、ボーガンテストのようにそれに伴います。レストランでのワイン（ "mm ... it's red！"）。
もちろん、開発者はアジャイルな方法での作業に戻り、ユーザーが求めるものを構築し、可能な場合はレッドテープをショートカットします。 SDLCのいくつかの部分、たとえばリリースの承認などが行われますが、そのほとんどは、それがポリシーであり、政治的に敏感すぎるという疑問があるために行われます。
開発者は図を描き、オブジェクトモデルを設計する傾向がありますが、それらは非常に有機的に行われ、必要に応じて厳密にはフェーズの一部としてではありません。ただし、それがポリシーでない限り、通常、実際の作業ができるように、それを邪魔にならないように急いで行われます。ベギン。
以下は私自身のものです。それは、ずっと前にSDLCで成功した会社で働いた人としての私の経験に基づいています。おかしい、SDLCの使い方を間違えたので、私は別の大企業を去った。ここにあるものすべてが、今日の方法論や技法で現在有効であるとは言えません。
概念的には、SDLCは、製品を提供するための一貫した統合プロセスのセットです。方法論の主な目的は次のとおりです。
1-プロジェクト管理が可能になるように、作業フェーズと成果物を定義します。
2-業界のベストプラクティスを使用して成長するにつれて、組織が強化できる概念的なプラットフォームを定義します。
3-各タスク/ステージの入力と出力を特定することにより、組織がすべてのプロジェクトで車輪を再発明するのを止めます
4-開発プロセスの混乱状態を最小限に抑え、組織内の1人または特定の人々がすべてを知ることへの依存を最小限に抑えます-これは、適切な文書化とプロセスのさまざまなレベルの関与によって実現されます
5-合意された一連の用語、KPI、およびコミュニケーションツールを確立することにより、製品開発、管理、および組織内の他の関係者間のコミュニケーションを強化します。
SDLCは、各プロセスで最適な手法とツールを利用することで目標を達成します。
SDLCのセットアップ/選択は簡単ではなく、SDLCタスクを実行することは価値があります。
UMLはSDLCではなく、その逆も同様です。 UMLは、ソフトウェア製品を作成するために特定のSDLCによって採用される可能性があるツールの1つですが、そうではない場合もあります。たとえば、UMLを使用するメインフレームCICS開発者はそれほど多くありません。
あなたのポイントに従って：
ブロック引用たとえば、ドメインクラス図は、（設計クラスからの）追加のものではなく、厳密に分析または発見フェーズからの出力になりますか？技術的な実装についても少し考えると思いますか？そうしないと、後で元のドメインクラス図とは非常に異なる設計クラス図になる可能性がありますか？ブロッククォート
あなたはこれのいくつかで正しいです。ドメインmdoelは必ずしも設計モデルではありません。 2つの違いは、ドメインモデル（使用する方法によって異なるものと呼ばれます）は、ビジネス分析段階でビジネスの重要な事実とルールを収集することになっています。分析におけるオブジェクトの概念は非常に広いです。このようなモデルの目的は、収集した情報を設計者が使用できる形式で格納することです。通常、これはアナリストによって作成されるため、2つのクラス図が似ている場合、件名は取るに足らないか、1つのソリューションしかありません。技術モデルの目的は異なります。分析モデルからルール、データ、およびビジネス目標を継承しますが、コード生成、特定のデータベース要件、およびパフォーマンスに合わせて形成します。これは、アナリストではなくソフトウェアエンジニアが行います。その結果、それは異なります。たとえば、顧客番号は分析におけるCustomer Enittyの適切なキーかもしれませんが、データベースでは、一意のインデックスを持つ列として実装され、代わりにシーケンス番号が使用されます。また、カスタマークラスが抽象クラスに変換され、さまざまなタイプのカスタマーが独自のクラスを取得する（またはその逆）ことも珍しくありません。
あなたの質問について：
また、イニシエーション、ディスカバリー、デザインなどの図が何であるかを思い出すのは難しいと思います。さらに、これらのフェーズはSDLCによって異なると思いますか？ですから、役に立つと思うときに、通常は図を作成します。それは間違った方法ですか？
方法論は、開発プロセスの段階と、これを行うために使用する専門家とツールによって作成される図を定義する必要があります。
たとえば、分析セッションにはプロトタイプのWebページを含める必要がありますか？プロトタイプのWebページは、UML図ではありません。一般に、次のものを定義および調整する必要があります。
ユースケース図
クラス図
アクティビティ図
状態機械図
上記の各図には目的があります。目的をよく理解すれば、いつ使うべきかがはっきりします。
データモデル図（ERD）を忘れないでください。ただし、ERDはUMLの一部ではありません。繰り返しになりますが、UMLは十分ではありません。少なくとも、ほとんどの場合、それは十分ではありません。作業を正しく行うには、統合ツールと方法論、そして何よりも人々が必要です。
ですから、それが役に立つときにダイアグラムを作成します。それは問題ありませんが、方法論を使用してチームで作業している場合は、それに従う必要があり、プロジェクト計画でもそのための時間を割り当てることを忘れないでください。
このすべての最後に、SDLC、UML、プロジェクト管理を区別してください-それらは（少なくとも私にとっては）異なるものです。
幸運を。