ソフトウェアエンジニアリング

◎ 単語

UML・・・各種の分析や設計段階でのモデル記法。
SLCP・・・もともと異なる文化をもつ顧客と開発会社が、システム開発の一連の流れを同じ視点で理解しコミュニケーションに不自由がないよう策定されたシステム開発に関連する言葉、尺度、手順などの枠組み。

◎ ソフトウェアエンジニアリングとは

☆ソフトウェアの大規模化、複雑化に伴い、品質や生産性の低下が問題になっています。そこでソフトウェアエンジニアリングが提唱されました。
ソフトウェアエンジニアリングとは、プログラム開発を工学として捉え合理的に様々な方法論と開発手法を用いながら、早く、安く、正確に、誰でもプログラムを作成できることを目指す学問です。

まず、はじめにソフトウェア開発の全体像について説明していきます。

◎ 全体の流れ

ソフトウェアの開発の全工程は上図のようになっています。

顧客から要望を聞き、それに対する分析・設計をします。設計書に従い製造(コーディング)を行い、テストをします。顧客に対する受け入れテストが完了すると、開発自体は終了します。場合によっては運用中の保守業務をする必要があります。

開発手法によっては、工程の流れは違いますが、基本はこのような開発工程になっています。このように、時系列に沿って段階的に開発を進めていく手法を「ウォーターフォール型」と呼びます。

◎ 代表的な分析・設計手法

☆まず、上流の工程である、分析・設計手法について解説していきます。

○ システム設計

分析と設計

分析

顧客がシステムに求める機能や性能を、開発するシステムの要件として矛盾なく整理すること。
顧客から要望を聞き出したり、現在の業務の流れを調べてたりして得られた情報を解析し顧客のニーズにあったシステムを明らかにする。つまり何を作るかを明らかにする。

設計

分析によって明らかになったシステムの要件を、どのように実現するか(プログラムにするか)を決定する。どのように作るかを明らかにする作業。

○ 構造化分析と構造化設計

システムの機能をサブシステムやモジュールに分割する。
データの流れを直感的に把握しやすいDFDという図がよく用いられる。

○構造化分析と構造化設計

システムの機能をサブシステムやモジュールに分割する。
データの流れを直感的に把握しやすいDFDという図がよく用いられる。

○オブジェクト指向分析とオブジェクト指向設計

メソッドと属性に分割する。
外部からメソッドを実行して、属しての値を書き換える。

◎ 代表的な開発手法

システム開発を早く、安く、正確に誰でもプログラムを作成するために
必要な考え方。

○ ウォーターフォール型

☆ウォーターフォール型とは、開発手法の中で最も代表的で伝統的な開発プロセスです。開発工程は時系列に沿って段階的に進むと考え分析(要件定義)から始まり、設計(外部設計、内部設計)⇨製造⇨テストと1工程ごと完了していき、受入テストを最後に行って、運用となります。

○ スパイラル型

☆スパイラル型は、ウォータフォール型の段階的なアプローチは活かしつつ、現実の開発に対し、より柔軟に対応できる開発工程が新たに考案され、その中の1つです。

ウォーターフォール型の開発工程の中に、さらに「分析」「開発と検証」「次の計画」「次の目標設定」のフェーズを設けて、それらを繰り返すことによって各工程が正しいか確認しながら、開発工程を進めていきます。

ウォーターフォール型で進めながらPDCAを回していくようなイメージです。

○ アジャイル型

☆アジャイル型とは、ウォーターホール型で行ってきた予想外の変化に対する経験的な対応を体系として取りまとめ、実務的な視点から開発プロセスの見直しが行われたものです。

アジャイル型の特徴は、2001年にAgile Allianceという団体が発表したアジャイル宣言から読み取ることができます。

• プロセスやツールより、個人そのものや個人間の交流を重視する
• 広範囲に渡る大量の文書作成より、きっちり動くソフトウェアの作成に注力する。
• 契約に関わる交渉より、顧客と協調することに重点をおく
• 無理に計画に従うより、目の前の変化へ柔軟に対応する

これにより、変化する顧客の要望を取り入れることができ、素早い開発が可能となります。

図

◎ 基本知識

○ 文書について

○ 用字と用語の統一

　・語尾(である。だ。⇄です。ます。)
　・音引(センサ⇄センサー)
　・句読点( ‘,’⇄’、’ )
　・言語(日本語と英語)
　・平音と拗音(デジタル⇄ディジタル)

最低限の文書

　・要件定義書
　・外部設計書
　・内部設計書

実務上必要な文書

　・システム提案書
　・開発計画書
　・プロジェクト完了報告書

・外部仕様
　　・背景
　　・課題
　　・目的・方針
　　・概要
　　・機能
　　・システム化の範囲
　　・ユーザインターフェース
　　・システム構成
　　・ソフトウェア構成
　　・ハードウェア構成
　　・ネットワーク構成
　　・システムインターフェース

・内部仕様
　　・プログラム構造
　　・データ構造
　　・ネットワーク構造
　　・処理ロジック
　　・メッセージ

・運用
　　・導入・移行計画
　　・運用保守

・共通
　　・作業標準
　　・品質管理
　　・開発環境
　　・工程計画
　　・体制
　　・費用・工数・規模
　　・成果物

