応用技術者試験の進捗報告　#0

資格取得勉強の進捗報告いきます。
今勉強中なんで、勉強終わったら編集でまとめるんでヨロシク

【復習】
先日やったのは、システム開発の分野。
あやさとはシステム開発を生業にしている（ﾄﾞﾔｧ）のだが、会議で上司や先輩方の言っている専門用語が普通にわからないことがあるため、この分野を一番初めに勉強することにした。
意識高い系とかではなく、ITでは専門用語を理解している前提でナチュラルに使用してくるので、ITに行く人は入社前後でそれなりのITリテラシーを理解しておく必要がある、さあいこう。

システムは作られてからシステム終了までの一生を
企画→要件定義→開発→運用→保守　の過程を経て過ごす。これをソフトウェアライフサイクルという。
先ほどあやさとも言ったように、かなり専門性が高い仕事なので、そこでの用語や作業内容に対する齟齬が生まれると、発注先もしくは受注先が不利益を被ってしまう可能性があるわけですね。それを避けるために、用語や作業内容は共通フレームというガイドラインが定められました。

共通フレーム2023

システムを発注する側は、作ってほしいシステムの目的や現在の業務内容などを記したRFIを作り、受注側はそれを参考に最近の事例などを挙げて「こういうシステムにしたらいいと思います」と提案。
その後にRFPという、作ってほしい内容とその予算を出します。それをうけた受注側が見積書を出し、それを発注側が受ければ合意。

見積もりの出し方は主に2種類あり、
・プログラムステップ法・・・手を加えるコードの行数から、会社の基準となる行数と照らし合わせて予算を算出
・ファンクションポイント法・・・画面の数、入出力の数に難易度を点数化したものを掛け算して、それに独自の係数を加えたものを予算として算出する

主な開発方法は、３つ。
・ウォーターフォールモデル・・・要件定義→外部設計→内部設計と順番にやっていき、その分進捗の進み具合がが分かりやすくなるが、機能が発注側の意図と違ったりすると直すのがとても大変（あやさとの案件は今これ）
・プロトタイピングモデル・・・要件定義後、設計する前にプロトタイプ（試作品）を作り、レビューを聞いて修正をするという事を繰り返した後に作る手法、要望がエンドレスになったり、工数がかかったしまったりする。
・スパイラルモデル・・・システムを「サブシステム」に分け、それぞれのサブシステムを要件定義→外部設計→内部設計→製造→テストをして1つ終わらせ、次のサブシステムを要件定義から・・・と少しずつ確実に終わらせるスタイル。サブシステムのレビュー結果は、次のサブシステムにも反映される。

ここで唐突にソースコードを機械語に表示する方法を2種類ご紹介します。
・コンパイラ方式・・・いったん全部機械語に翻訳
・インタプリンタ方式・・・随時翻訳しながら進める（一個一個？）

開発作業の各工程ではレビューという成果物の検証が行われる。レビューの種類は
・デザインレビュー（要件・外設・内設）
・コードレビュー
このレビューの実施方法が色々あって、これがまた名前が覚えにくい。
・ウォークスルー・・・どうやら仲間内の検査の事らしい。開発した人が主体となって、プレゼン的な感じで紹介していって、レビューする人は内容を理解するとともに指摘もしていく・・・のかな？
あやさとの今の案件がこんな感じ、ウォークスルーあやさととお呼び。
・インスペクション・・・ウォークスルーとは違って第三者（モデレータ）が責任者となってレビューをするという手法らしいです。
・ラウンドロビン・・・参加者全員が持ち回りでレビューする・・・意味が分かりかねますがメンバーの実力が同程度で、指導者的存在が特にいないときにこの手法を用いるみたいです、へぇ・・・

そういったソフトウェアのプロセスを評価し、どれだけ体系化できているかの成熟度を判断したものがCMMIという。うーん覚えにくい。
コンマミリミリ1センチでも成長する、と覚えましょう（？）

そんなシステム開発を図表にしたりしてわかりやすくしてくれる支援ソフトウェアツールをCASEツールという・・・そうですか（諦）
大学で使ったUMLとかいうフローチャート作れるあれがそうみたい、へぇー

P.S
今日会社の人たち（部長と先輩）に誘われて他会社のフットサルに参加したのだが、やっぱりみんなうまくてヘコむあやさと。
いいもん、おれは仕事に生きるもん（ドへこみ中）