読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

ソフトウェアの作りかた

社内勉強会のメモ。昨日だったけど。

何が出来るのか

機械に出来ることと人間に出来ることは違う

e.g. 炊飯器を製造すること vs 米を炊く

ソフトウェア(機械) 明確に定義出来るものを開発されたもの
特に文章化されている必要はなく、コードで定義されている
(必ずしも人間に理解されている必要はない)

cf. AIがいつまでたっても開発されないのは、「知能」というものが上手く定義されていないから


米を炊くことは定義可能 米の入った水を密閉された空間でわかすと出来る
(パンを焼く、ラーメンを作るなど、想定外の操作には対応しづらい)
機械はやる事を決めて、人はやることの決まった機械を他の物事に応用する。

ただし、技術的制限、政治的理由で定義できても実装出来ないことがある

e.g. cloud computing
ネット上でファイルを置くソフトウェア(Dropboxなど)
1960年代から発想自体はあるものの、ネットが遅すぎてお蔵入り

ソフトウェアの開発は、定義 実装 束縛がキモ

設計

やりたい事を明確にする

  • ビジネスゴール
  • マーケティング
  • ブランド

機能要件

  • 機能の部分。(米を炊く)

非機能要件

  • パフォーマンス (おいしく炊く)
  • 見た目 (美しいフォルム)

pitfall 何がしたいのか分からない、機能が不要となったらお蔵入り

ソフトウェアが扱うデータ (敵味方のデータ、残機、アイテム)を、漏れなくダブリなく書き出す
データ設計がイカれていると結構面倒だから。

データのやり取りを設計する

INPUTの箱のつながり = ソフトウェア
業務の設計 = どの部署が何をどうする
is Softwareの設計

data applicationを実際に形に落とすために何を使うか

notice

  • ノウハウ
  • スケーラビリティ
  • 人材
  • 相互運用性

開発計画

  • 導入プラン && 設計はきちんとしないとバグが頻発するかも
  • バグがない
  • テスト(INPUT-OUTPUTの組で定義)
  • 保守性
    • 綺麗にコードが書けているか
    • ドキュメントがあるか
  • フィードバック(から得られた結果を元に次のビジネスゴールや追加機能を新たに決める)

でも、毎回全部はやらないよ
必ず守らなければならない順番はなく、
フェーズを行ったり来たりする

watarfall

  1. 要求仕様定義
  2. デザイン
  3. 実装
  4. テスト

カッチリ決まった順番で開発をやる
計画性を重視する
リスクが高いソフトウェア向け
要求があまり変わらないもの向け(飛行機などはバグ(=墜落)は絶対に避けたいので、設計が蝶重要)
要求がコロコロ変わると爆発する
全ての機能が完成しないとリリースできない
設計は1回でパーフェークトにやらなければならない

agile

開発対象を小さな機能に分割
一定期間でリリース
やりかたは色々
初心者が少ない場合に向いている
変更が多く、リスクが少ないソフトウェアの開発に向いている。(人の命に関わらない)

業務の複雑性=プログラムの複雑性
業務フローを変更すると、データの整合性が取れなくなることがあるし、誰に不利益がかかるかも考える必要がある
テクノロジの限界もある。