アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
請負法なんとかしてくんない？ (スコア:1, 興味深い)
モジュール単位で各社に振り分けてるんだけど、
各社のリーダのみとのコンタクトだと危なっかしくてしょうがない。
ソフトウェアは図面だけでやり取りできるものではないのだから。。。
Re:請負法なんとかしてくんない？ (スコア:1, すばらしい洞察)
派遣であれば責任者以外にも直接指示が可能ですよ。
Re:請負法なんとかしてくんない？ (スコア:0)
けど、それは勝手な理屈だなと思います。
Re:請負法なんとかしてくんない？ (スコア:1)
何かまずいことがあるのでしょうか。むしろ、多分にアナログ
な要素が入るハードより、仕様書でのやりとりがしやすい
分野ではないかと思うのですが。
# 純粋に興味だけの質問ですが、御教示頂けると幸いです。
Re:請負法なんとかしてくんない？ (スコア:1)
行うべき処理があいまい（他モジュールとの機能分担が曖昧だと調整が非常に面倒です）
処理の細部が不明（記載してない）
エラー時の処理が書いてない
こんな仕様書が多いです。
# ひどいのになると１行しか書いてない...
notice : I ignore an anonymous contribution.
Re:請負法なんとかしてくんない？ (スコア:0)
Re:請負法なんとかしてくんない？ (スコア:1)
まず、フォロー下さった皆様、ありがとうございました。
読んでいて感じたのは仕様書を作りこむことが出来ない、
というよりは、やってられない、ということのような
気がします。
H/Wの場合、仕様書を作りこんでから設計というのが基本
なので、入力と出力が仕様通りであれば、内部構成について
顧客からクレームがくることはないです。
もっとも、私の場合、IEEEという神様仕様がいるため、
仕様決定のために負荷が激増することはないからできている
ことではあります。
商品規格/ソリューション提案から仕様書に落とし込む際に、
効率的で抜けのでないような方法が確立されれば、品質や
全体の効率が改善するのかも知れませんね。
Re:請負法なんとかしてくんない？ (スコア:0)
＃新入社員のころ聞かされたときは「ハァ？」だったけど、今は身にしみてる…
Re:請負法なんとかしてくんない？ (スコア:0)
Re:請負法なんとかしてくんない？ (スコア:0)
Re:請負法なんとかしてくんない？ (スコア:0)
2、要求仕様書などの○○仕様書を作る
3、コレを満たすのつくってちょと仕様書を下に渡す
4、下は設計書作成やプログラム作成を行う
5、QAテストや納品テストで「仕様書にない」仕様が発覚する
6、1から3の部分が面倒なので、直接1->4という流れが出来る
7、5と6を繰り返す
8、顧客に次のバージョンで要求に対応するからと頭を下げて納品
9、次バージョン開発でも当然1から8を繰り返す
ということになっているのではないかと妄想ぉ
ハード屋さんはビックリするかもしれませんが、不具合分類一覧とか
つくると3割以上が「仕様漏れ」とかに分類されていたりするプロジェクト
が石を投げれば当たるくらい存在するような気がします。
#さらに「設計ミス」の分類とかを分析すると実は「仕様漏れ」が原因な不具合だったり
Re:請負法なんとかしてくんない？ (スコア:0)
>何かまずいことがあるのでしょうか。
ハード：
- 商品企画
- 仕様書／設計図
- 製造
ソフト：
- 仕様書
- プログラム
- ビルド／コンパイル
くらいじゃ。仕様書は曖昧で矛盾だらけなので、
「仕様書通り」にプログラムを作ることは、
ほとんどの場合不可能な場合です。
Re:請負法なんとかしてくんない？ (スコア:0)
ハードは、単純な作業を高速に繰り返すのが得意です。
ソフトは、複雑な手順を状況に応じて適切に行うのが得意です。
ソフトもハードもいかなる状況でも適切に動作することが求められますが、ソフトの場合、入力/出力される情報の種類は多く複雑なため、
仕様書上で検討しても、考え漏れることは良くあります。
(例: エラー発生時の処理とか、メモリ獲得に失敗するとどうするとか)
したがって、ソフトの場合、やりたいことが単純でも、いざ作成してみると、予想外に結構複雑といったことが良くあります。
「こんなこと