アジャイルプラクティス導入による組込みシステム開発の ... · 2017. 9....

アジャイルプラクティス導入による組込みシステム開発のプロセス改善

三宅康宏

計測事業グループ計測事業本部

サービスインフラストラクチャソリューション事業部商品開発部主任アンリツ株式会社

ソフトウェア品質シンポジウム2017

2017年9月14日


2

スライドタイトル

Copyright© ANRITSU CORPORATION

発表内容

1. 開発概要

2. これまでの課題と対策

3. 今回の試み

4. 実践した開発プロセス

5. 結果、まとめ


Copyright© ANRITSU CORPORATION 3


開発概要

開発対象タッチパネルGUIを持つ測定器制御系だけでなくアプリケーションも比較的リッチ

開発体制ソフト開発メンバー：7人


4



発表内容

1. 開発概要


3. 今回の試み






ウォーターフォール

これまでの課題

順調だったはずのプロジェクトが、結合から怪しくなるシステムテストでのバグの大爆発実は順調では無かった

仕様設計実装テスト結合

日程遅延

コスト増加

設計が荒れてメンテナンス効率低下

メンテナンス




これまでの対策１（ウォーターフォール）

上流での問題検出／欠陥除去ドキュメントやレビューの厳格化

システムテスト工程でのバグの爆発は防ぐことができずウォーターフォールの限界



これまでの対策２（アジャイル）

アジャイルの導入結果は失敗内容を良く理解しないまま本を片手に実践いざやってみると分からないことだらけ

プラクティスをどこまでやればよいのかうまくいかないときどうすればよいのかスキル的にできないプラクティスをやろうとする

昼過ぎまで朝会

ウォーターフォールを２週間に区切っただけのイテ

レーション

テストコードのメンテに忙殺




これまでの対策に対する反省

「流行りのアジャイルを導入すればうまくいくんじゃないか」という甘い考え

プロセスを構成するプラクティスの目的・意味を理解できていない

そもそもアジャイルが解決策なのか？

何のためのアジャイル？


9



発表内容

1. 開発概要

2. 課題とこれまでの対策

3. 今回の試み






他プロセス（アジャイル等）

今回の試み

現行プロセスから新しいプロセスに乗り換えるのではなく

現行プロセス新プロセス

現行プロセスﾌﾟﾗﾃｨｽ

ﾌﾟﾗﾃｨｽ

ﾌﾟﾗﾃｨｽ

ﾌﾟﾗﾃｨｽ再設計／改善

現行プロセスに必要なプラクティスを取り入れる自ら設計すればプロセスは自分のものになるはず

乗り換え




今回の試み

現行プロセスの再設計手順

現行プロセスの問題点分析

問題点を解決するプラクティス選出／実施方法決定

現行プロセスから残すプラクティス決定

プラクティスを組み合わせてプロセスを作成




現行プロセスの問題点分析

どの工程で埋め込まれた問題が、どの工程で顕在化するのかを分析

仕様実装結合テストメンテナンス

全体計画

全体計画更新

ウォーターフォールモデル




問題の原因分析（一例）

顕在化する工程

問題埋めこまれる工程

番号

全体計画更新

仕様に基づいた実装見積が計画を超えた場合、仕様見直し作業が発生する。仕様 1

実装実装コストを無視した仕様や、仕様漏れが見つかり仕様見直し作業が発生する。

仕様 2

結合担当者間で認識違いによるインターフェースミスや実装漏れ作業が発覚する。

実装 3

ソフト単体の不具合によりハード／ソフトの不具合原因切り分け作業に時間が掛かる。

実装 4

ハードウェアの仕様変更、日程遅延に対しソフトウェア開発が柔軟に対応できない。

結合 5

テスト修正と差戻しを繰り返しバグが収束しない。実装者の仕様理解が不足している。

仕様 6

実装時に作業が膨らんでいるにも関わらず見積の更新がされず、日程のプレッシャーから作業の質を薄めてしまう。それが不具合として露呈する。

実装 7

実装フェーズで仕様の理解不足による間違った実装が不具合として露呈する。

仕様実装

8

実際に触ってみたら使いにくい／想像と違う⇒仕様見直し作業が発生仕様実装

9

特定の人にバグが集中しクリティカルパスとなる。実装 10 メンテナンス

設計が荒れている為、改造の度にデグレ検証コストが発生テスト 11




