約 3,744 件
https://w.atwiki.jp/hokonin/pages/50.html
#blognavi 2009/10/12に行われた技術士一次試験の専門科目（情報工学）の予想解答です。この解答が正しいことを保障するものではありません。 IV-1 …… 2 1～20までを足すと210（11010010）、これは46（00101110）を足すと0（100000000、9bit目無視）になるので、-46 IV-2 …… 2 桁落ち。問題のように有効桁数7桁で、5桁目までが非常に近い2値を減算すると、有効桁数が2桁以下に減ってしまう。 IV-3 …… 4 引数値は次の通り。(n,a,b)＝(6,1,1)→(5,1,2)→(4,2,3)→(3,3,5)→(2,5,8)→(1,8,13)。よって8 IV-4 …… 4 #が最優先で右から左に結合なので、まず「a@b$c@(d#(e#f))」とできる。あとは$→@の順に括弧をつけるだけ。 IV-5 …… 3 IV-6 …… ? 未選択 IV-7 …… 5 IV-8 …… 4 組合せだけなら5も正しいが…… IV-9 …… 3 IV-10 …… 5 未選択 IV-11 …… ? 未選択 IV-12 …… 3 IV-13 …… 2 0.9*10+0.1*60=15 IV-14 …… 2 IV-15 …… 1 A200→B200→C200（終了）→D200→B200（終了）→D200→A100（1500経過） IV-16 …… ? 未選択 IV-17 …… 1 IV-18 …… 5 IV-19 …… 3 IV-20 …… 1 IV-21 …… 3 未選択 IV-22 …… 3 IV-23 …… 5 IV-24 …… 4 IV-25 …… 1 IV-26 …… ? 未選択 IV-27 …… ? 未選択 IV-28 …… 1 未選択 IV-29 …… 5 IV-30 …… 4 IV-31 …… 5 IV-32 …… 4 IV-33 …… 4 5と書いてしまった…… IV-34 …… 2 未選択 IV-35 …… 4 カテゴリ [資格・免許] - trackback- 2009年10月16日 13 01 17 名前 コメント #blognavi
https://w.atwiki.jp/hokonin/pages/42.html
blog2009/2009年04月24日/HTML＋JavaScriptでコンボボックスを作る～その２～ #blognavi
https://w.atwiki.jp/hokonin/pages/69.html
#blognavi 本日受けてきた、情報処理技術者試験のプロジェクトマネージャの午後I解答例を書いておく。問1と問3を選択。 今回の午前IIはちょっと毛色の違う問題が多かった。自分の正答率は80%だったので助かったけど、引っかかった人は多そうだと感じた。 問1 設問1 (1)判明した不具合の影響調査と対応 (2)仕様理解の容易化と手戻り発生の軽減 設問2 (1)独自開発部分の規模増加による納期遅延 (2)具体的なイメージを元に要件を固められる 設問3 (1)新規に開発又は修正した部分を含む上位のプログラム (2)当該機能に詳しい要員がチームリーダ等に適切に配置されているか (3)テストケース内容が障害検出の面で不十分 (4)テストケースを再度洗い出して追加テスト 設問4 (1)最終的に対応不要となる障害に対応する無駄をなくせるから (2)障害の業務への影響と、８月に対応する必要性の有無 問3 設問1 (1)本番移行の対象となるデータ件数が減るから (2)各案で本番移行に要する時間を試算する (3)本番移行が６時間以内に終えられるか 設問2 現行システムに詳しい要員の参画または支援の要請 設問3 (1)本稼働後の実環境に近い状態でテストが行えるから (2)不具合の原因がデータ側と機能側のどちらにあるかの切分けを迅速に行えるから 設問4 (1)修正により新たに不具合が入り込み、データ移行が正しく行えない (2)対象データの変更も含め、本番移行が６時間以内に終了するか所要時間の把握 色々題意を外してる気もするけど、6割取れてると良いな。 カテゴリ [資格・免許] - trackback- 2010年04月18日 23 33 28 名前 コメント #blognavi
https://w.atwiki.jp/hokonin/pages/61.html
#blognavi 本日1/12より、H22春期の情報処理技術者試験の申込みが開始された。 予定通り、PMの申込みを完了。 本当は昼休みの内に会社から申し込むつもりだったところ、午前I免除のための合格者番号を調べておくのを忘れたため帰宅してから申し込んだ。 情報処理教科書は既に4周くらい読んでいるけど、論文ネタの用意がほとんど進んでいない。 気を引き締めてかかろう。 カテゴリ [資格・免許] - trackback- 2010年01月12日 21 29 28 名前 コメント #blognavi
https://w.atwiki.jp/hokonin/pages/33.html
(2009年01月23日) W-Zero3メールの起動が遅い
https://w.atwiki.jp/hokonin/pages/58.html
#blognavi 「問3 事前予防的な問題管理について」を選択 １ 私が携わったＩＴサービスとインシデント発生傾向 の概要 １．１ ＩＴサービスの概要 Ａ社は東京に本社と、全国に１０箇所の営業拠点と６ ００の代理店を持つ保険会社であり、東京の通信センタ にある２台のホストと３台のＷｅｂサーバによる２４時 間３６５日稼動のオンラインサービスを稼動している。 私は通信センタ内のネットワークシステムを開発し、 保守・運用を委託されている情報システム会社Ｂ社に所 属し、運用チームとして通信センタに常駐してＩＴサー ビスマネージャ業務を行っている。 このネットワークシステムは、全国の約１０００台の 端末と、３台のＷｅｂサーバからの電文を中継するゲー トウェイサーバ（ＧＷ）を配置して、負荷分散、優先度 制御を行いホストに中継する。また、各機器の稼動状況 の監視、ログの採取、アラートの通知機能を持ち、Ｗｅ ｂサーバ用のＧＷはセッション毎に動的に端末ＩＤを割 り当てる機能を有している。 Ａ社と締結したＳＬＡの中には、２４時間３６５日の インシデント受付と、応答時間５分以内の遵守率９５％ という項目が含まれている。 １．２ インシデント発生傾向の概要 ＳＬＡ遵守のため、測定している項目の中に、ＧＷ内 の電文処理時間がある。これは電文がＧＷに到達してか らホストに送信する時間と、ホストからの応答を受けて から端末やＷｅｂサーバに返信する時間の和である。 電文処理時間の閾値を２．５秒に設定したところ、閾 値をこえる現象が月に６日程度発生した。これらの発生 は月末月始に集中していた。さらに時系列分析を行った ところ、午後１時から午後３時に集中していた。 ２ 発生傾向に対する問題の発見と対策 インシデント発生傾向に対しては、仮説検証などによ る考察を深める事が重要と考え、以下の通り行動した。 ２．１ 発生傾向に対する仮説と検証 判明した発生傾向は明らかに業務のピーク時に集中し ていることから、私は以下３つの仮説を立てた。 ・ネットワーク帯域のボトルネック ・ＧＷのハードウェア性能不足 ・ＧＷ内の制御プログラムのミス ネットワーク帯域に関しては、回線速度が１Ｇｂ／秒 に対し、電文１件当たり２０ｋＢでピーク時電文件数２ ０００件／秒であることから否定した。 ＧＷのハードウェア性能に関しては、ピーク時電文件 数が緩やかに上昇していることから否定した。 ＧＷ内の制御プログラムのミスに関して、Ｂ社開発部 の協力を得て調査したところ、端末ＩＤを動的に割り当 てる処理を行う際、内部テーブル全体をロックして処理 を行っており、単位時間当たりの電文件数が一定量を超 えると応答時間が加速度的に悪化することが判明した。 さらに、このプログラムが適用されてしまった理由と して以下の仮説を立てた。 ・現在のピーク時電文件数が開発部に伝わっておらず、 テストケースの想定値が甘い 実際に、開発時のテストケースを確認したところ、ピ ーク時電文件数の想定値が現在と比べ５００件程下回っ ていることが判明した。 ２．２ 発見した問題の対策 まず、応答時間が閾値を超えている問題については、 テーブル全体をロックするのではなく、レコード単位で ロックするようプログラム改修を行う必要がある事をＡ 社に報告した。電文件数は今後も増加傾向にあることか らＡ社より変更要求が出されることになった。 次にテストケースの想定値が実際と異なっている問題 については、臨時にＢ社開発部と会議を行い、ＳＬＡ遵 守のためにテストケースで用いる想定値が現実からかい 離しないよう、現在の想定値を伝えた。 ３ 事前予防定着のための取り組みと今後の改善 ３．１ 定着のための取り組み 事前予防定着のためには、担当者一人一人がＳＬＡを 理解し、事前予防を意識して作業を行う事が重要である と考えた。 そこで、運用チームとＢ社開発部を対象にＳＬＡの理 解度に関するアンケートを実施したところ、運用チーム ではほぼ１００％理解していたのに対し、開発部では５ ０％程度の理解であることが判明した。特に末端の開発 者にその傾向が強かった。 私は、ＳＬＡとインシデントの事例を含め、ＳＬＡ遵 守のために一人一人が意識して取り組むための資料を作 成し、配布した。これは約２０ページあり、例えばテス トケースの想定値が現実と異なっていないか意識する、 といった内容である。 ３．２ 今後の改善 上記取り組みは万全ではないため、改善が必要である。 具体的には、資料の具体的な数値が現実とかい離してい ないか常にチェックしたり、開発開始時やテストケース レビュに参加し、ＳＬＡ遵守の観点で開発が行われるよ うチェックすることが必要である。 また、インシデントを予防した者に対し、表彰を行う ことも予防活動の定着には効果的であると考えられるた め、Ｂ社上層部に進言するなどし、予防活動が定着する ようにしていきたい。 以上 ●試験本番の流れ ITILのプロセス中心、かつ変更管理と構成管理を捨てて準備していたので必然的に問3を選択 プロアクティブな問題管理についてはネタを準備していなかったので試験時間中に構想 内部テーブルのロック方式に起因する問題が使えると思い、月末月始の業務ピーク時に閾値超えというオーソドックスな展開を逆算 その他の仮説としてネットワーク帯域とハードウェアがあるところまで考え、多分いけると思って記述を開始 設問イの仮説検証を書く段階になり、回線速度を適当に1Gbpsとし、電文長、電文量を逆算して問題ない数値に決定 設問イの最後で、問題への直接的な対策だけでは題意に沿えないと気付き、問題のあるプログラムがリリースされた事に対する対策も追加 構想段階であまり考えられていなかった設問ウは、試験対策本にあった障害対応マニュアルの作成を参考にページ数などを随時考えて記述 最終的に字数が足りず、時間も迫っていたので問題文にあった表彰について記述し、時間ギリギリで終了 ●突っ込みどころ Style：略語を除いて英数字は半角で書くべきだった（減点：無） Style：箇条書きは○で囲った(1)、(2)、……とすべきだった（減点：無） 1章：タイトルは「インシデント」だが、内容は前段階の「閾値超え」について記述している。題材としては問題文の例に「ヒヤリハット」もあり問題ないが、タイトルとしては不適切（減点：極小） 1章：ホスト2台にWebサーバ3台と微妙なシステム構成だった。これは仮想の構成だが、事実かもしれないシステム構成部分で減点はないはず（減点：無） 1章：「ITサービス」ではなく「システム」の概要がメインになっている（減点：小） 1章：閾値の設定根拠が書かれていない。ただし本問のメインは潜在問題の発見プロセスのため、設定根拠はそれほど重要ではないはず（減点：小） 2章：仮説「ネットワーク帯域」を挙げたがGW内部の処理時間にネットワークは全然関係ない。論述は仮説3が軸のため致命的ではなかったか（減点：中） 2章：仮説「ネットワーク帯域」を否定した理由として最低限の数値は挙げているが、最終的な数値を記載せず若干論理の飛躍がある（減点：極小） 2章：仮説「GWのハードウェア性能不足」でどう緩やかに上昇しているのか説明が不足している。仮説3が軸のため減点は少なめか（減点：極小） 2章：1.1で「Webサーバ用のGW」と書いた通り、元々端末用とWebサーバ用でGWは別に存在する想定で書いている。また、動的な端末ID割り当てはWeb用の処理であり、実端末は固定端末IDを持つと想定している。従って、業務（実端末）では端末IDの割り当て処理は行われず、ピーク時に応答が遅くなるという論理は破綻している。これは致命的なミスだが、GW台数と端末IDについては抽象的な表現であること、実端末からの処理でも内部テーブルロックが発生する作りなのかも知れないこと、から論理破綻には気付かれなかった可能性がある（減点：無？） 2章：問題への対策について論述ボリュームが少ない。これも潜在問題の発見プロセスがメインのため大きくは減点されないはず（減点：小） 2章：漢字の「乖」が書けていない（減点：極小） 3章：運用チームとして事前予防のために取り組んだ「活動」を軸に書くべきだった。ただ開発者側へのアクションも活動の1つのため減点は少なめか（減点：小） 3章：開発者のサガで「開発」と連呼しているが、ITIL的には変更管理での変更時という視点も加えて書くべきだった（減点：極小） 3章：内容が思いつかず問題文にあった表彰について書いてみたが、３章の内容からは繋がり辛い内容であった（減点：小） ●まとめ 受験直後は論理破綻に気付いて絶対に落ちていると思ったが、上述した通り、抽象的な表現が採点者に論理破綻を気付かせなかった幸運があったと思う。 それ以外では、仮説→検証→仮説→検証とある程度題意に沿って記述できているため、こんな内容でも合格に繋がったのだと思う。減点を極小 1、小 5、中 10 とすると、合計 40 の減点。60点でギリギリA評価だったのかな、という感じ。 とにかく内容のほとんどが想像の産物なので、また苦労して論文の準備をしなくて良くなり安堵している。 カテゴリ [資格・免許] - trackback- 2009年12月24日 07 19 53 名前 コメント #blognavi
https://w.atwiki.jp/hokonin/pages/34.html
blog2009/2009年01月23日/W-Zero3メールの起動が遅い #blognavi
https://w.atwiki.jp/hokonin/pages/59.html
blog2009/2009年12月24日/H21年度秋季ITサービスマネージャ試験 復元論文 #blognavi
https://w.atwiki.jp/hokonin/pages/43.html
#blognavi プログラムはインストールしたくないけど.NETアセンブリを逆アセンブルしたい時に。 １．まず.Net Framework SDK 1.1 を入手する http //www.microsoft.com/downloads/details.aspx?familyid=9B3A2CA6-3647-4070-9F41-A333C6B9181D displaylang=ja ２．アーカイバ（FPress など）で [Setup.exe] を開き、[netfxsd1.cab] を取り出す ３．[netfxsd1.cab] から [ildasm_exe_1_JPN_X86.3643236F_FC70_11D3_A536_0090278A1BB8] を取り出す ４．取り出したファイルを [ildasm.exe] にリネームする ５．[ildasm.exe] を [%System%\Microsoft .NET\Framework\v1.1.4322\] フォルダに置く 注1) .Net Framework SDK 2.0 も同様に [Setup.exe] の [netfxsd1.cab] に同名のファイルが入っている 注2) .Net Framework 3.0, 3.5 は 2.0 の ildasm.exe で OK カテゴリ [Program] - trackback- 2009年04月27日 19 07 31 名前 コメント #blognavi
https://w.atwiki.jp/hokonin/pages/63.html
blog2010/2010年01月12日/H22春期 情報処理技術者試験申込み #blognavi