最初に開発ソリューションをデザイン/スケッチ/描画してから開発しますか?もしそうならどうやって？[閉まっている]

StackOverflow https://stackoverflow.com/questions/155948

  •  03-07-2019
  •  | 
  •  

質問

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

開発に 1 週​​間しかかからないアプリケーションでも機能するだけでなく、より大規模なプロジェクトにも使用できるような、設計プロセスへのアプローチ方法に関する提案やクリフ ノートを探しています。

これが UML の分野を詳しく掘り下げたものであることはわかっていますが、ビジネス ユーザーが図を理解して関連付けるのに役立つことはおろか、さまざまな図の種類を適切に使用するためのガイドを見つけるのが難しいことに気づきました。

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

役に立ちましたか？

解決

紙またはホワイトボード！

一人の開発者には、紙をお勧めします。少なくとも最初は、最終的にはUMLで形式化することをお勧めしますが、その必要はないと思います。

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

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

私は自分でプロジェクトをやっているので、クラスやインタラクションのためのペーパーを設計するために多くのインデックスカードを使用しています。重要なのは、簡単に変更できる必要があるということです。 UMLを実行するために、ダイアグラムエディターであるDiaを使用しましたが、変更を加えるのは非常に困難です。素早く変更できるようにしたいので、何が最適かを判断できます。

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

[1] C＃のExtreme Programming Adventures、8ページから：

  

＆quot;スパイク＆quot;極端なプログラミング用語です   「実験」の意味。言葉を使う   スパイクを   迅速な、ほぼ総当たり的な実験   ただ一つのことを学ぶことを目指しました。   を介して大きな爪を運転することを考えてください   ボード。

他のヒント

小さなタスクまたは非常に限定されたタスクの場合、開発者は、あらゆる種類のダイアグラムが不要なステップであることにほぼ普遍的に同意すると思います。

ただし、特に2つ以上のプロセスが相互作用する必要がある場合、または複雑なビジネスロジックが必要な場合、より大きく複雑なシステムを扱う場合は、プロセスアクティビティ図は非常に便利です。開発ではかなり純粋なアジャイルメソッドを使用しますが、これらがほとんど唯一の種類のダイアグラムであることがわかります。目の前にある大きな部品をすべてフローラインで接続するだけで、高レベルの設計をどれだけ最適化できるかは驚くべきことです。ダイアグラムを問題に合わせて調整することの重要性を十分に強調することはできません。逆ではなく、リンクが適切な出発点を提供する一方で、システム/問題を表すのに意味のあるものを追加してください。

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

Kruchtenの 4 + 1ビューをご覧ください。

次の手順を実行してください。

  1. ユースケースをユースケース図に収集します。これにより、アクターとユースケースが表示されます。ダイアグラムの詳細は多くありません。

  2. ユースケースを優先して、価値の高いユースケースに焦点を当てます。

  3. 物語を書きます。必要に応じて、アクティビティ図を描画できます。

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

  1. 名詞分析を行い、クラス図を描いてエンティティと関係を説明できます。最初は、これらはユーザー用語になります。マニアックな技術コンテンツはありません。

  2. アクティビティ図を展開するか、シーケンス図を追加して、処理モデルを表示できます。これは、エンドユーザーの非技術的な処理の描写から始まります。

  3. クラス図とアクティビティ図を反復処理して、分析から設計に移行できます。ある時点で、分析からエンジニアリングモードに移行します。ユーザーはこれらの写真のすべてを見たくないかもしれません。

  4. 開発ビューのコンポーネント図と物理ビューの展開図を描画できます。これらは、システムの概念が拡大および改良されるたびに繰り返されます。

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

ユーザーストーリーを確定したら、フローチャートを作成して、アプリを使用するときに人々がたどるパスをレイアウトします。

そのステップ（承認プロセスを取得することがあります）の後、インターフェイススケッチ（ペン/鉛筆＆グラフ用紙）を作成し、データベースのレイアウトを開始します。通常、これと次のステップは最も時間のかかるプロセスです。

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

この後、一般的なUMLダイアグラム、または他のオブジェクトレイアウト/機能の整理を行いたいかもしれませんが、ビジネスの人々はそのような詳細についてはあまり気にしません：）

