【伝わる!モデリング】はじめようUML! 第2回:ユースケース図を学ぼう! 著者:株式会社テクノロジックアート 照井 康真 公開日:2008/04/08(火) ユースケース図とは 前回は、UMLに関する全般的なお話から、業務分析でアクティビティ図を使用する方法を説明しました。今回は、要求分析でユースケース図を使用する方法を説明します。 ユースケース図は、UMLの生みの親であるスリーアミーゴスの1人、ヤコブソンがOOSEという方法論から取り入れた図です。システムが、外部から求められる機能的な要求を表現します。開発工程の中では主に要求分析段階で、開発者がユーザに機能的な要求を確認するために記述されることが多い図となります。図1は、最もシンプルな表記によるユースケース図の例です。 「サブジェクト」は、書いても書かなくてもそれほど違いはありませんが、ここでは後の説明のしやすさのために記述しています
ここでは、クラウドとレンタルサーバーの違いについてご案内しています。 クラウドとレンタルサーバーの違いとは 従来のレンタルサーバーでは専用サーバーや物理的なサーバーマシンを複数のユーザーがシェアするのが基本的な仮想専用サーバー(VPSサーバー)の利用形態であり、処理能力、利用できる容量はそのサーバーに備わっているだけで一定です。 クラウドのサーバーは、複数のサーバーが仮想化された状態であり、必要があれば利用するユーザーの状況に応じて処理能力の向上や容量の振り分けが可能になります。またクラウドの利用料金は定額制だけでなく、利用状況により変動する従量課金制は、クラウドの特徴と言えます。 クラウド レンタルサーバー(VPSサーバー)
開発したシステムが失敗に終わったとしても、そのシステムを開発した会社の技術レベルが低いということではありません。技術レベル自体は、ほとんどの会社・システムエンジニアに差はありません。個々のエンジニアは非常に優秀といえます。 システム開発で結果に大きな差を及ぼすのは、「開発する前にどれだけ準備したのか」に尽きます。発注者の構想の何%がシステムエンジニアに伝わったのか。 ・予算は? ・納期は? ・必要な機能は? ・優先事項は? ・システムを使うひとは誰? ・システムを使う環境は? ・システムを使う時間は? などなど 発注者の属する業界についての基本的に知識も、この際、エンジニアは何も知らないと考えていた方が間違い有りません。発注者は、小学生に説明するつもりで、作って欲しいシステムの内容をエンジニア側に伝える必要があります。 とはいえ、WEBの世界ではスピードが要求されるため、準備に時間をかけて
[数ヶ月の放浪から帰ってまいりました…] システム開発会社の中で仕事をしてきたわけでもない(非システムエンジニアという意味において)単なる一般人である私が、システム開発について失敗しない方法として最終的に落ち着きつつある結論は 『システム開発準備段階のシステム設計書(要求仕様書)を完璧な状態にする』 ということです。 (薄々分かっていたことではありますが…) 完璧な状態とは、「開発着手後から納品まで一切の仕様変更をしない」という前提で記載した書類(ドキュメント)のことです。 つまり、開発依頼者にとっては「要求仕様書=納品物」ともいえる状態に持って行くわけです。 さて、そうなると準備段階(書類作成段階)において、システム開発依頼者には驚異的な負担とプレッシャーが掛かってきます。 なぜなら、開発前段階であるが故に相談できるシステムエンジニアやプログラマーがいないという状態を覚悟する必要があるか
※本記事は日本IBM発行の「PROVISION No.63/Fall 2009」の論文紹介記事に一部加筆・編集して掲載しています。 筆者の経験に基づく個人の意見であり、IBMを代表する見解ではありません。 日本国内のITエンジニア不足が深刻な問題となる中、海外へITシステムの開発を委託するオフショア開発は当たり前の形態となっている。しかし、残念ながらビジネスとしての実態を見る限り、オフショア開発のすべてが成功しているわけではない。理由は文化や商慣習の違いからくる各種の摩擦、言語面でのコミュニケーション不備、そこから生じるさまざまなトラブルなど実に多種多様である[1]。 IBMもグローバル・デリバリー(海外IBM要員との協業:GD)という形で積極的にオフショア開発を推進している。だが、GDに関しても問題は多種多様であり、いまだに個々のプロジェクトだけでは解決できない問題が数多く発生しているの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く