派生開発における変更指示をモデルで表現する（問題編） - Qiita
セイコーエプソンの萩原さんと、モデルを使って派生開発の変更指示をうまく表現できない、という課題を議論しました。考えのメモです。 派生開発における「変更指示」 日本の組込み開発でよく使われる手法である清水さんの「派生開発」(XDDP)ですが、派生前の状態に対して「変更指示」を文書化します。 ソースコードレベルであれば問題は少ないのですが、構造に対しての修正は大域的になり、うまく表現しにくくなります。これをモデルで扱いたい、というのが問題です。 Before/After の問題点 まず考えられるのは、Before と After を示す方法です。 ここから実際の変更を行うのはとても観察力が必要！例えて言えば、間違い探しになってしまいます。 例えば astah などでは diff をとる機能もありますが、もっといい方法はないでしょうか？普通は「赤ペン」を入れたいところ。 さらに言うと、せっかくな
派生開発における変更指示をモデルで表現する（試案編） - Qiita
さて、派生開発の「変更」をどうモデル化するか。。。前回までのあらすじはこちら。 派生開発における変更指示をモデルで表現する（問題編） デルタの導入 欲しいものは、「修正」そのものをストレートに表現することです。なので、クラスの「修正」を表すステレオタイプ、《delta》を導入します。これは、クラスに対する変更指示そのものを示すクラスです。赤ペンで書くことを、少々フォーマルにして、このクラスの中に情報として書いて行きます。さらに、サブとなるステレオタイプ、《add》, 《delete》, 《modify》も導入。 デルタ: 《delta》 追加: 《add》 削除: 《delete》 変更: 《modify》 この 3 つに分け、変更を表現します。変更を「クラス」として閉じ込める分けです。さらに、この変更指示は、上位の変更要求に対応するはずです。この変更要求を「要求」（UMLでは《requi
派生開発、保守開発のレビュー：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
過去のバージョンのソフトウェア（母体、流用元、コア資産と呼ばれることもあると思います）をもとに拡張、変更をして次のバージョンのソフトウェアを開発することを保守開発(software maintenance)、ソフトウェア進化(software evolution)と呼んでいます。同一の過去バージョンをもとに、類似のソフトウェア、サービス、製品を同時に開発する場合には、派生開発と呼ぶこともあります。多数のバリエーションがある機器の組込みソフトウェアを想定いただくと派生開発がイメージしやすいと思います。 こういった過去のバージョンをもとに次のバージョンを開発するときの課題の一つは、過去のバージョンとの整合性を保ちながら新しいバージョンでの拡張、変更を実施することです。こうした開発では、拡張、変更した部分が期待通り動くだけでなく、過去のバージョンで提供されていたものも期待通り動くことが前提となっ
第5回 改造の影響を調べる：詳細な工数とソースコードの変更箇所を洗い出す
対応すべき案件が決まり，いざソフトウエアの改造に臨むとき，間違っても，いきなりプログラムを変え始めてはならない。「変更個所を見つけると，すぐにでもソースコードを変えたくなる。しかし，それでは後から後から変更個所が見つかり，作業に追われてしまうことになる」（システムクリエイツ の清水氏）からだ。 急ぎすぎた改造は，プログラム品質の低下も招く。住友電気工業はかつて，押し寄せる案件に対して，開発担当者が簡単なメモを作る程度で，プログラムの変更に着手していた。情報システム部の中村伸裕氏（システム技術グループ グループ長）は，「対応は早かったが，バグが多かった」と振り返る。こうした反省から，影響分析を徹底するように改造プロセスを改めた。「今ではソースコードの変更方法までレビューしている。レビューが通らない限り，担当者に本番のソースコードは触らせない」（中村氏）。 ソフトウエアの改造に当たり，エンジニ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
三菱電機技報2013年4月号 論文12
http://ftp.techmatrix.co.jp/asq/lattix/document/lattix_impact_analysis_solution_20130326.pdf
モデルベースの手法でコストをかけずに既存システムを分析する連載一覧：CodeZine（コードジン）