アカウント名:
パスワード:
文脈からプログラム設計書=詳細設計書という解釈なのでは?#システム管理基準内での文脈はまだ見てないので違うかもしれんけどそれなら、詳細設計書Firstというのはないかなあ。テストおよびデバッグにすごくコストがかかる場合に限ってはありだけど。ふつー、ソースとコメントから自動生成だろ。
>設計図で意思を確認するというわけにはいかないいやいや、設計図(仕様書)以外に意思(機能の目的)を確認する媒体はないでしょうに。
>設計書なしで打合せや、承認、メンテナンスはどうするつもりなのでしょうかね。
打ち合わせ:すべては口伝で受け継がれる承認:誰もそんな事はしない。すべてはあるがままに。メンテナンス:生贄を差し出し、擦り切れるまで使う
でも、まあ通常の知能があれば、設計書とは呼んでなくても設計書のようなものは自然発生すると思うけどなあ。
データ関連図やデータ構造のグラフって, ソフトの設計図じゃないのかな? シーケンス図みたいなので各種の挙動の設計をするってのも多いだろうし.
コード化以前にそうしたレベルでのイメージを整理しておかないと, コーディングの途中で混乱して効率が悪いんで, 自分のために描くようにしてるんですけど.
設計図・設計書・仕様書の違いは何だろう。設計図は図面、設計書は文章の違いだと思ったんだけど。設計図だと材質とか加工方法とか目的より手段。仕様書→計算書→組図⇔部品図かな?学校でしかやったこと無いので実際は知らないけど。#取説とかの仕様の入った図面は設計図から起こした設計図ではない説明図やメンテ図だよね?
うちのチームではシステムの仕様書は「何ができるのか」システムの設計書は「どういうふうに作られているのか」を書くものだと定義しています。外部設計書・内部設計書というふうに分けると、微妙にずれるところが出てくるのですが、概ね外部設計書が仕様書、内部設計書が設計書に相当するかなと。
このとき、特に重要な部分については事前にクラス設計とか処理方式程度まで含むドキュメントはつくるので、その基準に合わせるときにはそれに「プログラム設計書」という名前をつけてますね。
ある会社では、紙芝居を作りました。「何ができるのか」お客から了承得ました。DBサーバにテーブルを作りました。プログラム作りました。プログラム仕様書を作りました。「どういうふうに作られているのか」システム運用マニュアルを作りました。最後に、システム設計書を作りました。「何ができたのか」第2期の紙芝居を作りました。つづく
私のイメージではプログラム設計書っていうのはコード1行と1対1で日本語が書いてあるドキュメントですね。行間の情報はあまりありません。
じゃぁコード書けよっていう代物です。
# イメージっていうか実際にそういうの見たことも作ったこともあります。# 日本語でコード書いて、プログラマーという名の翻訳者がコードに書いていき、それが終わるまではプログラムを実行してはいけません。# ちなみに 詳細設計書とかオブジェクト関連図みたいなものは別でありました。
小規模ベンチャーだから大規模・大人数の開発経験が無い。もしくはプログラム設計書という言葉に対して思い描いてるものがずれているか。
書類がなんでも仕様書になってる会社ばかりではないことをご理解頂きたく。
-以上-
一番設計書にこだわってる感じ。
さすがにあなただけでしょう・・飛躍がすごすぎる
書類の必要は無い。メールでもいいから機能要求が書いてあれば仕様書とみなす事が出来ます。口頭の場合は内容をメールで送って確認するのが一番安全。
たとえば、Google Chromeとか、MySQLとか、設計書の存在が怪しいプログラムが世の中の大半だと思うんですが。これらの開発者が全く打ち合わせせずにプログラムを書いているとも思えませんし。
Google Chrome (Chromium) に関しては Design documents [chromium.org] というのがありますよ。ハイレベルなデザインはやはり文書に仕立ててレビューしてもらうみたいです。
コードがテストを通ったけど Design Doc が無くてコミットできない、とフォローしている Chromium 開発者が泣いてたっけ。Design Doc がないとセキュリティレビューに支障があるためらしい。
これはある程度出来上がった後に、機能を説明するために作ったやつですよね。ハイレベルなデザインも、外部からの受け入れのためのものだから、ちょっと方向性が違うと思います。
作りながら直して、また作って、ということをした時の細切れドキュメントを設計書として認定してくれるのであれば設計書は存在すると思うのですが、往々にして要求されるものって差分の積み重ねを認めてもらえなかったりするんですなぁ。
いや、非ウォーターフォールでも、それは最後に整理すべきものだろ...細切れになってると、自分で書いたものでも、後で見たときに困る
そのとおりドキュメントはメンテナンス資料
でも、メンテナンスする人が自分の為に作る事もあるけど
最終的に書き直さざるを得なくなるのは仕方ない工数だと思うの。
> プログラム設計書という言葉
MicrosoftもGoogleも、プログラム設計書なんてものは作っていない [blogs.com]ぞこれだからNOBAXのようなド素人は…
> MicrosoftもGoogleも、プログラム設計書なんてものは作っていないぞ
リンク先には以下の様な文言があるが。世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。アメリカ基準のアーキテクトなら、諸芸百般、百戦錬磨のソフト屋と言って良かろうよ。プログラム設計が出来ない方がおかしい。
翻って、プログラム設計もままならないど素人の集団にまともに仕事をして貰うなら、何らかの統制が必要だろう。プログラム設計を出来ない人間にやらせるのが問題なら、プログラム設計を別の人間がやって、その通りにコーディングさせると言うのもやり方としてはあると思う。昔ながらの詳細設計書、それもフローチャートとかがオンパレードのものの復活だわな。
あの品質のヒミツはそれか…
MSもGoogleもベンチャー企業だったってことを知らないヴァカ発見w
仕様がほしいのは大抵作った本人じゃなくそれを引き継いだ人だから、作る人が必要と思うかはどうでもいいんだよね…
クラスとかの名前が簡単な英語表記などでわかりやすくなっていればいいけれどE00とかm100とかになってるとイラっとする
ベンチャ企業ってのは、ものになるか分からない技術や製品を開発する「冒険」をする会社じゃなくて、金もない技術もない何もない状態で会社が倒産させないと言う、限りなく不可能に近い「挑戦」をする会社の事を言うのよ、日本ではね。
エンジニアが自分で考え、一番良いと思ったものを作り、できた物が市場の評価を受ける。それがベンチャーでしょう。打合せや、承認などの共通認識を持つという無駄な事に時間を使わない事こそがベンチャーが大企業に勝つための競争力のみなもとになるのでしょう。
自分が作る物がコケた時に、自分がした事の責任を取らず、打ち合わせ相手や承認した人のせいにするようなやつはベンチャーに向いてないから、大手の下請けという歯車で一生安月給でこき使われているのがお似合いです。
大手がこれぐらいやるのが当たり前でやらない企業はみんなモグリだ、と煽ってくれるほうがうちら零細にとってもありがたいこと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
この会社はどうやって開発しているのだろうか (スコア:2)
どうやってソフト開発をしているのか知りたいところですね。
ソフトウェアはモノ作りと違って形がないから、設計図で意思を確認するという分けにはいかないので、
言葉は非常に重要です。
その言葉が何を意味しているのか、共通認識を持たないと誤解が生じます。
そういう意味で共通フレームなどがあるわけですが、設計書なしで打合せや、承認、メンテナンスはどうする
つもりなのでしょうかね。
Re:この会社はどうやって開発しているのだろうか (スコア:1)
文脈からプログラム設計書=詳細設計書という解釈なのでは?
#システム管理基準内での文脈はまだ見てないので違うかもしれんけど
それなら、詳細設計書Firstというのはないかなあ。テストおよびデバッグにすごくコストがかかる場合に限ってはありだけど。
ふつー、ソースとコメントから自動生成だろ。
>設計図で意思を確認するというわけにはいかない
いやいや、設計図(仕様書)以外に意思(機能の目的)を確認する媒体はないでしょうに。
>設計書なしで打合せや、承認、メンテナンスはどうするつもりなのでしょうかね。
打ち合わせ:すべては口伝で受け継がれる
承認:誰もそんな事はしない。すべてはあるがままに。
メンテナンス:生贄を差し出し、擦り切れるまで使う
でも、まあ通常の知能があれば、設計書とは呼んでなくても設計書のようなものは自然発生すると思うけどなあ。
Re: (スコア:0)
Re:この会社はどうやって開発しているのだろうか (スコア:2)
データ関連図やデータ構造のグラフって, ソフトの設計図じゃないのかな? シーケンス図みたいなので各種の挙動の設計をするってのも多いだろうし.
コード化以前にそうしたレベルでのイメージを整理しておかないと, コーディングの途中で混乱して効率が悪いんで, 自分のために描くようにしてるんですけど.
Re: (スコア:0)
設計図・設計書・仕様書の違いは何だろう。
設計図は図面、設計書は文章の違いだと思ったんだけど。
設計図だと材質とか加工方法とか目的より手段。
仕様書→計算書→組図⇔部品図
かな?
学校でしかやったこと無いので実際は知らないけど。
#取説とかの仕様の入った図面は設計図から起こした設計図ではない説明図やメンテ図だよね?
Re:この会社はどうやって開発しているのだろうか (スコア:5, 興味深い)
うちのチームでは
システムの仕様書は「何ができるのか」
システムの設計書は「どういうふうに作られているのか」
を書くものだと定義しています。
外部設計書・内部設計書というふうに分けると、微妙にずれるところが出てくるのですが、概ね外部設計書が仕様書、内部設計書が設計書に相当するかなと。
このとき、特に重要な部分については事前にクラス設計とか処理方式程度まで含むドキュメントはつくるので、その基準に合わせるときにはそれに「プログラム設計書」という名前をつけてますね。
Re: (スコア:0)
ある会社では、
紙芝居を作りました。「何ができるのか」
お客から了承得ました。
DBサーバにテーブルを作りました。
プログラム作りました。
プログラム仕様書を作りました。「どういうふうに作られているのか」
システム運用マニュアルを作りました。
最後に、システム設計書を作りました。「何ができたのか」
第2期の紙芝居を作りました。
つづく
Re:この会社はどうやって開発しているのだろうか (スコア:1)
私のイメージではプログラム設計書っていうのは
コード1行と1対1で日本語が書いてあるドキュメントですね。
行間の情報はあまりありません。
じゃぁコード書けよっていう代物です。
# イメージっていうか実際にそういうの見たことも作ったこともあります。
# 日本語でコード書いて、プログラマーという名の翻訳者がコードに書いていき、それが終わるまではプログラムを実行してはいけません。
# ちなみに 詳細設計書とかオブジェクト関連図みたいなものは別でありました。
Re: (スコア:0)
小規模ベンチャーだから大規模・大人数の開発経験が無い。
もしくはプログラム設計書という言葉に対して思い描いてるものがずれているか。
Re:この会社はどうやって開発しているのだろうか (スコア:1)
書類がなんでも仕様書になってる会社ばかりではないことをご理解頂きたく。
-以上-
Re:この会社はどうやって開発しているのだろうか (スコア:2)
Re: (スコア:0)
一番設計書にこだわってる感じ。
Re: (スコア:0)
さすがにあなただけでしょう・・飛躍がすごすぎる
Re: (スコア:0)
書類の必要は無い。
メールでもいいから機能要求が書いてあれば仕様書とみなす事が出来ます。
口頭の場合は内容をメールで送って確認するのが一番安全。
Re: (スコア:0)
たとえば、Google Chromeとか、MySQLとか、設計書の存在が怪しいプログラムが世の中の大半だと思うんですが。これらの開発者が全く打ち合わせせずにプログラムを書いているとも思えませんし。
Re:この会社はどうやって開発しているのだろうか (スコア:4, 参考になる)
Google Chrome (Chromium) に関しては Design documents [chromium.org] というのがありますよ。ハイレベルなデザインはやはり文書に仕立ててレビューしてもらうみたいです。
Re:この会社はどうやって開発しているのだろうか (スコア:1)
コードがテストを通ったけど Design Doc が無くてコミットできない、とフォローしている Chromium 開発者が泣いてたっけ。
Design Doc がないとセキュリティレビューに支障があるためらしい。
Re: (スコア:0)
これはある程度出来上がった後に、機能を説明するために作ったやつですよね。ハイレベルなデザインも、外部からの受け入れのためのものだから、ちょっと方向性が違うと思います。
Re: (スコア:0)
作りながら直して、また作って、ということをした時の
細切れドキュメントを設計書として認定してくれるのであれば
設計書は存在すると思うのですが、
往々にして要求されるものって差分の積み重ねを認めてもらえなかったりするんですなぁ。
Re: (スコア:0)
いや、非ウォーターフォールでも、それは最後に整理すべきものだろ...
細切れになってると、自分で書いたものでも、後で見たときに困る
Re: (スコア:0)
そのとおり
ドキュメントはメンテナンス資料
でも、メンテナンスする人が自分の為に作る事もあるけど
Re: (スコア:0)
最終的に書き直さざるを得なくなるのは仕方ない工数だと思うの。
Re: (スコア:0)
> プログラム設計書という言葉
MicrosoftもGoogleも、プログラム設計書なんてものは作っていない [blogs.com]ぞ
これだからNOBAXのようなド素人は…
Re: (スコア:0)
> MicrosoftもGoogleも、プログラム設計書なんてものは作っていないぞ
リンク先には以下の様な文言があるが。
世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。
アメリカ基準のアーキテクトなら、諸芸百般、百戦錬磨のソフト屋と言って良かろうよ。プログラム設計が出来ない方がおかしい。
翻って、プログラム設計もままならないど素人の集団にまともに仕事をして貰うなら、何らかの統制が必要だろう。プログラム設計を出来ない人間にやらせるのが問題なら、プログラム設計を別の人間がやって、その通りにコーディングさせると言うのもやり方としてはあると思う。昔ながらの詳細設計書、それもフローチャートとかがオンパレードのものの復活だわな。
Re: (スコア:0)
あの品質のヒミツはそれか…
Re: (スコア:0)
これだからシステム開発をしたことがない奴は・・・
Re: (スコア:0)
MSもGoogleもベンチャー企業だったってことを知らないヴァカ発見w
Re: (スコア:0)
仕様がほしいのは大抵作った本人じゃなく
それを引き継いだ人だから、作る人が必要と思うかはどうでもいいんだよね…
クラスとかの名前が簡単な英語表記などで
わかりやすくなっていればいいけれど
E00とかm100とかになってると
イラっとする
Re: (スコア:0)
ベンチャ企業ってのは、ものになるか分からない技術や製品を開発する「冒険」をする会社じゃなくて、金もない技術もない何もない状態で会社が倒産させないと言う、限りなく不可能に近い「挑戦」をする会社の事を言うのよ、日本ではね。
Re: (スコア:0)
エンジニアが自分で考え、一番良いと思ったものを作り、できた物が市場の評価を受ける。
それがベンチャーでしょう。
打合せや、承認などの共通認識を持つという無駄な事に時間を使わない事こそがベンチャーが大企業に勝つための競争力のみなもとになるのでしょう。
自分が作る物がコケた時に、自分がした事の責任を取らず、打ち合わせ相手や承認した人のせいにするようなやつはベンチャーに向いてないから、
大手の下請けという歯車で一生安月給でこき使われているのがお似合いです。
Re: (スコア:0)
大手がこれぐらいやるのが当たり前でやらない企業はみんなモグリだ、と煽ってくれるほうがうちら零細にとってもありがたいこと。