プログラムの実務で

質問

よろしくお願いします。

現在パソコンの講師の仕事をしています。
高校の情報処理の授業を担当することになりました。
自分自身はプログラムを組んだ経験はありませんが
プログラミングの説明をしなければなりません。
BASICの基礎なのでたいしたことはしないのですが
実際に実務をするときに教科書に書いてあるような
下記の流れでよいのかを知りたいです。

問題の分析　→　流れ図の作成　→　コーディング
→　プログラムの入力　→　テストラン・デバッグ
→　プログラムの実行

流れ図はフローチャートシートにテンプレートを
使って書き、コーディングシートに記入する、と
書かれてるのですが、実際にされてるのでしょうか？

教科書がちょっと古そうなので実務と少々ギャップが
あるような気がするのですが・・・

回答No.4

honiyon · ベストアンサー

こんにちは、honiyonです。

　フローチャートは、パソコン向けプログラミングではもう限界です。
　頑なに従って設計すれば、逆に生産効率が低下します。かといって設計は重要なので、各社、または開発者個人で効率的な設計手法を用いている場合があります。

　日本ではウォーターフォール形式と呼ばれる、Dpopさんがご回答されている方式が標準的ですが、他にスパイラル形式による開発手法があります。

　スパイラル形式とは、まとめて設計、まとめて開発、と呼べるウォーターフォールに対し、部品単位、機能単位で設計から開発を行うという、小さな設計、小さな開発を繰り返し行う手法です。
　開発者から見れば非常に効率の良い手法ですが、全体の工程や期間が見えにくいというデメリットとなり、これが日本のIT業界では致命的となり普及が進んでいません。

　というわけで、学校で学んだ知識は基本中の基本と捉えるのが良いでしょう。
　実務は、その基本中の基本を元に発展・効率化した形で作業が流れているという解釈が実際に近いかも知れません。

　参考になれば幸いです（。。

お礼

ご回答、ありがとうございます。

設計・開発の仕方も色々あるのですね。自分自身でも勉強してみて、色んな言語の基礎の基礎なんだろうなぁと思います。やはり会社に入ってからその現場、現場での業務で学ぶものなのでしょうね。とりあえず無難な線で説明できるようにがんばってみます。

とてもわかりやすい説明をありがとうございました！

回答No.8

funifuni_no_neko

BASICの基礎…という時点で古いと思うので、そのままの内容で良いんじゃないですかねえ。
即戦力となる人材を養成する訳でもないと思うので、そういった先人の通った道？みたいな物を学ぶことも大切かと思うので。

紙に書いてから入力ってのも良いんじゃないでしょうか。
あらかじめ全体像を把握しておいた方が、理解も深まるでしょうし。
私は最近まで学生でしたが、そんな感じで習いました。先生はおじいちゃんでしたが(笑)

お礼

funifuni_no_nekoさんも学校で授業受けられたんですね？

まぁ確かに教科書に沿ってやろうと思うと、かなり現実とはギャップがあると思います。実際「情報」とは何ぞやのうんちくとか歴史とか自分でもやってて眠くなりそうな内容から始まってますしね。でもそこに基本があるんでしょうからね、自分自身も勉強するつもりでやってみます。

ありがとうございました！

回答No.7

notnot

いちおう、システムアナリストやコンサルタントが外部仕様を決めた後とすると、

外部仕様の明確化→サブシステム分割→基本設計(=内部設計)(各サブシステムのプログラム分割と各プログラムの機能とかファイルやDBの論理設計、入出力形式の詳細決定、プログラム間のインタフェース設計)→プログラムの詳細設計→コーディングまたはCASE等プログラム開発支援ツールでのプログラム作成→単体テスト→関連プログラムとの連結テスト→サブシステム単位の結合テスト→システム全体での総合テスト→システム全体での実業務レベルのテスト(デバッグは随時。バグが多ければ仕切りなおしで前のテストステップからやり直し)

ここまでがプログラム開発で、パッケージソフトならその辺で終わりだと思います。
後はシステムインテグレーション等でシステムとして動かすまでを対象範疇とするなら、DB物理設計、性能設計、本番機器の仕様決定・発注・設置・設定、また連結テストあたりから平行して、サブシステム単位の性能テスト→システム全体での性能テスト、障害テスト、実運用に沿ったシステム運用テストや、現行システムからの切り替えテスト、切り替え失敗時の旧戻してストなどですね。ユーザー教育も必要です。

以上、中・大規模システムでの比較的伝統的手法での流れです。小規模システムの場合はもっと先進的な手法が使われているかと思います。

＞流れ図はフローチャートシートにテンプレートを
＞使って書き、コーディングシートに記入する、と
＞書かれてるのですが、実際にされてるのでしょうか？

フローチャートは使われるケースもあるでしょうが、主流ではないと思います。高校生が最初にやるプログラミングでなら使っていいんじゃないですか、
コーディングシート記入はまず無いでしょう。PCでの直接入力ですね。

単なるプログラマ養成なら、プログラム詳細設計を与えて単体テストか連結テストまででいいと思います。
プログラム詳細設計を書ける人がプログラムデザイナ。
基本設計や総合テスト計画が出来ない人はSEとは呼べない。

