「夏のソフトウェアプロセス改善セミナー in 大阪」に参加した。午前中は2つの講演、午後はチュートリアルという構成だった。ここでは午前中2つの講演（ご講演順）を紹介する。 森田祥男氏（ソニーグローバルソリューションズ）「プロセス改善の真髄 ～ 日本のソフトウェア産業の発展にむけて ～」（SPI Japan 2003最優秀発表賞受賞） 阪本太志氏（東芝デジタルメディアエンジニアリング）「8年目のSPI　～ 継続的に改善するための秘訣 ～」（SPI Japan 2006プログラム委員長賞受賞） 私が印象に残った点は以下のとおり。 無用なルールの押し付けはダメ。 パートナ（派遣）さんによる人材確保の割合が高くなっている、後輩や部下が少ない年代の存在など、品質に関する知識の伝承を阻害される原因が増えている。 阿吽の呼吸で成り立っている日本企業にISOベースのドキュメンテーションの文化、責任と権限を

Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． "Software Architecture: Perspectives on an Emerging Discipline" の第3章には，合計7つのケーススタディが紹介されている．1つ目は，同じ問題に対して異なるアプローチがそれぞれどう作用するかと

'Pattern' の定義については，'View' や 'Viewtype' といった概念も含めて，第3回 参照． Reference: Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan, Prentice Hall 1996 --> Chapter 2 ソフトウェアアーキテクチャを最初に定義した本． 1996年発行と内容は少し古く，今日の開発に実践できる内容は少ないが，ソフトウェアアーキテクチャのいわゆる「クラシックエッセンス」に触れることができる． エンジニアとして「自分の引き出しを増やす」という意味では，ぜひ手元に置いておきたい1冊だ． 第3回で述べた通り，pattern は，要素と要素間の関係，またそれらの組み合わせに関する制約を定義し， 過去に実

Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． アーキテクチャ決定要因を分析し，優先順位もつけたとしよう．ではここから具体的に特定の品質特性を実現するにはどうすれば良いのだろうか． 本書ではこの実現手法を "tactics" と呼び，その集合を "architectural strategy" と呼

Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． 一般的に，要件は - 技術制約 (Technical Constraint) - ビジネス制約 (Business Constraint) - 機能要件 (Functional Requirement) - 品質特性 (Quality Attribut

今回はソフトウェアアーキテクチャの「表現方法」について． Reference: Documenting Software Architectures: Views and Beyond, by Clements, et al. Addison-Wesley 2003 --> Part I タイトル通り，アーキテクチャのドキュメント記述方法に関する本で，SEI の Product Line Systems Program の成果物の1つとして出版された．Product Line とは，SEI の代表的貢献として有名な CMM (Capability Maturity Model) に比べれば後発だが，最近注目されているソフトウェア開発の新しいアプローチの1つであり，本シリーズでもいずれ取り上げる予定． 本書には，Appendix に ECS Software のアーキテクチャ仕様書がそのまま

Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． ではまず「ソフトウェアアーキテクチャ」について，SEI (ソフトウェアに関する最も権威のある研究機関の1つ) の定義から見てみよう． How Do You Define Software Architecture? Software architect

ここ最近，ソフトウェアアーキテクチャについて深く携わる機会がある．経緯や素性についてあまり詳しいことは書けないが，内容については Blog で公開しても良いとの許可を関係者に頂いたので，これから何回かに渡り情報を共有したいと思う． Blog に書くからには定期的に更新していきたいと思うし，ご意見やご指摘等，幅広くコメントを頂けるとありがたい． 具体的な内容は次回以降に譲るとして，まずは少し概念的なところから始めてみよう． Reference: Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan, Prentice Hall 1996 --> Chapter 1 ソフトウェアアーキテクチャを最初に定義した本． 1996年発行と内容は少し古く，今日の開発に実践で

昨日のエントリーでは，John Rosemond の「家族力」という本について親の立場でレビューを書いたが，子育てについてのこの本の中で一際印象に残っているのが「しつけとはリーダーシップであり，しつけで一番重要なこと - つまりよいリーダーになるためにもっとも重要な特性 - は，コミュニケーション能力である」と言及している点だった． Peace Pipe: 家族力 - 「いい親」が子どもをダメにする [memo] 「しつけはリーダーシップ」という言葉に，非常に感銘を受けた． 私は会社ではリーダー的立場にあり，それなりにリーダーシップやコーチング手法を体得しようとしてきた．またこの Blog でも，「エンジニアにとって，技術力よりさらに重要なのはコミュニケーション能力である」と何度も述べてきた．それが，子育てでも同じだと著者は言うのだ． --中略-- 大部分の親たちが使う「ミルクトースト・ス

Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． 本書第7章では， - ライフサイクルにおけるアーキテクチャ - アーキテクチャ設計 - チーム構成と，組織がアーキテクチャに及ぼす影響 - スケルタルシステムの構築 を扱っている． それぞれに非常に興味深い内容だが，今回はライフサイクルについて軽く触れ

グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、

プログラマーの生産性をテーマにした有名な著書「ピープルウェア」には、最も優秀なプログラマと最低の成績のプログラマのあいだには約10倍にあたる生産性の違いがある、というデータが出てきます。 これは、1984年から1986年にかけて92社、延べ600人が参加したプログラミングコンテストのデータを分析した結果から導き出された結果で、課題として与えられたプログラミング作業の開始からコンパイル時のエラーを消すところ（第1チェックポイント）へ到達するまでにかかった時間を比べています。 グラフを見ても分かるように、最優秀者と最低者のあいだには作業時間にして約10倍のひらきがあります。また最優秀者は平均の約2.5倍の生産性だそうです。そして、COBOLやFortranのような旧世代のプログラミング言語と、PascalやCのような現代的なプログラミング言語でのコーディングでの生産性はほとんど同じであったそう

本エントリは「［ディスカッション］ソフトウェアインスペクション／コードレビューを成功させる方法（前編）」の続きです。 パネリスト（50音順） 越水喜之氏（日本IBM） 細川宣啓氏（日本IBM） 森崎修司氏（奈良先端科学技術大学院大学） モデレータ 新野淳一（前＠IT発行人、現Publickey編集長） 欠陥を指摘するためのテクニック 新野　ソフトウェアインスペクション／コードレビューの現状の分析をパネリストにしていただいたところで、次は、明日から使えるソフトウェアインスペクション／コードレビューのテクニックを紹介してもらおうと思います。 そういえばこのあいだ細川さんの情報処理学会の論文を読ませていただきました。で、そこにインスペクションのテクニックには2つある、って書いてあったんです。1つは発見するテクニック。もう1つは指摘するテクニックだと。指摘するテクニックってそのとき始めて知ったので

Hands-on with the new iPad Pro M4: Absurdly thin and light, but the screen steals the show

本シリーズも前回から「実践編」というフェーズに入ったが，今回は実開発における pattern 検討の例として，第7回で reference としたケーススタディ群の別のケースを紹介したいと思う． Reference: Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan, Prentice Hall 1996 --> Chapter 3.2 ソフトウェアアーキテクチャを最初に定義した本． 1996年発行と内容は少し古く，今日の開発に実践できる内容は少ないが，ソフトウェアアーキテクチャのいわゆる「クラシックエッセンス」に触れることができる． エンジニアとして「自分の引き出しを増やす」という意味では，ぜひ手元に置いておきたい1冊だ． 本書第3.2章では，実際に T

ソフトウエア・テストのカンファレンス「JaSST」の開催を主導するなど，ソフトウエア品質の分野で精力的な活動を続ける電気通信大学の西康晴氏に，現在の組み込みソフトウエア開発における問題点と解決策を解説してもらった。継続的に品質を高める体制を構築するための取り組みについて，プロジェクト・マネジメント，プロセス改善，テスト・レビューの3つの観点から概要を述べる。 この記事は，「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。別冊の詳細はこちらをご覧下さい。 筆者は，数年前までソフトウエアの品質コンサルタントをしていた。現在でも企業との共同研究を通して，ソフトウエアの品質向上手法の開発などを手掛けている。特にここ3～4年は，組み込み分野の企業からの相談が非常に増えてきている。家電や車