[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 10/16 11:50 / Filesize : 244 KB / Number-of Response : 935
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

仕様書、設計書について



1 名前:仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの?」「意味あるの?」といった物に出くわす事も少なくない

しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ

・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する?(Word/Excel/HTML/手書き!)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの?
・こんな仕様書/設計書は、ぶっちゃけアリ?ナシ?

などなど、設計書にまつわる話題を募集

724 名前:仕様書無しさん mailto:sage [2012/09/06(木) 00:42:28.17 ]
安かろう悪かろうの需要がまだあるうちは何とかなるだろうけど、未来はないよね

725 名前:仕様書無しさん mailto:sage [2012/09/06(木) 01:18:00.25 ]
今の状況がわかってない人達が、自分で自分の首を絞めてるだけ?

726 名前:仕様書無しさん [2012/09/06(木) 06:06:54.00 ]
>>722
ろくな仕事もないのに仕事をした振りできる公益法人やら天下り団体の職員が喜ぶんですよね。

そういう予算だけはあるけど仕事がないところがなんでもかんでも発注するし、
使い勝手とか機能とかがでたらめな内容で発注しまくるものだから
システム開発する側もろくなものを作らず、
結果として無能の再生産をする。


727 名前:仕様書無しさん [2012/09/06(木) 08:08:29.54 ]
基本も詳細も設計書は顧客向けに出すものではなく、V字モデルのテスト設計資料として活用するもの
そうやれてる企業は存在しないけどw
顧客向けなんてマニュアルと営業パワポでいい

728 名前:仕様書無しさん [2012/09/08(土) 11:30:54.54 ]
このスレダメすぎ。
仕様書、設計書、言ってる地点でアウトなんだよ。
いいかげん、ウォーターフォールを滅ぼさないと日本が滅びる。

729 名前:仕様書無しさん mailto:sage [2012/09/08(土) 11:50:04.08 ]
顧客

マニュアル

結合テスト

単体テスト

コーディング

仕様書

どうしてもウォーターフォールやりたいなら、こういう順序がいいと思うよ、本気で。

730 名前:仕様書無しさん [2012/09/08(土) 12:11:47.34 ]
「コードもないのにどうやって結合テストするの?」
とか言ってんの、もうねアホかとバカかと。

これはソフトだけの話じゃないんだよ、ハードだって開発はそういうもんなんだよ。
車の開発をしようとしたら、まずテストコースを準備する。
開発チームごとニュルに行く。
そこから始まる。当たり前の話。

731 名前:仕様書無しさん mailto:sage [2012/09/08(土) 12:41:35.07 ]
テストコースなんてどこにでもあるじゃん。
俺なんか公道でドリフトの練習しまくったよ。
字乞田けど。


732 名前:仕様書無しさん mailto:sage [2012/09/08(土) 13:52:16.21 ]
ツーホー



733 名前:仕様書無しさん mailto:sage [2012/09/08(土) 13:52:42.14 ]
面白いと思って言ってるんだろうから、そっとしておいてあげような

734 名前:仕様書無しさん mailto:sage [2012/09/08(土) 15:11:28.44 ]
「どこにでもある」
つまり、顧客環境=開発環境が当たり前の場合、
理論と実際の誤差が生じていてもなんとかなってるんだ。

逆に、特殊環境で動かさなければならないソフトの場合だ。
そのエミュレータを手前に準備しなければコーディングしにくい。

「当たり前にないテスト環境を整えることを先にやらなければならない」

この手順を突き詰めると、ウォーターフォールの誤謬に直面する。
そこから、テスト・ファーストという考えに辿りつく。

735 名前:仕様書無しさん mailto:sage [2012/09/08(土) 15:30:21.57 ]
> そのエミュレータを手前に準備しなければコーディングしにくい。
そんな事情は考慮しない。設計どおりのコーディングをすれば、
問題なく動くコードが出きるはずだ。

736 名前:仕様書無しさん [2012/09/08(土) 15:50:09.51 ]
>>735
それは、ベテランの人間が小規模なプロジェクトをクリアする場合には当てはまる。
それ以上にはならない。
普通レベルの人間に真似させられないだけでなく、
高品質なプログラムにならない。
結果、顧客のダメだし確率も上がり、開発期間短縮にもならない。
リスクが高いので、趣味の範囲にとどめるべき手法だといえる。

737 名前:仕様書無しさん mailto:sage [2012/09/08(土) 17:56:39.57 ]
よく、アジャイルは、ウォーターフォールを細かく繰り返すことだと言うけれど、
その認識じゃー、うまくいかないに決まってる。

なぜなら、ウォーターフォールモデルの手順自体が真逆だから。
>>729が正しい順序なのである。

それで、アジャイルがうまくいかないと嘆くことになるんだが、
ウォーターフォールの根源的問題を繰り返したら、
もっとうまくいかなくなるのは当たり前。

738 名前:仕様書無しさん mailto:sage [2012/09/08(土) 18:38:52.54 ]
ボトムアップ的なやり方だけじゃダメじゃね
ボトムアップとトップダウンを混ぜたようなやり方のほうが

739 名前:仕様書無しさん [2012/09/08(土) 20:07:59.54 ]
顧客←────┐
↓            │
マニュアル←─-┤
↓            │
結合テスト←─-┤
↓            │
単体テスト←─-┤
↓            │
コーディング─→┤
↓            │
詳細設計──→┤
↓            │
基本設計──→┤
↓            │
要求定義──→┘

トップダウンとボトムアップはそうなんだけど、
実際的な流れをより明確にするとこうなる。
テスト⇔コーディングが日常。
より大枠のところで、バージョンアップだ。

740 名前:仕様書無しさん mailto:sage [2012/09/08(土) 20:11:22.02 ]
>>739
試行錯誤が抜けてる。

全く同じ物のパラメータ違いを
作るなら話は別だけど、

プログラムで同じものは作らない
(自動生成すればいいから)

となると、ほとんどが新しいものであり、
試行錯誤しないと実現可能であるかもわからないものがある。
やってみて(コーディングしてみて)、この方法はダメだから
違う方法にするというのはよくある話。

そういう試行錯誤コーディングで
いちいちテストなんてやっても無駄。

741 名前:仕様書無しさん [2012/09/08(土) 20:29:03.63 ]
>>740
テスト⇔コーディングが試行錯誤だよ?
というか、試行錯誤のコーディングでテストをやらない?

なんて、嘆かわしい。
むしろ、そこはTDDを絶対オススメしたい。

742 名前:仕様書無しさん mailto:sage [2012/09/08(土) 20:47:43.94 ]
基本的にはテストケース考えながら、作り込む方だな、俺は

底辺部分はテストケースはわりと考えなくてもいいんだけど
中間部分はテストケースを考えながらやるし、単体テストもやりやすい
上位部分は流してみないとわからないから、ラフに作って
全体流すときに徹底的につぶすほうかな

要求が一般的なわりと知られてるやり方が出来るのは
先に設計書作れってうるさいみたいだね



743 名前:仕様書無しさん mailto:sage [2012/09/08(土) 21:32:23.97 ]
>>742
「テストケース考えながら」って、リストをエクセルなんかで書きなぐりながらってこと?
実行しながらじゃなく?

744 名前:仕様書無しさん mailto:sage [2012/09/08(土) 21:43:20.95 ]
え、分岐のないやつしかやったことないの?

745 名前:仕様書無しさん [2012/09/08(土) 21:56:30.34 ]
テスト駆動の話なんだけど、テスト用プログラム、走らせてる?
慣れると楽だよ。ある程度使いまわせるし。
なにより、脳内シミュでは完璧だったのに、バグがはじき出される時ある。
焦るけどホッとする。
そして、性能テストも同時にやっちゃう。
劇的な速度増加手段がそこで発見できることもある。
絶対いい。

テスト用プログラムっていっても、うまく作る必要なんか全然なくてさ、
つーか、統合開発環境がすでにテストプログラムなわけだし、
誰でも無意識にやってるはずのものなんだよね。
それを意識的に、プロジェクトフォルダの中には必ずテストソース入れるフォルダも作る。
で、なれると、テストコードを先に作った方がいいことに気づく。

結合テスト←─-┤
↓            │
単体テスト←─-┤
↓            │
コーディング─→┤

結合テストから入るってのは、C言語なら最初main()作って動かす。
PHPならZAMPP入れて動かす。
ただ、それだけのもの。出力真っ白、それがバージョン0.01
それをやるべき。つーか誰でもやってる。当たり前の話。

746 名前:仕様書無しさん mailto:sage [2012/09/08(土) 22:08:12.21 ]
>>739 続き
どうして要求定義が一番最後なのか?
顧客ヒアリングの段階でまとめなければいけないのではないか?

もうね、アホかとバカかと。

例えば、「wordのドキュメントをそのままwebページにしてくれ」と
顧客が言ってくるとする。
はいはいと言って、見積もって基本設計やって

そして、・・・その要求が不可能なことに「途中で」気づくのだ!

もちろん、これはごく単純な例で最初の段階で無理だと断れるパターンだが、
実際問題、コーディングをちょっとやってみないと、
どんな要求が実際消化できるかわからない!(そして正確な見積も!)
そういうときは、正直に一巡するまで待ってもらう。
もしくはその顧客はあきらめ、次のために研究しておくべきだ。

それを、顧客即要求定義みたいに書くから、それが可能であると
勘違いされてしまう。これは深刻なミステイクだ。
後から顧客に怒鳴られ減額されるのは本当に嫌なものだ!

747 名前:仕様書無しさん mailto:sage [2012/09/08(土) 22:08:27.74 ]
> 当たり前の話
?

748 名前:仕様書無しさん [2012/09/08(土) 22:32:38.48 ]
当たり前の話!
ウォーターフォール滅びろ!
みんな迷惑してる!

749 名前:仕様書無しさん mailto:sage [2012/09/08(土) 22:37:38.90 ]
その手の流れにもってくと、勘違いする人が出るような
当たり前だと思ってるだけで、実際にやってる人が...

750 名前:仕様書無しさん mailto:sage [2012/09/08(土) 22:43:31.84 ]
テスト書く為に早出、退行テストとベンチマークの為にサー残するならやっていいよ。つまり時間外でやれ
みたいなのだから一向に流行らん
それでもやるのが何人かいるのだけがまだ救いか


751 名前:仕様書無しさん mailto:sage [2012/09/08(土) 22:45:38.41 ]
時間で働いてる人に効率化とか無いですから

752 名前:仕様書無しさん mailto:sage [2012/09/08(土) 22:50:00.81 ]
>>741
> テスト⇔コーディングが試行錯誤だよ?
> というか、試行錯誤のコーディングでテストをやらない?

やらない。テストの工数ってのをちゃんと意識していれば、
とてもやろうとは思わない。

試行錯誤ってのは、何度も仕様に修正が入るということ。
つまり、テストもそれだけ修正が入るということ。

テストがあればリグレッションを防げるが
試行錯誤中はリグレッションを防げない。
なぜなら仕様が変わるからテストが失敗するのがほとんど。
だからそんな状態では人間が流行ったほうが早い。



753 名前:仕様書無しさん mailto:sage [2012/09/08(土) 22:52:41.52 ]
工数稼ぎのためにまともそうに書いてるだけですから

754 名前:仕様書無しさん mailto:sage [2012/09/08(土) 22:57:11.69 ]
一生懸命やってますアピールしても土方の保身には全く役に立たないからね

755 名前:仕様書無しさん [2012/09/08(土) 23:04:23.41 ]
>>752
そこまでカオスな研究段階だったそうだろうか。
それでも、可能な限りテストプログラムの稼働、テスト環境の整備、
テストデータの自動生成など提案したいが・・・
テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。

756 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:26:13.67 ]
> テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。

