# 1.1 開発手法
###### tags: `SD25` `授業ノート`

## システム開発部門の役割 | P.2
### 企業体系と情報システム
企業の永続的存続のためには、情報化も非常に重要な意味を持つ
* 内部情報
企業活動によって発生する情報
* 外部情報
企業を取り巻く環境・社会状況から発生する情報

情報システムとしては...
* 業務処理システム
日常業務の支援・効率化を提供
* 戦略情報システム
企業戦略を達成するために情報を処理・提供するシステム

**これら情報処理システムの開発を担うのが「SE」**
SE　≠　プログラマ

digraph {
  subgraph cluster1 {
     concentrate=true
    a [label="　プログラマ　"] [shape=box]
    sync [label="SE" shape=plaintext ]
  }
}

とはいえ、上図のようにプログラマとしての能力も必要。
システム開発部門が開発したシステムを利用するのは「ユーザー部門」

### 情報技術の発展
過去：プロセス中心のアプローチ
現在：データ中心のアプローチ

　・システム開発部門の現状
1. バックログ（バックオーダー）の増大
→ 依頼を受けているけど、着手できていない状態

1. マルチメディアシステムや大規模システムの増大
→ 単なる文字データだけを扱うのではなく、
　マルチメディアデータを取り扱うことに
　対応しなくてはいけない
1. 保守業務の増大
→ 機能改善・追加・変更などの保守業務も増大

**結果**
* 人手はいつも不足気味
* 社内SEは低賃金
* 派遣（ヘルプデスク）は契約金60％

### システム部門の新たな役割
1. 開発と保守・運用
2. データベース、ネットワークの構築・運用
3. 全社会情報化の企画・調整
4. ユーザーとの連携

**IT業界のDX化**
※　DX（Digital Transformation / デジタルトランスフォーメーション）とは、進化したIT技術を浸透させることで、人々の生活をより良いものへと変革させるという概念のことです。
例えば、銀行口座の開設から取引までオンライン上で行えるインターネットバンキングや、映画や新幹線などのチケット購入をオンライン上で完結できるシステムなど。

## ソフトウェア開発モデル | P.5

### 1. ウォータフォールモデル

* 従来から（古くから）ある手法
* 開発の各工程をいくつものフェーズ（段階）に分けて作業を管理
* 各フェーズを完了させて、次のフェーズへ進む
* フェーズ間は「<span style="color: red">後戻りさせないのが原則</span>」
### 2. プロトタイプモデル

**ウォーターフォールモデルでの問題点**
→ 基本計画段階で、ユーザーの要望の全体を把握することが難しいことが多い
* 設計図や、口頭での説明では理解されないことも多い（理解したフリをしていることも）
* となると、完成品は依頼者の求めていた物と違っていることになる
* これらの問題を解決するためのこのモデル
* プロトタイプ（サンプル、試作品）を作って依頼者に完成品のイメージをしてもらう
* プロトタイプを
* 本開発においては破棄して、本番品を作る
* ベースにして本番品へ拡張していく
　　↑　2タイプの構築手法
* 適用範囲として
* 開発の部分的に適用して開発する
* 開発全体の段階で適用する
**<span style="color: red">メリット</span>**
→ 開発後の大幅な使用変更などの「上流フェーズ」でのミスを予防可
**<span style="color: blue">デメリット</span>**
→ 開発コストがかかりがち……orz
→ スケジュール調整が難しい

### 3. スパイラルモデル🌀🌀🌀🌀🌀🌀🌀🌀🌀🌀🌀🌀
* 設計、プログラミング、テストの工程を、システムの部分単位で繰り返して開発:fire:
* 開発単位が独立している場合に適した手法
* オブジェクト指向型開発にも用いられる

### 4. オブジェクト指向型開発 {}
* 一種のスパイラルモデル
* システムを「オブジェクト」の集合体と見る
→各種の機能を持ったパーツの集合体と見立てる
* 各オブジェクトの「分析→設計→実装」を繰り返していく

### 5. 作業分解構造
* 作成することで得られるメリット
* コスト見積・分析のための資料提供
* 作業構成と範囲、作業責任の明確化
* 各作業単位の実績把握、作業計画の容易化

