質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
データ構造

データ構造とは、データの集まりをコンピュータの中で効果的に扱うために、一定の形式に系統立てて格納する形式を指します。(配列/連想配列/木構造など)

Q&A

解決済

9回答

31209閲覧

仕様書がないシステムの仕様を把握する方法

tmak1000

総合スコア32

データ構造

データ構造とは、データの集まりをコンピュータの中で効果的に扱うために、一定の形式に系統立てて格納する形式を指します。(配列/連想配列/木構造など)

0グッド

12クリップ

投稿2015/09/17 16:22

仕様書が存在していないプロジェクトに参加して、システムの仕様を把握するのに苦労しています。

実際の現場に入って2か月目の新人です。

特に、テストデータを用意する場合に、どのようにすれば、正しくデータを構成できるのかいつも悩んでいます。

ソースをすべて読んで、処理を追うことでしか仕様の把握をすることはできないのでしょうか。

システム全体の仕様を仕様書なしで把握する効率的な方法があれば、教えていただきたいと思います。

よろしくお願いいたします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答9

0

ベストアンサー

既にほかの方からの回答にもある通り
「今動いているものが正」として考えていいと思います。

私が実際に設計書が存在しない(あるいは大人の事情で公開できない)PJに参画した時には、
↓のような施策を実施していました。

1.今回のテストシナリオではA機能とB機能を使用する
2.A機能とB機能をテストシナリオに基づいた動作検証し、現状の動作を整理する。
3.(可能であれば)2.の動作をもとにテストデータ作成する。
4.業務有識者に、2.3.の結果を持参し、現在のアプリVer.とデータでテスト続行していいかどうかの確認実施。
5.4.で課題発覚した場合、アプリ修正依頼ORデータ修正ORテストシナリオ修正し、4.に戻る
6.テスト消化

ソースをすべて読んで、処理を追うことでしか仕様の把握をすることはできないのでしょうか。

ソース解析は非常に時間がかかります。
業務全体をある程度把握した上で、発生した障害の検証をする場合には有用でしょうが、まずは業務理解が先決と考えます。

システム全体の仕様を仕様書なしで把握する効率的な方法があれば、教えていただきたいと思います。

業務フロー、処理フローをみながら、とにかくアプリをたたきましょう。
テスト消化に追われてその暇もないということであれば、とにかくテストをこなしてアプリと仲良くなりましょう。
そのうち、「なんでここはこうなってるんだっけ?」という部分が出てきますので、業務有識者に確認しましょう。
そうすればいつのまにか全体の動きがわかってきます。

業務有識者は往々にして多忙であることが多く、聞くタイミングも少ないでしょうから
タイミングを逸しないことと、簡潔に質問できる準備をしておくといいと思います。

頑張ってください。

投稿2015/09/18 00:24

編集2015/09/18 00:29
ARADDIO

総合スコア160

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tmak1000

2015/09/18 09:47

ARADDIOさんがPJに参画した時のテスト消化フローが凄く参考になりました。 また、今までアプリを動作させてフローを考える割合が、ソースを読むよりも少なかったとも思います。可能な限りアプリをたたいて、業務への疑問を整理してみます。
guest

0

経験2ヶ月という事を考慮すれば、
ソースからフローチャート起こしてみるのが最善策。

  • 一つ一つ処理を把握しながら読む
  • 頭にあるものを紙に書く

という事がポイント。
そうすると、データの流れを把握しやすくなって、
処理を完了迄持っていくのに、どういうデータを準備すればよいか見えてくるはずです。

あと、今実装されているものが**「正しい仕様」**と
割りきってしまって良いと思いますよ。
だいたい仕様書のないプロジェクト(仕様書がっても)は、
現実装を正規の仕様としていますので。

ストレスを溜めすぎないよう頑張ってください。

投稿2015/09/17 22:08

TetsujiMiwa

総合スコア1124

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tmak1000

2015/09/18 09:50

フローチャートを描いてみたら、データの流れが把握しやすくなりましたありがとうございます。
guest

0

・テストデータについて
残念ながら仕様書を基にテストデータを作るため、正しいテストデータなんて作りようがありません。
また、ソースコードを基にテストデータを、作る事もできません。なぜなら目の前にあるソースコードが正しいかどうかは仕様書に基づくからです、仕様書を完全再現したソースコードがあるなら、そもそも仕様書がないなんて事はあり得ません。

・仕様の効率的理解について
結局のところ、システムにはユーザーがいます。ユーザーの意図が仕様になります。
ユーザーの正しい使い方を正常動作として把握し、あとは自身で例外的な使用方法について検証するしかないと思います。疑問に思ったところを一覧にして、先輩等に確認するといいかもしれないですね。

投稿2015/09/17 16:59

yona

総合スコア18155

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

可能な限り現場を好意的に捉えれば、TDD開発してて要件定義のような文書しかないだけかも
その場合テストコードが存在すると思いますので既に必要なデータが準備されているかもしれませんし、無くてもそこやバージョン管理のログから必要なものが推し量れるかもしれません。

もしウォーターフォール型で仕様書が無いとなると、システムの規模にもよりますが絶望的かも…
先輩に確認しながら時間を掛けて吸収していくしかないんじゃないでしょうか?
仮に「そう有るべき」から発見した不具合を指摘したとしても、作った人個々にPMと合意したローカルルールがあったりしたら意見対立待ったなし(それでも仕事なので報告と確認はしなきゃいけないんですが)ですし、新人だときついですね…。

投稿2015/09/17 17:38

編集2015/09/17 17:50
hirohiro

総合スコア2068

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

システムの規模にもよるかもしれませんが、
2か月の新人でそういう現場とは厳しいですね。
先輩や上司の言葉(専門用語など)がすでにわからなかったりな状況だったりしますか?
しかし応援したくなっちゃいますね。