番号解決策プラクティス 1 定期的に残作業の見積を更新するｲﾃﾚｰｼｮﾝ開発、ﾍﾞﾛｼﾃｨ計測2 仕様と実装を同時期に行い、細かい単位で工程移行する。ｲﾃﾚｰｼｮﾝ開発

3 コミュニケーションを密にする。頻繁に結合する。

ｽｸﾗﾑ会議、CI

4 動くソフトでステークホルダを含めレビューする。ｲﾃﾚｰｼｮﾝ開発、TDD5 実装優先度の組み換えや機能の取捨選択を可能にする。ｽﾄｰﾘ、ｲﾃﾚｰｼｮﾝ開発、TDD

ハードウェアに依存しない実装にする。ﾊｰﾄﾞｳｪｱｼﾐｭﾚｰﾀ※16 全員で仕様を作成し全員の仕様理解を深める。全員参加 7 動くソフトで第３者による客観的なテストを行う。ｲﾃﾚｰｼｮﾝ開発、TDD

定期的に残作業の見積を更新するﾍﾞﾛｼﾃｨ計測8 全員で仕様を作成し全員の仕様理解を深める。全員参加

動くソフトで検証を行う。ｲﾃﾚｰｼｮﾝ開発、TDD9 仕様作成段階で動くソフトでレビューを行う。ｲﾃﾚｰｼｮﾝ開発10 担当を固定せず、誰でもどこでも作り修正できるようにす

る。ｿｰｽ共有

11 ソースをリファクタリングする。テストを自動化する。 TDD、ﾘﾌｧｸﾀﾘﾝｸﾞ

問題解決のためのプラクティス選出

列挙した問題に対する解決策とそれを実現するプラクティス

TDD:テスト駆動開発, CI:継続的インテグレーション ※1:アジャイルのプラクティスではない

問題：実際に触ってみたら使いにくい／想像と違う⇒仕様見直し作業が発生

問題：実装時に作業が膨らんでいるにも関わらず見積の更新がされず、日程のプレッシャーから作業の質を薄めてしまう。それが不具合として露呈する

問題：ハードウェアの仕様変更、日程遅延に対しソフトウェア開発が柔軟に対応できない。




プラクティス実践の工夫

ここまででプラクティスは決定したそのままでは実践の難しいプラクティスには対策が必要

イテレーション開発

テスト駆動開発

組込みシステム特有の課題

チーム特有の課題




プラクティス実践の工夫（イテレーション）

イテレーション開発では、イテレーション毎にシステムテストを実施する

設計

実装ﾃｽﾄ

設計

実装ﾃｽﾄ

設計

実装ﾃｽﾄ

イテレーション#1 イテレーション#2 イテレーション#3




組み込み開発の場合、ソフトとハードを平行して開発ハードが上がってくるのは開発後半ハード無しでシステムテストを実施する必要

実装／テストソフトウェア開発

ハードウェア開発

ハード結合

設計実装／搭載

ハード無し期間

問題点




ハードウェアに変わるシミュレータ（ソフト）を開発ドライバからのレジスタRead/Writeに応答するデジタル信号処理ツールを用いてリアルなデータ作成システムテスト相当のテストが可能

FPGA（ハード）

Driver

ｼﾐｭﾚｰﾀ

Application

Read/Write

ソフトウェアアーキテクチャ

リアルな元データ

マルチプラットフォームの言語によりPC上でテスト可能

解決策



プラクティス実践の工夫（テスト駆動）

テスト自動化の為のプラクティスイテレーションを繰り返すたびデグレ確認テストが増えるテスト自動化できないとイテレーション開発がコスト高にイテレーション開発にテスト自動化は必須 xUnitで自動テスト可能な設計にするには、高いオブジェクト指向設計スキルが必要⇒今のチームには難しい

イテレーション

新規のテスト

デグレ確認テスト

自動化

問題点



プラクティス実践の工夫（テスト駆動）

テスト自動化の為のフレームワークを開発しアーキテクチャに組み込んだフレームワークに従い実装すればテスト自動化が可能な

設計にできる

その他テスト自動化への様々な工夫（運用時） GUI操作からテストコードの自動生成テストコードのリファクタリング機能その他様々な機能を束ねて自動化システムを構築

アーキテクチャにテスト自動化の仕組み

を組み込み対策

TDDのためのスキル不足

テスト自動化の継続が最も苦労した

解決策



現行プロセスから残すプラクティス選出

仕様策定後の全体計画更新仕様作成⇒計画⇒実装の流れは残す仕様変更はそれほど入らないので仕様は先に固めて全体

