実践ロバストネス分析 第2回 ロバストネス分析の適用 | オブジェクトの広場
本稿は、2003年11月号に掲載した「ロバストネス分析実践 第一回」の続編になります。前回の記事を掲載した後に、読者の方々から様々なご意見、ご感想を頂いていたにもかかわらず、今回の第二回掲載までに、1年3ヶ月もの空白期間を作ってしまいました。本稿の掲載を心待ちにしていた読者の方々にお詫びいたします。 はじめに 前回の記事の訂正 前回の記事ではロバストネス分析を適用したソフトウェア開発の流れ、ロバストネス分析の方法を説明しました。 しかし、前回の記事を掲載してから今回の記事までの 1年3ヶ月の期間で、よりよいロバストネス分析について考えた結果、前回の記事で紹介した内容についていくつか訂正を加えようと思います。いずれ、下記の訂正を前回の記事に反映する予定です。 ロバストネス分析の範囲からユーザーインターフェースの定義を除く 前回の記事では、ロバストネス分析の「バウンダリを識別する」作業でバウン
設計しないことがデスマーチを呼ぶ（予算もスケジュールも関係ない） | oldwaveの日記 | スラド
●画面設計書しかない開発現場 デスマーチになったプロジェクトに火消しとして参加してみると、設計書らしい設計書が画面設計書しかない、という場合がしばしばある。 「いや、そりゃ、わかってるよ。ちゃんと設計した方がいいってことはね。でも、スケジュール的にも予算的にも設計に時間と人を割けなかったんだよ」 「しかし、この混乱は設計書がなかったためでは？ 設計書がないから、各人が勝手な実装をしていて、同じ機能が二重に実装されていたり、画面によって入力値のチェック方法が違っていたりしてるんですよ。セッションに保持されている値はグローバル変数同様なんですから、その使い方はきちんと文書化しておかないと...」 「そうですね、ご説ごもっとも、私もちゃんと設計したかったです。でもね、スケジュールがね...」 こういう会話は何度も経験しているのだが、こういうことを口にする人は重要なことに気付いていない。予算もスケ
視点を分けて業務システムを可視化
間違った業務システムを効率的に開発しても、そのシステムへの投資は無駄になってしまいます。無駄な投資を抑えるためには、業務から論理的にシステム要求を導かなければなりません。 そのためには、業務を可視化すること、すなわち、モデリングが必要です。業務を可視化する手立てと進め方があれば、現場のコミュニケーションが活性化し、使われる、使えるシステムを開発できるようになります（図1）。 モデリング技能を磨くためには、実際に自分で手を動かしてモデルを作成することが必要です。そのため、この連載では架空の会社を取り上げ、一連のシナリオに沿った演習問題の形式で、具体的にモデリングを解説していきます。 モデリングでは着目する視点が重要 モデリングでは、着目する視点を考えることが重要です。なぜなら、業務システムは複雑で、複雑な物事を複雑なまま扱うことは困難だからです。ですから、着目する視点を分けて単純化し、理解し
ユースケース - Wikipedia
ユースケース（Use Case）は、ソフトウェア工学やシステム工学でシステム（あるいはシステムのシステム）の機能要求を含む振舞を把握するための技法である。各ユースケースは、何らかの目的・目標/機能に関する台本（シナリオ）での主体（アクター(actor)）と呼ぶ利用者（ユーザ）とシステムのやりとりを描いている。ユースケースのアクターはエンドユーザーの場合もあるし、別のシステムの場合もある。ユースケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語を用いる。ユースケースの作成は、ビジネスアナリストとエンドユーザーが共同で行う。ユースケースを図にしたものがユースケース図であり、両者を厳密に区別すべき根拠はない。 1986年、後に統一モデリング言語(UML)やラショナル統一プロセス (RUP) で重要な役割を演じたイヴァー・ヤコブソンは、初めてユースケースの
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (4/4)
今回は、業務システム開発の各工程におけるドキュメント成果物の種類について、弊社の開発ドキュメント標準DUNGEONをベースに説明しました。基本設計でデッサンし、詳細設計でその絵をペイントするという役割分担で、後戻りしない設計ドキュメント方式としています。 最初のドキュメントテンプレートとして、業務の流れを理解するのに欠かせない「業務フロー」について、具体例をもとに解説しました。システム化の対象となる画面や帳票を業務フローに漏れなく記述すること、記述するデータ（テーブル）については理解を深めるための主要なものでかまわないこと、などのポイントを覚えておいてください。 著者プロフィール 株式会社システムインテグレータ 梅田 弘之 東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。 常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネス
キミの設計に「トレーサビリティ」はあるか ― ＠IT情報マネジメント
システム開発の流れを俯瞰（ふかん）する 1.1 「ビジネス要求」から「実装・テスト」までステップは5段階 システム開発の工程は5つに分けることができます。すなわち、 ビジネス要求（の分析） システム要求（の分析） 機能（の設計） メソッド（の設計） 実装・テスト（の実施） です（図1）。 「ビジネス要求（の分析）」から「機能（の設計）」までを開発工程の前半とします。前半段階では、構築すべきシステムに対するビジネス・サイドの要求を明らかにします。つまり、業務を見える化（モデル化）し、誰にでもわかる形に仕立てます。 「メソッド（の設計）」から「実装・テスト（の実施）」までを開発工程の後半とします。後半段階では主に、システムに対するビジネス要求を実現するための機能（メソッド）を設計します。設計作業が終了すると、実装、テストを行い、機能が正しく実装されているか、ビジネス要求が満たされているかを検証
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
Part3 分析・設計手法の基本は「モデル作成」にあり
オブジェクト指向分析・設計の基本は，適切な「モデル」を作成することである。ここではオブジェクト指向に基づいた分析・設計手法の難しさを述べるとともに，具体的なモデルの内容，作成手順を解説する。オブジェクト指向では「分析―設計―実装」を反復することで開発を進める。 近年のオブジェクト指向の広がりには，目を見張るものがある。例えばオブジェクト指向の分析・設計モデルを作成する「UML（Unified Modeling Language）」の解説書や雑誌の記事は，今や世にあふれている。加えてUMLによる分析・設計スキルを認定する資格が登場するなど，オブジェクト指向の認知度は確実に向上していると言えよう。 しかし，オブジェクト指向関連製品や技術がこれだけ普及しているのとは裏腹に，その基本原理であるはずのオブジェクト指向分析・設計技法が正しく実践されているとは言えない。UMLとJavaを使ってシステムを
実践ロバストネス分析 第1回 ロバストネス分析の基礎 | オブジェクトの広場
ロバストネス分析は、ユースケースのように文章で記述された要求から分析レベルのオブジェクトを見つけ、適切な単位にまとめることができるものです。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。本稿はロバストネス分析の使い方と効果について解説します。 はじめに ロバストネス分析という用語を聞いたことはありますか？ ロバストネス分析を使うことによって、ユースケースのように文章で記述された要求から分析レベル（アーキテクチャが考慮されていないレベル）のオブジェクトを見つけ、適切な単位にまとめることができます。また、ソフトウェアシステムが行わなければならないことも適切な単位にまとめることができます。 これから、3 回に渡ってロバストネス分析について解説します。本稿にあたる第 1 回ではロバストネス分析の使い方と効果について解説し、第 2 回ではサンプルアプリケー
【中級】基礎からのオブジェクト指向 第3部 分析・設計手法の基本は「モデル作成」にあり（中編） | 日経 xTECH（クロステック）
【中級】基礎からのオブジェクト指向 第3部 分析・設計手法の基本は「モデル作成」にあり（中編） 作成するモデルは3種類 3つの視点でモデリングを繰り返す オブジェクト指向分析・設計において作成するモデルは，抽象度の違いに応じて3種類に分けられる注2）。抽象度の高い順に，「概念モデル」，「仕様モデル」，「実現モデル（実装モデル）」と呼ぶ。以下，順に説明していこう。 現在ではUMLを使ってオブジェクト指向分析・設計作業を進めることが一般的になりつつある。UMLで分析・設計内容を記述し，ユーザーとベンダー間，ベンダー内の設計チームと開発チーム間などで共有すると，システムの姿を明確にし，あいまいさを排除できるからだ。 概念モデルは，主に業務分析のために作成する。要件の記述や仕様定義の際の共通コンセプト，システム化する業務に登場する基本的な語彙をまとめたものだ。概念モデルとしてUMLで作成するのは，
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Persistence is Power:はじめての業務分析(思い出しながら) - livedoor Blog（ブログ）
第４章設計技法.PDF