デザインをまとめるとき、私はアイデアを視聴者にわかりやすく簡単に伝えることに気を配っています。その聴衆は、（通常は）さまざまな背景を持つさまざまな人々で構成されています。私がやりたくないのは、特定の設計モデルの「教育モード」に入る事です。頭が中実の矢印が何を意味するのか、それが中空の矢印とどう違うのか、四角形と円が何を意味するのかを顧客に説明するのにかなりの時間を費やさなければならないとしたら、私は進歩していません - 少なくとも進歩していませんしたい。

かなりカジュアルな内容の場合は、ホワイトボードか紙に、ブロックと単純な矢印だけでスケッチします。この時点での大まかな設計のポイントは、同じ認識を持っていることを確認することです。顧客によって異なりますが。

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

GUI インタラクションを示す必要がある場合は、Visual Studio でいくつかの単純なウィンドウ プロトタイプを作成します。これは迅速かつ簡単です。顧客はそれに非常に簡単に共感できることがわかりました。

簡単に言うと、関係者や関係者にデザインを伝えるための簡単な図面を (何らかの形式で) 作成します。私は自分が何をしたいのか、そしてもっと重要なことに、彼らがそれをするために何を必要としているのかを必ず理解し、それと話し合います。通常、人々はそこで道に迷い、すべてを n 次まで図式化するのに十分な時間が費やされるとは思わないため、通常は雑草には入りません。最終的に、デザインについて話し合った後、顧客と私 (およびその他の関係者全員) が同じ考えを持っていれば、私は幸せです。

私はアジャイルの男なので、作図にあまり時間をかけない傾向があります。ホワイトボードやナプキンに何かをスケッチすると、特定の問題や要件を確実に理解できる場合がありますが、実際に動作するソフトウェアを顧客の前に置いて動作を確認するのに勝るものはありません。あなたが顧客が前もってのデザインについて頻繁な反復とデモを受け入れるような状況にあるなら、私はそれを勧めます。ユニットまたは統合テスト（ Fit ここでうまくいきます。）

私は一般的にプロトタイプが嫌いです。なぜなら、プロトタイプが非常に頻繁に最終製品になるからです。私は、基本的に「概念実証」であることが判明した商用製品を拡張していたプロジェクトに取り組んでいるという不幸がありました。パッケージ化されて販売されました。コアアプリケーションに対して1000以上の欠陥がログに記録された後、プロジェクトはキャンセルされました（現在作業中の機能強化やカスタマイズはカウントされません）。

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

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

「痛みのない機能仕様」に関するJoelの記事を読むことをお勧めします。パート1のタイトルは＆quot; Why Bother？＆quot; です。

仕事ではモックアップ画面を使用します（＆quot;クイックスクリーンイージースクリーンプロトタイプ＆quot;）。画面を変更するのは簡単で、これは単なるデザインであることがわかります。

モックアップは、仕様を含むWord文書に含まれます。

概念的なブロックバスティング：より良いアイデアへのガイド by James L. Adams：

  

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

（pg。71、第3版）

言うまでもなく、図を使用して、数学でより適切にキャプチャできるアイデアをキャプチャすることを選択した場合も、同様に悪いことです。もちろん、コツは問題と解決策の両方を表現する適切な言語を見つけることです。そしてもちろん、問題と解決策の両方を表現するために複数の言語を使用することが適切かもしれません。

私のポイントは、図が最適な方法であると仮定しているということです。私はその仮定をするつもりがあるかどうかはわかりません。他のフレーミング要件や提案された設計の方法を使用して、より良い答えを得ることができます（そして顧客は結果に満足するかもしれません）。

ところで、概念ブロックバスティングは非常にお勧めです。

UMLのアドバイスは、大規模な＆amp;多くの利害関係者と多くの貢献者によるリスク回避プロジェクト。それらのプロジェクトでも、意思決定者に見せるためのプロトタイプを開発することは本当に役立ちます。通常、UIを使用してユーザーを操作し、一般的なユーザーストーリーで十分です。ただし、意思決定者のUIに焦点を当てると、検証、ビジネスルール、データの整合性などの重要なバックエンドの問題を無視する傾向があることに注意する必要があります。彼らはこれらの問題を「技術的」として書き留める傾向があります。ビジネス上の決定ではなく問題。

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

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

すべてのユーザーで機能することがわかったのは、実際にアプリケーションの画面を表示することだけです。あなたは言った：写真は千の言葉に値する。

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

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

オプション（1）では、好きなものを使用できますが、それは重要ではありません。

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

2005年にモックアップツールを作成しましたが、かなり人気になりました。 MockupScreens

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top