会社のクライアントの 1 つ (SMB) のプロジェクトを分析する仕事に出くわしました。私は .Net 開発者 (5 年) で、ソフトウェア (学校の UML) の分析経験はほとんどありません。
ユーザーとの 2 週間の話し合いが終わったところで、要件の大きなリストができました。明らかに、最も重要な要件を除外し、一連の要件を「範囲外」としてマークする必要がありました。
いくつかのユースケースを作成し始めたばかりですが、このプロジェクト全体をうまく終わらせるのに必要な専門知識がないと感じています。誰かが開発者からアナリストに飛躍したかどうか、そしてそれがどうなったかを知りたいです。また、プロジェクトの分析に関するいくつかの優れたリソースも役立ちます。
ありがとう。
他の誰もこれを攻撃していないようですので、私がそうします。
まず、歓迎されないニュースをお伝えしなければなりません。優れたアナリストであることは、優れた開発者であることと同じです。誰もができるわけではありません。私は、複雑な Windows アプリケーション コードを書くのが得意な人をたくさん知っていますが、ユーザーが何を望んでいるかを見つけ出し、それらの要件を絞り込み、設計を考え出すのには役に立ちませんでした。ですから、うまくいかなくても気にしないでください。
これは 2 番目のポイントです。特に最新の OO システムでは、分析と設計を切り離すことはできません。この 2 つは連続体の一部です。ですから、それに備えなければなりません。
3 つ目のポイントは、UML に固執しすぎないことです。あなたのアイデアを他の人に説明するのには良いツールですが (彼らも UML を知っていれば)、実際の設計を行うにはかなり腐ったツールです。たとえば、ユース ケースは、UML が使用する棒人間の描画とは対照的に、テキスト ファイルで簡単に管理できます。UML の代わりに、単純なブロック図を使用して、通常は紙やホワイトボードにスケッチされたオブジェクト、コンポーネント、および関係を示します。
最後のポイントは、A&D は 1 人の活動ではないということです。アイデアを跳ね返すことができる他の誰かを巻き込んでください。経験豊富なアナリスト/デザイナーに 1 日ほど手伝ってもらうことができれば、なおさらです。
それが有用であり、否定的すぎないことを願っています!
ニールの悪いニュースを和らげるために、あなたがこれらの質問をしているという事実は、おそらく良い兆候だと思います.
顧客 (および経営陣) と良好な関係を築いている場合は、アジャイル アプローチのいくつかの変形を検討する価値があるかもしれません。あまりにも遠い未来を見ようとするリスクの一部を軽減するのに役立つ可能性があります。
「顧客は、彼が求めたものをあなたが提供したときにのみ、彼が何を望んでいるかを理解する」ということを心に留めておいてください:)
Strain を分析 して、顧客の要件を分析しているときに開発者のように考えないようにします。また、顧客にとって新しいシステムがどのように見えるかについてのアイデアを考え出すときも同様です。技術的な「考慮事項」(「これはコーディングがはるかに簡単になるだろう」、「その新しいテクノロジー X を使用できるだろう」) は、有用で使用可能なものを設計する際に実際に邪魔になる可能性があります。
コーディングするときパニックにならないでください。作業を扱いやすいチャンクに分割します。誰もがこれに同意するわけではありませんが、頭が回らないような手に負えないチャンクがあることに気付いた場合は、コーディングを開始してください。たとえ途中でやり直さなければならない場合でも、ただそこに座って何かが起こるのを待っています。
「目標」を見失わないように注意してください。作業中に無意識に仕様を書き直していないか、頻繁に確認してください。
UML はコミュニケーション ツールであるため、ユーザーの要件を引き出すために使用する必要があります。
誰も理解できない小さな詳細で図を過負荷にしないでください。私に関して言えば、Rational Rose などのようなギークで醜い図を使用することは避けています。グラフィック ツールを使用して自分で描画しています。それ以外の場合は、yUML.me (無料のオンライン UML ツール) などの楽しいものを使用できます。ユーザーは気に入るはずです。それ。
yUML DSL の上にビジネス アナリスト向けの使いやすい言語を開発したので、ユーザーは平易な英語で直接表現し、UML のように翻訳することができます。
Blogger is a User
Admin is a Blogger
Author is a Blogger
Subscriber is a User
Admin Manage Site
Manage Site Include Manage Users
Manage Site Include Manage Themes
Manage Site Include Manage Plugins
ソースコードはこちらから入手できます: http://reboltutorial.com/blog/easy-yuml-dialect-for-mere-mortals/
重要なのは、物事をシンプルに保つことです。多くの人がダイアグラムを複雑にしすぎているため、UML の評判が悪いのです。
新人デザイナーが良いスタートを切れるように、いくつかの投稿を公開しました。すべての投稿はここにあります: http://aviadezra.blogspot.com/search/label/UML
ほとんどの場合、配置図を使用してシステムの物理アーキテクチャをモデル化することから始めます。投稿「システムの物理アーキテクチャのモデル化」は、ノードとその相互関係のみを示す配置図の簡単な使用法を示すことから始まります。ノードで実行されるコンポーネントとアプリケーションを含めることで全体像を把握できます。
次の段階では、コンポーネント図を使用してシステムの論理アーキテクチャについて説明します。投稿「システムの論理アーキテクチャのモデル化」では、論理コンポーネントの簡単な配線を示すことから始め、コンポーネントによって公開/必要とされるインターフェイスを含めて全体図を完成させます。それらが一緒に配線される方法。
アクティビティ図を使用して並列ワークフローを示すことから始めて並列アプリケーションを設計し、シーケンス図とクラス図を使用して図を完成させる場合は、投稿「並列アプリケーションのモデリング」でプロセス全体を説明します。
詳細設計段階に入ると、クラス図を使用して、さまざまな方法で相互に関連付けられたオブジェクト (クラス) のタイプの観点から問題のドメインを記述します。投稿「関連付け、集約、構成」では、関連付けコネクタの 3 つのバリエーションについて説明しています。クラス図で使用されます。
次に、シーケンス図を使用して、さまざまなオブジェクトがどのように相互作用するかを示します。シーケンス図でよくある問題は、条件と反復をどのように表示するかということです。投稿「相互作用フラグメント」では、相互作用フラグメント演算子 (Alt、Opt、Par、Loop、および Region) をその問題に使用する方法について説明しています。