を見たい。社内プロセス上も必要。

見積方法 WBSベースの時間による見積見積ポーカーやポイント制より現行の手法の方が良いと

判断

仕様実装結合テスト

全体計画全体計画更新

22



発表内容

1. 開発概要


3. 今回の試み






プロセス詳細＜全体＞

仕様フェーズ、実装フェーズ、テストフェーズに分かれる全体的な流れはウォーターフォール仕様／実装フェーズとアジャイルを2回まわす

テスト結合

システムテスト

仕様フェーズ実装フェーズテストフェーズ

リリース

開発開始

開発完了


実装仕様

全体計画更新




プロセス詳細＜仕様フェーズ＞

目的：仕様の確定、開発の全体像を把握作業：機能仕様書、ラフな実装

テスト結合



リリース

開発開始

開発完了


実装仕様

全体計画更新




プロセス詳細＜仕様フェーズ＞

チーム全員で実践手順

① 動作のレビューができる程度に機能実装② 動くソフトを全員でレビュー③ 詳細仕様をドキュメントに記述

予定した仕様の記述が完了したら実装見積りしてイテレーション完了

仕様記述

機能実装

レビュー

全員が仕様を理解

仕様手戻り防止

スムーズに実装へ

見積もり確度向上

ねらい見積




プロセス詳細＜全体計画更新＞

機能のプライオリティを決定実装フェーズのイテレーション計画を立てる

テスト結合



リリース

開発開始

開発完了


実装仕様

全体計画更新




プロセス詳細＜実装フェーズ＞

目的：実装完成作業：実装、テスト仕様作成、テストとその自動化

テスト結合



リリース

開発開始

開発完了


実装仕様

全体計画更新




プロセス詳細＜実装フェーズ＞

仕様確認、分担を決めるテスト仕様作成担当と実装チームに分かれて作業全員でテスト振り返り、残作業の見積もり更新

テスト実装

テスト仕様打合せ

分担

打合せ

見積更新

自動化

イテレーション（２週間）

仕様確認振り返り




プロセス詳細＜テストフェーズ＞

ソフトの完成度は高いのでハード結合はスムーズシステムテストは実ハード上でテストを行う。

ソフトに閉じた機能は省略可能

テスト結合



リリース

開発開始

開発完了


実装仕様

全体計画

全体計画更新


30



発表内容

1. 開発概要


3. 今回の試み






結果

システムテストでのバグの大爆発は阻止できたバグ件数は過去プロジェクトの1/3 余裕をもってスケジュール維持

リファクタリングにより、あるべき姿の設計を維持できた手戻り作業を減らしコスト削減できた

過去のデータが無いため比較はできないが今回の手戻り工数は20H程度。

ウォーターフォールと比較すると手戻りは確実に少ない。




まとめ

イテレーション開発によりその時点での完了を確実にすることでシステムテストへの問題先送りを防ぐことができる。

プロセスを自分のものに（深く理解）することで、効果的なプロセス運用を行うことができる。

アジャイルの変更への柔軟さは組み込みシステム開発においてはハードウェア開発からの変更に有効。ハードウェアシミュレータと組み合わせることでハード開発に依存しないソフト開発が可能。




おわりに

今回紹介したプロセスはあくまで一例開発プロセスとはその時の開発チームでその時の開発対象を効率的に開発するために最適化された仕組みであるべき毎回プロジェクトに合わせて設計する

“開発プロセスは与えられるものでも従うもので無く自分で作り自分でコントロールするもの”

開発チーム開発対象

ﾄﾞﾒｲﾝ知識

設計ｽｷﾙ性格

文化

品質

ｺｽﾄ

納期

新規性プロセス

最適化




アジャイルの変更への強さ

アジャイルはユーザの要求変更に対して柔軟なプロセスとして認識されている

ユーザの要求変更だけでなくすべての変更に対しても柔軟当初予定に対する変更の例

ハードウェアの仕様変更・日程遅延既存製品の緊急対応によるリソースの変更解決に時間のかかるバグの発生




高い独立性

アジャイルが変更に強い理由

独立性が高い “実装機能”ごとの独立性が高い（ストーリ）テスト自動化&リファクタリングで独立性の高い設計

設計

実装機能

時間軸で独立させる

ストーリ

ﾃｽﾄ駆動

ﾘﾌｧｸﾀﾘﾝｸﾞ

