2008-01-30 :-)
_ [JaSST][ソフトウェアテストシンポジウム]JaSSTソフトウェアテストシンポジウム-JaSST'08 Tokyo 1 日目
Software Quality In 2008 - Capers Jones
同時通訳。いまだにこのひとの本は読んでないです。
まとめ：バグを計測する。FP かわいいよ、FP
- 各業界でのソフトウェアバグによる問題
- 航空管制
- 防衛
- 金融
- 医療
- 保険
- 製造業
- 政府
- CMM
- レベル 3, 4, 5 が多いのはインド
- インドは日本が製造業で達成した品質ををソフトウェアでやろうとしている
- ファンクションポイント( FP )
- バグの除去効率を計測したい
- バグのたいはんはコードの 5% くらいにある
- よってコードのみを計測しても有効ではない( LOC のこと )
- 要件定義にもバグはある
- e.g. Y2K
- 要件定義が「年は 2 桁で表現する」
- 要件定義に沿ったテストなので「年は 2 桁」は正しい
- これをバグとみなすテストケースは作らない
- 除去効率 96% は甘い、99% やれ
- IBM、Rational、Motorola は 99% だ
- FP は計測値として妥当
- FP はおおむねソフトウェアの規模を表す
たとえばこう。自動車は 500 だっけ？
| 製品 | FP |
| Microsoft WindowsVISTA | 16 万 |
| Microsoft Office( たち ) | 10 万 |
| Oracle | 30 万 |
| 防衛設備 | もっと多い( 100 万台？ ) |
| ケータイ | 1.5 万 |
| iPod | 2 万 |
| 自動車 | 500 |
| 航空機 | 2.5 万 |
| 小さいウィルス | 4 |
- 要件は変わる
- 製品出荷時には当初の要件の 35% くらいは追加/変更される
- 要件も FP で計測
- テスティングの除去効率
- プログラマ自身によるテストは除去率 50%
- レビュー + テスト + 検査で 95%
- 95% を超えると開発コストを下げることができる
- バグの原因を計測する
- 以下はまだ計測データが少ない( or 無い )
- テストケースそのもの
- データベース
- web コンテンツ
- バグの重要度を計測する
- critical, serious, non-critical
どこでテストをやめるのか？ - 川村真弥(NEC)
まとめ：収束してそうなときにやめる
- 収束判定
- グラフのスケールは当てにならない
- スケールを変えればどうとでも見れる
- 横軸は日数じゃなくてテスト工数にする
- バグの重要度
- ソフトウェアテストに書いたから見ろ
出荷判定ライブ：寸劇から学ぶ出荷判定 −安心・安全な製品を出荷するために - ソフトウェア技術者ネットワーク
半分くらい寝てました。
ISO/IEC9126 & MISRA-C:2004ベース ソースコード品質診断 - 波木理恵子(オージス総研) 中川忠紀(東陽テクニカ)
- 測定値を得点化
- 集計と可視化
- 品質メトリクススイート
- GQM マッピング
- Goal Question Metrics
- GQM 各々に得点化。重みをつける
[ソース] → QAC → [QAC結果] → OGIS 診断 → [診断結果]
パックマンを事例としたゲーム設計のあり方 - 岩谷徹(東京工芸大学)
パックマンを作ったひと。ナムコだったひと。ナムコ時代を振り返る。NHK「プロフェッショナル仕事の流儀」で紹介される人物のようでした。
まとめ：ゲームはあらゆる学問を使ったソフトウェアである
- UI
- DS は老人でもマニュアルを見ずにプレイできる
- 30 年前
- ナムコの自由な風土
- 「いいねそれ」「やろうぜ」
- 締め切りが無い
- 質を煮詰めた
- ギャラガは完成段階になったあとでさらに 6 ヶ月煮詰めた
- パックマン
- 人間の心理を考えて設計
- 4 匹のゴースト
- 4 匹各々アルゴリズムがある
- ゴーストがホームポジション( 画面の 4 隅 )へ戻りそれからパックマンへ向かう
- 昭和 55 年のパックマン最終仕様書
- 方眼紙
- 出荷直後は客の技量が分からない
- 出荷後にパラメーターを調整
- 客の技量と売り上げを測定
- 出荷時の状態ではすべての客の技量をカバーできない
- うまいひと、へたなひと全員を満足させることは難しい
- 出荷後にプレイを測定する
- 自動的に難易度を調整する
- ゼビウスでこれやった
- 魅力
- 「かっこいいところを見せたい」「高得点ほしい」という魅力を設定する
- 対戦ゲーム
- ちゃんと競えるようにする
- うまいひとと下手なひとが同じ土俵で遊べるようにする
- ビリになったらスピードアップさせるとか
- 学習する楽しさ
- ミスやゲームオーバーの原因を分かりやすくする
- 失敗した原因を理解してもらう
- 分かりやすいフィードバック
- 次のプレイに活かす → 反省してリプレイ → ハマる
- FUN FIRST
- 楽しいいことが第一
- 楽しい → 継続する力 → 学習する力？
- ゲームとは「一定のルールに基づいた全ての遊び」である
- スポーツ然り
- 野球では「ゲームセット」「プレイボール」と言うだろ
- キックスタート？
- サービス精神
- プレイヤーの土俵に合わせてサービスを提供する
- プレイヤーは何が欲しいのか
- 企画
- 目的、なぜ、なんのために企画したのか
- リーダーの役割りは決断すること
- ミスは必然
- ミスを恐れない
- 決断しないことのほうが最悪
- ゲストの声
- 各メーカーのプロデューサーたち
- 熱い声
- 要求されるチカラ
- 考えるチカラ
- とにかくいろいろ経験する
- 失敗を恐れずに行動する
- コミュニケーションするチカラ
- とにかく話す、そのうち慣れる
- 経験できないならば想像する
- 相手は何を考えているのか
- 相手は何を言いたいのか
- 考えるチカラ
ゲームが目指すユーザーフレンドリー 吉沢秀雄(バンダイナムコゲームス)
昔テクモ、いまナムコ。「風のクロノア」などを担当したひと。プロデューサー？ 自分がいままでプレイしたゲームを思い出しながら話を聴きました。
まとめ：お客様は王様です( わがままです )
- ゲーム
- ゲームはやらなくてもいいもの。なくてもいいもの。必要ではない。娯楽
- 客からの評価は容赦ない
- わからない
- 出口どこ？
- ボスの弱点どこ？
- できない
- 「俺が未熟だから」とは言わない → 「ゲームが悪い」→ クソゲー認定
- おもてなし
- ナムコの 3 つの超
- 超おもてなし
- 超発想
- 超熱中
- ナムコの 3 つの超
- ゲームの最初が重要
- 最初に盛り上がれば後の困難は乗り切れる
- メニュー画面
- 分かりやすい言葉にする「一人で遊ぶ」「二人で遊ぶ」
- メニュー階層構造に戸惑うとテンションが下がる
- 分かりやすくする。シンプルにする
- 面倒くさいと感じさせてはダメ
- 気持ちの流れを止めない
- 買ってきてからのテンションを止めない
- 「さあやるあぜ！」→ メニュー分かりづらい → もうやらね
- 1 面はチュートリアル
- ゲームの基本操作を体験させる
- ゲームの流れを体験させる
- リアクション
- ダメージ食らったときのエフェクト
- ダメージを与えたときのエフェクト
- 弾がはじかれたときのエフェクト
- 弾がはじかれたときのエフェクト
- 弾がはじかれたときのエフェクト
- 敵が「固い」ときのエフェクト
- プレイヤーに有利なことは大きく
- プレイヤーに不利なことは小さく
- 当たり判定
- グラディウスのビックヴァイパーの当たり判定の小ささとか
- デバッグバージン
- このゲームをプレイしたことがないひとを観察する
- スタッフは散々プレイした → 初めてのプレイは出来ない
- ユーザーテスト
- ショー会場とか、招いたり
- ロケテスト
- 業務用
- 筐体を置く
- 「虫姫さま」サントラの「ロケテスト曲 〜Stage1(TestVer.)〜」はこーいうときに使う曲なんですね。
- 客を観察する
- 目の前で客の反応を見る
- どこで萎えたか
- どこで楽しんでるか
- すぐに分かる
- 最後に宣伝
- 「超劇場版ケロロ軍曹3 天空大冒険であります! 」
B00111NBSU
_ ちょっと休憩
雅叙園内の喫茶店。席についたら従業員が「これから花嫁が来ますよ」と教えてくれました。店内の窓からは外の様子が見れるんですがそこで結婚のための記念撮影している夫婦を見れました。花嫁と花婿は衣装を着て撮影していました。コーヒーは 925 円でした。昼飯より高いです。
[ツッコミを入れる]
