ソフトウェアアーキテクチャはプロジェクトを救うか [arch]
金曜の夜に同僚と飲みに行き，「ソフトウェアアーキテクチャ」や「ソフトウェアアーキテクト」の定義を何時間も議論するのもどうかと思うが… 彼の「アーキテクチャ」の定義は制約を形にしたもの．「アーキテクト」の定義は監視役． 私の「アーキテクチャ」の定義は意思決定 (もしくは意思決定ツール)．「アーキテクト」の定義は組織によって変わる (高層ビルの建築家と木造住宅の建築家は別物)． 「意思決定」を補足すると，よく「線引きをする」という表現が使われると思うが，本来引かれるべき線は直線ではなく，ぐにゃぐにゃした線ではないだろうか．直線なら素人が引いても10回に1回は成功するかもしれないが，ぐにゃぐにゃした線は当てずっぽうでは引けない．視野を広く持ち，制約・ビジネスに対する影響・トレードオフなどを鑑みて，妥協するところは絶妙に妥協し，譲らないところは1歩も譲らずに引いた線とその表現がアーキテクチャだと思
ソフトウェアアーキテクチャ その7 - パターンの実際 [arch]
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つ目は，同じ問題に対して異なるアプローチがそれぞれどう作用するかと
![ソフトウェアアーキテクチャ その7 - パターンの実際 [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/df7abb2e41883e0d2f434fc3e62d0b642e7e4d18/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FANbyha1PB6QSvxoVJdcOjCce9Q2En8Yw5BGMQYBg7tg1AJ8ll5j2gOo-QvPrcN-l8x9QMIGk-qHDFw0EGRpW6zpLITZpDuu9ZP5nq7ZUY2KeOmOjnHDisJmwvMPjA-svyQdI9vN91g%3Dw1200-h630-p-k-no-nu)
ソフトウェアアーキテクチャ その6 - パターンとその解釈方法 [arch]
'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 は，要素と要素間の関係，またそれらの組み合わせに関する制約を定義し， 過去に実
![ソフトウェアアーキテクチャ その6 - パターンとその解釈方法 [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/da74f836f0e042b9a5e058eb1056b64ad6f10e4a/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FANbyha1OnIamlgFM8AS0OCbuwAvHHGzQp24I5x1DqyJ8T-ZAYaBhilv2dKxH-Fvte6pbGLlw6tvCGkrBqhv5ZLeghRC4AVLjd2QeUaOAeiTa2sOMcINkuXvkwvlFhKkFfXm3oMFI7g%3Dw1200-h630-p-k-no-nu)
ソフトウェアアーキテクチャ 番外編 - QAW [arch]
今回の番外編は，Quality Attribute Workshop (QAW) というものの紹介． Reference: Quality Attribute Workshops (QAWs), Third Edition by M. Barbacci, R. Ellison, A. Lattanze, J. Stafford, C. Weinstock, W. Wood Technical Report CMU/SEI-2003-TR-016: Software Engineering Institute, 2003 ここまでで品質特性がいかに重要かを再三述べてきたが，実際に品質特性を正しく定義することは非常に難しい． QAW とは，関係するステークホルダーを全て集めて，丸一日かけてプロジェクトの品質特性を，品質特性シナリオまで含めて定義してしまおうというイベントで， 1. QAW Pr
ソフトウェアアーキテクチャ その5 - 品質特性の実現手法 [arch]
Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． アーキテクチャ決定要因を分析し，優先順位もつけたとしよう．ではここから具体的に特定の品質特性を実現するにはどうすれば良いのだろうか． 本書ではこの実現手法を "tactics" と呼び，その集合を "architectural strategy" と呼
![ソフトウェアアーキテクチャ その5 - 品質特性の実現手法 [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/4850ad6b232acc1989aafc07236b15753ad7f900/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FANbyha2zJ-kSxFtvQ-DLwz7COWQ9kAKpiDHaCZBtHg-oW4nb9vDrhRy0zGPWGHqvj9O3T7qj0T6_f-RR4lSwTXuKEAnqReUIAUE64sXal4ftxpgDwc2R15UKmt3D4iwYIeP_uT-Zew%3Dw1200-h630-p-k-no-nu)
ソフトウェアアーキテクチャ その4 - アーキテクチャ決定要因と品質特性 [arch]
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
![ソフトウェアアーキテクチャ その4 - アーキテクチャ決定要因と品質特性 [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d39783b1c594c934484b79a62718fe607d18ed4/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FALY8t1tueREyYc3hLfKNQTV15uHOW3fltPRnYLKPpRv4QFYjDMgvN47J1vkDLWLe-9WFU8hsS6r8z_gxLTOmlIQ--TGJL-JgrgLtu9bWzKZDd6UStsRqr_wz5TrBVGEhp1JJmAip6Q%3Dw1200-h630-p-k-no-nu)
ソフトウェアアーキテクチャ 番外編 - 本質的な検討を行う為に [arch]
今回は息抜きに「番外編」として，Paul Clements の興味深いエッセイを紹介しよう． Reference: Essays on Software Architecture - What's the Difference Between Architecture and Design? 「『アーキテクチャ』と『設計』の違いは?」というタイトルであり，これに対する Architecture is design, but not all design is architectural. という言葉は，Clements の名言だと思う． 私は業務でソフトウェアの上流設計を行っているが，ついつい細かすぎることまで考えてしまい，全体のアーキテクチャ設計という観点から外れた部分に陥ってしまうことが時折ある．今週も SEI のアーキテクトと話す機会があったが，議論の中でやはり彼が "Is this
ソフトウェアアーキテクチャ その3 - 表現方法のコンセプト [arch]
今回はソフトウェアアーキテクチャの「表現方法」について． 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 のアーキテクチャ仕様書がそのまま
![ソフトウェアアーキテクチャ その3 - 表現方法のコンセプト [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/3dfba0a980dd86d4d804bceab0846308a2da650d/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FANbyha2cBPci4skxW2mTeK0ZrXaYqa6RSaUjJYEJE4IdSDTRSrxMbMpxTfOlHBrmDaIdjnyS5B2rFSZQm-guVZZTNcEQuqFxUckM6Inx-YC49RxC2mvmCJ7EBmPKjjoB9iZG5Od_%3Dw1200-h630-p-k-no-nu)
ソフトウェアアーキテクチャ その2 - 「ソフトウェアアーキテクチャ」とは [arch]
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
![ソフトウェアアーキテクチャ その2 - 「ソフトウェアアーキテクチャ」とは [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/801367cd7b895675269a8bc52683ed83e13d2eb4/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FANbyha28imqTg0AuBwL-zOtRqnof8oyYYaUQWcPotgjzrnNPCsq2M5eES9NMSGgl72hTHHCAh3BiSwwWbxkDiVml0kl0q3bPRmsrar9m3gR35kn94IuXyAuxUWZrdQ8_0rgcUmBh6w%3Dw1200-h630-p-k-no-nu)
ソフトウェアアーキテクチャ その1 - ソフトウェアの現状 [arch]
ここ最近，ソフトウェアアーキテクチャについて深く携わる機会がある．経緯や素性についてあまり詳しいことは書けないが，内容については Blog で公開しても良いとの許可を関係者に頂いたので，これから何回かに渡り情報を共有したいと思う． Blog に書くからには定期的に更新していきたいと思うし，ご意見やご指摘等，幅広くコメントを頂けるとありがたい． 具体的な内容は次回以降に譲るとして，まずは少し概念的なところから始めてみよう． Reference: Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan, Prentice Hall 1996 --> Chapter 1 ソフトウェアアーキテクチャを最初に定義した本． 1996年発行と内容は少し古く，今日の開発に実践で
![ソフトウェアアーキテクチャ その1 - ソフトウェアの現状 [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/60d1f8b3778561aa642416c7500177e05abbcbeb/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FANbyha2e6kXUmsrNnvZeDWgUbGeO69lIaw-1ZgwUdWboaN4Jr2CVbByDbcvHwqzLmPYB8yW0n2SNjGYuiriG1qvmO91J5L2SMiO9mG_zyb5Ou0-DSE0g4TQgVWgfk6GWIV1_er1TeQ%3Dw1200-h630-p-k-no-nu)
コミュニケーションにおいて，してはいけない10の禁止事項 [memo]
昨日のエントリーでは，John Rosemond の「家族力」という本について親の立場でレビューを書いたが，子育てについてのこの本の中で一際印象に残っているのが「しつけとはリーダーシップであり，しつけで一番重要なこと - つまりよいリーダーになるためにもっとも重要な特性 - は，コミュニケーション能力である」と言及している点だった． Peace Pipe: 家族力 - 「いい親」が子どもをダメにする [memo] 「しつけはリーダーシップ」という言葉に，非常に感銘を受けた． 私は会社ではリーダー的立場にあり，それなりにリーダーシップやコーチング手法を体得しようとしてきた．またこの Blog でも，「エンジニアにとって，技術力よりさらに重要なのはコミュニケーション能力である」と何度も述べてきた．それが，子育てでも同じだと著者は言うのだ． --中略-- 大部分の親たちが使う「ミルクトースト・ス
![コミュニケーションにおいて，してはいけない10の禁止事項 [memo]](https://cdn-ak-scissors.b.st-hatena.com/image/square/ba4281bfedb15aa8c4a140f35bd0b77eb3ca02e4/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FANbyha1VJiL_504Fed080b1DE4WESAuY6BiBMl_1clsiQ9S64kK8MBqT01eq2NIkE4nEMjx5ysy2MzelTdmXn76ULyy2YZW_Xf7lEiW--a7a32cISaqXZ5Jvtc8nZ20huQ-Iq-waKA%3Dw1200-h630-p-k-no-nu)
ADD(Attribute Driven Design) 品質特性駆動型設計 - アーキテクチャ設計の実際 [arch]
Software Architecture in Practice (Sei Series in Software En ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必... アーキテクトのバイブルとされる本．SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている． タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている． こちらがその和訳本． 本書第7章では， - ライフサイクルにおけるアーキテクチャ - アーキテクチャ設計 - チーム構成と，組織がアーキテクチャに及ぼす影響 - スケルタルシステムの構築 を扱っている． それぞれに非常に興味深い内容だが，今回はライフサイクルについて軽く触れ
ソフトウェアアーキテクチャ その10 - プロダクトラインでのパターン選択ケースタディ [arch]
本シリーズも前回から「実践編」というフェーズに入ったが，今回は実開発における 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
![ソフトウェアアーキテクチャ その10 - プロダクトラインでのパターン選択ケースタディ [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/d5f9c3729e28379e067e2418996316eb3b5ec887/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FAHs97-kMvTRcXAEgL-0crjVgl42poVeGzbn1C6mmfPyEzUsAHeAidv9qGBFTj-7gej8qZHwvztFikseovWUR9oA0QtdziEW3rVlPRTmlCC-gjF5g7LL0jIG49CUu_bKwqD431dfGoQ%3Dw1200-h630-p-k-no-nu)
ソフトウェアアーキテクチャ その12 - ドキュメントを書く上での6つのテクニック [arch]
前回 に引き続き，ドキュメンテーションについて． 前回は「健全なドキュメントを書く7つのルール」を紹介したが，今回は「ドキュメントを書く上での6つのテクニック」を紹介したいと思う． 本シリーズでアーキテクチャドキュメントを扱うのは，今回で最後の予定． Reference: Documenting Software Architectures: Views and Beyond, by Clements, et al. Addison-Wesley 2003 --> Chapter 9, Chapter 11.1 - 11.3 タイトル通り，アーキテクチャのドキュメント記述方法に関する本で，SEI の Product Line Systems Program の成果物の1つとして出版された．Product Line とは，SEI の代表的貢献として有名な CMM (Capability Ma
![ソフトウェアアーキテクチャ その12 - ドキュメントを書く上での6つのテクニック [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/994b7ba02f594972eccaa8eddc14d037f705979a/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FAByxGDS4BayNVi5FFRVSka7wPM2LPSvGk0Huwgaavqw2lR61TqCoezZN_OtOwsoMh-vV53FXyRse5je4hJqPolJWpn8Exh4E8sThbgeSuoCZEMH0XnwEhg2iZaLo19A56GvmdLdk%3Dw1200-h630-p-k-no-nu)
ソフトウェアアーキテクチャ その11 - 健全なドキュメントを書く7つのルール [arch]
今回は少し趣向を変えて，ドキュメントの書き方について取り上げたいと思う． "Documenting Software Architectures" に記述されている，「健全なドキュメントを書く7つのルール (Seven Rules for Sound Documenation)」を紹介する． ところでこのエントリーを書きながら，e-mail や Blog を書く時にも当てはまることがいくつもあると思った． Reference: Documenting Software Architectures: Views and Beyond, by Clements, et al. Addison-Wesley 2003 --> Page 24 - 30 タイトル通り，アーキテクチャのドキュメント記述方法に関する本で，SEI の Product Line Systems Program の成果物の1
![ソフトウェアアーキテクチャ その11 - 健全なドキュメントを書く7つのルール [arch]](https://cdn-ak-scissors.b.st-hatena.com/image/square/bbb87ad2867874cfebe8d2583f56b1fba13d817a/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FAHs97-mBZDC1ID2qQqOozyzQRvnxVlf61GHP7zV97eidnZVGkSovFvzijkhKVAi2YdIxZqG_BAX2UUTETui32nZSg7b1zmuK1gohdNHrL_t1g5wsxXcuHvrxm7YSI2XuNRpH3GPL%3Dw1200-h630-p-k-no-nu)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
