データ、UI、業務手順の「3要素」をとらえる ― ＠IT情報マネジメント
データ、UI、業務手順の「3要素」をとらえる：分析設計技法「三要素分析法」集中講座（2）（1/3 ページ） 「三要素分析法」は技術者とユーザーとの意思疎通と開発現場での実用性を重視した業務システム向けの分析・設計手法だ。今回は3要素の関係とそれぞれの図式を見ていく。 前回「ユーザーと共通理解できる“システム観”が必要だ」では、「三要素分析法」が業務システム向けに最適化された分析・設計の枠組みであることを説明しました。そこでは、システム要件を分析・設計した結果は「データモデル」「機能モデル」「業務モデル」の「業務システムの3要素」として図式化されること。また、システム開発においてはそれらの論理要件のほかに、利用される実装技術や組織上の特性といった「物理要件」の影響を無視できないこと。結果的に、3要素が「データベース」「プログラム」「ユーザー」としてプロジェクト固有の形を取りながら実装されるこ
GTDでつまずきやすい「プロジェクト」って？
これはボトムアップ、トップダウンの考え方を説明するために用いられていますが、注目してもらいたいのは、GTDでは高度0メートルで考えるべき「次に取るべき行動」「カレンダーに書いたリマインダー」などと、「プロジェクト」ではレベルが違うということです。 GTDにおける「プロジェクト」が分かりにくいのはここに理由があります。GTDのワークフローでは二つのレベルの話が同列に語られているのです。本来ならば「プロジェクト」はワークフローの一段上に書かれるべきなのです。 従って、INBOXに入ったものを「処理」する時は、「これは次に取るべき行動か、それともプロジェクトか？」と考えること自体が間違いなのです。求めるべき結果に達するのに2つ以上の行動が必要なものについては「プロジェクト」にその求めるべき結果を書いておき、同時に次に取るべき行動を決めなくてはいけないのです。 ここで最も注意しなくてはいけないのは
ファイルバージョンの管理だけで十分ですか？
短期連載（要求仕様のボトルネックを探る）では、ITプロジェクトにおける“要求”というものにフォーカスし、高品質な要求開発と、その要求を管理することについてお話ししました。今回の連載では、構成管理（SCM：Software Configuration Management）について見ていきたいと思います。 読者の中には、構成管理といわれると「ソースコードのバージョン管理のことでしょ」ということで、主にライブラリアンと開発者が気にするものという認識の方も多くいらっしゃるのではないかと思いますが、本当にそうでしょうか？ 数人のチームで、1カ月程度で作り上げるようなシステムや、オープンソースではうまくいっても、ある程度の規模の受託開発や、製品開発ではそれだけではうまくいかないことが多いのです。そこで今回は、まずは構成管理の概要をつかんでいただきたいと思います。 プロジェクトの現場で見られる問題点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
