Copyright (C) Mitsubishi Research Institute, Inc.
Upcoming SlideShare
Loading in...5
×
 

Copyright (C) Mitsubishi Research Institute, Inc.

on

  • 1,089 views

 

Statistics

Views

Total Views
1,089
Views on SlideShare
1,087
Embed Views
2

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 2

https://twitter.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Copyright (C) Mitsubishi Research Institute, Inc. Copyright (C) Mitsubishi Research Institute, Inc. Presentation Transcript

  • オープンソース実践特論 第 10 回ソフトウェア開発ツールの評価 2009 年 12 月 5 日 情報技術研究センター 飯尾 淳
  • 開発ツールの評価
  • 評価の位置づけと目的
    • 開発ツール導入時の、ツール選択方法と評価の意義
      • 評価を行うべきシチュエーションとその理由
    • 開発の生産性を上げるために、新しい開発ツールを導入したい
    • 生産性向上のレバレッジ効果
    • 例:大企業
    •   開発者多数  ×  効率化 = 莫大な時間の削減
    • 新しい技術のキャッチアップ
    • 流行のフォロー
    • 開発技術、ツールも日々進化する
    • 常に新しい情報を押さえておくべき
    • インターネットで協働して開発される OSS
    • 開発者の間でツールの共有が求められる
    • 自分にとって使いやすいツールとは
    • 協調作業がしやすいツールとは
    • 関係者間における開発技術の共有
  • 評価に関する作業内容 … コストの算出
    • コストの算出方法
      • コストとは
        • 金銭的費用
        • 時間的負荷
        • 担当者や関係者の負担
        • その他、様々な要素を考える
    • 様々な局面で発生するコスト
      • 導入コスト
        • ソフトウェアのライセンス費用
        • 導入作業にかかる費用
        • ハードウェアの新規購入、等
      • 教育コスト
        • 新しいツールの使い方に関する教育
        • 慣れるまでの(一時的な)生産性低下、開発者の精神的負担
    OSS であれば 基本的には不要だが… コスト要因
  • (補足)導入教育の重要性
  • 評価に関する作業内容 … 導入のメリットデメリット
    • 導入のメリットとデメリット
      • 開発ツールを導入する際のメリットとデメリットを考えてみよう
    新たな開発ツールを導入するメリットとデメリット デメリット メリット ツール活用の教育コストがかかる 維持のコストがかかる場合がある 効果がすぐには現れないこともある ツールを受け入れる体制が求められる 開発効率を向上させることができる 成果物の品質を高めることができる 開発コストを下げることができる 新しい技術に対応できる メリット デメリット OSS であれば大丈夫…?
  • 実施タイミング
    • 評価のタイミング
      • 導入前の見積り
      • 導入後の効果測定
    • 導入前の見積りに関する課題
      • きちんとした見積りは実現可能かどうか?
        • 見積りは… 難しい
        • 経験に頼る… 「開発ツールの導入」機会はそう何回もあるものでもない
    見積りの難しさについては、 関連書籍を参照 ⇒
  • 実施タイミング(続き)
    • 評価のタイミング
      • 導入前の見積り
      • 導入後の効果測定
    • 導入後の効果測定に関する課題
      • 効果測定した結果をどのように活用すべきか
        • 次回の導入にフィードバックする? ⇒ そうそう機会があるわけではない
        • 定期的な効果測定により、効率向上の定量的な指標を作成 ⇒ 開発者のモチベーション向上
        • 「開発ツール」開発者に効果をフィードバック ← OSSならではの活用法
  • 開発ツールの評価項目
  • 開発ツールの何を評価すればよいのか 操作性、操作の習得しやすさ 相互運用性、 互換性 デバッグ効率 購入・保守費用 機能性 移行性、 移行コスト 第三者による 評価、評判 開発ツールの 評価項目
  • 開発ツールの操作性とユーザビリティ (写真提供: FreeFoto.com, 写真素材 足成) User eXperience 開発者の満足度 = 開発効率の向上? 機能の提供 ユーザビリティ UX
  • 操作性と、操作習得のコスト
    • 操作性の評価
      • 操作性が悪いと…
      • 操作性は、どうやって評価すればよいだろうか?(考えてみよう)
    • 開発ツールの操作性に関する評価のポイント
    • あることを実現するために多数の手数がかかる
    • 何べんも同じミスを繰り返す
    作業効率が低下
    • 十分にテストできず、バグが紛れ込む可能性が高くなる
    • 開発者のやる気も低下、士気が下がる
    品質が低下
    • 開発ツールの常識とかけ離れていないかどうか
    • マニュアルやヘルプを見なくても操作できるかどうか
    • 情報は見やすく表示されているかどうか
    • ミスを防ぐ仕組みや手戻りできる仕組みが用意されているかどうか
    開発者が操作するユーザインタフェースの良し悪しを評価
  • (参考)情報システムのユーザビリティ評価ツール UxDux ルールセットの内容と項目数 ルールセット(抜粋) 作成:三菱総合研究所 14 会社情報へのアクセス手段は適切か、 社員を検索する手段が用意されているか、等 イントラ内の個別情報 9 コンテンツは標準に準拠しているか、 色・形だけで情報を伝えていないか、等 アクセシビリティ 7 エラー表示がわかりやすいか、 不正使用が行われない工夫があるか、等 エラーへの対処、 セキュリティ 10 動作速度は高速か、新しいウィンドウを次々に開いたりしないか、等 反応のよさ、動作のわかりやすさ 20 デザイン・文字の大きさは適切か、文章が長すぎないか、等 情報の把握しやすさ、わかりやすさ 20 処理状況がわかるか、検索できるか、 適切なリンクがあるか、等 情報へのアクセス性、みつけやすさ 17 ヘルプが無くても作業を進めることができるか、不要なダイアログはないか、等 データ入力のしやすさ 項目数 内容 分類
  • (参考) UxDux の診断結果
      • ユーザビリティ評価の結果は、カテゴリごとの傾向と具体的な所見という形で示す
    出典:三菱総合研究所 ユーザビリティ評価のアウトプット例 (カテゴリごとの傾向)
  • 操作性と、操作習得のコスト(続き)
    • 操作方法習得コストの評価
      • 操作方法の習得にもコストがかかる
        • 簡単に操作方法を習得できるか
        • 教育に高いコストがかかることはないか
    • 前提となる開発技法習得の必要性
      • そのツールが特定の開発技法を前提としていないか?
        • オブジェクト指向開発
        • データベース、ネットワーク、等の特定ドメインに特化した開発技法
        • 他ツールの利用
          • 例:  Android SDK は、 Eclipse も利用可能 (ADT, Android Development Tools Plugin)
        • 開発スタイルによる違い
          • アジャイル開発
          • (古き良き)ウォーターフォール開発、 etc…
      • 開発ツールだけでなく、言語環境、開発フレームワーク等にも依存
    • 開発環境やフレームワーク等を OSS で提供
    • 操作方法の教育や活用に関する教育で対価を得る
    • 認定試験を実施し、認定料を得る、など
    (参考)オープンソースの 教育ビジネスの事例
  • 移行性、移行コスト
    • 移行性とは?
    移行性 … 簡単に移行できるかどうか 移行コスト … 移行にかかるコスト 新しい開発ツールの導入 =  これまでの開発環境から、 新しい開発環境に 移行
  • 機能性
    • 必要な機能が備わっているか
      • 特殊な環境に対する開発ツール(例、 iPhone SDK に含まれる開発ツール)
    ※  組み込み機器の開発ツールには、機能性の検証が不可欠 ドラッグ・アンド・ドロップにより GUI を簡単に構築するためのデザイン・ツール Interface Builder 開発中の iPhone アプリケーションに関するプロファイラ Instruments Mac OS X 上で動作する iPhone 自体のシミュレータ。開発中のプログラムがどのように動くかを検証するために利用 iPhone Simulator プロジェクト管理、ソースコードエディタ、デバッガ等を含む統合開発環境 Xocde
  • 購入および保守の費用
    • 購入、保守の留意点
      • 購入の費用は無料(フリーソフトのフリーは「無料」のフリー、ではないことに注意)
      • では保守は?
        • システム、ソフトウェアの保守… メンテナンスは不可欠
        • 何をしなければならないか、何に費用がかかるか?(考えてみよう)
    • OSSサポートのコスト
      • サポート… 長期間、導入した開発ツールを使い続けるためにはとても重要
      • ポイント
        • 誰がサポートするのか
        • 技術を理解している人間が身内に居るかどうか
        • 開発が途切れてしまうことはないか、etc.
  • デバッグ効率
    • デバッグの効率が開発の質と速度を左右する
    デバッグの効率と開発スピード、プログラム品質の関係 デバッグ プリント 効果的なツールの活用 開発速度、開発成果の品質
    • 単純なプログラム
    デバッガの利用 統合開発 環境の活用
    • 単独作業
    • 開発プロセスの統一
    • 様々な開発メソッド
    • オープンソースプロジェクト
    • 個人による開発
    • プロトタイプ
    • インターネットの利用
    • 大規模開発
  • デバッグ(おさらい)
    • デバッグプリントによる動作確認
      • ソースコードに変数の値を出力するコードを埋め込む
        • 例: 変数 v の値を知りたいとき
        • printf (“DEBUG: v = %d ”, v);
      • デバッグプリントのメリット
        • お手軽
        • どんな言語でも、たいてい対応可能
      • デバッグプリントのデメリット
        • 端末に表示をできないケースがある(例: カーネルモジュール、組み込みシステム等)
        • 簡単に確認できないバグもある(例: 画像処理プログラム、リアルタイムシステム等)
        • デバッグプリントのコードが本体に影響し、動作が変わるケースもある
          • スタックを破壊しているようなバグで、デバッグプリントの影響によってバグを回避してしまうケースなど
  • デバッグ(おさらいの続き)
    • デバッガ(および統合開発環境に組み込まれたデバッグ機能)による動作確認
      • デバッガによるデバッグの標準的な流れ
        • シンボル情報付きでコンパイル
        • デバッガを起動、デバッガの操作により、不具合(バグ)の問題点を追求する
      • デバッガ利用によるデバッグのメリット
        • ブレークポイント、ウォッチポイント等の細かなプログラム制御による確認が可能
        • どんな言語でも、たいていデバッガは用意されている
      • デバッガ利用によるデバッグのデメリット
        • デバッガの使い方を覚えなければならない
        • 最適化されていると、デバッガが適切に動作しないケースもある
    • デバッガ利用によるデバッグで戸惑うケース( C プログラミングの場合)
    • 最適化が効き、変数がレジスタに割り当てられてしまう
    • レジスタの内容を見なければならないが、対応が分かりづらい
  • 他ツールとの接続性と生産物・データの互換性
    • 接続性、互換性とは
      • 接続性
        • 様々なツールを組み合わせて使うときに、問題が生じないかどうか
        • エディタ ⇒ コンパイラ ⇒ デバッガ ⇒ プロファイラ ⇒ …
      • 互換性
        • 様々なデータのやり取りで問題が生じないかどうか
        • 例1: WWW、様々なブラウザで動作するか
        • 例2: オフィス文書(ODF, Open Document Format)
        • 例3: 各種のXMLデータ(開発ツールで利用)
    • マルチプラットフォーム対応
      • マルチプラットフォーム: Windows、Mac OS X、Linux、各種UNIX、モバイル機器、携帯電話、etc.
  • 多様性の問題
      • 多様性とは何か
        • コンポーネントの組合せ方が
        • 自由なため、組合せの数が爆発
        • 自由度の高さに相反、
        • トレードオフの関係
      • プロプラエタリ環境でも
        • PC/AT 互換機
        • デバイスの多様性
        • デバイスメーカが対処
          • マイノリティは辛い
  • 3つの多様性
    • データの多様性
      • 外部との電子化文書交換で問題が発生
        • アプリケーション固有のデータフォーマット
        • ex. *.doc, *.xls, *.ppt,...
      • 交換したいのは、形式ではなく内容そのもの
        • 文書
          • 文章の記述、体裁 ...
        • 表計算シート、プレゼンテーション
          • 値、グラフ、図形、フォント ...
      • データが個別アプリケーションに依存
        • 同じカテゴリのアプリケーションでも、データ形式が違う
        • ex. ワードプロセッサ
          • MS-Word, OpenOffice.org Writer, KOffice, AbiWord, etc...
    • プラットフォームの多様性
      • プラットフォーム構成に関する自由度が高すぎ
      • 選択肢
        • カーネルパラメータ、カーネルモジュール
        • ライブラリ、ツール
        • その他のアプリケーションが依存するソフトウェア
      • 動作環境に関する多様性の原因
        • ディストリビューションの違い
          • Red Hat, SUSE, Debian, Knoppix, etc...
        • バージョンの違い
          • 個々のアプリが個別の進化を繰り返すため
        • プロプラエタリ OS でも、同様の問題はある
        • SPx を当てた / 当てない、 YYY エディション、など
    • ユーザインタフェースの多様性
      • 操作の多様性はユーザの不信感に直結する
        • とくに、デスクトップ利用で顕著
      • 慣れ親しんだユーザインタフェースと操作性
      • 本質的な機能は同じでも ...
        • アイコンが違う
        • メニューの位置や表記が違う
        • キーボードショートカットが違う
        • エラーメッセージが違う、 etc...
      • ユーザは保守的
        • 新しい操作を覚え直す手間と時間がもったいない
        • せっかく操作を覚えたのに