開発技術 - 13.ソフトウェア開発管理技術 - 1.開発プロセス・手法 - 1.ソフトウェア開発手法

Last Update : April 16 2021 23:31:51

     

a. ソフトウェア開発モデル

ウォータフォールモデル
開発作業の全体を複数の作業工程に分割し、その工程ごとに作業を完了させ、進めていく手法です。
上流から下流へ一方通行で作業が進んでいきます。

  1. 一つの作業工程が完了してから、次の工程へ移るため、進捗管理や工程管理がやりやすい。
    大規模な開発プロジェクトに向く。
  2. 途中での仕様変更はやりにくい。
  3. 原則、上流へ戻ることはないが、それを行うときには、影響が多く修正に時間と費用がかかる。

スパイラルモデル
これは、開発工程を何回か反復することでシステム開発を進めるモデルです。つまり、「システムの独立性の高い部分に分解して、その部分ごとに設計、プログラミング、テストの工程を繰り返します」。ウォータフォールモデルとプロトタイピングモデルの2つの長所を生かしたモデルです。

プロトタイピングモデル
システムの試作品(プロトタイプ)を作成してユーザに提供する。これにより、ユーザ要求を明確化でき、隠れたユーザ要求を洗い出すことが可能となります。
「要求のプロトタイプ」(ユーザの評価・修正)
「設計のプロトタイプ」(ユーザの評価・修正)
「システムのプロトタイプ」(ユーザの評価・修正)
「テスト」
上記のように各工程でプロトタイプを作成して、ユーザの評価を得て、必要ならば修正を行います。

RAD
Rapid Application Development の略。GUIを利用した画面の作成や自動プログラミング機能などの開発ツールを利用して、短期間でソフトウェアを開発する手法。
つまり大雑把にいうならば、多くのソフトウェアに共通している処理を担うソースを書かなくても自動的に実装してくれるのがRADツールであり、プログラマーは個々のソフトウェアに必要な固有の機能を担うソースだけを書けばすむのである。 これによって結果的に開発が容易になる。 RADツールを用いた開発の一般的なデメリットの傾向としては、開発されたソフトウェアの動作速度が遅くなる、あるいは実行ファイルのサイズが大きくなる、などが挙げられるが、これらは開発ソフトによるので、全てにあてはまる性質ではない。 またGUIの設計以外の作業が多いソフトウェアを開発する場合、RADの持つ長所を十分に発揮できない。

ソフトウェアプロダクトライン
ソフトウェアをドメインと呼ばれる小さな単位に細分化して開発する手法。多くのプロジェクトでこのドメインをソフトウェア部品として扱い再利用する。全体としての生産性、開発効率、品質の向上などが期待できる。組み込みソフトウェアなど類似の仕様で多数のソフトウェアを少数生産しなければならない場合に有効な手法である。
ソフトウェアプロダクトラインは再利用可能なソフトウェアの「部品」であるドメインを開発する「ドメインエンジニアリング」、ドメインから製品であるソフトウェアを開発する「アプリケーションエンジニアリング」、ドメインに関する情報を管理する「管理」の3段階から成り立つ。アプリケーションエンジニアリングで開発されたソフトウェアの中にはドメインとして再利用されるものもある。

繰返し型モデル 】(反復型モデル)
一通りの設計を行い、実装を行うのではなく、何度も分析・設計・実装を繰り返しながら徐々に完成度を上げていく手法。
スパイラルモデルとも呼ばれる。
ウォーターフォールモデルの中で小さな反復型設計を行うラショナル統一プロセス(Rational Unified Process:RUP)などもある。また、アジャイルの一種であるエクストリームプログラミング(eXtreme Programing:XP)も反復型開発の一つ。

段階的モデル(Incremental Model)
最初に小さなシステムを作成し、それを段階的に発展させていく手法。要求を全部一度に実現するのではなく、複数に分割し、順次実現していくアプローチをとる。
システムを独立性の高いいくつかのサブシステムに分割して、サブシステムごとに順次開発、リリースしていくプロセスモデルである。サブシステムの開発が並列進行する点が、スパイラルモデルと異なる。
最初にシステム全体の要求定義を行い、要求された機能をいくつかに分割して段階的にリリースするので、すべての機能がそろっていなくても、最初のリリースからシステム全体の動作確認をすることができる。

