Information Architecture Institute > Learning IA - Information Architecture Institute:
We’re currently in the process of migrating our library to the new Drupal system, but in the meantime we’ve made the content available via Google Documents. Our library is the largest expertly-curated, information architecture-specific library in the world, including articles, tools, templates, podcasts, and a full listing of all the books one could ever need to get to the next level of their IA p
セレナビジネスマッシュアップについて
Knowing what has changed in a software environment is as critical today as it was in 1980 when Serena began. From the very first product Comparex, to the Release Management and Deployment Automation solutions, Serena focused on managing every facet of IT change. These products are depended upon daily by global organizations to develop and deliver their critical business systems so they can “move f
escafeFlowEditor
escafeFlowEditorとは、escafeFlow専用のxpdlエディタです。 escafeFlow用のxpdlファイルは、JaWEやJPEdといったxpdlエディタで編集できます。しかし、それらのエディタはxpdlの全ての編集ができるように多機能になっています。escafeFlowはxpdlの一部のみを使うので、慣れないうちは操作に迷うかもしれません。 xpdlのうちescafeFlowで使う部分だけを簡単に編集できる専用のエディタとして、escafeFlowEditorを開発しています。残念ながら、現在のバージョンではescafeFlowの全てをサポートできていません。今後のバージョンアップで少しずつ対応していきますので、ご期待ください。 ソースコードはSubversionのリポジトリに入っています。 https://www.escafe.org/svn/escafeflowe
ユーザーと共通理解できる“システム観”が必要だ － ＠IT情報マネジメント
企業システム開発では、しばしばユーザーの思いどおりのシステムに仕上がらないことがある。その大きな原因の1つが、ユーザーの“要求”と開発者の“理解”のズレだ。ユーザーと開発者が共通認識にたどり着くには、何が必要だろうか？（→記事要約<Page2>へ） 業務システム向けの分析設計技法としてさまざまなやり方が提唱されています。有名なところがUMLを用いた「オブジェクト指向分析・設計手法」です。しかし、開発現場で実際に利用されているのは、昔から無批判に繰り返されてきた古めかしいやり方だったり、せいぜい「UMLもどき」とでもいえそうな案件ごと独自に「工夫」されたやり方です。 UMLは、バラバラだったオブジェクト指向系の表記法を統一するための体系として鳴り物入りで登場しましたが、必ずしも当初の期待どおりの効果を挙げているわけではありません。それは、システム開発においてボトルネックになっているのが「シス
非機能要求記述ガイド
経済産業省 ソフトウェア開発力強化推進タスクフォース 要求工学・設計開発技術研究部会 非機能要求とアーキテクチャWG 概要 非機能要求とアーキテクチャWGは、2007年度活動として、非機能要求の効率性と回復性に絞って非機能要求記述フォーマットの定義、及び非機能要求とそれを実現するための実現手段の関連性を分析しました。また、定義した非機能要求記述フォーマットの有効性の確認や改善点をフィードバックすべく、フォーマットを利用した記述方法の検証を実施しました。これらの結果をまとめた「非機能要求記述ガイド」が完成しましたので、ここに公開します。
発注者ビューガイドライン - 情報処理推進機構：ソフトウェアエンジニアリング
要求・アーキテクチャ領域「機能要件の合意形成技法WG」の検討成果の前身となる発注者ビューガイドラインを公開します。 機能要件の合意形成技法WGでは、2006年から2007年にかけて活動が行われた「実践的アプローチに基づく要求仕様の発注者ビュー検討会」（以下、「発注者ビュー検討会」といいます）の検討成果物である「発注者ビューガイドライン」をベースに検討活動を行います。 WGの本格活動に伴い、IPAでは発注者ビュー検討会の参加企業9社(株式会社NTTデータ、富士通株式会社、日本電気株式会社、株式会社日立製作所、東芝ソリューション株式会社、株式会社構造計画研究所、日本ユニシス株式会社、沖電気工業株式会社、TIS株式会社)から発注者ビューガイドラインの譲渡を受けましたので、それを公開します。 ※なお、発注者ビューガイドラインは改訂を行い、機能要件の合意形成ガイドとして2010年3月に公開しました。
高可用性データ同期アーキテクチャ：CodeZine
各種のデータベース管理ソリューションは、それぞれ異なるデータ同期メカニズムを使用しています。Sybase iAnywhereの同期ソフトウェアである「MobiLink Synchronization」は、拡張性の高いセッションベースの同期システムを持ちます。このソフトウェアを利用することで、統合データベースと呼ばれるメインデータベースと多数のリモートデータベース間のデータ同期が可能になります。統合データベースにはいくつかのODBC規格のデータベースを使用でき、例えばSQL Anywhere、Sybase Adaptive Server Enterprise、Oracle、Microsoft SQL Server、IBM DB2などが使用できます。
マルチコア時代のサーバ設計について - Happy Hacking Diary
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
Welie.com - Patterns in Interaction Design
A Pattern Library for Interaction Design This site contains a lot of best practices in Interaction Design. Over the years I have collected examples and insight on their applicability that I share with you here on this. So there is really no 'original' design to be found here, sorry. It has all been done before... See it as a reference or basic 'toolkit' you can use when design user experiences. It
RailRoad diagrams generator
RailRoad is a class diagram generator for Ruby on Rails applications.RailRoad is a class diagrams generator for Ruby on Rails applications. It's a Ruby script that loads the application classes and analyzes its properties (attributes, methods) and relationships (inheritance, model associations like has_many, etc.) The output is a graph description in the DOT language, suitable to be handled w
設計レビューをどうはかるか：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
設計ドキュメントのレビューの効率や効果を測りたいが、どうやってはかればよいかわからない。という質問を受ける。最初はレビュー指摘件数やドキュメント量で指摘数を割り算したレビュー密度として定量化するのが一般的ではないだろうか。現実には、指摘の内容が誤字脱字の指摘だけだったり、参加すべきメンバが参加していないレビュー等、このメトリクスだけでは頼りない。 自分の開発経験も含めて、以下を勧めている。理由は説明が比較的簡単であることと、それなりの効果が出そうに思うからである。（残念ながらエンピリカルな検証は計画段階にあり未実施である） レビュー前に実施しておくべき作業の定義と実施の有無 レビューのperspective数（役割分担数）とperspectiveに沿った指摘の数 指摘重要度の分類（軽微、重大、どちらでもない） 指摘内容の分類（正常系、異常系、非機能） 指摘対象機能/サブシステム 1は、まず
適切なアジャイル性を実現するアーキテクチャ (arclamp.jp アークランプ)
先日、憧れのITアーキテクトと「アジャイル・アーキテクチャ」について議論。きちんと理想と現実と捉えていて、さすがという感じでした。 アーキテクチャ自身がアジャイルなわけではない まず言われたのが「アジャイルなアーキテクチャ」といってしまうと、アーキテクチャ自体がアジャイルに変化するというミスリードをするのではないかという点。確かにそうですね。広義のアーキテクチャというのは全体性を決定する思想・概念であり、それ自体がアジャイルに変化することが求めることはあまりないと思っています。狭義のアプリケーション・アーキテクチャに変更が求められる場合はありえますが、それすら広義のアーキテクチャには織り込み済みであるべきです。 では、僕らが考えるアジャイル・アーキテクチャとは何か。それは"適切なアジャイル性を実現するアーキテクチャ"と定義できそうです。 ここで出てきたのがアーキテクチャの結合度、可変性分
プログラマの思索: RubyよりもJavaが好きな理由
最近、Ruby関西に行ってRubyの勢いを感じている。 そんな時に、Javaの最近の動きを聞く機会があった。 Java6やSeasarの話を聞くと、JavaがC#やRailsの影響を受けているように聞こえた。 でも、話しているうちに、「やっぱりRubyよりもJavaが好きなんだ」と気づいた。 その理由は、「JUnitのようなテスト駆動ツールが揃っている」点に尽きる。 そこで「テスト駆動の観点から眺めたJavaの利点とプログラミング思想」について考察してみる。 【１】テストを意識するとメソッドの行数が自然に短くなる プログラミング初心者のプログラムを見ると、行数がやたらと長く、長いプログラムを書き上げた後からデバッグし始める。 だから、いつまで経っても動かない。 プログラミング中級者になると、行数は長いままだが、少しずつ書いてはプリント出力してデバッグで動作を確認し始める。 この
Do not set yourself on fire ...: API Design Guidelines
Some random thoughts and (vaguely) interesting things I see or do. I keep getting back to some references on the best practices for C++/Java API design so I decided to summarize them all here for future reference. General design guidelines Be minimal: A minimal API is one that has as few public members per class and as few classes as possible. This makes it easier to understand, remember, debug, a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
経路のセキュリティと同時にセキュアなセッション管理を：IPA 独立行政法人 情報処理推進機構
「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZine
http://www.flashfloorplan.com/index.php
シオンの建築ＵＤ評論
勝ちにいく！ソフトウエアテスト---目次：ITpro
