2010年1月21日のブックマーク (9件)

  • 電子署名の仕組み 財団法人 日本情報処理開発協会 電子署名・認証センター

    すなわち、電子署名とは、作成者や改ざんの有無が明確になりにくい電子文書の欠点を補い、誰が作成したものか、また、改ざんが行われていないかどうかを確認できるようにするためのものだといえます。 したがって、受領した電子文書に電子署名が行われていれば、その電子文書の作成者を特定することが可能です。また、電子署名が行われていれば、電子署名が行われて以降、作成者も含めた何者も電子文書の改ざんを行っていないことを証明することができます。 電子署名の仕組みを技術的に支えているのが「暗号化」の技術です。 以前は、通信する双方が暗号化及び複合を同一の鍵(共通鍵)を用いて行う「共通鍵暗号方式」が使われていました。しかし、この方式では通信をする相手ごとに異なる「共通鍵」を用意しなければならず、かつ、暗号化に際して使用した鍵を、他人に知られないように必要な相手に渡すのは非常に難しいという欠点がありました。

    nekokihon
    nekokihon 2010/01/21
    デジタル署名の仕組み
  • 暗号入門:ハイブリッド暗号|SBINS

    皆様に多くのお問い合わせをいただいている暗号技術について、暗号入門と題して数回に分けて解説します。 第5回目の今回は、ハイブリッド暗号について、もう少し詳しく説明します。 ※掲載されている情報は掲載日時点での情報です。 公開鍵暗号方式は、相手へ容易に鍵を渡すことができる安全で強力な暗号ですが、処理速度が遅いため、大量のデータ処理や速度を要求される処理には向きません。 一方、共通鍵暗号方式は、速度も比較的速く扱いやすい暗号ですが、どうやって鍵を受け渡すかという大きな問題があります。 この2つの欠点を補い合う形で組み合わせて使われることが良くあります。 下の図のように、共通鍵暗号方式を使って平文を暗号化し、その暗号化に使用した「共通鍵自体」を公開鍵暗号方式を使用して暗号化し、相手に送るという方法です。このような方法のことを、ハイブリッド暗号、ハイブリッド方式などと呼んでいます

    nekokihon
    nekokihon 2010/01/21
    共通鍵・公開鍵方式が分かってないと厳しいです
  • 5分で絶対に分かるUML ― @IT情報マネジメント

    UMLとはいったい何だ? 近ごろUML(Unified Modeling Language)が注目を集めています。多くの雑誌にUMLの特集が組まれ、@ITにもUMLに関する記事がたくさん掲載されています。また、最近ではUMLを知っていることを前提とした文章も珍しくありません。 実際、システム開発の現場でUMLが積極的に使われ始めています。UMLに対応したツールも多く登場し始め、UMLが説明の必要もないほど必須の技術になっているといえます。 稿ではそんなUMLとは一体どんなものなのか、どのように使われているのかについて、オブジェクト指向の話と併せて取り上げていこうと思います。この5分がUMLに興味を持つきっかけとなれば幸いです。

    5分で絶対に分かるUML ― @IT情報マネジメント
    nekokihon
    nekokihon 2010/01/21
    オブジェクト指向の感覚を掴もう!
  • 結合テスト

    結合テスト ひとつの製品を見ると,複数の部品の集まりです。 同じく, ひとつのプログラムを見ると,複数のモジュールの集まりです。 複数のモジュール間の関係(=インタフェース)をテストするのが,結合テストで す。 そこで,まずモジュール間に上下関係があります。人の世界に上下関係があるのと 同じです。 (過去問題から憶える) ボトムアップテスト 下位のモジュールから上位のモジュールへと,順次結合してテストする。 (H12 春 問62) ボトム→(底)→下位 から アップ→(上がる)→上位 へ (イメージから憶える) (過去問題から憶える) トップダウンテスト 上位のモジュールから下位のモジュールへと,順次結合してテストする。 (H12 春 問62) トップ→頂上→上位 から ダウン→下がる→下位 へ (イメージから憶える) (過去問題から憶える) ボト

    nekokihon
    nekokihon 2010/01/21
    結合テストにおけるスタブ・ドライバなど
  • 第3回 ホワイトボックステスト | gihyo.jp

    はじめに プロジェクトの終盤にさしかかるテスト工程では、期間的にも予算的にも切迫した状態となる場合が多いのではないでしょうか。そういった状況ではとくに、どんなテストで何を確認するか、という「テストケース」は無駄なくそして漏れなく作成したいものです。連載の第3回目となる今回は、テストケース作成技法の1つ、ホワイトボックステストについて取り上げます。 ホワイトボックステストとカバレッジ ホワイトボックステストは、テスト対象の構造に着目してテストケースを作成する技法です。設計や実装の内容から内部構造(処理経路)を網羅するようにテストケースを作成します。そして、作成したテストケースは、どれくらい処理経路を網羅しているかを評価することが重要です。この処理経路の網羅度合についての基準をカバレッジ(網羅率)といい、ホワイトボックステストでは、目標とするカバレッジを満たすように効率よくテストケースを設計し

    第3回 ホワイトボックステスト | gihyo.jp
    nekokihon
    nekokihon 2010/01/21
    ガバレッジ(網羅率)を知ろう!
  • 第4回 ブラックボックステスト | gihyo.jp

    はじめに ソフトウェアテストのテクニックについて紹介する連載ですが、今回もテストケースの作成に使えるテクニックを紹介します。限られた時間、予算の中でテストを行う際には、パターンを漏れなくダブりなく分析し、網羅性を確保しつつ効率よくテストケースを作成できるかがポイントになります。今回は、前回(第3回)のホワイトボックステストに続き、もう1つの代表的なテストケース作成技法「ブラックボックステスト」について紹介します。 ブラックボックステストとは? ブラックボックステストとは、テスト対象の「仕様」に基づいたテストケースの作成技法です。 前回紹介した「ホワイトボックステスト」が、テスト対象の内部の「構造⁠」⁠、たとえばソースコードのロジックに着目してテストケースを作成するのに対し、ブラックボックステストでは、テスト対象を「中の見えない箱(ブラックボックス)」としてとらえてテストケースを作成します

    第4回 ブラックボックステスト | gihyo.jp
    nekokihon
    nekokihon 2010/01/21
    同値分割やら境界地分析など
  • [Think IT] 第3回:ウォーターフォールにおけるドキュメント作成ポイント (1/3)

    【楽々デブドックを書こう!】手法別開発ドキュメントの書き方 第3回:ウォーターフォールにおけるドキュメント作成ポイント 著者:ウルシステムズ 小堀 真義 公開日:2008/02/21(木) 基設計書は詳細設計とテストのインプットとなる 「第2回:開発モデルに共通するドキュメントをまとめる視点」では、開発モデルに関係なく、開発ドキュメントをまとめる上で大切となる視点について解説しました。第3回、第4回では、具体的な開発モデルを取り上げ、ドキュメント作成における重要なポイントを押さえていきます。今回取り上げるのはウォーターフォールモデルです。 ウォーターフォールモデルの特徴は、各工程を順番に1回だけ行い、原則として後戻りが許されない点です。各工程は、前工程の成果物をインプットとして、次工程のインプットとなるアウトプット(成果物)を作成するために作業を行います(今回は、図1のV字モデルと工程名

    nekokihon
    nekokihon 2010/01/21
    ウォーターフォールモデルを簡単に分かりやすくまとめてあります。
  • 上流工程-要件定義---目次:ITpro

    NVIDIAの時価総額が526兆円で世界首位に、生成AIが促す11年ぶりの地殻変動 2024.06.19

    上流工程-要件定義---目次:ITpro
    nekokihon
    nekokihon 2010/01/21
    DFDなど上流工程の説明
  • Í×·ïÄêµÁ¡¦´ðËÜÀß·× - µ»½Ñ¾ðÊóWiki

    ´ðËÜÀß·× † ¥·¥¹¥Æ¥à¤Î¥ê¥×¥ì¡¼¥¹°Æ·ï¤¬ºÇ¤â´í¸±¤ÊÍýͳ 2008.2.24 ±¿ÍѤ·¤Æ¤¤¤¯¤¦¤Á¤Ë¡¢¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤äµ¡Ç½Äɲäǡ¢¶²Îµ¤Î¤è¤¦¤ËÇϼ¯¤Ç¤«¤¯¤Ê¤Ã¤¿Ãæ¿È¤Ï¡¢ºÇ¿·¤Î¥ª¥Ö¥¸¥§¥¯¥È»Ø¸þ¸À¸ì¤Ç¡¢Æ±¤¸¤è¤¦¤Ë¤¿¤¯¤µ¤ó¤Î¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤ò½Å¤Í¤ÆÀѤ߾夲¤¿¤â¤Î¤ËÊѤï¤ë¡£ Ʊ¤¸¥½¡¼¥¹¥³¡¼¥É¤ÎÃÇÊҤϰì¤Ä¤â¤Ê¤¤¤Ï¤º¡£ ¥×¥í¥°¥é¥à¤ÎÊݼéÀ­¤ä°Ü¿¢À­¡¢ºÆÍøÍÑÀ­¤¬¡¢¤É¤Î»þÂå¤Ë¤Ê¤Ã¤Æ¤â¡¢¸À¸ì¤¬¤¤¤¯¤éȯŸ¤·¤Æ¤âÆñ¤·¤¤¤³¤È¡£ Æä˺ÆÍøÍÑÀ­¤Ï¡¢¤½¤Î¥

    nekokihon
    nekokihon 2010/01/21
    実務ベースな話