- ベストアンサー
設計書の書き方 業務の流れ
最近プログラムの仕事に就くことになりました。 そこでいくつか教えて頂きたいのですが １．プログラムの仕事における業務の流れ 例）基本設計→構造設計→詳細設計→DR？ ２．設計書の書き方、レビューの仕方等 上記の件で参考になる書籍やサイトがあれば教えてください。
- oeppu08
- お礼率63% (33/52)
- その他（プログラミング・開発）
- 回答数5
- ありがとう数5
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
他の方が、共通フレームをご紹介になってらっしゃるのでその補足を。 「共通フレーム98」は版元の通産資料調査会が倒産したため長く絶版品切状態が続いていました。98年版はその前の「共通フレーム94」を国際規格との整合性をもたせるために改訂したものです。 http://www24.big.or.jp/%7Etss/shoseki/slcp98.html 又、共通フレーム98に基づいたシステム開発に関する書籍がありますが、設計書の書き方と云うよりもIT関係の仕事の流れを掌握するには良いかも知れません。 http://www.tdupress.jp/book_da/ISBN4-501-52930-X.html 上掲の国際規格の日本版は「JIS X 0160」です。内容は日本工業調査会のホームページから閲覧できますし、印刷物は日本規格協会で取り扱っていますが、ヴォリュームの割りに高い印刷物です。 調査会のJIS検索です。 http://www.jisc.go.jp/app/JPS/JPSO0020.html なお、現在は「2007」ですがこれは、情報処理振興機構で推進し「オーム社」から書籍が出版されています。（下記URL） 後、このようのカリキュラムは概略だけですが参考となるやも知れません。（94年頃にはテキストもあったのですが絶版） http://www.ipa.go.jp/jinzai/risa/study/kenshu02.html http://www.ipa.go.jp/jinzai/risa/study/kenshu03.html http://www.ipa.go.jp/jinzai/risa/study/kenshu04.html 参考となれば幸甚です。
その他の回答 (4)
- nakatyuu
- ベストアンサー率20% (2/10)
「発注者ビューガイドライン」 設計書の書き方ではないけれど、わかりやすさ、伝えやすさをまとめたものです。 一読の価値があると思います。
補足
ご回答ありがとうございます。 参考サイトすごいです。自分が知りたいことがたくさんあり熟読しようとおもいます。
- gyrocompas
- ベストアンサー率23% (24/104)
プログラマーの仕事から始めるとすれば まず詳細設計を理解することから始めねばなりませんが、 この様式は、開発現場によってさまざまで 前もって、書籍で勉強しておくのは無理でしょう それより、プログラミングの復習をした方が良いでしょう。 心構えとして、詳細設計は、徹底的に理解することを こころがけましょう。 少しでも、おかしなところや、矛盾点や、理解できないところは なくすようにしなければいけません。 詳細設計書を読んでもわからないことは、ありがちなので 疑問点はかならず設計者に質問して明らかにして下さい。 疑問点や理解できないところを、そのままにしておくと あとで、泣きを見るのは、プログラマーですので。
お礼
ご回答ありがとうございます。 なるほど。だから自分が探している書籍があまり見つからなかったのかもしれません。 プログラムはかなり久しぶりなのでそちらの復習に重点をおきたいと思います。
- R32C
- ベストアンサー率39% (115/290)
（Software Life Cycle Prosses-Japan Common Frame） SLCP-JCF98 の本とかが具体的でわかりやすかったです。 絶版になっていると思いますが、 SLCP-JCF2007の本があるらしいですが、中身みてないのでわかりません。 SLCP-JCF98は、JIS X0160と大体同じらしいので 日本工業規格のページから X0160で検索するといいでしょう。 エンジニアリングの視点 開発プロセス あたりでしょう。 基本的には、共通フレームから自社用の基準に変えて運用するのが 一般的です。
お礼
ご回答ありがとうございます。 ご指摘された本をチェックしてみます。
- asuncion
- ベストアンサー率33% (2126/6288)
> １．プログラムの仕事における業務の流れ > ２．設計書の書き方、レビューの仕方等 社内標準規約はありませんか？
お礼
補足に記載漏れしましたのでこちらに記載します。 上記の他に各設計書が具体的にどういうものでどういう内容なのかも あまり分かりませんので教えていただけないでしょうか
補足
業務の流れの方はあるとは思いますが設計書の方はないと思います。 また一般的にはどういう流れなのか知りたいと思い質問させて頂きました。
関連するQ&A
- 設計業務におけるクレーン選定
お世話になります。 今業務で設計を行っているのですが、クレーン選定の仕方がどうもよく分かりません。 参考になる書籍やＨＰ等ありますでしょうか？ よろしくお願いします。
- 締切済み
- 研究・開発・技術職
- 設計についてわかりづらいご質問ですが・・
現在概要設計というフェーズで作業をしています。PGや保守など技術寄りの仕事が長く、はじめての上流の仕事なのですがちょっと壁にぶつかっています。 現状としては業務フローが機能分割され自分はそのうち５機能ほどを担当しています。 でその機能をプログラム化をイメージした設計書に起こす必要があるのです（ちょっと詳細よりかもしれません）。 ただどうも自分の意識の問題かもしれませんが、プログラム化をイメージはできますが業務よりの下記のような意識（発想）がなかなか持てないのです。 ・業務全体としてその機能の役割 ・業務であり得るデータのパターン ・各論理テーブルが持つ業務的な役割 結局、業務的な説明ができないため作成した設計書のレビューでうまく話ができない状態です。 なにかきっかけをつかみたいのですが・・。 わかりづらい内容ですがどうぞよろしくお願いします。
- 締切済み
- SE・インフラ・Webエンジニア
- 機械設計の業務（実務）にはどんなものがありますか？
機械設計の技術者を抱えています。 概念設計／基本設計／詳細設計の各技術者が居るのですが、その者たちの設計実務スキルを数値化したいと考えています。 ○○の○○ができる／できない。○○の知識がある／ない。 例えば 「ねじ」の「選定」 が 「できる／できない」 などの設問から、客観的に且つ明確に判断したいと考えているのですが、その設問作成で壁に当たっています。 概念設計にはどんな実務や知識が必要か？基本設計には？詳細設計には？ ・概念設計＝仕様決定やアイデアの創出 ・基本設計＝具体的構造や形状の決定 ・詳細設計＝詳細な寸法公差や加工基準等の決定や製図 これらの分類内容はわかるのですが。。。 実務内容で判断するために、何か良いアイデアはないでしょうか？ そんな機械設計の実務一覧表などご存知ありませんでしょうか？
- 締切済み
- 機械設計
- 基本設計 詳細設計は何をするの？
職務経歴書のサンプルを見ると担当業務の欄などに、「基本設計」とか「詳細設計」と書かれていますが、基本設計や詳細設計はそもそも簡単にいうとどんな事を指しているのでしょうか？ どなたか、教えて下さい！
- ベストアンサー
- Microsoft ASP
- 設計業務について
場違いな質問であれば申し訳ありません。 自分は大学を出て1年目で今電気設計のほうをやらして頂いているのですが、勤めている会社の残業時間が夜の10時まで毎日あるのですが、設計の業務だとこれが当たり前なのですか、ちなみに自分は、仕事がなくて早めに帰ったことがあるのですが、同僚に上司が帰るまでいているのが当たり前と違うのかと、 上司が言っていたと聞いてから怖くて帰れません。 すみませんが参考にしたいので教えていただけませんか。
- 締切済み
- 製造業の財務・経理・相続
- 業務の流れがどんどん変わります
金融関係の仕事をしているのですが、毎日のように業務の流れが変わります。指示は基本的にはメールで来るのですが、同じことでも対処法が変わったり、報告方法が変わったりします。 収集がつかなくなることがあるのですが、こういう場合皆さんはどのようにして自分の頭を整理していますか？
- 締切済み
- その他（ビジネス・キャリア）
- Webシステムの設計で
あるWebシステムの開発プロジェクトの仕事をやっています。 現在基本設計の段階です。 この仕事は、あるメーカー系の企業から請け負った仕事なんですが、 基本設計工程はその企業がメインで行い、うちの会社は支援として携わることになっています。 詳細設計以降の工程は、うちの会社が全て行います。 基本設計で画面設計をやっているのですが、要員不足、スケジュールの遅れということもあり、 うちの会社がやることになりました。 個人的な考えではありますが、本来はメインとなる請負元企業が行うべきではないかと思っています。 うちがやっているのはたたき台の作成で、最終的にはその企業とレビューの結果が最終形になります。 今までいくつかレビューをやっているのですが、その企業とうちの会社との考えが異なることがよくありました。 そのときに、「業務をわかっていない」とか「設計のスキルが足りない」などと言われたのですが、 私にはそうは思えなくて、ユーザインタフェースなど画面の見せ方に関する考え方の違いが出ているだけだと思うんです。 結局その企業の言う通りにするんですが、それならその企業から「こういう感じで作って」と指示があってもいいと思うんですが、それもありません。 作業のロスをなくすために、できるだけ設計のやり直しは避けたいのですが、その企業に対して、こういう主張をしても大丈夫でしょうか？
- ベストアンサー
- SE・インフラ・Webエンジニア
- メーカーの設計業務
今年社会人1年目の男性です。 大卒後、大手機械メーカーに勤務してます。 設計業務をしているのですが、いまいち設計という感じがしません。 設計って、もっと製品を見て、触って、考えて作る業務と考えていましたが、やらされる仕事は尽く 書類雑務ばっかりです。参考に完成図面見せてもらったりするのですが、何が何やらぜんぜんわかりません。 例えば、電気回路図のある部分は、製品のどの位置に搭載されているもので、どのような機能を果たすものなのか分からないという感じです。一応、私は電気系出身なので、知識はあるのですが、どうにも仕事の実態がわかりません。 要求仕様書通りに電気回路図を変更する業務も、流れ作業で淡々とすすめるので、頭を使って設計(?)してる実感がわかず、困っています。 そんな感じなので、いざシステムの詳しい事を聞かれると答えられません。 なにせ、システムの事なんか理解せず仕事自体が完遂できてしまうわけですから・・・・。 これって、私の業務の進め方が行けないんですか？ それとも、仕事とはこういうものだと割りきってしまうべきなのですか？？
- ベストアンサー
- SE・インフラ・Webエンジニア
- ソフトウェア開発の流れ
ソフトウェア開発の流れについて知りたいのですが、あるサイトには、(1)要求分析(2)概要設計(3)詳細設計(4)プログラミング(5)テスト(6)実施 とありますが、基本設計とかっていうのはどこにあてはまりますか？また、基本的に(1)～(6)の流れが一般的な開発の流れなんでしょうか？ 宜しくお願いしますσ(^^)
- ベストアンサー
- その他(ソフトウェア)
- [ソフトウェア設計]処理の流れは、アクティビティ図？フローチャート？どちらで書くべきか。
VCですでに組まれているソフトの設計を設計書として文書にする作業をしています。 （現状あるソフト設計を別のソフトの設計に継承するため、このような作業が発生しました。すでに組まれているソフトには設計書がありませんので、参照はできません。） この場合、ソースコードに記載されている処理の流れは、UMLのアクティビティ図で書けるのでしょうか？ 参考書でアクティブ図を勉強しましたが、プログラムの処理の流れ（基本情報技術者試験の擬似言語で記載されているような処理）をそのまま書いたような図は見つかりませんでした。一般的には、プログラムの処理の流れは、アクティブティ図では、書かないのでしょうか？ そのような処理は、フローチャートで書くべきなのでしょうか？ シーケンス図も一緒に書いていますので、できたらUMLで統一し、アクティブティ図で書きたいのです。 設計書は、今まで記載していなかったので、ノウハウがありません。 知識がおありの方がおられましたら、ご教授お願いいたします。
- ベストアンサー
- その他([技術者向] コンピューター)
補足
ご回答ありがとうございます。 自分が求めていた情報がまさにこれです。 参考にさせていただきます。