flowchart.js
st=>start: Start:>http://www.google.com[blank] e=>end:>http://www.google.com op1=>operation: My Operation sub1=>subroutine: My Subroutine cond=>condition: Yes or No?:>http://www.google.com io=>inputoutput: catch something... para=>parallel: parallel tasks in=>input: some in out=>output: some out st->op1->cond cond(yes)->io->e cond(no)->para para(path1, bottom)->sub1(right)->op1 para(path2, top)->o
初歩のUML：＠IT
編集局より：2003年2月に本連載が「【改訂版】初歩のUML」としてリニューアル、大幅な加筆・修正を行い、さらにわかりやすい内容に生まれ変わりました。 UML(Unified Modeling Language：統一モデリング言語）は、フローを書くとソースコードのほとんどを自動生成してしまうような旧来の似非CASEツールの一部のように思っている方も多いようです。UMLは、そのようなものではありません。 「UMLはオブジェクト指向を使ってモデリングする際に使われる統一的な言語なのです」といっても、何のことかよく分からないですよね。最近書店に行くとUMLコーナーができるくらい、ものすごい人気。過剰ともいえる盛り上がりを見せています。現在はソフトウェア技術者だけがUMLユーザーとなっていますが、今後何年かの間に普通のビジネスマンがUMLを使用することになるでしょう。ビジネスの構造をとらえる手法（
シンプルなテキストファイルで UML が書ける、オープンソースのツール
🚀 はじめに PlantUMLは、様々なダイアグラムを迅速かつ簡単に作成できる、非常に多目 的なツールです。 シンプルで直感的な言語を利用することで、ユーザは様々なタイプのダイアグラム を簡単に作成することができます。 この言語の機能とシンタックスの詳細については、PlantUML Language Reference Guide をご参照ください。 PlantUML を初めてお使いになる場合には、 を素早く立ち上げて実行するために、クイック・スタート・ ページから始めることをお勧めします。 さらに、PlantUML は、ワークフローを強化するために、他のさまざまなツールと シームレスに統合することができます。
標準フローチャート記号と使い方
Part 1: よく利用される3つのフローチャート記号 ここでは、非常に人気があり、ほとんどすべてのフローチャートで一般的に使用されている3つのフローチャート記号が表示されます。: 開始/終了、処理、判断。 ① 開始/終了記号 「端子」とも呼ばれる「開始/終了」記号は、角丸四角形であり、プロセスまたはプログラムの開始/終了を示す記号です。 通常、フローチャートの最初と最後に配置され、記号内に「開始」と「終了」を記述します。 具体的な業務フローには、業務開始の機会・トリガーや終了の結果・目標が記載されている場合もあります。たとえば、採用プロセスフローチャートでは、開始記号に「採用戦略決定」を入力し、終了記号に「候補者雇用」を入力できます。 ② 処理記号 「行動」記号とも呼ばれる「処理」記号は、四角形であり、プロセス内の個々のステップ、操作、処理、および機能の特定の内容を表す記号です。各ボック
すごい役立った！Web制作に特化した「提案書」に入れておきたいこと、知識
作成：2014/02/3 更新：2014/11/01 ディレクション > 提案書に必ず書いておきたいことを順を追ってメモしました。イメージはブログ用なので簡易的なものとなっています。フローや内容は会社によって違うと思います。 エンジニア速報は Twitter の@commteで配信しています。 もくじ サイトリニューアルの提案 自社分析によるサイトの問題点とその解決策 見やすさ、管理しやすさへの主な工夫 サイトレイアウト案（トップページ） フロント画面＋管理画面 イメージ 保守＋運用 セキュリティ面でのご提案 バックアップと緊急時の対応 サイトマップ案 強み、実績、事例 スケジュール サイトリニューアルの提案 企画提案書の流れをメモしておきます。実際に提案するときは、ポイントをおさえて簡潔に説明していきます。必要な部分だけピップアップして使います。 自社分析によるサイトの問題点とその解決策
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォータ
勉強会でグラッフィックレコーディングを６時間ぶっ続けで描き続けてみた。 - スワンのラクガキ報
こんにちわ、スワンです( 'ω') 2/3に開催された「Creative X #1 今あるデザイナの危機に立ち向かう知識」に参加してきました。デザイナー向けのイベントでかつ土曜日だったのに参加者は300名とっても大盛況な大型イベントでした〜 もちろんイベント自体もすごい良かったんだけど、今回は昨年の年末ぐらいから取り入れだしてたグラフィックレコーディングをライブで実践して練習してみようと思って散財したipadちゃんと共に馳せ参じました( 'ω')> swaaan.hateblo.jp ちなみに今回、意気揚々と現地に着いたものはいいもの六本木一丁目が複雑すぎて会場着くのに半泣きなりかけるほど迷いまくった・・・（笑）いろんなところ不法侵入した気がする。 でもどうにかたどり着いてみたら、DMMの会議室までの道のりとイベントスペースが禿げそうなほどにオシャレだったのでビビりまくりでしたがとっても居
単体テスト項目書を書くのに、守らなかったら自殺すべき3つの原則 - @ledsun blog
1.テスト項目書を書くときは用語集を作ること 用語集を作れば 表記ブレを防げる 重複を減らせる 毎回説明を記述する必要がなくなるので全体はコンパクトになる。 テスト実施者に重複した内容を何回も読ませる奴はDRY原則をわかってない、自殺すべき。 2.ユースケースシナリオと単体テストの項目が合ってないのはどっちかがおかしい ユースケースシナリオと単体テスト項目の内容がずれていたら「正しい仕様」を確認する。 ログインに失敗したときのメッセージが ユースケースシナリオでは「パスワードを確認してください。」 単体体テスト項目では「IDとパスワードのいずれかが間違っています。」 と書いてあったら？メッセージが出ているのだからテストに合格したと判断するのはダメ。 仕様もテスト項目も確認しないでリリース直前に「これおかしくないですか？」とかドヤ顔言うやつは、自殺すべき。 3.ユースケースは能動態で試験項目
テストケース仕様を書いてみよう！！ | Ques
今回このブログを書かせていただきます、 ヒューマンクレストの高橋です。 私の担当する回ではテストに関するTipsをいろいろ書いていきます。 前回は 第一回目として、テスト設計の「テスト要求仕様」作成のフェーズにスコープを充てて書いてみました。 今回はその続編として、「テストケース仕様」にスコープを充てて書いていきます。 前回のテスト要求仕様書で定義したテストケースを具現化していくことにより、テストを効率的に実施し、バグを検出する事を助けることが、テストケース仕様書の目的になります。 私が考えるテストケース仕様書の記載必要内容は、以下の内容を想定しています。 （なお、テスト結果も同時に記入を行える「テスト結果一覧」も兼ねています。） ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ①テスト実行環境の明確化 テスト実行時の環境を明確にします。 テスト実行時の環境に
テスト仕様書の作り方大公開：テスト設計の手順とセオリー - ソフトウェアテスト.com
みなさん、こんにちは。 以前の記事「テスト仕様書サンプルあり。高品質なテストを実現する方法」では、ソフトウェアテストを行う上で必要な基礎知識をコンパクトにまとめた『テスト入門ハンドブック』をご紹介するとともに、テスト仕様書のテンプレートを提供しました。 以前の記事はこちら 先の記事でも述べましたように、フォーマットは道具であって目的ではありませんから、ただ記入欄を埋めただけでは意味をなさないことは言うまでもありません。大事なのは「何をどのように検証するのか」を正しく誰にでもわかるように記述することです。 「テスト仕様書を作れと言われたけれど何をどう書いたらいいのかわからない」「テストケースに抜け漏れがあり、テストをしてもバグが残ってしまう」といった悩みをお持ちの方に向けて、今回から『テスト仕様書の作り方大公開』と題して７回にわたって連載いたします。 まず初回は、フォーマット記入に先立って「
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
わかりやすいマニュアル・手順書を書くための7つのポイント - 小さい頃はエラ呼吸
photo credit: pierofix via photopin cc はじめに togetterでとても共感できるツイートを見つけました。 わかりやすいチェックシートを作る為には - Togetterまとめ SEの仕事をしていると自分以外の人のために手順書を作成したり、逆に他の人が作った手順書を見て作業を行うことが多々あります。 わかりやすいマニュアル・手順書を書くためのポイントを自分なりの解釈でまとめてみました。 図解 ミスが少ない人は必ずやっている「書類・手帳・ノート」の整理術posted with amazlet at 14.01.26 サンクチュアリパプリッシング 売り上げランキング: 1,080 Amazon.co.jpで詳細を見る １．作業の目的を必ず明記して作業者に伝える 手順書の冒頭には、作業者に作業の目的を理解してもらうため、"この作業の目的は何か"を必ず書くよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
