タグ

2007年12月20日のブックマーク (6件)

  • 非機能要求とISO9126 | オブジェクトの広場

    稿では、ソフトウェア要求とは何なのかを理解し、非機能要求に焦点を当て、ISO9126、要求定義プロセス、事例と解説していきます。 ※稿は、技術評論社刊『JAVA PRESS Vol.40』に掲載された記事「機能外要求と ISO9126」を加筆、修正したものです。JAVA PRESS 編集部の了承を得た上で転載しています。 ※一切の転載をお断りします。 はじめに 私達がソフトウェアを開発するためには、ソフトウェアに対する要求 (ソフトウェア要求) が必要です。 ソフトウェア要求がなければ、そのソフトウェアには当は必要のない機能を作ってしまったり、必要な機能を作っていなかったりするでしょうし、何よりもソフトウェアが完成したのかさえ評価できません。 そのためにも、私達ソフトウェアを開発する者は、ソフトウェア要求とは何なのかを正しく理解しておかなければなりません。 稿では、ソフトウェア要求

    非機能要求とISO9126 | オブジェクトの広場
  • 非機能要件を見極める【後編】:ひな型を使い漏れ防止

    非機能要件は,ユーザーの要求からは出てきにくい。エスエムジーの小森裕介氏(オブジェクトフレームワークディヴィジョン テクニカルコンサルタント)は「経験上,非機能要件の中でも,許容できるダウンタイムや操作性などはユーザーから比較的出てきやすい。しかし,信頼性や性能は意識的にヒアリングしないとあまり出てこない。拡張性に関してはほとんど出てこない」と指摘する。そのため情報システム部門側で主導的に洗い出す。ここからは事例を基にそのプロセスを見ていこう。 ◆どう洗い出すか? ひな型を使い漏れ防止 要件をテンプレート化しておく 非機能要件は機能要件と異なり,項目レベルで業種や業務による違いが少ない。「性能」「保守性」「拡張性」「セキュリティ」など,どのシステムでも同じような項目が並ぶ。そこでエスエムジーは要件定義のテンプレートを用意し,非機能要件として洗い出すべき項目を列挙した。SEはその項目を埋めれ

    非機能要件を見極める【後編】:ひな型を使い漏れ防止
    masapon1967
    masapon1967 2007/12/20
    非機能要件を見極める【後編】:ひな型を使い漏れ防止
  • 非機能要件を見極める【前編】:ヒアリングでは不十分

    「要件定義を難しくする」とクローズアップされてきたのが“非機能要件”の存在である。非機能要件とは,性能や信頼性,拡張性,セキュリティなど,機能要件以外のもの全般を指す。これらはユーザーへのヒアリングからだけでは洗い出しにくい。漏れがあると,稼働後のトラブルの種になる。こうした事態を未然に防ぐ,非機能要件の見極め方を探る。 旅行代理店のアールアンドシーツアーズは,今年10月末に予定しているホテル予約システムの稼働に向けて,今,開発の真っ最中だ。このシステムは,仕入れた航空券の在庫や宿泊の空室情報を管理するホストに,2次代理店からインターネット経由で送信されてくる予約データを受け渡すもの。 開発を主導する大平雅義システム部長は,「機能要件はほぼ固まったが,性能に関する非機能要件が懸案として残っていて悩ましい」と語る。 予約データはインターネットを介してやり取りされる。そこに含まれる顧客情報は暗

    非機能要件を見極める【前編】:ヒアリングでは不十分
    masapon1967
    masapon1967 2007/12/20
    非機能要件を見極める【前編】:ヒアリングでは不十分
  • ITアーキテクチャ設計の反復と吟味

    前回「製品/技術の適用と実現性の検証」までに、一通りのITアーキテクチャ設計ステップを紹介したが、それぞれのステップは独立して1回ずつ行えばよいというわけではない。前のステップの設計内容を受け継いで後続の設計を行い、設計結果を吟味して、必要に応じて前のステップの設計を見直すといった反復が、良いアーキテクチャ設計には欠かせない。 ITアーキテクチャ設計は「要件の洗い出し」「機能的アーキテクチャ設計」「配置設計」「製品/技術の適用」といった流れで行われるが、この流れは1回実施したら終わりというわけではない。製品や技術は、来、ビジネス要求から一連の設計ステップを経て選択されるものであるが、採用技術によっては、適切な配置設計が変わるケースもある。このような場合には、前のステップに戻って、アーキテクチャ設計を見直すことが必要である。 また、いったん、ITアーキテクチャが完成しても、さまざまな観点で

    ITアーキテクチャ設計の反復と吟味
    masapon1967
    masapon1967 2007/12/20
    ITアーキテクチャ設計の反復と吟味
  • 製品/技術の適用と実現性の検証

    前回「配置設計の手順と注意点」までの、機能的なアーキテクチャ設計と配置設計によりITアーキテクチャの骨格は出来上がる。今回のステップでは、描いたITアーキテクチャに実際の製品や技術を当てはめ、性能を検討してITアーキテクチャの実現性を吟味する。ITアーキテクチャが「絵に描いたもち」にならないためには、マシンを用いて技術検証や性能測定を行うことも重要だ。 「アーキテクチャは一見完ぺきなのに、採用した製品の問題で動かない」。このような場合、製品のせいだからITアーキテクトの責任ではないといえるだろうか。ITアーキテクトは、製品や技術の選択やITアーキテクチャへの適合のさせ方についても、当然、責任を持つべきだろう。 製品や技術の問題としては、バグなどの不具合を考えがちであるが、それだけでなく、以下のような点を考慮する必要がある。 欲しい機能がITアーキテクチャ設計上の想定どおり動作するか 開発が

    製品/技術の適用と実現性の検証
    masapon1967
    masapon1967 2007/12/20
    製品/技術の適用と実現性の検証
  • JRubyからJavaへのアクセス方法:CodeZine

    はじめに 稿は、JRubyに固有の特徴を説明し、JRubyをJavaのクラスを利用するための簡易な言語として使えるようにします。JRuby一般の解説については『JRubyチュートリアル』などを参照してください。稿はJRuby 1.0.2について書かれましたが、JRuby 1.0.3にも適用できます。対象読者 読者は、RubyJavaの基礎知識があると仮定します。文字エンコーディング JRubyは、文字をUTF-8扱いするか、それとも1バイトずつの列として扱うか、二通りの指定が-Kオプションや$KCODEで可能です(少なくともJRuby内部で指定を受理する部分はそのように作られています)。しかし、今のところ、その指定はほとんど意味をもっていません。 正規表現やinspectメソッドは、指定にかかわらず、文字列をつねに1バイトずつの列として扱います。getsやputsなどでも文字列をバイ

    masapon1967
    masapon1967 2007/12/20
    JRubyからJavaへのアクセス方法