電話なし、企画書なし！アイデアがみるみる形になるオフィス：日経ビジネスオンライン
こんにちは、エバーノート日本法人会長の外村仁です。今回は原稿執筆中のフィル・リービンCEOに代わって、連載の代役を務めさせていただきます。 もしかすると、ご覧になった方もいらっしゃるかも知れませんが、先日の日経ビジネスオンラインの別コラムで、シリコンバレーにあるエバーノートの新オフィスについて少し紹介しました（「グーグルが社食をタダにする理由」）。 シリコンバレーのネット企業がこぞって快適なオフィス作りや福利厚生にこだわっている様子と、その真意を解説したのですが、この記事が予想以上の反響をいただいたようで、編集部から「エバーノートのオフィスを紹介して欲しい！」とリクエストをいただきました。そこで、今回は、私たちの新本社をご紹介したいと思います。 1人のイノベーティブなアイデアが、世界を変えるようなサービスに化ける可能性がある今、いかに社員のひらめきを誘発する環境を作るかが、シリコンバレーの
システム設計日記
テスト駆動開発 和田卓人(t-wada)さんによる『テスト駆動開発』の新訳版が出版されました。 オブジェクト指向でソフトウェアを開発するのであれば、この本とマーチンファウラーの『リファクタリング』は必読書だと思います。この古典ともいえる『テスト駆動開発』が和田さんの手によって新訳版として復刊されたことは、ほんとうにすばらしいことです。 この本が出版された経緯と、和田さんはじめ関係者の方々のご努力については、和田さんの、このブログをぜひ読んでいただければと思います。 新訳版『テスト駆動開発』が出ます 新訳本は、単に原著が日本語で読めるようになっただけではありません。和田さんの手によって、原著にはない新たな価値が付け加えらました。 一つは、サンプルコードの工夫です。 できるだけ省略はしない変更箇所を目立つようにした各章末にその時点での全コードを記載する これらの工夫により、本に書かれた内容が、
【ICONIX】 まずは、ドメインモデリングから始めよう( ･`ω･´)ﾜｯﾌｩーｗ
以前、友人たちとチーム開発をやった際に ICONIXプロセスを導入して、ユースケース駆動開発を実践したことがあります。 それから数年、使わないと人間忘れてしまうものですね・・orz 『やべぇ、ユースケース図がほんとにコードになった！ｗｗ』という感触を思い出し、後で復習出来るようにするため、 記録をつけながらもう一度実践してみたいと思います (`・ω・´) ﾜｯﾌｩー ではまず、プロジェクト(と言っても今回一人ですがｗ)の用語集にあたるドメインモデルを作りたいと思います。。 要求事項から名詞を抽出顧客などから出してもらった要求記述から、出来るだけ現実世界にある名詞(オブジェクト名)を抽出します。 内容 例
ICONIX « ツール工房 覚書
ICONIXプロセスとは開発プロセスの一つです。ユースケース駆動のプロセスであり、分析と設計のギャップを埋める「ロバストネス分析」を行うことが特徴です。 ICONIXプロセス：http://ja.wikipedia.org/wiki/ICONIX 今回は、ICONIXプロセスを用いてHSMS通信ソフトをモデリングしてみました。 ドメインモデル まず要求リストを基にドメインモデルを作成します。 （接続と送受信が出来ることを目指します。） ドメインモデルは分析麻痺に陥らないように2時間以内で作成します。また、この先のユースケース図、ロバストネス図で見つかった新しい用語は随時ドメインモデルに反映することが大切になります。が、今回はドメインモデルの更新が疎かになり、シーケンス図作成後まとめて更新となりました。更新する機会を設けなかったこと、また更新担当者を割り当てなかった事が原因だったと思います。
Xプレーン - Wikipedia
この項目では、アメリカ合衆国が開発した実験機・記録機シリーズについて説明しています。フライトシミュレーションゲーム『X-Plane』については「X-Plane」をご覧ください。 最初のXプレーン、ベルX-1 Xプレーンは、アメリカ合衆国が開発した実験機・記録機シリーズのこと。名称が実験機・記録機を意味するXで始められていることから、Xプレーン（X plane: planeは飛行機の意）と呼ばれるようになった。その性格上、製造機数は少ないが多様であり、特異な外形を持つものや、世界記録を更新するなど優秀な性能を示すものも作られた。 概要[編集] 最初のXプレーンは、1946年に製作されたベルX-1である。これは、音速を突破するために造られた機体であった。これ以降もアメリカ航空宇宙局（NASA）、空軍、航空機メーカーを中心に開発されている。 高速性の追求においては大きな成果を挙げている。たとえば
要求仕様の決定に時間を割かない結末は？
次のような話を聞いたことはあるだろうか？ 「要求仕様をまとめる時間がない。すぐにコーディングに取り掛からないと納期には絶対に間に合わない」 このような話（よく聞く話だが）は、個人もしくはチームの考え方や成熟度を測るための重要な手掛かりになる。要求仕様をまとめる時間がないという言葉が出てくるのは実際にはどういうときであり、どのような意味があるのだろうか？ 本稿で詳しく見ていこう。 「要求仕様」という単語には多くの定義があり、メソッド、プロセス、方法論、そして専門家ごとにそれぞれ固有の解釈があるようだ。しかし、要求仕様はそのプロジェクトが何を構築し、提供するのかを明確に記述すべきである、との点ではだれも異論はないはずだ。もし上述の話の中にある要求仕様という言葉をこの簡単な定義で置き換えると次のようになる。 「構築および提供すべきものの内容をまとめている時間がない。すぐに……」 このようなことを
モデル推敲に有効な手法を紹介する
前回（「正しい設計と理想的なモデル」）は、「良い設計モデルとは何を意味するのか？」「どうすれば良い設計モデルを作ることができるのか？」について、概念的な話をさせていただきました。何となくイメージしていただけたでしょうか？ 簡単にいってしまうと「できるだけ、分かりやすくて、拡張性や保守性がある、開発しやすいモデル」が「良いモデル」であって、そのモデルを作るために、「オブジェクト指向技術の抽象化やカプセル化をうまく使って、積極的に依存性を排除し（モジュール間の独立性を高め）、シンプルなモデルに仕上げていきましょう」という話になります。しかし、実際は、「言うは易（やす）く行うは難（かた）し」です。今回は、「どうすれば、良い設計モデルに近づけるか？」という具体的な話をしていきたいと思います。 「分析モデル」から「設計モデル」へ 前回解説した「CRC分析法」や「名詞・動詞分析法」、もしくはドメイン・
ICONIX - Wikipedia
この項目では、ソフトウェア開発方法論について説明しています。韓国のアニメ会社については「Iconix Entertainment」をご覧ください。 ICONIX（アイコニクス） は、ラショナル統一プロセス（RUP）、エクストリーム・プログラミング（XP）、及びアジャイルソフトウェア開発よりも前から存在するソフトウェア開発方法論である。RUPと同様にICONIXプロセスはUMLのユースケース駆動であるが、RUPより軽量である。XPやアジャイルのアプローチとは異なり、ICONIXは十分な要求と設計のドキュメントを作成するが、分析麻痺にはならないようにする。ICONIXプロセスは、4ステップのプロセスでただ4つのUML図を使用して、ユースケース記述を動作するコードに変換する。 ICONIXを他と区別する特徴は、要件定義と詳細設計のギャップを埋める方法であるロバストネス分析を使用することである。ロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
20 Terabytes a Night
エバーノートCEO シリコンバレー流を大いに語る！：日経ビジネスオンライン
IconixProcess.com is for sale | HugeDomains
http://stream.edubase.jp/packages/view/27
http://stream.edubase.jp/packages/view/11
http://www.iconixsw.com/index.shtml