2013年12月30日月曜日

[World of Tanks]ドイツ車は車体下部を隠せ JagdPathner II @高速道度(North America)

幸運のベストマッチ。

リプレイファイルはこちらです!
http://www.noobmeter.com/replay/2003248257.3710372090879767


高速道路は、南側が不利なマップだと思う。市街地に入るときは側面をさらすリスクがあるが、ここを抜けないと市街地からの勝利はできないので、思い切りが必要だ。一発くらい当たったからってひるんじゃいけない。



チームの中で一番隠ぺい率が低いと思うが、思い切って先頭を進むとこうなります。
ただし、このプレーは、Tier トップ、自走砲なしだからこそできたと思う。



しかし、IS-6と38naのnoob度が目立ちまちたよね・・・でも楽しかった。
XVMを入れていないが敵の方が優秀と思われる。


良かったこと

  • ヤクパンII の足が活かせた。
  • 頭は結構固い。破壊した軽戦車を利用して車体下部を隠せた
  • 砲は威力、貫通力、精度とも◎

悪かったこと

  • Tiger Pにラムしてしまった^^;(車体下部を隠すためなのだが・・・)
  • 味方をうまく利用できなかった

失敗は、Tiger Pにラムアタックをしてしまったこと。あれは、軽く接触すべきだった。

ラッキーだったこと

  • 敵の主力がみんな西に行ってしまった
  • ISの弾薬庫が燃えた
  • HellcatがAFKだった
  • Tiger Pが微妙すぎた
  • 軽戦車のルクスが最初に飛び出して私の餌食になってくれたこと

以上



2013年11月27日水曜日

[ソフトウェア品質技術]品質の定義(Gerald M. Weinberg)(第8回)


Weinberg は, 品質には相対性(立場によって重視することが異なる)があり,『品質は誰かにとっての価値である』〔Weinberg 1994〕と考えた人
  • ソフトウェアを1日8時間利用するユーザにとっては使い勝手のよさが高品質である
  • 故障のたびに批判されるシステム管理者にとってはゼロ故障が高品質である
  • 厳しい予算の制約下にあるプロジェクト管理者にとっては,開発費用が少ないことが高品質である

…などその人の立場によって定義が違うという考えですね。

◆文献

”Gerald Weinberg's Secrets of Writing and Consulting -Agile and the Definition of Quality”
http://secretsofconsulting.blogspot.jp/2012/09/agile-and-definition-of-quality.html

◆余談話

「要求仕様の探検学―設計に先立つ品質の作り込み 」で知った方ですが、なかなかユーモアのある方でいろいろな本を書いていらしゃりますね。末期癌で大変とか噂をきいたのですが、twitterでも精力的に活動しています。
https://twitter.com/JerryWeinberg

[ソフトウェア品質技術]品質の変貌(第7回)


「品質」という定義は、時代と共に変貌しているというお話。

◆ギリシャ(紀元前)


  • アリストテレス
     『範疇論』(はんちゅうろん)で量に対する質という考えを説いた?


◆ドイツやオーストリア(19世紀から20世紀)


  •  商品学
    商品の質的性質を主として、材質や原料の側面から議論し,品質を分析した。


◆アメリカ(20世紀)


プロセスを管理することによって、均一な品質の製品を安定して生産することに関心を寄せた。


[ソフトウェア品質技術]お受験断念(第6回)

「第11回 初級ソフトウェア品質技術者資格試験」が2013年11月30日にあります。
みなさん、試験勉強ばっちりですかぁ?

今回は受験を断念することにしました。
受験申し込みの段階ですでに学習の遅れが出ていたこと、私的に忙しかったので集中して勉強できなかったのが言い訳です。w

前回、申し込みだけして受験しなかった経緯もあります。
今回は、申し込みもしないで断念することに決定しました。(かなりヘタレですね~。)

ブログにアップロードしていない学習メモがいっぱいあるので少しずつアップデートしていこうと思います。orz.

◆参照情報

