要求仕様書について
「要求仕様書」の必要性は、多くの人が認めているにも関わらず、実際には殆ど書かれていません。仕様を意識していることは、プログラムのバグの原因分析において、「仕様モレ」や「仕様の勘違い」といった項目で集計されることからも分かります。でもそこまでです。 開発組織によっては、それに代わるものとして「機能仕様書」と呼ばれるものが書かれていることがありますが、その場合、内容は当然のことに「機能」に限定されます。残念ながら「機能」だけでは要求を満たすのに十分ではありません。「品質」も製品を構成する重要な要素です。また、機能仕様がどうやって抽出されたかが問題です。 多くの開発現場で遭遇する混乱のおおもとは、殆どが「要求仕様書」の不備に起因しているのです。一体、「要求仕様書」にはどんな役割があって、どのようなところに注意して書けばよいのか。 また、よく分からないものとして「要求」と「要求仕様」の違いにつ
昔から思うのですが、マイクロソフトの日本語表記ルールは実に奇妙です。現在は、広く一般に公開されていますので、ぜひ目を通してみてください。 まず、マイクロソフトは世界中の多くの言語をサポートすることを強調しています。そのためのポータルサイトも設置されています。しかし、そのサイトの日本語名は「マイクロソフト ランゲージ ポータル」。「ランゲージ」という言葉は決して一般的な用語ではありません。「ポータル」が一般に通じるかどうかも怪しいものです。各国の言語を尊重しているようにはとても思えません。 ちなみに、フランス語サイトもスペイン語サイトも、最初のパラグラフに登場する英語は「Microsoft」だけです。なお、かなに相当する文字を持つ言語はどうだろうと思い、韓国語サイトを開いてみましたがハングルは読めませんでした。 次に、各言語のスタイルガイドを見てみましょう。一覧の中で、私が知っている言語は日
OPS 2.0 v1.0 日本語訳 [Open Publication Structure (OPS) 2.0 v1.0]
See related links to what you are looking for.
何を使って、共同で仕様書を書こうか
ソフトウェア開発の仕事を請けるとき、すぐに開発を始められるような仕様が提示されることは、ほとんどない。発注側がそんなものを用意できるなら、私に依頼せずに、クラウドソーシングを使うほうが費用対効果が高い。仕様を策定するのも込みで、なんなら要件を発掘するところも含めて、仕事が依頼される。 問題解決をしながらのものづくりには、反復的な変更を伴う。顧客に問題ドメインの知識があり、こちらに解決手段の知識がある場合は、互いの共同作業になる。「こういうことですかね？」「ちょっと違うんだよねー。アレをナニする感じで」「こうやれば、いけるかも」「うは、それいい」みたいに。 仕様を記載したファイルを、厳密にキャッチボールできないときには、ひとつのファイルに対して、複数の人間が並行して変更することになる。プログラミングでは diff と merge というツールが活用できる場面である。仕様書を共同で作るとき、そ
HTML HTMLの仕様策定には複雑な歴史があります。詳細は他の解説記事に譲りますが、簡単に述べるとW3CとWHATWGのダブルスタンダード状態が長い間続いていました。2022年現在はWHATWGによってLiving Standardとしてまとめられた仕様が実質的な標準となっています。Living Standardという名前が示す通り、バージョンはなくエディターによって随時更新されています。 CSS CSSの仕様はW3Cが策定しています。現在は、CSSとして1つの標準仕様があるわけではなく、数多くのモジュールに分かれて標準仕様の策定が進められています。草案、勧告候補などを経て勧告に至るプロセスと、Levelという概念で整理されたバージョン管理が特徴です。年に1度、SnapShotとしてその時点での標準化の概況が公開されています。 JavaScript JavaScriptは主にWebブラウ
Supported media formats | Android media | Android Developers
Build AI experiences Build AI-powered Android apps with Gemini APIs and more. Get started Start by creating your first app. Go deeper with our training courses or explore app development on your own.
言語（API）Processingは、簡単に洗練された視覚や概念的な構造を創造できるようにデザインされている 他の外国語を選択 : 英語 この日本語リファレンスは旧バージョン(Alpha)用です。 Beta版リファレンスは英語サイトをご覧ください。日本語訳に関する質問はTetsu Kondoまで。 size() (サイズ) ; (セミコロン) = (アサイン) () (括弧) , (コンマ) // (コメント) /* */ (マルチラインコメント) void ボイド setup()（セットアップ） loop()（ループ） new（新規） {} (波括弧) [](配列アクセス) . (ドット) width（幅） height（高さ） framerate()（フレームレート） delay()（ディレイ） smooth()（スムーズ） noSmooth()（スムーズなし） cursor()（カー
EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。
wg:Maintainable CSS CSS を維持・管理していく上で、保守性の高い CSS を作成するにはどういったことを意識して作成するだろうか。上記サイトでは個人的な好みと前置きし、いくつかアイデアを述べている。コメント欄なんかでもちょっと盛り上がってて、激しく同意できる部分もあったりそりゃ違うなとか思ったりと、色々と考えさせられた。 CSS を作成する際に自分が考えること 自分でも改めてまとめてみると何か新しい事が見えてくるかもしれないし、コメントで何かヒントやアイデアを教えてくれる人も居るかもしれないなぁとか思ったんで、ちょっとまとめてみた（上記サイトと被ってるのが多いけど）。 CSS ファイルの肥大化を抑えるよう、作成中にボツになったスタイルは必ず削除しておく。頻繁にスタイルを変えるような場合は、指定する必要のないスタイルが残っていないかチェックする。 どれだけ些細な事でも、
Natural Docs
Natural Docs lets you document code written in any of 21 programming languages, plus it can be easily extended for more so whatever you use, it can too. And if your project uses multiple languages, no problem! It will all be included in the same set of documentation. Natural Docs also speaks your other language... English! Its comments are designed to be very natural and readable so they're jus
コミっくむｰび-
電子書籍を電子書籍ストアで買う場合、本を書店で買う時と同じように１冊ずつ買う場合とサイトによっては、定額で読み放題など様...
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「アート・オブ・プロジェクトマネジメント」読書感想文（その1）
最近、マネジメント系の仕事ばかり振られるようになったので、予習のつもりで一読 したが、これはスゴい。読んでる途中から振り返り読みを繰り返し、再読も再々読もしなければならないことに気づいた。本書で紹介されるアート（技芸）は、How to モノと大きく異なり、根っこから考え→実践に適用し→フィードバックが必要なものばかり。 あ、最初に結論を述べておくと、これは今年のNo.1スゴ本なり。ふり返ると「No.1スゴ本」の称号をいくつかの書籍につけてきたが、本書は間違いなくNo.1だと言い切れる。読み手の経験に応じ、必ず得るものがある。概要はamazon紹介文をどうぞ（太字はわたし）。 「ものごとを成し遂げるためには何を行う（あるいは行わない）べきか」という実用的な視点からプロジェクトを捉えて、ものごとを成し遂げるための考え方やヒントを、スケジュール、ビジョン、要求定義、仕様書、意思決定、コミュニケー
実践的アプローチに基づく要求仕様の発注者ビュー検討会
NTTデータ（国内事業会社） 企業情報 プロフィール 社長メッセージ 役員一覧 NTTデータのテクノロジー NTTデータグループ（持株会社） 企業情報 プロフィール 社長メッセージ Our Way 役員一覧 サステナビリティ 沿革 グループ会社 協賛・文化活動 取引先企業の皆様へ NTT DATA, Inc.（海外事業会社） 企業情報
本当は楽しいドキュメント作成
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 文書作りは好きですか？ 今回からこの連載を担当いたします、アクセンチュア・テクノロジー・ソリューションズの宮本和洋です。 システム開発プロジェクトでは、さまざまな文書が作られます。私の連載ではこの文書に注目し、「文書ドリブン開発」という考え方を紹介したいと思います。 文書ドリブン開発は私の造語です。「文書が作成されることにより、具体的な開発作業が進行していく」ことを意図しています。 多くのITエンジニアは、文書作りではなく、動くものを作ることに楽しさを見いだすと思います。その作業の楽しさの中には、システムの設計に悩み、動作実証実験を繰り返す楽しさも含まれているのではないでしょうか。「この仕組みでちゃんと動くかな～、どうかな～」と試してみることが、ワク
Kodougu - TopPage
Kodougu とは Kodougu とは、ブラウザ（Firefox/IE）上で動作するモデリングツールです。UML などのモデリング言語を用いたモデリングを、専用ツールをインストールすることなく、ブラウザ上で動作させることができます。また、Kodougu はウェブサイト（ホームページ、ブログ、wiki など）に貼り付けることもできます。 Kodougu の使い方は以下のチュートリアルを参照してください。 Kodougu チュートリアル Kodougu に関するアナウンスは以下の RSS で配信されます。興味のある方は、RSS リーダに以下の RSS を登録してください。 http://www.kodougu.net/p/kodougu/rss ニュース 2008-07-25 14:38 : [メディア掲載情報] InfoQ にて Kodougu の紹介記事が掲載
急がば回れ──質の良い仕様書の作り方
前回は、自社の業務に必要なシステムの要件の定め方について触れた。今回はその次のフェイズ──仕様決定について考えていこう システムの要件が決まったら、これを具体的なシステム仕様書に落とし込んでいく必要がある。システム仕様書とは、要件を満たすための具体的なシステムの機能・性能に対する要求事項を文書化したものだ。 ソフトウェアの場合、要件定義や仕様書の段階で発見された不備を是正するコストと、運用段階に入ってからのそれとでは、実に200倍の差があるという説がある。また、NASAの記録では、最初の20％の工程に、全体の作業時間の15％を投入することで、プロジェクトの成功確率が80％にまで高まるという。 「早く、安く、最小の投資で最大の効果を生むシステム構築をする」には、システム仕様書の作成に手を抜いたり、他人任せにすべきでない。「急がば、回れ！」である。 質の高い仕様書とは 要件を満足するための、必
PaulはUXのデザイナーでありデジタルトランスフォーメーションの専門家です。彼はユーザーを促進するためのウェブやソーシャルメディア、モバイルの活用を、非営利やビジネスの分野で手助けしています。 私たちUXデザイナーは、プロトタイプをよく使います。しかし、UXデザイナーにとって、クライアントや経営陣にプロトタイプが時間や経費に見合うものだと説得することはストレスです。この記事では、プロトタイプのビジネスにおける利益について説明していきます。 プロトタイプは私たちが自由に使うことのできるもっとも強力なツールの内の１つです。しかし、多くの人がプロトタイプはお金がかかるデザインツールだと思っています。そのため、プロトタイプは適切なツールだと思われません。 締め切りまでの期間が短く、予算が限られている場合プロトタイプは最初にカットされるものの１つであることが多いです。代わりに、企業は生産工程を短縮
業務システムの複雑膨大な設計情報を効率的に管理するために、Excelのような汎用ツールではなく、専用のCADツール（システム開発用の設計情報管理ツール）を使おう。そのように主張しているのだが、反応はさまざまだ。もちろんほとんどの技術者が賛同するのだが、所属組織にそれを導入できるかどうかになるとビミョーだったりする。 専用ツールを用いることの効果のひとつが、設計の巧拙がはっきりする点だ。スキルレベルの高い組織であればそれでいいだろうが、そうでない組織は現状維持を望むかもしれない。Excel方眼紙（細かい方眼紙状に設定されたExcelシート）で設計書を書くやり方は蛇蝎のように嫌われているが、それが設計の拙さを見えにくくするための隠れ蓑として役立っていることがある。彼らはExcel方眼紙がもたらす壮大な無駄を棚に上げ、「新たなツールを導入すれば、余計な学習コストがかかる。だいいち、ツールベンダー
Media Queries Level 3 W3C Recommendation, 05 April 2022 More details about this document This Version: https://www.w3.org/TR/2022/REC-mediaqueries-3-20220405/ Latest Version: https://www.w3.org/TR/mediaqueries-3/ Latest Editor Version: https://drafts.csswg.org/mediaqueries-3/ Previous Version: https://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/ History: https://www.w3.org/standards/history/
このウェブサイトは販売用です！ studyinghttp.net は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、studyinghttp.netが全てとなります。あなたがお探しの内容が見つかることを願っています！
フィードバックを送信 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 記事（Article、NewsArticle、BlogPosting）の構造化データ ニュース、ブログ、スポーツの記事のページに Article 構造化データを追加すると、Google がウェブページの詳細を理解し、Google 検索やその他のサービス（Google ニュースや Google アシスタントなど）の検索結果で、その記事のタイトル テキスト、画像、日付情報を適切に表示できるようになります。 トップニュースなどの Google ニュース機能の対象となるためのマークアップ要件はありませんが、Article を追加することで、コンテンツの内容（たとえば、ニュース記事であることや、記事の作成者とタイトルなど）を明示的に Google に伝えられます。 例 以下に、Article 構造
要件と機能の関連を保つテンプレート
品質の鍵は上流工程にあり SIer業界において、生産性向上は永遠のテーマです。そのための施策としてよく行われるのがドキュメントの標準化です。もちろん、弊社においても実践しており、その一環として業務システムの開発ドキュメント標準テンプレート「DUNGEON（ダンジョン）」を作成しています。DUNGEONは現場主体で作成しており、そのノウハウが凝縮されているのが特徴です。2005年に連載「即活用！業務システムの開発ドキュメント標準化」（http://www.thinkit.co.jp/free/project/4/1/1.html）にて紹介したところ、大変好評でした。 その後もこのDUNGEONは、現場で鍛え続けて進化しています。そこで、再度そのノウハウを「すぐに使えるテンプレート」として紹介することになりました。対象は業務システムをウオーターフォールで開発するSEを想定しています。今回は、そ
この文書について この文書は、内田明が家族用に作成しているWeb「ページ」づくりのテキストですが、第三者の方がお読みになっても構いません。まだ制作途上、中途半端な状態ですが、ご意見ご感想など頂戴できるとすごく嬉しいです。 という具合に、家族以外に読まれることがあると想定しているので、よそいきの文章になっています。 はじめに World Wide Webの「ページ」づくりは、文章や画像など「ページ」の元となる素材をつくる作業と、その素材を「マーク付け言語」の「文書型」に合うよう編制する作業、そして「スタイル言語」で出力の体裁を決める作業から成り立っています。 「マーク付け言語」というのは、「文章の中に『マーク（目印）』を挿入していくことで、文章を成り立たせている『見出し』や『強調語句』など各要素の役割や関係性を、ある型に沿って機械にも解るように記す際の語彙と文法」です。「スタイル言語」は、「
Web Audio API
This version: https://www.w3.org/TR/2021/REC-webaudio-20210617/ Latest published version: https://www.w3.org/TR/webaudio/ Editor's Draft: https://webaudio.github.io/web-audio-api/ Previous Versions: https://www.w3.org/TR/2021/PR-webaudio-20210506/ https://www.w3.org/TR/2021/CR-webaudio-20210114/ https://www.w3.org/TR/2020/CR-webaudio-20200611/ https://www.w3.org/TR/2018/CR-webaudio-20180918/ https
The Google Maps API V3 - Google Maps JavaScript API V3 - Google Code
Google Maps API Premier Same great maps plus a SLA, support, and control over ads Welcome to Version 3 Welcome to the release of version 3 of the Google Maps API. This JavaScript API will look similar to the existing version 2 of the Google Maps API. However, much has changed under the hood: Version 3 (called V3 within this document) has been designed to load fast, especially on mobile browsers
CSS2邦訳
Cascading Style Sheets, level 2 CSS2 Specification W3C 勧告 1998年5月12日 本版: http://www.w3.org/TR/1998/REC-CSS2-19980512 最新版: http://www.w3.org/TR/REC-CSS2 前版: http://www.w3.org/TR/1998/PR-CSS2-19980324 編者: Bert Bos <bbos@w3.org> Håkon Wium Lie <howcome@w3.org> Chris Lilley <chris@w3.org> Ian Jacobs <ij@w3.org> 概要（Abstract） この仕様はCascading Style Sheets, Level2（以下CSS2）を規定する。 CSS2は、文書作成者及びユーザが、HTMLやXM
パブリックコメント−経済産業省
当省では、情報システムを主に外注により調達しています。この場合、システム開発企業に当方の要求を的確に伝えるための媒体である外注仕様書が非常に重要なものとなります。この調達を適正かつ効率的に行うため、平成１４年度に行った「システム開発仕様書の作成における調査分析」（外注先：株式会社三菱総合研究所）を基に「システム開発に係る外注仕様書作成マニュアル（案）」を作成しました。 本マニュアルは当省の情報システム室が関与するシステム調達に使用することを主な目的としておりますが、今般、本マニュアルを取りまとめるに当たり、広く国民の皆様からの御意見をいただきたく、以下の要領で御意見（パブリックコメント）の募集をいたしますので、忌憚のない御意見をお寄せいただきますようお願い申し上げます。
大企業にありがちな問題。委託開発の甘い罠・・・
このところ、「大規模サービスを展開する企業が陥るジレンマ」 や 「本当に技術が必要とされる現場にgeekがいない」 で興味深い話が語られています。賛同する部分も多くあります。 さて、とある企業に勤める僕なのですが、最近手がけている仕事のやり方が非常に気にくわない部分がありまして、グチっぽいかもしれませんが思うところを記事にしてみました。他の企業の方々はどうなのかなぁ〜と思いまして。 それは、外注（開発の請負や業務委託等）って本当に必要なの？ってことです。特に大企業にありがちだと思います。 金融系や通信系といった真にミッションクリティカルな基幹系システムにおいては、その業界に特化した基盤やルールってのがあって、その専門的知識を有するソフトウェアベンダーへ開発を業務委託するってのは当然かと考えています。もっともソフトウェア業界で働く知り合いからは悲鳴しか聞こえてきませんが・・・。 僕が問題とし
今後、マニュアルを書いてメンテナンスも継続的にしていく機会が丁度ありそうなので、現時点(2012/05/02)でどのツールが自分たちにフィットするか検討してみた。ツールの候補は以下。なお、過去の仕事ではWordとDocBookは経験あり。 Word DocBook Sphinx ReVIEW 前提 今回のマニュアル作成の前提は以下の通り。 複数人で作業し、1つのドキュメントを作成する(主に章単位でアサイン)。 特定顧客向けに部分的にカスタマイズして提供することもある。 外部向けのドキュメントなので、体裁はそれなりに整っている必要がある。 製品のエディションによってマニュアル構成が変わる(上位のエディションだと機能が増えるので章や節、説明が増えるなど)。 出力フォーマットはWordまたはHTMLならOK。PDFは必須ではない。 ドキュメント中に画像はそれなりにある。スクリーンキャプチャ、構成
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
ここでは、はてなダイアリーの構造を少し詳細に解説しています。 そもそもCSSって何？ と云う方がいきなり見てもチンプンカンプンかもしれません。HTMLおよびCSSについては、以下のリソースが参考になります。 仕様書 CSS1の仕様書の原文(英語) CSS2の仕様書の原文(英語) CSS2の仕様書の翻訳(日本語) Ａ CSS2の仕様書の翻訳(日本語) Ｂ W3Cの仕様書等の文書の日本語訳集 リファレンス、バグ ごく簡単なHTMLの説明 スタイルシート1 - スタイル設定の方法 ばけらの CSS リファレンス CSSバグリスト＠CSSバグ辞典スレッド また、記述されたCSSが仕様に適合しているかどうか検証してくれるサービスがあります。 W3C CSS 検証サービス なにぶんミスの多い人間なので、誤字・脱字・不適切なマークアップ或いは完全な間違いなどの不備がありましたら、はてなの日記（Run,
要求仕様戦争（その2）
■要求どおりに動かない、書いたとおりに動く 「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。 「書いたとおりに作りました」 「書いてあることしか作っていません」 「書いてないことは作りこんでいません」 「書いてないことは何がおきるか分かりません」 つまり、メインルートから外れると何が起こるか（書いた本人も）分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。 あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆる
第4回 BNF記法入門（1） ─XML関連仕様を読むために─ W3Cの勧告として発表されているXML 1.0の仕様書は、XMLの構文を厳密に定義するためにBNFと呼ばれる記法で記述されている。XML関連の仕様書を読みこなそうとすれば、BNFの理解は不可避だ。今回はそのBNFを解説しよう。 ■話題 BNF記法 ■程度 C （XMLに関するひととおりの知識を持っている人を対象とする） ■目的 基礎的な知識の解説 この連載を初めてお読みになる方は、「XML深層探求について」をご覧ください。
政府機関のための Twitter 戦略テンプレート/Template Twitter strategy for Government Departments | PDF
英BIS作成の"Template Twitter strategy for Government Departments"の日本語訳です。オリジナルは以下のURLからご確認下さい： http://www.scribd.com/doc/17313280/Template-Twitter-Strategy-for-Government-Departments 簡単な解説はこちらに： http://blogs.itmedia.co.jp/akihito/2009/08/twitter-templat.html
翻訳者より この翻訳は Ecma International で標準化された C++/CLI の日本語訳です。 個人的な愛から始めた翻訳名ので、用語や言葉の使い方が正式に書式化されたものではなく、俗に言う「俺語翻訳」となっています。 また、英語力の不足から、怪しい翻訳部分もあるので、内容的に怪しいと感じた場合には、原文を参照してください。 Ecma の Mr. Jan van den Beld から翻訳の公開許可を頂きました。 注意 Disclaimer This is a translation of the authoritative text which Ecma published here http://www.ecma-international.org/publications/standards/ECMA-372.htm. This translated document
CSS Custom Properties for Cascading Variables Module Level 1 W3C Candidate Recommendation Snapshot, 16 June 2022 More details about this document This version: https://www.w3.org/TR/2022/CR-css-variables-1-20220616/ Latest published version: https://www.w3.org/TR/css-variables-1/ Editor's Draft: https://drafts.csswg.org/css-variables/ Previous Versions: https://www.w3.org/TR/2021/CRD-css-variables
戦場のガールフレンド:アルファルファモザイク
■２ちゃんねるまとめサイト ヘッドライン：「麻生・中山を若者が支持したり、…戦前のドイツ・日本の様で極めて危険」
沈黙のプログラマ - megamouthの葬列
プログラマと言えば寡黙、というイメージがある。 実際のところ、彼らは寡黙というよりはプログラム以外の話をするのが苦手なだけで、専門分野について話を始めると、こちらが驚くほど饒舌であったりもするものだが、アルゴリズムの計算量の話をしない普通の人間にとっては、無口な人に見えてしまうのも無理はない。 また、彼らは作業中に話しかけられることを嫌う。プログラムという作業は集中を要する仕事であって、その最中に電話や会話で作業が途切れると集中が切れてしまうからだ。作業中のプログラマに簡単な用事を口頭で伝えようとして露骨に不快な顔をされた経験のある方も多いと思うが、そのへんの自制心のなさもプログラマの特徴であるので、プログラマとはとかくコミュニケーションを取りにくいという印象がある。 しかし、システム構築においては、このコミュニケーションの不足が致命的な事態を招くことがある。 知り合い伝手で、その仕事の話
データベース設計はいつ、何をポイントに行うか
データベース設計はいつ、何をポイントに行うか：ゼロからのデータモデリング入門（4）（1/3 ページ） 前回までは、データベース設計の歴史的背景からデータベース設計の有効性までを解説しました。今回は、システム開発ライフサイクルと照らし合わせ、それぞれのフェイズで必要となるデータベース設計について、お話をします。 どの段階でどう設計すればいいのか 前回、データベース設計は自社のビジネス活動を理解している自社内の人間がやるべきであり、情報システム部門の存在意義を高めるために必要な技法であるとお伝えしました。しかし、システムの外部委託が多いというのもまた事実です。 筆者の職場では、お客様からデータモデリングに関するご相談をいただく際、最初に「貴社のデータモデルを拝見させてください」というお願いをします。システム開発を外部委託しているケースでは多くの場合、形として残っているのは「物理データモデル」で
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロソフトの日本語表記ルール | 日経 xTECH（クロステック）
HTML, CSS, JavaScriptの標準の仕様書はどこにあるのか
Processing 1.0 _ALPHA_ � Reference
ドキュメント力を強化したい人のためのマニュアルライティング入門講座一覧
Lucky bag::blog: 維持しやすい CSS を考える
プロトタイプがビジネスに利益をもたらす理由
「何を使って設計書を書いていますか？」と尋ねよう: 設計者の発言
Media Queries (W3C Recommendation 19 June 2012)
[Studying HTTP] RFC-Translations related HTTP
リッチ スニペットと構造化データについて - ウェブマスター ツール ヘルプ
https://www.ietf.org/rfc/rfc2616.txt
はじめてのWebドキュメントづくり
ドキュメント作成ツールの検討(Sphinx、ReVIEWとか) - wadahiroの日記
www.vdmtools.jp – このドメインはお名前.comで取得されています。
CSS Tips for はてなダイアリー：構造詳細
BNF記法入門（1） ─XML関連仕様を読むために─
C++/CLI 言語仕様書 - Standard ECMA-372
CSS Variables Module Level 1 (Editor's Draft)