NTTデータ、ソースコードから要件定義書を生成するシステムの開発へ 53
ストーリー by hylom
無から有を生み出せ 部門より
無から有を生み出せ 部門より
あるAnonymous Coward 曰く、
以前、「NTTデータ、既存システムのソースコードから設計書を自動生成するサービスを開始」という話題があったが、この技術を強化し、設計書だけでなく要件定義書までも生成できるよう開発を進めるという（日刊工業新聞）。
現在提供されている「設計書リカバリーサービス」は、ソースコードを解析してドキュメントや設計書を出力するというものだったが、これらに顧客の業務内容といった情報を加えることで要件定義書までも生成できるようにするという。まだ開発開始というレベルのようだが、今後は「解析によって生成した設計情報のチェック、新しい設計情報を元にしたアプリケーション（応用ソフト）の生成までの一連の流れを自動化する技術の高度化」を勧め、2015年度には開発工期を半減させることを目指すという。
生成ドキュメントを想像 (スコア:3)
顧客要望：一覧でる。（全列でソート可能 added on 10/5 , 昇順デフォルト on 11/5, 名前はミドルネームあり・・・)
void getList2( age, gender, flag,hoge)
age: 特殊フラグとして使用。例： "3,-4,33"
gender: 鈴木さんに聞いてください（2014.1.11鈴木さん退職 by山田）
flag: (セットしたらこないだ２日間で落ちたので、使わないこと by 佐藤）
age の中にCSV形式でflagを入れるようにした）
hoge: (使われていないと思うけど、１年仕様実績があるので残した by 鈴木）
void getListX()
void getListX2()
void old_getList( age, gender, flag) {
/*
Description: この関数は古いです getListX を使ってください。
age: 年齢
gender: 性別
*/
}
void __old201105_43_getList(){
}
Re:生成ドキュメントを想像 (スコア:2)
ソースのプリントアウトの最後に、
「以上のソースより生成されたモジュールの動作に準ずる」
#存在自体がホラー
Re: (スコア:0)
静的解析によってゼロから仕様をあぶりだすようなアプローチであれば、
妙なシンボル名にまどわされずコメント部分にあるような真の挙動だけが見えてくるんでしょうね。
さらにNTTデータの情報網を応用すれば鈴木さんの所在まで追跡してくれることでしょう。
Re:生成ドキュメントを想像 (スコア:2)
昔、testAge() みたいな関数で惑わされた経験も思い出されました。
「これはテスト用関数？なぜこれが製品コードに？」と戸惑ったのですが、
人の書いたコメント以外に（そもそもそんなものはない）、
内部ロジックを解析して、「 引数 age の妥当性を調べる。」的な機会生成コメントがつくと
うれしかったわけです。
改修案件用なのか (スコア:2, すばらしい洞察)
システム作り終わった後に要件定義とか頭が腐っているのかと思ったけど、仕様書が足りない現行システムのためのものなのね。
これを適用して、過去のNTTデータ案件で実装漏れとかが見つからないことを祈っております。
Re: (スコア:0)
なるほど改修用か。要件がないのにどうやってシステムを発注・受け入れしてんだ？と思ったが、大昔のシステムのためね。どっちにしろ、無茶じゃね？という気がビンビンするわけだが。
Re:改修案件用なのか (スコア:1)
仕様書が出てきても「どのようにしているのか」が多少分かるだけで「何をしているのか」「何故しているのか」は全く分からないでしょうから.
Re: (スコア:0)
技術的に実現するかどうかは別として、顧客情報やAIの技術などを利用して「何故そうした設計になっているのか」を解析するシステムを目指すそうですよ。
難癖つけるなら、一応元記事は読んだ方がよろしいかと。
覆水盆に返らず (スコア:1)
＞顧客情報やAIの技術などを利用して「何故そうした設計になっているのか」を解析するシステムを目指すそうですよ。
目指すだけじゃ、意味ないな。実現できないと。
そしてそういう解析は本質的に不可能だから。実現する気なら魔法でも使わないとｗ
壊れたデータから名寄せするシステムの失敗で懲りてないのかね。
それとも奴らは魔法とプログラムの見分けも付かないほどバカなのか？
Re: (スコア:0)
いいんだよ、目指す分には自由だし。
NTTデータの製品ってのはみんなそうなんだから。
Re: (スコア:0)
勝手に高い目標に仕立て上げて勝手にdisりなさんな
既存技術でも、ソースから境界条件を抽出することくらいはある程度できます
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)
自動生成された設計書が意味不明で手を入れたものがリポジトリに登録され、
その後、リポジトリに登録された設計書をもとにプログラムを修正しようとしたときに、
設計書とプログラムの対比ができない事態が多発しそう。
テスト設計書の自動生成でそういう経験をしてます。
去年11月のNTTデータのセミナーに行きました (スコア:2, 参考になる)
開発は Common Lisp または Haskell だそうです。
対象言語はCOBOLなど超レガシーコード。
詳しい技術はここで・・・と思ったら、肝心の該当項目のpdfがありませんね。
COBOL meets Haskell
- Haskellを用いたCOBOLのプログラム解析ツールの開発事例 -
http://www.msi.co.jp/userconf/2013/index.html [msi.co.jp]
Re: (スコア:0)
cobolだからできたんですかね
変数名も日本語よく使われるし、生成したものが
仕様書っぽくなりそう
Re: (スコア:0)
COBOLの設計書生成ツールなら、前世紀からあるじゃないか。
で、それじゃ使えないから、Abstructする研究があったのだが、そのための解析ツールをsed/awkでつくっていた。
それも前世紀の話。あれどーなったのかなー。
Re:去年11月のNTTデータのセミナーに行きました (スコア:1)
sed/awk以前にSNOBOLでやっていた人はいたのかいなかったのか?まああったにせよ後発の言語用に巻き取られてしまったんだろうなあ。というわけで先行開発事案をあったなかったで探すよりどこに注力していたか次第で有用だったか再発掘する価値ありかという点は分かれるのでは?
誰も必要としていない設計書 (スコア:1)
誰の為の設計書なのか。
本末転倒とはまさにこのこと。
不要なものなら契約時から納品物に含めなければいいだけなのに。
Re:誰も必要としていない設計書 (スコア:2)
次回の移行のために必要。
# バグの扱いはどうなるんだろうか。
# アナログ式にバグチェックできたら便利だなあ。
# コードが理解できなくても、業務を把握している人がバグチェックできるのは大きいと思う。
Re:誰も必要としていない設計書 (スコア:1)
みんなそう思ってるけど、納品物が無いと気がすまないのが会社なのよね
ソースがあるじゃん、っていう人もいるけど、お偉いさん方は
ソースもらってもわかんないしね。設計書みて「ふむふむなるほど（よくわかってないけど」
と思うために存在するわけですよ。
それに意味があるかないかを考えることこそ意味がない。
だってそれがあれば丸く収まるんだからね
Re: (スコア:0)
成果物のCDRなんてドライブに入れられることが無いとわかってるけど作る。
Re: (スコア:0)
でも、それは純粋に商習慣の問題であって、市場経済的には淘汰されてしかるべきものですよね。
Re: (スコア:0)
商習慣じゃなくて税法の問題。
Re:誰も必要としていない設計書 (スコア:2)
納品物：動作モジュール一式
納品場所：御社サーバ（XXXX）上
でも問題ありませんけど。
Re:誰も必要としていない設計書 (スコア:1)
いや、だから税法上の問題じゃないでしょ。
法律の問題があれば、これは通らないわけで。
Re: (スコア:0)
スピード違反をした人が全員捕まってると思ってるのかな？
Re:誰も必要としていない設計書 (スコア:1)
納品物に設計書がないとダメっていうのは、税法上のどういう問題なんですか？
上場企業で国税監査も入ってるから、モジュール納品で問題があるっていうのはちょっと考えにくいと思うのですが。
Re: (スコア:0)
それなら、税制改革の対象にしてほしいですね？
Re: (スコア:0)
そのソースが正しいか否かをどうやって確認するんだよ。
不具合を仕様にする道しか残ってない。
Re: (スコア:0)
ソースの実装をきっちり設計しているExcel設計書なんて見たこと無いけど
Re: (スコア:0)
誰も読めないけど絶対止めちゃいけないクソシステムをフルスクラッチで書き直すのに人手使いたくないんだろ
バイナリしかないとやっぱり死ぬけどこれが完成すれば発掘したソースの断片とかが少しは使えるようになるんじゃね
何会社の何部署とは言わんが (スコア:1)
SES契約社員の間で噂になってた話。
最初の要件定義書もつくらないまま指示受けて、
あれこれ考えて自社なりに考えて設計して、ドキュメント添えてソースを納品するじゃん？
そしたらこうなるわけ
理想：あなたの会社はしっかりしている、今後もよろしくお願いします。
現実：何そんなに時間かけてんの？残業しすぎで高いから別の会社にしちゃうよ(ﾁﾗｯ
当然どの会社も急ごしらえの酷いものしか納品しないんだよね
ミクロな修正履歴の報告書が何百積み上がってもマージする人が居なけりゃゴミだから、ソースコードしか残らんよね
その辺ちゃんとやってる会社や部署ならこういう問題起こらないもんなのかね？
それとも、どこでもこういう問題抱えてるって話なのかな？
もしかして (スコア:0)
Java等からmind [wikipedia.org]へのソースコードコンバータだったりして。
なら許す。
# ぴゅう太BASICでも可
下請けに強制するのかね (スコア:0)
で、これを使ったことで工数が削減できるはずだからと開発費を値切るために使うとか。
工期半減だから開発費も半分だね。あと利用料も徴収すれば一粒で二度おいしいね。
バグはどうなる (スコア:0)
コードのバグを仕様でなくコードのバグとして認識できたらちょっとすごい。
もしそうならないんだとすると単体レベルのバグが仕様バグに昇格して責任の所在が移っちゃうんですがいいんですかそうですか。
俺も良くやってるわ (スコア:0)
現状の不具合っぽい動作を「仕様です」って言い切ることだろ？
Re: (スコア:0)
仕様ならちゃんと書いとけ。
Re:俺も良くやってるわ (スコア:1)
よく聞け、「仕様(がないの)です」と言ってるんだよ。(括弧内はできうる限り小声で)
#存在自体がホラー
現場が本当に必要だったもの (スコア:0)
こういうのって、ソース読めばわかる仕様よりは「なぜこうなってるか」という理由の方が大事なんだよなぁ。
もう居ないお偉方の妙な思い込みで斜め下の仕様になっていたのを忠実に再現する必要とかないんだし。
Re: (スコア:0)
『最初ＸＸという要件であったが、途中で外部システムの都合で無理やり要件を変更してか～ら～の～、
大どんでん返しで実装後に不要なことが分かったので使われていないが処理は残しておいてほしいと要件が追加された。』
（結局一度も使われていないから削除可能、まで自動でドキュメントされるならすごいけど(笑)）
Re: (スコア:0)
（結局一度も使われていないから削除可能、まで自動でドキュメントされるならすごいけど(笑)）
と、思いきや、タスクスケジューラに登録されていて削除不能とか・・・
#学生のころのOSの教科書で、20年だか動かしたマシーンを処分するときにログを調べたら、一度も動いてないジョブがスケジューラに載ってた、って与太話があったなあ。
一体彼らは (スコア:0)
何を作ろうとしているのでしょうか?
Re: (スコア:0)
これ [unkode-mania.net]じゃないの？（とか
ところで、 (スコア:0)
このサービス自体のソースを読ませたら、何が出てくると思う？
Re: (スコア:0)
ふつうに簡易自己紹介で終わるんじゃないですか？
無限再帰とか合わせ鏡みたいな要素はないと思うんですけど。