MOONGIFT: » ネットワーク図を簡単に描ける「Network Notepad」:オープンソースを毎日紹介
ちょっと懐かしめの、それでいて現役で役立つソフトウェアの紹介だ。 オフィスのLAN配線図や、Webサービスのサーバ配置図を作る際にネットワーク図を作ることがある。Microsoft Visioがあれば良いが、高価なソフトウェアだけに全員分は難しい。とは言え、単なる四角などではちょっと雰囲気が出ないので寂しいだろう。 ネットワーク図を簡単に作成する そこで使ってみたいのがNetwork Notepadだ。Windows向けのフリーウェアで、ネットワーク図を作成するのに必要な機能およびアイコンが多数登録されている。 Network Notepadは各種オブジェクトを配置して線で結んだり、水平線を引いたりしてネットワーク図を作成するためのソフトウェアだ。もちろんオブジェクト同士をつないだ線は、オブジェクトの移動に合わせて長さが変わるようになっている。 多数のオブジェクトが存在する IPアドレスを
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
