組み込みソフトウェア開発向けコーディング作法ガイド（ESCR)

DM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」
の第７回（今回から三田）

組み込みソフトウェア開発向けコーディング作法ガイド解説


つまり、ESCRの話を聞いてきたのでメモメモ

---

組み込みシステム開発者技術リファレンスESｘRシリーズ
　　開発プロセス
　　プロジェクトマネジメント
　　プロジェクト計画立案
　　コーディング作法ガイド
　　品質作りこみガイド

■第一章　組み込みソフトウェアにおけるコード品質
１．１　組み込みソフトウェア開発の現状
　　組み込みソフトウェア産業実態調査
　　　　ソフトウェアが原因の問題：半分くらい
　　　　　　→なんとかしないと
　　　　不具合の１／３は、実装工程で作りこまれている
　　　　　　→コーディングに問題
　　　　避けるような作法ガイドに

１．２　コード品質
　　ソフトウェア実装・単体テストの流れ
　　　　コーディング規約
　　　　レビュー観点リスト
　　コーディング規約：あまり使われていない
　　　　流用：もともとのコードの品質影響
　　実装時にレビューしないで、テストでまかなっている
　　　　コーディング規約と静的診断ツール
　　コーディング規約は形骸化している
　　　　命名や書式にこだわりすぎ
　　　　守れないルール・チェックしづらい
　　　　更新されていない。個々のプロジェクトに対応していない

１．３　コーディング規約
　　コーディング規約を守れるようにするために
　　　　必要性がわかるように
　　　　作法をC言語に落とし込む
　　　　カスタマイズしやすいルール
　　　　基本的に押さえるべきコーディング技術を取得
　　　　　　ルールの集合

■第二章　適用事例
２．１　コーディング規約の運用事例
　　静的解析ツールを使用して、コード品質の改善を図っているが、
　　　　様々な課題を抱えている
　　挙がってきた問題点
　　　　開発者がコード品質を上げる意識なし
　　　　ツールが多く指摘：重要点をみうしなう
　　　　対応が表面的になりがち

　　コーディング作法の導入

　　実装の段階で、解析

　　保守性を重点的に

２．２　コード品質を向上するには
　　効果を得るためのアプローチ
　　　　コーディング規約の教育
　　　　プロダクトの目的に適したコーディング規約の作成
　　　　ツールの有効活用
　　　　実装プロセス改善

■第三章　ESCR
３．１　コーディングミスの実際
　　・プログラミング言語の基本的な使い方を理解しただけでは、
　　　実際のソフトウェア開発には対応しきれない
　　・ソースコード中に実行されることのない式や文を記述したまま
　　・型に対する制約範囲を意識する
　　・メモリ操作
　　・論理演算の勘違い
　　・タイプミス
　　・コンパイル依存

３．２　ESCRの内容
　　特徴
　　　・体系化された」作法とルール
　　　・すぐ使えるリファレンスルール
　　　・ルールの必要性をを提示
　　　・他のコーディング規約との対応関係を明示
　　　　　　MISRA　C(みすらーC)
　　基本構成
　　　作法とルールを体系化
　　　　　品質概念：信頼性、保守性、移植し、効率性
　　　　　作法:言語依存しない
　　　　　ルール：言語依存

　　　例：
　　　　作法概要
　　　　　　信頼性１：領域は初期化し、大きさに注意して使用する
　　　　作法詳細：具体的な実装の考え方
　　　　ルール：作法詳細ごとにある
　　　　　　コード例、必要性の提示
　　　　　　選択指針：規約にする必要性
　　　　　　規約化：詳細化する必要性
　　　　作法５１、ルール１２９

３．３　品質特性ごとのルール紹介
　　細かいルール紹介（省略）


３．４　ESCRを使用した実装品質向上への取り組み方
コーディング規約を作る手順
　　（１）コーディング規約作成方針の決定
　　（２）コーディングルールの選択
　　　　　　　選択指針
　　（３）ルールのプロジェクト依存部分定義
　　　　　　　規約化
　　（４）適用除外の手順決定
　　　　　　　文書化