進展的モデル(Evolutionary Model)
開発プロセスの一連のアクティビティを複数回行う反復型のモデルである。要求に従ってソフトウェアを作成し、出来栄えを評価する。その結果改訂された要求に従って作成し、また出来栄えを評価する・・・というように、要求事項やソフトウェアを改訂しながら反復を繰り返し、ユーザーが本当に求めている要求に近づけていくといった特徴を持つ。エボリューショナルモデルでは、ユーザーの要求が発散してしまいソフトウェアがいつまでたっても完成しないリスクがある。一方で、要求やソフトウェアの仕様に対して妥当性であるという確信が持てない場合に、繰り返して評価することで精度の高い要求や妥当なソフトウェア仕様に到達できるメリットがある。
システム全体のプロトタイプを最初に作り、それをバージョンアップしていく。スパイラルモデルは、部分毎にプロトタイプ、バージョンアップとしながら全体を作っていくので、この点で異なる。OSの開発に向いている。


b. アジャイル (Agile)

アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、1~3週間程度で1つの反復 (イテレーション) で1機能を開発する(⇒反復型開発)。 この反復のサイクルを継続して行い、1つずつ機能を追加開発していくのである。 おのおのの反復は、小規模なソフトウェア開発プロジェクトに似ている。 各反復では、それまでに開発した成果物に1つの小さな機能を追加する。 計画、要求分析、設計、実装(コーディング)、テスト、文書化といった、ソフトウェアプロジェクトに要する全ての工程を、1つの反復内で行う。場合によっては、1つの反復内で開発すると計画していたソフトウェア機能を、必ずしも期間内で充分に実現できるとは限らない。このように時にはうまくゆかない反復もあるが、アジャイル開発手法では、各反復が終了するごとに、機能追加された新しいソフトウェア (ビルド) をリリースすることを目指す。 各反復が終了するごとに、プロジェクトチームは、プロジェクトにおける優先度を評価し直す。
アジャイルソフトウェア開発では、システムの重要な機能から順次開発し、それを顧客に引き渡す。つまり、そのシステムの価値をできるだけ早く顧客に届けようというシステム開発手法なのである。

XP(エクストリームプログラミング)
ユーザー要求や仕様の変更リスクを軽減するために、顧客や開発者間のコミュニケーションを重視し、コーディングとテスト、リファクタリング(コードの書き直し)に重点を置いて、短期間のリリースを繰り返して開発を進めていくソフトウェア開発方法論。アジャイルソフトウェア開発もしくは軽量(ライトウェイト)開発と総称される一連の手法のうちの代表的な1つ。
XPは10人程度くらいまでの比較的少人数のチーム開発に適しているといわれ、小規模のソフトウェア開発に向いた手法だとされることが多い。

テスト駆動開発
ソフトウェア開発スタイルの1つで、コーディング(あるいは設計)に先立ってテストケースを書き、そのテストをパスするように実装/リファクタリングを行うということの反復を繰り返す技法のこと。

  1. 追加したい機能について、テストケースを記述する
  2. テストを実行して、失敗することを確認する(レッド)
  3. 機能を仮実装してテストを行う。テストに成功するまで修正を繰り返す
  4. テストに成功すること(=仕様を満たしている)を確認する(グリーン)
  5. グリーンを保ったまま、リファクタリングを行う
  6. 1.から繰り返し

最初にテストを書く(テストファースト)ことは、テストケースの形で仕様(どのような機能や振る舞いを持つソフトウェアを開発するのか)を作ることであり、コーティング作業のゴールを先に明確にすることになる。この後、レッド(仕様の確認)→グリーン(動作することの確認)→リファクタリング(コードの整理)のサイクルを循環的に繰り返していく中で、ソフトウェアの設計および実装コードが次第に洗練され、システムが形づくられるという点にテスト駆動開発の特徴がある。