http://juse-sqip.jp/jcsqe/juken.html

2013年10月23日水曜日

[Windows 7]F2キーでファイル名と拡張子の両方を選択したい

Windows XPからWindows 7 x64にOSが変わって困ったことがありました。

<F2>キーの仕様が変わって、ファイル名だけが選択されて拡張子が選択されなくなったことです。

VISTAからの仕様変更ですが、ファイル名変更時に拡張子が変わって困ってしまうという多くのユーザーの意見を取り入れた形だそうです。主要な機能の仕様を変更するときは、既存ユーザーも考慮して、動作をカスタマイズできるようにしないと品質(ユーザー満足度)が下がってしまう良い例に感じました。

Ctrl+A で我慢できる人も多いようですが、技術系ドキュメントの編集が多い私にとって、頻繁にファイル名をコピーしたりする作業が多く、想像以上のペインだったので対策を探してみました。ちなみに「お忍びリネーム」というツールがありますが、64ビット環境ではうまく動作しなかったので、「AutoHotKey」を使うことにしました。

AutoHotKeyを使って
次のようなスクリプトを用意しました。スクリプトファイルは、マイドキュメントに初期生成されるものを上書きして使います。
#IfWinActive, ahk_class CabinetWClass

F2::Send {F2}^a

#IfWinActive



このスクリプトを実行すると、<F2>キーを押したときに、ファイル名と拡張子の両方が選択されます。そのほか、いろいろなキーのカスタマイズができるみたいです。

スクリプトエンジンのダウンロード先はこちらです。
http://www.autohotkey.com/

2013年8月6日火曜日

[ソフトウェア品質技術]JIS規格の調べ方 (第5回)

ソフトウェア品質技術に関連したJIS規格について調べるときは、実際の規格を読むのが早いと思いますが、どうやってインターネット上で閲覧するかを調べました。当初、購入が必要だと思っていた規格は閲覧だけなら無料でできることを確認しました。また有志の人がHTMLで公開していることもわかりました。

お勧めはやはり、PDFファイルの閲覧です。検索しやすいですし、原文そのものなので図や表などの閲覧も不自由なく読めます。どちらの方法で閲覧する場合でも、ダウンロードして自分の環境からアップロードして公開みたいなのはNGですので絶対にやってはいけません。

◆PDFファイルの閲覧

  1. 日本工業標準調査会のホームページの「JIS検索」ページを開く。

  2. 必要な情報を入力して、「一覧表示」をクリックする。
    たとえば、JIS X 0192 を調べたいときは、「JIS規格番号からJISを検索」のテキストボックスに"X 0129" と入力して 「一覧表示」をクリックする検索結果の一覧が表示されます。

  3. 一覧から検索対象のJIS規格番号のハイパーリンクをクリックする。
    クリックするとJIS規格詳細画面が表示される。

  4. 規格の閲覧 PDFのアイコンかその隣のハイパーリンクをクリックする。
    クリックすると著作権保護の警告文が表示されるのでそのまま「OK」をクリックする。新しいブラウザーウィンドウが起動し、PDFファイルが表示される。

※PDFファイルの表示されないときは、ダウンロード中の可能性があるのでもう少し待ってみるとよさそうです。それでも無理なら<F5キー>でリフレッシュしてみるのがよいかも知れません。

◆HTMLファイルの閲覧

  1. 次のWebサイトにアクセスする。
    日本工業規格の簡易閲覧
    http://kikakurui.com/
  2. 規格番号から対象範囲内のハイパーリンクをクリックする。
    たとえば、JIS X 0192 の場合、「X 0000-0999」のハイパーリンクをクリックする。

◆余談

現物のコピーは、国会図書館で依頼できるらしいです。
国会のことを英語で"National Diet"って言うんですね。知らなかった。

2013年8月5日月曜日

[ソフトウェア品質技術]ディペンダビリティ、リライアビリティ、セキュリティ、ユーザビリティ、セーフティ (第3回)

◆ディペンダビリティ と リライアビリティの違いとは?

