アカウント名:
パスワード:
システム作り終わった後に要件定義とか頭が腐っているのかと思ったけど、仕様書が足りない現行システムのためのものなのね。これを適用して、過去のNTTデータ案件で実装漏れとかが見つからないことを祈っております。
なるほど改修用か。要件がないのにどうやってシステムを発注・受け入れしてんだ？と思ったが、大昔のシステムのためね。どっちにしろ、無茶じゃね？という気がビンビンするわけだが。
仕様書が出てきても「どのようにしているのか」が多少分かるだけで「何をしているのか」「何故しているのか」は全く分からないでしょうから.
技術的に実現するかどうかは別として、顧客情報やAIの技術などを利用して「何故そうした設計になっているのか」を解析するシステムを目指すそうですよ。難癖つけるなら、一応元記事は読んだ方がよろしいかと。
＞顧客情報やAIの技術などを利用して「何故そうした設計になっているのか」を解析するシステムを目指すそうですよ。目指すだけじゃ、意味ないな。実現できないと。
そしてそういう解析は本質的に不可能だから。実現する気なら魔法でも使わないとｗ壊れたデータから名寄せするシステムの失敗で懲りてないのかね。
それとも奴らは魔法とプログラムの見分けも付かないほどバカなのか？
いいんだよ、目指す分には自由だし。NTTデータの製品ってのはみんなそうなんだから。
勝手に高い目標に仕立て上げて勝手にdisりなさんな
既存技術でも、ソースから境界条件を抽出することくらいはある程度できます
目指すだけなら大学生の卒論レベルだなｗ
http://www.nikkan.co.jp/news/nkx0220140121bjan.html [nikkan.co.jp]
さらに生成した設計情報に顧客の業務を当て込み、人工知能（ＡＩ）の技術などを適用することで個々のプログラムが担っている業務や、そもそもプログラムが「なぜ」そうした設計になっているのか、といったシステムの根本的な目的を要件定義書などの形で復元する。
ソース
x += 3;
目指すもの
/ * 現在のシステムでは、ここで追加で3回リトライする可能性を考慮する必要がある。 リトライ回数の決定要因となるのはネットワークの速度であったため、 ネットワークトポロジを変更する場合は留意すること。 また、リトライ回数を増やした場合、UIの反応速度に影響する場合があるため、増やすのは実測の上必要最小限度とし、 かつ、修正影響範囲にUI操作を含め、QAに確認すること。*/
できたもの
// 変数xに3を加える。
http://it.srad.jp/comments.pl?sid=599426&cid=2374311 [srad.jp]
#このくらいが限度?
NTTデータ本体には寝言を言って予算を取って、予算取った後の設計以降から丸投げで、成果はうやむやのまま逃げる詐欺師がうようよいるんだよな。#直接には二例ぐらい知ってる#丸投げされた物をうっかり受けたら死ぬんだろうな
そのぐらいで死ぬようなやつにはそもそも投げないから大丈夫。 ＃死なないというかすでに死んでるというか
簡単に挙げられる例で言うと、とあるものの動態データを取って解析するというシステムで「解析手法はどう考えられていますか？それに即して設計します。」（R使おうかな...）「ですから解析してください」「えっ？」「えっ？」
設計書の自動生成までは既に出来てるということだから、案外目処が立ってるのかもな。自分も無茶だと思うし開発には関わりたくないけど、技術的にはちょっと興味ある。
設計書の自動生成のイメージはこんなのhttp://itpro.nikkeibp.co.jp/article/Active/20130426/473921/?SS=imgview... [nikkeibp.co.jp]
自動生成された設計書が意味不明で手を入れたものがリポジトリに登録され、その後、リポジトリに登録された設計書をもとにプログラムを修正しようとしたときに、設計書とプログラムの対比ができない事態が多発しそう。
テスト設計書の自動生成でそういう経験をしてます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
改修案件用なのか (スコア:2, すばらしい洞察)
システム作り終わった後に要件定義とか頭が腐っているのかと思ったけど、仕様書が足りない現行システムのためのものなのね。
これを適用して、過去のNTTデータ案件で実装漏れとかが見つからないことを祈っております。
Re: (スコア:0)
なるほど改修用か。要件がないのにどうやってシステムを発注・受け入れしてんだ？と思ったが、大昔のシステムのためね。どっちにしろ、無茶じゃね？という気がビンビンするわけだが。
Re:改修案件用なのか (スコア:1)
仕様書が出てきても「どのようにしているのか」が多少分かるだけで「何をしているのか」「何故しているのか」は全く分からないでしょうから.
Re: (スコア:0)
技術的に実現するかどうかは別として、顧客情報やAIの技術などを利用して「何故そうした設計になっているのか」を解析するシステムを目指すそうですよ。
難癖つけるなら、一応元記事は読んだ方がよろしいかと。
覆水盆に返らず (スコア:1)
＞顧客情報やAIの技術などを利用して「何故そうした設計になっているのか」を解析するシステムを目指すそうですよ。
目指すだけじゃ、意味ないな。実現できないと。
そしてそういう解析は本質的に不可能だから。実現する気なら魔法でも使わないとｗ
壊れたデータから名寄せするシステムの失敗で懲りてないのかね。
それとも奴らは魔法とプログラムの見分けも付かないほどバカなのか？
Re: (スコア:0)
いいんだよ、目指す分には自由だし。
NTTデータの製品ってのはみんなそうなんだから。
Re: (スコア:0)
勝手に高い目標に仕立て上げて勝手にdisりなさんな
既存技術でも、ソースから境界条件を抽出することくらいはある程度できます
Re: (スコア:0)
目指すだけなら大学生の卒論レベルだなｗ
Re:改修案件用なのか (スコア:1)
http://www.nikkan.co.jp/news/nkx0220140121bjan.html [nikkan.co.jp]
さらに生成した設計情報に顧客の業務を当て込み、人工知能（ＡＩ）の技術などを適用することで個々のプログラムが担っている業務や、そもそもプログラムが「なぜ」そうした設計になっているのか、といったシステムの根本的な目的を要件定義書などの形で復元する。
ソース
x += 3;
目指すもの
/ *
現在のシステムでは、ここで追加で3回リトライする可能性を考慮する必要がある。
リトライ回数の決定要因となるのはネットワークの速度であったため、
ネットワークトポロジを変更する場合は留意すること。
また、リトライ回数を増やした場合、UIの反応速度に影響する場合があるため、増やすのは実測の上必要最小限度とし、
かつ、修正影響範囲にUI操作を含め、QAに確認すること。
*/
できたもの
// 変数xに3を加える。
http://it.srad.jp/comments.pl?sid=599426&cid=2374311 [srad.jp]
#このくらいが限度?
Re: (スコア:0)
NTTデータ本体には寝言を言って予算を取って、予算取った後の設計以降から丸投げで、成果はうやむやのまま逃げる詐欺師がうようよいるんだよな。
#直接には二例ぐらい知ってる
#丸投げされた物をうっかり受けたら死ぬんだろうな
Re: (スコア:0)
そのぐらいで死ぬようなやつにはそもそも投げないから大丈夫。
＃死なないというかすでに死んでるというか
Re:改修案件用なのか (スコア:1)
簡単に挙げられる例で言うと、
とあるものの動態データを取って解析するというシステムで
「解析手法はどう考えられていますか？それに即して設計します。」
（R使おうかな...）
「ですから解析してください」
「えっ？」
「えっ？」
Re: (スコア:0)
設計書の自動生成までは既に出来てるということだから、案外目処が立ってるのかもな。
自分も無茶だと思うし開発には関わりたくないけど、技術的にはちょっと興味ある。
Re: (スコア:0)
設計書の自動生成のイメージはこんなの
http://itpro.nikkeibp.co.jp/article/Active/20130426/473921/?SS=imgview... [nikkeibp.co.jp]
Re: (スコア:0)
自動生成された設計書が意味不明で手を入れたものがリポジトリに登録され、
その後、リポジトリに登録された設計書をもとにプログラムを修正しようとしたときに、
設計書とプログラムの対比ができない事態が多発しそう。
テスト設計書の自動生成でそういう経験をしてます。