コンピュータの成り立ちとか、基礎とか理解できればこれから先どんなことをやるにしても理解が早いのではないかと思い勉強を始めました。
キタミ式イラストIT塾 基本情報技術者で勉強させていただいております。
まとめます！
システム開発の流れ
ありがたいことに案件に携わることができていますが(ちなみに私は何もしていないが)
初めて聞く用語ばかりで先輩たちの発していた言葉をメモしてググりながら過ごしています。
ビックリしたのは想像していたよりも多くのことを細かく細かく決め、いろいろなフェーズがあるということ。
確かにしっかり認識合わせをしないと作って欲しかったものと違うものが出来上がってしまいますもんね。
オムライスを作って欲しかったのに「卵で包んだ食べ物を作ってください」だけ伝えたらオムレツができちゃうみたいな。
しっかり「中にご飯が入っていて、それはこういう味付けで、それを卵でこういう形に包んだ食べ物を作ってください」と伝えて写真を見せて、作る前に確認してOKがもらえたら作り始めてってやっていけばオムレツが出てくることはないですもんね。
本を読んで認識を深めることができましたー。
ソフトウェアライフサイクル
企画→要件定義→開発→運用→保守
システムの一生は大まかにこの流れで、運用のフェーズで修正が入ったり保守でメンテナンスを繰り返しながら働きます。
調達
発注することを「調達」といいます。
①情報提供依頼書(RFI)
発注側が最新の技術の動向とか導入事例とかを開発担当に聞く。
②提案依頼書(RFP)
発注側が「こういう要件のものを考えてるから提案してくれ」と開発担当に聞く。
私が一番最初に聞いた知らない言葉はこのRFPでした。
③提案
開発担当が提案依頼書を元に提案をまとめて発注側に提示する。
④見積もり
提案がOKされたら予算を発注側に提示する。
⑤契約
ここでめでたく契約ができます。
なんかここまで頑張って契約に至らないこともあるのかなと思うと大変ですね。
開発プロセス
基本計画(要件定義)→システム設計→プログラミング→テスト→導入・運用
このような流れです。詳しく見ていきます。
①基本計画(要件定義)
求められる機能や性能を洗い出す。
実際に使う人へのヒアリングが重要。
所感ですがここが思っていたよりも何倍も細かく詰めているなーという印象です。
②システム設計
要件定義で洗い出した内容を具体的な画面や処理をどうするかなどシステムの仕様に落とし込む。
(1)外部設計
利用者が実際に使う部分の設計をする。
viewの仕様ですね。
トップ画面がどうとか項目は何が入るとかここのボタンを押したらどこに遷移するとか。
(2)内部設計
開発側の設計をする。
例えばログイン機能があって、そこにはどんな処理があって、どの処理とどの処理がつながっているとか。
(3)プログラム設計
プログラムをどう作るかを設計する。
モジュール同士のインターフェース仕様など。
③プログラミング
ここは分かりやすい。
ソースコードを書いていく作業ですね。
④テスト
単体テスト、結合テスト、システムテスト、運用テストをしていきます。
システムテストと運用テストの内容が被っちゃうんですけど、システムテストはシステム全体を稼働させて動作確認や負荷試験をして外部設計通りに動くかを確認し、運用テストは実際の運用と同じ条件下で要件定義が満たされているかをチェックします。
ちなみに私は何故かテストコードが大好きです。
以上です。
「最初は先輩達の言葉が全然理解できないよ」っていうTwitterやQiitaの情報は間違っていませんでした。