関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

設計に関するpowerbombkunのブックマーク (17)

  • SEが苦手にしがちなドキュメント力を強化する5つの視点

    SEに最も必要なスキルは「伝える力」だと言われています。分業が前提となるシステム開発において、意志の伝達がうまく出来ないことは致命的だからです。 よって、作成するドキュメントにも正しく伝える技術が求められるのですが、しかし多くのSEはドキュメント作成を苦手としているようです。 そこで今日は、SEがドキュメント作成で失敗しがちなポイントと、ドキュメント力を強化するための5つの視点について、『エンジニアのための文章術再入門講座』からご紹介します。 1.SEがドキュメント作成で失敗しがちなポイント SEがドキュメント作成に失敗しがちなポイントは、主に以下の2つです。 相手の関心と不一致 知識差のための説明が不足 例えば、システム開発プロジェクトの部長向けの進捗報告の場面を思い浮かべてください。性格にもよりますが、一般に部長クラスの方が気にするのは「予算を超過しないか」「顧客との関係は良好か」「今

  • これから設計を学ぶ君に贈る一冊 #君に贈る102冊目の名著 - Create a new world

    こちらの翔泳社さんの 100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊 作者: デブサミ運営事務局,SEshop.com編集部出版社/メーカー: 翔泳社発売日: 2012/02/22メディア: 単行(ソフトカバー)購入: 18人 クリック: 537回この商品を含むブログ (38件) を見るを読んでて、自分もちょっと書評を書きたいなぁと思ったので書いてみます。 今回の書評はこちら。 ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series) 作者: ダグローゼンバーグ,ケンドールスコット,Doug Rosenberg,Kendall Scott,長瀬嘉秀,今野睦,テクノロジックアート出版社/メーカー: ピアソンエデュケーション発売日: 2001/11メディア: 単行購入: 1人 クリック: 38回この商品を含むブログ

    これから設計を学ぶ君に贈る一冊 #君に贈る102冊目の名著 - Create a new world
  • ブログ記事「ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か」の質疑応答

    Social Changeの記事「ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か」 http://kuranuki.sonicgarden.jp/2012/01/post-62.html の質疑応答をまとめました。

    ブログ記事「ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か」の質疑応答
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略

    開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略:きのこる先生のエンジニア転職指南(6)(1/2 ページ) 元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。 師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。 繰り返す、ここはSIerではない さて今回は、かつて私が所属していた「システム・インテグレータ(SIer)」、そしていま所属している「Web系企業」についてお話します。 SIerは、長引く不況とIT業界の構造変

    開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略
  • 開発者が知っておくべき、6つのUIアーキテクチャ・パターン - @IT

    .NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET/.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「

  • プログラマーが意識するべきUI設計指針 3つのMVCモデル - GeekなNooblog

    数ヶ月前の記事に引き続きMVCモデルについてのまとめです。 MVCモデルについて - GeekなNooblog プログラマーが意識するべきUI設計指針 3つのMVCモデル - GeekなNooblog MVCモデルの問題点を解決するPMモデルとMVPモデル - GeekなNooblog MVCにおけるViewの表示方法 トランザクションスクリプト、ドメインモデル - GeekなNooblog MVCモデルというものはすごくやっかいで、人によって言っていることが違います。 なのでこれが必ず正解!というものはないと思いますが、個人的に勉強した中でこれが正解であって欲しいなっていうものをまとめてみたいと思います。 今回も実際のコードを例に挙げていきますが、GUIではなくCUIで簡易的な実装で紹介していきたいと思います。 コードの例題としては、ネットショップの商品の商品名、金額、在庫数が表示するペ

    プログラマーが意識するべきUI設計指針 3つのMVCモデル - GeekなNooblog
  • 一生使える「SEの共通言語」

    記事を書く以上、多くの方に読んでほしいので題名には工夫を凝らす。とはいえ「一生使える共通言語とは大げさすぎる」と思われた読者がいるかもしれない。題に入る前に題名に込めた意味を書いておく。 「一生使える」とは「長持ちする」を強調した表現である。長持ちするからSEを一生続けるのであればその言語は一生使える。 「SE」の定義は色々あろうが、ここでは「顧客の要望をくみ取って情報システムを設計し開発できる人」とする。 「共通言語」は、SE同士はもちろん顧客とSEの間でも通用する。ローカルではなく世界各国で使われている。 以上の意味を頭に入れて「一生使えるSEの共通言語」とは何かを考えていただきたい。 長持ちしSEと顧客が使えるもの 稿で用意した答えは「データモデル」である。データモデルは記述された成果物だからデータモデリング手法や表記方法が言語かもしれない。 実は質問の前にデータモデルあるいはデ

    一生使える「SEの共通言語」
  • Ruby で「Lisp脳」に迫る。 - YNote

    はじめに 再利用性の高いプログラムを書くにはどうしたらよいのだろう、と、いつも思う。 学生のころ、BASIC と C と Verilog を勉強して、社会人になってから Ruby をちゃんと勉強した。正確には学生のころも Ruby さわったことがあったんだけど、「正規表現が使えてセミコロンがいらない C 」くらいにしか思ってなくて、それよりも踏み込んで便利さを知ったのは、けっこう最近。 再利用性が高いプログラムを書くのに、Ruby はやっぱり便利だ。 Ruby が便利な理由としては「メタプログラミングが得意」とか「オブジェクト指向だから」、とか、いろいろ言われるけれども、個人的には「『DoA(Data Oriented Approach)』を気軽に実践できる」というのが大きいと思う。 DoA というのは「データ中心アプローチ」とも言われていて、データ構造の変遷を中心にプログラムを設計してい

    Ruby で「Lisp脳」に迫る。 - YNote
  • バグゼロのための設計原理

    バグゼロのための設計原理 昨今、いかにソフトウェアの不具合を減らすべきかという議論がいろいろとなされています。現状として、量産直前での総ざらい、過去トラチェックで不具合を発見しても、待ち構えているのはあまりにも大きな手戻りと、穴を空けてしまう日程への困難な交渉業務です。 そこで、よく言われるようになってきたのが、“日々の品質の作り込み”=“先手管理”が大切だということですが、スローガンとして理解できても、さて担当として何を実践すればよいのか迷うところです。もう少し、具体的にブレークダウンした方法論は、何かないのかと調べてみました。 その結果、以下の表に示す七つの実践原理をソフトウェア工学の論文より見つけてきました。[君島 浩氏(富士通)論文より部分引用] 少しでも皆様のお役に立てるようここに公開します。

  • アーキテクトを考える | システム設計日記

    Bruce A. Tate 著、まつもとゆきひろさん監訳、田和勝さん訳の 「7つの言語 7つの世界」 を楽しみながら読んでいる。 最初のページの「読者の声」の、 「複数のパラダイムを理解すると、設計能力が大幅に強化される」by Dr. Venkat Subramaniam に、はっとさせられた。 読み進めるうちに、この言葉の意味が、実感できてきた。 「異なるパラダイムを、実感してみる」と「設計の発想やセンスが変化する」手ごたえがあった。 9章「まとめ」に、プログラミングパラダイムを4つに分類した要約がある。 ●オブジェクト指向 --> Ruby, Scala ●プロトタイプ型 --> Io ●制約論理型 --> Prolog ●関数型 --> Scala, Erlang, Clojure, Haskell ※「手続き型」がないのは、このでは C, FORTRAN, COBOL, BASI

  • 第9回 原発事故から学ぶ「システム設計」の重要性 | gihyo.jp

    エンジニアの役割 福島第一原発での事故は、私たちにいろいろなことを教えてくれた。畑違いとはいえ、エンジニアの一人として最初に感じたのは、「⁠エンジニアたちはいったい何をしていたんだ?」「⁠システムアーキテクトはいたのか?」という疑問である。 核エネルギーを発見したのは科学者たちである。そして、そのエネルギーは原子爆弾だけでなく、発電にも使えるかもしれないと考えたのも科学者たちである。科学者たちの仕事は、自然を観察し、法則を見つけ出し、そこから私たちの生活や経済活動に役に立つ可能性のあるものを見つけることである。その意味では、「⁠原子力の平和利用」という発想はすばらしいものであった。 一方、原発を日のエネルギー政策の中心に置いたのは政治家である。その政策に従い、日各地に原発を作り、そこで作った電力を販売しようと決めたのは電力会社のビジネスマンたちである。彼らの仕事は、国なり会社なりの枠組

    第9回 原発事故から学ぶ「システム設計」の重要性 | gihyo.jp
  • ドメイン駆動設計の概要

    目次 プラトン的モデル 言うべきことを言う コンテキスト 価値提案を把握する 単一責任システム エンティティは ID とライフサイクルを持つ 値オブジェクトは記述する 集計ルートによりエンティティを結合する ドメイン サービス モデルの主要な操作 リポジトリにより集計ルートを省略する データベースの関連事項 DDD の使用を開始する ドメイン駆動設計 (DDD) とは、洗練されたオブジェクト システムの設計に役立つ原則とパターンをまとめたものです。設計に DDD を適切に適用することで、ドメイン モデルと呼ばれるソフトウェア抽象化を実現できます。このモデルにより複雑なビジネス ロジックをカプセル化できるため、実際の業務とコードとの間に存在するギャップを小さくすることができます。 この記事では、DDD に関連する基的な概念と設計パターンについて解説します。機能豊富なドメイン モデルを設計し

    ドメイン駆動設計の概要
  • 実行可能な仕様書は“設計できるプログラマ”が書く

    実行可能な仕様書は“設計できるプログラマ”が書く:“実行可能な仕様書”を作る!(2)(1/3 ページ) 前回、「実行可能な仕様書」を実現するための鍵が「機能パターンの確立」だと述べた。それらのパターンを有効活用するためには、DBを正規化するとともに、ビジネスロジックを機能側からDB側に移行しなければいけない。そして、ビジネスロジックを的確に仕様化するためには設計スキルとともにプログラミングスキルが必要になる。 DBを正規化することのインパクト 前回、業務システムに含まれる機能(データ処理プログラム)をいくつかの「機能パターン」に整理することで「実行可能な仕様書」が実現可能になると説明した。機能パターンごとに仕様情報のデータ様式を定め、これを処理する「仕様翻訳エンジン」と「仕様エディタ」を用意すれば、「実行可能な仕様書」のための基盤が完成する。この基盤を便宜上「アプリケーションドライバ(アプ

    実行可能な仕様書は“設計できるプログラマ”が書く
  • 書評「UIデザインの基礎知識」 - elm200 の日記(旧はてなダイアリー)

    私はずっとプログラマとして活動してきたが、ウェブデザインをはじめとする見かけのデザインは苦手だった。ずっと避けて通っていたのだが、いまの時代、ウェブサイトのプロトタイプくらい自分で作れるようになりたいと思った。デザイナーの知人に相談したところ、紹介してくれたのがこの。 ユーザーインタフェースデザインの基礎知識 ~プログラム設計からアプリケーションデザインまで~ 作者: 古賀直樹出版社/メーカー: 技術評論社発売日: 2010/04/23メディア: 単行(ソフトカバー)購入: 11人 クリック: 170回この商品を含むブログ (15件) を見る 豊富な例を引用しながら、ユーザーインターフェイスをデザインする上で陥りがちな典型期な過ちを解説していく。数学科出身の著者というだけあって、解説は理論的で、感覚より論理を重視するプログラマにも分かりやすい。 理想的なコンピュータシステムは、ユーザー

    書評「UIデザインの基礎知識」 - elm200 の日記(旧はてなダイアリー)
  • データ中心指向とオブジェクト指向

    オブジェクト指向プログラミングと対比されるものとして、手続き型のほかに、データ中心指向があります。データ中心指向は、大量のデータを扱う業務アプリケーションで適用される方法論で、機能や処理を中心に考えるのではなく、データを中心に考えていくアプローチです。機能や処理に比べてデータは不変であるため、データが重要な意味を持ってくる業務アプリケーションでは、この考え方が適しています。 オブジェクト指向との違いは何かというと、簡単に言えば、オブジェクトを中心に考えるか、データベースを中心に考えるかの違いです。 ドメインを中心に考えている点では、どちらも一緒です。ドメインとは、アプリケーションが解決しようとしている問題領域のことです。ドメインを明確にする際、モデルが作成されます。モデルは、その問題領域で扱うデータを構造化し、関連を明確にし、アプリケーションの質的な部分、骨子を明確にしていくものです。そ

  • 正しい設計と理想的なモデル

    現在では、開発現場で「UML」という言葉が一般化し、「オブジェクト指向」という言葉もごく当たり前のように使われるようになりました。実際にプロジェクトの中で、UMLを用いて分析/設計を行い、開発を進めている開発者や、これから始めようとしている開発者もかなりの数に上ると思います。 しかし、「UMLの表記方法や、ビジネスモデルをオブジェクト指向で分析する方法は、ある程度理解できるのだが、実際に出来上がった分析モデルをどのように設計モデルにしていくか?」または「設計モデルは作成したが、出来上がった設計モデルは、実際にどれほど有効なのか?」という疑問を持っている方も多いと思います。連載では「良い設計モデルとは何を意味するのか?」「どうすれば良い設計モデルを作ることができるのか?」というテーマについて、前後編の2回で皆さんと一緒に考えていきます。 前半は分析/設計モデルに関する概念的な解説を行い、後

    正しい設計と理想的なモデル
  • 1