[実践的]ソフトウェア開発工程管理

[表紙][実践的]ソフトウェア開発工程管理

A5判/232ページ

定価(本体2,280円+税)

ISBN 4-7741-1075-2

ただいま弊社在庫はございません。

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

商品としてのソフトウェアの開発は,少人数のプロジェクトから大規模な開発まで,人が集まって実施するという点で,問題の発生する局面は多々存在します。本書は,豊富な実践経験を持つ著者が,永年にわたって蓄積してきた知識を一挙に公開するものです。

こんな方におすすめ

  • ソフトウェア開発に携わっている方
  • 初めてソフトウェア開発のプロジェクトに参加する方

目次

第1章 ソフトウェアの開発

  • 1・1 ソフトウェア開発の手順
  • 1・2 ソフトウェアの設計
    • 1・2・1 基本設計
    • 1・2・2 機能設計
    • 1・2・3 詳細設計
  • 1・3 ソフトウェアの開発と製造
    • 1・3・1 プログラミング
    • 1・3・2 テスト仕様書
    • 1・3・3 プログラム変更管理
    • 1・3・4 テスト進捗管理

第2章 管理とは何か

  • 2・1 管理に対する考え方
  • 2・2 開発工程と管理

第3章 開発と管理

  • 3・1 開発管理で用いるドキュメント
    • 3・1・1 アローダイアグラム(作戦遂行戦略図)
    • 3・1・2 工程管理表
    • 3・1・3 テスト進捗管理(バグ発生/テスト消化曲線)
    • 3・1・4 目標設定
  • 3・2 アローダイアグラム
    • 3・2・1 アローダイアグラムの利用
    • 3・2・2 アローダイアグラムを利用する上でのポイント
  • 3・3 目標の設定
    • 3・3・1 プログラミング
    • 3・3・2 テスト項目
    • 3・3・3 摘出不良件数
  • 3・4 開発管理マスタードキュメント
    • 3・4・1 工程管理表
    • 3・4・2 ILUO(モジュール関連図)管理
  • 3・5 テスト進捗管理
    • 3・5・1 テスト進捗管理の事例
    • 3・5・2 発生/テスト消化曲線でのテスト進捗管理のポイント

第4章 品質と管理

  • 4・1 品質の管理
  • 4・2 品質とコスト
  • 4・3 不良の分析
    • 4・3・1 プログラム変更管理表
    • 4・3・2 不良摘出状況分析/予測

