基本情報技術者試験
こちらより

内容がまとまったので

まとめて投稿しなおします。

システム開発プロセス/開発モデル

共通フレーム

ソフトウェアの開発者と発注者の間で段取りに対する共通概念を作ること
基本①から⑤まで順番に行います。

①企画プロセス

経営の目的、目標より計画を作成

②要件定義プロセス

必要機能、使いやすさを明確にする

③開発プロセス

要件を詳細にし設計を進め、作成しテストする。

④運用プロセス

システムを導入し、ユーザー教育し継続運用する。

⑤保守プロセス

不具合や諸事情の変化に対応
④に適時行う

⑥管理プロセス

①②③④⑤格プロセスの管理

共通フレームの開発プロセス活動

流れとしては

1,要件定義 : 機能要件の定義
2,方式設計 : 具体的なシステムの構成
3,結合: できた格コード、ソフトウェアの結合
4,適格性確認テスト: 結合からの性能確認

が基本となる流れで
システム(全体)とソフトウェアの開発を合わせる
と下記のとうに順番に行っていく形です。

①システム全体を対象とした作業:初期段階

システム要件定義

システム方式設計

②ソフトウェアを対象とした作業

ソフトウェア要件定義

ソフトウェア方式設計

ソフトウェア詳細設計

コード作成とテスト

ソフトウェア結合

ソフトウェア適格性確認テスト

③システム全体を対象とした作業:完成段階

システム結合

システム適格性確認テスト

ウォーターフォールモデル

下記のように上流工程と下流工程に別れ
①から順番に行っていく形です。

開発の終わりの見通しが立ちやすく
コストや開発期間の見積もりが容易ですが

後戻りを考慮してないので、やり直しの大きなコストがかかってしまいます。

上流工程

①基本計画

ユーザー要求を分析して、
「要求仕様書」にまとめます。

②外部設計

ユーザー側の視点で捉えて設計します。
大まかな機能単位にシステムを分けます。

論理データ設計
入出力設計
コード設計

③内部設計

プログラムでどう具体的にどう実現するか設計します。

物理データ設計
入出力詳細設計

④プログラム設計

内部設計で定義したプログラムを
モジュール単位に分割します。

モジュール

プログラムを組み立てる部品となるソフトウェアです。

下流工程

⑤プログラミング

⑥テスト

下記の順番で行われます。

1,単体テスト
2,結合テスト
3,システムテスト
4,運用テスト

⑦運用・保守

下記のように分類されます。

修正保守
変更(適応)保守
改良保守

⑧レビュー

見直し作業のこと

ウォークスルー: 開発者が自ら説明して意見を求める
インスペクション: 進行役のモデレーターによって進められる
ラウンドロビン: 参加者が持ち回りする

スパイラルモデル

ウォーターフォールとは逆で修正しやすくしたもの

下記の①②③④を4回繰り返して完成させます。

①目標、代替案、制約の決定

②代替案とリスクの評価

③開発とテスト

④次フェーズの計画

プロトタイプモデル

ベータ版とも言われ、ユーザーに試作品を使ってもらい
意見を聞く

アジャイル開発

ウォーターフォールモデルの改良版で
時間の短縮、要求対応、品質向上を目的とした
開発手法の総称です。

下記のような用語があります。

XP(エクストリームプログラミング): 仕様変更は当たり前として、柔軟性やスピード重視
ペアプログラミング: コンビのプログラマが行う
継続的インテグレーション: 単体テストが終わったら、すぐ結合テストをする
テスト駆動型開発: テストケースを事前作成する
スクラム: スプリントと呼ばれる、短い周期で行う。
リファクタリング: コードの整理

リバースエンジニアリング

下流工程の成果物から上流工程の成果物を生成する。

リエンジニアリング

リバースエンジニアリングからの製品より
新たに製品を作ること。

プロセス中心設計とデータ中心設計

プロセス中心設計

基本DFD作成して設計を進めます。

1,業務処理分析