どんだけ少ないんだ?

極端な例を出せば、網羅テストなんかやると
数年単位の時間がかかって現実的ではない。

必要ないテストを省くなどして、
どうやってテスト時間を短くするか考えなきゃならないのに。

757 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:30:14.81 ]
>>756
そこまでタイトな網羅テストが必要なプログラムかよ!
そんなの知らねーな、今は一般的な話しをしているのだ。

758 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:31:31.81 ]
テストがテストになっているかをテストするためのテストで今忙しい

759 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:36:16.58 ]
TDDのテストは品質保証が目的ではないいう流儀か
そういう類のテストを工数稼ぎと看做す場では受け入れられんだろうな

760 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:36:43.91 ]
自己採点が基本でしょ、プログラム系は
受験みたいに点数つけてくれる人はいない
書いて終わりじゃないところが、紙の試験とは違う

761 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:41:28.27 ]
自己採点でクビか契約更新かを決めれたらいいのにね

762 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:43:24.26 ]
> クビか契約更新か
それは、人が人を判断してるってことでしょ



763 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:58:01.12 ]
なぁんだ
なぁんだとはなんだ
なんだとはなんだとはなんだ
なんだとはなんだとはなんだとはなんだ
オペレーターズサイドもいっかいやってみようっと。あれ?マイクどこにしまったかなぁ・・・

