ソフトウェア・エンジニアリング入門 セッション 2: ソフトウェア・プロセス chart 2-1 このセッションの目標 • ソフトウェアはどのようにして作られるのかを理解する – おぼろげな要求や期待からソフトウェアを作って運用す るまでの一連のプロセス – 各フェーズ、タスクでは何を行うのか • ソフトウェア・プロセスの問題点について論じる • 良いソフトウェアを作るための望ましいソフトウェア・プ ロセスとは何かを考える chart 2-2 ソフトウェア･プロセスとは何か？ ソフトウェアのプロセス・モデルは、ソフトウェア・ プロジェクトの以下の事柄を規定するものである： – 作業活動 – 作業成果 – 作業活動間での作業成果の流れ – レビュー･ポイントとマイルストーン chart 2-3 ウォーターフォール・モデルの例 システム要件 の分析と定義 一般の工業製品の製造工程を模したもの ソフトウェア要件 の分析と定義 長所: 基本設計 詳細設計 1. 進捗の管理が容易。 2. 仕様が明確で、類似システムの 開発経験があるときには、 効率・品質面で優れる。 短所: 1. 定義した要件に合致したシステムができたか、 プログラミング 定義した要件自体が正しかったかどうかは、 運用するまでは判明しない。 2. 作業工程の柔軟性に欠けるので、 テスト 途中で前提条件の変化や問題に気づいても 対応できない。 運用 ※箱の数や、各箱の中の名前（呼び名）は、場合によって変わることがあります。 chart 2-4 Vモデルの例 業務要件 ユーザテスト システムテスト システム要件 基本設計 詳細設計 統合テスト サブシステムテスト 実装 （プログラミング、単体テスト） chart 2-5 スパイラル・モデル • 企業内で経営環境の変化に応じた業務改善を行う場合 に用いられる PDCA (Plan-Do-Check-Action) サイクル の考え方をシステム開発にも適用し、仕様の変更も積極 的に取り入れられるよう考案されたもの • 次ページを参照のこと chart 2-6 主要な作業活動： コアタスク • 分析 … 対象領域の理解、開発対象の要件定義 – 何がどうなっているのか、何をしたい（する）のかを明確にする。 • 設計 … 要件から実装への橋渡し – 要件を満たすためにどうするのかを明確にする。 – 複数ある実現方法の中から、状況に合わせて取捨選択する。 • 実装 … 実際にコンピュータ上で動作するものを作る – 設計に基づいてプログラムを作成し、単体での動作を確認する。 • テスト … 作ったものが仕様に合致しているか検査する • 運用と保守 chart 2-7 コアタスク 分 析 • おぼろげな要求から、解くべき課題を明らかにする。 – 解くべき課題を明らかにしなければ、解くことはできない。 • 課題のコンテキスト（前提、背景）を明らかにする。 – 「システム」（作るべきもの）と「適用領域」（与えられるもの）との 関係。 • 適用領域を明らかにする: 領域（ドメイン）分析。 – 適用領域の特性、領域間の相互作用 • システムあるいはソフトウェアの要件を明らかにする。 – この段階までには、システムの運用要件・方針も明らかにする。 – 提供すべきサービス、要求される特性、時期、コスト等 chart 2-8 コアタスク 領域分析（ドメイン分析） • 扱うべき主題や適用領域を明らかにする – ここでの「領域（ドメイン）」とは、ひとまとまりのものとして考えると 都合が良かったり、ある程度、世界の他の部分から分離して考 えることができるもの。 – 課題の定義や課題の文脈から、主題と適用領域を洗い出す。 • 異なる主題の複数の領域に適用領域を分割していく。 • 領域の適切さに関する原則: – 要求に関連するすべての事項が適用領域のどこかに現れなけ ればならない。 • 領域分割の基準: – それぞれの領域の内部属性と振る舞いが大部分お互いから独 立していること。 ※このページの内容は、マイケル・ジャクソン著『ソフトウェア博物誌』ISBN4-8101-8098, p.231-237を参考にしました。 chart 2-9 コアタスク 領域分析（ドメイン分析） 続き • 領域特性を明らかにする。 – 領域特性が異なれば、それを扱う問題の適切な解き方も異なる。 – 領域特性の例: • 静的／動的、１次元／多次元、有形／無形 – 動的領域では時間軸（事象、状態）を考慮しなければならない。 – 動的領域を区別する特性として、不活性(inert)、反応的(reactive)、能 動的(active)というのもある。 » たとえば、気象を扱うプログラムでは、大気は能動的領域とみな す。（気圧、湿度、温度、風速などはすべて自発的に変化する要 素だから） – 能動的領域のなかにはさらに、自律的、指示可能、プログラム可能と いった重要な区分がある。 • 領域間の相互作用を明らかにする。 chart 2-10 コアタスク システム要件の分析と定義 • システムが何をすべきか明らかにする。 – システムが提供すべきサービスは何か。 – ものとしてのシステムが持つべき特性は何か。 – 実現可能な要件を「仕様」として定義する。 • 留意点: 「願望」の記載と「事実」の記載は明確に分ける • 要件には次のような観点がある – – – – 特徴／機能 性能要件、品質特性 時期的要件、コスト要件、設計上の制約条件、 運用（操作）に関する要件、優先順位 等 chart 2-11 コアタスク ソフトウェア要件の分析と定義 • システム要件のうち、ソフトウェアで実現すべき部分につ いて、分析を行い要件を定義する。 • 少なくとも以下の事柄は明らかにする: – 対象ソフトウェアの外部とのインタフェース – 提供すべき機能、サービス – 扱うべき情報の種類、構造、関係 – 振る舞い（動作）に関する要件 – 性能要件、品質要件 – その他設計に影響を及ぼすような制約条件 chart 2-12 コアタスク 設 計 • 要件を実現するための方策を検討し、決定する。 – 「何を(What)」から「如何に(How)」へ。 – 技術的課題とその方策、リスクを明らかにする。 – 考えられる方策を比較検討し、妥当な設計を探る。 – リスクの大きい部分ほど細かく検討する。 • リスクの大きい部分は、先行開発したり、プロトタイピングしても良い。 – 設計結果だけでなく、なぜその設計にしたのかの決定理由があとで 分かるように、将来再検討できるように、理由も文書化しておく。 – ドメインごとに分担して並行に設計をすることも考えられる。 • なぜなら、ドメインごとに異なる知識が要求されるから。 – ここでは、基本設計と詳細設計に分けて考える。 chart 2-13 コアタスク 基本設計 • データベース、ネットワーク、分散化、信頼性確保対策等、 システムの基盤となる設計を行う。 – 要件（機能だけでなく信頼性などの品質要件を含む）を満たすた めには、どのような方式、規模が良いか。 • 利用できるもの（フレームワーク、パターン、基本ソフト、 DBMS、ERP、TPモニタ、ビジネスオブジェクト、ライブラ リ等）は極力利用し、新規開発部分を削減する。 – – – – 考えなくてすむなら考えない。 作らなくてすむなら作らない。 利用するものの特性やライフサイクルも考慮して設計する。 既存システムと接続する場合には、インタフェース設計も重要。 chart 2-14 コアタスク 基本設計 続き • システムを適度な大きさのコンポーネントに分割する。 – 分割の仕方が基本設計の重要なポイント。 – 適切な分割は、システムの複雑さを低減してくれる。 • コンポーネント間の関係（動的関係、静的関係）、インタ フェース、各コンポーネントがやるべきことを明確にする。 • よく知られているパターンや構成、フレームワーク等をうま く利用する。 – レイヤ、ブローカ、Model-View-Controller、３層クライアント／ サーバ型等 – OMG (Object Management Grop) では、ドメイン共通やドメイン 別のフレームワークの標準化を進めている。 • http://www.omg.org/techprocess/meetings/schedule/index.html chart 2-15 コアタスク 良い設計のための根底技術（基礎原理） • • • • • • • • • • 抽象化 カプセル化 情報隠蔽 モジュール化 関心の分離 結合度と凝集度 充足性、完全性、プリミティブ性 ポリシーと実装の分離 参照の一点性 分割統治 参考: POSA本(邦訳：ソフトウェアアーキテクチャ）の6.3節 chart 2-16 コアタスク 詳細設計 • ユーザインタフェース設計 – 画面、帳票のレイアウト、ユーザイベントに対する動作等 • データベース設計 – 基本設計の段階で設計したDBスキーマを正規化 – テーブル定義、ビュー定義、アクセス権定義等 • コンポーネント設計 – – – – コンポーネント間インタフェースの確認 アルゴリズムの検討 プログラミング言語の特性を考慮した設計 デザインパターンの活用 chart 2-17 コアタスク プログラミング • 必要に応じて更に細かくモジュール分割する • コーディング – 記述言語、ライブラリ、ツール等を適切に使用する。 – 表明 (assertion) 等のよく知られたテクニックを適切に使用する。 – よく知られたイディオム（プログラミング・パターン）を活用する。 • コンパイル • 単体テスト、デバッグ – – – – コンポーネント（プログラム）単体での動作を確認する。 単体テストが終わるまではプログラムができたとは言えない。 この段階では、通常、ホワイトボックステストが行われる。 ホワイトボックステストとは、プログラムの内部構造（条件分岐 等）に従ってテストケースを設定して行うテストのことである。 chart 2-18 コアタスク 設計・実装上の技術的課題 （順不同） • 複雑さへの対処 • 計算モデルと言語 • データ構造とアルゴリズム – データ量、計算量 • メモリ管理、ゴミ集め • トランザクション管理 – データの一貫性の保証等 • エラー処理、例外処理 • プラットフォーム、基盤ソフト等の 絶え間ないバージョンアップ、それ らとの組合せ・相性 • • • • • • • • • • • 情報量、通信量 負荷増大・負荷集中への対処 並列、分散 同期／非同期 実時間（リアルタイム） リソースの競合、デッドロック セキュリティ、認証、アクセス権 計算精度、誤差 （種々の）依存関係 （種々の）トレードオフ etc. chart 2-19 コアタスク テスト • テストとは、ソフトウェアが品質要件を満たしているかどう か確認すること。 • 品質要件に基づいてテストするので、ブラックボックステストとな るが、その前にはコードレビューやホワイトボックステストを行い、 単体の機能レベルでの欠陥をなくしておくのが前提。 • 機能性を満たした後で、その他の品質要件のテストを行う。 • 統合テスト – 単体テスト済みのコンポーネントを統合して行うテスト • 顧客テスト（ユーザテスト） – 本番の運用（と同等の）環境下で顧客（ユーザ）が行うテスト • 品質特性に応じた特別なテスト – 耐久テスト（ストレステスト、ラッシュテスト）、性能テスト、ウィルス予 防テスト、セキュリティテスト、プラットフォームテスト chart 2-20 コアタスク テストの基本 • いつでも同じテストを再現できるように準備する。 • テストで欠陥が見つかったら、必ず記録を残す。 – 何をもって欠陥とみなすか、欠陥の数え方、記録の仕方... • 欠陥を分析し、担当者に割り当て、行方を管理する。 – 基本設計に起因するような深い欠陥だったら… – 単体レベルの欠陥が統合レベルで出るようなら... • 欠陥を修正したら、必ず、（単体テストから）テストをやり直す。 – 欠陥を一つ直しても、新たな欠陥を埋め込むことはよくある。 – 欠陥を一つ直すと、別の欠陥が発見されることもよくある。 • テストは、用意したテスト環境（基盤、テストケース、テストデータ） での実施において、欠陥が見つからなかったことを保証するだけ である。欠陥が存在しないことを保証するわけではない。 chart 2-21 コアタスク 運 用 • （早期に決まっているはずの）運用方針に基づいて、運用 設計、運用準備を行い、運用する。 – 運用方針は、システム設計に影響を与える。 – 大規模システムの場合には運用は特に大切であり、システム開 発と並行して入念に準備されるのが普通。 • 主な考慮事項 – – – – 運用の主体、期間および時間、形態、手順 既存システムとの連携、移行方法等 開発チームや保守チームとの連携 運用準備としては: 機器類の調達、開発したシステムおよび運用 ツール群の調整、運用上の各種パラメータの調整、マニュアル chart 2-22 支援作業活動： サポートタスク • コアタスクの進行を横から支援 するため： – コアタスクを行うメンバに行わ せるには負荷がかかりすぎ、 本来の作業ができなくなって しまうような作業 – プロジェクト全体として統一を 取るべき事柄 • 例： – – – – – – – – – プロジェクト管理 標準化 開発環境の整備と運用 品質保証・品質管理 構成管理、欠陥管理、リリー ス管理 文書化 要員の教育・トレーニング 法務 その他 chart 2-23 サポートタスク プロジェクト管理 • プロジェクトの運営に伴う管理業務。 • プロジェクト管理者が一人で行うのでは作業負荷がかか るので、チームでプロジェクト管理サポートを行う。 • 配員、リソースの手配に伴う雑務。 – プロジェクトによっては、頻繁に座席変更や引っ越しが必要なこ ともある。開発メンバにかかる負担は極力減らすようにサポート。 • リスクの管理。 • その他。 • 詳しくは、３日間のプロジェクト管理セミナーで扱います。 chart 2-24 サポートタスク 標準化 • 何を標準化するか – 開発手法、手順、文書、図表の表記(notation) 、エラーや障害の 取扱い、命名基準、コーディング・スタイル 等 – 形式の標準化も大切だが、記述すべき内容の標準化も大切。 • どのように標準化するか – 守りやすく、守って良かったと思えるような標準にする。 – 対象ソフトウェアにとって大切な部分については特に明確に。 – うまくいっている標準があるならそれに合わせるのも良い。 • 標準をどのように守らせるか – 標準を決めるだけでなく、サンプルの提示、ツール類やテンプ レート類の提供で支援する。 chart 2-25 サポートタスク 開発環境や支援ツールの選定・整備・運用 • 開発には開発に便利な環境とその運用が必要。 • たとえば: – 開発に使用する基本ソフトやミドルソフトの載った環境, • 確認のため、最終的には運用環境と同等の環境も必要。 – 文書化やコミュニケーションのための Windows PC, • プロジェクト内だけでなく、全社的なネットワークも – 成果物の一元管理に便利な UNIX Server, – 作業内容や目的に合わせた支援ツール – ツール類のバージョンアップや成果物のバックアップも組織的に – 広い机、空調の効いた部屋、ホワイトボード、適度なミーティング スペース等も必要 chart 2-26 サポートタスク 構成管理、欠陥管理、リリース管理 • 構成管理とは、システムの構成を追跡できるように管理 すること。成果物の一元管理、バージョン管理を含む。 • 欠陥が発見されたら必ず記録に残るようにし、その欠陥 の症状、原因、修正状況等の情報がいつでも参照できる ようにしておくこと。 • どのリリースではどういう構成なのか、確実に把握できる ようにしておくこと。 • どのリリースでどの欠陥が修正されたのか、顧客に確実 にリリースされたのか、追跡できるようにしておくこと。 • これは、ソフトウェアに限った話ではない。 chart 2-27 サポートタスク 構成管理 (Configuration Management) • 一つのパッケージ（リリース）は通常複数のファイルから構成さ れる。パッケージによっては、スタンダード版、デラックス版な どファイル構成を変える場合がある。 • 各ファイルは変更を明確に管理するためバージョンを付ける。 変更は仕様変更か欠陥修正のために行われるのが普通なの で、それらとの関係や変更理由も合わせて明確に管理する。 • 全体としてのパッケージにもバージョンを付け、個々のファイル のバージョンとの対応を明確にする。 • 複数名での開発においても矛盾が生じないようにする。 • 簡単にいうと、以上のようなことを、うまくできるようにするのが 構成管理。構成管理ツールと適切な運用が必要。 – ClearCase(http://www.rational.com/)やCVS(http://www.cyclic.com/)が有名。 chart 2-28 サポートタスク プロジェクト情報の共有支援 • プロジェクトが同じ方向を向くように • 担当者が休むと何もわからないということがないように • 皆が直接担当者に聞いて、担当者が忙しすぎるというこ とがないように • 既に解決していることを知らずに悩んだりしないように • 知識データベース等を活用して情報を共有する: – プロジェクトがどこへ向かっているのか、どういう状態にあ るのか、 – ある事柄に関する窓口は誰か、 – 解決すべき課題は何か、解決できた課題は何か、 – プロジェクトへの新規参入者が知るべき情報等 chart 2-29 現状のソフトウェアプロセスの問題点 • どんな問題点があるでしょうか？ • 現場は混乱していませんか？ – 途中で誰かが問題点に気づいたとき適切に対応できるよう になっているでしょうか？ – どの時点で何をしているべきなのか、関係者皆が把握してい るでしょうか？ • 工程が進んでいるようにみえて、課題を先送りしているだ けだったということはありませんか？ – 予定の時期がくれば仕事が終わってなくても工程は終わ る？ • すなわち、ソフトウェアプロセスの定義自体や、管理方法に 問題がないでしょうか？ chart 2-30 ソフトウェアプロセスの特徴づけ • 並行性と分散性 – 空間的、時間的に分散したタスクと相互作用し、並列なも のも含む。 • 不確定性と非決定性 – 選択肢となるパスは進行中に作られる。予測できない。 • エラー、やり直し、および他の突発事項 • 進化と変化 – ソフトウェアと同様、ソフトウェアプロセスにもフェーズから なるライフサイクルが存在する。 ※参考:Alfonso Fuggetta, Alexander L. Wolf 編，岸田孝一監修「ソフトウェアプロセスのトレンド」， 海文堂，1997，ISBN4-303-72850-0， p.3-7 chart 2-31 良いソフトウェアを作るためには: • 欠陥のないソフトウェアはない。 • 良いソフトウェアとは？ • 望ましいソフトウェア・プロセスとは何でしょうか？ – プロダクトの特徴とプロセスの特徴 • 要求される品質特性を計画的に作り込むには？ • 問題点の早期発見、対処、フィードバック • 短いサイクルを何度も回しながら、良くない部分を排除し て、次第に良くしていくアプローチ • リスク管理 chart 2-32 問題点を早期発見するための方法の例: • • • • • • 関係者間でコミュニケーションを良くする。 各自の成果物はプロジェクト内で（早めに）オープンにする。 早めにプロトタイピングやデモンストレーションを実施する。 ウォークスルーを実施する。 ソースコードレビューを実施する。 なるべく早い段階からテストシナリオやテスト項目を明らか にし、test-suites (テストスクリプトやデータと期待される結果 のセット）を準備する。 • コンパイルが通る程度のソースコードができたら、毎日自 動コンパイル（ビルド）、自動テストを行う。 • 完璧を待たず、ある程度できたら使って評価してもらう。 chart 2-33 セッション2 まとめ • ソフトウェアプロセスモデル – ウォーターフォール、スパイラル • ソフトウェアプロセスにおけるタスク – コアタスク – サポートタスク • ソフトウェアプロセスの特徴 • 良いソフトウェアを作るためのプロセス chart 2-34
© Copyright 2025 ExpyDoc
