タグ

developとstandardに関するfragarach_the_swordのブックマーク (10)

  • ER図の目的とは? 初心者向けに書き方を教えます

    ER図(Entity Relationship Diagram) ER図とは、データベースのテーブル(Entity)とテーブル同士の関連(Relationship)を図に表したものであり、データベースのテーブル設計に用いられる。ER図において、エンティティは四角形の記号、リレーションは四角形同士を結ぶ線で表現される。 書き方 ER図の書き方は、エンティティとリレーションを記号で表して書く。ER図の書き方には、以下に示す2種類がある。 IDEF1X記法 IE記法 エンティティ 論理モデルのER図の場合、エンティティ(実体)は業務におけるひとまとまりのデータを表している。物理モデルのER図の場合、エンティティはデータベースのテーブルを表す。 エンティティには2種類あり、非依存実体と依存実体に分けられる。 非依存実体 非依存実体とは、他のエンティティに依存せずに存在できるエンティティである。例え

  • 「開発のち運用」から「運用時々開発」へ

    この3月、情報処理推進機構(IPA)から1冊のが発行された。タイトルは「共通フレーム2013」。システムの企画・開発・運用に至る作業内容や成果物、役割分担などを定義したものである。システム開発に携わる方なら、標準的な開発プロセスとしてなじみのあるフレームワークかもしれない。 おおむね5年おきに改訂される共通フレームには、その時代の「情報システムの潮流」が反映されている。前版の共通フレーム2007では、「超上流」がトピックだった。具体的には。システム化構想やシステム化計画の立案といった企画プロセスが拡充された。実際、この前後から、超上流を強化する開発現場が確実に増えた。当時在籍した日経SYSTEMSでも、見積もりや要件定義など超上流の記事をよく取り上げたことを覚えている。 では、今年発行された共通フレーム2013のトピックは何か。それが実は「運用」にほかならない。筆者らは今年4月、「日経B

    「開発のち運用」から「運用時々開発」へ
    fragarach_the_sword
    fragarach_the_sword 2013/07/07
    記者の眼 - 「開発のち運用」から「運用時々開発」へ:ITpro
  • 共通脆弱性タイプ一覧CWE概説 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構

    共通脆弱性タイプ一覧CWE概説 CWE(Common Weakness Enumeration) ~脆弱性の種類を識別するための共通の脆弱性タイプの一覧~ >> ENGLISH 共通脆弱性タイプ一覧CWE(Common Weakness Enumeration)(*1)は、ソフトウェアにおけるセキュリティ上の弱点(脆弱性)の種類を識別するための共通の基準を目指しています。 1999年頃から米国政府の支援を受けた非営利団体のMITRE(*2)が中心となり仕様策定が行われ、2006年3月に最初の原案が公開されました。その後、40を超えるベンダーや研究機関が協力して仕様改善や内容拡充が行われ、2008年9月9日にCWEバージョン1.0が公開されました。 CWEでは、SQLインジェクション、クロスサイト・スクリプティング、バッファオーバーフローなど、多種多様にわたるソフトウェアの脆弱性を識別するた

    共通脆弱性タイプ一覧CWE概説 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
    fragarach_the_sword
    fragarach_the_sword 2011/08/30
    情報処理推進機構:情報セキュリティ:共通脆弱性タイプ一覧CWE概説
  • 「早期に」「誤解なく」「漏らさずに」非機能要求グレードを使いこなす

    性能や信頼性、保守性といった非機能要求は情報システムの高度化・大規模化が進むに伴って、その重要性が改めてクローズアップされている。あいまいにしたままシステム開発を進めるのはあまりにもリスクが大きいからだ。 こうしたなか「システム基盤の発注者要求を見える化する非機能要求グレード検討会」はこの5月に非機能要求グレードを公開した(図1)。検討会はNTT データ、富士通NEC、日立製作所、三菱電機インフォメーションシステムズ、OKIの6社が2008年4月に共同で発足させた。 非機能要求グレードの目的は、「早期に」「誤解なく」「漏らさずに」非機能要求を発注者が受注者と共同で定義して、かつ、合意できるようにすること。これまでの非機能要求定義の難しさを克服するため、非機能要求で決めるべき項目を定め、その具体例を段階的に「見える化」することで、発注者が非機能要求を決めやすくしている。 「機能以外」だから

    「早期に」「誤解なく」「漏らさずに」非機能要求グレードを使いこなす
    fragarach_the_sword
    fragarach_the_sword 2011/06/25
    「早期に」「誤解なく」「漏らさずに」非機能要求グレードを使いこなす - 非機能要求の“見える化”:ITpro
  • 「DMBOK」の中核機能

    データこそが企業の資産であり、資産価値を高める諸活動が不可欠である。データ関連の活動を知識体系としてまとめたDMBOKが登場。そのなかでも「データガバナンス」の確立が急がれる。データ関連のポリシーや手続き、担当者の役割と責任を定義し、データにかかわる活動を統制するものだ。 今、CIO(最高情報責任者)や情報システム部長は担当している情報システムや自身の仕事のグランドデザインを描き直す時期に来ている。その際には、データをマネジメントの対象にしっかり入れるよう見直す必要がある。 データ資産を生み出し、その価値を高めていく活動全体を「データマネジメント」と総称する。まず必要なデータをあらかじめ設計し、マスターデータを整備しておく。MDM(マスターデータマネジメント)は、データマネジメントの重要な一部である。 続いて設計通りのデータを生成し、記録し、格納し、使用し、同時に保護する。並行して、データ

    「DMBOK」の中核機能
    fragarach_the_sword
    fragarach_the_sword 2011/05/24
    「DMBOK」の中核機能 - 今こそ「グランドデザイン」:ITpro
  • 品質とは何か

    品質という言葉の意味 測定との関係と視点 品質の種類 基的な考え方 ソフトウェア品質特性 機能性品質特性の品質副特性 信頼性品質特性の品質副特性 使用性品質特性の品質副特性 効率性品質特性の品質副特性 保守性品質特性の品質副特性 移植性品質特性の品質副特性 利用時の品質とは 俯瞰 まとめ 品質という言葉の意味 「品質」という言葉は、我々の世界ではよく使いますが、 品質とは何でしょう。 品質が良い/悪い、と言ったり、 品質を上げる、と言ったりしますが、 これがどんなものなのか、明確に認識しているでしょうか。 いろいろな人の話を聞いていると、 意外と認識が一致していません。 人によっては、検証の結果を見て言います。 「このモジュールは品質が悪いね」と。 人によっては、プロジェクト開始前に言います。 「前回のような品質問題は起こさないようにしよう」と。 人によっては、常に使います。 「品質を測

  • ソフトウェア品質特性 - Software Quality.com

    ソフトウェアは「目に見えないモノ」ですので、その評価は現時点でも非常に難しい課題の一つです。 見えないからこそ、ソフトウェア品質の評価は重要となります。 その難題に一つの光明を見いだしたのが皆さんもご存じのISO/IEC9126(JIS X 0129) ソフトウェア品質特性(Quality Characteristics) です。 (正式名称は「Information technology software product evaluation:Quality characteristics and guidlines for their use」) この規格は1991年(JISは1994年)に発行され、多くの人が存在(名前だけ?)を知っているのですが、その難解さ故利用されることは少ないようにも思います。 そこで、Software Quality.comではこのソフトウェア品質特性をある程

  • NTTデータ公式サイト

    NTTデータ(国内事業会社) 企業情報 プロフィール 社長メッセージ 役員一覧 NTTデータのテクノロジー NTTデータグループ(持株会社) 企業情報 プロフィール 社長メッセージ Our Way 役員一覧 サステナビリティ 沿革 グループ会社 協賛・文化活動 取引先企業の皆様へ NTT DATA, Inc.(海外事業会社) 企業情報

    NTTデータ公式サイト
    fragarach_the_sword
    fragarach_the_sword 2010/02/27
    非機能要求グレード検討会
  • 富士通のMDA資料

    SDAS(エスダス)(注1)は、開発期間短縮を実現し、お客様のビジネスのスピードアップに貢献する為の総合システム開発体系です。 新しい「SDAS」は、「短期間・高品質」のシステム開発を実現するとともに、「オープン性・国際標準」「ライフサイクル全般でのシステム最適化」「エンジニアリングとマネジメントを両輪とするプロジェクト遂行」を特長としています。 これにより、システム開発期間を従来と比べ、概ね半減することが可能となり、ITの観点から、お客様のマーケットの動きを先取りしたビジネス展開を支援していくことで、競争優位確保に貢献します。 システム開発を「要件定義」「設計」「構築」「テスティング」の4フェーズに分け、それぞれのフェーズを最短化する開発手法、標準技術に基づくツール群およびテンプレートを適用することで、トータルの期間短縮を実現します。 注1 SDAS: System Developmen

  • JISC 日本産業標準調査会

    サイトでは、JISの閲覧は可能ですが、印刷・購入はできません。 JISの購入については JISの入手閲覧方法 をご覧下さい。 ※データベース検索においては、アクセスが集中した際に正しく表示されない場合が ございます。その場合は、暫く経過したのち再度アクセスをお願いいたします。

    fragarach_the_sword
    fragarach_the_sword 2009/01/07
    JISC日本工業標準調査会:JIS規格検索・閲覧可能(IE)
  • 1