自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。お読みのページは後編です。 大規模なテストをどうやって実行しているか 続いて、大規模なテストについて。 1000万件のテストパターンを作っても、それぞれのテスト結果の正解を人手で作っていたら追いつきません。なので、別々に運賃計算ソフトウェアを作って、その答えを突き合わせてチェックしよう、という話です。 例
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
日本の情報システムは頑張りすぎ？ 日本企業の計画外停止は年間平均1.6時間、米国企業は12.6時間というデータ
日本の情報システムは頑張りすぎ？ 日本企業の計画外停止は年間平均1.6時間、米国企業は12.6時間というデータ 日本企業の情報システムの「計画外停止時間は米国の約9分の1」であることを指摘する記事が、今月の日経SYSTEMS 2012年1月号に掲載されています。日本情報システム・ユーザー協会（JUAS）顧問の細川泰秀氏の「データは語る」という連載の第1回。 米ガートナーの2008年10月のデータによると、米国企業におけるミッションクリティカルなアプリケーションでの計画外停止時間は年間12.6時間。 一方、JUASが経済産業省の委託を受けて調査した「企業IT動向調査2011」（2011年3月発表）によると、日本企業における基幹系システムの計画外停止時間は平均で年間1.5時間なのだそうです。 つまり日本のITの現場は、システムの計画外停止時間を米国の約9分の1にとどめている。 やはり日本の品質
Hadoopがバージョン1.0へ。2.0、3.0の議論も進む
大規模分散処理フレームワークのHadoopの最新安定版「Hadoop 1.0.0」が、昨年12月27日に公開されました。これは、これまで安定版として開発されていた「Hadoop 0.20」ブランチの最新バージョンを1.0.0としたものです。 Hadoopは、前身となるNutchが2002年にDoug Cutting氏によって開発され、（このビデオの10分頃のCutting氏の発言によると）2008年にNutchからHadoopプロジェクトが分離。約4年を経てバージョン1.0へと到達したことになります。 今回バージョン1.0.0となった旧0.20ブランチのほかに、Hadoopには0.22、0.23など複数のブランチで開発が進んでおり、Hadoopに対する新しい機能、例えば従来のMapReduceを完全に書き換えたMapReduce 2などはこれら新しいブランチに対して実装が行われています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
