第5回 改造の影響を調べる：詳細な工数とソースコードの変更箇所を洗い出す
対応すべき案件が決まり，いざソフトウエアの改造に臨むとき，間違っても，いきなりプログラムを変え始めてはならない。「変更個所を見つけると，すぐにでもソースコードを変えたくなる。しかし，それでは後から後から変更個所が見つかり，作業に追われてしまうことになる」（システムクリエイツ の清水氏）からだ。 急ぎすぎた改造は，プログラム品質の低下も招く。住友電気工業はかつて，押し寄せる案件に対して，開発担当者が簡単なメモを作る程度で，プログラムの変更に着手していた。情報システム部の中村伸裕氏（システム技術グループ グループ長）は，「対応は早かったが，バグが多かった」と振り返る。こうした反省から，影響分析を徹底するように改造プロセスを改めた。「今ではソースコードの変更方法までレビューしている。レビューが通らない限り，担当者に本番のソースコードは触らせない」（中村氏）。 ソフトウエアの改造に当たり，エンジニ
XDDPについての議論 - Yasuo's Notebook
先日、リーンカンファレンスでXDDPについてのセッションがあったためか、アジャイル開発実践者の方がXDDPについて言及されているのをよく見かけます。Facebook上でも議論をしたので、その時に書いた私のXDDPについての個人的な感想を書きます。 XDDPを適用する判断基準 まず、私はアジャイル開発とXDDPの両方の経験があり、プロジェクトによって使い分けています。XDDPを適用する判断基準は次の通りです。 自分達でない誰かが作ったプログラムの変更である。 役に立つドキュメントがない。 長い関数が大量になるなど複雑なコードになっている。 変更にかけることができる期間やコストが少ない 特に組み込み系の開発では、上記のような条件に当てはまるものが多いので、その分野でXDDPが支持されている理由の一つなのではないかと思います。XDDPでは、リファクタリングしたりユニットテストを書いたりしないのか
SysMLの要求図の書き方 - プログラマの思索
SysMLの要求図の書き方についてメモ。 間違っていたら後で直す。 【参考】 astah 6.1 で「要求モデル」が目指している姿：An Agile Way：ITmedia オルタナティブ・ブログ 「何故システムモデリングが必要か」 | 株式会社オージス総研 第2回 SysMLとは何か | Think IT 第2回目 SysMLとは？SysMLの現状 : つれづれブログ SysML : つれづれブログ 第3回目 SysMLセミナー感想 : つれづれブログ The Rational Edge：汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述 (1/2) - ITmedia エンタープライズ 「システムエンジニアリングで SysML を使いこなす」第2章 実践編－電光掲示板を設計する(1) astah* professional 6.1の要求図:
問題構造分析とPFDの併用による現実的・段階的な改善実践方法の提案
鈴木三紀夫 @mkoszk_live みなさん、こんにちは。（みんな疲れた感じ） 今日、最後の講演になります。くつろいで聴いてください。 この方法は、自社の問題点を改善するにあたって、使っている方法です。 でも、課題がありました。 PFDを作っていく過程で課題が残りました。 それを解決する方法を考えました。 2013-05-24 16:52:01 鈴木三紀夫 @mkoszk_live 提案の背景。 PFDでプロセス記述が簡単だと思っていません。 PFDを仕事で使っている人、手を挙げて。（以外と少ない） 効果があるなと実感する人、手を挙げて（以外と多いですね） 自社でトライアルしたとき、効果を実感できませんでした。 清水さんの本を読んで試しました。 2013-05-24 16:53:30 鈴木三紀夫 @mkoszk_live スタッフ部門が書けても、現場で書けない。 なぜか。 自分たちの仕事
ソフトウエア改造力
ソフトウエアの改造がトラブルの温床になっている。改造案件が増える一方で，改造ならではの方法論が未熟だからだ。プログラマやSE，プロジェクト・マネージャが一丸となって「改造力」を高めるノウハウを解説する。 第1回 ソフトウエア改造力が足りない：変更ミスがトラブルの温床に 第2回 ソフトウエア改造力が足りない：工数膨らませる影響調査と確認テスト 第3回 対応すべき案件を選ぶ：要望を集め，工数を概算する 第4回 対応すべき案件を選ぶ：費用対効果で優先順位を判断する 第5回 改造の影響を調べる：詳細な工数とソースコードの変更箇所を洗い出す 第6回 改造の影響を調べる：ドキュメントをまとめ作業計画をレビューする 第7回 テスト範囲を最適に決める：過去のテスト項目集めて漏れを減らす 第8回 テスト範囲を最適に決める：シナリオや環境整備でテストを効率化する 第9回 テスト範囲を最適に決める：本番リリース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアエンジニアのためのホームページ Presented by System Creates Inc.
IPA 独立行政法人 情報処理推進機構：SEC主催セミナー「プロセス改善ベストプラクティス」ワークショップ
xddp.jp - このウェブサイトは販売用です！ - 派生開発 プロセス改善 ソフトウェア ソフトウェア開発 セミナー リソースおよび情報
派生開発XDDPガイド サンプル版公開のお知らせ
MI.XDDP Excelアドインツールの詳細情報 : Vector ソフトを探す！
http://researchmap.jp/joxqebp4p-50024/
XDDPへの道 連載は「作業診断試行」 - researchmap
researchmap
XDDPへの道（4）仕様の誤解釈 - researchmap
XDDPへの道（2）CMM - researchmap
XDDPへの道（1）アジャイル - researchmap
日々精進 - スパークスシステムズ ジャパン代表のBlog:既存の機能を組み合わせた、お手軽XDDP支援 (2) - livedoor Blog（ブログ）
日々精進 - スパークスシステムズ ジャパン代表のBlog:既存の機能を組み合わせた、お手軽XDDP支援 - livedoor Blog（ブログ）
派生開発推進協議会・勉強会企画委員会のイベント・セミナー - こくちーず（告知's） イベント・セミナー集客を支援する無料サービス
このページを見るには、ログインまたは登録してください