タグ

システム開発に関するhoshinekodouのブックマーク (4)

  • 経営に役立つ情報システム---目次

    利用部門と情報システム部門の間で意思疎通が不備なために,出来上がったシステムがうまく使われなかったり,意図したものと異なってしまったことがこれまで数多く報告されている。連載は,「経営に役立つ情報システム化」を実現するために,経営者・システム部門・利用部門がそれぞれ何を考えるべきか,3者の役割にスポットを当てる。システム化の各段階において,3者の視点を変えることで見えてくるものについて考えていきたい。 第1回 システム企画には偏りのない視点が肝要 第2回 現場の視点では,経営トップは納得しない 第3回 システム化の体制作りはバランスが肝心 第4回 業務改善の手段として情報システムを利用 第5回 システム開発には広い視点で取り組め 第6回 システム開発の進め方と,成功のポイント 第7回 コミュニケーションの定期的な継続が重要 第8回 テスト・検証はシステム開発の最後の山場 第9回 移行・導入

    経営に役立つ情報システム---目次
  • Webアプリにおける11の脆弱性の常識と対策

    Webアプリにおける11の脆弱性の常識と対策:Webアプリの常識をJSPとStrutsで身につける(11)(1/4 ページ) 連載は、JSP/サーブレット+StrutsのWebアプリケーション開発を通じて、Java言語以外(PHPASP.NETRuby on Railsなど)の開発にも通用するWebアプリケーション全般の広い知識・常識を身に付けるための連載です 【2013年2月25日】編集部より、おわびと訂正のお知らせ 稿において読者の皆さまより多数のご指摘をいただきまして、誠にありがとうございます。編集部であらためて調べた結果、間違いを把握し、あらためて修正版を掲載させていただきます。この度は、長期にわたり誤った内容を掲載したので、読者の皆さまに多大なご迷惑をお掛けしたした点をおわび申し上げます。 通常、記事に間違いがあった場合には、筆者確認後に修正版を掲載するのですが、今回の場

    Webアプリにおける11の脆弱性の常識と対策
  • 開発工程でSEが書く文書の基本 − @IT自分戦略研究所

    「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回

    開発工程でSEが書く文書の基本 − @IT自分戦略研究所
  • 要求開発アライアンスのビジネス・モデリング道場

    要求開発とコタツモデル(2)−−アンチパターンを活用する [2008年06月17日] 前回は,要求開発・要件定義フェーズを成功させるためのポイント「コタツモデル」についての説明を行いました。今回は,具体的な「コタツモデル」形成のテクニックの一部についてご紹介したいと思います。 要求開発とコタツモデル(1)−−失敗パターンに陥らないために [2008年05月29日] 今回は,要求開発アライアンスの会員にしか知られていない,プロジェクト成功のための秘訣をご紹介します。この秘訣は要求開発アライアンスの中では「コタツモデル」と呼ばれています。 目標追跡型グローバルソフトウエア生産システムを考える(2) [2008年02月28日] 前回は,機能要件を対象とした国内開発をまず先に実施し,その後オフショア拠点を利用して非機能要件を満たすフトウエアを完成させるという基的な考え方について説明した。前

  • 1