ウェブリ/ブログログイン

]

トップ  プロフ  フレンド  サークル

課題1 １）それまでの職人的プログラムではプログラマは処理のすべての段階を記憶していて常にたどることができたが、プログラマ本人でさえ記憶が薄れたり、他人にとっては出来上がったプログラムをみただけでは処理の流れが推測できなかった。それに対して構造化プログラミングはプログラマも処理のすべての段階を記憶している必要はないし、定型化された盛業構造に沿ってプログラムを読めば、処理は再構成できるので、処理がしやすくなったこと。 ２）オブジェクト指向プログラミングを人的共同作業（委託-統合）になぞらえて、作業を分散統合させるもので、その結果完成したプログラムの見通しはたいへんよくなった。 スパイラル開発モデルは要求分析→設計→コーディング→テスト→運用・保守という順番に螺旋的に繰り返して、ユーザの満足にたどり着く。ユーザの要求は開発期間を通して変化し続けるがスパイラルを上るにつれて収束すると想定する。そうすると、ソフトウェア開発に付き物の要求仕様の変更などの時にオブジェクト指向プログラミングだと、作業を細かく分解しているため対応しやすい。だから相性がいいのではないか。 3) 伽藍方式とバザール方式 一番だいじなソフト（OS や、Emacs みたいな本当に大規模なツール）は伽藍のように組み立てられなきゃダメだと思っていたが、実際はバザール方式が機能し、一貫した安定なシステムが出てくることがわかった。というわけでこれから、そのプロジェクトの話をしようではないの。そしてそれを使って、上手なフリーソフト開発についていくつかアフォリズムを提案してみる。 仕事柄インターネットの電子メールが手放せなくなったが、うまく自宅のパソコンとCCILとでSLIP接続するのに手間取るなど面倒なことが増えてきたので新しい方法を使おうとした。そこから５つの教訓が得られた。1. よいソフトはすべて、開発者の個人的な悩み解決から始まる。2. 何を書けばいいかわかっているのがよいプログラマだということ。3. 捨てることを最初から予定しておけ。1回で完全に問題を理解できると思わないほうがいい。4. まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。5. あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。 　ユーザは大事な財産である。なぜなら単に、自分が何かニーズに対応しているんだな、なにか役に立つことをしたんだな、ということを実証してくれるからというだけじゃなく、きちんと育てれば、ユーザは共同開発者になってくれるからだ。ユーザの中にもハッカーがたくさんいるがソースコードが公開されているから、同じハッカーでも役に立つハッカーになってくれる。これはデバッグ時間短縮にはすごく役に立つ。ちょっと励ますだけで、ユーザが問題を診断し、直し方を提案してくれて、一人でやるよりずっとはやくコードを改善できるようにしてくれるからだ。そこで６つめの教訓は6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法ということだ。 リーヌスの法則としてベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。ここに伽藍建築方式とバザール式のちがいの核心部分があるんだと思う。伽藍建設者的なプログラミングの見方では、少人数で時間をかけてバグや開発上の問題を調べるが、バザール的見方だと、大人数で一気に調べる。 Popclient から Fetchmail へ変わるときに自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれた。発展を遂げるうちにUnix マシンと SLIP/PPP メール接続を持ってるハッカーみんなが本当に必要としているプログラムになった。ここからの教訓はおもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めようということだ。ここで話したいことはオープンソースが圧勝した世界のビジョンではなく、オープンソースの成功のいちばんだいじな影響の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えたいのだ。 4）次の用語の意味を各200字程度で述べなさい。 　○CORBA　 OMGが定めた分散オブジェクト技術の仕様。異機種分散環境上のオブジェクト(プログラム部品)間でメッセージを交換するためのソフトウェア(ORBと呼ばれる)の仕様を定めている。具体的には、ORBの基本構造や、プログラミング言語からORBを利用する際の手順、異なるORB間で相互にメッセージを交換する際の規定などを定めている。 ○CASE　　「コンピュータ支援ソフトウェア工学」の略。システム開発支援ツールと開発方法論の統合、システム開発作業の効率化を目的としている。CASEツールと呼ばれるソフトウェアを用い、ソフトウェア開発の多くの局面を自動化することができる。　CASEツールには、計画・設計など、ソフトウェア開発の初期段階を支援する上流CASEツールと、プログラム作成・テスト・保守などを支援する下流CASEツールがあり、これらのプロセスすべてに一括して対応するものを統合CASEツールと呼ぶ。 課題２ ○要約 多くのソフトウェア開発の現場では、今でも技術者の経験や勘に頼っている。しかしソフトウェアの大規模化による開発環境の分散や開発人数の増大のため、経験や勘にばかり頼っているわけにはいかない。ソフトウェア工学とは、そのような職人芸的な部分を定式化し、品質の高いソフトウェアを開発する方法論を確立するための学問である。一般に考えられているソフトウェアのシステム開発は誤りを発見するのに時間がかかり、無駄な時間を莫大に使ってしまうと考えられている。しかし、ソフトウェアの実際はソフトウェア開発方法論、開発プロセスモデル、開発者の参加基準、開発ツールにわかれていてそれぞれ歴史とともにいろいろな方法が使われるようになってきた。ソフトウェア開発方法論は1945年からは職人的プログラムが採用され、65年からは構造化プログラム、85年からはオブジェクト指向プログラムが採用されるようになった。オブジェクト指向プログラムでは人的共同作業（委託-統合）になぞらえて、作業を分散統合させるもので、完成したプログラムの見通しはたいへんよくなった。開発プロセスモデルはウォーターフォール・モデル、スパイラル・モデル、アジャイルソフトウェア開発と進化してきた。開発プロセスは要求分析→設計→コーディング→テスト→運用・保守として機能する。1999年から運用されているアジャイルソフトウェア開発では、ユーザを背負っているソフト技術者だけで開発チームを構成し、要求仕様を書いた者たちがコーディングもする。開発中のソースコードはネットで共有され、バージョンが管理される。エラーの発見がすばやく、的確である。完成するソフトの品質がよく開発効率がよい。 ○感想 ソフトウェア工学と聞くと、私は理系のイメージしかなくて、その仕事についている人はみんな理系の人だと思っていました。しかし、実は考え方などは文型の人の考えを使ったほうがいいという先生の話に驚きました。オブジェクト指向プログラムの内容が完全に人間社会に似ていておもしろかったです。ウォータフォールモデル、スパイラル開発モデルに見られるように、もしも全部作業が終わった後にミスが見つかったときにやり直す手間を考えるとやはり細かく分けて戻るにしても、その戻る範囲を小さくできるようになったことは規模の大きなものを開発する上でとても助かったんだろうと思いました。

<< 前記事（2008/11/13）

トップへ

後記事（2008/11/25）>>

<< 前記事（2008/11/13）

トップへ

後記事（2008/11/25）>>