cles::blog

プログラミング言語 Pascal の考案者であり、ソフトウェア工学の大家であった ヴィルト (Niklaus Wirth) 先生が 1 月 1 日逝去されました。

ソフトウェアはまだ学門としてまだ若いこともあって、教科書に出ている偉人がまだ存命であるというのが大きな特徴でしたが、ソフトウェア黎明期に第一線であった方は既にかなりの高齢になっているので、徐々に鬼籍に入られる人も多くなってきた印象です。同じくソフトウェア工学の大家である Bertrand Meyer も X (Twitter) で追悼コメントを出していました。

ちなみに僕は N88-BASIC からプログラミングに入ったので、残念ながら Pascal とかは触れる機会がなかったんですよね。Borland のTurbo Pascal も存在は知っていたんですが、当時の小遣いでは買えませんでした。

【訃報】プログラミング言語「Pascal」の開発者ニクラウス・ヴィルト氏が89歳で死去、ソフトウェア設計のパイオニアとして複数のプログラミング言語を考案し1984年にチューリング賞を受賞 - GIGAZINE

プログラミング言語「Pascal」の開発者であるニクラウス・ヴィルト氏が2024年1月1日に亡くなりました。89歳でした。

独立行政法人情報処理推進機構 社会基盤センター, "図2-1-1.1: SLOC 規模別発生不具合密度(新規開発)の箱ひげ図," ソフトウェア開発分析データ集2022, p.29, Sep. 2022.

IPA がソフトウェア開発分析データ集 2022 を公開していたのでメモ。

エンピリカル系のソフトウェア工学では基礎なる貴重なデータですね。

特にグラフの欠陥密度についてのデータが興味深いです。これは稼働 6 ヶ月後の kSLOC(Source Lines of Code) あたりの欠陥密度、つまり、「リリースから半年でソースコード 1000 行あたりバグがいくつ見つかるか？」という値です。

惜しいのは欠陥の定義が書かれていないので、どの程度の欠陥で 1 件とカウントされているのか分かりません。そんなわけでこれを多いとみるか少ないと見るかは判断が分かれそうですが、とりあえず規模が小さいほど、ばらつきが大きいという傾向については間違いなさそうです。

「ソフトウェア開発分析データ集2022」の発行：IPA 独立行政法人 情報処理推進機構

これまでに収集したデータ数は分析データ集2020で5,000件を超え、今回の分析データ集2022では5,546件になりました。この分析データ集2022では、分析データ集2020と同様に、過去のデータ白書であまり見られていない図表などは省略しコンパクトにすることで読みやすくし、開発プロセスに依存しない普遍的なメトリクスである信頼性を中心に分析しました。前回の分析データ集2020では「信頼性は向上するも生産性は低下」が特徴でした。そして、今回の分析データ集2022では「信頼性も生産性も低下」という傾向になりました。

TL でスクエニの「ゲーム開発 プロジェクトマネジメント講座」という PDF が話題になっていたのでメモ。
ネットを検索してみると発表当時もそこそこ話題になったようです。

10 年資料ですが今読んでみても工期に関するフェルミ推定も興味深いですし、純粋に読み物としても面白いと思います。

個人的にはプロジェクトマネジメントは「未来は予想できるという立場」と「不測の事態にも対処しなければならない（適応）という立場」が両輪になっていて、PM はこの 2 つの立場を切り替えながら、どちらの考え方も尊重しながら進めていくのがキモだと思っています。

この資料はそのような考え方を実践しやすい形で記述した良いプラクティス集になっていると思います。

ソフトウェア開発のレビュープロセスに関する JIS 規格 JIS X 20246 が正式版になっていたのでメモ。
「ISO/IEC 20246:2017 Software and systems engineering — Work product reviews」の邦訳版になります。

設計書・仕様書のレビュー方法を定めたJIS規格登場　チェック体制を標準化しやすく - ITmedia NEWS

「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。

• 日本産業規格(JIS)を制定・改正しました（2021年11月分） （METI/経済産業省）
• システム開発における作業生産物のレビュープロセスに関する JIS 制定

以下のウェブページから X20246 で検索すると閲覧できます（ダウンロード不可）。

• 日本産業標準調査会：データベース検索-JIS検索

ページ数も 40 ページとコンパクトにまとまっているので、すぐに読み終わると思います。
内容としてはFagan Inspection^*1)や、IEEE 1028 IEEE Standard for Software Reviews and Auditsなどの古典的なレビュー方法を踏まえた基本的なものなので特に目新しい感じはしないですね。

