「関連情報」を上手に活用してシンプルにする 6.「事後条件」 ユースケースがうまく動いたら結果として何が出てくるのか。それを書くのが事後条件です。この場合なら、次回から利用者がシステムを利用できるように「ユーザID」と「パスワード」を発行します。一般的なWebシステムの場合には、仮のユーザIDとパスワードを発行し、後ほどユーザがそれらを変更するような仕組みにしています。
「関連情報」を上手に活用してシンプルにする 6.「事後条件」 ユースケースがうまく動いたら結果として何が出てくるのか。それを書くのが事後条件です。この場合なら、次回から利用者がシステムを利用できるように「ユーザID」と「パスワード」を発行します。一般的なWebシステムの場合には、仮のユーザIDとパスワードを発行し、後ほどユーザがそれらを変更するような仕組みにしています。
カスタマージャーニーマップだけでは不十分顧客行動の分析ツールであるカスタマージャーニーマップを使うと、顧客行動を包括的に捉えることができ、新しいサービスを考えるヒントの発見につながります。 しかし、実際の現場では「ジャーニーマップを作成したものの、そこから新たなサービスのアイデアにつながる糸口が見出せなかった」ということも少なくないようです。場合によっては、カスタマージャーニーマップを作ること自体を目的にしてしまい、肝心の顧客価値の創出を可能にするサービスの設計につながらないということも……。 うまくいかない原因は何でしょうか? それは、サービスを設計するうえで、 「顧客の旅」を把握するということは、どういうことなのかカスタマージャーニーマップは、「顧客の旅」のどの段階の把握に有効なのかといったことを理解しないまま、マップを作成しているからではないでしょうか。 そうです。サービスデザインの
システムまたはアプリケーションが人、組織、外部システム等と対話するシナリオを示したものです。ユースケース図でこれらの登場人物(システムも含む以降アクターと呼ぶ)が達成する目的やシステムの範囲を示すものです。システムの範囲というのが重要です。 ユースケース図も規模が大きくなってくると複雑になるので、ある特定のシーン(シナリオ)においてという前提をつけて書き出すと綺麗になっていきます。 ユースケース自体を書き始めると粒度が分からなくなってしまう事が多いので、ザクっとした「○○が✕✕する」という英語で習った主語+動詞というレベルだけに絞って書くなどのルールを決めると分かりやすくなります。 自分なんかは設計するときに口を酸っぱくして言うことの1つに「システムでやらないことを決めろ」といいますが、システムでやらないことを決めるのに、利用するのがユースケース図です。 いや逆でしょってツッコミ受けると思
キーボードから手を話したくありません。 なのでファイラーはあふです。 どこかにまとめがありましたのでそれをさらに自分用に。。。 あふの終了 [q] 設定画面 [z] 処理の中止・内部ビューアの終了 [esc] ファイル窓の大きさ変更 [alt]+[←][→] 左右のファイル窓を同サイズにする [-]+[(テンキー)] メッセージ窓の大きさ変更 [alt]+[↑][↓] メッセージ窓のラインスクロール [shift]+[↑][↓] メッセージ窓のページスクロール [shift]+[←][→] あふで使うDLLをメッセージ窓に表示 [/] 容量計算表示(占有容量) [i] 容量計算表示(単純合計容量) [shift]+[i] ドライブの変更 [l] ルートディレクトリに移動 [\] 一つ上のフォルダに移動 [bs] 登録フォルダに移動 [j] パスを指定して移動 [shift]+[j] ファイ
2011年4月以降に追記したコンテンツは「あふwと連携 - 其弐」に移動しました。 旧「あふと連携」コンテンツに関しては、「あふw」での動作確認をしてから 再公開する予定です。あくまでも予定。予定は未定。 Afx Wiki をご覧頂いた方ががいいかも。
まずはじめに注意。万一ここで説明した内容にわかりにくい部分や誤りがあったとしても、絶対にフリーソフトの作者さんにメールで質問したりしないでください。フリーソフトは基本的にノンサポートです。サポートしてくださったとしてもそれは作者さんの厚意によるものです。分からない部分はご自分で調べるようにしてください。 これからしばらく初心者の方にも配慮が必要な内容となるためっていうか俺自身の気分転換のため、敬体で記述することにしようと今唐突に決めた。っていうかきめました。 なんか俺自身書いてて調子が狂うっていうか気持ち悪いのだがじゃなくてですが、カチャカチャWindows編終了まで、この不気味な文体におつきあいいただければと思います。 なお、初心者向けとはいえそこはそれさすがに俺のこと、ほんとに全然皆目分からない方のために懇切丁寧な説明ができるほど根気がありませんので、何だよおめえわかんねえよそこんとこ
gitで日本語ファイルが文字化けする こんばんは。小室です。gitを使っていて日本語のファイル名を入れるとファイル名の表示が崩壊するという経験をしました。 割と今までは放置していたのですが、きちんと日本語ファイル名を表示するコマンドを教えてもらったため、備忘録として記録しておきます。 若干人を小馬鹿にしたようなファイル名のファイルを配置したディレクトリをサンプルとして用意しました。 $ ls -la total 8 drwxr-xr-x 4 komurohiraku staff 136 Mar 25 19:09 . drwxr-xr-x 22 komurohiraku staff 748 Mar 25 19:08 .. drwxr-xr-x 10 komurohiraku staff 340 Mar 25 19:08 .git -rw-r--r-- 1 komurohiraku staff
たとえば、svnのリポジトリhttp://server/svn/trunk/repoをgitで扱いたい場合、 [shell]git svn clone http://server/svn/trunk/repo[/shell] とやれば、svnのリポジトリをgitとして扱うことが出来ます。 gitでtagやbranchなども使ってsvnリポジトリを扱いたい場合 [shell]git svn clone -s http://server/svn/trunk/repo[/shell] とすれば、ブランチやタグの情報も取得出来るようになります。 ただし、 http://server/svn/trunk/repo http://server/svn/branches http://server/svn/tags という構成になっていないと よろしくやってくれないようです。 通常と違う構成でsvnを使
svnからgit移行はwindowsが便利だった話。 いろんなところでgit-svnコマンドでの変換を見たけど、 winならGUIで一発で変換できた。 必要なもの tortoisegit(とーたすぎっと) これだけ。 やり方 checkout したいディレクトリで右クリック > Git Clone ... svnのURLと、git変換後ディレクトリの指定、 From SVN Repositoryにチェック > OK success と表示されれば完了 プロキシは 右クリック > Tortoisegit > Setting... > Network あとは $ git remote add origin [URL] とか $ git push origin master 変換後コミットログ コミットログはgitに変わっても svnのコメント、時間に加えコミット番号も残る。 commit 0c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く