ソフトウェア・エンジニアリング入門セッション 1: はじめに chart 1-1 このセミナー全体の目的 • 以下について理解するための “きっかけ” を提供する: – ソフトウェアはどういうものなのか， – ソフトウェアは実際にどうやって作られているのか， – 自分のチームのソフトウェア・エンジニアが本当は何をしているのか， – 良いソフトウェアとはどのようなもので、どのように作っていけばよいのか • 「ソフトウェア・プロジェクト管理」セミナーへのイントロダクションの役割を果たす。 chart 1-2 このセミナー全体のアウトライン • セッション1: はじめに – このセッション • セッション2: ソフトウェア・プロセス（過程） – 良いソフトウェアはどのように作るのかを考えます。 • セッション3: ソフトウェア・プロダクト（成果物） – ソフトウェアの成果物、特に記述について考えます。 • セッション4: まとめ – 全体を振り返ります。質問にお答えします。 chart 1-3 このセッションの目標 • ソフトウェアとはどういうものかを理解する。 – 相違点（ハードウェアとの～、ソフトウェア同士の～） – 共通点 – 問題点 • 良いソフトウェアとはどういうものかを考える。 – 品質特性 – 対象ソフトウェアの特徴と要求される品質特性 chart 1-4 このセッションのアウトライン • • • • • • • ソフトウェアとはソフトウェアの多様性ソフトウェアの稼働環境プログラミング言語良いソフトウェアとは何か品質特性ソフトウェアの特徴と求められる品質特性 chart 1-5 ソフトウェアとは • 広辞苑第五版（岩波書店）によれば: – (1)コンピューターのプログラムを抽象的にとらえる呼称。コンピューターの運用に関する手順や処理する情報などを含めてもいう。ソフト。「―工学」「―危機」 • コンピューターのプログラムとは: コンピューターに対して、どのような手順で仕事をすべきかを、機械が解読できるような特別の言語などで指示するもの。 – (2)情報を表現・伝達する媒体とは区別して、情報の内容を指す語。放送の番組や記録された音楽・映像など。ソフト。「ＡＶ―」ハードウェア。 • ここでは、もちろん、(1)の「コンピュータ・ソフトウェア」の意味で使用します。 chart 1-6 ソフトウェア（システム）にもいろいろある • 用途: 社会生活基盤、産業用、医療用、個人用…. • 稼働形態: 機器組込、汎用コンピュータ＋ネットワーク…. • 納入形態: 業者が納入して設定、組み込まれた機器を販売、CD-ROMなどのメディアで販売、ネット上で希望者がダウンロード... • 寿命: 一瞬～数ヶ月～１年～数年～数十年… • バージョンアップ頻度: 毎日1回～年に１回～全くしない – バージョンアップには、欠陥修正と仕様変更がある。 • 主な機能: 制御、通信、事務処理、情報検索、シミュレーション、作業支援… chart 1-7 ソフトウェアの立場にもいろいろある • 他のソフトウェアに対して基盤を提供するソフトウェア – いわゆる「基盤」。OS 、DBMS、ライブラリ等。 • 他のソフトウェアに対して部品として組み込まれることを想定して特定のサービスを提供するソフトウェア – いわゆる「部品」「コンポーネント」。 – 部品の提供形態として、EJB(Enterprise Java Beans)等がある。 • ユーザに対して何らかのサービスを提供するソフトウェア – いわゆる「アプリケーション」「システム」。 – 基盤の上でさまざまな部品を組み合わせて構築される。 • ソフトウェア開発に使用する道具としてのソフトウェア – いわゆる「ソフトウェア開発支援ツール類」。CASEツール。 chart 1-8 ソフトウェアの多様性が増している • コンピュータの高性能化、小型化、ネットワークの高速化等に伴い、ソフトウェアへの期待は高まり広まっている。 • 使われる分野の多様化 • 利用環境の多様化 • 扱う情報の多様化 (動画、感性…） • 利用者の多様化 (視覚等の障害、年齢、言語、文化…) • 要求される品質の多様化 – 極めて高い品質が求められるものから – じゅうぶん（そこそこ）良ければ良いというものまで chart 1-9 同じSWシステムに対する要求も常に変化しているソフトウェアを取り巻くいろいろなものが、互いに影響を及ぼしあっている。ビジネス顧客経済・社会の要請法律、規制ソフトウェアシステム利用者機器・装置ネットワーク他システム部品ソフトプロトコルコンピュータ記述言語基盤ソフトツール標準規格符号化 chart 1-10 例: 文書を編集・印刷するソフトウェア • 個人用のワープロソフト、業務用のレイアウトソフト等 • 扱う対象: 文書、文字列、単語、行、段落、ページ、修飾、図表、画像、位置、大きさ等 – 文書の最も基本的な対象物は文字。文字や文字の集まりをどう捉えるか。 • 基本的には同じ機能を持つソフトウェアでも、何を対象と考え、対象をどのように扱うかで、いろいろと違いが出る。 • ユーザ層やニーズの幅広さ、用途等によって、求められる要件（機能、価格、品質特性等）にも違いが出る。 • 時代や環境によっても、要件は変化する。 – 日本語もタイ語もハングル文字も同一文書で扱いたかったら？ chart 1-11 例: 現金自動預け払い機（ＡＴＭ） • 概要: 窓口を介さずに利用者が入出金等を行える機械 • 扱う対象: お札、硬貨、通帳、カード、口座、金額、ATM内部の各装置、その口座のある勘定系システム等 • 実際には多数のセンサやポートを介して入出力を制御する。 – センサ数: 200余り、ポート出力: 100余り、マイクロプロセッサ15～16、100のタスクを同時実行 [坂本 1996年] • 機能: 入金、出金、残高照会、通帳記入、振込等 • 利用者: 公衆、金融機関の保守担当者 • 他の金融機関の口座とのやりとりをするため、通信手順については業界標準が決まっている。 • 公衆の生活に直結するので、高品質が求められる。 chart 1-12 例: 企業の会計・販売管理等の基幹業務システム • • • • 目的: 会計・販売管理等の企業の業務を支援する。利用者: 業務に精通した者からアルバイトまで扱う情報: 金額、品目等業務に必要な情報。主に数字と文字列。機器構成: 大企業なら、UNIXサーバ、クライアントPC、POS端末等をネットワークで繋げるのが主流。安全および負荷分散のため、サーバは複数設けるのが普通。 • ソフト構成: ERPまたは業務専用ソフト、DBMS、TPモニタ、ワークフローソフト、ジョブ管理ソフト等を利用し、足りないところは SQL等で作り込むという場合が多い。 • 特徴: 一般に、大規模。日本の場合は、企業独自部分の作り込みが多くなることが多く、運用・保守も困難。 • 寿命: 企業がその業務を行う限り、手直ししながら使う(?) chart 1-13 ソフトウェアの稼働環境 • 基本的には、コンピュータ（CPUと記憶装置） – CPUの個数、CPUのアーキテクチャや速度、メモリの容量や速度、外部記憶装置の容量や速度等 • 周辺機器（キーボード、マウス、ディスプレイ、プリンタ等） – インタフェース、速度、解像度等 • ネットワーク – プロトコル、トポロジー、媒体の転送速度や特性 • OS (Operating System) • ミドルソフトウェア (DBMS、TPモニタ等) chart 1-14 OS (Operating System) • OSの３つの役割: 使いやすさの提供信頼性の提供性能保証機能 • OSの２大機能: – 機能マシン提供機能 • 入出力処理の汎用化、ファイルの論理化→機能マシン – 資源管理機能 (ファイル管理、プロセス管理、メモリ管理...） • 資源: CPU、主記憶装置、ファイル（外部記憶装置） • OSの例: – UNIX系, Windows系, MacOS, ITRON, リアルタイムOS系... 参考: 吉澤康文「－IT革命時代の－オペレーティングシステム」, 昭晃堂, 2000年3月, p.1-10 chart 1-15 DBMS (DataBase Management System) • データベースを管理するソフトウェア • データの一貫性／整合性を保証しつつ、データの保管、更新、削除、検索等のサービスを提供してくれるもの • 永続性サービス(persistence service)の一つ • 現在は RDBMS (リレーショナルDBMS)が主流 • RDBは基本的には表(table)ではなく集合を扱う – 挿入した順番で格納されていると思いこんではいけない。 – 集合の中の要素を一意に特定するためのキーが必要となる。 • RDB操作の基本: 集合演算(select, projection, join) • RDBMSにデータを問い合わせるための簡易言語: SQL chart 1-16 プログラミング言語 • 手続きやデータをコンピュータに指示するために、人間が使用する言語。 – 人間が読み書きできるものであること – コンピュータが実行できる形式に翻訳できること • 手続き: – 直列処理、並列処理 – 連接、選択、反復、他への依頼、戻り • データ型: – 基本的なデータ型は何か。内部表現、互換性の問題。 – ユーザが柔軟にデータ型を定義できるか否か – データ型を厳密にチェックするか否か chart 1-17 ソフトウェア・システムで良く起きる問題点 • 開発に時間がかかりすぎる、納期遅延、予算超過... • できたソフトウェアが使えない – 要件分析が悪い、仕様が悪い、設計が悪い、実装が悪い • • • • 安定しない、遅い、使いにくい、正しくない... 大規模・複雑になりすぎて誰も実状がわからない要件や環境の変化に追従できない正しく動いていた（みたい）なのに、あるとき、突然誤動作する… • etc. chart 1-18 良いソフトウェアとは何か • 「顧客の期待と利用者のニーズ」を満たすソフトウェア – 「顧客の期待」とは何か、「利用者のニーズ」とは何か • • • • • • • • 当面の問題を解決してくれること必要な機能を提供してくれること期待通り正しい結果が得られること安全で安心して使えること使いやすいこと気持ちよく動作すること期待やニーズの変化に柔軟に対応できること ….. • 必要なときにいつでも親切にサポートしてくれること chart 1-19 ISO 9126 の品質特性 • 機能性 (functionality) • 信頼性 (reliability) • 使用性 (usability) • 効率性 (efficiency) • 保守性 (maintainability) • 移植性 (portability) 品質特性に関する数枚のスライドについての参考文献: トッパン「ソフトウェア品質向上のすすめ－－新しいソフトウェア開発の標準－－」, ISBN4-8101-8-87-5 原題: Software Quality -- A Framework for Success in Software Development and Support -chart 1-20 機能性 (functionality) • 機能の集合の存在とそれらの規定された特徴の存在をもたらす属性の集合。機能は、明示的または暗示的な必要性を満たすものである。 • 機能性の副品質特性: – – – – – 合目的性 (suitability) 正確性 (accuracy) 相互運用性 (interoperability) 標準適合性 (compliance) 機密保護性 (security) chart 1-21 信頼性 (reliability) • 規定された条件のもとで、規定された期間、その性能のレベルを維持するソフトウェアの能力をもたらす属性の集合。 • 信頼性の副品質特性: – 成熟性 (maturity) – 耐故障性 (fault tolerance) – 回復性 (recoverability) chart 1-22 使用性 (usability) • 明示的、または、暗示的な複数の利用者が使用するために必要とする労力および個々の使用結果による評価に影響する属性の集合。 • 使用性の副品質特性: – 理解性 (understandability) – 習得性 (learnability) – 操作性 (operability) chart 1-23 効率性 (efficiency) • 規定された条件下でのソフトウェアの性能レベルと使用する資源の量との間の関係に影響する属性の集合。 • 効率性の副品質特性: – 時間効率性 (time behavior) – 資源効率性 (resource behavior) chart 1-24 保守性 (maintainability) • 仕様化された改訂を行う上で必要な労力に影響する属性の集合。 • 保守性の副品質特性 – – – – 分析容易性 (analyzability) 変更容易性 (changeability) 安定性 (stability) 試験容易性 (testability) chart 1-25 移植性 (portability) • ソフトウェアをある環境から別の環境へ移す場合の能力に影響する属性の集合。 • 移植性の副品質特性 – – – – 環境適応性 (adaptability) 設置容易性 (installability) 規格適合性 (conformance) 置換容易性 (replaceability) chart 1-26 ソフトウェアの特徴と求められる品質特性 • たとえば: – 信頼性はほとんどのソフトウェアで重視されるが、人命に関わるシステムや公共性の高いシステムでは特に重視される。 – 寿命が長ければ、保守性や移植性が重視される。 – 制御系なら、一般に信頼性と効率性が重視される。 – 制御系で使用性が悪ければ、操作ミスによる大惨事や、売行き不振の原因ともなる。 – 流行に左右されるものならば、安く早く作れることが最も重視され、使用性、機能性、効率性も重視される。 – シミュレーションシステムなら、シミュレーション方法（の改良）、結果の正しさ、速さ、わかりやすさが重視される。 chart 1-27 良いソフトウェアはどのように作ればよいか • セッション２で考えましょう chart 1-28