「派生開発」を成功させるプロセス改善の技術と極意

  • 182人登録
  • 3.86評価
    • (11)
    • (14)
    • (9)
    • (2)
    • (1)
  • 15レビュー
著者 : 清水吉男
  • 技術評論社 (2007年10月27日発売)
  • Amazon.co.jp ・本 (416ページ)
  • / ISBN・EAN: 9784774132495

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
メアリー・ポッペ...
有効な右矢印 無効な右矢印

「派生開発」を成功させるプロセス改善の技術と極意の感想・レビュー・書評

並び替え:

表示形式:

表示件数:

  • 世界中で,システム設計の現場では、「新規開発」より、「派生開発」としての動いているシステムの変更や機能追加が多い。
    その点に着目した著者の経験が凝縮されている。

    派生開発の場合に何が課題になるかの仕立てをうまくしている。
    仕様をどうやって明確にしていくかについての知見が豊富にある。

    仕立て(tailoring)をしているだけでなく,清水吉男さんのよいところは,現場にあわせた着付け(fitting)もできることだ。

    決めたことを,決めた通りにやるだけなら,能力のある技術者はいらないかもしれない。
    どういう制約条件のもとで決めたことか,条件が変わったらどうするかを考える能力があるかどうかが課題だろう。

    数少ない日本の相談業務(コンサルティング)を頼みたくなる方だ。
    一度,清水さんの話をお聞きになられた方なら感じられたと思う。

    相手を引きつける力
    相手に頼む力
    相手の話を聴く力
    がある。

    自分の経験を大事にする技術者としての感性を持ったまま,
    経営的な課題に取り組もうとする姿勢がある。

    著者の書かれたことを勉強するだけでなく,
    著者そのものを勉強することをお勧めしたい。

  • 現状の業務では、派生開発の機会が多いので、
    実践的な進め方が記載されていて実務に役に立ちそうです。

    既存のソフトウェアに対して、どう機能を変更&追加していくか、参考になりました。

    特にトレーサビリティマトリクスは、新規&派生問わずこれから作成して行きたいです。


    しかし、階層型仕様で核となるMECEに仕様を分解して行くスキルは、実践での試行錯誤で磨いていく必要があると感じました。

  • よくお似合いですよ

  • A2

  • ド新規開発は ほとんど無い。PGが作り出す前に そのPGの理解や解釈を可視化する、というのは、底上げになる。

  • 最近、新規プロジェクトが少なくなってきたと聞く。
    そうであれば、今後は、既存システムの改修案件が増えてくるであろうということで、読んでみた本。

    よくあることだが、ソースを書いた人と保守する人は別の人。
    だから保守する人はどこを直せばよいのか、わからないことがある。
    そんな時、「部分理解」な人でも、できる限り手戻りなく修正するプロセスを確立しておけよってことがこの本の趣旨。

    ごもっともです。

    主軸は、レビューの大切さ。そしてレビュアーに気づいてもらうように(アンカー効果が働かないように)、変更内容の事前準備をすること。

    その方法として、手順は5つ。
    ・変更内容とその理由を記載した、変更要求仕様書を作成すること。
    ・縦軸に変更内容、横軸に画面一覧(ソースファイル一覧)としたトレーサビリティマトリックスを作成すること。これで、修正漏れを少しでも防ぐ。だって同じようなソースが至る所にあること多いもん。
    ・どのように変更するかを記載した、変更設計書を「プログラム言語」ではなく「文章」で作成すること。before/afterを文章で書く。
    ・レビューを実施して、勘違い・考慮漏れなどを無くすこと。
    ・ここでようやくソースコード修正。これ直してよ。ちょろです。直しますね。は、ご法度。

    まあ、C言語っぽい言葉がやたらと出てきて、SVNとか差分管理ツールとかないんかいとか思わせる言い回し、オブジェクト指向を前提としていないよねとか、オフショア開発ではなく1人プロジェクトを主体としていることが前提となっているように読めたから、使えるところだけ使おう。

  • 改善や改修に特化した開発プロセス方法が記載されている。ソフトウェアの話として書かれているが、機械や電気系の人にも役立つと思う。特に、組み込み系をやられている方は、殆どの場合、既存製品のモディファイが開発となると思われるので、参考として手にとってはいかがだろうか?

    XDDPと呼ばれる筆者が考えた方法論が書かれている。背景まで丁寧に書かれているので、手っ取り早くノウハウを得たい人にはやや冗長に映るだろう。基本的に本手法の肝は、要求からの漏れチェックのための視覚化と要求からの変更内容を導く思考過程の可視化だと思った。よって、その場限りのコード改修と異なり、レビューがしやすくなる上、設計者の従来機種への理解が深まるというメリットが有るように思う。

    本手法が新規設計が少ない組み込み業界の開発プロセス標準の一つとなり、多くの設計者が報われるようになることを望みたい。

  • 誤字脱字が多く、口説い説明で読みづらいが、多くの知見が得られる

  • 希望が見えるような気もするけど、自分の問題への適用可能性は正直やってみないと分からないなーという感覚。手法のエッセンスとバックグラウンドについては完全に同意できる。

  • ソフトウェアエンジニアリングの教科書には「新規開発をどう上手くやるか」について書いてありますが、私たちが日々格闘している「派生開発」については「保守」としてひとくくりにされ、十分な記述がありません。

    もちろん、新規開発のノウハウが役立つ部分もあるのですが、筆者の清水吉男は「派生開発の現場では、時間に追われバグを見つけ次第直すという間違ったプロセス」にメスを入れています。
    つまり、派生開発においては、
     o 変更要求仕様書
     o トレーサビリティ・マップ
     o 変更設計書
    を作るプロセスを提案しています。これらは、実践的で非常に役立つノウハウと思います。口語調で話が整理されていないためちょっと読みにくい点がちょっと残念です。

全15件中 1 - 10件を表示

「派生開発」を成功させるプロセス改善の技術と極意を本棚に「いま読んでる」で登録しているひと

「派生開発」を成功させるプロセス改善の技術と極意の作品紹介

いつまで「派生開発」で疲労し続けますか?派生開発にはそれに適したプロセスがある!合理的なプロセスと成果物で構成された「XDDP」でデスマーチから脱却を!確実に派生開発プロジェクトを成功させる実践的方法論の登場。

「派生開発」を成功させるプロセス改善の技術と極意のKindle版

ツイートする