＠IT：ソフトウェアの不具合を追跡するには
不具合の追跡プロセスはソフトウェア開発の下流工程では非常に重要なもので、それはそのままソフトウェア開発の下流工程を規定するものといっても過言ではありません。不具合は、一般に開発者とQAの間で、不具合報告書（PR：Problem Report）をやり取りしながら管理することになります。今回は、不具合の状態と処理方法に注目し、不具合を追跡するプロセスについて説明します。 不具合とは ソフトウェアが意図もしくは期待したとおりに動作しないことを指して不具合といいます。面白いことに、ソフトウェアの「不具合」にはいろいろな別名があります。 不具合 障害 欠陥 故障 不備 バグ エラー 仕様 これらはすべて、同じソフトウェアの「不具合」を指す用語として使われることがあります。ただし、ドメインによっては、ソフトウェアの不具合の種類により、これらの別名を使い分けることもあります。仕様どおりに実装できていない
YappoLogs: 悪のりで学ぶsvnadmin/trac入門実用編
悪のりで学ぶsvnadmin/trac入門実用編 とある平和なある週末に事件は起こった xx:14 ([aopy]+) stfuawsc汚染なコードをciってまった xx:14 (A) ちょ xx:14 (B) ｗｗ xx:14 (C) ｗｗｗ xx:14 (D) stfuawsc xx:14 {[ainOS]+} パネラーディスカッションという事で、直近のコミットした内容をこの世から抹消しなければならなくなった。 しかもtrac上のデータもあわせて..! 消したいリビジョンは100である。 svnのデータを消すコマンドだけで直前のコミットを取り消せないものかと調べたが、出来ないという事が分かった。 ちょっと冷静になって、svnadmin dumpとsvnadmin loadの組み合わせで何とか出来ないか？と考え$ svnadmin dump /svn/public > /tmp/publ
QuickImage | psnet
The QuickImage plugin provides an eclipse-editor for viewing images. You can browse images one by one, or all as thumbnails. Use the toolbar to navigate or by single- or double-clicking the images. By default QuickImage associates its editor with .gif .jpg .jpeg .png .bmp .ico Initial intention with the plugin was to use it with web projects etc, not for viewing large collections of huge images. T
XMLデータストリームの検証を動的プロセスにする：CodeZine
はじめに XML Schemaのもともとの目的は、XMLの検証および定義をDTD（文書型定義）よりも優れた方法で行うためのレイヤを提供することでしたが、その根本にあったいくつかの概念はいつのまにか変化しました。そうした概念の1つが、「属性は列挙（リスト）に設定できるが、その列挙はスキーマ自体の中に指定する必要がある」というものです。XMLが分散化するに従って、また、データ構造が複雑化して静的な定義だけでなく動的な定義にも依存するようになるに従って、開発者たちは、そうした動的な定義を自分自身でサポートするスキーマ言語を使う必要があると認識するようになりました。 ISO SchematronはXPath 2.0（特にdoc()やunparsed-text()のような関数）を利用できるようになったため、ビジネスコンテンツのためのクリティカルな「分散検証」言語であると考えていいかもしれません。Sc
「Aクラス理論」：Aクラスの奴はNoを言わない上に褒めるのが上手い。 - shibataismの日記
ウェブ時代 5つの定理―この言葉が未来を切り開く!にある、 http://www.bunshun.co.jp/umeda_web/umeda_link_teiri02.htm ■p.93 Ａクラスの人は、Ａクラスの人と一緒に仕事をしたがる。 Ｂクラスの人は、Ｃクラスの人を採用したがる。── シリコンバレーの格言 A-level people want to work with A-level people. B-level people tend to hire C-level people.──Silicon Valley proverb という格言。 これは、何となく流行語になりそうなので「Aクラス理論」と勝手に呼ぶことにする。 さて、今、インターナショナルなチームで一つプロジェクトをやっているのですが、ゼロからチームを作れるということだったので、この「Aクラス理論」を徹底的に意識して
記事から学べ 論理思考を身に付けたい！ ― ＠IT自分戦略研究所
ITエンジニアだろうがなかろうが、論理的な思考はビジネスパーソン共通のスキルである。では、それをすぐに学習する方法は何か？ そう、記事を読むことだ。そんな記事を紹介しよう。記事を読み、論理思考を身に付けよう。 必要な人材像 ITエンジニアにとっての基本スキルは、技術スキルであるのは当然だ。ただし、それだけではない。技術スキルに負けず劣らず重要な必須スキルがビジネススキル（ヒューマンスキル）だ。 日ごろ取材などで多くのIT企業を訪れる機会がある。そうしたとき、各企業の経営陣、現場の開発者から聞くその企業に必要なITエンジニア像は、多くの場合技術スキルだけではなく、ビジネススキルを併せ持った人というものだ。 人材紹介会社など、人材系の企業でも、「企業にもよりますが、技術スキルはある程度あればいいと。それよりも、ビジネススキルが重要です」といった意見はよく聞く。 では、どのようなビジネススキルを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユースケース記述を作成する際の11つのチェックポイント - Fight the Future