SQiPシンポジウム2009 商品開発プロジェクトの実際 予定では・・・ 新製品開発における ソフトウェア品質改善事例 発売 ｼｽﾃﾑ ｼｽﾃﾑ 評価 評価 実用化開発 実用化開発 商品開発 商品開発 遅れ 現実は・・・ 実用化開発 実用化開発 量産 量産 遅れ 遅れ 商品開発 商品開発 発売 量産 量産 ｼｽﾃﾑ評価 ｼｽﾃﾑ評価 評価 評価 積み残し 発売 量産 量産 修正 ・・・・ ・・・・ テスト 修正 正 修 商品開発 商品開発 テス スト ト テ 実用化開発 実用化開発 シスメックス株式会社 科学計測事業部技術開発課 積み残し 積み残し 実際は！ ○小枝 徳晃 瀬下博之 宮本樹美代 井塚宗久 ・・・・ ・・・・ 評価といいながら 不具合対策 2 改善のための分析 対応策の検討 原因は複数考えられる・・・ 効果的に対策を打つにはどこから手を付ければよいか 「システム評価」といいながら、 実際は「不具合修正」を行っている。 TOC（制約理論）によれば・・・ システムのスループットを決めているのは、 １つか２つのボトルネックである。 との記載がある。 システム評価の段階で不具合発見による手戻り TOCの現状問題構造ツリーを用いて、 原因を分析を実行する プロジェクト全体の開発工数を圧迫 最終段階で発生するため、リカバリーが困難 UDE（Undesired Effect:好ましくない結果）を抽出 次にそれらの関係を導き出す。 ～ ～ 積み残し 積み残し 積み残し 積み残し ～ ～ ～ ～ ～ ～ 遅れ 遅れ 遅れ 遅れ ことに決定！ 3 現状問題点構造ツリーによる分析 分析結果からの考察 システムテスト システムテスト でバグを見逃す でバグを見逃す ボトルネック 事前テストが 事前テストが 不十分 不十分 仕様の誤解 仕様の誤解 発生 発生 修正漏れの 修正漏れの 発生 発生 先祖帰りの 先祖帰りの 発生 発生 情報共有が 情報共有が 不十分 不十分 変更管理が 変更管理が 不十分 不十分 ソース管理 ソース管理 が不十分 が不十分 システムテストの手戻り 単体テストでの問題もさることながら・・・ テスト技術力が テスト技術力が 低い 低い テスト工数が テスト工数が 不十分 不十分 テスト期間が テスト期間が 短い 短い システム設計 システム設計 技術力が低い 技術力が低い UDE（好ましくない結果）が集中している 開発期間が短い バグが多い バグが多い システムテ ストでの手戻 りが多い 4 仕様の漏れ バージョン バージョン アップが アップが 多い 多い 開発期間が 開発期間が 少ない 少ない システム設計 システム設計 が不十分 が不十分 仕様の誤解 要求管理が 要求管理が 不十分 不十分 ソース管理 コミュニケーションの問題 プロジェクトマネジメントの問題 仕様の追加 仕様の追加 変更が多い 変更が多い 比較的対応しやすく、効果が高い 共通化が 共通化が 進んでない 進んでない プロジェクト管理が プロジェクト管理が 不十分 不十分 仕様決定が 仕様決定が 遅い 遅い 「システムテストの手戻り」 市場のニーズ 市場のニーズ がわからない がわからない を今回の改善の対象に決定！ 5 6 SQiPシンポジウム2009 どう品質を改善するのか？ ①不具合、機能追加管理の徹底 Ｍａｎｔｉｓを活用した修正管理例 優先すべきは、システムテストの手戻り対策 不具合のカテゴリー・重要 度・ステータス（どういう状 態にあるか）など一目でわか る。 Mantisの活用 変更管理が 不十分 ①不具合、機能追加管理の徹底 ソース管理 が不十分 ②ソース管理の徹底 情報共有が 不十分 ③情報の見える化 開発用ＷＥＢ構築 Ｆｏｒｕｍ，Ｗiki テスト工数が 不十分 ④自動テストの実施 ＮＵＮＩＴの活用 ＴｅｓｔＣｏｍｐｌｅｔｅの活用 不具合管理ツールのMantisを機 能追加も含めた作業管理に使用 特にステータスは、色別で直 感的にわかりやすいため、不 具合が放置されっぱなしに なることはなくなる VSSの活用 Subversionの活用 VSS：Microsoftのソース管理ツール Subversion：Linux用ソース管理ツール 各項目修正毎に第3者の検 証を実施。 問題を早期に解決 NUNIT:単体テスト用のツール TestComplete：自動テスト管理ツール 全ての業務指示は、Ｍａｎｔｉｓに記載することにより、指示を徹底 全てのプログラムの修正項目の対応状況をいつでもだれでも確認可能 アプリケーション操作を記録し、テストを 自動化 7 ②ソース管理の徹底（１／２） 8 ②ソース管理の徹底（２／２） 開発経過 ＶＳＳを用いたソース管理 2006年度 上期 下期 2007年度 上期 下期 要素開発 任意の時点のソースを 常に取得でき、チェック アウト機能により、同時 のソース変更を禁止で きる。 2008年度 上期 下期 2009年度 上期 下期 '07/7 市場試験 α00-00開発 α00-01開発 β00-00開発 β00-01開発 '08/2 商品開発開始 '06/7 要素開発開始 '06/9 実用化開発承認 β00-02開発 β00-03開発 開発中の中間バージョ ンを作成、管理。 作りかけの機能を載せ ない。 テスト期間の確保 β00-04開発 '08/10 出図 00-00開発 00-01開発 '09/10 設変予定で 開発中 00-02開発 00-03開発 修正者、修正理由が記録され、いつの時点のソースにも復元可能 プログラムソースだけではなく、ドキュメント、ツール等も一元管理 スパイラル開発の考え方を導入 中間バージョンを計画に基づくリリース ソフトウェアの「未実装や作りかけの機能に伴うトラブル」といった問題の排除 リリースの計画化により、労働時間短縮 休日出勤日数はゼロ 残業時間メンバー平均１８．５６時間／月 (前商品開発時：平均３５．６時間／月) 9 ③情報の見える化 スケジュール管理例 10 ④自動テストの実施 ＷＥＢを用いた情報の共有化 不具合の早期発見 ＦＯＲＵＭ，ＷＩＫＩ グループウェアのように情報 を一元化・共通化がはかれる。 スケジュール管理、議事録、各種必要な情報をいつでも確認可能 関連サイトや連絡事項も掲載 現在開発中の2種類のプロジェクトを対象として、自動テストを試行した。 11 12 SQiPシンポジウム2009 ④自動テストの成果 プログラム作成量と不具合件数 自動テストのスクリプト作成工数はか かったが手動では確認できないような マイナーな不具合が瞬時に発見でき た例もある。 プロジェクト１自動化テスト工数の比較 1400 種類 1200 有効行 コメント行 空白行 総行数 PC部 134,097 74,540 21,886 227,601 本体部 35,327 5,266 5,082 45,675 テストスクリプト 32232 1000 800 スクリプト作成時間 テスト実施時間 時間 600 400 200 0 スクリプト作成時間 テスト実施時間 手動実施時 自動化後 0 1278 371 95 プロジェクト２：７１件の不具合発見 プロジェクト２バージョンテスト 自動化 640 + 40×回数 手動での実施 480×回数 5000 プロジェクト１：１９件の不具合発見 PC部におけるプログラム開発中の修正・変更 原因 件数 ①開発中に発生した仕様追加、仕様漏れ等の対応 723件 ②開発中に発見された不具合（リリース前、後の合計） 972件 計 1695件 4500 一度スクリプトを作成すると、バージョ ンアップ時には少ないメンテナンス工 数で、繰り返し正確にテストを実施で きる。 テ ス ト工 数 （ 累 積 ） [ H] 4000 仕様の追加、漏れが4割（723件／1695件） 3500 3000 ・市場の要望が後で判明 ・要望していた仕様と異なる 2500 2000 1500 1000 500 0 1 2 3 4 5 6 7 8 9 バージョンアップ回数 バージョンアップ回数・ソースのボリュームなどのバランスはあるものの基本的に 再現性良く、繰り返し何度でも実行できるのは、自動テスト最大のメリットである。 その分省力化できたところを他のテストに時間を有効活用できる。 市場の情報がうまく入ってくる仕組みが必要 13 まとめ及び今後の課題 まとめ •システムテスト不具合件数が７件（手戻り１回）となり、前回プロジェクトの 数十件（手戻り５回程度）から改善が見られた。 •先祖がえり、修正漏れの不具合は発生していない。 ソース管理、不具合管理ツールの効果が大きい。 •仕様の誤解は、大幅に改善した。 •変更1件毎に修正後の確認を行うことが改善につながった。 •自動テストにより、不具合の早期発見につながった。 今後の課題 ・ソフトの共通化の推進 コンポーネント化、ライブラリ化 ・テスト技術を向上 各種テスト技法の導入 ・要求管理技術の向上 要求管理技術・要求工学の導入 ・プロジェクト管理技術の向上 ＰＭＢＯＫ、ＳＷＥＢＯＫの導入 15 14
© Copyright 2024 Paperzz
