内容と予定（ - jaist.ac.jp‚ªブジェクト指向とソフトウェア工学.pdf ·...

内容と予定（2）• オブジェクト指向ソフトウェア開発方法論

– ユースケース駆動統一プロセスの概要

– エレベータ制御システム：問題記述とユースケースモデル

– エレベータ制御システム：問題領域（分析）オブジェクトの発見

– エレベータ制御システム：サブシステム設計とタスク設計

– エレベータ制御システム：性能評価

– プロダクトライン技術

• オブジェクト指向技術の位置づけ

– ソフトウェア工学の歴史とオブジェクト指向技術の

位置づけ

– 最終課題

北陸先端大落水浩一郎

オブジェクト指向技術のソフトウェア工学における

位置づけ

北陸先端科学技術大学院大学

情報科学研究科

落水浩一郎


ソフトウェアは従来の工業製品と異なる特徴をもつ

• 現在、人間が生産する産物のうちでソフトウェアはもっとも複雑なものであり、建物やVLSIに比べてもはるかに複雑である（ F.ブルックス Jr.）


ソフトウェアは従来の工業製品とは異なる特徴を持つ（ F.ブルックス Jr.）

• 複雑性ソフトウェアは膨大な数の異なる部品とその組み合わせからなる

• 適合性ソフトウェアは社会規則、機械の性能、使用するコンピュータなどが課す境界条件を遵守して作成されなければならない

• 変更困難性社会規則の変更や計算機の進歩に追随するのが容易でない

• 不可視性設計図面の幾何学的抽象が他の分野のように容易でない


機械

SoC

組込みソフトウェア

ビジネス, 社会規則

計算機とネットワーク

情報システム複雑性, 不可視性

適合性

進化（変更困難性）制約

制約

制約

制約

進化（変更困難性）

複雑性, 不可視性

適合性

適合性

適合性


ソフトウェアはチーム活動で作成される

• さまざまなスキルレベルを持つ人間が協調して、一行の間違いも許されない正確なプログラムを、所定の期日までに完成しなければならない。

• 人間に起因する、様々な変動性、突発性、不確定性への対応が困難である


ソフトウェア工学とは

• これらの特性をもつソフトウェアの開発や進化を支援する技術がソフトウェア工学である

• ソフトウェア固有の問題点を制御する手段を与え、人間集団の活動を支える技術を提供する


例えば

• ソフトウェアプロセスモデル– ソフトウェア開発の戦略を規定する

• ソフトウェア開発方法論– ソフトウェアの持つべき望ましい「構造」を定義し、それらを作りこむ手段を検討する。

– 「構造」の属性の例：正しさの確認容易性、変更波及の局所化、作業分担の容易性、再利用容易性、進化容易性など

• プロジェクト管理– プロジェクトチームのコスト、スケジュール；プロダクトの品質などに関して、それらを計画・見積り・資源割当・状況の監視（メトリクス）と制御（ベストプラクティス）落水,「ソフトウェア開発方法論とプロジェクト管理の融合法に関する基礎考察」,電子情報通信学会ソフトウェアサイエンス研究会資料、信学技報SS2006-19, PP.37-42,2006


ソフトウェアプロセスモデルの役割

• 様々なスキルレベルを持つ人間からなるチームを（必要なら異なる組織にわたって）協調させるためには、まず、適切なソフトウェアプロセスモデルを採用する必要がある。


ソフトウェアプロセスモデルだけで大丈夫か

• しかし、人間集団の動きを統一するだけでは品質はつくりこめない。目標とする品質を作りこむためには、開発手段の標準化が必要であり、適切なソフトウェア開発方法論を採用する必要がある。

• ソフトウェアプロセスモデルで定義された戦略のもと、開発手段の標準化をこころみるためにソフトウェア開発方法論が必要である。


ソフトウェア開発方法論の役割

• ソフトウェア開発方法論の研究では、ソフトウェアの望ましい「構造」を模索しつつ、それらの構造を作りこむ手段を検討してきた。追求されてきた「構造」の属性として、正しさの確認容易性、変更波及の局所化、作業分担の容易性、再利用容易性、進化容易性などがある。


ソフトウェアプロセスモデルとソフトウェア開発方法論だけで

大丈夫だろうか

• 人間集団の動きを統一し、開発手段を標準化することにより足並みをそろえても問題は残る。