一般的な言語学の世界では、「ディペンダビリティ(Dependabllity)」 と 「リライアビリティ(Reliability)」は「同意語(Synonym)」な扱いだと思いますが、ソフトウェア品質技術や科学、学問の世界では違うものとして扱われているらしいです。

『JIS Z 8115 2000』によると、ディペンダビリティはリライアビリティと同じように「信頼性」と訳されることが多いが、ディペンダビリティはリライアビリティよりも上位のより包括的な概念だそうです。
  • ディペンダビリティは、非定量的用語で一般記述に使う(信頼性)
  • リライアビリティは、定量的な表現で使う(信頼度)
だそうでう。

◆ディペンダビリティ、リライアビリティ、セキュリティ、ユーザビリティ、セーフティの関係は?

ディペンダビリティという知識領域の下には副知識領域として次の領域が存在します。
  •  セキュリティ(Security)
  •  ユーザビリティ(Useability)
  •  セーフティ(Safety)

結局、図で書くとこんな感じでしょうか?
@Todo: 図を入れる

◆余談ですが・・・

『JIS Z 8115 2000』によると、ディペンダビリティは、 次の3つを含むものという説明がありました。
  • ”Availablity"
  • "Maintainability"
  • "Reliablility"
SQuBOK Guideで気になる点はガイドとしてのスタンスが分かりにくい点が多いことです。そもそも、見出しに「ディペンダビリティ,リライアビリティ,セキュリティ,ユーザビリティ,セーフティの関係」と書いているのだから、きちんとその5つの関係を説明して欲しいのだが、読めば読むほど混乱してしまうのは自分だけでしょうか?

◆参照情報

"dependability and reliability - WordReference Forums"
http://forum.wordreference.com/showthread.php?t=38022

2013年7月26日金曜日

[ソフトウェア品質技術]Error、Fault、Failure の定義 (第4回)

『SQuBOKガイド』からそのまま引用します。

「JIS X 0014〔JIS X0014:1999〕の定義
  1. 「誤差・誤り(ISO/IEC 2382-14の error)
    計算、観測若しくは測定された値または状態と、真の、指定された若しくは理論的に正しい値または状態との間の相違。
  2. 「障害(同ISO/IECの fault)
    要求された機能を遂行する機能単位の能力の、縮退または喪失を引き起こす、異常な状態。
  3. 「故障(同ISO/IECの failure)
    要求された機能を遂行する,機能単位の能力がなくなること。」

◆言いかえるとこんな感じかな…

  1.  「誤差・誤り(error)」
    異常な値や状態、正常な値や状態との相違のこと
  2. 「障害(fault)」
    故障を引き起こす状態
  3. 「故障(failure)」
    実行できなくなること

◆注意事項

人的過誤(mistake やhumane error)は、「誤差・誤り(error)」に含まれないらしいです。

2013年7月24日水曜日

[ソフトウェア品質技術]JIS規格 規格番号の書式について (第2回)

◆JISの規格番号の意味が知りたい

JISの標準規格は、番号で管理されています。そんなことは理解できますが、JISの番号は、JISの後に続く、「JIS Z xxxxx -n:19xx」や「JIS X xxxxx」などと表記されていて、具体的にどんな意味が有るのかが分かりません。

部門記号

このアルファベット、部門記号と呼ばれていて、規格を部門でカテゴライズするものとして利用されているみたいです。部門記号に続く4~5桁の数字と合わせて一意の規格番号になっています。

SQuBOKで頻繁に使用されている部門記号は次のとおりです。
  • 「C」電子機器及び電気機械
  • 「X」情報処理
  • 「Q」管理システム
  • 「Z」その他
この記号、部門名を英語にしたときの頭文字が記号になっているわけではないそうです。
単純にアルファベットの昇順で部門をアサインした感じなので、関連したJIS期間番号の出題が有ったと思うので、暗記必須だとキツイですね。(暗記が苦手です。)
あと、「その他」という部門は適当すぎると思うし、「I」、「J」、「O」などの部門記号が無いのも気になるところです…