764 名前:仕様書無しさん mailto:sage [2012/09/08(土) 23:59:02.33 ]
>>756
テストしたことないでしょ。

765 名前:仕様書無しさん mailto:sage [2012/09/09(日) 00:01:40.83 ]
雇用側とかの認識がおかしいから、人集めるにしても、とんでもになってるとか

766 名前:仕様書無しさん mailto:sage [2012/09/09(日) 00:12:03.67 ]
>>764
テストしたことないでしょ?

スローテストって言葉知ってる?
テストが短時間で終わるためには、
短時間で終わるように工夫しなきゃいけないんだよ。

自動化すればすぐに終わる?
アホだな。

銀の弾丸はない。

767 名前:仕様書無しさん mailto:sage [2012/09/09(日) 00:16:03.48 ]
自動化してもテストは際限なく増えていく。
増えていけば必ず時間がかかる。

自動テストに時間が掛かるって状況になっていないのなら
それはまだテストが少ない段階なんだなぁとしか思えない。

768 名前:仕様書無しさん mailto:sage [2012/09/09(日) 00:27:15.25 ]
やってる内容によっては、いくら自動化しようがダメ出し食らうだけじゃね
テスト自動化したら終わりってわけじゃないような

769 名前:仕様書名無しさん mailto:sage [2012/09/09(日) 02:15:34.13 ]
ウォーターフォール否定的なヤツが多いが、一時的に大量に人集めて、大規模システムを納期どおりに一定の完成させるにはウォーターフォールしかないのが現実。