DFD(データフローダイヤグラム)などを用いて
業務やシステムにおける格機能の関係を処理する。

2,機能分析

機能を分割し、詳細化していく

3,機能設計

各機能の仕様を定義する

4,プログラミング

仕様にしたがって実装する

5,テスト

DFD(データフローダイヤグラム),コンテキストダイヤグラム

プロセス間のデータの流れに注目して
システムや業務を分析し、全体像を図式化する方法です。

最初に作成する、大雑把な形をコンテキストダイヤグラムといいます。

使用する、オブジェクトは以下のようにあります、

ターミネータ(源泉/吸収)

データの発生源、行先

プロセス

データに加える処理

データフロー

データの流れ

データストア

データの蓄積

プロセスフロー図

処理の順序を表す流れ図です。

具体的な処理手順(アルゴリズム)は表現しません。

データ中心設計, カプセル化

データベースへ登録したデータにアクセスするための処理を
標準プロセスとして用意します。

また標準プロセスを介してデータにアクセスする仕組みにすることを
カプセル化といいます、

1,データ分析

ER図などを用いてデータを洗い出す。

2,データベースの設計

データ分析の結果をもとにデータベースを設計する。

3,処理の分析

データベースに対して行う処理を洗い出す。

4,処理の設計

洗い出した処理内容を設計する、

5,プログラミング

データベース及び処理を実装する

6,テスト

テストを行う。

オブジェクト指向

データと処理をひとまとまりにして考えます。

オブジェクト指向の概念

オブジェクト

データとメソッドをまとめたもの

メソッド

処理

カプセル化

オブジェクト化(データとメソッドをまとめる)すること

情報隠蔽

メソッドのみデータにアクセスできるようにすること

クラス

オブジェクトの型

インスタンス

クラスより出来上がったもの

クラス間の関係

1.集約-分解関係

全体と部分の関係

2.凡化-特化関係

親子の上下関係

3.スーパークラス、親クラス、基底クラス

2.の上位クラス

4.サブクラス、小クラス、派生クラス

2.の下位クラス

5.インヘリタンス

上位クラスが下位クラスを引き継ぐこと

6.ポリモルフィズム,多様性

メソッド同じでもオブジェクトごとに異なる動作を行うこと。

インヘリタンス(継承)

上位から下位へクラスを引き継ぐため
差分プログラミングするだけで、内容を多様化できる。

オーバーライド(上書き)とポリモルフィズム

インヘリタンスの際に、上位の内容で修正した内容でやりたい場合
下位でオーバーライド(上書き)を行う。

またメソッド(処理)が同じでも
元のクラスが違う場合
結果が異なるのをポリモルフィズムといいます。

例: 計算
計算メソッド呼び出しで

掛け算クラス
割り算クラスだとそれぞれ結果が異なります。

UML

オブジェクト指向による、システム分析・設計に用いる図法です。

ユースケース図

ユーザーから見て、システムがどのように機能するかを表す図です。

クラス図

クラス間の関係を表す図です。

シーケンス図

オブジェクト(インスタンス)間のやりとりを時系列で表す図です。

モジュール分割技法とモジュールの評価

分割方法と独立性(リサイクル性)について書きます。

STS分割

分岐のない、データの流れが一直線の場合使用

S(source: 源泉(入力))
T(transform: 変換(処理))
S(sink: 吸収(出力))
の三つのモジュールに分割します。

TR分割

分岐する場合に使用
分岐元を上位
分岐先を下位とします。

TR(トランザクションの意)

モジュール強度

単体でのまとまりの良さを表す指標

強いほど独立性(リサイクル性)が高いです。

1から順に独立性と強度が高い順に紹介すると
したのようになります。

1,機能的強度

モジュール一つに一つだけの機能

2,情報的強度

同一データから複数機能を個別実行

3,連絡的強度

データフローにより関連する
複数機能を順次実行

4,手順的強度

仕様により関連する
複数機能を順次実行

5,時間的強度

時期の一致する複数機能を実行

