プログラムの設計について質問です。

１についての回答なのですが、おそらく職場にいった場合はプログラミングの方を先にやることになると思います。

要は先輩の作成した、詳細設計に基づいてＰＧを作成する。

詳細設計はあってもフローは必要だと思いますので、基本設計よりもＰＧの為のフローだと思います。

でもって、現場の環境が分かるにつれて基本設計書、外部、内部の設計書も作るようになると思います。

１のみの回答ですので、参考に鳴らないようでしたら、ポイント不要です。

1.

　一人でプログラムを設計すると仮定します。

　利用する言語が確定しているならば、

　フローチャート（それ以前にアルゴリズム

　の勉強をしたほうがより良いのですが）を

　先にやると、基本設計時に必要な項目を

　考えやすくなります。

　逆に利用言語を用途で選ぶ場合が主であれば

　設計思想を言語にとらわれずに書けるよう

　SE的な部分を先にやってから、どの言語で

　どうフローを組めばよいか、という順で

　学習していったほうが馴染めます。

３．

　DynamicDraw　というフリーソフトや

　Microsoft Visioという製品が有名です。

1番のみ回答します。

「フローチャート」なんざ勉強せんでよろしい。

全然役に立ちません。無駄です。無意味です。

まともな所なら、もうすでにフローチャートは

使われなくなっています。

以前に、フローチャートを山ほど書いた僕が

断言するのですから、確かです。

最近では UML が流行のようです。

基本設計書は必要ですが……つーか、ソレが

ないと仕事は始まらないんで。

でも、「素人がそれなりのソフト」となると

仕事としてやってるわけではないのですね?

なら、設計は気にしないでバリバリコーディング

して下さい。それがハッカーの正しい道です。そうして経験を積んで、設計がわかって

来ます。

1.趣味としてソフト開発をするのであれば、恐らくSE的仕事(仕様決定)とPG的仕事(プログラミング)を両方行う必要があると思います。実際の職場でも、SE的仕事とPG的仕事を同時にこなす場面というのは多々存在します。そのとき、PG的な事を全く知らずに設計することは不可能だと思われますので、まずはPG(プログラム言語・アルゴリズム)の知識をある程度習得した方がよいと思われます。

ちなみに、フローチャートというのは最近の言語の振る舞いを記述するのには適していない場合が多いため、PG的仕事＝フローチャートとは考えない方がよいと思われます。

とりあえずは適当な言語を一つか二つ習得された後で、プログラム設計を行う事をお勧めいたします。

2.「アルゴリズム」でググってみました。

アルゴリズム入門

アルゴリズムはプログラミングの主となるものですから、良い書籍も沢山出版されていますので、書店等で探してみるのも良いかと思われます。

3.仕事ではWordとExcelしか使ってません(笑)

１の回答ですが、フローチャートの勉強が先です。

基本設計というのはプログラムによって

何が実現でき、何が実現できないかを知らなければいけません。

実際、開発業務となると（システム屋ですが）

プログラムのスキルがない人が設計したりしますが、

そういう人の設計書はボロボロです。

ほぼユーザの言葉をそのまま書いたようなものということが多いです。

しかしフローチャートがかけなくてもアルゴリズムの勉強をしておけば問題ないです。

むしろ今時フローチャートなんて使いません。

何故かというと、最近はオブジェクト指向的な開発が主流になってきていますが、

オブジェクト指向的な設計にフローチャートが向かないからなのです。

では、実際に何が使われているかというと、主にＵＭＬです。

ＵＭＬは資格もあり、実際に読み書きできるととても便利です。

２の回答ですが、ＵＭＬやアルゴリズムといったキーワードでgoogleで検索すると

いっぱいヒットしますので、自分のレベルにあったものを見るのが１番かなと思います。

ですので、ＵＲＬは書きませんが、理解できそうなものから読み始めるといいと思います。

３の回答ですが、基本設計書といっても各会社によってマチマチですが、

データベース設計や、画面設計は主にエクセルで作ります。

画面設計は直接ＨＴＭＬを書いたり、イラストレータやフォトショップで作成することもありますね。

ＵＭＬの設計はフリーソフトで、Judeというツールがあります。

これは純国産のソフトですので、使いやすいと思います。

他にRational Rose(IBM)やEclipseのプラグインのEclipseUMLを使うこともあります。

プログラムを覚えるのであれば、アルゴリズムの勉強と

実際にプログラムを書いて、頭で覚えるというのを並行しておこなうのが一番いいと思いますよ。

理論だけ学んでも、なんにも楽しくないですし、実際に頭に入りにくいですね。

1. どちらかといえば、フローチャートの方でしょう。

ただ、ソフトを作るということはきちんと文書化するかどうかを別にすれば、結局はどっちもやることになりますね。

また、フローチャートを勉強するというよりは、コーディングできるレベルでの具体的な処理手順を考えることと思ってください。

その表現のひとつがフローチャートです。

嫌われるのは、簡単にいくらでも汚いフローチャートが書けてしまうからです。

フローチャートを書くこと自体はそんなに難しい事ではないと思います。

ただ、それを書くための考えを具体化することが勉強すべきことでしょう。

1. 実現可能性が無い基本設計なぞいりません。

ソフトウェアの仕組み、言語、その他様々なことを知らない人が書いた設計書ほど信憑性の低いものは無いでしょう。

かと言って、フローチャートを書いている人は最近見たこと無いです。また、他の方が勧めているUMLですが、オブジェクト指向のことが分からないと理解は難しいとおもいます。まぁ、この考え方は賛否両論あるでしょうが。

UMLが理解でき、書くことができれば基本設計・詳細設計のどちらも「ある程度は」いけます。多分。

2. UMLについては山ほどありますので・・・

3. UMLならJude、Eclipseプラグイン、基本仕様書ならOffice製品、DB設計ならERwin、Eclipseプラグイン、等等でしょうか。

「システム」1つ作るにもいろいろな技術要素が必要になるので、一概にコレだけやっておけばOKとは言えません。

ただ、間違いなく言えるのは基本設計だけでシステムは動かないし、フローチャートだけで望ましいシステムの絵は書けない、ということです。

SE、PG両方のスキルが無いと(あるいは分担しないと)成り立たないでしょうね。

趣味の世界であれば、単に言語から入っていくことをお勧めします。そこから必要なものが見えてくるでしょうし。