要求開発とコタツモデル(1)－－失敗パターンに陥らないために
筆者は，SIerの立場で様々なITシステム開発プロジェクトに参加しています。常に思い知らされるのは「ITシステム開発は難しい」という事実です。特に要求開発・要件定義といったコンセプトを決める工程では，以前に成功したプロジェクトで採用していた方法を使用しても，同じように成功するとは限りません。 「どうやったらプロジェクトを成功させることができるのか」──これは筆者に限らずITシステム開発にかかわるすべての人の悩みではないでしょうか。 書籍『要求開発』には書かれていない秘訣がある 要求開発アライアンスでは，同じような悩みを持つ人々が，ユーザー企業やシステムベンダーの垣根を越えて集まり，月例勉強会や合宿を開催してシステム開発についての悩みを議論しています。「要求はあるものではなく，開発するものである」──このコンセプトに共感する参加者の発表や意見には，刺激的なものが少なくありません。 要求開発ア
要求開発とコタツモデル(2)－－アンチパターンを活用する
前回は，要求開発・要件定義フェーズを成功させるためのポイント「コタツモデル」についての説明を行いました。「コタツモデル」とは，ITシステム開発プロジェクトにおける，主要な三つのステークホルダーの関係性を表すメタファーです。 ビジネス戦略を決定するビジネス・オーナー（経営者や高位の責任者），実際のビジネスを遂行しているユーザー（現場担当者），そしてシステム開発担当者の三者によってシステムの目標を決定する＝一つのコタツに入って議論する状況を，要求開発アライアンスでは「コタツモデル」と呼んでいるものです。 今回は，具体的な「コタツモデル」形成のテクニックの一部についてご紹介したいと思います。 「コタツモデル」形成に王道なし，アンチパターンの活用 「（要求開発・要件定義などの）上流工程は異種格闘技戦である」──これは筆者の持論です。ITシステム開発の下流工程，すなわち設計・プログラミング・テスト・
se.htm
システムズアプローチの教材 システムズアプローチ，要求分析，構造化，評価などのシステム工学の教材 (ppt)や関連事項を載せます。 システムズアプローチ システム開発の手順 システムズアプローチ システムズアプローチをpptで表現しました。これらのスライドのオリジナルは，過去の経営科学の受講生が，Macintoshの上のMac Drawで作ったものです。それをMac上でpptに変換し，MacOpnerでWindows上に変換し，uploadしました（Macから直接uploadすればよいかな）。 身近な問題のレポート作成時の留意点 システムに関する学問 ユーザ指向の考え方製品開発のときには，利用者のことを考えなくてはなりません。ユーザは何を期待しているのでしょうか。メーカに就職を決めてから，見ると将来参考になるかもね。イントロだけ載せました。 「情報1」 システムズアプローチ (2007.1
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
要求仕様書の標準化プロセス
「DUNGEON」はソフトウェア開発の各工程において必要とするドキュメント標準を決めて、その具体的なテンプレートを用意したものです。概念的なアプローチとはまったく逆に、アウトプット側から開発プロセスを標準化するという実践的な考え方を重視しています。 これまで7回にわたって、基本設計から詳細設計、プログラミング、単体テスト、結合テスト、総合テストという流れに沿って、各プロセスで必要とするドキュメントの標準化を説明してきました。最終回の今回は、その前段のプロセスである要求分析フェーズのアウトプットについて説明します。 みなさんはSLCPという言葉を知っていますか。SLCPとはSoftware Life Cycle Processの略で、ソフトウェアの開発ライフサイクル、つまりこれまで解説してきた基本設計から総合テストまでの開発工程を指す言葉です。SLCPの代表的なものは30年前に提唱されたウォ
ヒアリングとインタビュー | 「最高のゴール」を目指して！
ヒアリングとインタビューとは違うと思います。 様々な意見があると思いますが、私の理解は以下の通りです。 ・ヒアリングとは、相手の知っていることを聞き出し、正確に理解する。 主体は、相手です。 ・インタビューとは、相手より広い範囲で質問し、新たな視点や気づきを引き出す。 主体は、聞き手です。 そして、得られる情報はインタビュー能力次第だと思います。 よくシステムエンジニア（ＳＥ）が、「お客様の業務をヒアリングして、システムを開発する」と言います。 これは、「現状業務をプログラムに忠実に置き換える」という意味になると思います。 現在求められるのは、インタビューを通して「新たなビジネスモデル」を提案し、それをシステムで実現することではないでしょうか。 インタビューのポイント そこで、私の考えるインタビューのポイントを、以下に整理します。 １．インタビューが全てを決定することを認識する。 インタビ
システムテスト プロジェクト管理者の道具箱
■開始条件 総合テストが完了している事。 ■システムテストの目的 ハードウェア、ソフトウェア、アプリケーションの関係において信頼性や性能に問題のない事を確認する。 ■システムテストの方法 システムテスト計画を立てる。 修正にかかる工数や体制を予め取っておく。 システムテスト仕様書はシステム設計書を基に作成する。 システムテスト計画書やシステムテスト仕様書のレビューを行い、テストパターンやテスト項目の過不足、テストの妥当性についてチェックする。 システムテストにて、性能テスト(パフォーマンステスト)と障害テストを行う。 システムテスト結果を評価し、次の工程に進むべきかどうかの判定を行う。 ■性能テストの方法 性能テストの為に、本番運用と同等以上のデータを準備する。 性能テストの為に、本番運用と同等以上のトランザクションを発生させるツール、もしくはオペレータを準備する。 サーバの各種資源(CP
セキュリティ要件をどうRFPに盛り込むか
セキュリティ要求仕様のレベル JNSAのセキュリティ要求仕様は、できるだけ多くの発注者が、これを参考にして実際にセキュリテ ィに関する要件をシステム提案依頼に含められるようにすることを目的としている。ここで問題となるのは、発注者、受注者の双方で、セキュリティに関するリテラシーのレベルがさまざまだということである。 そこで、JNSAのワーキンググループでは次の3つのタイプのセキュリティ要件を提示し、RFPを作成する人に、自社にとって一番使いやすいものを選択してもらう方式とすることにした。それぞれの具体的な要件については直接参照してもらうとして、ここでは、各タイプの特徴を説明し、それぞれが持つ発注者、受注者にとってのメリット、デメリットを説明したい。 1対策手法の視点 技術的な視点、あるいはシステムを開発するベンダ側の視点から作成した要求仕様であり、現状で一般的に検討されているセキュリティ対策
非機能要求とISO9126 | オブジェクトの広場
本稿では、ソフトウェア要求とは何なのかを理解し、非機能要求に焦点を当て、ISO9126、要求定義プロセス、事例と解説していきます。 ※本稿は、技術評論社刊『JAVA PRESS Vol.40』に掲載された記事「機能外要求と ISO9126」を加筆、修正したものです。JAVA PRESS 編集部の了承を得た上で転載しています。 ※一切の転載をお断りします。 はじめに 私達がソフトウェアを開発するためには、ソフトウェアに対する要求 (ソフトウェア要求) が必要です。 ソフトウェア要求がなければ、そのソフトウェアには本当は必要のない機能を作ってしまったり、必要な機能を作っていなかったりするでしょうし、何よりもソフトウェアが完成したのかさえ評価できません。 そのためにも、私達ソフトウェアを開発する者は、ソフトウェア要求とは何なのかを正しく理解しておかなければなりません。 本稿では、ソフトウェア要求
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://itckinki.jp/article.php/20070906145425147/print
発注者ビューガイドライン（ダウンロード可能） | 発注者ビュー検討会 | NTTデータ
Amazon.co.jp: 要求開発と要求管理: カール・E. ウィーガーズ (著), 雅彦,宗 (監修), Wiegers,Karl E. (原名), 恵,田沢 (翻訳), 真理子,溝口 (翻訳): 本
基本設計書
非機能要求モデル