第5回

モデルベース開発について(2/2)

 

前回に引き続き、モデルベース開発について紹介いたします。
今回は、モデルベース開発のメリットやデメリット、運用面についてのポイントなどを書きたいと思います。

 

◆メリット
・ブロック線図で表現されるため、処理の流れが視覚的にも分かりやすい。
・設計段階から妥当性確認を行うことで、検証に掛かる工数を削減することができる。
・コードの自動生成が行うことで、ヒューマンエラーによるコーディング時の不具合を排除することができる。

 

◆デメリット
・初期費用が高く専門の技術者が少ない為、導入までの敷居が高い。
・従来開発とモデルベース開発[運用・導入]を平行して行うため、運用までの間、業務負荷が高くなる。
・設計段階で要求の誤りや抜け、漏れが合った場合、間違ったモデル(仕様)のまま開発が進められてしまう。

 

◆運用について
メリット、デメリットで記載した項目もありますが、運用面でのポイントは以下の3つです。

 

<ポイント1>
複数のユーザーで使用する場合は、ブロック図の構成や階層の粒度などの記載ルールを設定し
共通の粒度で作成することが重要となります。

 

<ポイント2>
パラメータの適合や調整等といったことに注視して工数を掛けてしまうこともある為
本来の使用方法の妥当性確認を念頭において利用すること。

 

<ポイント3>
ブロック図の構成や階層を自由に構築、また仕様変更も手軽にできてしまうことで
変更点(要求に対する考え方、対応方法)が残らない場合も起こり得ます。
またその一方で、変更点を残す運用をしようとした場合
妥当性確認の回転速度が低下し効率が悪くなる可能性もあるため
いかに工数をかけずに変化点を残すことができるか、が運用面のポイントであり
継続的な課題といえます。

 

◆自動車業界の現状と課題
私が自動車業界の開発現場に携わり、感じている現状と課題は以下の通りです。

 

<自動車業界の現状として>
自動車に搭載されるECU(電子制御ユニット:Electronic Control Unit)の数は10〜15年前は
10〜20個程度でしたが近年では50個を超える(高級車では100個以上)と大きく増加しています。
車両機能の多様化に伴い、ECUの通信機能が強化、高速化されたことやハイブリッド車の普及も
その要因といえます。
また自動車の先進運転支援システム(自動ブレーキ等)の開発もあり、今後もECUの増加が想定され
複雑化する制御開発に対応するため、さらに効率の良い開発システムの運用が必要となってきている現状があります。

 

<車両の開発費についての課題>
近年はECUの増加、車両機能の拡大に伴い、開発費の増加が大きな課題となっています。
新たに車両を開発する場合、試験用の車両を100〜200台と製作します。
一般的には1台あたり3000万〜4000万といわれており、高いものは1億を超えるといわれています。
1台3000万としても3000万×100台=30億と非常に高額なものとなります。
開発の効率化で製作数を減らしていくことがとても重要な課題です。

 

◆最後に
モデルベース開発は特にハードウェアを伴う大規模な開発に有用だと思います。
運用面に課題の残る開発システムではあるが、まだまだ発展途上の
開発システムであるといえます。
どの開発現場でも諦めずに継続的に改善し最適化していくことが
重要であることを仕事を通じて肌身をもって感じています。
モデルベース開発について解説、言及している書籍やWebサイトは多数あり、
海外では航空開発、金融、エネルギー要素でも活用されていますので
みなさんも興味のある方は調べてみると面白いと思います。


モデルベース開発についての紹介は以上となります。
ありがとうございました。
 

| QMD Editors | - | - | pookmark |
第4回

モデルベース開発について(1/2)     
     
現在自動車業界の開発現場に携わっています。     
その現場で自動車業界を中心に使用されている開発システムが     
ありましたので紹介いたします。
エンジンやトランスミッション、HV車の開発等

多岐に渡って利用されております。
自動車は様々な分野の集合技術から成り立っているため
他分野にも応用できる開発システムであると思いましたので紹介していきます。

◆概要
モデルベース開発とは、シミュレーション技術を取り入れたシステム開発手法である。
※モデルベース開発(Model Based Development)
上流工程(設計)でモデルを作成し、シミュレーションを行うことで設計品質の
向上を図ります。また、上流工程で作成したモデルはプログラムの自動生成
(オートコード)、シミュレータ(HILS:Hardware in the Loop Simulation)を
使用した検証など、全ての工程で効率的かつ品質向上に効果を発揮します。
※モデル:たとえば自動車の場合、エンジンやモーターをモデルとして
(下記画像全体)機能や制御は青、赤、橙、緑のBOXのような構成となります。
機能や制御の流れを含め、図形で表現できるため、視覚的にも分かりやすく
表現できます。(下記図の青BOXの制御)

 