スクラム
開発依頼者や市場のニーズに即したソフトウェア(プロダクト)をすばやく開発するための手法。
スクラムの基本単位は、スクラムチームという小さなチームである。スクラムチームは、スクラムマスター1 人、プロダクトオーナー1 人、複数人の開発者で構成される。チーム全体は、10 人以下である。
スクラムの特徴

  1. 要求を価値やリスクや必要性を基準にして並べ替えて(プロダクトバックログ)、その順にプロダクトを作ることで成果を最大化します。
  2. スクラムでは固定の短い時間に区切って開発を進めます。固定の時間のことをスプリントと呼びます。このスプリントという一定の期間毎(最長1ヶ月)に計画、実行、テストから完了までの一連の業務を行い、動くソフトウェアを作ります。
  3. 現在の状況や問題点を常に明らかにします。これを透明性と呼びます。
  4. 定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題がないかどうかを確認します。これを検査と呼びます。
  5. やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを適応と呼びます。
スクラムはわかっていることよりもわからないことが多いような複雑な問題を扱うのに適しており、5つのイベント(会議など)、3つのロール(人の役割)、3つの作成物など最低限のルールのセットで構成されています。あくまで最低限のルールのみ用意されているので、そのルールを実際どのように適用していくのかは自分たちで考えなければいけません。

ペアプログラミング 】(pair programming)
2人のプログラマがペアを組み、同じ画面を見ながら1つのプログラムを書くソフトウェア開発手法のこと。XP(エクストリームプログラミング)の主要なプラクティスである。
ペアプログラミングは開発チームのメンバーが常に2人1組で作業を行うことで、お互いに刺激し合いながら多様な視点を持ち寄って、質の高いプログラムの開発を目指す。ペアの組み合わせは頻繁に変わるので、コード全体の問題点やメンバーそれぞれの特性などについて、チームで共通して認識できる点も利点である。コードを書くと同時にレビューを行っていることになるので、ピアレビューの一種とみなされることもある。
ペアのうち、キーボードを使ってコードを書く人を「ドライバー」、ドライバーに対して助言や提案を行う人を「パートナー」「オブザーバー」「ナビゲーター」(※)などと呼ぶ。ドライバーとパートナーは適当なタイミングで交代する。ペアは半日から1日で組み替えるのがよいとされる。教育を目的に経験ある開発者と初心者をペアとする場合もあるが、原則としては同じレベルのプログラマがペアとなるのがよい。

リファクタリング
ソフトウェア・プログラムの保守性・再利用性を高めることを目的に、それが提供する機能仕様を変えることなく、内部構造を再構築(restructuring)するプログラミング・テクニックのこと。
プログラムの品質劣化を未然に防ぎ、将来にわたる機能拡張性の維持と保守作業の効率化を目的に、個々のプログラムを随時手直ししていくのがリファクタリングである。
「プログラムの外部の振る舞いを変えない作業」を指し、機能追加・変更とは別の概念である。また、システムの設計やアーキテクチャの変更を意味するものではない。


c. ソフトウェア再利用

今までに作成されたソフトウェアを再利用することは、ソフトウェアの開発生産性の向上と品質向上に有効である。
生産性向上には、開発済みのソフトウェアを利用することで、新規に開発する割合が少なくなるためであり、 品質向上には、すでにテストが行われて信頼のあるソフトウェアを使用するので、不具合が少ない。

ソフトウェアの再利用を、モジュールの単位で行う場合は、モジュールの開発時に、モジュールの独立性を高め、汎用性のあるモジュールにしておくようにする。
システム全体や一部を再利用する場合は、そのシステムをできるだけ標準的に作成しておき、必要に応じてカスタマイズすることで対応する。


d. リバースエンジニアリング

リバースエンジニアリングとは、既存のソフトウェアコードを分析し、基本的な設計方針や具体的な処理内容・アルゴリズムなどの仕様を見つけ出す手法のこと。
リバースエンジニアリングを行うツールとして、プログラム解析ツール、逆コンパイラ、コールグラフなどがある。
既存のソフトウェアの担当者が退職したり、開発時の利用者文書がなくなったりで、ソフトウェアの保守がしにくくなった場合に有効である。
ただ、市販のソフトウェアをリバースエンジニアリングすることは、知的財産権の侵害になるので行わないようにする。

逆コンパイラ
機械語で記述されたオブジェクトコードを解析し、人間にわかりやすいソースコードを作成するプログラムである。

