GoogleがプロトタイピングツールPixateを買収。無料化される。オススメ。 | fladdict
Googleが、ローカルベースのプロトタイピングツールPixateを買収した模様。以後、Pixateアプリは無料となり引き続き開発が続けられるようです。 2013年頃、Pixateに$600払ってた俺は泣いた。おめでとうございます。 Invisionを主流に百花繚乱の分断化で割と困っていたプロトタイピング業界。Googleがこの分野に手を出したことで変動は起きるのだろうか。 これがプロトタイピングツールの決定版になるとよいですね。高性能だし無料だし。クラウド版も$5だし。 日本でプロトタイピングサービスばパッとしない究極の問題は、サービスがオンラインのことなんですよね。SI系の人たちは「セキュリティ的な事情でオンラインの共有サービスを使えない」という事情がありました。Pixateはローカルアプリなので、その辺の心配をする必要がないのがポイントですね。そのうち大手SIとかでもこういうツールが
要求交換フォーマット(ReqIF)を調べてみた。(1) - たこはちの「へのかっぱ」日記
OMGが公開している要求交換フォーマット(ReqIF:Requirements Interchange Format)について調べてみた。以下のURLからダウンロードしたReqIFの仕様書を読んでいるところだ。2011-04-02にリリースされている。 http://www.omg.org/spec/ReqIF/1.0.1/ 以下の記事も参照のこと。 (1) ReqIFの3つのユースケース (※この記事) (2) ReqIFの8つの機能 (3) ReqIFの再利用性、RIFとの差異 (4) ReqIF/RIFの動向 (5) ReqIFフォーマットの構造 (6) ReqIFでの代替IDとアクセス制限 ReqIFは、要求を記述したファイルをXMLの統一規格で定義して、企業間やツール間で扱いやすくしようというものだ。これまで「要求仕様」は、WORDやEXCELで記述したり、リーズナブルなツールな
【コラム】"本当の顧客要求"のつかみ方 (1) シナリオをもって臨む | 経営 | マイコミジャーナル
最近の企業システムについての相談は、単に「○○の機能がほしい」という要求ではなく、例えば「顧客からの問い合わせ対応のレベルを高めたい」とか、「トレーサビリティを確保したい」のようなビジネス的課題の表現で話が始まることが多い。 つまりは、当たり前のことをやるシステムはすでにあるのだが、求めているものは次の次元の話というわけである。そういう課題はつめてみると、業務の歴史的経緯や既存のシステムのさまざまな制約が絡まって面倒なことになっていたりするので、業務的な整理や改善と合わせてシステム的対応を考えなければ解決ははかれない。 こうした課題解決をはかるプロジェクトの企画プロセス(筆者らは、「要求開発」と呼んでいる)は、まさに道なき道で、「言われたものを言われたとおりに作ってきた」システム屋にはまず手が出せない。 ビジネス上の課題解決をはかるプロジェクトの企画プロセスは、道なき道を行くようなもの か
要件定義の勘どころ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
システム企画に役立つ概念データモデル作成の基本
概念データモデルの構成要素 概念データモデルは、システム化対象範囲にある業務プロセスをモデル化したもので、これを見ただけで企業のビジネス活動が分かるという大きなメリットがあります。図1の販売活動に焦点をあてた概念データモデルを例に、この企業の販売活動を読み解いてみましょう。 概念データモデルは「ハイレベルエンティティ」（図1緑色枠）、「識別子」（図1青色枠）、「リレーションシップ」（図1赤色枠）の3つから構成されます。 エンティティとそれを捕捉する識別子 まず、概念データモデルは企画段階で作成するものであるため、システム化対象範囲にあるデータ群を簡易的なレベルで表します。このデータ群が「ハイレベルエンティティ」（本稿ではエンティティと略記します）です。 これらエンティティを顧客コードや商品番号のような「ｘｘコード」、「ｘｘ番号」という「識別子」から捕捉します。 イベント系エンティティ、リソ
いまさら聞けない要求管理の基本
なぜ、要求を管理する必要があるのか なぜ、要求を管理するのでしょうか？ 一言でいうと、要求を管理することが、プロジェクトの成功を大きく左右するからです。まず、一般的なプロジェクトのゴールを考えてみましょう。次のような定義を見てください。 「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか？ プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならな
要求分析に表れるソフトウェア技術者の心
要求分析に表れるソフトウェア技術者の心：上を目指すエンジニアのための要求エンジニアリング入門（3）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 在庫調整が進んだので生産増、景気回復が望めるとの一部報道がある。しかし、経済環境は相変わらず厳しい。 とはいえ、ソフトウェア開発を糧にして生きるには、ソフトウェアの開発需要が必要である。需要の提供者、中でも業務システムを必要とするユーザー企業、およびソフトウェア製品やソフトウェアを組み込んだシステム機器ベンダの多くは急激な収益悪化に直面し、コスト削減を迫られている。こんな時期には、収益向上あるいはコスト削減に効き目があると期待できるソフトウェアやシステム
BPMを正しく理解するために－要求定義と要件定義 (mark-wada blog)
経営とITの同期を議論していくと、経営の要求をどうITに反映させていくのかとう問題が出てくる。ここの議論での焦点は、「要求定義」と「要件定義」の違いである。 米国ではこの前者の「要求定義」のための「要求工学」というのがしっかりとあるというのは一色教授の話にもあった。「要求工学」というのは要求獲得―要求仕様化―要求検証―要求管理というサイクルを工学的にやろうという動きである。 日本にも要求工学はあることはあるし、要求開発というコンソーシアムもあるのだが、概して、「要件定義」に寄っている。どういうことかと言うと、システム化するための要件、システムとして備える要件に持っていってしまうということである。 そうなると端的にいえば、システム化できる業務だけに限った要求になってしまう。この時点で、経営とITの乖離が起きる。経営戦略の達成は何もIT化できる業務だけでできるわけではなく、手作業やコラボレーシ
現行システムの見える化，どうしていますか？
多くの企業において，現行システムのブラックボックス化が進んでいる。ここで言う「ブラックボックス化」とは，システムが大規模化・複雑化してプログラムの構造やロジックが不透明になることを指す。プログラムの度重なる改修や，ドキュメントの不備，担当者の退職など，システムがブラックボックス化する理由はさまざまだ。しかし，それにより新規・保守開発の調査工数が膨らんだり，予期せぬ障害を招いたりするケースが後を絶たない。 こうしたこともあって，システムの見える化は開発・運用現場が抱える大きな課題の一つになっている。記者は取材を通じてそれを痛感し，日経SYSTEMSの2008年11月号で「現行システムの見える化」に関する特集を担当することにした。ここでは，現行システムの見える化に悩む現場の実態を紹介するとともに，本テーマについて皆さんのご意見をぜひお聞きしたいと思っている。 しわ寄せは現場にくる 「見える化す
要求開発とコタツモデル(2)－－アンチパターンを活用する
前回は，要求開発・要件定義フェーズを成功させるためのポイント「コタツモデル」についての説明を行いました。「コタツモデル」とは，ITシステム開発プロジェクトにおける，主要な三つのステークホルダーの関係性を表すメタファーです。 ビジネス戦略を決定するビジネス・オーナー（経営者や高位の責任者），実際のビジネスを遂行しているユーザー（現場担当者），そしてシステム開発担当者の三者によってシステムの目標を決定する＝一つのコタツに入って議論する状況を，要求開発アライアンスでは「コタツモデル」と呼んでいるものです。 今回は，具体的な「コタツモデル」形成のテクニックの一部についてご紹介したいと思います。 「コタツモデル」形成に王道なし，アンチパターンの活用 「（要求開発・要件定義などの）上流工程は異種格闘技戦である」──これは筆者の持論です。ITシステム開発の下流工程，すなわち設計・プログラミング・テスト・
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ビジネス要求の急激な変化に対応する開発プロセスとは？