こんにちは
セカンドセレクションのUmeharaです。
前回はソフトウェア開発の大きな流れを確認していきましたが、今回は「ソフトウェア開発工程を詳細に記そう」と思います。
先輩SEを見て学んだことを僕の勉強のために残していきます。皆さんも是非お付き合いください。
システム開発とは
前回の記事（こちら）でも紹介していますが、大きな流れは「設計」「実装」「試験」です。
しかし実際のソフトウェア開発では必要なプロセスをできるだけ細分化します。また各工程ごとに期限を決める（マイルストーンを設定する）ことによって、プロジェクトの進捗具合を管理して開発を進めていきます。
もちろんソフトウェア工程の分け方は企業、受注規模ごとに違いますが、いずれの場合も目的は品質の高いソフトウェアを遅れることなく納品するために作業を分けていきます。
ソフトウェア開発プロセス
計画立案・受注相談
ソフトウェアを導入することで現行業務の効率化ができるのか。
本当に自社のコストカットすることができるのか。
こんな感じのソフトウェアはどのくらいでできそう？
というラフなきっかけから開発需要が生まれるようです。納得していただける企画案ができたら、ソフトウェア開発会社から見積書を提出し、合意できればソフトウェア開発の契約となります。
要件定義
要件定義は非常に難しく、僕はまだまだできないのですが「こんなものこの値段で作って～」というざっくばらんな状態から、おおまかにスペックを決めていきます。
お客様の要望を聞き取り、実装する機能や性能を検討します。
弊社で心がけているのは「誰が」「いつ」「どこで」「どのように」使うのか明確にすることです。
ここを一つでも間違えてしまうと、高いお金を出して作ったけど、結局使わなかった状態になります。（ダイエット器具と同じですね）
インプット
- 企画提案書・プロジェクト計画書
- 既存機能の画面・帳票レイアウト（システムが存在する場合）
アウトプット
- 要件定義資料
- プロジェクト計画書（スケジュールを書いた資料）
要件定義を間違えてしまうと現場に入った後でどこか使いにくさや不適応が起こるので、
必ず「お客様の目線に立つ」ということが大事！先輩を見ていて僕が感じたことです。
設計について
外部設計
ユーザー機能を設計し、システム外部の仕様を確定します。
要件定義書をさらに具体的に落とし込む作業です。
- 画面レイアウト・画面仕様、帳票レイアウト・帳票仕様を確定
- DB設計ではテーブルとリレーション、ファイル設計ではファイルレイアウトまで確定
既存のものがある場合は、本当に必要な機能なのかを再度検討させていただきます。
インプット（先と同じ）
- 企画提案書・プロジェクト計画書
- 既存機能の画面・帳票レイアウト（システムが存在する場合）
アウトプット
- 外部設計書
- 機能設計書
- 画面設計書
- 帳票設計書
- DB設計書
- ファイル設計書
内部設計
ユーザーには実際に見えないシステム内部を設計します。
外部設計書に記述されている内容と重複しない部分、詳細化した部分（イベント仕様やテーブル・ファイルの参照・更新について設計していきます。
一言で言うなら、DB設計やファイル設計の仕様を具体的に確定する。
ユーザーに見える外部設計（デザインやDBとファイル）ももちろん大事ですが、先輩を見ていると「内部設計をどれだけ上手にできるのか」というのがSEの力だと感じました。
※ここは開発規模によっては外部設計と一緒になることもあるそうです。
インプット
- 企画提案書・プロジェクト計画書
- 外部設計書
アウトプット
- 内部設計書
- 詳細設計書（DB、ファイル等）
- プログラム構造設計書
ここまでが「SEにしかできない仕事」の内容です。ここでソフトウェア品質の8割～9割を占めると思います。
研修中、僕は何回も「テストではなく設計こそが品質を決める」と指導していただきました。
設計の参考本
「設計について」知り合いのSEから紹介してもらった本です。紹介だけしておきます。
１）オブジェクト指向でなぜつくるのか
２）はじめての設計をやり抜くための本
実装（プログラミング）
※やっと僕の出番が来ました！
外部設計書・内部設計書の機能をもとにプログラムを実装します。
設計書に基づいて「1つの機能を追加する」こと。これが今僕ができることです。
・設計書に基づき変数名、関数名、処理のカタマリを意識しながら実装しています。
最初は何をしていいかわからない状態でしたが、できることから一つずつやることで少しずつですが道が見えてくるようになりました。
インプット
- 企画提案書・プロジェクト計画書
- 外部設計書・内部設計書
アウトプット
- ソースコード
- フローチャート
※プログラミング勉強方法は3分で学べるドットインストールを使って勉強しましょう。
テストについて
テストは「単体テスト」「結合テスト」「システムテスト」「運用テスト」の4つに分けられます。
ソフトウェア開発ではバグがでることがありますが、それを未然に防ぐため何回もテストでバグを出し、出た箇所を修正していきます。僕（プログラマー）は1日7時間テストをすることもありますが、「お客様のために、良い品質のもの」を提供するため必死になってバグを探します。実際にテストを経験して、必要だと感じたことは「なんの目的でどのバグを調べているのか」です。
これを間違えてしまうとテストで出すべきバグを間違えてしまい、手戻りが発生してしまうので気を付けましょう。（僕も失敗をたくさんしました）
テスト目的は以下のV字モデルを理解するといいと思います。基本は設計に対応したテストを行っていきます。（規模によっても変わります）
単体テスト
単体テストでは、内部設計で実装した機能を一つ残らずテストします。
個々の機能やモジュールが単体で動作するかどうかを検証するテストです。原則、バグが完全になくなるまで、テストと不具合修正を繰り返します。
この時点ではバグが多く出ますが、修正自体はその箇所のみでよい場合が多いです。
結合テスト
結合テストでは、外部設計で実装した機能間の繋がりがある動作を確認していきます。
ただ動作するかどうかをテストするのではなく、操作と機能動作の組み合わせが正しいか、仕様書通りに機能しているかについても検証します。単体テストで正しく動作することが確認された機能やモジュールを対象とし、機能間の連携や一連の機能が仕様書通りに正しく動作するのかを確認します。
総合テスト
総合テストでは、実際の業務や時間の流れに沿って多岐にわたって動作を検証します。
構築したシステムが全体として予定通りの機能を満たしているかどうかを確認するテストです。パフォーマンステストや負荷テスト、障害テストもこの工程で実施します。
開発者側の最終テストになるので要件定義した内容が満たせているかを徹底的に検討して納品します。
運用テスト
お客様が実際の業務や時間の流れに沿って動作を検証します。
開発者側からは検知できないユーザー観点からバグや障害を挙げてもらうテストのようです。
※僕はまだ詳しく言及できません。
インプット
- 企画提案書・プロジェクト計画書
- プログラミングしたソースコード
- 外部設計書・内部設計書
アウトプット
- 各テスト計画書、仕様書、実施報告書、エビデンス、バグ票、バグ一覧
- テスト済みプログラム
システムリリース
システム移行
運用テストが終了し顧客ニーズが満たせたとき、実際の稼働環境（本番環境）へシステムを移行します。ある時点で旧システムから新システムへ一斉へ切り替えを行う「一斉移行」やシステムの機能単位ごとに新システムへ切り替えを行う「順次移行」などの方法があるようです。
インプット
- ソースコード
- 調整前のマスタデータ（システムを使う最初の段階から無いと困るデータ）
- 現行システムのデータ
- 移行プログラム
- 企画提案書・プロジェクト計画書
アウトプット
- 調整後のマスタデータ（システムを使う最初の段階から無いと困るデータ）
- 移行プログラムで生成されたデータ群
運用・保守
「運用」はマシンの起動や停止、現行のシステムを日々動かす作業です。稼働状況のモニタリングやCPUやメモリの利用状況などのシステムリソースのモニタリングも実施します。
「保守」はシステムを改善・変更する作業です。主にシステム障害や改修要望に伴うプログラムやデータの修正を行います。
ソフトウェアにはライフサイクルがあるのでメンテナンスも考慮して、再利用性の高いプログラムを最初に受注したほうが継続的にみると安く済むそうです。
開発工程の手法
ソフトウェア開発工程には2つの開発手法があると研修で習いました。
ウォーターフォール開発(waterfall)
直訳すると「滝のように流れる」開発工程です。
上流（設計）から下流（プログラミングやテスト）へ作業が移っていきます。
メリット
- スケジュールを立てやすい
- 予算やSE（システムエンジニア）の手配がスムーズに行える
- 品質を高くしやすい
リリースの早さよりも、テストを数多く重ねて確実性を求める場合はウォーターフォール型開発が好まれます。現状多くの会社は開発工程にこの方式を使っていると思います。
アジャイル開発(agile)
直訳すると「素早く機敏な」開発工程です。
基本的な開発手順は変わらないのですが、1週間ごとというように短い期間で打合せを行い、ニーズの変化や細かい仕様の変更に応えていきます。
こうすることで無駄な開発人件費を削ることができたり、お客様の要望に逐一対応することができるので、近年非常に注目されています。
アジャイルの本質は、常に改善している状態・より良いものを目指している状態だそうです。
参考記事：https://qiita.com/567000/items/33c8821f014885024577
長文読んでいただきありがとうございました。
2021年よりSSブログの更新中です。ぜひお楽しみください！