uml - 最初に開発ソリューションを設計/スケッチ/描画してから開発しますか? もしそうなら、どのように？

Question

私は、ビジネスでテクノロジーをより有効に活用したいと考えている意思決定者と多くの仕事をしています。百聞は一見にしかず、システムのプロトタイプを何らかの図で作成することは、常に議論に大いに役立ちます。私は、Visio、UML (ある程度)、マインドマップ、フローチャート、およびモックアップされた WinForms を使用して、これらのスポンサーのビジョンを開始し、全員が同じページにいることを確認しました。私は常に、共通のプロセスを使用してビジネスビジョンを開発プロセスに結びつけ、「問題を解決する機能的なもの」という同じ目的に到達できるようにする方法を探しているようです。

開発に 1 週間しかかからないアプリケーションでも機能するように設計プロセスにアプローチする方法についての提案や Cliff のメモを探していますが、大規模なプロジェクトにも使用できます。

これが UML の領域を掘り下げていることは承知していますが、さまざまな種類の図を適切に使用するためのガイドを見つけるのに苦労していることに気付きました。

システム/アプリケーションのビジョンを捉え、プロジェクトのスポンサーに提示するために何を使用しますか? (1行のコードを書く前にすべて)...

score 3 · Accepted Answer

紙でもホワイトボードでも！

孤独な開発者には、紙をお勧めします。少なくとも最初は、最終的には UML で形式化したくなるかもしれませんが、その必要はないと思います。

(物理的に) 一緒に作業する開発者のグループには、ホワイトボードをお勧めします。そうすれば、誰にでも見えるようになり、誰もが改善して貢献することができます。繰り返しますが、この時点で形式化したいと思うかもしれませんが、まだその必要はないと思います

私が最初に OOP (またはアルゴリズムの設計) を始めたとき、コーディング中に頭の中ですべてを行っていました。しかし、かなり複雑なプロジェクトをいくつか行った後、システム内のさまざまなオブジェクト間の相互作用を引き出すことの利点を明確に理解しています.

私は一人でプロジェクトを行っているので、クラスの設計にはインデックスカードを、相互作用については紙を大量に使用します。ポイントは、簡単に変更できる必要があるということです。UML を作成するためにダイアグラムエディタの Dia と遊んだことがありますが、変更を加えるのは難しすぎます。すばやく変更できるようになりたいので、何が最適かを判断できます。

TDD と "spike"[1] プロジェクトを行うことは、システムを設計するときにも役立つことに言及する価値があります。

[1] C# での極端なプログラミングの冒険、8 ページから:

「スパイク」は「実験」を意味するエクストリームプログラミング用語です。私たちがこの言葉を使っているのは、スパイクとは、たった 1 つのことを学習することを目的とした、ほとんど力ずくのような迅速な実験だと考えているからです。ボードに大きな釘を打ち込むことを考えてみてください。

score 2 · Accepted Answer

小規模または非常に制限されたタスクの場合、開発者はほぼ例外なく、どのような種類の図も不要なステップであることに同意していると思います。

ただし、大規模で複雑なシステムを扱う場合、特に 2 つ以上のプロセスが相互作用する必要がある場合や複雑なビジネスロジックが必要な場合は、プロセスアクティビティ図が非常に役立ちます。私たちは開発においてかなり純粋なアジャイル手法を使用しており、これらが私たちが使用するほとんど唯一のタイプのダイアグラムであることがわかりました。すべての大きなピースを目の前に配置し、それらをフローラインで接続するだけで、高度な設計をどれだけ最適化できるかは驚くべきことです。その逆ではなく、問題に合わせて図を調整することがいかに重要であるかを十分に強調することはできません。そのため、リンクは適切な出発点を提供しますが、システム/問題を表すのに意味のあるものを追加するだけです.

ストレージに関しては、ホワイトボードはブレーンストーミングやアイデアがまだ洗練されているときに最適ですが、アイデアがかなり最終的な形になったら、電子的なものや Wiki の方が優れていると私は主張します (OmniGraffle はダイアグラム作成の王様です)。仕事で Mac を使用できるほど幸運です :) 。これらすべてのダイアグラムをダンプする領域があると、新しい人がコードを掘り下げることなくシステムの全体的な部分をすばやく把握するのに非常に役立ちます。また、アクティビティ図はより大きな論理ブロックを表すため、常に最新の状態に保つ必要があるという問題はありません。システムに大きな変更を加える場合は、そうですが、既存の図を使用して変更を計画することをお勧めします。

score 1 · Accepted Answer

私はアジャイル派なので、作図にはあまり時間をかけません。ホワイトボードやナプキンに何かをスケッチすることが、特定の問題や要件を確実に理解するのに役立つ場合もありますが、顧客の前で実際に動作するソフトウェアを見て、どのように機能するかを確認することに勝るものはありません。あなたの顧客が、事前の設計よりも頻繁な反復とデモを受け入れる状況にある場合は、それを選択してください。単体テストまたは統合テストに合格するという形で初期のフィードバックを得ることができればさらに良いでしょう (ここではFitのようなものがうまく機能します)。

