What's wrong? ― 2009/04/10 23:04
【どうしたの、悪いところはどこ？】
世界的に著名なソフトウェア工学者 David Lorge Parnas 氏の講演を聴きました。タイトルは、"Practical Mathematical Methods for Software Development"（実際に役立つ、ソフトウェア開発の数学的手法）というものでした。
http://sec.ipa.go.jp/seminar/2009/20090410.html
通訳付きでしたが、なんだかよくわからなかった。
講演資料のタイトルは以下のとおりです。先頭の番号はページ番号です。３ページは全部載せます。
3 what's wrong with software development - old problems
ソフトウェア開発のいけないところ - 昔からある問題
- programing progress unpredictable, schedules don't work.
プログラミングの進み具合が予測できなく、スケジュールどおりいかない
- developers unclear about module responsibilities (gaps, duplication)
モジュールの開発責任が不明確（意図どおりになっていないものがあったり、機能が重複しているモジュールがある）
- "Mythical Man Manth" effect
30年前の「人月の神話」の話は現在でも依然として正しい。例、開発遅れのチームに人を投入するともっと遅れる
- developer's work does not integrate easily
開発者が個別に作ったものはそう簡単には一つにはならない
- inspections of code are not effective - many errors not found.
コード検査は効果的ではない - 見つけられない多くのエラーが残る
- testing does not find faults - important test cases overlooked,
テストで不良はみつからない - 見逃された重要なテストケースがある
- many bugs in delivered products
出荷品に多くのバグが潜んでいる
- system doesn't meet the "real" requirements.
最終段階になって、これは望むものではないといわれる
- "ripple effect"
池に石を投げたように障害が四方八方に拡がる
- poor design decisions not found until code is tested, in use, or changed.
下手な設計だというのが、テストまで、使われるまで、修正せざるを得なくなるまでわからない
- maintainig software (correcting erros/updating) very expensive.
ソフトウェアのメンテ（エラー修正、改版）には金がかかる
4 what's wrong: a widespread belief in magic
5 pretend process improvement (PPI)
6 what's wrong : simple solutions to complex, difficult, problems
7 what's wrong : ignoring the science
8 what's wrong : ignoring the people
9 what's wrong : assuming that people cannot be educated
10 the role of documentation in engineering
11 what is document?
12 documents as predicates
13 document roles : Descriptions vs. Specification
14 what i do NOT mean by "document"
15 why do engineers need documents
16 what do engineering documents look like
17 how do software developers see documentation
18 software developers do not treat documents with respect
19 documents vs. models
20 views in documents
21why use mathematics in software development
22 when should developers use of mathematics during design
23 use of mathematics during quality assurance
24 mathmatical assistance in inspection
25 mathematical assistance in testing
26 methematics is essential for verification
27 use of mathematics during maintenance
28 use of mathematics in documents
29 software documents : wwhat views are needed?
30 system views as a black box
31 system structure view
32 alternative system structure view
33 software component/module : black box
34 use relation between problems
35 software module : internal view
36 terminating program : black box
37 terminating program : hierarchical set of displays
38 functional/relational model of documentations
39 basic mathematical concepts
40 contents definitions for documents (general concept)
41 system black box view
42 system structure view
43 alternative system structure view
44 software component/module : black box
45 use relation between programs
46 software module : internal view
47 terminatin program : black box
48 terminatin program : hierarchical set of displays
49 representation of rekations with tabular expressins
50 a semi-formal mathematical expression
51 inverted tables
52 generalized decision table
53 multi function multicolor tables
54 case study : dell keyboard checking tool
55 this mathematical expressin documents the behavior
56 keyboard checker : tabular expressin
57 more real world I
58 more real world II
59 no theoretical advantage
60 application of functional documentation
61preparing for change
62 don't use change as an excuse
63 advantages over other "formal" approaches
64 why it works in practice
65 educational implications
世界的に著名なソフトウェア工学者 David Lorge Parnas 氏の講演を聴きました。タイトルは、"Practical Mathematical Methods for Software Development"（実際に役立つ、ソフトウェア開発の数学的手法）というものでした。
http://sec.ipa.go.jp/seminar/2009/20090410.html
通訳付きでしたが、なんだかよくわからなかった。
講演資料のタイトルは以下のとおりです。先頭の番号はページ番号です。３ページは全部載せます。
3 what's wrong with software development - old problems
ソフトウェア開発のいけないところ - 昔からある問題
- programing progress unpredictable, schedules don't work.
プログラミングの進み具合が予測できなく、スケジュールどおりいかない
- developers unclear about module responsibilities (gaps, duplication)
モジュールの開発責任が不明確（意図どおりになっていないものがあったり、機能が重複しているモジュールがある）
- "Mythical Man Manth" effect
30年前の「人月の神話」の話は現在でも依然として正しい。例、開発遅れのチームに人を投入するともっと遅れる
- developer's work does not integrate easily
開発者が個別に作ったものはそう簡単には一つにはならない
- inspections of code are not effective - many errors not found.
コード検査は効果的ではない - 見つけられない多くのエラーが残る
- testing does not find faults - important test cases overlooked,
テストで不良はみつからない - 見逃された重要なテストケースがある
- many bugs in delivered products
出荷品に多くのバグが潜んでいる
- system doesn't meet the "real" requirements.
最終段階になって、これは望むものではないといわれる
- "ripple effect"
池に石を投げたように障害が四方八方に拡がる
- poor design decisions not found until code is tested, in use, or changed.
下手な設計だというのが、テストまで、使われるまで、修正せざるを得なくなるまでわからない
- maintainig software (correcting erros/updating) very expensive.
ソフトウェアのメンテ（エラー修正、改版）には金がかかる
4 what's wrong: a widespread belief in magic
5 pretend process improvement (PPI)
6 what's wrong : simple solutions to complex, difficult, problems
7 what's wrong : ignoring the science
8 what's wrong : ignoring the people
9 what's wrong : assuming that people cannot be educated
10 the role of documentation in engineering
11 what is document?
12 documents as predicates
13 document roles : Descriptions vs. Specification
14 what i do NOT mean by "document"
15 why do engineers need documents
16 what do engineering documents look like
17 how do software developers see documentation
18 software developers do not treat documents with respect
19 documents vs. models
20 views in documents
21why use mathematics in software development
22 when should developers use of mathematics during design
23 use of mathematics during quality assurance
24 mathmatical assistance in inspection
25 mathematical assistance in testing
26 methematics is essential for verification
27 use of mathematics during maintenance
28 use of mathematics in documents
29 software documents : wwhat views are needed?
30 system views as a black box
31 system structure view
32 alternative system structure view
33 software component/module : black box
34 use relation between problems
35 software module : internal view
36 terminating program : black box
37 terminating program : hierarchical set of displays
38 functional/relational model of documentations
39 basic mathematical concepts
40 contents definitions for documents (general concept)
41 system black box view
42 system structure view
43 alternative system structure view
44 software component/module : black box
45 use relation between programs
46 software module : internal view
47 terminatin program : black box
48 terminatin program : hierarchical set of displays
49 representation of rekations with tabular expressins
50 a semi-formal mathematical expression
51 inverted tables
52 generalized decision table
53 multi function multicolor tables
54 case study : dell keyboard checking tool
55 this mathematical expressin documents the behavior
56 keyboard checker : tabular expressin
57 more real world I
58 more real world II
59 no theoretical advantage
60 application of functional documentation
61preparing for change
62 don't use change as an excuse
63 advantages over other "formal" approaches
64 why it works in practice
65 educational implications
最近のコメント