time~派生開発、組み込み開発周りのこと。説明がなされていますが、どうにも掴みにくいと思っており自分なりにまとめたいと思います。Processの略称で、派生開発に対する開発アプローチの総称である。具体的なプラクティス、実践方法については、下記の書籍にて説明されています。XDDPの価値XDDPには以下3つの価値があると考えます。現場はウォーターフォール開発が多く、最初に仕様書を作ってしまったらそれ以降変更することがあまりないなど種々理由で、ドキュメントが残らないことが多いです。そのため、ソースコードのみがある状態からのスタートが多くなります。それらに立ち向かうために形式知化する種々アプローチが提案されています。差分に徹する膨大なソースコード全てを理解することは現実的ではありません。要求仕様よりベース環境から追加機能に必要な差分を検討し、その差分を実装するために必要な領域のみに対して設計を行います。この方針を忘れないようにします。この方針に従うアプローチがベターです。一歩ずつ進める手順を飛ばしてはいけません。時間がなくても、一歩ずつ進めるべきです。焦って憶測で開発を進めても、結局飛ばしたところに戻らないと前に進めなくなってしまいます。1つずつ整理理解して進めていく必要があります。原則がまだよくわかっていません。いうのは私自身がXDDPの経験が不十分だからです。これから少しずつ実践研究していき、原則を発見していきたいと思います。XDDPのプラクティスXDDPのプラクティス(活動)は先の書籍でいろいろ紹介されておりますが、変更3点セットと呼ばれているものが主です。スペックアウトも入れておきます。XDDPを支える表現技法として、USDM*1とPFD*2が存在します。トレーサビリティーマトリクス変更設計書スペックアウトおわりにカイゼンジャーニーにおいて、紹介した内容について価値,原則,プラクティスを著者の方たちがまとめておられました。この価値,原則,プラクティスによって開発アプローチの中身を整理することができそうと思い、自分なりにまとめてみました。これを起点に、少しずつアップデートしていきたいと思います。(AFFORDD)の研究会キックオフに参加しました。月別アーカイブ検索スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。