試作品が最終製品になることがあまりにも多いため、私は基本的に試作品が嫌いです。私は、パッケージ化されて販売された「概念実証」であることが判明した、基本的に商用製品を拡張するプロジェクトに取り組んでいたという不運に見舞われました。コアアプリケーションに対して 1000 件を超える欠陥が記録された後、プロジェクトはキャンセルされました (現在取り組んでいる拡張機能やカスタマイズはカウントされません)。

私は UML を使ってみましたが、ダイアグラムを見ている人が UML を理解していなければ、ほとんど役に立たないことがわかりました。画面のモックアップは一般的に悪い考えではありませんが、ユーザーに直接影響を与えるアプリケーションの側面のみを表示するため、プレゼンテーション以外のものについてはあまり効果がありません. 奇妙なことに、Visual Studio のワークフローデザイナーのようなツールは、非開発者が理解しやすい非常に明確なダイアグラムを生成するため、アプリケーションが十分に複雑である場合、コアアプリケーションワークフローを生成するための優れたツールになります。

それでも、私が何年にもわたって使用してきたすべてのアプローチの中で、ユーザーが問題をどれだけよく理解しているかを知らせるために何かを手に入れることに勝るものはありません。

score 1 · Accepted Answer

コンセプチュアルブロックバスティング: ジェームズ L. アダムスによるより良いアイデアへのガイド:

知的ブロックは、精神的戦術の非効率的な選択または知的弾薬の不足をもたらします。. . . 1. 間違った言語 (口頭、数学、視覚) を使用して問題を解決する -- 問題を視覚的により簡単に解決できるのに数学的に解決しようとする場合のように

（71ページ、第3版）

言うまでもなく、数学でより適切に捉えられる可能性のあるアイデアを捉えるために図を使用することを選択した場合、それは同様に悪いことです. もちろん、秘訣は、問題と解決策の両方を表現する適切な言語を見つけることです。そしてもちろん、問題と解決策の両方を表現するために複数の言語を使用することが適切な場合もあります。

私が言いたいのは、図が最善の方法であるとあなたが想定しているということです。私はその仮定を進んで行うかどうか確信が持てません。要件と提案された設計をフレーミングする他の方法を使用して、より良い回答を得ることができます (そして、顧客は結果に満足する可能性があります)。

ちなみに、Conceptual Blockbusting は読むことを強くお勧めします。

score 1 · Accepted Answer

Kruchten の4+1 Viewsを読んでください。

先に進む方法は次のとおりです。

ユースケースをユースケース図にまとめます。これにより、アクターとユースケースが表示されます。この図は、多くの詳細から始まるわけではありません。
ユースケースに優先順位を付けて、価値の高いユースケースに焦点を当てます。
物語を書く。必要に応じて、アクティビティ図を描くことができます。

上記は完全に非技術的です。UML では、使用する形状にいくつかの規則が課されていますが、それ以外は、エンドユーザーの用語で物事を表すことができます。

エンティティと関係を説明するためにクラス図を描いて、名詞分析を行うことができます。最初は、これらはユーザー用語になります。マニアックな技術コンテンツはありません。
アクティビティ図を展開するか、シーケンス図を追加して、処理モデルを表示できます。これは、エンドユーザー向けの非技術的な処理の描写から始まります。
クラス図とアクティビティ図を反復処理して、分析から設計に移行できます。ある時点で、分析からエンジニアリングモードに移行します。ユーザーは、これらの写真のすべてを見たくない場合があります。
開発ビューにはコンポーネント図を、物理ビューには配置図を描くことができます。これらは、システムの概念が拡張および洗練されるにつれて繰り返されます。

score 1 · Accepted Answer

アプリケーションを設計するとき (私は主に Web アプリケーションを作成しますが、これは他のアプリケーションにも当てはまります)、通常、ユーザーストーリーを作成して、エンドユーザーが本当に必要としているものを正確に判断します。これらは典型的な「ビジネス要件」を形成します。

ユーザーストーリーが明確になったら、フローチャートを作成して、ユーザーがアプリを使用する際にたどる経路を示します。

そのステップ (承認プロセスが必要な場合もあります) の後、インターフェイススケッチ (ペン/鉛筆と方眼紙) を作成し、データベースのレイアウトを開始します。これと次のステップは、通常、最も時間のかかるプロセスです。

次のステップは、スケッチを取得して、それらをクリーンアップされたワイヤーフレームに変換することです。このステップには OmniGraffle を使用しています。これは Visio よりも何光年も先を行っています。

この後、典型的なUMLダイアグラム、または他のオブジェクトレイアウト/機能編成を行いたいかもしれませんが、ビジネスの人々はその種の詳細についてあまり気にしません:)

score 1 · Accepted Answer

