タグ

仕様と開発に関するdenkenのブックマーク (4)

  • と~く2ちゃんねる - Talk 2ch

    と~く2ちゃんねる 最終更新日: 2003/09/03 Samba24 2ちゃんねるとお話するための方法をまとめたメモです。 ※このページはコミュニケーションサイトではありません! 目次 最新情報 基 読み 書き その他 おまけ - rawモード 2ちゃんねるの仕様は日々変わっていくので、ここに書いてある情報は古いかもしれません。 もし、間違え・仕様変更などがあれば掲示板の方へ書き込んで教えてくれると非常に助かります。 最新情報 Samba24という規制が始まった模様。(8月下旬~) 基 2chの漢字コードはShift-JISである 接続先ポート番号はもちろんTCPの80番になります スレッドのURLがhttp://news2.2ch.net/test/read.cgi/newsplus/1000000000/ならば ホスト名: news2.2ch.net 板キー: newsplus

  • HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方

    HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,

  • 「JAVA村」と「Perl村」の断絶がもたらすのは不幸なのか幸せなのか – 音極道茶室(旧アーカイブ)

    私も1月15日にブクマした「業務経歴書にPerl案件を書くと馬鹿にされる件」に関するessaさんの言及に対して、ちょっと反応しておこうと思う。 「JAVA文化Perl文化の断絶」については、essaさんの記事と、そこからリンクされている記事でほぼ語りつくされてるのだが、「この問題の根の深さ」について少し別の視点から語っておきたい。 Java文化Perl文化の断絶について語られる時、それはほとんど「開発者側」の視点からなのだが当に深刻な断絶はそこよりも、「マーケット」の断絶だと思う。 世のシステム系企業を「JAVA村企業」と「Perl村企業」に分けた場合、当然どちらの企業にも「クライアント」が存在する。ところが、JAVA村企業とPerl村企業が1つのクライアントに対して競合するような場面というのは極めて稀で、「ビジネスマーケット」そのものが交わる事無く分断されているのだ。 ちょっと乱暴

  • ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― @IT情報マネジメント

    プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基的なチェックポイントを紹介する(なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい)。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物(ドキュメント)を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 (1)題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”

    ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― @IT情報マネジメント
  • 1