優れたシステムを作るための“思考力、人間力”とは？
優れたシステムを作るための“思考力、人間力”とは？：何かがおかしいIT化の進め方（53）（1/3 ページ） 前回は、アップルやボーイングの例を示しながら、「個々の要素技術を最適な形で組み合わせて全体を構成する技術」の重要性を述べた。今回はこの問題を少し掘り下げてみる。 他人が作ったシステムをうまく管理できない理由 2011年7月、中国が「日本やドイツの技術をベースにはしたが、そこから独自に作り上げた技術で開発した」と豪語し、「特許申請する」とまで言っていた高速鉄道が大事故を起こした。事故の真の原因はわれわれには分からない。日本のメディアはやや嘲笑を込めて冷ややかに報道し、日本人の幾人かは溜飲を下げたのかもしれない。 しかし、この4カ月前、日本で起こった福島第一原子力発電所の大事故は、これと同じ種類の問題をはらんでいたように私には思える。基本を他人の技術に頼った“接ぎ木の危うさ”だ。 個々の
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか？ グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
テストの実行: QICT によるペアワイズ テスト
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 QICT によるペアワイズ テスト James McCaffrey サンプル コードのダウンロード すべてのソフトウェア テスター、開発者、マネージャーにとっては、ペアワイズ テストの原理についてしっかりとした知識が不可欠です。今月号のコラムでは、ペアワイズ テストとは正確にはどのようなものかを説明し、製品レベルの高い品質を備えた QICT というペアワイズ テストの完全な C# ソース コードを提供します。簡単に言うと、ペアワイズ テストとは、管理できないほど膨大なテストケースの入力数を、テストを実行するシステムで最低限バグを明らかにできる、ごく少量の入力数に削減する手法です。ペアワイズ テストを説明する、
Windows 7 デスクトップのデザインプロセス - everything might happen tomorrow - yhassy - builder by ZDNet Japan
Macユーザーではありますが、10月発売が決定した Windows 7 は結構期待しています。Vista で見つかった問題をどのように解決したのかという点も気になりますが、パソコンを利用する方達にどのようなソリューションを提案しているのかも興味深い点です。既にスクリーンショットやスクリーンキャストがウェブ上で出回っていますが、期待値が上がる UI や機能が幾つかあります。 Windows 7 のデスクトップはどのようにデザインされたのでしょうか。今年3月に開催された MIX09で、マイクロソフト シニア UX デザイナー Stephan Hoefnagels 氏が「Designing the Windows 7 Desktop Experience」というプレゼンをしました。デスクトップの細部にフォーカスして徐々に問題解決し、目指すゴールに近づけるプロセスを分かりやすく説明しています。以下
PerforceによるSW構成管理 - プログラマの思索
Perforceというソース管理ツールがある。 このツールは、CVSやSVNよりもマージやブランチ作成などの機能が優れていて、特にゲーム業界でよく使われていると聞く。 PerforceのHPにSW構成管理の良い記事があったのでメモ。 ＃あくまでも書きかけのメモ。 メインラインモデルとSW構成管理の新たな関係。 継続的な改善と変更管理の密接な関係。 インクリメンタルな開発スタイルは品質管理、リリース管理に密接に関係する。 【元ネタ1】 PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス） 【1-1】メインライン（主流となる開発経路）を持つようにする。 何故、trunkというメインラインを1本ずっと保持し続けるか、の良い理由が書かれている。 メインラインを昇格していくモデルでは、開発者へ別の開発環境を作るという不要なコストを強いるから。 ソフトウェア開発の殆どの無駄な作
無秩序なバージョン番号 | OSDN Magazine
フリーソフトウェア・アプリケーションやディストリビューションをいくつか試用してみて気づくのは、バージョン番号にほとんど意味がないことだ。昨今のバージョン番号を見ても、そのアプリケーションがどの開発段階にあるのか見えてこない。わかるのは、せいぜい、ビルドの前後関係ぐらいで、バージョン番号はビルドを区別するための単なるラベルに成り下がっている。バージョン番号が適切であれば、そのビルドの進捗状態がわかるはずなのに、これは何ともひどい状況だ。 しかし、複数の番号体系が使われていることが問題なのではない。種々の方式があることさえ知っていれば、GNOMEの奇数番号リリースが開発ビルドであり偶数が公式リリースであることを調べるのは造作ないことだからだ。また、KOffice 1.9.95-4をKOffice 1.0の後続バージョンかと一瞬誤解することはあっても、すぐにバージョン2.0の初期ビルドであること
ブログが続かないわけ | 初心者プログラマーが簡単なフォームを作るときにやりがちな6つのミス
お問い合わせフォーム、登録フォーム、キャンペーンの申込フォーム。 Webにはいろいろなフォームがある。 Webプログラマーであれば誰もが一度は作ったことがあると思う。 新人プログラマーの初めての実務がフォームであることも多いだろう。 新人が作っているというのにもかかわらず、技術的にも面白い部分がないせいか、正しい知識のある人がレビューすることが少ないと思われる。 単純さゆえにテストが不足しているということもあるかもしれない。 上記の理由は憶測にすぎないが、杜撰なフォームがたくさん出回っているのは事実だ。 もう、CAPTCHAの話とか以前の問題だ。 よく見かける悪い例を簡単にあげておく。新人が初めての実務に当たるときにこれを気にしてくれれば、世の中のフォームがだいぶ良くなると思う。 1. クライアントサイド(JavaScript)でのチェックのみ。 2. 選択肢式の入力欄に対するチェックの漏
角谷HTML化計画(2007-12-22) 江渡さんの『WikiとXPをつなぐ時を超えたプログラミングの道』講演動画を公開しました
■1 江渡さんの『WikiとXPをつなぐ時を超えたプログラミングの道』講演動画を公開しました 以前に少し書いた通り、『 WEB+DB PRESS Vol.42』の連載に「なぜそんなにも（アジャイル開発者にとって）Wikiは重要なのか」というコラムを書きました。 これに合わせて、本コラムの着想の元になった、オブジェクト倶楽部の今年の夏イベントでの江渡さんの講演動画をgoogle videoとニコニコ動画で公開しました。『10+1 No.48』に載っている江渡さんへのインタビュー「Wiki的都市は構想可能か？」とあわせて楽しんでもらえればと思います。 スライドの視認性が低かったり、会場の音を拾いすぎていたりして、動画のクオリティはあまり高くないので、江渡さんがslideshare.netで公開してれている当日の資料も参考にしてください。動画のライセンスはクリエイティブコモンズ 表示 2.1 日
肉厚と抜き勾配をおさえるべし！（1/3） － ＠IT MONOist
機械設計の基礎知識から、3D CADによるモデリングやCAE解析、3Dプリンタ活用といった実践スキルまでをカバーする、メカ設計技術者のスキル向上を支援する情報フォーラム
非機能要求
1 はじめに システム開発における要求分析モデルとして、ユースケースを中心に説明してきました。 ユースケースはユーザの目的をモデル化したモデル要素であり、システムがユーザに提供する機能を表現するという意味で機能要求のモデルといえます。第1回では、図1[営業社員のシステム・ユースケース]に示すユースケースを用いた要求モデルを作成しましたが、これは機能要求ということになります。 しかし、要求仕様は機能要求だけで構成されるわけではありません。実際のシステム開発では「ユーザの目的」とは別の観点でさまざまな要求を定める必要があります。このような機能外の要求のことを非機能要求と呼びます。 今回は、この非機能要求について説明します。 2 ISO/IEC 9126(JIS X 0129) 非機能要求を考える上では、システムの品質という切り口が重要です。 ISO/IEC 9126は、ソフトウェア開発における
非機能要求とISO9126 | オブジェクトの広場
本稿では、ソフトウェア要求とは何なのかを理解し、非機能要求に焦点を当て、ISO9126、要求定義プロセス、事例と解説していきます。 ※本稿は、技術評論社刊『JAVA PRESS Vol.40』に掲載された記事「機能外要求と ISO9126」を加筆、修正したものです。JAVA PRESS 編集部の了承を得た上で転載しています。 ※一切の転載をお断りします。 はじめに 私達がソフトウェアを開発するためには、ソフトウェアに対する要求 (ソフトウェア要求) が必要です。 ソフトウェア要求がなければ、そのソフトウェアには本当は必要のない機能を作ってしまったり、必要な機能を作っていなかったりするでしょうし、何よりもソフトウェアが完成したのかさえ評価できません。 そのためにも、私達ソフトウェアを開発する者は、ソフトウェア要求とは何なのかを正しく理解しておかなければなりません。 本稿では、ソフトウェア要求
品質とは何か
品質という言葉の意味 測定との関係と視点 品質の種類 基本的な考え方 ソフトウェア品質特性 機能性品質特性の品質副特性 信頼性品質特性の品質副特性 使用性品質特性の品質副特性 効率性品質特性の品質副特性 保守性品質特性の品質副特性 移植性品質特性の品質副特性 利用時の品質とは 俯瞰 まとめ 品質という言葉の意味 「品質」という言葉は、我々の世界ではよく使いますが、 品質とは何でしょう。 品質が良い／悪い、と言ったり、 品質を上げる、と言ったりしますが、 これがどんなものなのか、明確に認識しているでしょうか。 いろいろな人の話を聞いていると、 意外と認識が一致していません。 人によっては、検証の結果を見て言います。 「このモジュールは品質が悪いね」と。 人によっては、プロジェクト開始前に言います。 「前回のような品質問題は起こさないようにしよう」と。 人によっては、常に使います。 「品質を測
ソフトウェア個人開発プロセス手順書
●ソフトウェア個人開発プロセス手順書 version 0.4 目次 目的 プロセスの順番について、サンプルについて 開発手順 文章管理 開発管理帳 （開発体制表、 スケジュール表、 作業スタック、 要求履歴、 作業履歴、 数値データ） 基本仕様書の記述項目 試験仕様書兼報告書の記述項目 試験報告書の記述項目 評価報告書 分析 ～ 現状の理解と目的と対応の分析 見積もり作成 基本仕様作成 仕様変更 設計 ～ 各担当による機能実現の手段 入出力設計 イベント設計 詳細仕様作成（プログラミング） 試験仕様作成、試験方針 テストプログラム作成 状況欄 出荷モード 予防 デバッグ レビュー コーディング・レビュー レビュー記録 進捗報告 ISO-9001 の要求事項との対応 ◆ 目的 本書は、ソフトウェア開発の実際の作業に則しながら 品質を保証する手順のテンプレートです。 本書は、筆者の開発手順をモ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
パーソナルソフトウェアプロセス（PSP）実践講座 ～第1日 自分の生産性・品質を算出する
コンポーネントテストと統合テストってどう違うの？
InfoQ: ThoughtWorks社がCruiseをリリース：継続インテグレーションとリリースの管理システム
[Think IT]バグ管理チャンネル
八角研究所 : 未踏ソフトウェア創造事業体験記（3） - 開発編