版元ドットコム

探せる、使える、本の情報

文芸 新書 社会一般 資格・試験 ビジネス スポーツ・健康 趣味・実用 ゲーム 芸能・タレント テレビ・映画化 芸術 哲学・宗教 歴史・地理 社会科学 教育 自然科学 医学 工業・工学 コンピュータ 語学・辞事典 学参 児童図書 ヤングアダルト 全集 文庫 コミック文庫 コミックス(欠番扱) コミックス(雑誌扱) コミックス(書籍) コミックス(廉価版) ムック 雑誌 増刊 別冊
ライティングソフトウェア Juval Löwy(著/文) - 翔泳社
..
【利用不可】

書店員向け情報 HELP

書店注文情報

受注専用FAX:
注文電話番号:
なし
注文FAX番号:
注文メール:
なし
受注センター:
注文電話番号:
注文FAX番号:
注文メール:
なし
注文メール:
注文電話番号:
なし
注文FAX番号:
なし
注文メール:

ライティングソフトウェア (ライティングソフトウェア)

このエントリーをはてなブックマークに追加
発行:翔泳社
B5変型判
432ページ
定価 3,800円+税
ISBN
978-4-7981-6683-4   COPY
ISBN 13
9784798166834   COPY
ISBN 10h
4-7981-6683-9   COPY
ISBN 10
4798166839   COPY
出版者記号
7981   COPY
Cコード
C3055  
3:専門 0:単行本 55:電子通信
出版社在庫情報
不明
書店発売日
登録日
2021年2月19日
最終更新日
2021年4月27日
このエントリーをはてなブックマークに追加

紹介

プロダクトとプロジェクトを泥沼から救う工学的手法

【本書の内容】
本書は
Juval Löwy, "Righting Software",
Pearson Education, 2020
の邦訳版です。

オブジェクト指向以降、プロダクトを機能によって分解・構成する手法が一般化しましたが、再利用性やメンテナンス性は言うほど高まってはいません。それは、小さな変更が波及的にプロダクト全体の修正を要求するようになるからです。
そこで「機能」ではなく、「変動性」に着目することで、本来の「設計(デザイン)」を取り戻します。

さらに、変動性を生む要因となる「プロジェクト」自体も、ヒト・モノ・カネ・時間・リスクといった複雑に絡み合う全アクティビティを定量化し、バランスのよい計画と軌道修正を可能にするプロジェクトデザイン(設計)の方法を提示します。

【本書のポイント】
・機能別分解思考から変動性抽出方法へのシフト方法
・プロダクトにかかる人員・品質・コスト・納期・リスクの評価
・全アクティビティのパラメータ抽出および評価方法
・破綻せずに妥当なラインに落とし込むバランスの見つけ方
・図版は4色

【読者が得られること】
・無理・無駄のないプロジェクト
・ブラックな現場をホワイト(せめてグレイ)にする手法
・炎上案件の見極め能力・修正能力

【著者について】
Juval Löwy(ジュヴァル・ローウィー)はIDesignの創設者で、システム/プロジェクトデザインを専門とするソフトウェアアーキテクトの重鎮である。納期、コスト内に高品質のソフトウェアを完成させるために、世界中の無数の企業を支援してきた。マイクロソフトに世界のトップエキスパート、業界のリーダーの1人として認められ、C#、WCFと関連テクノロジーの社内戦略的デザインレビューに参加し、「ソフトウェアのレジェンド」と呼ばれた。数冊のベストセラー本と現代のソフトウェア開発のほとんどあらゆる側面についての数々の論文を発表している。メジャーな国際的ソフトウェア開発カンファレンスで頻繁に演壇に立ち、現代のソフトウェアアーキテクトに求められるスキルは何か、デザイン、プロセス、テクノロジーのリーダーとしてどのように責務を果たすべきかを無数のプロフェッショナルたちに伝授している。

目次

第1章 ザ・メソッド
1.1 ザ・メソッドとは何か
1.2 ザ・メソッドは何ではないか