図1.モデル図のイメージ

 

主に工業製品、特に電子機器製品の組み込みシステム開発のプロセスを改善する為の
手法の1つです。現在では、自動車分野における組み込み制御システム開発の現場で
採用され、一定の効果がでていることから注目されています。

 


図2.ウォーターフォール型開発にモデルベース開発を取り入れた図

 

◆特徴
モデルベース開発の主な特徴は以下3点になります。
・モデルによる仕様の表現、定義(実行可能な仕様書)
・モデルのシミュレーションによる詳細設計、妥当性確認
・モデルからの自動コード生成(オートコード)

次回はモデルベース開発のメリット、デメリットについて紹介いたします。

| QMD Editors | - | - | pookmark |
第3回

現在アジャイル開発※の現場に携わっています。
その現場で、クリティカルなバグを効率よく検出するために
リスクベーステストをしているので、そのステップの一例を記載します。
※反復 (イテレーション) と呼ばれる短い開発期間単位を採用することで
リスクを最小化しようとする開発手法

 

■STEP1:イテレーション初期段階でのリスク抽出
イテレーションの初期段階でミーティングを実施し
リリース予定の新規機能、機能改修のリリースによるリスクの抽出を行います。
例として新たに「顧客検索機能を実装する」機能をリリースする場合のリスクを

以下に記載しました。
 

プロジェクトリスク
まだ機能仕様書がない
別案件と業務が重なるためリソースの確保が必要、網羅性のあるテストができない可能性がある
プロダクトリスク
別案件と業務が重なるためリソースの確保が必要、網羅性のあるテストができない可能性がある
共有モジュールに修正が入るため、元々ある他の検索機能(商品データ、店舗)への影響がある
顧客数が多い場合、検索結果が表示されるまで時間がかかる可能性がある
検索テキストボックス新規追加の影響による他UIの使用性の低下

 

企画、エンジニア、QAのステークホルダ間でミーティングを実施し多角的に抽出するポイント。
例えば内部的な影響範囲などはエンジニアにヒアリングをかけないとわからないためテスト実施漏れにつながりやすい。
また各リスクに優先順位をつけることも忘れない。

 

■STEP2:対策の立案
次にリスクに対して施策を立案します。

これもステークホルダ間でレビューをした上で合意を得る必要がある。
抽出したリスクに対しの対策例を赤字で記載しました。

 

プロジェクトリスク

対策

(プロジェクトリスク)

まだ機能仕様書がない ・エンジニア、QAにデッドラインを確認したうえで担当者に仕様書の作成依頼を出す。
・作成する時間がない場合、仕様共有ミーティングを設定する。
・それぞれ締め切りを設け、スケジュール、進捗管理を必ず行う
別案件と業務が重なるためリソースの確保が必要、網羅性のあるテストができない可能性がある 他案件とリソースの調整を実施する
プロダクトリスク

対策

(プロダクトリスク)

共有モジュールに修正が入るため、元々ある他の検索機能(商品データ、店舗)への影響がある クリティカルなバグの流出やデグレードの発生を抑止するため、商品検索、店舗検索の機能テストもスコープに含める
顧客数が多い場合、検索結果が表示されるまで時間がかかり、サービスの正常利用ができなくなる可能性がある 検索処理の性能テストを実施する(目標速度はエンジニアと別途相談)
検索テキストボックス新規追加の影響による他UIの使用性の低下 運用上他機能の使用性が担保されているかUIテストを実施する

 

プロダクトリスクはテスト設計、実行フェーズに落とし込み
プロジェクトリスクは初期段階でつぶす必要があるため締切日を設定しています。
 

簡単なステップを工程に作りこんだだけですが
以前に比べ、テストの抜け漏れ(本番障害流出)が減少し
効率のよい品質の積み上げの実現を肌で感じています。
今後もPDCAしながら最適化を目指します。

| QMD Editors | - | - | pookmark |
第2回

こんにちわ。QMDEditorsの宮崎です。

 

第1回に引き続き、
弊社社員が常駐し、UI・ユーザビリティに関わる評価時
どのようなところを注意すべき個所かという
内容を簡単に説明させていただきます。


アプリ評価時に注意すべきPoint
<iOSの場合>
iOSに起因する問題に対し、
アプリで改善できるものは改善するようにしなければならない。
※OS(メーカー)側に修正をお願いすることはできないため

