情報処理過去問のまとまったサイト

毎年、情報処理受けていますが、参考書って、一回買うと、使いまわすので、最新の問題
を使いたくなります。

このサイトに過去問がたくさんあるので、使ってみると便利です。
ただ、回答の解説がないので、他のサイトなども使って、利用した方がよさそうです。

　http://go2.shoeisha.jp/c.p?82cvz445hF1

IPAのWebサイトからも、過去問題が、すべてダウンロードできる形で公開されています。
しかし、IPAのWebサイトでは、過去問題が年度ごとにまとめられているので、過去問参照は、上のサイトの方が便利です。

VisualStudioから、直接実行した場合に、下図のようなエラーダイアログが表示されました。
対応策を調べましたので、まとめておきました。

【ダイアログ内のメッセージ】
CLR は、COM コンテキスト 0x73e3cbf8 から COM コンテキスト 0x73e3cd20 へ 60 秒で移行できませんでした。ターゲット コンテキストおよびアパートメントを所有するスレッドが、ポンプしない待機を行っているか、Windows のメッセージを表示しないで非常に長い実行操作を処理しているかのどちらかです。この状態は通常、パフォーマンスを低下させたり、アプリケーションが応答していない状態および増え続けるメモリ使用を導く可能性があります。この問題を回避するには、すべての Single Thread Apartment (STA) のスレッドが、CoWaitForMultipleHandles のようなポンプする待機プリミティブを使用するか、長い実行操作中に定期的にメッセージをポンプしなければなりません。
➾C#からネット上にMySQLに大量のデータを書き込んでいる時に、エラーが発生するようです

【対応策】
Visual Studioの
[デバッグ] メニューの [例外] で表示されるダイアログで [Managed Debuggin Assistants] の [ContextSwitchDeadlock] のチェックを外す。

【参考URL】
https://social.msdn.microsoft.com/Forums/ja-JP/39fef89f-19f6-4c6a-ad9e-7d6a35200bed/contextswitchdeadlock?forum=vbgeneralja
http://accountingse.net/2010/10/216/
http://nanaganbaru.blog.fc2.com/blog-entry-273.html

IE開発者ツールの使い方（メモリリーク調査）

IEに「開発ツール」があります。
IEの歯車アイコン選択して、「 F12開発ツール」選択すると起動します。