SQuBOKに取り組まれている規格番号を表にしようと思ったが数が多い。単純なテキスト検索で400件以上だったので断念しました。読み進めるにあたって、キーとなる規格番号が理解できたらそのときまとめることにします。"JIS X 0129" だけ憶えておきますか・・・

枝番(第n部)

枝番は、規格の規模が大きいときに、"-n" で表記して部に分けるときに使います。たとえば、"JIS X 0129-1"は、「ソフトウェア製品の品質― 第1部:品質モデル」となるらしいです。

改正版

規格は、改正されることがあり、改正した年数を入れることで改正版であることを示すそうです。たとえば、"JIS X 0129-1:2003" は「ソフトウェア製品の品質― 第1部」の2003年改正版を示しているらしいです。

◆参照情報

2013年7月18日木曜日

[ソフトウェア品質技術]ソフトウェア品質技術者試験学習 (第1回)

◆経緯

ソフトウェアの品質に関わる仕事をしているため、体系的な知識を増やすことを目的にソフトウェア品質技術者試験を受けることしました。

今回で受験は、2回目です。前回は、それなりに問題集を中心に勉強をしました。
なので、問題集の問題はすべて正解を答えられ、問題集に出てきたキーワードはだいたい理解した状態での受験でした。

もちろん「不合格」だったんですよ。ネットで調べると、難易度が低くて問題集だけで簡単にとれたという人が多いようです。そういう方々は、試験ロジックに精通した優秀な人達だと思います。

◆やること

  • SQuBOK Guideの熟読
    『初級シラバスV1.1』に書かれている知識レベルを参考に、どの見出しに注力するかを考えながらこの本を読むことにします。

    SQuBOKの熟読度と合格率の関係を見れば一目瞭然?熟読者の方が合格する可能性が高いからです。

    でも、この表を見ると、「一通り読む」だけではかえって合格率が下がっているところが気になりますね。これ、考えられる原因は問題集の影響度だと思いました。この統計は、9回目の試験であり、ちょうど問題集が発売された回の試験だったんです。

    「一通り読んだ」と回答した人達は、問題集のウェイトが高かったんじゃないでしょうか? 問題集は、網羅性、解説もそこそこですが、応用力に欠ける自分にとって、本番の設問が問題集の説明から外れていると回答に苦しむこと間違いなしです。

    なので、今回の試験対策ではこの本の熟読を中心にやって行こうと思いました。
  • 問題集回答
    問題集は間違いなく、全て回答できることを目標にします。恐らく、この問題集を解くころにはSQuBOK Guideも熟読済みなのでさほど難しくないでしょう。

◆計画

テストまでの学習期間と学習ステップは次のとおりです。
  • 学習期間 7月14日(日)~11月29日(金)計138日
  • 熟読1回目 8月21日
  • 熟読2回目 9月28日(土)
  • 試験申し込み 9月28日(土)
  • 問題集回答 10月8日
  • 熟読3回目 ~11月15日(金)
  • 問題集回答 ~10月25日
  • 最終調整 ~11月29日(金)
  • 受験 11月30日(土)

138日
46日 x 3回
75項目 1日2項目=38日

1. ソフトウェア品質の基本概念
 1.1 品質の概念 LV1
  1.1.1 品質の定義(品質の考え方の変遷) LV1
  1.1.2 ソフトウェア品質モデル LV1
  1.1.3 ディペンダビリティ LV1
  1.1.4 セキュリティ LV1
  1.1.5 ユーザビリティ LV1
  1.1.6 セーフティ LV1
 1.2 品質のマネジメント LV2
  1.2.1 品質コントロールの考え方 LV2
  1.2.2 品質保証の考え方 LV2
  1.2.3 改善の考え方 LV2
  1.2.4 ソフトウェアの品質マネジメントの特徴 LV2
  1.2.5 ソフトウェア測定の考え方 LV2
  1.2.6 ソフトウェア評価の考え方 LV2
  1.2.7 V&V(Verification & Validation) LV2
  1.2.8 検査 LV2
