akon2.00βのよっぱらいの戯言

色しょく是食、食しょく是色 当サイトではアフィリエイトプログラムを利用して商品を紹介しています。

ドキュメントファースト以外ありえないのです---工事進行基準とXP---

工事進行基準に対応できないでしょ」と一蹴してしまいましたが、とあるところで、意見を求められたので、整理しておきます。404に無縁な方は、読み飛ばしてください。
#無縁なシステムってどんなシステムだろう
#いまの環境では、野良と呼び、見つけ次第捕獲されています。
開発ドキュメントとソースコードが一致していることが、担保できなければ、ドキュメントファーストであることに、意味がないのは、承知の上です。でも、404は免罪符なんですよ。
したがって、建前はドキュメントファーストなんですよ。基本設計書なり、外部設計書という表紙のついたドキュメントが日付の入った承認印とともに、残っていないといけない。
#大手二社の監査法人からの指摘なので、
#よそではどのようになっているかは知りませんが、
#出入りの大手SIerも同じような感じですし、
#監査法人の指摘には反論できないので、どこも同じではないかと思っています。
#これだと改ざんできるじゃないかというつっこみは受け付けません。
フォワードエンジニアリングというシステムのライフサイクルのものすごくちいさな局面にスポットをあてていた議論が、システム開発全体に適用できると誤解されてような気がしています。もしかしたら、実装フェーズというさらにちいさな局面の議論かも。
一括受託の場合、納品までに、開発ドキュメントを作成すれば、帳尻はあうでしょう。多くのシステムは、つくりっぱなしが許されるはずはなく、改修が行われます。保守契約に基づいて、個別に受発注が行われず、改修を行うにしても、改修依頼ベースに改修が行われます。この際に、「ソースコードを変更したので、開発を承認してください」なんてありえないのですよね。もちろん、承認証跡のない開発なんて許されないのです。開発承認があり、リリース承認があるとわけですよ。このためには、なんらかのドキュメントが必要になります。404が進んでくると、リリース承認に当たっては、設計書とソースが一致していることの証跡がもとめられそうですが、いまのところは、目こぼしされています(監査法人のITリテラシが低いから)。だからといって、プロジェクト内で隠蔽工作をして形式美に走るにしても、そもそも論を知らないと隠蔽できないし、ヒアリングされたら、ばれるわけですよ。金融系に携わっている方の発言だったので、まさか件名だけで開発承認が下りるとは思えないので、話の真偽を疑いつつ、どのあたりで、こんな議論がされているのか、しらないのですが、おそらく、保守フェーズを知らない方が、もしくは404の対象にならないようなシステムしか携わっ
ていない方が、机上の空論をぶつけてみただけで、実際はガチガチなので、よい子は真似をしないように。
ちゃんと設計書を書いてから、実装しましょうねという話でした。設計書というのがミソですからね。工事進行基準が浸透すると、この詭弁は通用しなくなりそう。
誰か工事進行基準とXPについて法的に調べた人はいないのかな。承認プロセスが機能すればいいのだから、「ソースコードが設計書でビルドの際に承認プロセスが入っている」という主張が監査人に受け入れられる・・・わけはないですね。