• ベストアンサー

ウォーターフォール型開発プロセスの略称について

某ソフトハウスの企業で使用している、開発プロセスの各工程の 略称があるのですが、どんな単語の略なのか、ご存知でしたら 教えていただけないでしょうか。 こんな内容です。 SA:要求分析 SS:基本設計 PS:詳細設計 PG:プログラム MT:単体テスト PT:結合テスト IT:結合テスト ST:総合テスト FT:現地テスト 一応、以下の内容なのでは、と推測してます。 SA⇒System Analyze? SS⇒Standard Specification? PS⇒Program Specification? PG⇒Programming IT⇒Integration Test? ST⇒System Test? くらいは、想像できるのですが、あとはわかりません。 そもそも、一般的な略称なのでしょうか? ぐぐってみても、ほとんど引っかからないので、 おそらくこの企業の独自の略称だと思ってます。

質問者が選んだベストアンサー

  • ベストアンサー
  • jjon-com
  • ベストアンサー率61% (1599/2592)
回答No.1

キーワード「SA UI SS PS PG PT IT ST」でGoogleして4番目にヒットするのがこちら。 http://img.jp.fujitsu.com/downloads/jp/jmag/vol57-1/paper03.pdf 3ページ目の p.18 の日本語を参考にするなら,次の英単語を指しているものと思われます。 SA: System Analysis SS: System Structured Design PS: Program Structured Design PG: ProGramming MT: (間違いではないですか?) PT: Program Test IT: Integration Test ST: System Test FT: (このページには載っていませんが Field Test でしょう) このうちのいくつかは和製英語なのでしょう。 同キーワードでGoogle検索して2番目にヒットする次のExcelデータの[English]シートを見ると, http://www.ewavesys.co.jp/NMT.xls SA:Investigation/Analysis・Requirement Definition(調査/分析・要求定義) SS:Detail design PS:Program design PT:Unit Test のように,頭文字と英単語が合わない例が見受けられます。

nepiatissue
質問者

お礼

回答ありがとうございました。 富士通の開発標準のFDEMと呼ばれているものに 近いですね。若干の差異はあるものの、この開発標準を ベースに、うちの会社独自で定めたんでしょうね。

その他の回答 (1)

  • thefools
  • ベストアンサー率80% (4/5)
回答No.2

昔を思い出してみました。 MTはModule Testじゃないですかね? プログラム1本全体をテストする前に、個々の関数のレベルをテストしておくことではないかと思います。 ウォーターフォールモデルの開発プロセスは、オリジナルがIBMなので 基本的な枠組みは各社似たようなものなのですが、その工程の範囲や用語の使い方などはおそろしく独自です。 元請けからXX次下請けまでが集まるプロジェクトの現場では 「プロジェクトメンバ全員の認識が合わない」 なんてことになりやすいです。

nepiatissue
質問者

お礼

間違って、お礼ではなく補足コメント欄に記入してしまいました。

nepiatissue
質問者

補足

回答ありがとうございました。 MTはModuleTestですか。なんかそれっぽい気がします。 >元請けからXX次下請けまでが集まるプロジェクトの現場では >「プロジェクトメンバ全員の認識が合わない」 >なんてことになりやすいです。 今まさに、こういう状況が発生しつつあって、 同じ単体テストを意味する単語も、一人は「MT」と呼ぶし、 他方では「UT」と呼ぶので、統一がとれてないんですよ。 しかも、社内のプロジェクトで。 なので、なるべく世間一般で通用している標準的な 名称を使いたいのですが、各社オリジナルなものが多いんですね。