2.ソフトウェア品質マネジメント
 2.1 ソフトウェア品質マネジメントシステムの構築と運用 LV1
 2.1.1 品質マネジメントシステム LV1
  2.1.2 ソフトウェア品質推進活動 LV1
  2.1.3 品質マネジメント組織 LV1
 2.2 ライフサイクルプロセスのマネジメント LV1
  2.2.1 ライフサイクルモデル LV1
  2.2.2 プロセスモデル LV1
 2.3 プロセスアセスメント・プロセス改善のマネジメント LV1
 2.4 検査のマネジメント LV1
 2.5 監査のマネジメント LV1
 2.6 教育・育成のマネジメント LV1
 2.7 法的権利・法的責任のマネジメント LV1
 2.8 意思決定のマネジメント LV1
 2.9 調達マネジメント LV1
  2.9.1 パートナーとのコミュニケーション LV1
 2.10 構成管理) LV2
  2.10.1 変更管理) LV2
  2.10.2 バージョン管理) LV2
  2.10.3 不具合管理) LV2
 2.11 リスクマネジメント LV1
 2.12 プロジェクトマネジメント全般 LV1
 2.13 品質計画のマネジメント LV1
 2.14 レビューのマネジメント LV1
 2.15 テストのマネジメント LV1
 2.16 品質分析・評価のマネジメント LV1
 2.16.1 製品品質の分析・評価 LV1
 2.16.2 プロセス品質の分析・評価 LV1
 2.17 運用・保守のマネジメント LV1
3.ソフトウェア品質技術
 3.1 メトリクス LV2
  3.1.1 測定理論 LV2
  3.1.2 プロダクトメトリクス LV2
  3.1.3 プロセスメトリクス LV2
 3.2 品質計画の技法 LV2
 3.3 要求分析の技法 LV2
 3.3.1 品質要求定義 LV2
 3.4 レビューの技法 LV3
  3.4.1 レビュー方法 LV3
  3.4.2 仕様・コードに基づいた技法 LV3
  3.4.3 フォールトに基づいた技法 LV3
 3.5 テストの技法 LV3
  3.5.1 経験および直感に基づいた技法 LV3
  3.5.2 仕様に基づいた技法 LV3
  3.5.3 コードに基づいた技法 LV3
  3.5.4 フォールトに基づいた技法 LV3
  3.5.5 利用に基づいた技法 LV3
  3.5.6 ソフトウェアの形態に基づいた技法 LV3
  3.5.7 組み合わせの技法 LV3
  3.5.8 リスクに基づいた技法 LV3
  3.5.9 テスト技法の選択と組み合わせ LV3
  3.5.10 テスト自動化技法 LV3
 3.6 品質分析・評価の技法 LV3
  3.6.1 信頼性予測に関する技法 LV3
  3.6.2 品質進捗管理に関する技法 LV3
  3.6.3 障害分析に関する技法 LV3
  3.6.4 データ解析・表現に関する技法 LV3
 3.7 運用・保守の技法 LV2

◆参照情報



2013年3月24日日曜日

清水公園の温室

千葉県野田市にある清水公園へ行ってきました。
桜の季節なのだかわかりませんが、清水公園には人がいっぱい。
ゆっくりベンチでお昼を食べることができずに入った花ファンタジア。
http://hanafantasia.jp/

シーズンオフなので、庭の花がぜんぜん少なかったんですが、温室は面白かった。

有料施設には空のベンチがいっぱい。1人630円。

併設されている花ファンタジアの温室に入りました。
そこで、変わった植物を発見したので紹介しておきます。




これは花のつぼみです。
咲くとこうなります!


すごい色でしょ?まるで翡翠(ヒスイ)みたいなので「ヒスイカズラ」というらしいです。


 今度は、ツツジが菖蒲の花が咲くころに再挑戦です。