• ソフトウェア開発プロジェクトで常に問題になるのは、コスト超過、スケジュール遅延、品質の不十分性である。


プロジェクト管理技術の役割

• プロジェクト管理の役割は、

– 限られたリソース（人、設備、お金、情報など）を基に、納期どおりに、求められた品質を達成する妥当なプロジェクト計画を策定し

– かつ、開発の進行につれて顕在化してくる、見積もりや計画段階で読みきれなかったことがら（状況）を検知し（学習）、必要な対応策をほどこすことにある。様々な状況を測定し制御する必要がある。


ソフトウェアプロセスモデルソフトウェア開発方法論、プロジェクト管理技術の発展の歴史（サーベイ）

• ウォータフォールモデルの提案• プログラミング方法論の提案(1970年代前半）• 設計方法論の開発(1970年代後半）• 要求定義技術の開発(1970年代後半）• 定量的プロジェクト管理のはしり(1970年代後半から1980年代前半）• システム工学の導入によるWaterfall Model の改善(1980年代中期から後半）• 反復型Waterfall Model の提案(1980年代前半）• プロトタイピングの出現(1980年代前半）• 実行可能仕様とフォーマルメソッド(1980年代中期）• プロセスプログラミング(1980年代後半）• プロセス改善技術(1990年代初頭）• CASEツール(1990年代初頭）• アーキテクチャ中心開発(1990年代中期）• オブジェクト指向技術（ 1980年代以降）• ソフトウェアアセスメント技術の成熟（1990年代後半）• UML (1990年代後半）• 反復型プロセスモデル（2000年代）• アジャイル（2000年代）• ゴール指向要求工学、統合要求工学、COTS（最近）

落水,”ソフトウェア開発方法論とプロジェクト管理の融合法に関する考察“, SPI Japan 2006, 2006年10月．


ソフトウェアプロセスモデルの変化

• Waterfallモデル（わける、契約駆動、内製）– フェーズ間に集積される文書間の依存関係を利用して開発計画

を立案し、また集積された文書の品質を保証することで大規模開発を制御する

• Vモデル（システム工学の導入、折り曲げる、外注）– 開発（発注）仕様とテスト（受入）仕様を同レベルの抽象度で

書くことにより外注に対応する

• ミニWaterfallによる反復（繰り返す、リスク管理）– ウォータフォールモデルを繰り返し実行することにより、コス

ト・納期・品質に関するリスクを早期に発見・対応する

• プロトタイピング（取り込む、ユーザの取り込み）– 繰り返しにユーザを含めることにより仕様の早期確定をはかる

• 反復型モデル（イテレーティブ＆インクリメンタル、重ねる、不確実さの減少、プロジェクト特性の学習）– 各フェーズを重ねて並行実行し、プロジェクト固有の問題点を

発見するたびに反復を繰り返す

落水, 「WaterFall Model 再考」．SEAMAIL, Vol.14, No 9-10, pp.32-59


ウォータフォールモデル構築に至る論理の展開

• モデルの構築– （プログラム）「分析」と「コーディング」から始める

– 大規模ソフトウェア開発を制御するために必要なフェーズ群を付加する（システム要求定義、ソフトウェア要求定義、プログラム設計、テスティング、稼動）

– フェーズの実行順序に関する情報を付加し、ベースラインの移行法に関する仮定を導入する

• 問題点の指摘と対応策の提案– 「テスト」→「設計」→「要求」となる、大幅な手戻りに関す

る問題の指摘と対応策の提案• 基本設計フェーズの導入

• パイロットモデルの開発（基本設計以下を2度行う）

• 設計結果の文書化

• テストの計画、制御、監視

• 顧客を含める

Winston.W. Royce,”Managing the Development of Large Software Systems: Concepts and Techniques”, Proc. of IEEE WESCON, pp.1-9, 1970 (Proc. of 9th ICSE, pp328-338, 1987に再掲)。北陸先端大落水浩一郎

内部利用のための小規模なプログラムを引き渡すための実現ステップ

分析

コーディング

顧客：報酬

プログラマ：創造

内部利用のみ有効


顧客に引き渡すための大規模プログラムを開発するための実現ステップ

分析

コーディング

システム要求

ソフトウェア要求

プログラム設計

テスティング

稼動

大規模プログラムの開発にはさらにいくつかのフェーズを

追加する必要がある


分析

コーディング

システム要求



テスティング

稼動

できれば、開発時のフェーズ間の干渉は隣り合ってる方がよい

残念ながらフェーズ間の干渉は必ずしも隣り合わない


分析

コーディング

システム要求



テスティング

稼動

基本設計

文書システムオーバービュー

データベースとプロセッサー

の設計

サブルーチン記憶の割当

サブルーチン実行時間の

割当

オペレーティングシステム手続きの

記述

プログラム開発に関する制約条件を明らかにするために

基本設計フェーズを導入する


分析

コーディング

システム要求



テスティング

稼動

基本設計１．ソフトウェア要求定義

２．基本設計書（仕様）

３．インタフェース設計書（仕様）

４．最終設計書（仕様）

４．最終設計書（仕様）

５．テスト計画（仕様）

４．最終設計書

（ビルト）

６．操作指示

５．テスト計画（仕様）テスト結果

・・・

少なくとも６つの異なる文書が必要

文書化は最新でかつ完全でなければならない


分析

コーディング

システム要求



テスティング

稼動

基本設計

基本設計

分析


コーディング

テスティング

利用

制約が読み切れない場合は、その部分をまず、仮に実現せよ


分析

コーディング

システム要求



テスティング

稼動

基本設計

テストの前にコードを視覚的

に査読する

すべての論理パスをテストする自律的な

分離したテストグループ

検査プロセスの

計画

品質保証技術を利用する

構成管理仕様保守

テストに関する標準、手順、

ツール

テストを計画、監視、制御せよ北陸先端大落水浩一郎

分析

コーディング

システム要求



テスティング

稼動

基本設計

ＰＳＲ基本設計レビュー

ＣＳＲクリティカルソフトウェアレビュー

システム要求生成

ＦＳＡＲソフトウェア

受理最終テスト


ＣＳＲクリティカルソフトウェア

レビュー


レビュー


レビュー


レビュー


レビュー

公式レビューに顧客を継続的に十分な内容を持って含めよ


分析

コーディング

システム要求



テスティング

稼動

基本設計

ＰＳＲ基本設計レビュー


システム要求生成

ＦＳＡＲソフトウェア

受理最終テスト



レビュー


レビュー


レビュー


レビュー


レビュー

基本設計

分析


コーディング

テスティング

利用

１．ソフトウェア

要求

２．基本設計

３．インタフェース

設計

４．最終設計

４．最終設計

・・・

５．テスト計画

６．操作マニュアル

ウォータフォール

モデル

1．分析とコーディングの前に設計を完了せよ

2．文書は最新でかつ完全

3．可能なら2度行え

4．テスティングが計画さ

れ、制御され、監視されるべき

5．顧客を含めよ

Winston.W. Royce,”Managing the Development of Large Software Systems: Concepts and Techniques”, Proc. of IEEE WESCON, pp.1-9, 1970 .


システム工学の導入

• システム工学は複雑なシステムのコンポーネント設計、仕様化、実装の検証を主な目的としたもので

• 元々はスペース・シャトルのような航空宇宙システムやNATOの指揮制御システムといった、大規模システム構築時に発生する問題を解決するために開発されたものです。

• 上記のようなシステムは、あまりにも規模が大きいため、開発そのものを複数の企業に分散させねばなりません。

• まず、ある企業が元請業者となり、システム全体の設計と統合を担当し、そして、元請業者のシステム・エンジニアが集まってシステム要求を分析し、その後、複数のサブシステムへと分割してシステム設計を行ないます。

マレー・カンター著、村上雅章訳、「ソフトウェア開発管理の要」、ピアソン・エデュケーション、2002．北陸先端大落水浩一郎

Vモデル• Vモデルはドイツ政府関連のソフトウェア開発

工程を規定するために開発された

• Vモデルはウオータフォールモデルをコーディ

ングのフェースで折り曲げた形をしている。結果として、開発仕様とテスト仕様の抽象度のレベルをあわせた表現になっている。

• Vモデルの特徴

– 開発各工程のフェーズとテスト各工程のフェーズは対応している。

– 同じ抽象度で開発仕様とテスト仕様を書くことにより、同じ抽象度で開発仕様とテスト仕様をかくことにより、開発仕様が発注仕様、テスト仕様が受け入れ仕様に対応させ外注によるソフトウェア開発を助ける効果もある。


要求獲得・定義受け入れテスト

基本設計システムテスト

機能設計統合テスト

詳細設計単体テスト

コーディング

Vモデルはドイツ政府関連のソフトウェア開発工程を規定するために開発された。


テストの種類• 単体テストとは、ソフトウェアの基本ユニットの機能を独立にテストすることであ

る。各ニットの細部が多くの場合開発者によってテストされる。単体テストの目的は、個々のユニットの中の論理やデータのなどの誤りを発見することである。

• 統合テストとは、二つ以上のすでに単体テストされたユニットを結合して実施するテストである。二種類の誤りを探す。一つはユニット間のインタフェースの誤りであり、もう一つは個々のユニットでは実現できなかったグループとして実現された機能に関する誤りである。手法としてはトップダウンテストやボトムアップテストなどがある。

• システムテストとは、統合テストが終了すると、システム全体がテストされる。テスト項目の選択には機能仕様記述や要求仕様記述が用いられる。システムテストではEnd-to-Endの機能の誤りがテストされるが、これ以外に、実効効率、信頼性、負荷への耐性、使い勝手、保守性、守秘性などの非機能要求もテストされる。

• 受け入れテストとは、システムテストが終了すると、システムは顧客や利用者に渡される。受け入れテストにより所有権は開発者から顧客や利用者に移る。受け入れテストの目的は、誤りを発見することでなく、正しく稼働していることの確信を顧客に与えることにある。また、開発されたシステムが受け入れ組織の事務や管理の実際にうまく適合するかがテストされる。開発者側での実際の利用者による使用をアルファテスト、利用者側での使用をベータテストとよぶこともある。


要求獲得受け入れテストの実行

仕様記述システムテストの実行

アーキテクチャ設計

統合テストの実行

詳細設計単体テストの実行

テスト活動の開始

システムテストの計画

統合テストの計画

単体テストの計画

デバッギングと変更




コーディング

テスト、デバッグ、変更、再テスト

Wモデル


Vモデルの適用

• システム工学的アプローチの導入

– システム要求を定義する

– システム要求をサブシステムに配分する

– 詳細なコンポーネントを定義する

– コンポーネントを検証する、サブシステムを検証する

• 同じ抽象度で開発仕様とテスト仕様を書く

マレー・カンター著、村上雅章訳、「ソフトウェア開発管理の要」、ピアソン・エデュケーション、2002．


自動車の内部はどのようになっているのか環境

運転手

電子制御装置

バス

ツール

（故障テスター）

車輪速度センサー

ステアリング角度センサー

車輪ブレーキ（アクチュ

エーター）

ブレーキペダル装置

車輪ブレーキ（アクチュ

エーター）

水式調整器

Jorg Schauffele, Thomas Zurawka, “Automotive Software Engineering”, SAE Intnl. 2005.北陸先端大落水浩一郎

電気・ソフトウェア系の設計

乗物レベル

乗物サブシステムレベル

電子制御レベル

マイクロコントローラレベル

ソフトウェアレベルソフトウェアサブシステム

ソフトウェアコンポーネント


車載システム開発法（BMWの例）

構成管理プロジェクト管理

要件管理

サブ契約者管理品質管理

電子乗物システム

支援プロセス

コアプロセス

要件


組込みソフトウェアの開発

システム開発

ソフトウェア開発

ユーザ要求の解析と論理的システムアーキテクチャ

の仕様化

論理的システムアーキテクチャ

の解析と技術的

システムアーキテクチャの仕様化

論理的システムアーキテクチャ

技術的システムアーキテクチャ

ソフトウェアソフトウェア要求の解析とソフトウェアアーキテクチャ

の仕様化

ソフトウェアコンポーネントの仕様化

ソフトウェアコンポーネントの設計と実現

ソフトウェアコンポーネントのテスト

ソフトウェアコンポーネントの統合

ソフトウェア統合テスト

システムコンポーネントの統合

システム統合テスト

校正

受理テストとシステムテスト


後戻りから反復へ

• ミニWaterfall、スパイラルモデルによる反

復（繰り返す、リスク管理）

– 繰り返すことにより、コスト・納期・品質に関するリスクを早期に発見・対応する

• プロトタイピング（取り込む、ユーザの取り込み）

– 繰り返しにユーザを含めることにより仕様の早期確定をはかる


反復モデル

• いくつかの問題を早期に洞察すればするほど、それを修正できる可能性がましていくというのが大規模システム構築における基本原則である（カンター）。

• プロジェクト開始時には、向かっている目標がわからない。インクリメンタルな開発は、一度開発サイクル全体を経験させ、新しく発見した知識をすぐ使えるようにする。プロジェクトには突発事項が待ち構えている。インクリメントによって、そのような突発事項に早く気付くことができ、各インクリメント境界で作業方法を変更する機会が得られる（コーバーン）。

アリスター・コーバーン著、長瀬嘉秀、今野睦監訳、「アジャイルプロジェクト管理」、ピアソン・エデゥケーション、2002．

マレー・カンター著、村上雅章訳、「ソフトウェア開発管理の要」、ピアソン・エデュケーション、2002．


成果物セット

管理セット立案成果物1．作業分解構造（作業の分解と経理調査のメカニズム）2．ビジネスケース（コスト、スケジュール、収益の予測）3．リリース仕様（リリースのベースラインの対象範囲、計画、目的）4．ソフトウェア開発計画書（プロジェクトのプロセスインスタンス）5．リスクリスト

運用成果物1．リリース説明書（リリースのベースラインの成果）2．ステータス評価（プロジェクト進捗の周期的なスナップショット）3．ソフトウェア変更指示データベース（ベースラインに対する個別の変更についての記述）4．導入ドキュメント（カットオーバー計画、トレーニングコース、販売用資料）5．環境（ハードウェアおよびソフトウェアツール、プロセス自動化、ドキュメント作成、追加のトレーニング）

要求セット

１．開発ビジョン説明書

契約提供サービス制約

２．要求モデル

ユースケースモデルドメインモデル

設計セット

１．設計モデル

ソリューション空間の様々な要素

２．テストモデル

３．ソフトウェアアーキテクチャ説明書

実装セット

１．ソースコードのベースライン

２．関連するコンパイル時ファイル

３．コンポーネント実行可能ファイル

導入セット

１．統合製品実行可能ファイルソーコードのベースライン

２．関連する実行時ファイル

３．ユーザマニュアル


反復型モデルの特徴

• 成果物は順番に作成されるのではなく、一緒に開発途上で変更、詳細化し、様々な選択肢が拮抗する中で制約、異なる抽象レベル、自由度のバランスをうまく保つ

• すなわち、従来モデルと異なり、各ライフサイクルフェーズでは、開発作業のワークフローが直線的に進捗するわけでも、成果物の作成がある成果物から別の成果物へと一方向に進むわけでもない。

• 開発活動では、成果物の間を何度も行ったり来たりし、情報の広さと深さの両面でバランスを保ちながら学んだ教訓を生かして、システム全体の記述と開発プロセスを段階的に向上させることが大切である

• 反復とは、ある時点でのアーキテクチャ全体と引き渡し可能なシステム全体の状態をあらわす。一方、追加とは現在進行中の作業をあらわし、それが前回の反復と組み合わさって次の反復を作る。


An iterative development model

Planning

Initial Planning

Requirements Analysis & Design

Implementation

TestingEvaluation

Deployment


細かく切るからよくない。活動を重ねあわせよう！（開発作業の注力レベル）

Walker. Royce著、日本ラショナルソフトウェア監訳、「ソフトウェアプロジェクト管理」。ピアソン・エデュケーション、2001．

方向づけ（アイデア）推敲（アーキテクチャ）作成（ベータリリース）移行（製品）

管理

環境

要求

設計

実装

評価

導入


ソフトウェアプロセスのワークフロー

• 管理ワークフロー：プロセスを制御し、

すべての利害関係者の成功条件を保証する

• 環境ワークフロー：プロセスを自動化し、

保守環境を進化させる

• 要求ワークフロー：問題空間を分析し、

要求成果物を進化させる

• 設計ワークフロー：ソリューションのモデルを作り、

アーキテクチャと設計成果物を進化させる

• 実装ワークフロー：コンポーネントのプログラムを作り、

実装成果物と導入成果物を進化させる

• 評価ワークフロー：プロセスと製品の品質の大勢を評価する

• 導入ワークフロー：最終製品をユーザに移行する北陸先端大落水浩一郎

反復の単位

管理環境要求設計実装評価導入

割り当てられた利用シ

ナリオ

前回の反復の結果

次回の反復に渡す結果


反復の例方向づけ

推敲

management Environment Requirement Design Implementation Assessment Deployment

ビジネスケースと開発ビジョンの用意

開発環境と変更管理インフラ

ストラクチャの定義

利用コンセプトの定義

アーキテクチャのコンセプトの考案

アーキテクチャのプロトタイプのサポート

計画、開発ビジョンプロトタイプの評価

ユーザコミュニティの分析


計画の開発

開発環境

のインストールと変更管理データベースの確立

アーキテクチャ目標の定義

アーキテクチャのベースラインの達成

アーキテクチャの評価

ユーザマニュアルの定義

アーキテクチャのベースラインの達成


反復の例作成

移行


開発の監視と制御

開発環境とソフトウェア変更指示

反復目標の定義

コンポーネントの設計

完全なコンポーネント群の製造

中間リリースの評価

移行資料の用意


導入の監視と制御

保守環境とソフトウェア変更指示データベースの維持

リリース目標の精緻化

アーキテクチャとコンポーネントの精緻化

製品リリースの評価

ユーザへの製品の移行

コンポーネントの保守


活動• 管理：リリースの内容を決定し反復計画の詳細を作成する；開

発チームへの作業割り当て

• 環境：製品/テスト/環境コンポーネントに対する、すべての新しいベースラインと既存のベースラインの変化を反映させるために、ソフトウェア変更指示データベースを進化させること

• 要求：ベースライン計画、ベースラインアーキテクチャ、この反復の終了時点で実証されるユースケースを十分に練り上げるためのベースライン要求セット、評価基準を分析すること；この反復における開発作業の結果として必要になる変更を反映するためのあらゆる要求セット中間成果物を更新すること

• 設計：この反復に割り当てられた評価基準に照らして実証するために必要な設計/テストモデルコンポーネントを十分精密なものにするために、ベースラインアーキテクチャとベースライン設計セット中間成果物を進化させること；この反復における開発作業の結果必要になった変更を反映させるために、設計セット成果物を更新すること


活動• 実装：任意の新しいコンポーネントを開発または入手し、または任

意の既存コンポーネントを機能拡張または修正して、この反復に割り当てられた評価基準を満たすことを実証すること；新しいコンポーネントと修正済みコンポーネントをすべて既存のベースライン（前バージョン）と統合してテストすること

• 評価：反復の結果、すなわち割り当てられた評価基準の判定結果や現在のベースラインの品質といったことを評価すること；必要となる作業のやり直しをすべて特定し、それをこのリリース導入の前に実行すべきか、あるいは次のリリースに回すべきかを決定すること、結果を評価して、後に続く反復の計画の基礎を改善すること。テストは評価ワークフローの一部である

• 導入：事後検討を実施し学んだ教訓を取りこみ次のリリースに反映できるようにしてから、リリースを外部組織（ユーザ、検証および実証作業の独立請負業者、調整機関）あるいは内部の評価組織に移行すること


ＳＰＭのまとめ

• 「規模を制御する」から「変動性、突発性、不確定性を制御する」へ

リスク管理

アウトソーシング、オフショア開発


ソフトウェア開発方法論の発展の歴史（どのような構造を定義し、かつそれを作りこむ手段を定義したのか）

• 構造化プログラミング正しさの確認容易性、作業分担の独立性を保証する構造

• 情報隠蔽モジュール（データ構造の変更波及を局所化する構造

• 構造化分析・設計変更波及を局所化する関数呼び出しの構造

• 要求定義ユーザ世界の活動を抽象し、それをソフトウェア構造に変換するための構造

• 実行可能仕様とフォーマルメソッ– 自動化、検証、証明

構造よりむしろ表現（言語）の問題であるが、数学的記法に則って仕様を記述することにより、特定の性質を検証・証明することを可能にする。

• オブジェクト指向情報隠蔽原理の採用による変更波及の局所化、型の間の類似性の整理による再利用や拡張容易性が達成された。

• ゴール指向要求工学, 統合要求工学, COTS – 納期短縮システムの開発目標とソフトウェア要求をソフトゴールの階層によってつなぐゴール指向要求分析や、仕様の獲得とソフトウェアコンポーネント開発を並行させ、厳しい納期短縮の要求に応えようとする統合要求工学

落水, 「WaterFall Model 再考」．SEAMAIL, Vol.14, No 9-10, pp.32-59北陸先端大落水浩一郎

ソフトウェア工学の原理（それらを抽象したもの）

1. 厳密性と形式性数学的記法で書かれた仕様書をもとに、検証や証明により信頼性を保

証する。2．関心の分離

特定の関心に対応するソフトウェア部分を識別し、局所化し、操作することにより作業の並列化と責任の分担を支援する。

3．モジュラリティ関心の分離の一種であり、機能と特徴を局所化する

4．抽象関心の分離の一種であり、設計目標(what)と設計手段(how)を分離す

る。例えばＵＭＬ図面群はJavaやC++コードの抽象である。5．変更の予期

問題を一般化することにより汎用性のある解の構築を支援する。6．汎用性

解を一般化することにより広範囲に適用できる解を構築する。7．インクリメンタリティ

ソフトウェアを小さなインクリメント毎に作成することで開発上のリスクを軽減する。

落水、北陸先端大「ソフトウェア設計論」講義ノート北陸先端大落水浩一郎

フィーチャ指向

プロダクトライン

オブジェクト

指向(クラス,

継承, 多相性)

補完する

製品系列に拡大する

横断的関心事

局所化する

ＵＭＬ（ビュー）

Whatとhowの分離

機能の表現単位

データ抽象

厳密性と形式性

関心の分離

モジュラリティ

抽象

変更の予期

汎用性

インクリメンタリティ

アスペクト指向

複雑性

適合性

変更容易性

不可視性

Whatの表現

プロセス

ＵＰ，アジャイル

形式仕様記述、証明、検証

モデル検査、定理証明

図２ソフトウエア特有の性質、それを制御する原理、原理を実現する技術の関係

振舞の解析・検証

コンポー

ネント指向

サービス

指向


ＳＤＭのまとめ

• 追究されてきた構造– ソースコードのまとまった箇所に作成・検証・変更の対象があらわれる

– 記述量が少なくなる

• 抽象度の高い構造や振舞いの表現• ビジネスモデルとの連続性

• この分野の発想の原点の一つは、「要望を限りなく取り込み、それを吸収しうる構造を創りだそうとすること」にあるように思える。コンポーネント技術はその典型であろう。この指導原理は本当に有効なのか


ソフトウェア開発プロジェクト管理技術の発展

• 種々のメトリクス– コスト見積り、危険要因の検出、

テスト打ち切り時期の判定

• 測定手段– ファンクションポイント

• CMM– 成熟度とベストプラクティス

• ソフトウェア評価– ベースラインとベンチマーク

• PMBOK – 知識体系の整備

落水, 「WaterFall Model 再考」．SEAMAIL, Vol.14, No 9-10, pp.32-59北陸先端大落水浩一郎

プロジェクト管理技術の発展（もともとは）

• 戦略兵器の開発、ロジスティクスの効率的管理（米国）

• PERT/CPM（1950年代後半）

• 兵器開発の日程管理の改善への科学的手法の導入（アメリカ空軍）オペレーションズ・リサーチチームの結成（1957年）

• PMIの結成（1969年）

• TOC（制約条件の理論）、DBR（ドラム、バッファ、ロープ）、クリティカルチェーン（1980年代後半）

村上、井川、「最速で開発し最短で納めるプロジェクト・マネージメント」、中経出版、2002．北陸先端大落水浩一郎

TOC

村上、井川，「最速で開発し最短で納めるプロジェクト・マネージメント」，中経出版、2002．

制約条件

みつけ、補強する

– 制約条件（ボトルネック、もっとも能力の低い活動）に注目し、それを強化することが重要である

物理的制約：純粋に能力が不足している

方針制約：社内の規定・制度や組織構造などマネージメントの仕組みの中にある制約

市場制約：生産量が伸びない原因が需要不足にある


DBR（ドラム、バッファ、ロープ）

村上、井川，「最速で開発し最短で納めるプロジェクト・マネージメント」，中経出版、2002．

•ボトルネック工程が休止するのを避ける•ドラム：制約条件に生産速度をあわせる•バッファ：時間的な余裕のこと•ロープ：原材料の投入をコントロールする


ソフトウェア計測の必要性

着目点：

市場投入時期顧客満足度経費節減

着目点：

生産性コスト監視作業効率パーフォーマンス

着目点：

ファンクション工数欠陥数スケジュールプロセス遵守ポイント

レベル観測者

第３層上級管理者

第2層中級管理者

第１層プロジェクト

管理者

デービッド・ガーマス、デービッド・ヘロン著、小泉、中村、向井訳、児玉監訳、「ファンクションポイントの計測と分析」、ピアソン・エデュケーション、2002．北陸先端大落水浩一郎

ソフトウェア評価

• 定性的データによって原因を理解し、定量的データでそれを正当化する。

• FPに関する尺度には以下のものがある。

• 生産性に関する指標：FPあたりの費用、IT部門の生産性、開発速度、ユーザが利用する機能と開発された機能

• 品質に関する指標：機能要求の規模、完備性、変更率、欠陥除去率、欠陥密度、テストケースの網羅率、文書量

• 経済性に関する指標：FP当りの費用、補修費率、ポートフォリオ資産価値

• 保守性に関する指標：保守性、信頼性、要員配置、成長率、ポートフォリオ規模、バックファイア値、安定度

デービッド・ガーマス、デービッド・ヘロン著、小泉、中村、向井訳、児玉監訳、「ファンクションポイントの計測と分析」、ピアソン・エデュケーション、2002．北陸先端大落水浩一郎

品質特性(quality charastristics)

品質副特性(quality subcharactristics) 主な内容

機能性（ｆuctionality）

合目的性（ｓｕｉｔａｂｌｉｔｙ）正確性（accuracy）相互運用性（ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）標準適合性（ｃｏｍｐｌｉａｎｃｅ）セキュリティ（ｓｅｃｕｒｉｔｙ）

目的から求められる必要な機能の実装の度合い

信頼性（ｒｅｌｉａｂｉｌｉｔｙ）成熟性（maturity）障害許容性（ｆａｕｌｔ tolerance)回復性（recoverability)

機能が正常動作し続ける度合い

使用性理解性習得性運用性

分かりやすさ、使いやすさの度合い

効率性時間効率性資源効率性

目的達成のために使用する資源の度合い

保守性解析性変更性安定性試験性

保守（改訂）作業に必要な努力の度合い

移植性環境適用性設置性規格適合性置換性

別環境へ移した際そのまま動作する度合い

ＩＳＯ／ＩＥＣ９１２６では、ソフトウェア品質を示す特性に「品質特性」とそれをさらにブレイクダウンした「品質副特性」を定めています。全部で品質特性が６種類、品質副特性が２１種類存在します。


PMのまとめ

• 切るからよくない（ウォータフォールモデル）、重ねればよい（反復プロセス）しかし何かが足りない

• ぎりぎりで人を使いこなすアプローチ（従来のプロジェクト管理）にも無理がある

• 個人やチームの、容量と負荷を考慮する必要がある。


OOAD, SOA and Cloud

Object-Orientation

Service Orientation

WebServices

EAIEnterprise ApplicationIntegration

AOPAspect OrientedProgramming

BPMBusinessProcess Management

Others

ModularDevelopment

ProceduralProgramming

RPCOthers

OO OO OO

SOA

｛｛｛

ITEnterprise

Thomas Erl, “SOA Principles of Service Design”, PRETICE HALL, 2008北陸先端大落水浩一郎

OOAD, SOA, and Cloud• The major benefit of the concept behind cloud computing is that

the average user does not require a compute that is extremely powerful to handle complex database indexing tasks that server farms can

• Instead, with the use of broadband, users can easily connect to the cloud, which would commonly be referred to as the point of contact with the larger network.

• With this point of contact, cloud computing users from all across the world can reap the benefits of enormous processing power without major capital or technical know-how.

• Benefits: Flexibility, Scalability, Capital Investment, Portability• Drawback: Dependability, Security, Little or No Reference

“Cloud Computing – The Complete Cornerstone Guide to Cloud Computing Best Practices”, The Art of Services, 2008北陸先端大落水浩一郎

ソフトウェア工学の誤った使い方

開発チーム＋

ソフトウェア工学

過度な競争

厳しい納期

不足する資金

不足する人員

スキル不足


ソフトウェア工学はチームのキャパを増すための手段である

内部要因

外部要因

SDMs, Language&Environments

プロジェクトマネージャー

チーム結束度、練達度

コミュニケーションと

継続的学習

チームの容量を増加させる

プロジェクトのリスクを早めに読み切る

SPM,PM

デスマーチ

不安定性、突発性、不確実性

現在のゴールは必要条件ではあるが十分ではない。より適切なゴールの設定が

必要

変更や再利用の容易な構造を組み込む

記述量を少なくする関連箇所がまとまる

アウトソーシングオフショア開発分散開発


内容と予定（ - jaist.ac.jp‚ªブジェクト指向とソフトウェア工学.pdf ·...

Documents