タグ

Programmingとworkに関するmukakenのブックマーク (2)

  • 職業訓練所の思ひ出 - マシンがどんどん廻る廻る 

    id:phaさんのとこで職業訓練校についての記事があった。 実は会社を辞めてからのニート期間に僕は職業訓練の学校に通っていたことがありました。職業訓練ってかなり良い制度だと思うんだけど意外と実情が知られてないようなので勿体なく思っているので、ちょっと職業訓練について自分の体験を交えながら書いてみようかと思います。 で、かくいう僕も転職準備中という名目のニート期間に職業訓練校に通い、そこでJavaの勉強をしたのがプログラマになった(ホント直接の)きっかけでもあったので、自分の経験をつらつらと書き記しておきたいと思う。行くのを悩んでる人の検討材料にでもなれば幸い。 無謀な辞職から始まる というわけで職業訓練校にいったきっかけなわけだけど、これはもうものすごくストレートに「失業保険の給付期間を延長したい」がため。その前まで僕は某音楽雑誌の編集部にいたんですね。詳しくは書かないけど、これが超ワーキ

    職業訓練所の思ひ出 - マシンがどんどん廻る廻る 
  • ユメのチカラ: 開発工程を別々に担当してはいけない

    古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更

  • 1