この 「開発ツール」を使うことで、以下調べることができます。
・パフォーマンス調査(CPU時間など）
・ メモリリークの調査

【メモリリーク調査】
 ［メモリ］ツールは、メモリの使用量を調査できるツールで、以下の機能があります。
① プロファイリングセッションの開始。
② プロファイリングセッションの終了。
③ プロファイリングセッションのインポート。
④ プロファイリングセッションのエクスポート。
⑤ ヒープスナップショットの作成。
⑥ メモリ合計。

　プロファイリングセッションを開始①すると、終了②するまでメモリの合計⑥がグラフで表示される。
⑤の［ヒープ スナップショットを作成します。］をクリックすると、そのクリック時点での、ページで使われているメモリの詳細情報（＝スナップショット）が採取される

ヒープスナップショットは、メモリの状況を以下確認できます。
① ページ内のメモリ使用量。
② ページ内で保持しているオブジェクト数。
③ メモリ使用量と前回のスナップショットからの増量が表示される。
④ オブジェクト数と前回のスナップショットからの増減数が表示される。

①～④のようなリンクをクリックすることで、その詳細を確認できる。例えば、オブジェクト数の増減を示している④をクリックしてみよう。すると次の画面のように表示される。

タブ［種類］［ルート］［ドミネーター］をクリックして、オブジェクト数の関係詳細を把握することができます。
詳細は、実際に表示してみると、何となくわかりますが、
詳しく知りたい人は、【参考URL】のサイトを確認すると、分かりやすいです。


まとめますと、
・作成したページのメモリ使用量が多い場合
・使っているうちに次第にメモリ使用量が増えていく場合
などで、問題がどこにあるのかを特定する際に役に立ちます。

パフォーマンス調査用に、YSlowというツールも便利そうです。
下の参考URLにYSlowについて、詳しく書いてありました。
時間のある時に、使ってみようと思っています。


【参考URL】
http://www.yoheim.net/blog.php?q=20130708
http://www.buildinsider.net/web/ief12devtools/01

システム管理のお仕事(その5)

今回は、リリース管理について、まとめます。

ソフト開発すると、バグ修正することに、モジュールをリリースします。
その時に、いつ、どのような内容でモジュールをリリースしたのかバージョン管理することで、不具合の再起(デグレ）時のソース確認作業等、役に立つことができます。
また、お客様の問い合わせや、モジュールの再インストール等でも利用できます。

http://www.itmedia.co.jp/im/articles/1009/09/news110.html
http://www.itmedia.co.jp/enterprise/articles/0710/18/news011.html

リリース管理の最終目標は、変更管理が計画した変更を、本番環境に確実に実装することであり、そのために不可欠なのが「テスト」と「リハーサル」となります。
確実にテストされたバージョンのみをリリースすることを保証するようにます。

リリース前のテストでの確認内容は次のようになります。
（1）計画されたリリース手順が問題なく実行できるか
（2）計画されたリソースに過不足はないか
（3）リリースがほかのITインフラに負の影響を与えないか
（4）仮にリリースに失敗した場合、安全に元の状態に戻せる（切り戻し）か
（5）切り戻しの手順は確立されているか

リハーサルを行うのも重要で、可能であれば、（仮想的なものでもいいから）本番環境とまったく同じ環境を作ってリハーサルするのが望ましいといえます 。

又、本番環境にリリースしたすべてのソフトウェアのインストールキット、リリースの手順書、ソフトウェアのマニュアルなどを1カ所に集めて保管しておくことが重要になります。
ソフトウェアの再インストールが発生した場合でも、DSL（DML)を参照すればそこにすべてのキットと手順書、マニュアルが存在しているので迅速に対応できるのです。

DSL :（Definitive Software Library：確定版ソフトウェアの保管庫）
DML :（Definitive Media Library：確定版メディアライブラリ）

廃棄されたアプリケーションもある程度の期間保管しておくことも重要で、バージョン管理も必ず行いましょう。

HTTPヘッダーの情報

時々レスポンスデータの解析を行いますが、その都度、情報を調べないといけないので、
メモで必要な情報を残しておきます。

参考URL ：
http://web-tan.forum.impressrd.jp/e/2010/01/12/7156

●HTTPリクエスト
１）1行目：HTTPリクエスト行
「メソッド」「URL」「HTTPのバージョン」の3つの情報が含まる。
メソッド：GET＝HTTPリクエストでは「データ本体」は送られない
　　　　　POST＝HTTPヘッダーの後にデータ本体が続きます

 ２）2行目以降：HTTPヘッダー
・ユーザーエージェント名（User-Agent）　：　 
　ブラウザの種類やOSの情報
・リファラ（Referer）　：　
　どのページから発生したリクエストなのかを示します。
　例えば、ページAにあるリンクをクリックしてページBに行った場合に、ページBへのHTTPリクエストにリファラーとしてページAが入る
・更新されていたら（If-Modified-Since）／同じでなければ（If-None-Match）　：
 ブラウザは、一度表示したデータを「ローカルキャッシュ」として保存しておき、同じデータは何度も通信して取得しなくてもいいようにしています。そのときの情報となります。
・ クッキー（Cookie）
・受け取り希望（Accept、Accept-Language、Accept-Encoding、Accept-Charset）

● HTTPレスポンス
 「レスポンス状態行」「HTTPヘッダー」「データ本体」の3つのパートがあります。

１）1行目：レスポンス状態行 
　ここには、「HTTPステータスコード」などが含まれます。

200番台は成功
　200：OK、データを送ります

300番台はリダイレクト
　301：新しい場所から取得してください（今後もずっと）
　302：新しい場所から取得してください（今回だけ）
　304：変更されていません（データ本体は送られない）

400番台はクライアント側のエラー
　401：ユーザー認証が必要です
　403：アクセスが禁止されています
　404：見つかりませんでした

500番台はサーバー側のエラー
　500：内部エラー
　503：現在はサービス提供不可能


２）HTTPヘッダー 
　各種の状態を示す情報が入れられている部分です。
・コンテンツタイプ（Content-Type）
 　データがHTMLなのか画像なのかや、文字コードなどの情報。
・ 再利用期限（Expires）
　取得したデータを再度サーバーに問い合わせなくてもブラウザが再利用していい期限（キャッシュの制御に使われる）。
・データの最終更新日時（Last-Modified）やエンティティ情報（ETag）
　次回同じデータをリクエストする際に、これらの情報を使って更新されているかどうかを確認します。
・キャッシュ制御（Cache-ControlやPragma）
　ブラウザや通信を橋渡しするプロキシが、データのキャッシュをどう扱うかの情報。
・接続状況（Connection）
　接続を持続するのか（keep-alive）、毎回接続を切断するのか（close）。ブラウザもサーバーもHTTPバージョン1.1の持続接続（keep-alive）を使える場合、通信のやりとりが効率良くなります。
・移動先（Location）

システム管理のお仕事(その３)

10/19(日)にAP試験を受けてきました。
情報処理といえば、昔はプログラミング試験に近かったのですが、今の試験は、サポートや経営に近い内容の試験問題が多いですね。
前回記載した、インシデント管理、今回説明する問題管理について、午後試験に出題がありました。
日々、問題意識を持って仕事をするのが大事だとつくづく思いました。

AP試験の問題解答は、以下URLにあります。（問１０が問題管理の問題）
http://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2014h26.html#26aki


●問題管理

１、問題とは？
ITサービスの品質低下をもたらしている状態、または、もたらす可能性のある状態を引き起こしている「根本原因」を問題といいます。

IITL（システムの運用、管理業務に関する体系的なガイドライン）では「インシデントを発生させる可能性のある未知の原因」のことを「問題」といっています。
つまり、問題＝インシデントの根本原因となります。

原因が明らかになり、一時的な回避策、あるいは永続的な解決方法が判明したら、問題は既知のエラーと呼ばれます。

２、問題管理とは？
ITサービスの品質低下をもたらしている、または、品質低下をもたらす可能性のある状態を引き起こしている根本原因 を効果的・効率的に認識し、特定し、速やかな解決に導くためのIT運用管理上の1つのプロセス」といわれています。
（サービスの品質低下の対策をインシデント管理で行い、問題解決を問題管理で行います）

 問題管理を、大きく2つに分けると次のようになります。

1) インシデントの、原因と追究
インシデント管理がビジネス側の業務を復旧させることを最優先に活動しますので、
原因追求を行わず、とにかくビジネスを復旧させます。
その後、問題管理が原因追求を行います。
よって、インシデント管理と問題管理を別プロセスと捉えています。