小規模で最適な開発方式をそのまま大規模に適用させられると思ってるおバカさんが多すぎる。

770 名前:仕様書名無しさん mailto:sage [2012/09/09(日) 02:18:18.41 ]
プロマネにも言えるが小規模PJを幾つも上手く回すスキルと、大規模PJを完遂させる能力は質が違う。

771 名前:仕様書無しさん mailto:sage [2012/09/09(日) 02:30:21.49 ]
ちゃんとした体裁のドキュメントなんて完成に近づいてからやりゃいいけど、
ある程度決めないといけない内容を残す必要もあるから、そういう意味では先に造らないといけない部分はあるんだよなー
でも、ウォーターフォールはその残すためのものを最初から完璧に作ろうとしては
書き直して無駄な工数を裂くことがおおくて、その帳尻あわせにケツが縮まって燃える(´・ω・`)

772 名前:仕様書無しさん mailto:sage [2012/09/09(日) 02:31:09.88 ]
まともなとこは、人海戦術的なことはやらんでしょ



773 名前:仕様書無しさん mailto:sage [2012/09/09(日) 02:32:32.61 ]
TDDはある程度コーディングの実力が伴わないと難しいと思うよ
試行錯誤して手探りしてるレベルの人だと、いきなり適切なテストケースを用意するのはかなり難しい
だって、はじめたばかりだったり知識が足りてない段階だと、
どういうテストを用意すればいいかわからないし、そもそも作るものがどういう実装になるかを想定できないからね

もちろん、要所を押さえれば知識が浅いうちでもそれなりにはできるようにはなるとは思うけれど
試行錯誤があまり必要ないくらいにすぐ目的のコーディングに入れるようになるまでは、いきなりテスト作成はきつい
自分も結構実装前段階でテスト準備はうまくやれないから、そういうのはなんとなくわかる

でも一通りやれる事や実装の見通しが実装に入らなくても想定できるようになってくると、
テスト作成から入るって意味もわかると思うけどなー

網羅テストのような(大して意味がないけどw)のがテストとして求められてるようなものなら、そういうわけには行かないけどさー

774 名前:仕様書無しさん mailto:sage [2012/09/09(日) 02:32:54.97 ]
今の要求は、人がいれば出来るような簡単なもんじゃないと思うけどね
簡単なの探すほうが大変じゃね

775 名前:仕様書無しさん mailto:sage [2012/09/09(日) 02:34:31.80 ]
つかまずその大規模プロジェクトって物自体が否定されてるようなもんだからなw
頭とケツしか考えられないから、ウォーターフォールしか選択肢がない
仕様書とか設計書とかって、この無駄にピザってしまった縦割り開発の
伝言ゲームのためにあるようなもんだし、無駄だよやっぱ

776 名前:仕様書無しさん mailto:sage [2012/09/09(日) 02:38:21.62 ]
新規じゃないのは、枯れてくれば、少人数になっていくような

777 名前:仕様書無しさん mailto:sage [2012/09/09(日) 02:53:54.52 ]
>>770
料理人とかでも同じだな、大規模宴会料理と小料理屋の料理じゃ全然違うと。
まあ、どの業種でも言えることだけどね。

778 名前:仕様書無しさん mailto:sage [2012/09/09(日) 02:59:07.84 ]
料理系とかは下積み長い人達が割と集まる(める)から成り立つんだよ
人がいればこなせるほど、甘い世界じゃないだろ、歴史があるところは

味抜きでやってるとこは、先ないだろうね、料理系

779 名前:仕様書無しさん mailto:sage [2012/09/09(日) 03:05:01.39 ]
好きこそ物の上手なれっつーか、興味をどれくらい持ってるかでのピンキリ差が激しいし、
実際の土方みたいに体動かしてりゃなんとかなるわけでもないから、数いりゃいいってもんでもないしな。

780 名前:仕様書無しさん mailto:sage [2012/09/09(日) 03:27:22.13 ]
> 実際の土方
やってる人に経験値高い人達がいるから、成り立ってんじゃねえの?

781 名前:仕様書無しさん mailto:sage [2012/09/09(日) 03:57:35.35 ]
>>778
> 人がいればこなせるほど、甘い世界じゃないだろ、歴史があるところは

そうでもない。
例えば皮むき。下ごしらえなんかは、時間がかかる上に
テクニックはそんなに必要ない。そういう所に人を入れれば
○人でできる量を増やすことが出来る。

うまく人を配置すれば、一流の料理人をたくさん集めなくても
同じ質で生産量を増やすことが出来る。


そして、現実問題に対応しないといけない。
現実問題というのは、団体さん100人が来た時に対応できないといけない。
できるかどうかではなく、要求が先にある。

機材を増やした所で生産量は増えない。
人を増やすことでしか対応できないこともある。

782 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:01:40.32 ]
どっかが、やれば出来るって言って素人に刺身切らせてましたのと同じ発想なのがお笑い



783 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:04:10.22 ]
>>781
逆読みすれば、
ど素人でも出来るようなことをやってる
っていってるような

784 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:04:18.37 ]
素人 と 刺身を切るスペシャリストの
違いがわかってないの?

一流の料理は作れなくても
刺身を切るのはうまいって人もいるだろう。

785 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:09:37.97 ]
料理自慢って言われてる人はいるだろうけど
自分からいう人は、あんまりいないんじゃね

786 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:14:56.89 ]
>>783
だれもど素人がやるなんて言ってないしw

えとさ、ある作業があっとして、
それを一つスキルが低い人でも出来るようにしたら
その分、生産量は上がるよね。

お前も、この考え方のその恩恵に預かってるはずだが?
例えば音声合成をするための技術はないが、
ライブラリがあれば、スキルが低くても音声合成ができる。

787 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:35:32.42 ]
>>786
その時点で開き直ってるような
ま、やらせる相手によるのかもしれんけど

788 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:41:04.15 ]
>>787
日本語でお願いします

789 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:43:07.15 ]
一流でなければど素人って言うような人だからねぇ。

そいつにとっては、一流の野球選手じゃなければ
甲子園に行ったとしてもど素人なんっだろうねw

790 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:46:30.03 ]
そういう例え方しかできんの?

791 名前:仕様書無しさん mailto:sage [2012/09/09(日) 04:48:48.86 ]
20年前のやり方が通用せん分野も出てきてるのにね

792 名前:仕様書無しさん mailto:sage [2012/09/09(日) 05:37:09.93 ]
>>766
そうか。
お自動化して数年かかるようなテストやってるんだろ?
自動化しなかったら、もっと時間がかかるだろw



793 名前:仕様書無しさん mailto:sage [2012/09/09(日) 06:06:09.63 ]
テストの実行にそんなに時間がかかるのだとしても、
それでもテストは繰り返すべき、だな。
基本、マシンスペックを上げる。放置プレイも重要。

そこまでの規模なら、テストの前にコンパイルで相当時間がかかるはず。
Googleはコンパイル時間が短い言語を独自開発してる。
Cでも満足できないらしい。
これはとどのつまり、テストの周期を短くするためだ。
場合によっては新言語開発さえ必要、ということ。

794 名前:仕様書無しさん mailto:sage [2012/09/09(日) 07:38:36.42 ]
料理人どうののたとえ話じゃなくて、普通にマの話で説明すべきだろう
マ板住人が料理人の仕事の詳細を例えに使えるほど理解してるわけないだろう
余計ややこしくなるだけ

795 名前:仕様書無しさん mailto:sage [2012/09/09(日) 12:36:01.37 ]
>>793
> そこまでの規模なら、テストの前にコンパイルで相当時間がかかるはず。

ん? なんでテストの時間と
コンパイル時間が関係あると思ってんの?

796 名前:仕様書無しさん mailto:sage [2012/09/09(日) 12:59:17.63 ]
>>792
たとえば新しいOSが増えたら、テストがその分増えるわけ。
ウェブアプリだったら、テスト時間×ブラウザ数になるわけ。

自動化関係なく、テストは時間がかかるもの。
完璧なテストは数年かかるからやれない。
だから手抜きする。

自動化でそれが0になるわけじゃなく減らせるだけ。
自動化してもやっぱり手抜きは必要。

797 名前:仕様書無しさん mailto:sage [2012/09/09(日) 15:17:34.16 ]
>>796
君が「自動化=テスト項目の削減をしない」って勝手に定義してるだけだろ。

798 名前:仕様書無しさん [2012/09/09(日) 16:26:27.82 ]
自動化は時間の削減であって項目の削減ではないだろ
区別して考えろよ

799 名前:仕様書無しさん mailto:sage [2012/09/09(日) 16:28:24.71 ]
日本語化したら、コンピュータが勝手に動いてくれると思ってるのかしら、かしら
テスト自動化したら、問題が減っていくと思いたいのかしら、かしら

800 名前:仕様書無しさん [2012/09/09(日) 16:52:44.47 ]
ランダムテストみたいに入力をランダムに振るテストを「自動化」とか呼んでそうだな

801 名前:仕様書無しさん mailto:sage [2012/09/09(日) 17:14:45.41 ]
CI

802 名前:仕様書無しさん mailto:sage [2012/09/09(日) 17:19:29.48 ]
動かすより、テストすること考えて作るほうが難易度高いこともあるのにね
テストの自動化出来ましただけ言ってると誤解する人増えそう



803 名前:仕様書無しさん mailto:sage [2012/09/09(日) 19:05:42.06 ]
全自動になる前の麻雀で初心者がハマる状況に似てるな、この業界

804 名前:仕様書無しさん mailto:sage [2012/09/09(日) 20:17:35.37 ]
連チャンに耐えられる人達ってどんくらいいるんだろうね

805 名前:仕様書無しさん mailto:sage [2012/09/09(日) 21:34:54.77 ]
曖昧な書き方して逃げ道作ってる奴ばっかw

806 名前:仕様書無しさん mailto:sage [2012/09/09(日) 21:36:21.09 ]
保身に拘るのは最早職業病

807 名前:仕様書無しさん mailto:sage [2012/09/09(日) 21:44:46.40 ]
書いたら、終わりじゃないのにね

808 名前:仕様書無しさん mailto:sage [2012/09/09(日) 22:32:58.63 ]
>>755
> テスト工数は多くなっても自動化すれば、トイレ行ってる間に終わるからな。

終わらねーよw

809 名前:仕様書無しさん mailto:sage [2012/09/09(日) 22:38:07.65 ]
テストを自動化したって、時間がかかるものはかかる。

make testをしたらわかるだろ?

810 名前:仕様書名無しさん mailto:sage [2012/09/09(日) 23:44:51.16 ]
1.日本は新卒文化
2.経験不要、コミュ力重視で採用。
3.プログラムは下っ端の仕事

上記理由から、プログラマの大部分は
ド素人であることが昔からこの業界の常識。

ド素人集団でもシステムを作り上げられる唯一の開発手法がウォーターフォール。

811 名前:仕様書無しさん mailto:sage [2012/09/09(日) 23:53:34.93 ]
自動化はJenkinsみたいなCIサーバー使ってコミットされたらビルド→自動テストを
裏で動かせるのが肝だろ。CIサーバー使わなくてもビルドスクリプト使って
ある程度の自動化が出来てないと恩恵は少ないわな。

812 名前:仕様書無しさん mailto:sage [2012/09/10(月) 00:13:41.27 ]
え、大規模でも統合環境じゃないの?



813 名前:仕様書無しさん mailto:sage [2012/09/10(月) 01:27:43.84 ]
>>811
うん、コミットする前に自動テストやったら
コミットするまで時間かかるから
自動テストは、コミットが終わった後でやるんだよねw

814 名前:仕様書無しさん mailto:sage [2012/09/10(月) 01:49:17.50 ]
>>813
普通に自分の環境でビルド通して、自分が書いた分の自動テストが通ったら
コミットするだろ。 

ただプログラム書いたやつなら分かるが、自分の環境だと問題なくても
他人が修正してコミットしたモジュールと合わせるとビルド環境やデプロイ
環境でビルドが通らなかったりテストが通らなかったりするから、要所要所
でビルドと自動テストをして早い段階でエラーを検知する仕組みにする。 

今はCIサーバーとかがあって、そういうのが自動で組み込める便利なツールが
あるからそれを使えるならそういうのを使えばいいだけ。

設計書だけしか書けない人はこういうツール類が昔に比べ遥かに便利で
高速化されてることを知らないのが多いね。 まあ、普通に開発してる
人間でもアンテナ張ってても引っかからないことが多いけどね。

815 名前:仕様書無しさん mailto:sage [2012/09/10(月) 07:08:33.88 ]
設計書だけしか書けない奴ってホントつかえねーよな
使えなすぎてガンガン首切られてる
スキル0のゴミだから転職もできない

816 名前:仕様書無しさん mailto:sage [2012/09/10(月) 15:26:31.58 ]
本日見つけた迷言

「フレームワークを使わないのがXXX(言語名)だ。」
「俺のOOPはフレームワークには負けない。」


817 名前:仕様書無しさん [2012/09/11(火) 09:48:33.01 ]
すべてのプロジェクトに当てはまる万能な開発手法はない。
しかし、脱ウォーターフォールは万人にオススメできる。
日常のツール作りから原発まで脱ウォーターフォールを真剣に考えるべきだ。
あなたが、ウォーターフォールでうまくいっていると思っているなら、
実際は、ウォーターフォールが実践されていないからだ。

818 名前:仕様書無しさん mailto:sage [2012/09/11(火) 10:46:38.85 ]
それは言えてる

819 名前:仕様書無しさん mailto:sage [2012/09/12(水) 06:48:45.39 ]
ウォーターフォールでも何でもいいけど、下流の馬鹿マが内部設計すら出来ないのは勘弁してくれ。
概要設計から製造までお前んとこで請け負ってるのに、何でもいちいち聞いてくんな!!
「こんな内部変更が必要になるなんて聞いてない。」って、外部インターフェースのプロトコル変更は真っ先に挙げてるし、その対応見積り出したのあんただろ。
しかも、「じゃあ、そのプロトコルのサンプルソースくれ。」とか、知らないで見積ったのかよ!!
100歩譲って知らなかったとしても、今まで何も調べてないのかよ!!

820 名前:仕様書無しさん [2012/09/12(水) 06:54:58.89 ]
印刷設計書が書きにくいから計算結果もDBに書き込むようにしてほしいと言われた。
書きにくいから・・・・そこ書くのがてめぇらの仕事だろ。

821 名前:仕様書無しさん mailto:sage [2012/09/13(木) 00:39:01.05 ]
>>755
お前、それただのデバッグなんだが。
デバッグのことをテストって言ってね?w

822 名前:仕様書無しさん mailto:sage [2012/09/13(木) 01:45:54.74 ]
中抜きは下選べるだけマシじゃん
上は選べないんだぞ



823 名前:仕様書無しさん mailto:sage [2012/09/13(木) 01:50:06.87 ]
>>819
その程度の会社と知らないで契約したのかよ!!

>>821
えっ

824 名前:仕様書無しさん mailto:sage [2012/09/13(木) 06:53:32.86 ]
>>823
情報漏洩防止手続きとか、レートとかあって、選択肢無いんだよ!!
しかも、中のマはコロコロ変わるし、ハズレが多いんだよ!!






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<244KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef