“読書”と“資格取得(今は司法書士)”と“音楽鑑賞”のメモ

 

Planned Happenstance 〈偶然〉=〈必然〉

09« 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.»11

検索

カテゴリー

最近の記事

ブロとも申請フォーム

カレンダー(月別)

最近のコメント

最近のトラックバック

RSSフィード

リンク

Copy right

読書〔IT〕の記事一覧

全ての記事を表示する

Posted on --:--:-- «Edit»
--
--/--
--

Category:スポンサー広告

スポンサーサイト 


上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

tb: --     com: --
Posted on 13:16:52 «Edit»

上流工程にこれから携わろうと言う人にも、
すでに要求定義に関わっている人にも、
作業や考え方を整理するうえでいい本。

図解入門 よくわかる最新システム開発者のための要求定義の基本と仕組み
図解入門 よくわかる最新システム開発者のための要求定義の基本と仕組み佐川 博樹

おすすめ平均
stars分類が斬新
stars論理的かつ「情」も感じる、開発着手の前にまず読みたい本
stars眼から鱗

Amazonで詳しく見る
by G-Tools
スポンサーサイト

テーマ: ソフトウェア

ジャンル: コンピュータ

tb: --     com: --
Posted on 18:34:04 «Edit»

 「清水 吉男」の名になんとなく覚えはあった。
 一頃「要求定義」に悩まされた。実際はこの後に来る設計やコーディングの段階でその失敗の痛みが出て来るのだが。。。かつて、失敗の分析のためにこんな雑誌を読んだりしたな。
Software People Vol.4
Software People Vol.4Software People編集部

おすすめ平均
starsプログラマからSEへむけて
stars燃えないために正確に仕様化しましょう
stars要件定義の重要性を再認識

Amazonで詳しく見る
by G-Tools

 この雑誌で言い足りない部分を書いたのが本書↓だそうだ。

要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?
要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?清水 吉男

おすすめ平均
stars要求仕様の重要性
starsシステムを使う立場の方にもおすすめ
starsとにかく読みづらい
starsソフトウェア開発に携わる人みんなが読むべき…
stars内容が冗長すぎ

Amazonで詳しく見る
by G-Tools

 「要求」「理由」「説明」をしっかりわけること。この三つの違いがよくわかっていないといけない。そしてIDをふり階層化して管理していく。散文的になってはいけない。シンプルで当たり前のことにも思えるけど、これを徹底して実践していくのは難しい。その大事さ、実践におけるコツを微に入り細に入り説明している。

■ソフトウェアエンジニアのためのホームページ
http://homepage3.nifty.com/koha_hp/

テーマ: システム開発

ジャンル: コンピュータ

tb: --     com: --
Posted on 06:02:13 «Edit»
2007
01/29
Mon

 この手のシステム開発プロジェクトの運営に関する本を手にしたのは久しぶり。
 プロジェクト運営にはPMBOKみたいな手法もあるが、この使用が成功を約束してくれるわけでは決してない。しかも「ITは他の分野に比べて不確実性が大きい」と言われる。プロジェクトの成功に定石はない、というのが本当だろう。したがって、そのための成功ハウツー本も存在し得ない。では、こういった本で勉強する価値はないのだろうか。

プロジェクトはなぜ失敗するのか―知っておきたいITプロジェクト成功の鍵
プロジェクトはなぜ失敗するのか―知っておきたいITプロジェクト成功の鍵伊藤 健太郎

おすすめ平均
starsプロジェクトは本来、失敗するものである
stars成功をイメージしよう
starsより深い議論が欲しい。
stars現場の問題がわかっていないのでは?
stars奇麗事だね。

Amazonで詳しく見る
by G-Tools

さらば!失敗プロジェクト―その経験が成功へ導く
さらば!失敗プロジェクト―その経験が成功へ導く日経システム構築

おすすめ平均
stars声が届かないから、失敗が繰り返される
stars参考になりました。
stars教訓としてはいいかも

Amazonで詳しく見る
by G-Tools

 『プロジェクトはなぜ失敗するのか』では、「プロジェクトは本来、失敗するものである」とし、そう考えることで「事前の対策にエネルギーを多く費やすことになり」、「失敗する確率、または失敗による影響度を減らすことにつなが」るという。そして逆に、プロジェクトは成功して当然であると考えると、「事前の対策より、失敗した後の担当者への責任追及などの事後対応が中心に」なるともいう。
 「プロジェクトは本来、失敗するものである」ということを前提にして、上の二冊には失敗の具体例・典型的パターン、それらの分析がのせられている。システム開発プロジェクトを経験したことのある人だったら身に覚えのある「あるある!」ネタばかり。やはり、こういう本や自分の経験、特に失敗の経験から自ら考えて教訓を引き出し、次に活かさなければならないのだと思う。これらの本にも一応成功ノウハウや立て直し事例ものってはいるが、これに関しては結局、理想論や一般論に留まる印象がある。
 予測のつかないプロジェクトを目の前にしたときほど、根拠のない甘く楽観的な見積もりや計画を立ててしまったり、新技術や新手法の「魔法の杖」で何とかなるはずなんて言い合ったりする。典型的なデスマーチの前奏曲。細かな失敗の萌芽をできるだけ早く察知して対処していく地道な繰り返し作業の先に、プロジェクトの成功はあると思う。常に前倒し、前倒しで失敗要因を潰す行動に出ていかねばならない。上の二冊は即座に対処すべき“問題をかぎ分ける嗅覚”を鍛えるのに役立つ。
 ・・・とは言っても、やはりPMBOKは基本だと思うし、個人的にはWBSも好き(?)っす。
名前だけのITコンサルなんていらない
名前だけのITコンサルなんていらない内山 悟志

おすすめ平均
stars行き詰まった時の解決のヒントが沢山
starsこれから求められるSEのあるべき姿を簡潔に・・・
starsITビジネスに関わる人必見の書!!

Amazonで詳しく見る
by G-Tools

 ついでにこんな本もよんだ。上流工程に着き始めたころに読むと良い本。アナリストが書いた冷静な視点。ちょっと一般論が強いかな。ITコンサルが持つべき基本スキルが一通りのっている。

テーマ: ソフトウェア

ジャンル: コンピュータ

tb: --     com: --
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。