Upgrade to Pro — share decks privately, control downloads, hide ads and more …

re: iterative development (iteration 4)

re: iterative development (iteration 4)

at rakuten-osaka

seki at druby.org

September 16, 2017
Tweet

More Decks by seki at druby.org

Other Decks in Programming

Transcript

  1. W.Royceͷ࿦จΑΓ Managing the Development of Large Software Systems (1970) ʮWATERFALL

    Model ࠶ߟʯΑΓ ๺཮ઌ୺Պֶٕज़େֶӃେֶ མਫ ߒҰ࿠ ໊લͰग़Φνʂ
  2. W.Royceͷ࿦จΑΓ Managing the Development of Large Software Systems (1970) ਤ͚͕ͩҾ༻͞ΕΔ͜ͱͰ༗໊ͳ࿦จͰ͢ɻ

    I SYSTE M I ANALYSIS PROGRAM DESIGN I coo,.o TESTING I OPERATIONS Figure 2. Implementation steps to develop a large computer program for delivery to a customer. I believe in this concept, but the implementation described above is risky and invites failure. The
  3. ॱ࣍ਐΉ͕໭Γ͸nεςοϓ ໰୊͸Oεςοϓલͷͱ͜Ζʹ͋Δ͜ͱ͕ଟ͍ͱ͍͏͜ͱͰ͢ɻ TESTING OPERATIONS Figure 3. Hopefully, the ~terat=ve interact=on

    between the various phases is confined to successive steps. I SYSTEM "1 .~oo,.~-,..Sl.,~ I so,w..~ !. I ANALYSIS PROGRAM DESIGN I coo,.G I,~ ! TESTING I I O .ATO.S ! Figure 4. Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps. 330
  4. Ή͠Ζೋ౓࡞Γ·͠ΐ͏ arrive at an error-free program. In either case the

    point of all this, as with a simulation, is that questions of timing, storage, etc. which are otherwise matters of judgment, can now be studied with precision. Without this simulation the project manager is at the mercy of human judgment. With the simulation he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the area of computer program design (as in the estimation of takeoff gross weight, costs to complete, or the daily double) is invariably and seriously optimistic. I I,,, 1 I ANALYSIS I ! PROGRAM I I DES,GN I -U coo,.o I LI .,s.,.o USAGE PRELIMINARY I% PROGRAM DESIGN ANALYSIS i PROGRAM DESIGN TESTING [ OPERATIONS Figure 7. Step 3: Attempt to do the job twice - the first result provides an early simulation of the final product.
  5. Royceͷਤ͸ςετͷശ͕ͻͱͭ I SYSTE M I ANALYSIS PROGRAM DESIGN I coo,.o

    TESTING I OPERATIONS Figure 2. Implementation steps to develop a large computer program for delivery to a customer. I believe in this concept, but the implementation described above is risky and invites failure. The
  6. ͜ͷࢿྉͰ͸VࣈϞσϧ෩ 7ࣈϞσϧͰ͸ςετ෦෼͕ෳ਺ͷ޻ఔʹͳ͍ͬͯΔɻ I SYSTE M I ANALYSIS PROGRAM DESIGN I

    coo,.o TESTING I OPERATIONS Figure 2. Implementation steps to develop a large computer program for delivery to a customer. I believe in this concept, but the implementation described above is risky and invites failure. The ⵸⼱ך䊨玎ח㼎䘔ׅ׷ 嗚鏾䊨玎ָ֮׷
  7. ݪҼ޻ఔͱൃݟ޻ఔͷҧ͍ 工程別の不具合原因工程と不具合発見工程の比率:平均値 不具合原因は「企画・仕様」 、 「システム設計」 「ソフトウェア設計」 、 「ソフトウェア実装・ デバッグ」 の上流工程での比率が高い。

    一方、 不具合発見は 「ソフトウェア実装・デバッグ」 以降の下流工程を中心に発見されている。 Q8-4 不具合の原因工程と不具合の発見工程の比率 (不具合原因 N=92、不具合発見 N=84):平均値 不具合の原因工程比率:平均値 不具合の原因は「企画・仕様」 、 「システム設計」 「ソフトウェア設計」の上流工程が6割強と 0% 5% 10% 15% 20% 25% 30% 35% 40% 企画・仕様 システム設計 ソフトウェア設計 ソフトウェア実装・デバッグ ソフトウェアテスト システムテスト 運用・実機テスト 不具合原因比率 不具合発見比率
  8. ݪҼ͸্ྲྀ޻ఔ͕60%ڧ Q8-4 不具合の原因工程と不具合の発見工程の比率 (不具合原因 N=92、不具合発見 N=84):平均値 不具合の原因工程比率:平均値 不具合の原因は「企画・仕様」 、 「システム設計」

    「ソフトウェア設計」の上流工程が6割強と っている。 Q8-4A 不具合の原因工程比率(N=92):平均値 企画・仕様 11.8% システム設計 15.8% ソフトウェア設計 33.5% ソフトウェア実装・ デバッグ 27.1% ソフトウェアテスト 5.0% システムテスト 2.8% 運用・実機テスト 3.7%
  9. Լྲྀ޻ఔͰ75%Λൃݟ 不具合の発見工程比率:平均値 不具合は「ソフトウェア実装・デバッグ」 、 「ソフトウェアテスト」 「システムテスト」 、 「運 用・実装テスト」の下流工程で約3/4が発見されている。 Q8-4B

    不具合の発見工程比率(N=84):平均値 ソフトウェア不具合に起因する品質問題の再発防止策(複数選択) ソフトウェア不具合に起因する品質問題の再発防止策として 「ソフトウェア開発プロセスの 企画・仕様 6.6% システム設計 6.9% ソフトウェア設計 12.1% ソフトウェア実装・ デバッグ 25.8% ソフトウェアテスト 20.4% システムテスト 13.4% 運用・実機テスト 15.0%
  10. 1/4

  11. 1/8