ura87 no omote
メインのブログ(d:id:kiwofusi)は日本語の読めるひとみんなに読んでもらいたいので、作業メモやソースコードなどはこちらに書きます。
以下は筆者の受けた授業内容に基づく概要と感想です。理解や表現の誤りはご了承ください。
この授業はソフトウェア開発のなかでとくに「検証」を扱う。検証に関する諸概念、諸技術を理解し、説明できるようになることが主な目的である。
検証とはソフトウェアの「正しさ」を確認することである。ひとつは verification 正当性の確認、つまりソフトウェアを正しくつくっているか、プログラムが仕様に合っているか、の確認である。もうひとつは validation 妥当性の確認、つまり正しいソフトウェアであるか、仕様やプログラムが顧客の要求を満たすか、の確認である。したがって検証はソフトウェア開発のあらゆるプロセスにおいてプログラムだけでなく文書に対してもおこなう必要がある。
検証の理想は欠陥ゼロのソフトウェアをつくることだが、現実には要求を仕様化する難しさやコスト・規模の問題があり、顧客の要求を満たすことを第一に考えるべきである。
プログラムの検証には、実際に動作させる動的検証、ソースコードに対しておこなう静的検証がある。また仕様に対してはレビュー(インスペクション、ウォークスルー)をおこなう。
仕様を形式言語で記述することによって仕様が明確になり検証を自動化できるが学習コストが大きい。数学的な検証方法としてほかにモデル検査検証がある。
検証というのは趣味でプログラミングしているときはてきとうになりがちなので、授業でやってみるのもよいかなあと思う。
以下、授業課題の感想文。
検証にverificationとvalidationのふたつの概念があり、仕様だけでなく要求に基づく検証も必要であることを理解した。要求が「正しいソフトウェア」の基準になることから、上流工程における要求の議論や要件定義の重要性がわかった。このような観点をもったことがあまりなかったのでこの授業を機に身につけたい。またアサーションや形式手法については聞き慣れないこともありよくわからなかった。これらも今後の授業で理解したい。
現実には、要求やコストに応じて品質を妥協させることが必要なのだろう。しかしあるベンチャー企業のエンジニアは、顧客の要求とは異なるサービスを内密に平行して開発し、顧客をおどろかせた(実際によろこんでもらえた)というエピソードを語っていた。これは極端な事例ではあるが、顧客の要求を上回るものをつくろうというやる気もエンジニアにとっては大事だと思う。しかし根性論でデスマーチを肯定されても困るので、なかなか微妙な問題だ。「顧客の期待が低ければ低品質でもかまわない」というのは冷静には理解できるが、なんだか釈然としない気もした。
以下は筆者の受けた授業内容に基づく概要と感想です。理解や表現の誤りはご了承ください。
この授業は情報システムの評価についてICTリテラシーの観点からアプローチする。システムの評価の仕方ではなく、システム利用者のソフト面におけるリテラシーを問題とする。
ICTリテラシーの定義には Cisco, Intel, Microsoft による 21st Century Skills http://www.atc21s.org/home/ を用いる。liberalな定義である。内容を分析したみたが、従来の考え方とは劇的に違う。将来、知性の基準が大きく変わるだろう。OECDも問題解決能力の一部としてこのICTリテラシーを取り入れた。日本では注目されていない。
授業は 21st Century Skills のペーパーの読解・発表とディスカッションを受講人数に合わせたかたちでおこなう。
情報システムの評価とは直結しない内容におどろいたが、内容は興味深い。ペーパーは、日本でいうところの「新しい学力観」を本気で議論して文書化したようなものだと思う。こういう考え方が日本になじむのは何十年後かわからないが、これからどういうふうに成長を志していけばよいかを考えるうえで参考になると思う。教育や教育学は「いかにひとに教えるか」の分野だと思っていたのだけれど、人間の知性はいかにあるべきか、という本質的な議論が背景にあることに気づき、興味が出た。
受講目的としては、
というところ。あとは英語リテラシーとディスカッション能力の向上。情報システムの評価との関係についてはのちのち考えたい。
英語もディスカッションも嫌いだけれど、内容に興味のある授業を受けないなんて学生である意味がない、と思い、受講を決めた。