実装プロセスへの適用
　　　要求定義→コーディング規約→ツール→レビュー

継続的改善

効果的に運用していくためには
　　　ESCRを理解
　　　ツール・レビュー
　　　コーディング規約の振り返り

ESCRに対応したツール

利用状況

C++にも対応
　　オブジェクト、ジェネリック、例外
　　構成とかは、Cと同じ作法までは言語非依存なので同じ
　　ルールは言語依存なので違う
　　利用が難しい機能の制限
　　Misra-c++や、EffectiveC++などなどを調査して含めた

ESCRを使い場合の注意点
　　作法ルールをすべて利用するのではない

Redmine、Tracを使った「定量的プロジェクト管理ツール」の紹介

IPAの

日本におけるアジャイル開発に適した契約モデル案と事例
http://sec.ipa.go.jp/seminar/2012/20120523.html

にいってきた。そのときの

Redmine、Tracを使った「定量的プロジェクト管理ツール」の紹介

についての内容をメモメモ

---

Redmine Tracを使った「定量的プロジェクト管理ツール」の紹介

Agile開発におけるプロジェクト管理の課題
・リアルタイム名タスク管理
　　　　・反復開発
・ソースコードの二重、三重、四重・・・管理
・変更管理とバージョン管理

Redmine,Tracとは
　　　　オープンソースのプロジェクト管理ソフトウェア
　　　　バグトラッキングシステム（BTS)として
　　　　課題管理システムへ（Issue　Tracking　System）
　　　　チケット駆動開発へ
　　　　　　　　作業→タスク→チケット
チケットとは
　　　　担当者が割り振られ、作業ごとに状態
Agile開発への適用
　　　　チケットをタスクカードとして使用
　　　　　　　　ボードにはってもいいけど
　　　　チケットをグループ化
　　　　チケット一覧をタスクボードとして利用
チケット駆動開発の利点
　　　　情報共有が簡単
　　　　作業報告の省力化
　　　　残タスク・進捗をリアルタイムに
　　　　ツールとの連携
　　　　トレーサビリティ（履歴として残るので）
　　　　プロジェクト管理の問題を機能へ：ツール自体進化
定量的プロセス管理ツール
　　　　見える化の必要性：作業を楽に
　　　　開発の多様化・短期間化・低コスト化
　　　　　　　　品質、進捗のばらつき
　　　　　　　　　　　　プロジェクトがおかしくなっているのに気づかない

IPAの見える化：３つ
　　　　定性的な見える化
　　　　定量的な見える化
　　　　２つの統合→リスク把握

測定して、何になるの
　　　　→予測ができるようになる
　　　　ベンチマーキング

定量的プロジェクト管理ツールとして公開（４月２７日）

定量的管理の課題
　　　　定量データの工数
　　　　　　　　日常的に使ってるものからデータ
　　　　分析に時間
　　　　　　　　グラフ、直感的に
　　　　現場で使ってるもの違う
　　　　　　　　いったいで提供
　　　　データがたまらないと
　　　　　　　　ためるところをきめる

定量的プロジェクト管理業務
　　　　即時的にデータが見える
　　　　　　　　KKD（勘、経験、度胸）からツールに基づいたプロジェクト管理

（IPAが出した）定量的プロジェクト管理ツールの特徴
　　　　グラフ表示
　　　　既存ツール
　　　　　　　　グラフかく：BIRT、データ収集にPENTAHO
　　　　定量的データの自動収集
　　　　ツールが簡単に利用できることを重視

（そのIPAのツールの）チケット
　　　　プロジェクト管理に足りないものがあったので足していた
　　　　　　　　自由にきっていただいて結構

　　　　各種チケット
　　　　　　　　WBS(タスク）チケット
　　　　　　　　課題チケット
　　　　　　　　障害チケット

（そのIPAのツールの）提供グラフ