2) 恒久的な解決策の、立案と実施
問題の根本原因が明らかした後、恒久的な解決策の立案と実施を行います。

日々の業務に埋もれがちな予兆を発見し、大事に至る前に予防措置をとるというプロアクティブな活動も含まれます。
予兆の発見や根本原因の特定には、経験によって養われる直感が威力を発揮しますが、まずは情報が必要になります。
経験済みの障害だけでなく、類似する障害の発生を未然に防ぐことも大事となります。

原因追求には次の４点を視点に行います。
（1）問題の明確化
（2）事実の明細化（整理)
　3W1E（What、Who、Where、Extent）の項目ごとにIS（起きている事実）とISNOT（起きても良さそうなのに起きていない事実）を列挙する。
（3）原因の想定
（4）原因の絞込と裏づけ

３、 ワークフロー
参考URL:
http://www.newton-consulting.co.jp/itilnavi/glossary/problem_m.htm
http://www.manageengine.jp/products/ServiceDesk_Plus/problem-management.html


(1) 問題の識別と記録
　インシデントの発生をもたらした根本原因が不明な場合に、問題として認識されることになります。
  その問題を識別し、問題管理表を作成して、問題レコードとして記録する。
　問題管理表作成時には、問題管理発生元のインシデント番号 も記載します。
　（インデント管理表には、リンクしている問題管理番号を記載します）

　
(２) 優先度の設定、調査と診断
　記録された問題を、緊急度で分類し、優先度を決定する。
　緊急度は、「ビジネスに対するインパクトと緊急度」という観点から行います。

　優先順位にもとづき、より優先度の高い問題から、調査を開始し、根本原因の究明を目指します。

　必要に応じて専門家チームを結成し、問題の根本原因を調査する。
  根本原因が判明した問題は既知のエラーとして、記録します。

(３) エラー制御（対策）・記録
  既知のエラーについて、実質的な解決策を施し、再発防止につなげます。
　必要に応じて専門家チームを結成し、エラーに対する恒久的な解決策を行います。

　根本的な解決に対して、IT構成に何らかの変更が必要だと判断された場合は変更要求書(RFC:Request For Change)を作成します。

　解決策は、問題レコードに詳細に記録します。
　この情報は、将来のインシデントに対するワークアラウンドや、インシデントを回避 するための情報として有意義なものになるかもしれない。
　RFCが作成されている場合、このRFCを次のステップである「変更管理」プロセスに渡します。

(4) クローズ
　変更実装が終ったり、既知のエラーが完全に取り除かれたことを確認したら、問題レコードをクローズする
　（この時点で問題はすでに既知のエラーになっているため、エラーレコードという場合もある）


最後に、問題管理についてテストです。
以下のURLの問題で、問題管理について理解できたか確認してください。
http://www.ap-siken.com/kakomon/22_haru/q54.html

だんだんSilverlightの終焉がみえてきました?

１１月１１日で、Silverlightの古いバージョンはブロックするようです。

＜現象＞

11月の Windows Update で、IEを更新すると、古いSilverlight（ActiveX）をIEが遮断するようになります。

遮断対象のSilverlightのバージョンは、5.1.30514.0未満となります。

（チャート右クリックでSilverlight選択すると、ダイアログにて、バージョン情報が確認できます）

＜対応策＞

Silverlightのバージョンを最新に更新してください。

　⇒5.1.30514.0未満のバージョンを読み込もうとすると、アップデートを促す通知が表示される。

