アカウント名:
パスワード:
文脈からプログラム設計書=詳細設計書という解釈なのでは?#システム管理基準内での文脈はまだ見てないので違うかもしれんけどそれなら、詳細設計書Firstというのはないかなあ。テストおよびデバッグにすごくコストがかかる場合に限ってはありだけど。ふつー、ソースとコメントから自動生成だろ。
>設計図で意思を確認するというわけにはいかないいやいや、設計図(仕様書)以外に意思(機能の目的)を確認する媒体はないでしょうに。
>設計書なしで打合せや、承認、メンテナンスはどうするつもりなのでしょうかね。
打ち合わせ:すべては口伝で受け継がれる承認:誰もそんな事はしない。すべてはあるがままに。メンテナンス:生贄を差し出し、擦り切れるまで使う
でも、まあ通常の知能があれば、設計書とは呼んでなくても設計書のようなものは自然発生すると思うけどなあ。
データ関連図やデータ構造のグラフって, ソフトの設計図じゃないのかな? シーケンス図みたいなので各種の挙動の設計をするってのも多いだろうし.
コード化以前にそうしたレベルでのイメージを整理しておかないと, コーディングの途中で混乱して効率が悪いんで, 自分のために描くようにしてるんですけど.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
この会社はどうやって開発しているのだろうか (スコア:2)
どうやってソフト開発をしているのか知りたいところですね。
ソフトウェアはモノ作りと違って形がないから、設計図で意思を確認するという分けにはいかないので、
言葉は非常に重要です。
その言葉が何を意味しているのか、共通認識を持たないと誤解が生じます。
そういう意味で共通フレームなどがあるわけですが、設計書なしで打合せや、承認、メンテナンスはどうする
つもりなのでしょうかね。
Re: (スコア:1)
文脈からプログラム設計書=詳細設計書という解釈なのでは?
#システム管理基準内での文脈はまだ見てないので違うかもしれんけど
それなら、詳細設計書Firstというのはないかなあ。テストおよびデバッグにすごくコストがかかる場合に限ってはありだけど。
ふつー、ソースとコメントから自動生成だろ。
>設計図で意思を確認するというわけにはいかない
いやいや、設計図(仕様書)以外に意思(機能の目的)を確認する媒体はないでしょうに。
>設計書なしで打合せや、承認、メンテナンスはどうするつもりなのでしょうかね。
打ち合わせ:すべては口伝で受け継がれる
承認:誰もそんな事はしない。すべてはあるがままに。
メンテナンス:生贄を差し出し、擦り切れるまで使う
でも、まあ通常の知能があれば、設計書とは呼んでなくても設計書のようなものは自然発生すると思うけどなあ。
Re: (スコア:0)
Re:この会社はどうやって開発しているのだろうか (スコア:2)
データ関連図やデータ構造のグラフって, ソフトの設計図じゃないのかな? シーケンス図みたいなので各種の挙動の設計をするってのも多いだろうし.
コード化以前にそうしたレベルでのイメージを整理しておかないと, コーディングの途中で混乱して効率が悪いんで, 自分のために描くようにしてるんですけど.