お礼

notnotさん、ご回答ありがとうございます。

実務経験を踏んだ方ならではの細かいご説明をありがとうございました。今回はPGやSEの養成というわけではなく、一般常識的な部分だけでよいのですが「現場はこんな感じ」という説明もできたら加えたいなと思いました。色々と参考にさせていただきますね。

ありがとうございました！

回答No.6

terra5

コーディングとプログラムの入力が分かれているのは、
20年以上前なら、まだそんな感じの処理があったと思いますが、今はもうその手順では無いように思います。
私が就職した当時の新人教育がそんな感じでしたが、
それが最後で、その後すぐに完全に端末での作業に移行しました。

だいたい、コンピュータの入力装置がキーボードでなくカードリーダー、出力がディスプレイでなくプリンタの時代の手順ですね。
一人一台占有できる現状では、コーディングとプログラムの入力は同時に行っていると考えていいでしょう。

あと、いきなり流れ図といのは、かなり規模の小さいプログラムでの手順だろうと思います。
就職当時、既にDpopさんの回答のような手順でしたし。

しかし、いつの時代の教科書なんでしょうね(^^;;

お礼

terra5さん、ご回答ありがとうございます。

現状がよくわかりました。ありがとうございます。教科書のほうは、おそらく改訂とかあまりしてないんじゃないかと思います。そもそもプログラマーの養成とかではないのです。ですが、これから学校教育もどんどん変わってくると思います。我々も勉強しなければならないことが増えてくるでしょうね～。がんばります！

回答No.5

ykkw_2001

＞流れ図はフローチャートシートにテンプレートを
＞使って書き、コーディングシートに記入する、と
＞書かれてるのですが、実際にされてるのでしょうか？

特に「コーディングシート」は、古代遺跡から発掘されてきてもおかしくはないほど、古いです。

基本的に”紙”を使うこと自体、よほどの客先要求がない限りは、されていないと思います。

大企業でＩＳＯ９０００などを導入しているとこは別です。（紙だらけです）

＞BASICの基礎なのでたいしたことはしない
でしょうが、個人的希望を言えば、どうか是非、紙に（手で）書くことを教えてやってください。お願いします。

お礼

ykkw_2001さん、ありがとうございます。

>個人的希望を言えば、どうか是非、紙に（手で）書くことを教えてやってください。お願いします

これは、処理手順をきちんと把握する癖をつけさせたほうがいいということなのでしょうか？プログラムは全く初めての学生対象なので一応書かせようとは思ってますが。

回答No.3

Dpop

Web屋です。

フローチャートを書く人も居ますね。全く書かない人も多いですね。僕がプログラムを書く時には、構造化プログラミングに都合の良い書き方をしています。

コーディングと言う作業も、今は研修で行う程度だと思います。パンチャーと言う専門職が居たころの名残だと思います。

僕は、設計屋なのですが、問題の分析からいきなり流れ図を作るという発想は、ちょっとびっくりです。
現実的には、

コンサルテーション → 問題分析 → 概要設計(外部設計) → 基本設計(内部設計) → 詳細設計 → プログラミング → 単体テスト → 内部結合テスト(スルーテスト) → 外部結合テスト → 本番テスト

なんて手順を踏む事が多いですね。

お礼

DpopさんはWebプログラマーなんですね～。憧れです！

さて、実務レベルでの流れをありがとうございました。教科書ではそもそもの処理がかなり単純なので、フローチャートを作ることのほうが面倒かなというくらいです。しかし実際には様々な手順が生じてくるでしょうから、そのようになるのでしょうね。

参考にさせていただきますね！

回答No.2

Tsukasa0215

>問題の分析　→　流れ図の作成　→　コーディング
→　プログラムの入力　→　テストラン・デバッグ
→　プログラムの実行

一応この流れであっています。

>流れ図はフローチャートシートにテンプレートを
使って書き、コーディングシートに記入する、と
書かれてるのですが、実際にされてるのでしょうか？
会社にもよりますが、この作業は省かれている場合もあります。

お礼

Tsukasa0215さん、ご回答ありがとうございます。

他の方もおっしゃってますが、フローチャートやコーディングシートの記入はあまりしないみたいですね。しかし初めての人は一応やっておいたほうがいいのかなという気がしてきました。

がんばって授業の組み立てをしてみます。

回答No.1

MetalRack

問題分析は、テストラン・デバッグで発見された不具合の修正に使うのが良いでしょう。

普通は、「要件定義」→「詳細仕様決定」と繋がっていきます。
プログラムとは、やらせたいことをマシンに指示するための物です。
まず、何をやらせたいのか「要件定義」を明確にする必要があります。
次に、それに沿った仕様を決めます。エラー理時の処理など、考えられる事象に対する対応を明確にしていくわけです。

お礼

早々のご回答、ありがとうございます。

説明が不足していましたが、「問題の分析」というのは手順のことを言っているようです。教科書の例題はいたって単純な処理です。でも実務ではもっと複雑な流れになるのでしょうね。

ありがとうございました！