こんにちは。
応用情報技術者を勉強しているロペです。
今回の記事では、システム開発技術について書いてきます。
私のいつも、システム開発の仕事をしているので、8章まできて遂に得意分野が出てきました！
なので、業務での経験を交えつつ、いつもよりも分かり易い記事を書けると思います！
なお、この章は以下3つの節に分かれていますが、この記事では開発環境と開発手法について書きます。
・開発環境と開発手法
・要求分析・設計技法
・テスト・レビューの方法
システム開発技術とは
システム開発とは、長く実務をしてきた身としては、
大枠の設計、管理/マネージメント、関係者間の調整が主な仕事かなと思っています。
(なので、広く浅くの知識とコミュニケーション力が大事になると感覚を持っています)
杓子定規に書くと、基本計画、外部設計、内部設計、プログラム設計の工程とそれに対するテスト工程を経て運用されます(V字プロセスという開発スタイルです)。
さらに、運用中のシステムに機能改善や機能追加などの改良を加えながら利用されていきます。
よりよいシステム開発を行うには、各種設計技法やテスト技法を熟知しておく必要がります。それだけでなく、プログラミンやソフトウェアパッケージやツールなどの開発ツールや環境使用できることが望ましいです。
(大規模なシステム開発者になるほど、プログラミングなどソースコードを触ることはなくっていき、できなくても仕事は回っていきますがエンジニアとしては出来るようになっておくことが必須だと思っています)
システム開発の手順
下の図はいわゆるV字プロセスという開発手順になります。
左側の設計部分はトップダウン方式で、右側のテスト工程はボトムアップ方式で行い、それぞれ設計とテストでペアになっています。
要件定義
システムの開発では、まず要件を定義して、徐々に細かい設計に入ってきます。
例えば、洗濯機を設計するとしたら、要件定義は
「汚れものを綺麗にする」、「乾燥できる」とかが挙げられると思います。
外部設計(ソフトウェアの方針設計)
ソフトウェア構造とコンポーネントの方針設計、外部およびコンポーネント間のインターフェースの方式設計、データベースの最上位レベルの設計、ソフトウェア結合のための要求事項の定義などです。
要件定義と同じように洗濯機に例えたら、外部設計は、
ボタンを押したときの状態遷移や信号のやり取りの設計になると思います。
内部設計(ソフトウェアの詳細設計)
ソフトウェアコンポーネントの詳細設計、ソフトウェアインターフェースの詳細設計、データベースの詳細設計、ソフトウェアユニットの要求事項の定義、ソフトウェア結合のための共有事項の更新などです。
要件定義と同じように洗濯機に例えたら、内部設計は、
洗濯、脱水、乾燥みたいな個々の詳細な仕様設計になるかと思います。
テスト
ボトムアップで、まず内部設計に対するコンポテストを行い、外部設計に対するサブシステムの結合テスト、最後に要件定義に対するシステムテストを行います。
開発環境
システム開発における各工程の設計情報をデータベース化することで、システム開発の後半になればなるほど使いまわしになるので自動化ができるのですが、これを支援するソフトをCASEと呼びます。
CASE
CASEとはComputer Aided Software Engineeringの略で、開発や保守作業の自動化を支援するソフトウェアです。
システム開発工程の各種情報は、リポジトリと呼ばれている共通データベースに蓄積して一元管理します(実際に私も業務でリポジトリに保存してソフトを管理しています)
レポジトリで一元管理することで、整合性や完全性のチェック変更に対する影響の分析を自動でできるようになります。
CASEでは全行程で入力したデータと同じ情報を後工程で再度入力する必要なくなり、追加データに関しても差分がチェックできます。
アジャイルソフトウェア開発
アジャイルは最近よく聞く言葉なのですが、迅速な素早いという意味で、効率的な効率的なシステム開発手法の総称です。
競争激しいソフトウェアの開発で、このアジャイル開発は注目を浴びていて、従来から提案されてきたシステム開発技法よりも早くプロジェクトを進めることを目的としています。
プロセスモデルとコストモデル
プロセスモデルは、ソフトウェア開発工程をモデル化したもので、ソフトウェア開発手順の指針の1つです。
コストモデルは、ソフトウェアの生産や品質管理など、費用(工数)を計量化するためのモデルです。
ここでは代表例を書いておきます。
プロセスモデル
ウォータフォールモデル
ソフトウェアの開発工程の段階を上流から下流に向けて作業を進めていくモデルです。
全体像が把握しやすく、プロジェクト管理がしやすい一方で、後戻りが発生すると開発効率が悪化します。
プロトタイピングモデル
システム開発の早い段階でユーザが要求を目で見えるような形で確認できるようにプロトタイプ(試作品)を作成する開発技法です。
私も業務では、このプロトタイピングモデルを使用していおり、効率的に開発ができる一方で開発費用が高くなります(試作費が発生するため)
コストモデル
FP法
プログラムの機能に着目して開発規模を推定する方法です。
ユーザーにとって必要なのは、ソフトウェアのステップではなく、ソフトウェアが出力する情報であるという考え方に基づくものです。
COCOMO
ソフトウェアの開発ステップ数からソフトウェアの開発工数を経験値(過去の統計値)を基に算出する方法です。
以上になります。
第1章から第7章についても書いていますので、もしよければ覗いてみてください。
コメント