プライバシーや、アクセシビリティの更新による影響がOSごとに
少なからずあるので、試験実施時には注意する必要がある。
例えば、文字の大きさのほかに太さがOSで追加更新された場合、
表示崩れがないかなどを注意するなど。

 

また、問題・原因が判明した際には修正をした方が良いものもある。

端末の時刻設定はAndroidの場合、

タイムゾーンを意識しアプリ開発・検証を行うが、
iOSの場合、タイムゾーンのほかに、
暦法の変換のされ方も意識し、開発・検証を行う必要がある。
端末の時刻を取得してサービスを提供するアプリは
特に意識しなければならない。

<Androidの場合>
Androidは解像度の種類が多いこともあり、一部の端末のみで
レイアウト崩れが発生することが多い。
※全機種でレイアウト確認できない場合でも、最低でも解像度ごとの確認は必須。

旧型の端末はある程度で見切りをつけることになる。
ただし、新しい機能が追加された時などは古いバージョンに悪影響を
及ぼしていないかなどの確認もしなければならない。

試験対象端末を絞り込む必要がある。
解像度、メーカー、OSのバージョンなどに取りこぼしが無いように注意。

全ての端末で完璧に不具合を無くすのは困難
基本的な機能の確認はしっかりとやる必要があるが、
軽微なものなどは許容することも必要になってくる。

 

宮からは、以上です。

ありがとうございました。

| QMD Editors | - | - | pookmark |
第1回

こんにちわ。QMDEditorsの宮崎です。


今回と次回で、携帯アプリ開発、評価を行っている皆様へ、
弊社社員が常駐した結果、UI・ユーザビリティに関わる評価時
どのようなところを注意すべき個所かという
内容を簡単に説明させていただきます。

 

AndroidとiOSの違いとは?
<iOSの場合>
OS上で稼働するアプリケーションに対し、かなり“ガチガチ”に
制限されているため、OS問題に対してのケアが重要視される

新OSについてはiOS端末へ同時配信となる
※iOS8以上はiPhone4s以降の端末に対し、
 iPhone、iPad関係なく同時配信されている。

 但し、iOS10.0.1については、iPhone4sは対象外となっている。

 

<Androidの場合>
最終製品に仕上げるのは、国内外の多数の端末メーカーになるため、
OS問題(機種ごとに対応OSが異なる)のほかに、
メーカー独自の観点でのケアが必要になる。

Androidの内、SDカード対応機種に置いては、
データの移行が簡単に行えるため、課金サービスを含むアプリについては
暗号化の観点も含めなければならない。

 

AndroidとiOSでアプリリリースについての違いとは?

<iOSの場合>
アプリをAppleストアに乗せる場合は、
審査を通す必要がある。(この審査がとても時間がかかる)
Rejectも多数発生する。

新OSリリースの日付から審査&Reject分を逆算して
アプリ開発、検証を行わなければならない。

iOSアプリはキャリアフリー前提で開発しなければならない。
Androidはキャリア向けサービスをキャリアに絞って展開できるが、
iOSはAppStoreに出す時点で全キャリアに配信となる。

 

<Androidの場合>
アプリ開発者の指定したタイミングでマーケットにあげることが可能。

新OSや新機種発売に合わせて、マーケットにアプリをあげることも
iOSよりは簡単に計画、実行出来る。

 

今回は、以上です。
次回はをお届けいたします。

 

| QMD Editors | - | - | pookmark |
ご挨拶

ブログをお楽しみの皆様

クオリティ・マネジメント・ディビィジョン(QMD)の宮崎です。
※QMD=技術部署名とお考えください。

この度、
社内、外問わず現場で得た知識や経験等を皆様に知っていただきたく思い、
弊社社長のブログ(暴れん坊社長ブログ)を借り、
2016年12月より社員のブログ(QMD Editors)を
発信させていただくこととなりました。

今まで配信させていただきました、
暴れん坊社長ブログもCategoryから
閲覧可能ですので、ご安心くださいませ。

今後、定期的に配信を行っていく予定ですので、
暴れん坊社長ブログを楽しみにされていた方も
そうではない方も是非、見に来ていただけますと幸いです。

簡単ですが、
ブログ切り替えのご挨拶とさせていただきます。


株式会社SPPS
クオリティ・マネジメント・ディビィジョン所属
宮崎智美

| お知らせ | - | - | pookmark |
仕事はじめ
今日が新年の仕事初め。

今年はSPPS始まって以来の大変動の年になります。

2月の決算を待ち、来期始動する新たな取り組みや新サービスなど計画進行中。

公式発表までしばしお待ちください!

本年もよろしくお願いします。





 
| 暴れん坊社長ブログ | - | - | pookmark |