タグ

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

タグの絞り込みを解除

programmingとcommunicationに関するdeep_oneのブックマーク (6)

  • 第8回 [データモデル編]全体を俯瞰してレビューの構成を考える

    前回までは,システム振舞いと画面設計に関する工程成果物の書き方のコツとレビューのコツを紹介してきました。今回からは,[データモデル編]と題して,データモデルのレビューのコツを紹介していきます。 始めに,データモデルを表現するための工程成果物を説明しておきましょう。データモデルに必要な成果物は,各社でさまざまな定義をしていますが,「発注者ビュー検討会」では,次の4種類を,データモデルに関する工程成果物として定義しました。 ■ER図 情報のまとまりを「エンティティ(Entity)」,情報の相互関係を「リレーションシップ(Relationship)」で表したものです。

    第8回 [データモデル編]全体を俯瞰してレビューの構成を考える
    deep_one
    deep_one 2008/09/18
    むしろ「真っ白」なデータモデルを持ってこられて、クレームを付けたことならある(笑)
  • 第25回 ユーザは使いよう | WIRED VISION

    第25回 ユーザは使いよう 2008年7月22日 ITデザイン コメント: トラックバック (0) (これまでの増井俊之の「界面潮流」はこちら) 近年のユーザインタフェース開発では「ユーザ中心設計」(User-centered Design)を行なうことが常識になっています。システム設計者の思い込みにもとづいて作られたシステムがユーザにとって使いやすいものになる可能性は低いですが、設計の初期段階からユーザの欲求についてよく検討し、設計の途中段階においても実際にそれが使いやすいかどうかテストを行ないつつ開発を行えば、当にユーザにとって使いやすいシステムを開発することが可能になります。 ユーザビリティの専門家のJakob Nielsenは以下のような5個の要素を使いやすさの目標としてあげています。 1. 学習しやすさ (Learnability) 2. 効率 (Efficiency) 3.

    deep_one
    deep_one 2008/07/24
    ユーザーに一番聞きたいのは「どのように」するかではなく「なにを」するかだ。おうおうにして、それすらちゃんとまとまらない。
  • 【チーム編成編】できる人間を担当者にしてはいけない:ITpro

    組織を編成する場合に,個人の資質によって役割を与えることは非常に大切である。同じ人間であっても,使い方によっては実力の10%も発揮できずに終わることも多々あるからである。例えば次のような非常に優秀なプログラマが居たとする。 (1)仕事が速い (2)バグの少ないプログラムを書く (3)コーディング規約に沿って書く (4)仕様書を具現化する際に業務を見渡したアルゴリズムを構築できる チームにこのような優秀なプログラマがいると,どうしても担当者としてプログラムを書かせたくなるのは心情というものだ。しかし,プロジェクト・マネージャ(PM)は,このような優秀なプログラマを,他のプログラマと同様に担当者として扱ってはいけない。できる人間は,チームのリーダー格として抜擢すべきである。 できる人間の使い方をミスしたEさん 筆者の知り合いであるEさんは,Javaによる販売管理システム開発のPMに任命された。

    【チーム編成編】できる人間を担当者にしてはいけない:ITpro
    deep_one
    deep_one 2008/07/16
    しかし、出来るプログラマーが出来るリーダーかというと、違ったりする。
  • 現場に蔓延する“ひどいRFP”

    ITproの読者で「RFP(提案依頼書)」という言葉を知らない人は少ないだろう。それだけ,RFPが市民権を得た結果と言える。しかし,RFPの活用が広がる一方で,悲鳴を上げているベンダー担当者も増えているように感じてならない。悲鳴を上げているのは,コンペによって競争にさらされているからではない。“ひどいRFP”によって不当な提案を強いられたり,迷走プロジェクトに巻き込まれたりしているケースが目立つからである。 現場ではいったい何が起きているのか。記者は5月某日,RFPの読み手であるベンダー担当者3人を招いて,覆面座談会を開いた。テーマは「現場に蔓延する“ひどいRFP”」。すると,実際に出くわした“ひどいRFP”が,次から次へと挙がった。以下では,その典型パターンをいくつか紹介しよう。 ケース(1) 担当者の思いだけで記述 一つめは,担当者の“思い”だけがRFPに書かれていたケースである。大手

    現場に蔓延する“ひどいRFP”
    deep_one
    deep_one 2008/06/27
    よくある。ありすぎて困る。/さらに営業とかが「改善する気ゼロ」でさらに困る。
  • だれも教えてくれなかった外部設計の「極意」---目次

    外部設計書で最も大切なことは,「システム開発を依頼してきたお客様」(発注者)に読んでもらい,理解してもらうことです。外部設計書を,開発メンバーではなく,発注者に理解してもらうためには,「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。連載では,発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 [システム振舞い編]一覧表に一工夫入れることで漏れや重複をなくす 第3回 [システム振舞い編]全体を俯瞰でき,システム化範囲が一目で分かる業務フローを作成する 第4回 [システム振舞い編]発注者が理解しやすいシナリオの記述方法 第5回 [画面編]見れば“わかる”「画面レイアウト」の作り方 第6回 [画面編]画面遷移を

    だれも教えてくれなかった外部設計の「極意」---目次
  • 米グーグル、携帯向けプラットフォーム「Android」を発表

    グーグルは現地時間の2007年11月5日、携帯電話向けのプラットフォーム「Android」を、米モトローラや米クアルコム、台湾HTCなど33社と共同で開発に当たると発表した。Androidは、低コストで携帯電話や携帯電話向けサービスを開発するためのOS、ミドルウエア、ユーザーになじみやすいインタフェース、アプリケーションを搭載するソフトウエアである。同時に、米グーグルを含む34社は、Androidを開発する団体「Open Handset Alliance」を設立した。 Open Handset Allianceによると、Android向けのソフトウエア開発キット(SDK)は今月12日に公開される。また、Androidを搭載する携帯電話は、2008年下期に提供される予定だという。 米グーグルの発表資料Open Handset Alliance

    米グーグル、携帯向けプラットフォーム「Android」を発表
    deep_one
    deep_one 2007/11/06
    発売される頃には動かせる素人製ソフトがたくさん出ていそうだ。とうぜん、セキュリティーが怖いが。
  • 1