関連するQ&A

  • サポートや保守の略称について

    お世話になります。 プログラマーは「PG」、システムエンジニアは「SE」、プロジェクトリーダーは「PL」、プロジェクトマネージャは「PM」。 では、保守は何になりますか。 あとこのようなIT関連の職位の略称が掲載されているサイトがあったら教えて下さい。 宜しくお願いします。

  • 【ソフトウェア開発】 UD、CD,SDとは?

    ソフトウェア開発において、各工程のテストをする際 UD=単体テスト CD=結合テスト SD=システムテスト という言葉を耳にしますが、このUDとは何の略称なのでしょうか?UnitDebug?なのでしょうか。 ソフトウェア開発をしておりますと、上記の言葉だけではなくFS,DS,,,等々英語2文字の略称がよく出て参ります。これがそれぞれ何の略称でどういう意味なのかの一覧表などがあれば大変ありがたいのですが。。。 ご存じの方どうぞ宜しく御願いいたします。

  • ソフトウェア開発工程の呼び方、分け方

    システム開発の方法としてウォーターフォールという方法がありますが、Wikipediaでは、 「要求定義」 「設計」 「プログラミング」 「テスト」 「運用」 といった工程の分け方が紹介されていました。 ほかに、 「要件定義」 「概要設計」 「詳細設計」 「製造」 「単体テスト」 「結合テスト」 「運用」 という分け方も聞いたことがあります。 他にどのような分け方、呼び方があるでしょうか。 また、「製造」という呼び方は一般的なのでしょうか。(ちょっと違和感を覚えたので)

  • システム開発を行う上での

    システム開発を行う上での FP法での見積もりに対する各工程の所要日数について お伺いさせて頂きます。 Aシステム : 120FP 生産性  : 7.5時間 / FP 月間標準時間 : 150時間(1人月) (1日は7.5時間、月間は20日とする。) 作業要員:2名 システム開発の工程及び工程別工数配分率 要件定義: 50% 内部設計: 20% 詳細設計: 35% プログラム設計 : 50% コーディング : 30% 単体テスト : 20% システムテスト :20% 上記内容で詳細設計の プログラム設計、コーディング、単体テストの 所要日数を算出したいのですが以下の計算で認識は合っておりますでしょうか? 120FP × 35%(詳細設計) = 42FP(42人日) 42FP × 50%(プログラム設計) = 21FP(21人日) 42FP × 30%(コーディング) = 12.6(12.6人日) 42FP × 30%(単体テスト) = 8.4(8.4人日) プログラム設計の所要日程⇒ 21人日÷2人 = 10.5日 コーディングの所要日程⇒ 12.6人日÷2人 = 6.3日 単体テストの所要日程⇒ 8.4人日÷2人 = 4.2日 以上。 宜しくお願い申し上げます。

  • プログラム設計書の書き方

    僕は新人SEです。 今、上司の方からあるシステムの基本設計書・システム設計書・プログラム設計書を作り、プログラミングまでしてから単体テスト・結合テストもやるように言われています。(全て1人で) おそらく経験のある方ならすぐにできてしまうようなシステムで、上司の方も勉強のために全てやらせているようです。 今、基本設計書・システム設計書まではなんとかできて、プログラム設計書の作成に取り掛かりたいのですが、初めての経験で実際のプログラム設計書には何をどのように書いているものなのかも全く見当もつかずにいるので全く何も書けません。 上司さんは今週忙しいようで 「来週見てあげるから自分で調べたりしてやってみて」 と言っています。 ですが、全く何もできずにいるのもイヤなので何かそれらしいものでも書いてみたいのですが…プログラム設計書とは何をどう書いてあるものなのでしょうか? 日本語が書いてあるのかプログラムが書いてあるものなのか… そういったところからわからないので少しでも何か教えていただきたいです。 宜しくお願いします。

  • システムエンジニアの皆様に質問です。

    システムエンジニアの皆様に質問です。 こんにちは。今年の4月から入社した者です。 客先に常駐し始めたのは8月下旬からです。 その客先で現在、基本設計書を見ながら単体テストの仕様書を作っているのですが、その基本設計書が分からなすぎて困っています。 自分がその案件に関わってまだ数日しか経ってないのもあるのですが、システムについて理解出来ずテストケースもろくに作れないのが現状です。 基本設計書見ても何やっているのか分からなくて、テスト仕様書自体の作り方も分からなくて、そのプログラムがどこで動いているのか分からなくて、このプログラムは何の目的で作られているのか分からない状態で上の人間から、仕様書に関しては3日で作れと言われたけどもう5日も経ってしまって自分はやっばりIT企業には向いていなかったのかなーと最近思うようになってきました。 分からないことが分からない状態で作業が進まず、時間だけが過ぎていくことが多いです。皆さんは分からないことが分からない時はどうしていますか?

  • システム開発に関してご質問させていただきます。

    システム開発に関してご質問させていただきます。 外部設計時の見積規模 : 2420FP 結合テスト開始4週間後に、 外部設計時の見積規模より20%テスト項目が不足していることが判明 また、内部設計以降にユーザー要件変更が多発したため 外部設計時の見積規模よりも20%大きくなった。 上記2点に対する対策が以下の場合に考えられる リスクはどのようなものが考えられるでしょうか。 対策1:規模の増加分も考慮し、テスト項目を追加する 対策2:テスト項目の増加分に対応するために、新たに作業要員を外部から     調達しテストを実施することによって予定期日内にテストを完了させる。 以上。 よろしくお願い申し上げます。

  • システム開発における

    システム開発における 問題点の分析について、アドバイス頂きたい事があり 投稿させていただきました。 <経緯> 現在使用している販売管理業務システムを 現行の業務と乖離してきている為内容を修正することとなった。 販売管理システムは、X業務システム、Y業務システム、Z業務システム 3つのサブシステムで構成されていて それぞれの業務に精通したメンバーを割り当てる必要があった。 ところが、かつて現有システムの開発に携わった経験を持ち、 各業務に精通しているメンバはわずか3名であり、 一方Z業務管理システムの構築に必要な特別なスキルを 身につけているのも、この3名だけであった。 結果として、A課長はこの3名をZ業務管理システムの開発に配置し、 X業務管理システム、Y業務管理システムともに、業務には精通しているが 開発スキルは不十分なメンバと開発スキルは十分だが業務の理解は 不十分なメンバの混成チームを編成し、各チームにリーダを配置し、本プロジェクトを開始した。 結合テストが終盤に差しかかる頃、 バグが多発しテストの進捗に影響を与えている状況が露呈した。 結合テスト工程でのバグ原因分析 サブシステム名 設計バグ件数 製造バグ件数 総バグ発生件数 X業務     51     89     140 Y業務     25     137    162 Z業務     2      21     23 全体      75     250    325 結合テスト工程でのバグ原因分析の結果によると、 X業務システム、Y業務システムについて それぞれ問題点を認めることができますが X業務システム、Y業務システムのリーダの立場として、 (1)表3の分析から、不具合を是正するためにどのようなことを行うか。 (2)プロジェクトの初期の段階でどのようなことをすれば根本的に  ここで生じている問題を回避することができたと考えられるか。 上記2点に関して、アドバイスを頂けないでしょうか。 以上。 宜しくお願い申し上げます。

  • このようなプログラム開発会社に勤めているとき、転職を考えますか。

    いつもお世話になっています。 このカテゴリーでは、プログラムを開発する会社に勤務する方が見ていらっしゃると思い、質問させて頂きました。 このような会社にいるとき、転職を考えたくなるかどうか質問します。 医療機関向けのプログラムを作成する会社で、私はプログラマー(以下PGと表記)として働いています。小さめの企業のため全従業員が100名未満で、営業所(技術センターも含む)が全国で約10ヵ所あります。PGがプログラムを開発し、システムエンジニア(以下SEと表記)がそのプログラムを病院に設置・設定等を行います。SEとPGのやりとりは、ブラウザ上で質問や返答をしています。 会社の長所と短所を以下に挙げます。 長所 (1)地元の企業の中では給料がいい。 (2)土・日・祝は休日である。 (3)各種保険が充実している。 短所 (1)会社のホームページには研修期間が約1年と書いてあるが、実際は半年ぐらいだった。プログラムの書き方や医療システム等、覚えるべき点はもっとたくさんあると思うのに、半年は短いと思う。 (2)先輩の話や就職掲示板の書き込みによれば、PGの技術はアマチュアレベルで、他の企業から見れば技術に魅力を感じない。また、ソフトの開発より修正の方が多い。病院側ではプログラムの不具合が原因で、別の会社のソフトに転向するケースもある。 (3)業績は下降気味で、新入社員を雇えない状況にある。仕事の量の割りに社員が少ない。 仕事の中で分からないところがあれば、先輩方に質問して解決するようにしています。入社してまだ1年なので、これからも頑張っていきます。 ただ、学生時代に学んだことと今の業種内容が異なっていることもあり、学生時代に学んだことを活かせる仕事にも興味があります。また、今の仕事は人と関わることがほとんどないため、学生時代にしたアルバイトのように、いろんな人と接する仕事にも興味があります。 皆さんの場合は、転職しますか。それとも働き続けますか。 ご意見をお聞かせ下さい。 よろしくお願いします。

  • キャリアアップで必要な知識(経験)

    24歳でPG暦1年半です。PGを一度辞めて異業種についてたんですが、IT業界に戻ることにしました。 PG時代のスキルはVBのみ・・・。ですがサーバー構築など好きでやってるので、多少のスキルはあると思います。 Linuxインストール→Oracleインストール→LAN上のクライアントのアプリケーションと接続まではできます。 IT業界に戻るにあたってITコンサルを目指してます(できれば経営まで)。 それでボクが考えてるステップとして、 PG→SE→プロジェクトマネージャー→ITコンサル と登っていきたいと思っています。 ここで質問なんですが、 1.SE、PM、ITコンサルでそれぞれ必要な知識ってなんでしょうか?(設計の知識?工数の予測?戦略?etc...) 2.転職するにあたって、PGからスタートする必要ないですか? 転職する会社で迷っていて、企業を判断する上で上記の答えがどうしても必要です。よろしくお願いいたしますm(_ _)m

専門家に質問してみよう