Chapter1 ソフトウェア開発基礎知識
構造化
プログラミングの制御構造(処理の流れ)を簡素化して明確にすると考える方法論です。
管理技術
プロジェクト管理、要員管理、予算管理、工程管理、品質管理、構成管理、計算機資源管理など
オブジェクト指向
現実で存在している物の特徴をそのままプログラ化する。
UML（Unified Modeling Language）
アジャイル開発モデル
素早い開発が可能な手かた手法です。
開発における分析と設計
- 分析
分析とは、システム開発を依頼した顧客がシステムに求める機能や性能をこれから開発するシステムの要件として矛盾なく整理することを意味します。 - 設計
設計とは分析により明らかになったシステムの要件を、どのような形で、プログラムにしていくか、を決定する。
構造化分析と構造化設計
全てのシステムは、それより小さな要素の組み合わせて構成され、その要素も、またさらに小さい要素の組み合わせて構成される。
大規模のタスクを小さく分割してすること。
開発の工程と成果物
開発プロセス
- 要件定義・要求定義
実装するべき機能
要件定義書
- 設計
実装しなければならない機能の仕様
様々な図や表など、ドキュメント（設計書）
上流工程
下流工程
-
製造
-
テスト
開発モデル
- ウォータフォール型
段階的に進む
前に戻らない
要件定義・外部設計・内部設計・製造・テスト・運用
問題
- 最後のテストまで、不具合は見つからない
- 不具合に関する作業は無駄になる
- 遅れた工程は、他の工程の進行に影響がある
- スパイラル型・プロトタイピング
分析、開発と検証、次の計画、次の目標設定のフェーズを設け、それらを繰り返すことによって各工程が正しいかどうかを確認しながら、まるで渦のように進めています。 - アジャイル型
ウォータフォール型で行ってきた予想以外の変化に対する経験的な対応を体系として取りまとめ、実務的な視点から開発プロセスの見直しが行われました。
XP(Extreme Programming) スクラム
イテレーション
ユーザストーリ
基本的なルール
作業の標準化は必要です。チームメンバーが変わったでま運用・保守がでいまる。
用字と用語
理由：統一して、誰でも読める。
| 分野 | 読点 | 句点 | 音引き |
|---|---|---|---|
| 企業 | 、 | 。 | 企業より |
| 学会 | , | . | しない |
| JIS規格 | , | 。 | しない |
| 書籍 | 、 | 。 | 書籍より |
SLCP
要求定義 企画
要件定義 要件定義
外部設計
内部設計
製造 開発
テスト 単体テスト 結合テスト 総合テスト
チャット記法
UML
オブジェクト指向に基づいてオブジェクトをモデル化するための方法。
| 区分 | 名称 | 概要 |
|---|---|---|
| 構造図 | クラス図 | システム内のオブジェクトの関係の静的な関係 |
| オブジェクト図 | ある時点で、システムに存在しているインスタンス | |
| パッケージ図 | オブジェクトをグループ化するパッケージと依存関係 | |
| 配置図 | ハードウェアとソフトウェアの物理的な位置 | |
| コンポジット図 | クラス内部をさらにクラス分解することより内部構造の階層的な表現 | |
| コンポーネント図 | システムで用いるコンポーネント | |
| 振る舞い図 | シーケンス図 | オブジェクト間のメッセージのやり取り |
| ユースケース図 | ユーザとシステム間の典型的なやり取り | |
| 状態マシン図 | システムやオブジェクトの状態 | |
| アクティビティ図 | 処理ロジックや業務など。フローチャートと似ている | |
| コミュニケーション図 | オブジェクト間の関連性 | |
| 相互作用図 | アクティビティ図とシーケンスずを組み合わせたもの | |
| タイミング図 | システムの動作やオブジェクトの状態を時系列に沿って表す |
DFD データフロー図
業務やシステムにおけるデータの流れを表現する記法
Chapter3 開発プロセスと要求定義・要件定義
- 要求定義
顧客の要求を見定める工程 - 要件定義
先に出てきた要求定義を基にして、顧客が専門家であるシステム開発企業の協力を得たりしながらシステム化すべき項目、つまり要件を整理する工程
区別を簡単に理解したほうがいい。
- 機能要求
システムに求められる処理機能 - 非機能要求
システムが兼ね備える(かねそなえる）べき条件 範囲は広い
システム提案書
- システム化によって、解決しようとする問題
- システムの機能
- システムの構成
- 開発に必要な日数
- 開発に必要な費用
RFP要件定義書Request for Proposal 顧客からの提案書募集
要件定義書の手順
- 要求定義書の内容をしっかり把握する
- 要求定義書の内容をシステム化することを想定し、重複する機能を削除する。不足の機能を追加する
- システム化した際の、機能間の矛盾を確認する
- どの機能までをシステム化するかというシステム化の範囲を決定する
- 要件定義書としてまとめる
利用者の情報を入力・編集・削除->利用者の情報の管理機能
| 記述項目 | 内容 |
|---|---|
| 背景 | ・ |
| 課題 | ・ |
| 目的・方針 | ・ |
| 概要 | ・ |
| 機能 | ・ |
| システム化の範囲 | ・ |
| ユーザインタフェース | ・ |
| システム構成 | ・ |
| 導入 | ・ |
| 運用・保守 | ・ |
| 用語定義 | ・ |
| 工程計画 | ・ |
| 体制 | 開発を進める際の人的体制や作業環境など |
| 成果物 | ・ |
| 作業標準 | ・ |
| 品質管理 | プログラムをテストする方法や、バグ発生の収束を判断する指標 |
バージョン
X.Y版
0:社内検討中
1~:正式版
Chapter4 設計
外部設計
外部設計とは、システムが持つ機能や性能、あるいは構成など、システム外部からの見たときのシステムの振る舞いや構成を定義する工程です。
つまり、プログラムの書き方を考えず、システムが持つべき機能を定義する
外部設計手順
業務フローの作成（DFD）→サブシステムへの分割→画面レイアウトや帳票ライアウト→コード設計→論理データ設計（ER図・CRUD図）→システムインタフェース設計→外部設計書としてまとめる→レビュー
ER図
エンティティ・属性・リレーションシップ
エンティティ：現実に存在しているものの実体
CRUD図
- C Create生成
- R Refer参照
- U Update更新
- D Delete削除
外部設計書の記述項目
- 目的・方針
- 概要
- 機能
- ユーザインタフェース
- システム構成
- ソフトウェア構成
- ハードウェア構成
- ネットワーク構成
- システムインタフェース
内部設計
定義：外部設計書を基にプログラムの内部データを決定するなど、システムの具体的な実現方法を定義する
構造化設計について
- メリット
目的に応じたわかりやすい視点からシステムを展望できる点です - デメリット
設計が機能に注目して行われ、データに配慮が薄いため、データの重複や不整合の状況ある
内部設計書の作成手順
画面の詳細設計->帳票の詳細設計->外部インタフェースの詳細設計->処理ロジックの詳細設計->リクエスト処理の詳細設計->メッセージの詳細設計->物理データ設計->内部設計書としてまとめる
処理ロジック
機能仕様のロジックをプログラミング可能なレベルまで詳細化します。
外部設計書の記述する項目
- ユーザインタフェース
- プログラム構造
- データ構造
- 処理ロジック
- メッセージ
- システムインタフェース（外部システムとやり取りするデータの形式、分量、頻度など）
- ネットワーク構造
内部構造設計書はプログラムを製造するために必要な情報をすべて記述しなければなりません
Chapter5 製造とテスト
ソースコードレビュー
- 規約に沿って書いているかどうか
- 正しいロジックで書いているかどうか
単体テスト
関数や手続きといったプログラム単体の品質を確保するために行う。
コーテイング規約
- プログラムの冒頭に付けるコメントの記述ルール
- 変数名の付け方や宣言方法に関するルール
- プログラムロジックの記述ルール
- 変数の型のルール
規約の例
dataCount = 0; //データ数カウンタを初期化する
dataCount = 0; //dataCountを0にセットする
/*初期化と０にすること、意味は全然違います*/
単体テスト
ホワイトボックステスト
単体テストとは：関数や手続と言った最小単位のプログラムを単体で動かしてみる
ホワイトボックステストとは：プログラムの内部構造がわかっていることを前提とする
- メリット：網羅的にテストできる
- デメリット：プログラムが複雑になればなるほど、テストデータの作成が難しくなる
フローグラフテストデータ
ドライバとスタブ
- ドライバ
他のプログラミングから呼び出される - スタブ
他のプログラミングを呼び出す
ケースを設計
• 命令網羅
– すべての命令を最低1回は実行
• 判定条件網羅(分岐網羅)
– すべての分岐を最低1回は実行
• 複数条件網羅
– 条件がとりうる真偽値すべての組み合わせを網羅するテスト
テスト工程
- 結合テスト
- 総合テスト
結合テスト：
プログラムを組み合わせて動作を確認する（主にブラックボックステスト）
総合テスト
要件定義書、外部設計書の内容が実現できているかどうかを総合的に確認する
ブラックテスト技法
| 技法 | 説明 |
|---|---|
| 同値分割 | データをグループ分けし、各グループから一つまたは複数のデータを抽出したものをグループを代表するテストデータとする |
| 境界値分析 | 有効と無効の境界データを取り出してテストデータとする |
| エラー推測 | 経験的に知っているエラーが起こりやすパターンからテストデータを作る |
総合テストのポイント
| 1 | 2 |
|---|---|
| 効率性 | 適切な応答時間で反応するかどうか |
| 保守性 | 保守しやすさ |
| 移植性 | 異なる環境でも使えるか |
| 障害抑制性 | 障害発生の防げるか |
| 効果性 | 投資効果は十分か |
| 運用性 | 品質目標をクリアしているか |
| 技術要件 | 開発標準は適切か |
受け入れテスト
顧客が行う
上流工程の不具合なら、やばいです。。。。。。。。
Chapter6~7 アジャイル開発
QCD
- Quality
- Cost
- Delivery
システム開発の難しさ
１：ユーザの要望を把握しにくい
２：詳細な仕様を決めるこたは難しい
３：正確な要求を相手に伝えること難しい
４：品質の確保が難しい
重要：２番の例
二つの数字の積を計算して表示する
A X B = ？ 計算ボタン
ただ
- 数値を入れずにボタンを押した場合は？
- 入力する数値の範囲は？
- 入力する文字は半角？全角？
- 計算後に入力した数値は消すか？消さないか？
- 数値以外の入力があったとき、エラ〜メッセージは？
- 利用状況はログとして残すのか？ログの処理方法は？
- サイズが異なる画面で見た時の表示方法は？
- 任意のコードを入力欄に入力して実行できないようにしているか？