第5章 開発における実践アドバイス

  • 5・1 設計段階
    • 5・1・1 アローダイアグラムの日程は逆から立てる
    • 5・1・2 アローダイアグラムの項目ははっきりと記載する
    • 5・1・3 作業ステップ数はプログラム開発の基準値である
  • 5・2 プログラミング段階
    • 5・2・1 きれいなプログラムには不良が少ない
    • 5・2・2 プログラムの先頭にはヘッダコメントをつける
    • 5・2・3 コメントは重要な仕様書である
    • 5・2・4 プログラムの入口/出口は1カ所にまとめる
    • 5・2・5 プログラムのステップ数は,50ステップを目安にする
    • 5・2・6 インデンティングはあまり深くしない
    • 5・2・7 例外処理,異常処理はメイン処理の外に置く
    • 5・2・8 アセンブラ言語で記述することをおそれてはいけない
    • 5・2・9 罠を張るプログラムを仕込んでおく
    • 5・2・10 重要な処理についてはシミュレーションを行う
    • 5・2・11 チューニングは諸条件を考慮して注意深く行う
    • 5・2・12 作業エリアの定義は正確に行う
    • 5・2・13 ソースの管理は体系的に行う
  • 5・3 テスト段階
    • 5・3・1 テストの目的を認識しておく
    • 5・3・2 テスト項目作成の際は,不良があることを前提にする
    • 5・3・3 マトリックスチェックリストは,机上,単体テストに利用する
    • 5・3・4 プログラムテスト仕様書は,結合テスト,システムテストに利用する
    • 5・3・5 机上デバッグをおろそかにしない
    • 5・3・6 机上,単体テスト完了までは,結合テストに移行しない
    • 5・3・7 単体デバッグ以降は,メインパスを最優先に完了させる
    • 5・3・8 テスト項目件数は,その最適値を求める
    • 5・3・9 目標テスト項目件数の配分は,よく考えて行う
    • 5・3・10 摘出不良目標件数は,使用に従った開発の証明となる
    • 5・3・11 テストプログラムの作成は計画をもって行う
    • 5・3・12 負荷テストを前提にテストを実行する
    • 5・3・13 入力データは,許されない物もテストしておく
    • 5・3・14 モンキーオペレーションも重要なテスト方法である
    • 5・3・15 テスト結果の判定は正確に行う
    • 5・3・16 不良が発生したら分析を行う
    • 5・3・17 類似の不良はステップ数と同じだけあると考える
    • 5・3・18 「1と3の法則」に注意する
    • 5・3・19 不良の修正では,現象対策ではなく根本原因対策を行う
    • 5・3・20 プログラムの修正は完全を期して行う
    • 5・3・21 プログラムの変更管理は省かない
    • 5・3・22 自前ツールの開発は怠りなく行っておく
  • 5・4 管理者としての心構え
    • 5・4・1 プロジェクト管理者は,そのあり方を自ら問うべし
    • 5・4・2 プロジェクトの開発能力を把握するように努める
    • 5・4・3 開発者の技術能力の差を平準化するように努める
    • 5・4・4 開発者が達成可能な目標値を定め,「挑戦」する
    • 5・4・5 技術能力は個人個人で違い,1人=1人とはいえない
    • 5・4・6 つねに新しい試みを行うようにする
    • 5・4・7 管理者は,いつも攻撃的であれ
    • 5・4・8 油断はプロジェクトを混乱させる
    • 5・4・9 数字がすべてを物語るとは限らない
    • 5・4・10 管理はビジュアルに行う
    • 5・4・11 プロジェクト推進には3つの「山」がある
    • 5・4・12 突き当たった「壁」を知るには,ボールを投げてみる
    • 5・4・13 決断にはリスクがあることを認識しておく
    • 5・4・14 プログラムを切り捨てることも管理者の仕事である
    • 5・4・15 遅延を取り戻す特効薬はない
    • 5・4・16 分析ができない管理者は去れ
    • 5・4・17 過去の失敗は成功への扉の鍵として活かす
    • 5・4・18 ソフトウェアは,システムの総仕上げをするものである
    • 5・4・19 プログラムの最終評価は,使用する顧客が下す
    • 5・4・20 プログラムの品質という物を考え直してみる

著者プロフィール

竹山寛(たけやまひろし)

1969年日立製作所入社。メインフレームオペレーティングシステムの設計/開発に従事後,1980年からメインフレーム,システム開発のプロジェクトマネージメントを行う。1983年より半導体事業部で機器組込み分野に移り,ICEシステム,ファームウェア,μITRON仕様OS,JPEGミドルウェアの設計/開発とMMCビジネス構築,SoCシステムのソフトウェア開発環境の構築設計などに従事。トロン協会のITRON専門委員会委員長(1987~1990年)も務める。コンサルタント会社(2002~2004年)でソフトウェア開発管理の調査/分析/提案,開発管理支援,プロジェクト管理,ビジネスモデルの構築,研修セミナーの講師などを行う。

2004年コンサルタント会社ペネトレートを設立。組込みシステム開発,ファームウェア開発,ビジネスモデル構築,ソフトウェア開発プロセス,プロジェクト推進支援,品質管理,プロジェクト管理など組込みシステムに関するプロセス全般にわたり,現場で直ちに効果の出る実践的なコンサルティングを行ってきた。

2006年より株式会社ガイア・システム・ソリューションにおいて会長顧問の活動も行った。