　　この通知にて、Updateをすると問題ないようです

 

私のPCのSilverlightは新しいので、

http://blogs.technet.com/b/jpsecurity/archive/2014/10/16/out-of-date-activex-block-2.aspx

ここで書いてあるテストを試してみました。

結果は、特に問題はありません（ブロックしなかった）でした。

①IEを最新
http://windows.microsoft.com/ja-JP/windows-vista/Update-Internet-Explorer/?cm_sp=Sup-_-vb_syscheck-_-versionup_IE
・[スタート] ボタン をクリックし、[すべてのプログラム]、[Windows Update] の順にクリックします。 
・左のウィンドウで、[更新の確認] をクリックします。
・更新プログラムが見つかった場合は、[適用可能な更新プログラムの表示] をクリックします。
・必要な Internet Explorer の更新プログラムが選択されていることを確認し、[インストール] をクリックします。

②  コマンド プロンプトでVersionlist.xmlを更新しないようにする
・プログラムとファイルの検索で「cmd」入力
・以下のコマンドを実行し、Versionlist.xml を更新しないように構成します。
reg add "HKCU\Software\Microsoft\Internet Explorer\VersionManager" /v DownloadVersionList /t REG_DWORD /d 0 /f

③ テスト用の Versionlist (versionlist-TEST.xml) をこちらからダウンロードします。

④ダウンロードしたテスト用の Versionlist (versionlist-TEST.xmlをversionlist.xmlにリネームして上書き) を、端末の以下の箇所にコピーします。
 %LOCALAPPDATA%\Microsoft\Internet Explorer\VersionManager\    

※私の場合 %LOCALAPPDATA%=C:\Users\t.asano\AppData\Localとなります。
　コマンドプロンプトで%LOCALAPPDATA%を入力すれば、場所はわかります

⑤Internet Explorer を再起動します。

⑥検証を行う対象の ActiveX コントロールを配置しているウェブ サイトを閲覧し、通知が行われないか確認します。

注意: テストが終了したら、該当のレジストリ キーを削除してください。
もし削除しない場合は、VersionList.xml の更新を行わないため、ブロック対象となる古い ActiveX コントロールのリストが更新されません。運用環境ではなく、検証環境でのテストをお勧めしています。

http://blogs.technet.com/b/jpsecurity/archive/2014/09/02/ie-outdated-activex-control-block.aspx
キー: HKCU\Software\Microsoft\Internet Explorer\VersionManager\DownloadVersionList
を選択して削除する

品質向上に役立つテスト手法

テストに関して、再度おさらいです。
まず、要件定義をしっかりしないと、テストもなにもないです。
うちのシステムは要件定義がないから、いつももめるんだよなあ。。。。

まずは、テストの定義から、
日本におけるソフトウェアテスト技術者資格認定を運営する「JSTQB（Japan Software Testing Qualifications Board）」の標準用語集では、「テスト（testing）」は次のように定義されている。
成果物が定義した要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェア製品や関連成果物に対し、計画、準備、評価をすること。全てのライフサイクルを通じて実施する静的、動的なプロセス。

品質向上に役立つと思われるテスト手法について考えてみる。
(1) 負荷テストで失敗しないように考慮すること
・明確な目的の設定
・ 対象システムの特徴の把握
・負荷量・アクセス推移の分析 
・テストシナリオや判断基準 
・スケジュール 
・テストチームの体制
・テスト計画における目標値に対する見通しやデータ収集 
・負荷量の分析 
・チューニングの方法・手段
などを考え、事前に議論や文書化する。

（２）システム品質のボトルネックについて
「ソフトウェア開発プロジェクトで見つかるすべての欠陥のうちの56％は、その根本要因が要件定義フェーズで発生している」（James Martin『An Information Systems Manifesto』より）

ソフトウェア開発では、要件の変更が頻繁に起こるが、要件変更がすべて適切に管理するのは難しい。
要件とテストケースの間のトレーサビリティが維持されていないと、変更した要件に対する適切なテストが実施できず、システム品質が低下する要因にもなります。

「要件定義とその管理こそがソフトウェア品質を左右する重要な工程である」とし、“要件に基づくテスト（RBT：Request Based Testing）”というアプローチがあります。
　RBTでは、以下の3点を重点的に取り組むという。

1. ソフトウェア要件との強固な連携
2. ソフトウェア開発ライフサイクルの全工程を通じて、さまざまな作業を統合する
3. 体系化された費用対効果の高い要件とテストカバレッジの実現

これにより、要件の仕様化における失敗を防ぎ、システム品質のボトルネックを排除する。


Microsoftにもテストに関して説明されているので一読をおすすめします。
http://msdn.microsoft.com/ja-jp/library/aa292191%28v=vs.71%29.aspx