みなさんが回答されていることの繰り返しになるかもしれませんが、
システム全体仕様を手っ取り早く把握するには、いろんなパターンで「実際に動かす」です。
ただ細かい動作はソースを見るしかないと思います。
あと技術者としては微妙ですが「詳しい人に教えてもらう」が最強です。

ご参考までに「教えてもらう」の立ち回りを書いておきます。
1.わからないことや確認したいことを一覧にする
一般的に言うとQA一覧でしょうか。
有識者に毎回聞くとそのたびに相手の作業が中断してしまうためです。

2.自分なりの理解をMy資料にする
処理の概要から詳細まで自分なりに理解したことを資料にします。
何を聞けばよいのかがわかってくることもあります。

3.認識合わせと疑問点の解消
有識者に時間を取ってもらいましょう。
作成したMy資料とわからない点の一覧を使って打合せをします。
目的は以下です。
・自分の理解で正しいかを確認する
・現時点で出てきた疑問点を解消する。

おそらく最終的にはあなたに仕様書を作ってもらいたいのではないかな?と思います。
頑張ってください。

投稿2015/09/18 02:04

tsunex

総合スコア206

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tmak1000

2015/09/18 03:57

回答ありがとうございます。  ・実際に動かす。  ・QA一覧作成、My資料を作成して詳しい人に疑問点を聞く。  ・最終的に仕様書作成を目的としてみる。 を実践してみたいと思います。  
guest

0

そのような仕様書のない現場というの非常に多いです。

納品してから仕様書を書くなんてこともあります。

さて、把握する方法ですが、ご自分の受け持っている範囲内の分岐を把握し、これは何をする処理なのかを考えます。
次に、明らかにおかしい値と絶対通る値でテストします。
不安でしたら全パターンテストをお勧めします

投稿2015/09/18 00:35

kpiyohiko

総合スコア658

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tmak1000

2015/09/18 03:58

ありがとうございます。 実際に動かす際に  ・分岐の把握  ・明らかにおかしい値と絶対通る値でテスト  ・可能ならば全パターンテスト  を重視して進めて行きます。
guest

0

非常に厄介な状況ですね…

既に皆様がご回答くださっている通りなのですが、誤解を恐れずにざっくりとした表現の仕方をすると

  • 「仕様書」は、システムのあるべき姿(何が正しいか)についてクライアントと合意した内容=「定規」
  • 「テスト」とは、システムの実際の挙動が「定規」からズレていないことを確かめる作業

なので、「定規」である「仕様書」がなければ、そもそもテストをする意味がなくなってしまう訳です。

とはいえプロジェクトが発足した以上、何としてでもタスクを遂行してゆく必要があるので…
(言葉で書くとゴチャゴチャして分かりにくいですが)

まず、以下のような点について再確認してください。

  • プロジェクトの目的は何ですか?「品質向上」それとも「機能追加/改善」ですか?
  • テストのどの工程のデータ作りを想定していますか?「単体/連結/総合」

仕様書がない以上、「現在稼働しているシステム」が正解(仕様書に記載されているはずの内容に最も近い)とみなして作業を進める、つまり『現新比較』の結果を拠り所とするしかありません。

対象のシステムがどのようなものか分からないと具体的な回答は無理なので、以下はWebベースの業務システムを想定して記載します。

もし「品質向上」(=潜在的なバグの洗い出し)が目的なのであれば、現新比較しても無意味です。
その場合には、もう一度、業務フローやシステムの入力データとなる帳票類を分析して、十分なバリエーションのテストデータを作成するとともに、それらのデータに対して期待される結果が得られるかを、エンドユーザに確認してもらうしかありません。

「機能追加/改善」が目的なら、ソースの「分岐」部分に着目し、実装時点で境界値とみなされていた値を洗い出します。
そして境界値と考えられる値を中心に、業務上の要件も考慮して十分な量のテストデータを作成し、追加/修正対象の機能以外については変更のないことを現新比較によって確かめながら、手を加える部分の新しい仕様に従って細かいテストを実施します。

うまくまとめられませんでそたが…少しでもご参考になれば幸いです。

投稿2015/09/17 21:29

pi-chan

総合スコア5936

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ソースを読んで理解をしてテストをするのは正直、お勧めできません。
ソースよりも任されているテスト作業範囲の業務理解と業務データの流れ、データのCRUDについて知るのが優先だと思います。
これは業務サイドや現場の先輩に少しづつでも時間を取ってもらい教えてもらうべきだと思いますし、教えるべきとも思います。
誤っているソースをベースにテストケースを作ってもテストにはなりません。
ケアレスミスだけでなく条件すらソースから漏れている場合もあります。
結果としてテストも二度手間になりますし品質面でも問題がある進め方だと感じます。

投稿2015/09/17 16:44

CharmSystems

総合スコア241

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

まず、対象とするシステムにUIがあるのなら使いまくること。対象が何者なのかもわからずコードを見ても無駄。かならず間違う。
もし、ネットワーク関係の機器みたいにシステム仕様書がなければ、どういうことをやっているのか調査する。操作マニュアルとかぐらいはあるでしょう。なければつかっている人に聞く。
システムをBlackBoxとしてIN-OUTを把握していくのです。
イメージとして、OSSをHACKする場合も、何のOSSか把握してからコードを見ますが、それと同じです。
そう!システムをHACKするのです。
その後、ラッキーにもコードがあれば、動かしたときのことを思い出してコードを見ていきます。
最悪の場合、ネットワークの口から通信内容を把握して、動作を類推して、制御プログラムを作ることも可能です。

投稿2015/09/29 12:15

MorimasaMatsuda

総合スコア42

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問