• ^*1: M. E. Fagan, "Design and code inspections to reduce errors in program development". IBM Systems Journal, 15(3), pp.182–211, 1976. (doi:10.1147/sj.153.0182

Parser を使ってプログラムを解析する場合によく使われるのが AST ですが、ちょっと AST が確認したい場合に Web で簡単に AST が確認できるウェブサイトを見つけたのでメモ。

• AST explorer

これが上手く使いこなせるとプログラムを解析するアプリの開発に役立ちそうです。

ソフトウェア開発のあり方について痛烈に風刺している「66 Lessons from 50 Years of Software Experience」というエントリを見つけたのでメモ。教訓は 66 個あるので、なかなかの長文です。

エントリの著者をあまり気にせずに読み始めてしまったのですが、途中まで読んでこれが「Creating a Software Engineering Culture（邦訳：ソフトウェア開発の持つべき文化）」を書いた Karl Wiegers であることに気付きました。もともと、この書籍では以下にあるとおり教訓の数は 14 個でしたが、25 年の時を経て 66 個になってしまったようです。

• Creating a Software Engineering Culture - Karl Wiegers - Google ブックス

僕が一番好きなのはオリジナル版のこれでしょうか。

Quality is the top priority; long-term productivity is a natural consequence of high quality.
（品質が最優先事項です。長期生産性は、高品質の当然の結果です。）

VS Code で書いた自分のプログラムの LoC （Lines of Code: コード行数）が知りたくなったので、LoC を計測するプラグインを探してみたところ VS Code Counter というちょうどいものを見つけることができました。

• VS Code Counter - Visual Studio Marketplace

このプラグインの面白いところは VS Code の言語拡張を利用して動作するようになっているので、VS Code が対応している言語であればどのような言語であっても対応しているということろでしょうか。これは実装としてなかなか面白いと思います。

ちなみに使い方は以下の 2 ステップです。

1. Ctrl+Shift+Pでコマンドパレットを開く
2. VSCodeCounter: Count lines in workspace を選択

計測結果は.VSCodeCounterというディレクトリに計測毎にレポートが保存される仕組みなので、定期的に計測していくとコード量の移り変わりを後で振り返ることができます。

ミネソタ大学の博士課程の学生が脆弱性に関する実践的な研究をするために、Linux カーネルに Use After Free のバグを埋め込んだパッチを送って論文を書いた件が、大きな問題になっていたのでメモ。

ソフトウェア関連の研究に携わっている者として、人ごとではない深刻な事態だと受け止めています。研究をしていると、やってみたいという衝動に駆られるけれども倫理上の理由で実行できないということはよくあります。

問題の論文（On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits）についてはすでにwithdraw（取り下げ）になっているようです。

大学においてはヒト対象実験については倫理指針が定められていて、事前審査を受けなければ実施することができませんが、ソフトウェアの世界にも倫理審査が必要な時代が来てしまうのかもしれません。以下のメールで述べられている Linux コミュニティの意見は厳しいですが至極真っ当な意見だと思います。

Re: [PATCH] SUNRPC: Add a check for gss_release_msg - Greg KH

Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way.

Our community does not appreciate being experimented on, and being"tested" by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose.
If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.

Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems.

† 参考

• Linuxカーネルに意図的にバグを混入したとして大学にコミュニティ出禁措置 - GIGAZINE
• Linux bans University of Minnesota for sending buggy patches in the name of research [Update] - Neowin

在宅勤務時に PC 利用状況を把握するためのアプリが発売されていたのでメモ。

ソフトウェア工学の世界では、昔からエンジニアが PC でどのような作業に時間を費やしているのかを計測して生産性向上を目指すという考え方が存在していて、その代表的なものに Watts Humphrey の Personal Software Process (PSP) があります。ツールについても、以前国内の学会で同様の話を聞いたことがあったはずなので調べてみたら奈良先端の TaskPit という研究^*1でした。

在宅勤務PCの作業内容を記録できる監視アプリ「ManicTime Pro」。ライフボートから - PC Watch

使用したアプリの種類と稼働時間、編集したファイルや参照したURLの参照時間、各作業時のスクリーンショットなどを自動保存することが可能。その結果をグラフ化したり、レポート出力したりすることもできる。

• ^*1: Pawin SUTHIPORNOPAS, Pattara LEELAPRUTE, Akito MONDEN, Hidetake UWANO, Yasutaka KAMEI, Naoyasu UBAYASHI, Kenji ARAKI, Kingo YAMADA, Ken-ichi MATSUMOTO, "Industry Application of Software Development Task Measurement System: TaskPit," IEICE Transactions on Information and Systems, Vol. E100.D, Issue 3, pp. 462-472, 2017.

今年のチューリング賞^*1はAlfred Aho, Jeffrey Ullman の両先生に決まったようです。

大学の情報系学科できちんと講義を聴いていれば、この２人の先生の名前は一度は耳にしているはずです。
僕はコンパイラの時に習った、レジスタの割り付けのアルゴリズム（セシィ・ウルマン法）で覚えています。

チューリング賞、コンパイラ技術の開発に貢献した研究者2人に - CNET Japan

コンパイラと呼ばれる重要なソフトウェア開発ツールがなければ、コンピューターを制御するために、人間には理解が難しい機械語の世界まで降りていく必要が生じていたことだろう。この功績を称えて、高い権威を誇るチューリング賞の2020年の受賞者に、コンパイラの開発に貢献したAlfred Aho氏とJeffrey Ullman氏が選ばれた。

• ^*1: A.M. Turing Award