要件定義工程の進め方CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
第1回 あなたは，まだデータモデリングを正しく理解していない
多くの業務システムの開発プロジェクトで，データモデリングが行われています。しかし，皆さんはデータモデリングの「本当の目的」を理解しているでしょうか？ ひょっとしたら，「よく分からないけれど，成果物としてER図やテーブル仕様書をそろえればいい」くらいに考えていませんか？ この連載では，要件定義の工程におけるデータモデリング，それも，実装を意識せずに業務のデータ構造を表す「概念データモデル」に注目して，現場で役立つ実践的なモデリングの方法を解説していきます。 まずは，下記の事例から見ていきましょう。 ケース1 電子部品販売事業を展開するA社が，基幹システムをリプレースするプロジェクトをスタートさせたのは2年前。同社の情報システム部門は，業務の効率化と保守性の向上を目標に掲げ，業務分析とドキュメント化を進めました。もちろん，新システム導入後の業務について業務フロー図（図1）を作成し，必要な画面を
組込システムのための状態遷移図 | SS1の日記 | スラド
組込システムのための状態遷移図(UML)の書きかた。 組込システムの開発では，ソフト担当は，ハード仕様と要求仕様を貰ってから，開発に着手することになる。そこではじめに，状態遷移図を作ることが多い。組込屋さんは状態遷移図さえできれば，プログラムは出来たも同然という気分になる。状態遷移図を作ると，プログラムの挙動を明解に定義できるためだ。 私が書くときの基本的な指針はつぎのとおり。 １．図は，A4一枚にまとめる。 ２．アクションの矢印が交わってはいけない。 ３．初期状態は左上から，正常パターンは時計回りに進行する。 状態遷移表(ZIPCのEHSTM)は，UML形式に慣れてからは，あまり使わなくなった。表形式のもっとも大きい欠点は構造化されてないこと。遷移番号あるいはラベル名でジャンプするのは，BASIC，アセンブラの時代に逆行するようなものだ。 ただし，リバースエンジニアリングしたいときに使う
仕様書と設計書
デスマーチ2004-06-18泥沼というのは、自分がはまり込んでみるとかえってよくわからないものです。 「客観的な目標を立てるのが大事だ」と言いました。その目標となるのが「仕 様書」です。仕様書とは、何を作らなければならないのかを記述した書類です。 仕様書を書くのを面倒に思う人がいるかもしれません。しかしその理由のほと んどは体裁を気にするから起きることです。仕様書は内部文書であり、体裁を 気にする必要はありません。わかればいいのです。 仕様書は、書いた結果よりも書くという行為そのものに意味があります。つま り、いきなりコードを書き始めるのではなく、まず何を作らなければいけない のかを考えることです。 仕様が変更されるわけ「ソフトウェア開発では仕様はすぐ変わるから、仕様書は書くだけムダだ」と 言う人もいます。これは実態をよく表していますが、真実ではありません。な ぜ仕様がすぐ変わるかという
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
