不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
本稿は、ソフトウェア開発プロジェクト管理の一貫としての評価戦略を解説する3回シリーズの第2回である。本シリーズの第1回「プロジェクトの状態を評価する：パート1」（翻訳記事「プロジェクトのはじめに計画を立てるのは無謀」）では、プロジェクトの健全性を評価するメカニズムとしての評価の概念を紹介し、「方向付け」フェイズにおいてプロジェクトの健全性評価に役立つ具体的な評価値について解説した。第2回は、「メインとなる」開発作業である「推敲」と「構築」の両フェイズの評価に焦点を当てる。 推敲と構築の両フェイズには、同様の評価アプローチへとつながる多数の類似点がある。いずれのフェイズも、主眼はシステムに望まれる機能を漸次インプリメントして増やしていく実行イメージの作成だ。両フェイズの最大の違いは、それぞれが取り組むリスクの違いに起因している。推敲フェイズは、ソリューションのアーキテクチャに影響を与える技術
UPを基本から理解する
開発プロセスとは，先人が見出した「開発プロジェクトのベストプラクティス」，平たく言えば「勝ちパターン集」である。 開発プロセスに興味を持ったことがあれば，「Unified Process(UP）」を一度は耳にしているはずだ。しかしUPを正しく理解し，活用できているプロジェクトはあまりにも少ない。 本講座では，UPに含まれる膨大な開発プロジェクトの「勝ちパターン」を，4つのPartに分解して解説する。RUPやUPの導入を検討している人はもちろん，オブジェクト指向や反復開発には全く縁がなくとも，「開発プロジェクトを成功させたい」という想いがあるのなら，UPの知識はきっと役立つはずだ。 Part1 Unified Process，その生い立ちと構造を知る Part2 「ユースケース駆動開発」でUMLを理解する Part3 「ライフサイクルフェーズ」と「反復開発」 Part4 リスク最小化と再利用
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
