【IT】正直詳細設計書いらないよね？【SE】

>>60
わいがコード職人やで

Javadocがあれば、詳細設計書は要らないかも。
ドキュメントは、後で使うものだけにしたほうがいいというのは同意。

コードいじくりまわしているプログラマが一番気持ち悪い。

一応書いとかないと貰ったソースで謎のフラグが行ったり来たりしてカオスになるぞw

https://employment.en-japan.com/desc_871394/?arearoute=2&aroute=0&caroute=0701&PK=05231C
日本情報技術取引所
多重ぐるぐるドナドナ案件
コンピューターレスキュー
角度があがります

http://www.computer-rescuer.com/
https://create-solutions.jp/

ハラスメントが繰り返し起きている。
焦点となるのは加害者本人で、彼らの下劣で攻撃的で、
場合によっては違法ですらある行為の温床となった企業や業界の体質ではない。
だが、行為が単体で起こることはない。 企業はこうした人間を雇って昇進させ、
その仕事により収益まで得ていたわけだが、原因は構造的なものだ。
加害者の地位が高くなればそれだけ、抑制もバランスも機能しなくなる。

新日鉄住金ソリューションズ代表取締役社長 謝敷宗敬
副社長執行役員 北村公一
専務執行役員 近藤一政
常務執行役員 大城卓
常務執行役員 森田宏之
上席執行役員 國本衛
上席執行役員 福島徹二
上席執行役員 梶原敏弘
上席執行役員 南悦郎
執行役員 吉田佳子
執行役員 玉置和彦
執行役員 吉田勝彦
執行役員 熊本吉弘
執行役員 小池公彦
執行役員 黒木益尚
執行役員 福田成昭
執行役員 北沢聖
執行役員 鶴田進
執行役員 川崎淳
執行役員 齋藤聡

詳細設計書ができる前に開発が始まる、開発がほぼ終わってから詳細設計書に作業がもどるってことが起こるってことは詳細設計書は開発には必要ないんじゃないかって思っちゃうよね。あくまでもそのあとの保守に必要なだけなんじゃないかとか

パイプラインで作業やるのに、設計情報全部出そろってから開発するわけないんだ。
今はこなれてない設計でも、見切り発車して開発しはじめるパイプライン上等なんだ。

パラメータはどこで書くんだよ

>>12
ありがとうございます。
今の現場は、というか新卒での初の案件ですが…
画面ごとに単体テスト仕様書を書いてテストしてます。
おっしゃる通り画面スクショとDB取得結果を証跡としてエクセルにペタペタ貼ってます。

>>22
星の数ほどある人売屋の求人やんけ

変なフラグ作らせないためだろ

１つの画面を5日で作るのと20日で作るの、お金になるのは後者。だから書類は多ければ多いほどいい。
SIERなら常識。

テストで大事なのはステップ数と件数だから、全部同じ人がやらないと調整しにくいだろ？
バグが多ければテスト項目から削ったり設計書を直したり、少なければバグが出るテスト項目増やしたりして対応できる。

DBのなんかよくわからんパラメーターの設定一覧ならあったほうがいいと思う
でも基本いらないでしょ、どんなときに使うの？
アメリカとか設計書どうなってるんだろう、調べたら日本みたいな設計書はないって書いてあったけど

保守か開発かにもよるんじゃない？
開発だと遅延に遅延を重ねてとにかく早くやれって空気のとこ多いけど

作業が独立するので、テスト流す人と貼る人と確認する人が並列で動けるので動きが速い現場もある。
一概には何ともいえない。一人で直列にやればいつまでかかるかわからんことにもなる。

http://kikakurui.com/x0/X0125-1986-01.html

規格にもあるから、かなりメジャーな存在。
名のあるSIerだと自動生成するツールがあったりする。

これ参考になるかも
https://geechs-magazine.com/tag/tech/20160114
正常値　異常値　境界値　限界値
あとはマトリクスを書いてパターンを見てみるとか
全部バカ正直にテストやると時間いくらあっても足りないけど

プログラムはどの会社もフレームワークってのがあるはずだからフレームワークの振る舞いを理解する。
そういうふうになってるんだって割り切って理解する
コントローラーとサービスとビューはどういうふうに繋がってるかな？とか
データベースはどういうふうに操作してるのかな？とかね！

あとは頭からお尻までの流れを知る！
ここから入ってきてここから出て行くんだとか

あとデバッグを使いこなすこと！
困ったらデバッグデバッグデバッグ！
デバッグのやり方がわからない場合は最優先で覚えてね、
無理やりありえない値を変数に入れたり処理の途中で各変数の値をみたり

SI系ならもちろんEclipse＋Javaだと思う
ショートカットを覚えてね
F3とALT+←とShift+Ctrl+R
あと呼び出し元を参照とかこの辺は基礎だから(*ﾟ▽ﾟ*)

