Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

開発プロセスのアジリティと設計限界品質

設計とコードとの整合性で担保できるのは「設計限界品質」(IPA 平成30年度春期プロジェクトマネージャ試験(PM)午後I 問2)であって、実際には設計の内容を業務仕様に照らして「正しい」と言える場合にのみ利用できる指標だ、ということなんだろうか。

  • 業務仕様から見て設計が間違っている、またはその時点で提示されている業務仕様自体が実際の業務そのものに照らして間違っているという前提に立てるか、というのがアジリティなのか?
  • その前提だと設計限界品質には処理方式の一貫性などソースコードの保守性といった非機能的な意味しかなくなって、業務機能的な意味がなくなるのか?(もっともCode smellを減らす効果はあるだろうが……)