■第1部 システムデザイン

第2章 分解
2.1 機能別分解をしてはいけない
2.2 変動性に基づく分解
2.3 変動領域の見つけ方

第3章 構造
3.1 ユースケースと要件
3.2 階層化されたアプローチ
3.3 典型的な階層
3.4 分類のガイドライン
3.5 サブシステムとサービス
3.6 オープンアーキテクチャとクローズドアーキテクチャ

第4章 組み立て
4.1 要件とその変更
4.2 組み立てられるデザイン
4.3 機能はない
4.4 変化の処理

第5章 システムデザインの実例
5.1 システムの概要
5.2 アンチデザインの試み
5.3 ビジネスと歩調を揃える
5.4 アーキテクチャ
5.5 デザインの検証
5.6 次にすべきこと

■第2部 プロジェクトデザイン

第6章 プロジェクトデザインが必要な理由
6.1 なぜプロジェクトデザインか

第7章 プロジェクトデザインの概要
7.1 成功の定義
7.2 プロジェクトの初期の人員配置
7.3 知識に基づく判断
7.4 サービスと開発者
7.5 作業量の見積もり
7.6 クリティカルパス分析
7.7 工程のスケジューリング
7.8 プロジェクトのコスト
7.9 予定出来高
7.10 職務と責任

第8章 ネットワークとフロート
8.1 ネットワーク図
8.2 フロート
8.3 フロートベースのスケジューリング

第9章 スケジュールとコスト
9.1 ソフトウェアプロジェクトの加速化
9.2 スケジュールの圧縮
9.3 時間̶コスト曲線
9.4 プロジェクトのコスト要素
9.5 ネットワークの圧縮

第10章 リスク
10.1 デザイン案の選択
10.2 時間̶リスク曲線
10.3 リスクのモデリング
10.4 圧縮とリスク
10.5 リスクの弛緩
10.6 リスクの指標

第11章 プロジェクトデザインの実際
11.1 任務
11.2 基準ソリューションの特定
11.3 ネットワークの圧縮
11.4 効率分析
11.5 時間̶コスト曲線
11.6 プランニングとリスク
11.7 SDPレビュー

第12章 高度なテクニック
12.1 ゴッド工程
12.2 リスク交差点
12.3 弛緩ターゲットの見つけ方
12.4 幾何リスク
12.5 遂行の複雑度
12.6 非常に大規模なプロジェクト
12.7 小規模プロジェクト
12.8 階層構造によるデザイン

第13章 プロジェクトデザインの実例
13.1 見積もり
13.2 依存関係とプロジェクトネットワーク
13.3 基準ソリューション
13.4 圧縮ソリューション
13.5 階層構造によるデザイン
13.6 亜極限ソリューション
13.7 デザイン候補の比較
13.8 プランニングとリスク
13.9 SDPレビューへの準備

第14章 まとめとヒント
14.1 いつプロジェクトデザインをすべきか
14.2 全般的なガイドライン
14.3 プロジェクトデザインのデザイン
14.4 遠近法
14.5 移管
14.6 練習
14.7 プロジェクトデザインの反省会
14.8 品質について

■第3部 付録

付録A プロジェクトの進行管理
A.1 工程のライフサイクルと状態
A.2 工程の状態
A.3 プロジェクトの状態
A.4 進捗度と作業量の追跡調査
A.5 プロジェクトの今後の予測
A.6 予測と問題への対処策
A.7 予測についてさらに

付録B サービスのコントラクトデザイン
B.1 これはよいデザインなのか
B.2 モジュラー性とコスト
B.3 サービスとコントラクト
B.4 コントラクトの分割
B.5 コントラクトデザインのガイドライン
B.6 コントラクトデザインの課題

付録C デザイン標準
C.1 最高鉄則
C.2 鉄則
C.3 システムデザインのガイドライン
C.4 プロジェクトデザインのガイドライン
C.5 プロジェクト進行管理のガイドライン
C.6 サービスコントラクトデザインのガイドライン

上記内容は本書刊行時のものです。