ふう(o´Д`)

ソースを見て判断しなければならないのはドキュメントの保守が行われていないせいであってドキュメント自体は必要だろ。

現場はまじで場所によりけりだからね〜
もし先輩がついてないならすごい心細いね、どこの会社に雇われてるのかもわからなくなるしｗ

>>37
全体の概要がわかるような設計書なら、メンテに使うかも知れない。

1ステップごとの処理の内容をいちいち書いてるような設計書は時間のムダ。

>>17
二次受けっていうんでしょうか。
大きいSIさんが取ってきたお仕事を貰って客先に常駐してます。
教育は(´･ω･`)正直期待できないです…
ピリピリした現場に放り込まれて恐る恐る質問して、
恐る恐るプログラム、テスト。
そんな毎日です。

>>9
詳細設計が煮詰まった段階じゃねーの

>>16
元請け？2次受け？3次受け？
ちゃんと教育してもらえそう？

AIでソース書けや。

魂けがれなく、道けわし

アメリカが世界最先端で生産性も高いならアメリカに習えばいいと思ったけど検索しても情報がでてこないんだよね

議論にすらならないのか・・・

テスト仕様書ってどの段階で誰が描くのが適切なんでしょうか？

テスト仕様書ってどの段階で誰が描くのが適切なんでしょうか？

上司がドキュメントしかみないしドキュメントをみて判断をするからドキュメント自体は必要なのはわかる。
でも必要最小限にしたい、20以上のフォルダの中にそれぞれ10〜50のファイルがあってさらに1冊印刷するだけで数百ページになったりするものもある。
いくらなんでも過剰だとおもうし、保守なんてできないと思う（メンテしてることにしてるだけ）。
しかもどこの現場にいっても設計書のフォーマットが違ってどう読めばいいのか慣れが必要なんだよ
テーブルだけで300以上あるシステムとかだとDB設計書やSQLだけで恐ろしい量になったりするのもわかるけどさ

なにが必要な情報でなにが不要なのか日本中で統一して欲しいし、教科書てきなものも必要だと思う

開発の規模感次第じゃね？
俺んとこは2、3人で自社パッケージ製品開発だから全くドキュメントなし

結局ソースと不一致で無意味だろ
馬鹿か

>>18
それまじだから困る

え？それすぐ終わるくね？ってものでも一生懸命大量に資料作って遠回りな実装して毎日残業でやったほうがものすごい褒められてしまう世界

>>27
ありがとうございます

謎のフラグを使うのがNG
詳細設計書を作る暇があるなら
ソースレビューして叩きまくったほうが有意義

設計

詳細設計書があればフラグの状態読めるのかよ
馬鹿か

https://employment.en-japan.com/desc_871394/?arearoute=2&aroute=0&caroute=0701&PK=05231C
日本情報技術取引所
多重ぐるぐるドナドナ案件
コンピューターレスキュー
角度があがります

http://www.computer-rescuer.com/
https://create-solutions.jp/

>>44
あのな、AIは人間が作るんだよ。

どこの現場いってもそんなもんだよ
マトリクス式で全ての結果にDBと画像の証拠をExcelに貼り付けさせるような時間のかかるテストを要求するところもあるし殆ど時間くれないとこもある(;´д｀)

工程
要件定義　　-　　基本設計（外部設計）-詳細設計（内部設計）-実装
　↓　　　　　　　　↓　　　　　　　　　↓　　　　　　　　　↓
システムテスト　　結合テスト　　　　　単体テスト　　　　　プログラムテスト

的なものを勝手にイメージしてるんだけどPS（プログラムテスト）なんてどこも存在しないから
プログラムテストと単体テストを一緒にやるかんじなるのかな？
単体テストは修正したロジックの分岐を全て試すべき！
とかいわれる
詳細設計で決めたこと全部満たしてるかと修正したロジックの分岐を全部通してみる（そのときにデッドロジックに気づいたりもする）
あとは境界値と異常値の確認くらいかな？
結合テストでは修正とは関係なくてもデータパターンを一通り試したり、あとは要件定義とか外部設計で決められたこと全部満たしてるかとかそんな感じかな？

現場の顔伺いながら自己流でやってきてるから参考にならないかも(^_^;)

この板、人がこなくて暇だな〜(・ω・`)

他の人は詳細設計書ある部分プログラミングしてるけど俺の担当してるとこ詳細設計書ないんだけど(;´д｀)

「使用済み下着販売掲示板（画像付き）」で検索。

いい子、かわいい子、いっぱいいるよ。

詳細設計書からソース自動作成される日も近い

基本設計書は客に納品することが多いからいるよね
詳細はなくていい
基本設計書で不足してる情報を補足する資料があればいい

真面目な人はホントに>>18を頭の片隅に入れておいてくれ。
大事なのは誰かの時間と書類の行数。
自分じゃなくてもいいことを忘れないでくれ

手動で画面ペタペタとって黙視確認とか何とかならんのかねぇ。。

角度が非常に高いです

http://www.computer-rescuer.com/
https://create-solutions.jp/

あったあったV字のテストモデルの説明

http://tech.nikkeibp.co.jp/it/atcl/column/17/110200480/013100007/