ｲﾃﾚｰｼｮﾝ




アジャイルが変更に強い理由

イテレーション単位で計画変更可能実装機能の優先度変更途中リリース

入れ替え可能

入れ替え可能

途中リリース可能

途中リリース不可




ハード開発からの変更への対応

ハードからの変更対応

日程が遅れるシミュレータをアップグレードして本物ハードに近づけ、ハード結合でテストする予定だった部分を前倒す。

仕様が変わった既に実装した部分の修正が必要だが、自動テストでデグレは保証される

仕様が変わる（これから）シミュレータを修正してソフトの実装を進める。

仕様が増える確保しているリソースが足りなくなる場合、プライオリティの低い機能の仕様を変更、入れ替え、または途中リリースが可能。

アジャイル＋シミュレータでハード開発に依存しないソフト開発が可能




ハードウェアシミュレータの利点

ハードができるまでにソフトのテストが可能実ハードで再現させることが難しい状態を自在に作れるソフト屋がIOの先まで理解できる

シミュレーションするには知識が必要レジスタ仕様のレビューになる

シミュレータを作る際のインプットになる。間違いがたくさん見つかる




問題の原因分析

マインドマップを使って深く分析




テスト自動化の難しさ（１／２）

テスト自動化により効率を上げるのが目的自動テストコスト＜手動テストコストでないと意味ないコストを掛けずに自動化し続けることは難しい

テスト自動化の壁① テスト自動化を可能にする設計② テストコードの記述③ テストコードのメンテナンス

手動テストコスト

テストコード作成コスト

テストコードメンテナンスコスト




テスト自動化の難しさ（２／２）

テスト自動化を可能にする設計• テスト駆動で実装すれば誰でもできるわけでもない• テストを楽にする設計（オブジェクト指向）を熟知• 設計に失敗すると、テストコードの記述およびメンテナ

ンスのコストが増大するテストコードの記述

• テストコードの記述にはコストが掛かる• なるべくアーキテクチャの外側から記述する

テストコードのメンテナンス• イテレーションを繰り返す度にテストコードは増える• 仕様変更や修正があるとテストコードの修正が必要にな

る




テスト自動化の為のシステム（１／２）

Jenkins, Bugzillaとの連携

テストコードの作成テストコードのメン

テナンス

テストの為の設計（フレームワーク）

自動テストコード生成

テストコードエディタ

リファクタリングツール



テスト自動化の為のシステム（２／２）

テストコードの自動生成 GUIを操作するとテストコードが生成されサーバに

アップロードテストコードのメンテナンス

テストコード専用エディタにより入力アシスト結果を期待値になるようテストコードを自動修正機能全テストコードの一括修正機能テストFail状態とJenkins番号、SVNリビジョンの一覧

機能テスト実行環境

テストコードはJenkinsにより自動実行



オブジェクト指向

オブジェクト指向で共通化しました。効率が上がります。

共通部分に変更を入れると全部テストし直しです。コストが掛かります

テストを自動化しました。もうテストし直す必要はありません。

仕様変更するとテストコードを全部直すのでコストが掛かります。

最小コストでテストコードをメンテナンスする

オブジェクト指向




開発プロセスのとらえ方（１／２）

プロセスはそれを設計した人にとって最適されたものスキル、経験、企業文化、開発製品も異なる人たちのプロ

セスが自分にとって最適なのか？自分にとっての最適プロセスを見つけることが大事

XP Scrum UP

ケントベックサザーランドヤコブソン自分

？




開発プロセスのとらえ方（２／２）

開発プロセスの本に書いてあることは、膨大な経験・ノウハウの成功例の上澄み液

バックグラウンドを理解しないでそこだけをなぞっても、うまくいかない

自身でプロセス設計を行う過程である程度バックグラウンドを理解できる

プロセス本に書いてある事

バックグラウンド成功経験、失敗経験

チャレンジ、分析、ノウハウ




レビュー

レビューは上流で不具合の除去を目指す

製品

テストレビュー

実装機能仕様 IF仕様

Soft-Soft/ Soft-Hard

テスト仕様

ユーザ要求を満たすか実装の入力として条件に漏

れがないか

担当者間の認識の違いが無いか⇒CI

テストケースが網羅されているか無駄／冗長が無いか

テスト


アジャイルプラクティス導 入による組込みシステム開 発の ... · 2017. 9....

Documents

アジャイルプラクティス導入による組込みシステム開発の ... · 2017. 9....