タグ

上流工程に関するMikatsukiのブックマーク (4)

  • 改めて考えるITエンジニアとITアーキテクトの違い

    ITエンジニアのキャリアの一つに「ITアーキテクト」があるが、今ひとつ実像をつかみにくい職種である。そこでこの週末スペシャルでは、筆者がこれまでに関わったITアーキテクトの記事をまとめ、少しでもその実像と魅力をお伝えしたい。 筆者なりのITアーキテクトの定義はこうだった。「システムのアーキテクチャーに責任を持つエンジニア」。しかし、この定義ではイメージがクリアになるどころか、新たな疑問を持つ人のほうが多いだろう。 その疑問とは「アーキテクチャーとは何か?」である。アーキテクチャーがモヤモヤしている以上、ITアーキテクトもモヤモヤしてしまう。そう思っていたときに書いたのが次の2の記事だ。「エンジニアの発想」「要件の設計の間にあるもの」といったアプローチでアーキテクチャーの実体に迫ろうとしている。 アーキテクチャーとは「エンジニアの発想」のこと 要件と設計の間にあるもの アーキテクチャーにつ

    改めて考えるITエンジニアとITアーキテクトの違い
  • 超上流から攻めるIT化の事例集:INDEX:IPA 独立行政法人 情報処理推進機構

    SEC BOOKS「経営者が参画する要求品質の確保」では、情報化の現場で起こっている問題を取り上げ、それらの解決のヒントとして超上流工程における経営層のシステム開発への参画による要求品質の確保の重要性を説明しました。 ここでは、情報化に関わるユーザ企業・ベンダ企業が、心掛けるべき原理原則や取り組む上での行動規範を示しています。 また、心構えだけでは、「実際には何を行ない、どんなものを作ればよいのか」という問いに、実際の開発現場で行なっている情報化の進め方や、実際に使用している成果物を提供することにしました。 ユーザ企業とベンダ企業の間での情報化での作業や役割分担、成果物について、具体的なイメージをつかめればと思います。 ご利用条件について 当コーナーで紹介しているファイルをダウンロードすると下記の利用条件に同意したものとみなします。 利用条件は、IPAの「ご利用条件」に追加するものです。

    超上流から攻めるIT化の事例集:INDEX:IPA 独立行政法人 情報処理推進機構
  • モデリング:XEAD

    現在進行中のプロジェクトで、設計の品質や生産性を高めたい... 業務知識や上流工程のスキルを身につけてキャリアアップしたい... ――そのためのお役立ち情報を揃えています。実務家から高い評価を得ている設計手法、専用の支援ツール、洗練されたモデルライブラリー。これらを駆使して、効率的にシステム設計のレベルアップをはかりましょう。 ニュース 「CONCEPWARE/自治体」の開発が始まりました(080420) 「CONCEPWARE/販売管理」をバージョンアップしました(080404) 「CONCEPWARE/生産管理」をバージョンアップしました(080404) XEADで入出力パネルの画像ファイルを扱えるようになりました(071004) 管理人のブログ「設計者の発言」

    Mikatsuki
    Mikatsuki 2015/05/06
    これは?フリーなのかな?
  • [IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG

    「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要

    [IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
  • 1