### 6.工程と工程モデル
* 各工程の構成を時系列的に表現

## ソフトウェアライフサイクル | P.10
* 分析→設計→開発→保守→破棄
* 破棄の後は次期ソフトウェアへ移行

### 1. ウォーターフォールモデルの特徴
* システムを各段階に分けて管理し開発
* 各段階終了時には、各段階毎の成果物の「レビュー」を行う
* 各段階の成果物は、下流の段階へ引き渡し


### 2.基本計画
**現行システムの分析・問題点の洗い出し**
#### 1. システム化計画：基本計画を立てる
→ システム化計画書
#### 2. プロジェクト実行計画：具体的計画作成
→ 開発計画書
#### 3. 要求（要件）定義：要求の詳細な分析・定義
→要求定義書（要求仕様書）
#### 4. 外部設計：見える部分の設計
* 要求仕様の確認
* これを基にサブシステム化や入出力設計を行う
* サブシステムの定義と展開
* 具体的にサブシステムを定義していく
* 画面設計・帳票設計
* 文字通りのことを設計します
* ユーザーに直結する部分で、使い勝手にも影響が大きいです。
* コード設計
* 外部設計レビュー : 外部設計書をレビュー
→外部設計書、外部設計レビュー報告書
#### 5. 見えない（見せない）部分の設計
要求定義、外部設計で求められる内容を具体的に設計する
→ 効率良く実現するための設計
* 機能分割と構造家
* サブシステムをプログラム単位へ分割
* プログラム間でのデータをI/Oを明確化
* 物理データ設計（ファイル設計）
* 最近ではDB設計が主流かも

### 5. プログラム設計
ここまでの成果物を基に、実際にプログラムとして制作するための、各プログラムは「モジュール」単位に分割し、プログラミングはモジュール単位で行われる。モジュール間をつなぐための「インタフェース」の設計も行う。
さらに、テストを行うためのテストケースも設定する

### 6. プログラミング　：　コーディング
実際にプログラムを入力していく
* モジュール設計
* 単体テスト計画
* コーディング
* 単体テスト
→ モジュール設計書 :book:
モジュール設計レビュー報告書
単体テスト計画書
ソースプログラムリスト
ソースプログラムリストレビュー報告書
単体テスト報告書

### 7. テスト
* 単体テスト:モジュール単位
* 結合テスト：モジュール間
* システムテスト：全体的な結合テスト
* 運用テスト:実運用と同条件で行う
→　単体テスト報告書
→　結合テスト報告書
→　システムテスト報告書
→　運用テスト報告書

### 8. 運用・保守
運用が開始されれば、必要に応じて保守作業

## ソフトウェアの再利用 | P.17
効率良い開発のために、既存の仕組みを流用した開発方法
* 部品の再利用
* リエンジニアリングによる再利用
* 車輪の再発明的なこと:car:
* 部品の再利用：部品化方式
→ 標準化がカギ、部品ライブラリと検索システム 部品作成・検索ツールの充実
* リエンジニアリング
<span style="color: red">既存の製品を再利用</span>
・リバースエンニアリング
完成品から使用を導き出す → ソースコードを生成する

<span style="color:blue; white-space: pre;">
> reactのコンポーネント指向のこと？
そっちか
ほへ
多分API的なこと
他の人がつくったことがあるものをまた一から作らないで
使いまわすのがエンジニアの間での常識みたなとこがある
Githubに公開されているものをわざわざ自分で作らないで
そのまま使う的な......
なるほど。。。。npmとも同じか
これバックエンドの話やったななんでもフロントで例えてしまう
</span>

st=>start: はじめ:>https://smoothly-app-3af9f.web.app/signin[blank]
e=>end: おわり:>http://www.google.com
op1=>operation: 操作処理の結果
sub1=>subroutine: サブルーチン(定形手順)
cond=>condition: Yes
or No?:>http://www.google.com
io=>inputoutput: 何らかの入出力処理
para=>parallel: 並行処理
st->op1->cond
cond(yes)->io->e
cond(no)->para
para(path1, bottom)->sub1(right)->op1
para(path2, top)->op1