IoT設計製造のテンプレ・ガントチャート～Shiftall流、設計製造のポイントを添えて | Shiftall blog
Shiftall代表の岩佐です。 ESP32やRaspberry piを使って1品もののちょっとした試作機を作ったことがあるという人は増えてきましたが、いわゆる『量産品』を作った事がある人はそう多くはありません。また、大手企業に勤めていて量産品に関わったことがある人であっても、電気・メカ・ソフト・部品調達・品質評価・デリバリーなど開発の全プロセスを俯瞰して見た経験のある人は稀でしょう。 そこで本年を締めくくるShiftallブログネタとして、何十品目という家電・IoT製品のスケジュールチャートを引いてきた立場で、製品開発全体のガントチャートをどう引くか？をご紹介したいと思います。IoTの肝となるスマートフォンアプリ＆サーバサイドのガントチャートについては世に山ほど解説記事があるのでここでは省略します。 まず、全体工程のパート分けを行います。 電気 機構 組み込みSW App/Server（
幻の白いカラスを追い求め、僕らはインドにたどり着く
CMMレベル5の認定を受けたインドの会社に発注したはずが、品質が悪い。こうした悲劇がなぜ起こるのか？ そのメカニズムを考えてみよう 前回のコラムで紹介したように、絶望的に不足している組み込み系ソフトウェア開発技術者を補うものとして期待されているのがインドなどへのソフトウェア開発の海外発注です。インドは、レベルの高いハイテク技術者を安価に大量に提供できる能力を備えており、まさに需要と供給がピタリと一致しているのですが、懐石料理の繊細な風味をカレー粉の鮮烈さで塗りつぶすように、両者がうまく融合した例はほとんど聞きません。今回は、この悲劇が起きるメカニズムについて考えてみます。 インドのソフトウェア開発会社が日本でセールスを展開する場合、殺し文句として使うのが「ウチは、CMMのレベル5の認定を受けています」でしょう。“CMM（Capability Maturity Model）”とは、ソフトウェ
状態遷移表を使用した要求分析モデル
実際に、要求仕様から状態遷移表を作成するプロセスを紹介する。モデリングを行いながら、要求仕様書で定義されていない曖昧な部分を検討し、明確化。上流工程の段階でモデルを洗練しておくことで、無駄のない最適なソースコードを作成できる。 はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です。そして、不具合発生による手戻りコストの削減や開発効率の向上にも役立ちます。 こうした理由から、組み込みソフトウェア開発の世界では、長年、状態遷移系モデルで設計が行われています。 さて、前回は“なぜ状態遷移表を使うと、品質の良い開発ができるのか”を紹介しました。今回は「状態遷移表を使用した要求分析モデル」をテーマに、具体的に要求仕様から状態遷移表を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
中国で驚きの「速攻開発」 雨後の竹の子、AIスピーカー
【専門記者が振り返る】要件管理とトレーサビリティ、この1年――ISO 26262適合で日本でもツール基盤の導入進む