SPEM2.0とは — metametaweb
OMG (Object Management Group) の SPEM 2.0 (Software Process Engineering Metamodel) の概略について解説します. SPEMは, 「ソフトウェア・プロセス」を表現する「モデリング言語」を定義するものです. 「ソフトウェア・プロセス」とは, 「ソフトウェアを作るやり方」ですね. ソフトウェアを作るときには (どんなやり方にしろ), 何かのプロセス (過程, 工程) を経ているはずです. 今まではソフトウェアを作る過程で重要視されてきたのは「どういうもの (プロダクト) を作るか」ということでした. ユーザの要求を満たすもの, 品質の高いもの, 保守のしやすいものを作れるかどうかということに関心が集まっていました. もちろんそれも重要ですが, 結局いいものを作るにはうまいやり方で作らねばだめだ, ということが1990年
BOMプロセッサの開発完了 - 設計者の発言
組立型生産管理システムのレファレンスモデル「CONCEPTWARE／生産管理」の実装版OSSの開発が快調である。お正月休みを経て「BOM（部品表）プロセッサ」が完成したのだが、これは生産管理システムの心臓部と呼ぶべき重要かつ高度なモジュールだ。これが無事完成したということは、開発基盤(XEAD Driver)が持つ要件対応力の高さを示す一定の証しでもある。一山越えた気分でひとり祝杯を挙げたのであった。 「BOMプロセッサ」には、品目、部品表、工程表といった生産基本情報の保守機能が含まれる。ただし、今回の元ネタである「CONCEPTWARE／生産管理」の基本設計においては「フィーチャ・オプション」による品目拡張仕様の管理方式がとられている。したがって、部品表や工程表をフィーチャオプションコードによってマスキングできるようになっていて、BOMプロセッサとしての仕様としてはより複雑である。 プロ
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - レファレンスモデル
「教材」としてのレファレンスモデル ＣＯＮＣＥＰＴＷＡＲＥ（コンセプトウエア）は、ＸＥＡＤで閲覧・編集可能な、「財務管理」や「生産管理」といった業務分野毎に提供されるレファレンスモデル製品です。なぜ、このようなものが必要なのでしょう。 当社が推奨する分析手法である三要素分析法は、ユーザーとの打ち合わせのその場でどんどんモデリングするという、効果的ではありますが設計者にとっては過酷な方法です。経験の浅いＳＥにはとくに難しく感じられるでしょう。 そのような場合、ＣＯＮＣＥＰＴＷＡＲＥを用いて業務分野毎の設計パターンを事前に学んでおくことをお勧めします。また、ベテランのＳＥであっても、ＸＥＡＤを用いて分析結果をとりまとめる際に、これらのライブラリーが役に立つでしょう。ＸＥＡＤの開発者自身がまとめたものなので、ツールが本来どのように利用されるべきかがよくわかるからです。 「第三の選択肢」と
Windows/Linuxで動作するシステムモデリングツール·Open System Architect MOONGIFT
システム開発において、初期段階のドキュメントはしっかりと作られる傾向にある。もちろんデータベースの正規化や設計も適切に行われる。だが運用が開始してから起こる修正や、追加開発についてはそれらがおざなりになる。 論理モデル そしてシステムというのは目に見えず、全体像の把握が行いづらい。そこでまずは現状を見える状態にしよう。使うのはOpen System Architectだ。 Open System ArchitectはWindowsやLinuxで動作するオープンソース・ソフトウェアで、GPLの下に公開されている。 Open System Architectは論理モデルと物理モデルの二つのモデリング手法に対応している。初期の開発からであれば論理モデルから落とし込んだり、逆に既にある場合は既存データベースからの構築機能があるのでそれを使って物理モデルからはじめれば良いのではないだろうか。 テーブ
【複雑化する製品開発を乗り越える】第12回 モデル展開を助けるCRCRカード
ユース・ケースから導き出される多くの機能を，非機能要件を考慮した上で，論理モデルや物理モデルに展開するのは容易ではない。時間が掛かるし，検討漏れや間違いも発生しやすい。そこで我々が勧めているのが「CRCRカード」を使う方法だ。
[設計編]ユースケースに詳細を書いてはいけない
機能要求を「ユースケース」（利用者＝アクターから見たシステムの利用場面）としてまとめ，それを基に分析設計することが一般化してきた。ところが「ビジネス・ルールを入れ込んだり，if～thenレベルのロジックまで書き込んだりと，誤った書き方をしている人が結構多い」と，日本を代表するITアーキテクトの1人，榊原彰氏（日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア）は指摘する。どんどん詳細化し，必要ない情報まで盛り込んでしまうのだ。 「詳細化しないと気が済まないのだろう。『分析麻痺（Analysis Paralysis）』と言える」と同氏。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進するチェンジビジョンの平鍋健児氏（代表取締役）も同意見。「画面レイアウトなど情報量が多過ぎることが結構ある。ユースケースはシステムの目的なのに，ユースケース＝機能と考えるからそ
上流工程－「ビジネスモデリング」を基本から理解する---目次
企業がビジネスの目的を実現するには、関係者が勝手な価値観や利害で行動するのではなく、事業目標を共有することが重要だ。そのためには、“ビジネスの見える化”を実現する「ビジネスモデリング」が欠かせない。ビジネスプロセス・モデルを作成する際の基本的な考え方や方法、作成したモデルの活用方法などについて解説する。 ・第１回 なぜビジネスモデリングが大切なのか ・第２回 ビジネスモデリングでは何をモデル化するのか ・第３回 どんな手順・手段でモデルを作るのか ・最終回 作成したモデルをどう生かすのか
UMLモデリングの基礎
ITエンジニアにとって，今やUMLモデリングのスキルは必須と言って良いでしょう。特に要求の妥当性を判断するため，システムの導入によって業務がどう変わるのかを可視化する上でモデリングは大いに役立ちます。 この講座では，RFP（Reruest For Proposal）の作成までに必要な，業務とシステムの分析について，UMLモデリングの基礎を解説します。Part1～Part2は「基本編」として，モデリングの意義や大まかな手順を学びます。その上でPart3～Part12において「演習編」として，中古車の買取・販売の業務を題材に，モデリングの実際を見ていきます。 なおこの講座では，基本的にUML1.5をベースした表記を用います。これを拡張したUML2.0が登場していますが，実際には大抵の場合UML1.5 で事足ります。UMLモデリングの基礎を学ぶ上では，シンプルなUML1.5を使う方が良いでしょう
Part2 モデリングの全体像――視点を分けて業務要求をとらえ，システム要求を論理的に導く
複雑な物事は，着目する視点を分けて単純化すると理解しやすくなります。まずは業務要求をとらえてから，論理的にシステム要求を導きます。業務とシステムを共通の視点で可視化し，全体の整合性を検証します。 Part1では，モデリングの意義や，そもそもモデリングとはどういうことかなど，モデリングに関する一般的なことを解説しました。 Part2では，演習編に向けての準備として，本講座で実施するモデリングの全体像を説明します。また，本講座では，モデリングの具体的な成果物として，RFP（Request For Proposal：提案依頼書）を取り上げますので，RFPの入門的な知識も解説します。 Part1でも説明したように，RFPはユーザーが作成するものですが，本講座で想定しているレベルのRFPは，実質的にはベンダーのITエンジニアが作成していることが少なくないので，多くのITエンジニアに参考にしていただけ
Part1 モデリング入門――業務全体を“可視化”して顧客をナビゲート，モデリングのスキルが必要不可欠に
Part1 モデリング入門――業務全体を“可視化”して顧客をナビゲート，モデリングのスキルが必要不可欠に 今やモデリングのスキルは，ITエンジニアにとって必須と言えます。Part1では，業務システム分析におけるモデリングの意義を解説します。 業務システムは，業務を効率化してコストを削減するために，広く企業に利用されるようになりました。しかし，膨大な情報化投資を行ったにもかかわらず，結果的には業務の効率化に結びつかず，使われない，あるいは使えないままに放置されているシステムがいたるところにあるのが現実です。 システムを効率よく開発することは重要ですが，間違ったシステムを効率的に開発しても，そのシステムへの投資は無駄になってしまいます。 無駄な投資を抑えるためには，まず業務を経営の構成要素として適切に設計し，その中でシステムを業務の構成要素として開発しなければなりません。つまり，システム要求は
要求開発は誰のためのもの？(3)
前々回では，要求開発はユーザー企業のためのものであり，Opentyologyはユーザー企業の戦略やプロジェクトの目標を達成できる「本当に役に立つシステム」を構築するための，価値あるガイドラインであることを述べました。また，前回では，モデリングの目的とその価値について考えました。 この記事を書く中で，私自身，「要求開発」という概念が必要とされる背景やその目的について考えるようになり，いろいろな「気づき」がありました。ここで，もう一度「要求開発は誰のためのもの？」というテーマについて考えてみようと思います。 一つ，わかったことがあります。それは，要求開発はユーザー企業にとって価値のあるものであると同時に，プロジェクトに参加するSI企業にとっても価値のあるものだということです。 「要求開発」というテーマと向き合ったことで，システム開発に取り組むSI企業にとって，お客さまであるユーザー企業の視点で
反復型開発における見積もりの実際：ベースとなるのはユースケース
オブジェクト指向技術の浸透や，反復型開発の広がりなど，システム開発を巡る状況が大きく変化している。見積もり方法も，従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や，ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い，ソフトウエアを段階的に繰り返して開発していく「反復型開発（イタラティブ開発）」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため，従来型の見積もり技法を適合できない面がある。 そこで第4部では，反復型開発における見積もりの基本的な考え方と，現在，一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお，システム開発のプロセスは反復型開発において最も標準的な「統一プロセス（Unified
「UML2.0の2割で価値の8割を生み出せる」と“UMLの父”ヤコブソン氏
「UML（統一モデリング言語）2.0のドキュメントをすべて読んだ人はいますか？」。9月14～15日に東京で開催されたモデリング・フォーラム2006の基調講演で、イバー・ヤコブソン氏は壇上からこう尋ねた。同氏はUMLのオリジナルの作成者の一人で、特にユースケースを考案したことで知られる。現在はシンガポールや韓国、中国、米国、スウェーデンなど7カ国に自らの会社「イバー・ヤコブソン・インターナショナル」を設立している。 上記の問いかけに、会場の一人が手を挙げた。「何と、世界の不思議だ」とヤコブソン氏は言い、会場の笑いを誘った。「（UMLの最新版である）UML2.0は素晴らしい内容だが、あまりにドキュメントが厚すぎて、軽く900ページを超える。これはツール・ベンダーによるツール・ペンダーのためのものだ。UMLの利用者のことを考慮していない」。 UMLをモデリングに使うべきかどうかに関しては、「確実
要求開発におけるモデリングのコツ(2)---ユーザーの視点でモデリングせよ
前回触れたように，要求開発におけるモデリングにはシステム開発の場合とは違った難しさがある。中でも問題となるのが，モデルを理解すべきユーザー（業務担当者）自身がモデリングの重要性を認識していない場合があることだ。 こうした場合，いきなりUMLのモデルを業務担当者に示しても，「理解できない」と拒絶される場合が多い。そもそも，業務モデリングでUMLによる表記などの細かい流儀にこだわるのが間違いと言える。前回の表にもあるように，要求やステークホルダを一覧表にまとめたものも立派なモデルなのだ。モデルが必要だからといって，やれUMLだのと肩肘をはる必要はない。普通に分かりやすく書くにはどうするべきかを考えてみるとよいだろう。 要求開発のモデルは，システム設計とは違い，業務の観点から行うものである。こうした業務レベルのモデルでは，表記方法の正しさや整合性はそれほど重要ではない。それよりもまず，業務担当者
要求開発におけるモデリングのコツ(1)---観点と粒度に着目せよ
表1を見ればお分かりの通り，システム開発と同様に要求開発においてもモデルの多くはUMLで記述する。一般に，1つのモデルは多面的ないくつかの視点で示される。例えば概観ビジネスモデルは，ユースケース図，クラス図，業務フロー図といった複数のダイアグラムで表現する。これは，立体を表現する際に，三面図や影など複数の視点の図を利用するのに似ている。表1は，要求開発の各フェーズの成果物においてどのようなモデルを利用するべきか，その指針を示していると言える。 システム開発におけるモデリングの経験がある人なら，表1を参照して必要なモデルを作成していけば済むと思うかもしれない。しかし，それだけでは要求開発におけるモデリングはうまくいかない。モデリングで大切なのは，モデルの「観点」と「粒度」だ。たとえ同じようなモデルを描くにしても，システム開発と要求開発ではこの「観点」と「粒度」が異なるのである。 観点とは，モ
現場で使うOpenthology(2)---おいしい部分だけを“つまみ食い”
前回は，「使われないシステム」が出来上がる原因が要求定義にあると考えていた折に，要求開発方法論Openthologyに出会い，筆者の悩みを解決する大きな助けとなったことを述べた。今回は，Openthologyを実際のプロジェクトに適用する際のヒントをいくつか紹介したい。 システム開発に取り掛かる前段階としての要求定義では，様々な問題が発生する。筆者がこれまで携わったプロジェクトでも，「システム化する部分ばかりに目がいって，ビジネス上のゴールまできちんと詳細化できない」「要求仕様が膨れ上がってまとめきれず，時間切れになる」といったケースがあった。問題を簡単にまとめると，以下の2つになるだろう。 (1)要求を検討する際の目的とゴールが明確になっていない。 (2)本来議論すべき対象が可視化できておらず，議論が発散する。 こうした問題を解決するために，筆者は身近なプロジェクトにOpentholog
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
30分間データモデリング 〜ER図を描こう！〜（1/4） ― ＠IT