AndroidエミュレータとPCをUSB接続せよ！：実践しながら学ぶ Android USBガジェットの仕組み（8）（1/2 ページ） 起動不能になったPCを救出するアプリ「PCRescuroid」の配信を断念し、Androidフレームワーク層の改造に踏み切ったわれわれの前に一筋の光明が！ このアイデアが実現できたら世界初かも!? 「AndroidエミュレータとホストPCをUSB接続する」という新たな挑戦に向けたプロローグをお届けする。 はじめに 繰り返しになりますが、起動不能になったPCを救出する「PCRescuroid（ピーシーレスキュロイド）」のアプリ配信を断念せざるを得なくなったため、われわれは前回、PCRescuroidの機能実現のために“Androidフレームワーク層を改造する”という道を選択しました。 いまだにメンバー内には「何とかならないものか……」という思いがくすぶり続け

【総まとめ】ソフトウェア技術者の最高の能力は見積もりだ！：山浦恒央の“くみこみ”な話（47）（1/2 ページ） 「『見積もり』は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つである」――。見積もり・シリーズついに完結。これまでお届けしてきた重要ポイントをおさらいする！ はじめに 2011年5月から全16回にわたって、ソフトウェア開発におけるスケジュールやコストの“見積もり”について紹介してきました。 これまで何度も繰り返してきた通り、「『見積もり』は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります」。 この“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり

前回に引き続き、“契約条件”の面から実践できる見積もりミス対策を検討する。客観性のある見積もり技法を2つ以上学び、その技法の具体的な適用方法を習得し、さらに、契約面からも見積もりミスに対処できるようになれば、あなたは立派な「見積もりの“黒帯”」だ！ 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 “見積もり・シリーズ”の振り返り 本シリーズでは、見積もり技法の

実際に、要求仕様から状態遷移表を作成するプロセスを紹介する。モデリングを行いながら、要求仕様書で定義されていない曖昧な部分を検討し、明確化。上流工程の段階でモデルを洗練しておくことで、無駄のない最適なソースコードを作成できる。 はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です。そして、不具合発生による手戻りコストの削減や開発効率の向上にも役立ちます。 こうした理由から、組み込みソフトウェア開発の世界では、長年、状態遷移系モデルで設計が行われています。 さて、前回は“なぜ状態遷移表を使うと、品質の良い開発ができるのか”を紹介しました。今回は「状態遷移表を使用した要求分析モデル」をテーマに、具体的に要求仕様から状態遷移表を

なぜ状態遷移表を使うと、品質の良い開発ができるのか：状態遷移表による設計手法（2）（1/2 ページ） はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。そして、この設計品質の向上にはモデルベース設計が有効であり、数あるモデルの中でも“状態遷移系モデル”が最も多く使われています。このあたりの詳細については、前回お伝えした通りです。 本連載の主役である「状態遷移表」は、“イベント“と“状態”を全て網羅的に表現できるため、設計の「モレ」「ヌケ」の発見・防止に大きな効果があり、設計品質の向上が期待できます。 第2回では「なぜ状態遷移表を使うと、品質の良い開発ができるのか」をテーマに、その詳細を説明していきます。 なお、本連載では以下の6つのテーマを順番にお届けしていきます。 （前回）：状態遷移表設計手法の概要 なぜ状態遷移表を使うと、品質の良い開発ができるのか 状態遷移表を

次は「サッカー」「ダンス」だ！――「神戸こどもロボットクラブ」で二足歩行プログラミング体験：ロボット開発リポート（1/2 ページ） 2012年3月24日、神戸市機械金属工業会が、神戸RT（ロボットテクノロジー）構想の拠点「神戸ロボット工房」に新設された「神戸こどもロボットクラブ」に、二足歩行ロボット「VariBo」を20体寄贈した。本稿では、神戸RT構想と、贈呈式後に行われたロボット工作教室の模様についてリポートする。 神戸RT構想とは 神戸RT（ロボットテクノロジー）構想は、1）ロボット開発を通じた産学民官の連携によるモノづくり技術の高度化と市内産業の振興、2）次世代を担う子どもたちにロボットを通じた夢とモノづくりの楽しさを伝える、3）ロボットによる豊かで安全・安心な街づくりの実現の3つを目的としている。 本構想の原点は、1995年の阪神・淡路大震災の経験から、レスキューロボット・レスキ

ついに登場！ 究極の見積もり技法（その4：最短開発期間の算出）：山浦恒央の“くみこみ”な話（41）（1/2 ページ） 「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は筆者お手製のExcelシートの計算式を使い、“開発エンジニアを何千人・何万人投入したとしても、「この期間」よりも絶対に短く開発することはできない”というSLIMのトレードマーク「最短開発期間」の計算方法を解説する。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケ

巡視船「まつしま」にならいレーダーで津波を捕捉！ 太平洋沿岸に「TSUNAMIレーダー」を設置：沖合30km、到達15分前に津波を捉える ウェザーニューズは、津波を観測・捕捉する「TSUNAMIレーダー」を開発し、東北から北関東の太平洋沿岸部9箇所に設置。捕捉可能範囲は沖合約30kmで、津波が沿岸に到着する最大15分前に捕捉できる。 ウェザーニューズは、津波を観測・捕捉する「TSUNAMIレーダー」を開発し、東北から北関東（青森県、岩手県、宮城県、福島県、茨城県）の太平洋沿岸部9箇所に設置したことを発表した（2012年3月5日発表）。 TSUNAMIレーダーは、海底地震発生時に生じる海面の変動（＝津波）を捉えるもの。捕捉可能範囲は沖合約30km。津波のスピードは海底の地形や水深で変化するが、時間に換算すると津波が沿岸に到着する最大15分前に捕捉できるという。また、2秒に1回の観測が可能で、

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」のトレードマークといえる“最短開発期間”の概要を解説する。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。第38回のコラムから、パラメトリックス法の1つとして、「SLIM

「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」を取り上げます。上司からのムチャな開発期間の短縮要求をはねのける“究極の反撃法”が、このSLIMによる見積もりです。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回は