Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
アジャイルプラクティス導入による組込みシステム開発のプロセス改善
三宅康宏
計測事業グループ計測事業本部
サービスインフラストラクチャソリューション事業部商品開発部主任アンリツ株式会社
ソフトウェア品質シンポジウム2017
2017年9月14日
ソフトウェア品質シンポジウム2017
2
スライドタイトル
Copyright© ANRITSU CORPORATION
発表内容
1. 開発概要
2. これまでの課題と対策
3. 今回の試み
4. 実践した開発プロセス
5. 結果、まとめ
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 3
スライドタイトル
開発概要
開発対象 タッチパネルGUIを持つ測定器 制御系だけでなくアプリケーションも比較的リッチ
開発体制 ソフト開発メンバー:7人
ソフトウェア品質シンポジウム2017
4
スライドタイトル
Copyright© ANRITSU CORPORATION
発表内容
1. 開発概要
2. これまでの課題と対策
3. 今回の試み
4. 実践した開発プロセス
5. 結果、まとめ
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 5
スライドタイトル
ウォーターフォール
これまでの課題
順調だったはずのプロジェクトが、結合から怪しくなる システムテストでのバグの大爆発 実は順調では無かった
仕様 設計 実装 テスト結合
日程遅延
コスト増加
設計が荒れてメンテナンス効率低下
メンテナンス
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 6
スライドタイトル
これまでの対策1(ウォーターフォール)
上流での問題検出/欠陥除去 ドキュメントやレビューの厳格化
システムテスト工程でのバグの爆発は防ぐことができず ウォーターフォールの限界
Copyright© ANRITSU CORPORATION 7
スライドタイトル
これまでの対策2(アジャイル)
アジャイルの導入 結果は失敗 内容を良く理解しないまま本を片手に実践 いざやってみると分からないことだらけ
プラクティスをどこまでやればよいのか うまくいかないときどうすればよいのか スキル的にできないプラクティスをやろうとする
昼過ぎまで朝会
ウォーターフォールを2週間に区切っただけのイテ
レーション
テストコードのメンテに忙殺
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 8
スライドタイトル
これまでの対策に対する反省
「流行りのアジャイルを導入すればうまくいくんじゃないか」という甘い考え
プロセスを構成するプラクティスの目的・意味を理解できていない
そもそもアジャイルが解決策なのか?
何のためのアジャイル?
ソフトウェア品質シンポジウム2017
9
スライドタイトル
Copyright© ANRITSU CORPORATION
発表内容
1. 開発概要
2. 課題とこれまでの対策
3. 今回の試み
4. 実践した開発プロセス
5. 結果、まとめ
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 10
スライドタイトル
他プロセス(アジャイル等)
今回の試み
現行プロセスから新しいプロセスに乗り換えるのではなく
現行プロセス 新プロセス
現行プロセス プラティス
プラティス
プラティス
プラティス再設計/改善
現行プロセスに必要なプラクティスを取り入れる 自ら設計すればプロセスは自分のものになるはず
乗り換え
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 11
スライドタイトル
今回の試み
現行プロセスの再設計手順
現行プロセスの問題点分析
問題点を解決するプラクティス選出/実施方法決定
現行プロセスから残すプラクティス決定
プラクティスを組み合わせてプロセスを作成
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 12
スライドタイトル
現行プロセスの問題点分析
どの工程で埋め込まれた問題が、どの工程で顕在化するのかを分析
仕様 実装 結合 テストメンテナンス
全体計画
全体計画更新
ウォーターフォールモデル
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 13
スライドタイトル
問題の原因分析(一例)
顕在化する工程
問題 埋めこまれる工程
番号
全体計画更新
仕様に基づいた実装見積が計画を超えた場合、仕様見直し作業が発生する。仕様 1
実装 実装コストを無視した仕様や、仕様漏れが見つかり仕様見直し作業が発生する。
仕様 2
結合 担当者間で認識違いによるインターフェースミスや実装漏れ作業が発覚する。
実装 3
ソフト単体の不具合によりハード/ソフトの不具合原因切り分け作業に時間が掛かる。
実装 4
ハードウェアの仕様変更、日程遅延に対しソフトウェア開発が柔軟に対応できない。
結合 5
テスト 修正と差戻しを繰り返しバグが収束しない。実装者の仕様理解が不足している。
仕様 6
実装時に作業が膨らんでいるにも関わらず見積の更新がされず、日程のプレッシャーから作業の質を薄めてしまう。それが不具合として露呈する。
実装 7
実装フェーズで仕様の理解不足による間違った実装が不具合として露呈する。
仕様 実装
8
実際に触ってみたら使いにくい/想像と違う⇒仕様見直し作業が発生 仕様 実装
9
特定の人にバグが集中しクリティカルパスとなる。 実装 10 メンテナンス
設計が荒れている為、改造の度にデグレ検証コストが発生 テスト 11
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 14
スライドタイトル
番号 解決策 プラクティス 1 定期的に残作業の見積を更新する イテレーション開発、ベロシティ計測2 仕様と実装を同時期に行い、細かい単位で工程移行する。 イテレーション開発
3 コミュニケーションを密にする。頻繁に結合する。
スクラム会議、CI
4 動くソフトでステークホルダを含めレビューする。 イテレーション開発、TDD5 実装優先度の組み換えや機能の取捨選択を可能にする。 ストーリ、イテレーション開発、TDD
ハードウェアに依存しない実装にする。 ハードウェアシミュレータ※16 全員で仕様を作成し全員の仕様理解を深める。 全員参加 7 動くソフトで第3者による客観的なテストを行う。 イテレーション開発、TDD
定期的に残作業の見積を更新する ベロシティ計測8 全員で仕様を作成し全員の仕様理解を深める。 全員参加
動くソフトで検証を行う。 イテレーション開発、TDD9 仕様作成段階で動くソフトでレビューを行う。 イテレーション開発10 担当を固定せず、誰でもどこでも作り修正できるようにす
る。 ソース共有
11 ソースをリファクタリングする。テストを自動化する。 TDD、リファクタリング
問題解決のためのプラクティス選出
列挙した問題に対する解決策とそれを実現するプラクティス
TDD:テスト駆動開発, CI:継続的インテグレーション ※1:アジャイルのプラクティスではない
問題: 実際に触ってみたら使いにくい/想像と違う⇒仕様見直し作業が発生
問題: 実装時に作業が膨らんでいるにも関わらず見積の更新がされず、日程のプレッシャーから作業の質を薄めてしまう。それが不具合として露呈する
問題: ハードウェアの仕様変更、日程遅延に対しソフトウェア開発が柔軟に対応できない。
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 15
スライドタイトル
プラクティス実践の工夫
ここまででプラクティスは決定した そのままでは実践の難しいプラクティスには対策が必要
イテレーション開発
テスト駆動開発
組込みシステム特有の課題
チーム特有の課題
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 16
スライドタイトル
プラクティス実践の工夫(イテレーション)
イテレーション開発では、イテレーション毎にシステムテストを実施する
設計
実装 テスト
設計
実装 テスト
設計
実装 テスト
イテレーション#1 イテレーション#2 イテレーション#3
Copyright© ANRITSU CORPORATION 17
スライドタイトル
プラクティス実践の工夫(イテレーション)
組み込み開発の場合、ソフトとハードを平行して開発ハードが上がってくるのは開発後半ハード無しでシステムテストを実施する必要
実装/テスト ソフトウェア開発
ハードウェア開発
ハード結合
設計 実装/搭載
ハード無し期間
問題点
Copyright© ANRITSU CORPORATION 18
スライドタイトル
プラクティス実践の工夫(イテレーション)
ハードウェアに変わるシミュレータ(ソフト)を開発ドライバからのレジスタRead/Writeに応答するデジタル信号処理ツールを用いてリアルなデータ作成システムテスト相当のテストが可能
FPGA(ハード)
Driver
シミュレータ
Application
Read/Write
ソフトウェアアーキテクチャ
リアルな元データ
マルチプラットフォームの言語によりPC上でテスト可能
解決策
Copyright© ANRITSU CORPORATION 19
スライドタイトル
プラクティス実践の工夫(テスト駆動)
テスト自動化の為のプラクティスイテレーションを繰り返すたびデグレ確認テストが増えるテスト自動化できないとイテレーション開発がコスト高にイテレーション開発にテスト自動化は必須 xUnitで自動テスト可能な設計にするには、高いオブジェクト指向設計スキルが必要⇒今のチームには難しい
イテレーション
新規のテスト
デグレ確認テスト
自動化
問題点
Copyright© ANRITSU CORPORATION 20
スライドタイトル
プラクティス実践の工夫(テスト駆動)
テスト自動化の為のフレームワークを開発しアーキテクチャに組み込んだ フレームワークに従い実装すればテスト自動化が可能な
設計にできる
その他テスト自動化への様々な工夫(運用時) GUI操作からテストコードの自動生成 テストコードのリファクタリング機能 その他様々な機能を束ねて自動化システムを構築
アーキテクチャにテスト自動化の仕組み
を組み込み 対策
TDDのためのスキル不足
テスト自動化の継続が最も苦労した
解決策
Copyright© ANRITSU CORPORATION 21
スライドタイトル
現行プロセスから残すプラクティス選出
仕様策定後の全体計画更新 仕様作成⇒計画⇒実装の流れは残す 仕様変更はそれほど入らないので仕様は先に固めて全体
を見たい。社内プロセス上も必要。
見積方法 WBSベースの時間による見積 見積ポーカーやポイント制より現行の手法の方が良いと
判断
仕様 実装 結合 テスト
全体計画 全体計画更新
22
スライドタイトル
Copyright© ANRITSU CORPORATION
発表内容
1. 開発概要
2. これまでの課題と対策
3. 今回の試み
4. 実践した開発プロセス
5. 結果、まとめ
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 23
スライドタイトル
プロセス詳細 <全体>
仕様フェーズ、実装フェーズ、テストフェーズに分かれる 全体的な流れはウォーターフォール 仕様/実装フェーズとアジャイルを2回まわす
テスト結 合
システムテスト
仕様フェーズ 実装フェーズ テストフェーズ
リリース
開発開始
開発完了
イテレーション
実装 仕様
全体計画更新
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 24
スライドタイトル
プロセス詳細 <仕様フェーズ>
目的:仕様の確定、開発の全体像を把握作業:機能仕様書、ラフな実装
テスト結 合
システムテスト
仕様フェーズ 実装フェーズ テストフェーズ
リリース
開発開始
開発完了
イテレーション
実装 仕様
全体計画更新
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 25
スライドタイトル
プロセス詳細 <仕様フェーズ>
チーム全員で実践手順
① 動作のレビューができる程度に機能実装② 動くソフトを全員でレビュー③ 詳細仕様をドキュメントに記述
予定した仕様の記述が完了したら実装見積りしてイテレーション完了
仕様記述
機能実装
レビュー
全員が仕様を理解
仕様手戻り防止
スムーズに実装へ
見積もり確度向上
ねらい 見積
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 26
スライドタイトル
プロセス詳細 <全体計画更新>
機能のプライオリティを決定実装フェーズのイテレーション計画を立てる
テスト結 合
システムテスト
仕様フェーズ 実装フェーズ テストフェーズ
リリース
開発開始
開発完了
イテレーション
実装 仕様
全体計画更新
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 27
スライドタイトル
プロセス詳細 <実装フェーズ>
目的:実装完成作業:実装、テスト仕様作成、テストとその自動化
テスト結 合
システムテスト
仕様フェーズ 実装フェーズ テストフェーズ
リリース
開発開始
開発完了
イテレーション
実装 仕様
全体計画更新
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 28
スライドタイトル
プロセス詳細 <実装フェーズ>
仕様確認、分担を決めるテスト仕様作成担当と実装チームに分かれて作業全員でテスト振り返り、残作業の見積もり更新
テスト実装
テスト仕様打合せ
分担
打合せ
見積更新
自動化
イテレーション(2週間)
仕様確認 振り返り
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 29
スライドタイトル
プロセス詳細 <テストフェーズ>
ソフトの完成度は高いのでハード結合はスムーズシステムテストは実ハード上でテストを行う。
ソフトに閉じた機能は省略可能
テスト結 合
システムテスト
仕様フェーズ 実装フェーズ テストフェーズ
リリース
開発開始
開発完了
イテレーション
実装 仕様
全体計画
全体計画更新
ソフトウェア品質シンポジウム2017
30
スライドタイトル
Copyright© ANRITSU CORPORATION
発表内容
1. 開発概要
2. これまでの課題と対策
3. 今回の試み
4. 実践した開発プロセス
5. 結果、まとめ
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 31
スライドタイトル
結果
システムテストでのバグの大爆発は阻止できた バグ件数は過去プロジェクトの1/3 余裕をもってスケジュール維持
リファクタリングにより、あるべき姿の設計を維持できた 手戻り作業を減らしコスト削減できた
過去のデータが無いため比較はできないが今回の手戻り工数は20H程度。
ウォーターフォールと比較すると手戻りは確実に少ない。
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 32
スライドタイトル
まとめ
イテレーション開発によりその時点での完了を確実にすることでシステムテストへの問題先送りを防ぐことができる。
プロセスを自分のものに(深く理解)することで、効果的なプロセス運用を行うことができる。
アジャイルの変更への柔軟さは組み込みシステム開発においてはハードウェア開発からの変更に有効。ハードウェアシミュレータと組み合わせることでハード開発に依存しないソフト開発が可能。
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 33
スライドタイトル
おわりに
今回紹介したプロセスはあくまで一例開発プロセスとはその時の開発チームでその時の開発対象を効率的に開発するために最適化された仕組みであるべき 毎回プロジェクトに合わせて設計する
“開発プロセスは与えられるものでも従うもので無く自分で作り自分でコントロールするもの”
開発チーム 開発対象
ドメイン知識
設計スキル 性格
文化
品質
コスト
納期
新規性 プロセス
最適化
ソフトウェア品質シンポジウム2017
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 35
スライドタイトル
アジャイルの変更への強さ
アジャイルはユーザの要求変更に対して柔軟なプロセスとして認識されている
ユーザの要求変更だけでなくすべての変更に対しても柔軟 当初予定に対する変更の例
ハードウェアの仕様変更・日程遅延 既存製品の緊急対応によるリソースの変更 解決に時間のかかるバグの発生
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 36
スライドタイトル
高い独立性
アジャイルが変更に強い理由
独立性が高い “実装機能”ごとの独立性が高い(ストーリ)テスト自動化&リファクタリングで独立性の高い設計
設計
実装機能
時間軸で独立させる
ストーリ
テスト駆動
リファクタリング
イテレーション
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 37
スライドタイトル
アジャイルが変更に強い理由
イテレーション単位で計画変更可能 実装機能の優先度変更 途中リリース
入れ替え可能
入れ替え可能
途中リリース可能
途中リリース不可
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 38
スライドタイトル
ハード開発からの変更への対応
ハードからの変更 対応
日程が遅れる シミュレータをアップグレードして本物ハードに近づけ、ハード結合でテストする予定だった部分を前倒す。
仕様が変わった 既に実装した部分の修正が必要だが、自動テストでデグレは保証される
仕様が変わる(これから) シミュレータを修正してソフトの実装を進める。
仕様が増える 確保しているリソースが足りなくなる場合、プライオリティの低い機能の仕様を変更、入れ替え、または途中リリースが可能。
アジャイル+シミュレータでハード開発に依存しないソフト開発が可能
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 39
スライドタイトル
ハードウェアシミュレータの利点
ハードができるまでにソフトのテストが可能 実ハードで再現させることが難しい状態を自在に作れる ソフト屋がIOの先まで理解できる
シミュレーションするには知識が必要 レジスタ仕様のレビューになる
シミュレータを作る際のインプットになる。間違いがたくさん見つかる
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 40
スライドタイトル
問題の原因分析
マインドマップを使って深く分析
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 41
スライドタイトル
テスト自動化の難しさ(1/2)
テスト自動化により効率を上げるのが目的 自動テストコスト<手動テストコストでないと意味ない コストを掛けずに自動化し続けることは難しい
テスト自動化の壁① テスト自動化を可能にする設計② テストコードの記述③ テストコードのメンテナンス
手動テストコスト
テストコード作成コスト
テストコードメンテナンスコスト
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 42
スライドタイトル
テスト自動化の難しさ(2/2)
テスト自動化を可能にする設計• テスト駆動で実装すれば誰でもできるわけでもない• テストを楽にする設計(オブジェクト指向)を熟知• 設計に失敗すると、テストコードの記述およびメンテナ
ンスのコストが増大する テストコードの記述
• テストコードの記述にはコストが掛かる• なるべくアーキテクチャの外側から記述する
テストコードのメンテナンス• イテレーションを繰り返す度にテストコードは増える• 仕様変更や修正があるとテストコードの修正が必要にな
る
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 43
スライドタイトル
テスト自動化の為のシステム(1/2)
Jenkins, Bugzillaとの連携
テストコードの作成テストコードのメン
テナンス
テストの為の設計(フレームワーク)
自動テストコード生成
テストコードエディタ
リファクタリングツール
Copyright© ANRITSU CORPORATION 44
スライドタイトル
テスト自動化の為のシステム(2/2)
テストコードの自動生成 GUIを操作するとテストコードが生成されサーバに
アップロード テストコードのメンテナンス
テストコード専用エディタにより入力アシスト 結果を期待値になるようテストコードを自動修正機能 全テストコードの一括修正機能 テストFail状態とJenkins番号、SVNリビジョンの一覧
機能 テスト実行環境
テストコードはJenkinsにより自動実行
Copyright© ANRITSU CORPORATION 45
スライドタイトル
オブジェクト指向
オブジェクト指向で共通化しました。効率が上がります。
共通部分に変更を入れると全部テストし直しです。コストが掛かります
テストを自動化しました。もうテストし直す必要はありません。
仕様変更するとテストコードを全部直すのでコストが掛かります。
最小コストでテストコードをメンテナンスする
オブジェクト指向
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 46
スライドタイトル
開発プロセスのとらえ方(1/2)
プロセスはそれを設計した人にとって最適されたもの スキル、経験、企業文化、開発製品も異なる人たちのプロ
セスが自分にとって最適なのか? 自分にとっての最適プロセスを見つけることが大事
XP Scrum UP
ケントベック サザーランド ヤコブソン 自分
?
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 47
スライドタイトル
開発プロセスのとらえ方(2/2)
開発プロセスの本に書いてあることは、膨大な経験・ノウハウの成功例の上澄み液
バックグラウンドを理解しないでそこだけをなぞっても、うまくいかない
自身でプロセス設計を行う過程である程度バックグラウンドを理解できる
プロセス本に書いてある事
バックグラウンド 成功経験、失敗経験
チャレンジ、分析、ノウハウ
ソフトウェア品質シンポジウム2017
Copyright© ANRITSU CORPORATION 48
スライドタイトル
レビュー
レビューは上流で不具合の除去を目指す
製品
テストレビュー
実装 機能仕様 IF仕様
Soft-Soft/ Soft-Hard
テスト仕様
ユーザ要求を満たすか 実装の入力として条件に漏
れがないか
担当者間の認識の違いが無いか⇒CI
テストケースが網羅されているか 無駄/冗長が無いか
テスト
ソフトウェア品質シンポジウム2017