デザインをまとめるときは、アイデアをきれいに、簡単に聴衆に伝えることに関心があります。その聴衆は、（通常）さまざまなバックグラウンドを持つさまざまな人々で構成されています。私がやりたくないのは、特定の設計モデルの「教育モード」に入ることです。真っ黒な頭の矢印が何を意味するのか、中空の矢印とどのように違うのか、または正方形と円が何を意味するのかを顧客に説明するのにかなりの時間を費やさなければならない場合、私は進歩していません-少なくとも進歩ではありませんしたい。

それがかなり非公式なものであれば、ホワイトボードや紙にスケッチします - せいぜいブロックと単純な矢印です. この時点での大まかな設計のポイントは、同じページにいることを確認することです。客によって違うだろうけど。

より正式なものであれば、UML ツールを取り出していくつかの図をまとめるかもしれませんが、ほとんどの顧客はソフトウェアを作成しておらず、おそらく内部でわずかに興味深いだけです。私たちはそれを「バブルとライン」レベルに保ち、明確化が必要な箇条書きリストをまとめるかもしれません. 私の顧客は通常、クラス図などを見たくありません。

GUI インタラクションを表示する必要がある場合は、Visual Studio でいくつかの単純なウィンドウプロトタイプを作成します。すばやく簡単に作成できます。私は、顧客がそれを非常に簡単に関連付けることができることを発見しました.

簡単に言えば、関係者や利害関係者に設計を伝えることができる簡単な図面 (何らかの形式で) を作成します。私は、私が何をしたいのか、さらに重要なことに、彼らが何をする必要があるのかを理解していることを確認し、それと話します. 人々は迷子になり、すべてをn次まで図式化するのに十分な時間を費やすことができないため、通常は雑草には入りません。最終的に、デザインを通して話し合った後、顧客と私 (および他のすべての関係者) が同じページにいる場合、私は幸せな男です.

score 1 · Accepted Answer

「Painless Functional Specifications」に関する Joel の記事を読むことをお勧めします。パート1のタイトルは「Why Bother?」です。.

私たちは職場でモックアップ画面を使用しています(「迅速で簡単な画面プロトタイプ」)。画面を変更するのは簡単で、スケッチはこれが単なるデザインであることを明確にしています。

モックアップは、仕様を含む Word ドキュメントに含まれます。

score 0 · Accepted Answer

4+1 ビューは、技術者にのみ適しています。そして、彼らが十分に興味を持っている場合にのみ。ユースケース図について顧客と話し合うのに苦労した過去数十回のことを覚えていますか?

私が見つけた唯一の方法は、実際にアプリケーションの画面を表示することです。あなたは自分自身を言いました: 写真は千の言葉の価値があります。

不思議なことに、私のために働いた 2 つのアプローチがあります。

ユーザーに完全なユーザーマニュアルを提示する (開発を開始する前に)、または
完成したアプリのように見えないモックアップを使用する: 最初にアプリのメイン画面について話し合います。満足したら、モックアップの議論を続けますが、一度に 1 つのシナリオに進みます。

オプション (1) については、好きなものを何でも使用できますが、実際には問題ではありません。

オプション (2) については、ペンと紙から始めても問題ありません。しかし、すぐに専用のモックアップツールを使用したほうがよいでしょう (モックアップを編集、維持、または整理する必要がある場合)。

私は 2005 年に独自のモックアップツールを作成することになりました。

そして、これが私が知っているモックアップツールの最も完全なリストです。それらの多くは無料です: http://c2.com/cgi/wiki?GuiPrototypingTools

score 0 · Accepted Answer

UML のアドバイスは、多くの利害関係者と多くの貢献者がいる大規模でリスク回避的なプロジェクトに取り組んでいる場合に有効です。これらのプロジェクトでも、プロトタイプを開発して意思決定者に見せることは非常に役立ちます。通常は、UI と典型的なユーザーストーリーを説明するだけで十分です。とはいえ、意思決定者向けの UI に注目すると、検証、ビジネスルール、データの整合性などの重要なバックエンドの問題が無視される傾向があることに注意する必要があります。彼らは、これらの問題をビジネス上の決定ではなく「技術的」問題として片付ける傾向があります。

一方、コードをすばやく変更できる (そして間違いをすばやくロールバックできる) アジャイルプロジェクトに取り組んでいる場合は、すべての作業を含む進化的なプロトタイプを作成できる可能性があります。アプリケーションのアーキテクチャは、迅速な変更をサポートするのに十分な柔軟性と柔軟性を備えている必要があります (ネイキッドオブジェクトのデザインパターンや Rails スタイルの MVC など)。実験を奨励する開発文化を持つことは助けになり、BDUF は成功するソフトウェアの動作を予測するものではないことを認めます。

uml - 最初に開発ソリューションを設計/スケッチ/描画してから開発しますか? もしそうなら、どのように？

10 に答える 10

Related

Reference