ソフトウェア開発手法

ソフトウェア開発手法

データ

読み そふとうぇあかいはつしゅほう
属性 計画論
種類 概念　頭痛の種
能力 ゲームを完成へ導く程度の能力

説明

　あるソフトウェアを作る際に、どのように作るのかを抽象化した学問
ウォーターフォールやスパイラルなど、色々なアプローチが存在する。

ウォーターフォールモデル

　仕様決定→設計→実装→テスト→リリース　と順番に各工程を進めていく開発手法。
理想的には、一度進んだ工程は逆戻りしないのが特徴である。(実装してから仕様を変えたりしない)
非常に理解しやすく、かつ計画的に行えるため、詳細な制作期間や期日を決めやすい。
一方で、前工程にはミスが無いことを前提に進むため、たまに明らかなバグが「仕様です」となったりする。
これを「仕様バグ」と言う。
ちなみに現場では確信犯的に……おや、誰か来たようだ。

★ウォーターフォールの流れ
ウォーターフォールモデルを大雑把に分割するとこんな流れになる。
この分割はPDCAサイクルにも通ずる所があるので併載する。

1.工程の存在を確認する。(Plan)
2.各工程に期日を設ける。(Plan)
3.期日どおりに各工程を進める。(Do)
4.工程がきちんと期日どおりに進んでいるのか確認する。(Check)
　進んでいなければ期日や工程を見直す。(Action)

工程	行う作業の単位の事
期日	何を何時までにやる目標の事
PDCAサイクル	学校で教えてくれるよ

★1.工程の存在を確認する
「ゲームを作る(課題やる、就活する、飯作る)にはどのような作業をしなければならないか？」を考えるのがこのパートである。
このしなければならない作業一つ一つを工程と呼ぶ。ウォーターフォールはさながら面クリアゲームのように、この各工程を順番にやっつけていく事になる。
○参考に、ゲーム作りを行う際に考えられる工程を挙げてみる

企画を考える
仕様を考える
設計を考える
必要な素材リストを作る
プログラムモデルを考える
ゲームの作り方を勉強する
自機を実装する
敵を実装する
インターフェースを考える
デバッグする
難易度を調節する

ちなみに、こういった工程のリストをTODOリストと呼んだりする。

TODOリスト	「これからやる事」のリスト、人によっては重要度や緊急性で分類したりする
企画	「このゲームで何がしたいのか？」を考える事
仕様	「このゲームは何が出来るのか？」を考える事
設計	「このゲームをどう作るのか？」を考える事
実装	実際にプログラムを組んで、動く物にする事
プログラムモデル	何をどうプログラムするのか考える。(ex.自機のデータ構造体にはどんなデータが存在するのか？)

★2.各工程に期日を設ける。
その次に、この工程はいつやろうか、と言うのを考える。
ウォーターフォールモデルでは先に挙げた工程をジャンル別に分けることが出来る。
このジャンルはそのまま、計画に反映できるので利用すると良い。上から順番に行う事になる。

用件定義	｢何がしたいのか｣を整理する	企画を考える,インターフェースを考える
仕様書作成	｢何が出来るのか｣を整理した書類を作る	仕様を考える,ゲームの作り方を勉強する
設計書作成	｢どうやって作っていくか｣を整理した書類を作る	設計を考える,必要な素材リストを作る,プログラムモデルを考える
コードの実装	実際に作っていく	自機を実装する,敵を実装する
単体テスト	それぞれに作った物がちゃんと動くかテストする	自機を実装する,敵を実装する,デバッグする
結合テスト	単体テストに合格したコードを組み合わせて行く。結合コード書いたりもする	自機を実装する,敵を実装する,デバッグする,難易度を調節する
現場テスト	実際に使われる場所でバグらないかチェックする	デバッグする,難易度を調節する

何が何時までに終わるのか？は自己や協力者のスキルに依存するので、経験で判断するしかない。期日が外部によって決まっているなら(プロコンなど)それに合わせられるような計画を立てる。
※「計画を守る事」は、最初はあまり意識しなくても良い。重要なのは「この工程はこれ位の時間必要だ」という判断が出来る事である。この判断が出来る事で、次回はより正確な計画を立てることが可能になるのだ。

★3.期日通りに各工程を進める
一見、単に期日どおりに工程を進めるしかする事が無いように見えるが、一つの工程があまりに大雑把だった場合、より詳細な工程へ分割する必要が生じる。
○自機を実装する工程

自機のデータ構造を定義する
自機を表示して見えるようにする
自機に画像を適応する。
自機が動けるようにする
自機が動いた時、アニメーションさせる。

といったように細かい工程が出てくる。この段階で自機画像が無ければ、自機画像を作ったり、仮画像を作ったりとさらに工程は増えるだろう。

工程の分割(P)
工程を進める(D)
足りない工程が存在するか確認する(C)
存在すれば足す、何時やるのか考える(A)

と、入れ子構造になってゆくと思われる。

データ構造	要するに構造体の中身の事。自機の座標データはint? float?
入れ子構造	こんな状態→ for(i=0;;i++){for(j=0;;j++){printf("%d%d",i,j)}}

★4.工程がきちんと期日どおりに進んでいるのか確認する。(Check)　進んでいなければ期日や工程を見直す。(Action)
定期的に工程チェックを行う。このスパンも人それぞれで最も良いタイミングは違うだろう。いわゆる「一区切り」って奴だ
ここで一度反省し、より良い方法を考える。
例えば先ほど、自機の実装を分割したが、敵の実装も同じように、あらかじめ分割しておいたり、
「とりあえず、バグ無く動きはするもの」としてバックアップを取ったりすると良いのではないかと思う。

以上がウォーターフォールモデルの基本的な考え方だ。
冒頭でも言ったが、このモデルの最大の特徴は「分かりやすい」事にある。
この分かりやすさは、チーム活動を行う際にもっとも力を発揮するだろう。

コメント

• なにこれ誰が書いたのすばらしい。こういうのがほしかった -- ほにゃー (2011-05-18 12:06:55)
• ヲータホールモデルは仕様変更に弱すぎるのと、仕様がバグってた絶望しか残らないので非推奨。 -- f (2011-05-18 21:24:44)
• ヲータホールはヲータホールで、別ページ作りませんか -- f (2011-05-18 21:26:31)
• 仕様変更できないって事は、仕事に対する単価を明確に出来るって事なんだ。仕様が変わったんで追加料金頂きます。ってのは、なかなか理解してもらえない。 -- Javel (2011-05-19 21:36:45)
• 枯れた考え方だけどね -- Javel (2011-05-19 21:40:57)
• ついったーから拾ってきたコピペだけど、こんなんが。『「仕様を決め、詳細は決まらないので見切り発車し、機能を分析し、ガントチャートを引き、仕様変更が常時発生するため当初の機能分割とガントチャートが無意味化するので途中から無視して臨機応変にやる」というのが一番一般的だと思う』 -- f (2011-05-28 15:38:05)
• つ「アジャイルソフトウェア開発」　ただいま勉強中です…… -- javel (2011-05-29 08:29:21)