・内部用
　　・蓄積技術
　　・提言

○ 外部設計(≒基本設計)

　　要件を実現する方法を技術的に検討するための設計書。
　　システムを外部から見た時の振る舞いや構成を定義する工程。
　　システムをマクロの視点で定義する工程。

○ 内部設計

　　品質の安定したプログラムを製造するための設計書。
　　システムをミクロの視点で定義する工程。

◎単体テスト

☆単体テストとは、関数などの最小単位のプログラムを単体で動かしてみて、詳細設計書通りに動作するか確認するテストのことです。処理ロジックが正しいことを確認するのです。

○ ホワイトボックステスト

　　最小単位のプログラムを単体で動かしてみて、内部設計書どおりに動作するかどうかを確かめる工程。
　・プログラム上のすべての処理を網羅するテストデータの集合を作成し、すべての入力データに対して期待どおりの結果が得られるかどうかを確認する。

○ フローグラフ

　　フローチャートをフローグラフに変換することで、プログラムの処理の流れを分析する道具になる。
　
　ノード・・・円
　エッジ・・・矢印
　パス・・・プログラムに存在する処理の流れの数
　
　ドライバ・・・仮の呼び出し元プログラム
　スタブ・・・仮の呼び出し先プログラム

◎テスト

　結合テストと総合テストのこと。

○結合テスト

　☆結合テストとは、基本設計書(外部設計書)に記述した機能が実現できているかどうかを確認するテストです。単体テストに合格したプログラムを組み合わせて確認します。また、結合テストにはブラックボックステストを採用します。

ブラックボックステスト・・・内部構造には関知せず、入力と出力が正しいことを確認するテスト方法。

結合テスト項目の作成の観点

• 基本設計書(外部設計書)に記述した機能が実現できているかどうか

結合テスト項目レビューの観点

• 基本設計書(外部設計書)に記述した機能が実現できているかどうか
• プログラム間のインターフェースに問題がないか

結合テストのテスト項目数

十分なテストを行うのに必要なテストの項目数の目安は、テスト対象のプログラムステップ数の約1/20です。

○ ブラックボックステスト

　プログラムの内部構造には、関知せず、入力と出力が正しいことを確認するテスト。

　　同値分割・・・有効データと無効データを入力とする。
　　境界値分析
　　エラー推測

○ テスト項目数

　　テスト対象のプログラムステップ数の約20分の1。１万ステップなら500項目。が目安。

　

○ 総合テスト

　システム全体で機能が正しく動作しているか確認。
　要件定義で定めた、機能要件、非機能要件が満たされているかどうか確認。
　本番と同じ環境、あるいは本番に近い環境での動作を確認。
　要件定義書、外部設計書を参照。

　非機能要件・・・性能、障害回復、ログ、保守運用性の要件であり、総合テストで初めて確認する項目。
　機能要件・・・結合試験で全て確認が終了しているが、本番と同じ環境で改めて確認する。

　総合テストでは以下の観点でテストをすることが重要。
　・処理性能
　・過負荷時動作
　・操作応答
　・保守運用機能
　・障害回復性能

○処理性能

　システムの速度や容量に感する項目。
　・データの処理速度
　・入力に対する応答時間
　・取り扱うことのできる最大データ量

○過負荷時動作

　システムが過負荷になった際の振る舞いに関する項目。

○操作応答

　システムの操作方法や応答が要件定義書や外部設計書どおりであること。
　異常操作をしてもシステムが停止しないこと。

○保守運用機能

　データの外部への取り出しや外部からの読み込み、システム稼働状況の表示、故障が疑われる時の診断機能
　システムの運用に必要な各機能が要件定義書どおりであること。

○障害回復性能

　システムに障害が起きた時に、復旧が可能であること。
　システムに障害が起きた時に、回復に必要な情報が記録されていること。
　システムに障害が起きた時に、所定時間内に回復が可能なこと。

○ 品質保証

　テストが十分に行われたことを確認すること。
　・バグ累積曲線
　　バクの発生量を積み上げてプロットしたグラフ。
　　バグがなくなる頃を判断する指標として使用する。

○ 受入テスト

　顧客が要件定義と完成したシステムが要件定義どおりであるかどうかを確認するテスト。
　顧客が納入されたシステムが自社の発注内容を満たしており、希望どおりであるかどうかを確認するテスト。

検収・・・納入された成果物一式が適切であることを確認した、ということ。
デスマーチ・・・不具合の修正点が上流工程にあり、メンバの疲労や集中力不足が原因で、新たなミスを生み、システムが一向に完成しない状態。

◎ 静的解析について

☆静的解析とは、ソフトウェアの解析手法の1つで実行ファイルを実行せずに行なう検証です。コーディングの移行判定のひとつとして使うこともできます。
コーディング時という開発の早い段階でエラーを検出できるため、バグ修正コストを抑制できます。

○ 静的解析ツールの種類

☆実際にどんな解析ツールを使うのか触れていきないと思います。と言っても世の中に存在する静的解析ツールに触れるのは現実的ではないので、代表的(勝手な私目線)なものに限定して触れていきたいと思います。

C++test

cppcheck

参照<>