12/09/23 16:58:38.42
UML読めない客もお断り!
UML以外の設計書を納品する必要があるなら、見積り2倍で出します!キリッ
851:仕様書無しさん
12/09/23 17:37:55.58
刑法第246条詐欺罪(十年以下の懲役)
虚偽のマージン率または派遣料金の明示により労働契約を締結する行為は詐欺罪の「人を欺いて財物を交付」にあたると見られる。
職業安定法第44条の労働者供給事業の禁止規定違反
偽装請負、多重派遣と同様に、事前面接、履歴書の提出を行うと「派遣労働者を特定する行為」にあたり派遣会社の実態が労働者供給業と見なされるため、職業安定法第44条の禁止規定違反となる。
罰則の適用には被害者による刑事告訴か関係諸局・内部関係者による刑事告発が必要となる。
・職業安定法第5章第六十四条、1年以下の懲役または100万円以下の罰金
処罰は派遣先、派遣元の両者に科される。職業紹介を行う紹介予定派遣では例外として事前面接が認められている。
労働基準法第1章第6条違反(中間搾取の禁止)
再派遣は労働基準法第6条の違反となる。罰則の適用には被害者による刑事告訴か関係諸局・内部関係者による刑事告発が必要となる。
・労働基準法第13章第118条、1年以下の懲役又は50万円以下の罰金
両罰規定(労働基準法第121条)
労働基準法第1章第6条違反については両罰規定が設けられている。労働基準法第121条には
この法律の違反行為をした者が、当該事業の労働者に関する事項について、事業主のために行為した代理人、使用人その他の従業者である場合においては、事業主に対しても各本条の罰金刑を科する。
とあり、事業主(中間搾取行為をした事業者の経営担当者、労働者に関する事項について事業主の為に行為をするすべての者)と事業主の代理人についても処罰が科される。被害を受けた労働者は派遣先および派遣元の会社、従業員などに対して刑事告訴を行える。
852:仕様書無しさん
12/09/23 18:22:46.39
> UML読めるとこに仕事まわせばいいのに
UMLとプログラムは相性が悪いんだ。
UML読める奴に限ってプログラムが作れない。
もし作ってもむちゃくちゃで何やりたんだかわからない。
UMLでは大事な情報が抜け落ちてしまうから、
同じ仕事を5年も10年もやるような大企業ならいいけど。
それ以外では使い物にならないんだ。
UMLがいいと言ってる奴に限ってぐちゃぐちゃの
ソースコードを書くのは、いまとなっては誰でも知ってることだ。
853:仕様書無しさん
12/09/23 18:32:50.96
UMLで書けるような仕様なんて、大した仕様じゃないんだよ
それが何のためのシステムなのかを知っていれば、
誰でも類推できてしまう程度のことしか書けない
854:仕様書無しさん
12/09/23 19:26:03.90
勤勉な無能が一番厄介なのは知ってるだろ?
そういう無能にはUMLという名の落書きを書かせて
プログラマの仕事の邪魔をさせないようにするんだ
もちろん落書きだから後で使わない
855:仕様書無しさん
12/09/23 21:49:40.04
UML読めないって、フローチャート読めないレベルじゃね?
856:仕様書無しさん
12/09/23 21:54:41.67
UML、フローチャート読み書きできるのと、コード読み書きできるかは別なんだよ
857:仕様書無しさん
12/09/23 22:02:22.62
フローチャート読めないほど頭が弱い奴に、
まともなコードを期待するのは間違ってる。
858:仕様書無しさん
12/09/23 22:37:13.28
両方求めるほうがおかしいの
高学歴パー系がそういう無茶なこと要求するからね
859:仕様書無しさん
12/09/24 00:52:28.63
UMLはwordで書けないから使えない
860:仕様書無しさん
12/09/24 01:51:21.29
全部できる奴以外死ねって事だろ
861:仕様書無しさん
12/09/24 03:17:05.67
読めないからダメって言ってる人はさすがにアレだと思うわ
別にUMLを使いたいとは思わんけど、簡単だからかじるくらいには覚えたよ
読めないと困るときもあるし
つか、UMLの仕様すら頭に入らない人が、まともなコーディングできるわけないっしょ
862:仕様書無しさん
12/09/24 06:51:03.86
UMLだから、駄目/完璧ってのは無いよな。
使える図は使う、要らない図は使わない。
まぁ、要らないけど要求されるから、無駄と判っていても作るってのは多いけど。
863:仕様書無しさん
12/09/24 07:06:13.13
しかし、最近のマってデータ定義疎かにする奴増えた気がする。
どんな言語でも開発手法でも、データ定義決まらなきゃ内部設計出来ないだろ。
むしろデータ定義さえ正しく出来れば、よほど特殊な処理以外はイメージ出来るもの。
データも固めずに内部処理が判らん、って何言ってんだこいつ?
864:仕様書無しさん
12/09/24 10:17:18.98
ドメインモデルはニホンザルには無理か
865:仕様書無しさん
12/09/24 12:22:37.54
> どんな言語でも開発手法でも、データ定義決まらなきゃ内部設計出来ないだろ。
> むしろデータ定義さえ正しく出来れば、よほど特殊な処理以外はイメージ出来るもの。
そんなのは、ごく一部の領域だけ。
866:仕様書無しさん
12/09/24 15:51:45.19
元々、帳票系ベースだから、分野によっては使える使えない(ところ)があるのに
867:仕様書無しさん
12/09/24 23:59:55.41
まー閉じた世界にいると、その中で優劣考えるようになって
「あれ、俺できる奴じゃね?」って思っちゃったりすることは、誰にでもあることだしね
868:仕様書無しさん
12/09/25 06:31:59.18
>>867
おれにすらあることだな
869:仕様書無しさん
12/09/28 00:12:11.73
結局EXCEL方眼紙最強ってことだね
870:仕様書無しさん
12/09/29 01:18:33.33
いいえ
最狂のうんこ
871:仕様書無しさん
12/09/29 01:59:41.94
レビューの時に新たな仕様書の存在を聞かされた
あるあるwww
ワロタwww
ワロタ・・・
872:仕様書無しさん
12/09/30 09:02:46.71
「設計書」と「テストスクリプト」を一体化したいと漠然と思ってるんだが、何か問題ある?
最近はレビューばっかで自分で書かないからそこまで具体的に考えてる訳じゃないんだけど、
見てると「テストスクリプト」が「設計書」からのコピペと化していて
同じことを二度やっているようにか思えない
書いてある内容は、
<設計書>
これをやったら → こうなる
<テストスクリプト>
これをやったら → こうなる + 必要なエビデンス + OK/NG欄
の違いでしかない
「設計書」はWordで、何となく章立てや起承転結があるかのような装いをしていて
「テストスクリプト」はExcelで、表と言うか箇条書きと言うか、項目が1意に識別しやすい
というくらいの違いしかない
873:仕様書無しさん
12/09/30 12:47:48.39
うちは設計書の右にチェック欄つけて、それをテスト仕様書として提出することにしてる
仕様に書ききれてない処理については別項目のテスト作る感じで
テストコードなんて誰も作ってないまま数年経過したアレプロジェクトだから、こうするしかないってのもある
874:仕様書無しさん
12/09/30 12:49:20.91
あ、うんこExcel仕様書なので、一処理が一セルにかかれてるみたいなやつね
改定と仕様変更でちゃんとあってるかはだいぶ怪しくなってるけど、
ドキュメントはそれしかないからテストはそれでやってる感じ
875:仕様書無しさん
12/09/30 16:09:26.66
ありがとう
出来はともかく、方法としてはそれでいいように思うんだよな
10年前はプログラム作るだけでよかったんだが、
業界の規制が厳しくなってきたのと、会社もISO9001取ったりで文書類作るようになって、
ノウハウの蓄積のない分野を力技でやってる感じで、無駄に時間ばかりくってるんだよね
いつか初めてのところに外注で出したときに
失敗させる訳にいかんかったので考えられる全分岐を書き出してURSを作ったことがあって
(要するにベンダーには何も考えてもらうことを期待しない)、
そんときも、それがそのまま設計になると同時にテストパターンになるなと思った
876:仕様書無しさん
12/09/30 18:40:18.43
ISOで設計書の標準規格作ってくれよ
プロジェクト毎に設計書フォーマットが違う、取引先の気分や社内ルール次第で納品書式が変わるのはおかしいだろ。
877:仕様書無しさん
12/09/30 19:11:36.45
>>876
UML
すべての仕様を書き切れるなら神
878:仕様書無しさん
12/09/30 23:19:04.83
UMLでUIはどこに書くんだっけ?
879:仕様書無しさん
12/09/30 23:25:46.46
ゆ、ユースケース図
880:仕様書無しさん
12/10/02 00:44:26.80
ぶっちゃけUI周りはドキュメントに起こす意味のないものも多いけどな
そんなのしこしこ用意するより動くもの、モックなんかをドキュメントの変わりに使ったほうがいい
結局何か居ても客は理解しないから、触ってからはじめて違うっていい始めるわけだし
881:仕様書無しさん
12/10/02 00:48:11.09
結局何か居ても
→結局何書いても
そういや、ダンボールとか切り貼りして工作でWebUIのモックつくるようなの
前にどっかの企業の勉強会かなんかの記事でみたなw
>>876
変化についていけない層がへばりついてる会社が多いから、規格が定まっても難しそうな気がするけどなー
あると嬉しいけれど
882:仕様書無しさん
12/10/02 09:01:30.61
変化を制御しようって考えのない会社はおおいよな。
変化を抑圧しようって会社はおおいけどw
883:仕様書無しさん
12/10/02 17:26:16.50
>>879
どうしても、ユースケ・サンタマリアを思い出す。
884:仕様書無しさん
12/10/03 02:10:46.19
サタンマリアを思い出す
885:仕様書無しさん
12/10/06 19:29:18.82
UMLがいまいち普及しないのは、保守的云々以前に
単純にExcel方眼紙と対等に戦える糞だからじゃね?
886:仕様書無しさん
12/10/07 01:52:17.45
UMLで設計したら時間も労力も余分に必要だからだよ。
細部の設計も表現しづらいし。
887:仕様書無しさん
12/10/07 02:28:43.71
UMLはモデリング言語の名前の通り、
設計したものを、UMLで記述するという風に使うものであって、
UMLで設計するという言い方はおかしいぞ。
888:仕様書無しさん
12/10/07 04:14:36.37
単純に、UMLだけで設計書が完結するわけじゃないからな。
ある程度書き方に自由度があるから、伝えやすいというのと誤解させやすいと
いうのがあるから、結局のところ短納期で毎回違う人とやり取りするには精度の
問題が今までと変わらんから。
実装側に厳密にするとコード書くのと変わらないし、設計側に厳密にすると
実装に支障をきたすし、学習しなければならないというところまできてないよな。
フローチャートレベルで授業のカリキュラムや情報処理技術者試験みたいな
公的な資格試験に組み込まれてれば違ってくるんだろうけどね。
889:仕様書無しさん
12/10/07 11:16:50.29
>>887
じゃあどうやって設計すんだよ
論理的じゃない設計してそうだな~~お前
890:仕様書無しさん
12/10/07 13:52:56.45
UMLで論理的な設計wwww
891:仕様書無しさん
12/10/07 14:58:29.08
UMLはお客さんも理解できる(ドヤァ
とか書いてあった時期あったけどそんな奴居た事無いよな
国のエロい人が色々決めてたけどあんなの揃えてたら金いくらあっても足らんし
892:仕様書無しさん
12/10/07 17:18:57.20
そもそも、ちゃんとした設計とか学んだことなくてニュアンスでやってるひとは多いと思うわー
893:仕様書無しさん
12/10/07 18:10:41.62
Excelで結合セルを駆使して設計する方法は完璧に学習した。
894:仕様書無しさん
12/10/07 18:16:43.07
途中から別のプロジェクトに入ってまず困るのは、全体を概観できる資料がないこと。
よくあるのが、全体構成図では、「営業サーバ」、「総務サーバ」とか書いてあるのに、
設計資料ではいきなり、「○○(パッケージソフト名)サーバ#1」とかになってて、
「○○#1」と「営業サーバ」の対応は、設定やってる運用グループに聞かないとわからないとか。
895:仕様書無しさん
12/10/08 01:35:51.59
UMLってIT業界において、この十年間で最も衰退した技術だよな。
フレームワークや開発手法が成熟するのが早かったから、大部分が実際の開発には不要になってしまった。
本当にドキュメントが必要な部分は、UMLで記述しきれないような複雑な仕様やシステム外の業務的な背景。
896:仕様書無しさん
12/10/08 01:40:26.22
いや、普通に書籍等に書いてある図は
UMLなんだが・・・
897:仕様書無しさん
12/10/08 02:06:38.91
フレームワークもなぁ。
要件やメカニズムのどの部分が、どのフレームワークのどの機能で実現されてるのかが
分かる資料がつくられてなかったりすると悲惨。
DI多用してたりして、末端のPGのコードとDIしたコードがバッティングしてたりすると、
PGには原因がわからない(開発用と顧客用で切り替えとかをやってたりすると最悪)
それでもそのあたりを設計したアーキテクトがプロジェクトに残ってれば聞けばわかるが、
基本設計行程が終わったら別のプロジェクトに移るなんてやりかたしてたら、
プロジェクト内に問題解決できる人がいない(または解析しないとわからない)
状態になる。
898:仕様書無しさん
12/10/08 08:03:32.57
>>895がフレームワークべったりな開発だけしか経験してないんだなとしか。
899:仕様書無しさん
12/10/08 11:14:39.30
フレームワーク作る側がUMLを書いてると思ってるのかな?ww
あんなのドカタ専用ツールだと見なして無視してるけどね
900:仕様書無しさん
12/10/08 11:58:23.35
とりあえず、本当にフレームワーク・・・というか、
その種のプロジェクトの中心人物は、社交的で、
不用意に他人をけなしたりしないけどね。
901:仕様書無しさん
12/10/08 12:04:37.02
社交的で人当たり良くても、内心で「こいつらアホだな~、猿か?」と思ってます
902:仕様書無しさん
12/10/08 12:11:50.57
いや、おまえにとってそう見える相手はフレームワーク製作者に限らないだろ。
903:仕様書無しさん
12/10/08 12:19:55.89
アホに生まれた子って可哀想。
ただでさえアホだと馬鹿にされてるのに、
死ぬ程働いても給料1000万にも届かないし。
ほんと同じ立場に立ったら自殺するわ。
904:仕様書無しさん
12/10/08 19:52:14.70
>>896
だいたい書籍書いてる奴なんて実際の大規開発現場知らない奴ばかりだろ
UMLだけで書くのに都合の悪い例を排除してるというか…そもそも実務経験がなさ過ぎて想像もできないんじゃないか?
905:仕様書無しさん
12/10/08 20:06:20.83
UML知らない奴ほど、全部UMLで書こうとする。
906:仕様書無しさん
12/10/08 23:54:32.38
ユースケース図は粒度の決め方がアナログ過ぎ、ロバスト図はある程度以上の複雑さを表現しようとすると、2次元じゃ無理ゲー。
907:仕様書無しさん
12/10/09 00:02:11.70
ユースケース図の仕様に粒度は定められてない。
どう決めるかは使う側の問題。
ロバストネス図はそもそも、不必要な複雑さを省くために考えられたもので、
本当に複雑なものをわざわざモデリングしようとするのは本末転倒。
というか、批判するなら、規格書とか、発案者の書いた本ちゃんと読めよ。
908:仕様書無しさん
12/10/09 02:15:14.11
UMLがない時代でもそれなりに設計なんかしてたんだし、特に必要という訳ではないかもしれんが、
あればより良いものだけど、要る派の言ってる事も要らない派の言ってる事も極端だよ。
909:仕様書無しさん
12/10/09 03:24:36.52
まて、ここ最近のレスで要る派なんていたか?
910:仕様書無しさん
12/10/09 03:31:45.51
極端なのは、要る派と要らない派しかいない前提の >>908
の言ってることじゃね?
911:仕様書無しさん
12/10/09 03:32:44.01
利用価値0じゃないという意見はあったけど、
アンチからみるとちょっとでも使ってる人は要るよ派に見えてると思ってる
敵を作って戦わわないと気がすまない的な
912:仕様書無しさん
12/10/09 10:09:17.74
じゃぁUMLの代わりに何つかう?っていう話になると、
結局UMLが無難ってことになる。
913:仕様書無しさん
12/10/09 10:19:01.02
Excelのセルをちまちま埋めて仕様書を書いていく快感はUMLごときでは得られはせぬ。
914:仕様書無しさん
12/10/09 12:34:17.78
それは仕様書だね。設計書とは違う。
915:仕様書無しさん
12/10/09 20:20:14.25
UMLがどうのとかはぶっちゃけどうでもいいよ。求められれば使うだけ
だがな、ドキュメントとして文章めいたこと書くのにExcel使うのはいい加減やめにしてもらいたい
二度と修正を入れない使い捨てなら構わんが、保守を考えたらExcelドキュメントなんてうんこよりひどい
916:仕様書無しさん
12/10/09 21:19:43.34
ワードで書くよ~って言ったら嫌な顔するくせに
917:仕様書無しさん
12/10/09 22:27:10.85
まともに変更履歴も残さないUMLは使い物にならない
設計書で重要なのは変更履歴と変更理由
現状はソース見れば誰でもわかる
918:仕様書無しさん
12/10/09 23:41:24.45
それはバージョン管理システムの仕事だろ。
UMLでも、変更ごとにコミットしてコメントちゃんと入れれば無問題。
バージョン管理システム使わずにコメントだけで変更履歴残そうとして
しっちゃかめっちゃかになったソースだと、ろくに流れも追えなくなる。
919:仕様書無しさん
12/10/10 07:15:32.32
たとえバージョン管理システム使ってても
diff取れないバイナリで書いてりゃ威力半減
920:仕様書無しさん
12/10/10 07:40:25.34
そのあたりは使うツールによりけりだが・・・
とりあえず、diff が取れる代替え手段ってなんかあるの?
921:仕様書無しさん
12/10/10 07:42:02.80
diff とか言い出すと、 word や Excel より TeX だよな。
922:仕様書無しさん
12/10/10 17:36:08.65
TeXだと冗長になるし、なんかそれ用のエンジン使うのが賢いんだろうな。本当は。
923:仕様書無しさん
12/10/10 20:40:25.74
>>920
エクセルに1文1セルで書いて、隣の列に
1列1バージョンで改変有無と理由を記載
フィルタを使えば瞬時に差分が見られる
924:仕様書無しさん
12/10/10 20:54:09.99
>>923
それで事足りる案件なら、自分だって Diff もバージョン管理システムも、
UML も使わないよ。
925:仕様書無しさん
12/10/10 23:46:17.39
そういうのは大抵が打ち消し線だらけだったりカラフルだったりになるから
いろいろ糞だけどね
場当たり対応をコード以外でも多用してるだけだし
926:仕様書無しさん
12/10/11 06:43:08.22
技術文章としての体裁を要求されたり、図表使ったら終わるだろ、それ。
927:仕様書無しさん
12/10/13 13:18:12.48
上流工程の資料の作成が凄いネックになってる気がしてならない。
開発者の視点で厳密に書くと「こんなんじゃユーザがわからん」といってハネられる。
ユーザにわかるように書くと表現があいまいになって、開発者には意味不明になる。
この矛盾に悩みつつ、ダメだしを回避する資料を完成させるのに絶望的に時間がかかって、
プロジェクトの予備工数がほとんど消える。
最後にはタイムオーバでダメ出しする人間が折れることになるが、
なんだかんだで、ユーザにも開発者にも3割方意味不明な資料ができあがる。
この3割方意味不明な資料を使って予備工数がない状態で開発がスタートする・・・。
928:仕様書無しさん
12/10/13 15:51:58.47
ユーザー用と開発者用それぞれ別のドキュメント作ればいいだけでは?
むしろ作るべきでは?
929:仕様書無しさん
12/10/13 16:10:43.54
まず、そのための工数がとられてるプロジェクトをみたことがない。
あと、開発スタート後に鬼のように湧いてくる仕様変更を、
二重化したドキュメントに反映してメンテナンスしていくコストも大変。
930:仕様書無しさん
12/10/14 17:30:47.51
dfdとer(テーブルと多重度のみでOK。カラムは主キーのみでいい)意外不要。
931:仕様書無しさん
12/10/14 17:43:10.49
一人で作る程度のシステムで、クライアントがそれで納得してくれて、
その後の運用メンテも同じ担当者が続ける前提なら、それでなんとかなるかもしれん。
932:仕様書無しさん
12/10/15 02:52:27.14
成果物が糞じゃない前提なら、ドキュメントの必要性は減ると思うよ
webとかだったら画面遷移とかあると理解度は上がると思うけど、
マニュアルと動くものがあれば事足りるからなくてもいい
クラス図があると関連は理解しやすいけど
名前やパッケージ、IDEの機能で追っかけるのは簡単だからなくてもいい
まぁ作成や保守にかかるコストと教育にかけるコストと、教育対象者の質次第だな
劣悪なのはドキュメントがいくらあっても結局理解しないし、
できる奴は(ちゃんとしたシステムであれば)その場にあるので難なくこなせると思う
933:仕様書無しさん
12/10/15 12:49:11.89
技術的なドキュメントとして重要なのは基本設計と運用設計のほうだと思う。
基本設計資料がちゃんとしていれば、詳細設計は無くてもなんとかなる。
でも今、実際は、基本設計、運用設計、詳細設計で、ドキュメント量の比率としては、2:1:7 ぐらいじゃないか。
自分は、6:3:1 ぐらいでもいいと思う。
934:仕様書無しさん
12/10/15 15:22:41.07
詳細設計書 = ソースコードだからねぇ。
本当の必要な量で言えば、一番多い。
だけど、ソースコードを補足するものだけに
すれば、逆に少なくなる。
詳細設計の量が多いところは
ソースコードが詳細設計書だって
わかってない。