6,論理的強度

複数機能の内
引数から一つだけ実行

7,暗号的強度

関係のない機能を実行
定義自体不可

モジュール結合度

モジュール間の密着度を表す指標
弱いほど独立性が高くなります。

結合度が弱い順に紹介すると
以下のようになります。

1,データ結合

構造なしの引数により、データの受け渡しが行われる

2,スタンプ結合

構造ありの引数により、データの受け渡しが行われる

3,制御結合

呼び出し側が制御引数を用いることで
呼び出される側がモジュールの実行の制御に関わる

4,外部結合

構造なしの外部データを共有

5,共通結合

構造ありの外部データを共有

6,内部結合

モジュール間で内容を直接参照

構造について

構造をもつデータ: レコード側のデータ
構造なしのデータ: 変数

テストの概要

単体テスト

モジュール単体が正確に動作するかテストします。

結合テスト

組み合わせで正確に動作するかテストします。
モジュール間インターフェースの整合性についてチェックします。

トップダウンテスト

上位から順に行う
何度も上位はテストすることになるので
上位ほど品質が上がります。
その反面テスト作業を並行して行いにくいです。

スタブ

テスト用の仮の下位モジュール
上位だけだと動かないので

ボトムアップテスト

下位から順に行う
テスト作業を並行して行ええますが。
最終段階にならないと全体の動作テストができません。

ドライバ

仮の上位モジュール

サンドイッチテスト

トップダウンとボトムアップを同時に行う

ビックバンテスト

単体を終えたのを一度に結合して行う。

一斉テスト

単体を省略して、モジュールを一度に結合

システムテスト

設計仕様を満たしているかテストします。

機能テスト

全ての機能が備わっているかテストします。

性能テスト

レスポンスタイム、スループットなど
仕様性能のテストをします。

負荷テスト

障害テスト

運用テスト

実際環境下でテストします。

退行テスト(レグレッションテスト)

変更、更新などで不具合が出ないかテストします。

テスト技法と評価

ブラックボックステスト

入力値と出力値の対応関係が正しいかどうかを検証する手法です。

同値分割

代表となる数値を選んでテスト回数を減らす方法

仕様からデータを“⁠意味のあるグループ⁠”（同値クラス）に分類し，各グループから代表値を選ぶ技法です。

例えば、「20歳未満」という条件で行われる処理があるとき

その箇所を0歳から19歳まで20回テストする代わりに
15歳の場合のみをテストすることで大幅にテスト回数を減らすことができる。

限界値分析

同値クラスの境界値をデータとする手法

境界値分析(限界値分析)は、同値クラスの境界値付近には、バグが集中するという経験則に基づいている。
例えば、入力条件として「0以上99未満」のような範囲指定があるとき、設計書で「以下」と「未満」を取り違えたり
コーディングで「≧」と「＞」の記述ミスを犯したりという誤りが起こりやすい。

出力についても同値クラスの上限値や下限値は
経路分岐やロジックが正しいかどうかが端的に表れるポイントとなる。

ホワイトボックステスト

プログラムの流れを検証する技法

命令網羅

対象プログラム中のすべての命令を必ず一度は実行すること。
また、全命令のうちテストされた命令の割合を命令網羅率という。

判定条件網羅

プログラムの判定条件で
真と偽を少なくとも一回は実行する
ようにテストデータを作る。

条件網羅

プログラムの格条件で
真と偽を少なくとも一回は実行する
ようにテストデータを作る。

判定条件/条件網羅

上記二つを満たすように行う。

複数条件網羅

各条件の真偽の全ての組み合わせでテストデータを作る。

信頼度成長曲線

発見されたエラーの時間による累積推移のグラフ
ロジスティック曲線、ゴンペルツ曲線とも言います。

中盤で多く
序盤と終盤で少なくなります

このグラフと比べることで品質の良し悪しを見ます。

序盤で多すぎると品質が悪く
少なすぎるとエラーを見つけてないと判断できます。