コールグラフ
関数の呼び出し(コール)状況をグラフに表すもの。


e. マッシュアップ

マッシュアップとは、IT用語としては、複数の異なる提供元の技術やコンテンツを複合させて新しいサービスを形作ることである。複数のAPIを組み合わせて形成された、あたかもひとつのWebサービスであるかのような機能が、マッシュアップと呼ばれている。
「マッシュアップ」(MashUp)とは「混ぜ合わせる」というほどの意味である。もともとは音楽関係の業界でよく用いられてきた。まったく何もない状態から創造するのではないが、すでに在るものを用いて再び新しいものを創生する、というニュアンスがある。リミックス曲などがマッシュアップに相当する。
Web技術におけるマッシュアップは、「Web 2.0」の潮流とともに非常に盛んになった。その背景としては、Amazon.com、Google、Flickr、YouTubeといった、いわゆるWeb 2.0企業が、自社のWebサービスの機能をAPI(WebAPI)として無償で提供する事例が増えたという点を挙げることができる。それに伴い、APIを利用して複合的な機能を持ったWebサービスを開発することが可能となり、Webの可能性が広がった、というわけである。マッシュアップで構成されたサービスは、腕試し的に作成されたものもあれば、商用のサービスとして本格的に運営されているものもある。
マッシュアップ用のAPIとして代表的なものとしては、Google Mapsの地図情報などを挙げることができる。
WebAPIで使われるプロトコルには、
XML-RPC
 RPC (遠隔手続き呼び出し) をHTTPとXMLで行う
SOAP
 ● Webサービスの中核技術
 ● XML-RPCが元になっていて、XML-RPCを拡張したプロトコル
 ● XML-RPCとの違いは、HTTP以外のプロトコルも利用可能、複数の返り値を取得可能
REST(Representational State Transfer)
 ● HTTPのGET, POST, PUT, DELETEとユニーク(一意)なURIの組み合わせで動作を表現
 ● リソース(資源)のURIを指定するだけ。階層やパラメータの指定も可能
 ● ROA
WebAPIで使われるデータ形式には、
XML
 ● タグによる意味づけ
 ● 階層化された構造表現
RSS/Atom
 ● XML形式
 ● Weblogやニュース記事の配信(フィード)
 ● 天気情報や企業の情報配信などにも応用されている
JSON(JavaScript Object Notation)
 ● JavaScriptのオブジェクトや配列表現を利用
 ● 関数呼び出しを埋め込んだJSONPはクロスドメインを容易に解決

Web 2.0
Web 2.0では、従来のWebとは異なり、コンピュータにおけるOSのようにWebが一種のプラットフォーム(基盤)として振舞うようになり、その上で情報や機能が製作者の手を離れて組み合わされたり加工されたりするようなWebシステム全般を指す。
従来のWebは製作者が作った状態で完結しており、利用者は単にそれを利用するだけの関係であったが、Web 2.0ではWebサイトの持つ情報や機能を外部のサイトやソフトウェアなどから参照したり呼び出したりすることができ、利用者や他の事業者がソフトウェアやWebサービスを組み合わせて新たなコンテンツやツールを作成できるようになる。
また、多くのユーザが参加して情報を出し合うことで、その蓄積が全体として巨大な「集合知」を形成するという点もWeb 2.0では重要とされる。

Ajax
AjaxとはAsynchronous(エイシンクロナス) JavaScript + XMLの略で、スクリプト言語のJavaScriptやWeb記述言語のXMLといったオープンな技術を組み合わせて開発する手法を指す。今までの Web アプリケーションは、情報をサーバに送り、サーバからの結果を表示するには、ページ全体をロードしなおさなければならなかった。 Ajax は、JavaScript の HTTP 通信機能を使って、ブラウザとサーバが非同期通信を行い、 Web ページのリロードを行わないでサーバとデータのやり取りを行なう Web アプリケーションである。
Ajaxという新技術があるのではなく、動的にWebの表示を変化させるDynamic HTML(JavaScript + CSS)と、表示内容を適宜サーバーから通信を介して取得するXMLHttpRequestという、従来からある標準的な技術を組み合わせて、より効果的な利用方法を提唱したものを指している。
Google マップなどに使われている技術である。


f. モバイルアプリケーションソフトウェア開発

