引き続き、自学用のメモです。
試験日
2020年4月第三日曜日.
前回
メモ
システム開発技術
先日「レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス （David Scott Bernstein 著, 吉羽 龍太郎 翻訳)」を購入し読みすすめている途中です. 試験範囲を理解すると同時に, 実際の場面でのテストや進め方も調べていきたいと思います.
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
開発の工程
- 工程(システム開発ライフサイクル)
- プロジェクト計画立案：大まかな観点を生成し、目標を定める
- ソフトウェア要求分析：開発の必要な機能を分割
- システム設計と仕様記述
- ソフトウェアアーキテクチャの規定
- 実装：各機能のコーディングとテストを行う。
- 成果物の評価：外部に委託した機能や開発が仕様を満たしているか・受け入れるかを評価する＋開発したものが仕様を満たしているかを評価する。
- 文書化：将来的な保守点検と改良のために、内部の仕様やインターフェースをドキュメントにして整理する。
- 保守・点検：システムの改修とアップデートをくり返す。
要求分析・設計
機能的な要求を形式的な要求モデルに当てはめて記述する
- 機能階層モデル
- データフローモデル：ソフトウェアの入出力の観点からモデルの要求を分析
- ERモデル
- 有限状態機械モデル
- 抽象データモデル
- オブジェクト指向モデル：データ構造にある共通の特性を、クラスによって記述する
- ペトリネット：《ペトリネット》 - ORWiki
.. 非同期的でかつ並列的にふるまうシステムに対して, その中の情報の流れや制御を記述し解析するために考えだされた ..
UML(統一モデリング言語)
- オブジェクト指向モデルの分析・設計のために用いられるモデリング言語。UMLに用いる図は主に構造と振舞図の二種類に大別される。
- 構造図：システムの静的な構造を示す
- 振舞図：システム動作の動的な変化を示す
詳細割愛。応用ではあまり詳しくは聞かれないと想定しているので、上記サイトに目を通すだけで十分かと考えています。
参考文献
開発・開発環境
- CASE | IT用語辞典 | 大塚商会
システム開発を支援するため、設計や開発、改修などの工程でソフトウェアを利用すること。
開発モデル・方法論
- スパイラル
- Vモデル
- ウォーターフォール：要件定義→設計→実装→試験→本番環境での動作を各ステップ一回のみ行うモデル。もっとも古典的で広く使用されているが、後段で問題が発生した場合は手戻り・原因特定に時間を要する場合もある。
- アジャイル開発：短い期間での反復を繰り返すことでリスクを最小化する開発手法の総称。反復型よりもより発生した変更に速く対応することが主眼になっている。
- エクストリーム・プログラミング ：XP (エクストリームプログラミング) - Qiita
- ユーザー機能駆動開発 ：５つの基本活動を反復的に繰り返す。活動は機能価値（feature）ごとに行う。
- ダイナミック・システム開発メソッド
- スクラム：スクラム (ソフトウェア開発) - Wikipedia
- かんばん
- Scrumban（スクラム＋かんばん方式）
- RAD(Rapid Application Development)
- クリーンルーム：バグを予測することが主眼にある、ソフトウェアの信頼性を保つ開発モデル。
- 反復
- ソフトウェアプロトタイピング：ソフトウェアプロトタイピング - Wikipedia
ベストプラクティス
- ペアプログラミング
- テスト駆動開発
- behavior driven development(BDD)：要求する仕様に近い振る舞い・期待する動作をコメントに記述しながらテストコードを記述する。
- テストコードの可読性が向上する
- テストと仕様が近い存在になる
- 継続的インテグレーション
- ビルド・テスト・リファクタリングなどを継続的に実行する習慣が結果的には短期の開発に繋がる。
- Domain-driven design（DDD）：ドメイン駆動設計 - Wikipedia
テスト
テストには開発・品質・受け入れ側視点などの誰が何を確認するためのテストかで細かく分類される。
開発中のテスト
- 単体テスト：単体機能・関数やクラスごとのテスト
- 結合テスト：複数システム間での連結が正常に行えることの確認テスト
- システムテスト：システム全体が正常に動くことの確認テスト
- ソフトウェア適格性確認テスト：ソフトウェア要件定義で定義した適格性要件に従ってテストを実施、要件どおりの動作をしているか検証。
- テスト結果の評価：テスト実施後にプログラムの修正箇所や文書の修正箇所を確認・実施する。
- トップダウンテストとボトムアップテスト
システム発注側
- 受け入れテスト：納品されたソフトウェアが仕様を満たしているかを確認するテスト、検収テストとも呼ぶ。
- 検証テスト：仕様に合致しているかのテスト
- 適合テスト：OSなどソフトウェアが動作するプラットフォームに適合しているかをテスト
- 妥当性確認テスト：ユーザーが意図している動作をするかどうかのテスト
品質確認
- 機能テスト
- 性能・負荷テスト（ストレステスト）
- ユーザビリティテスト
- 正常系・準正常系・異常系のテスト
- 正常系：想定されうるデータ・使い方が正しく動くことのテスト
- 準正常系：想定はしていないが仕様に決められた異常ケースの対応ができていることを確認するテスト
- 異常系：仕様で指定されていないデータでのテスト
テストケース作成方法
内部のコードを見てテストをするかどうか
- ホワイトボックステスト：プログラムが期待した論理に基づいて動作しているかを、内部の制御パスを見ながら確認する。テストで通過した制御パスの範囲はカバレッジ率として求められ、テスト品質の指標の一つになる。
- ブラックボックステスト：ソフトウェア内部での制御やデータ内容を見ずに、様々な入力に対する動作・出力を見てテストを行う。
同値クラスによるテスト
- 同値クラス＝仕様上類似するデータ集合のまとまり
- 同値分割テスト
境界値分析テスト
制御パス・状態の変化によるテスト
- デシジョンテーブル（決定表）
- 因果グラフ
- 状態遷移テスト
- 命令網羅 (statement coverage) (C0)：すべての命令を実行
- 分岐網羅 (branch coverage) (C1)：すべての分岐の方向を実行
- 条件網羅 (condition coverage) (C2)：全ての条件分岐で、全ての可能な判定条件を網羅する
- 複合条件網羅
- 経路網羅：全ての制御パスを網羅するテスト
テスト代替
結合相手や下位のクラスが作成されていない状態で仮のテストを行うために、テスト対象のプログラムを呼出す・利用するための仮のプログラムを作ることがある。 このようなプログラムをテストドライバ・テストスタブと呼ぶ。
テストスタブ
参考文献