ネイティブアプリ
OSにアプリケーションストア経由でインストールして使うアプリのことを指します。
OSにインストールするのでインターネット環境に依存しない点です。また、スマートフォンの機能も利用できる点も特徴の1つとなっています。たとえば、カメラ・プッシュ通知・位置情報の取得などです。
メリット

  • 読み込みスピードが速い。
  • インストールして使うので、アプリによっては、インターネットに接続しなくても使えるものもある。
  • デバイス自体が持つ機能を利用し、プッシュ通知や位置情報を使った機能などを簡単に搭載できる。

デメリット
  • アプリストア経由でユーザーにダウンロードしてもらう必要があるため、利用を始めるには若干ハードルがある
  • リリースやアップデートの際にアプリケーション審査がある。
  • OSごとに作成しないといけないので開発コストが割高になる。

Webアプリ
ブラウザ上で使用できるアプリで、普段使用しているデバイスとインターネット環境があれば使用できるので、アプリをインストールしていなくても利用可能です。
Webブラウザ上でもアプリのような機能を載せられるのは、最近のWebアプリが基本的にHTML5で開発されているため。HTML5ではスマートフォンの機能と連動した動きも実装しやすい。
メリット

  • インターネット接続環境があれば、アカウントだけで使えるので、利用デバイスを限定しなくて良い。
  • インストールが必要なく、アップデートもサーバー側で行われるので、常に最新のアプリが使える。

デメリット
  • インターネット環境が必要。また、インターネットの環境が悪いと遅くなる。
  • ネイティブアプリのようにデバイスの機能をフルには使えない。

ハイブリッドアプリ
ネイティブアプリとWebアプリのメリットを組み合わせたものが「ハイブリッドアプリ」です。Webアプリをベースに、ネイティブアプリのデバイス機能を使用できるメリットを取り入れたもの。
ハイブリッドアプリもWebサイトを作成する際に使われる、「HTML5」「CSS3」「JavaScript」というプログラム言語で作成されます。しかし、ブラウザ上で動くのではなく、OS標準搭載のWebViewで動きます。
メリット

  • アップデート時は再インストールの必要がなく、サーバーのデータを更新するだけで、常に最新の状態で使える。
  • OSのアップデートの影響を受けやすいネイティブアプリより影響を受けにくくなっており、メンテナンスの低減が可能。
  • Webアプリでは使用できなかったデバイスの機能のカメラやマイク機能などもアプリに組み込める。
  • マルチプラットフォームが可能なので、OSごとに作成しなくて良いので、開発コストが抑えられる。

デメリット
  • アプリストア経由でユーザーにダウンロードしてもらう必要がある。
  • Webアプリより速いものの、ネイティブアプリ並みの動作速度を出すのは難しい。

バーミッション要求
アプリがAPI(アプリケーションプログラミングインターフェース)によって他のアプリやデバイスの機能にアクセスし、データのやり取りを行うため時の許可を求めること。 さまざまなモバイルアプリは、アクセスが制限されたサンドボックス内で実行されます。アプリ自体のサンドボックスの外部にあるリソースや情報を使用する必要がある場合は、権限を宣言し、このアクセスを提供する権限リクエストを設定すること。

アプリケーションソフトウェア審査
開発者はアプリケーションを配布する場合、それらが信頼できること、 期待どおりに動作すること、不快な表現が含まれていないことなどの審査を受けてからでないと配布できない。
またアプリケーションソフトウェアの配布もアプリストア経由でないと配布できない。


  [ 例題 ] 
  1. 平成29年度秋期 問50  リバースエンジニアリング
  2. 平成28年度秋期 問50  リバースエンジニアリング
  3. 平成27年度春期 問51  XP Extreme Programming
  4. 平成27年度秋期 問49  リバースエンジニアリング
  5. 平成24年度春期 問50  リバースエンジニアリング
  6. 平成24年度春期 問54  ソフトウェア品質
  7. 平成23年度春期 問53  ウォータフォール 修復コスト
  8. 平成23年度秋期 問50  プロセスモデル
  9. 平成21年度春期 問45  システム開発
  10. 平成21年度春期 問49  リバースエンジニアリング


     

www.it-shikaku.jp