![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-12-15T23:06:19+09:00","default:irrp","irrp") #author("2024-04-09T10:24:24+09:00","default:irrp","irrp") →上流工程一般 →要件定義 →アーキテクチャ →詳細設計 #contents * 基本設計と詳細設計の違い [#jdd1e783] -基本設計は大雑把な設計、詳細設計は細かい設計だと思っている人がいるが、それは誤り -基本設計は、システムを外から見たときどういう動きをするか（＝外部設計、What）を決めるもの。詳細設計は基本設計で決められた動きをどうやって実現するか（＝内部設計、How）を決めるもの、と考えるとよい。 -基本⇔詳細という言葉に惑わされず、外部から見たときの動きについての話なのであれば、どんなに細かいことでも基本設計に書く。 *一般 [#p99f0dd0] -[[システムで「性別」の情報を扱う前に知っておくべきこと #プログラミング - Qiita>https://qiita.com/aoshirobo/items/32deb45cb8c8b87d65a4]] 2024.4 -[[【入門】事例で学ぶ基本設計 #データベース - Qiita>https://qiita.com/KNR109/items/5d545903ec7fef85cd37]] 2023.12 -[[【入門】基本設計>https://zenn.dev/sutamac/articles/13d13809973c48]] 2023.11 -[[パッケージ設計の原則を本で学ぶ - Qiita>https://qiita.com/kamikawa_m/items/c905ff7cea8d6e199dd6#:~:text=%E3%81%9F%E3%82%82%E3%81%AE%E3%81%A7%E3%81%99%E3%80%82-,%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8%E8%A8%AD%E8%A8%88%E3%81%AE%E5%8E%9F%E5%89%87%E3%81%A8%E3%81%AF%EF%BC%9F,%E9%96%A2%E4%BF%82%E3%81%AE%E6%8C%87%E9%87%9D%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82]] 2023.10 -[[全ての基本は構造化から。『組み込みソフトウェア開発のための構造化モデリング』 - ろぐれこーど>https://dlrecord.hatenablog.com/entry/2020/12/30/131554]] 2023.9 -[[ロストテクノロジー化する外部設計 - Qiita>https://qiita.com/kaku3/items/6442adb13601dd06f84e]] 2023.9 -[[「システム設計の面接試験」という本が良かった>https://zenn.dev/taiga533/articles/3e3671d92e6cfe]] 2023.8 -[[分散システムについて語らせてくれ | ドクセル>https://www.docswell.com/s/kumagi/ZXYYLN-let-me-talk-about-distributed-system]] 2023.4 -[[「設計」で大事なのはこれだった！半年間で40本レビューして分かった 5つのポイント - Link and Motivation Developers' Blog>https://link-and-motivation.hatenablog.com/entry/2022/10/05/181858]] 2022.10 --1. ✅ 選択肢を網羅できているか --2. ✅ 機能要件を深く理解して観点を出せているか --3. ✅ 非機能要件も考慮できているか --4. ✅ 開発工数や拡張性を考慮できているか --5. ✅ 要件や工数のmust/wantと選択肢に対する評価が正しいか -[[GitHub - karanpratapsingh/system-design: Learn how to design systems at scale and prepare for system design interviews>https://github.com/karanpratapsingh/system-design]] 2022.8 -[[いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Sr. Product Manager @ Mercari｜note>https://note.com/fmkpro1984/n/n09a2f5b01f33]] 2022.8 -[[令和時代のシステム開発では、どのような設計書を書くべきか>https://thinkit.co.jp/series/9344]] 2020.7 -[[リトライと冪等性のデザインパターン>http://frsyuki.hatenablog.com/entry/2014/06/09/164559]] 2014.6.9 -[[システム分析アプローチを後輩と話した件>http://getlife.hateblo.jp/entry/2014/04/09/041606]] 2014.4.9 --POA,DOA,SOAの比較 -[[上流工程-設計>http://itpro.nikkeibp.co.jp/article/COLUMN/20060831/246890/]] -[[機能要件設計書だけで20種類>http://itpro.nikkeibp.co.jp/article/COLUMN/20090108/322434/]] 2009.1.8 --基本設計は大きく分けて三つのプロセスを踏む。いずれの設計も入力情報となるのは要件定義で作成した成果物である。 ---「機能要件設計」どのような機能をアプリケーションに求めるかを設計する。その際「画面」「業務プロセス」「データ」という三つの切り口に分ける。 ---「システム方式設計」システム方式設計では、性能や信頼性などの非機能要件を整理する。それを踏まえて、ハードウエアやソフトウエアなどの構造や実装方式を練る。 ---「アプリケーション方式設計」アプリケーション方式設計では、非機能要件を考慮しつつ、機能要件設計で明確にした機能（画面、業務プロセス、データ）を適切なサイズのモジュールに割り当てる。 --[[基本設計で作成する設計書の一覧(日立システム開発方法論「HIPACE」を基に作成)>http://itpro.nikkeibp.co.jp/article/COLUMN/20090108/322434/?SS=imgview&FD=54139247]] -[[異種統合型情報サービスシステムにおける自律分散アシュアランス技術の研究>http://tdl.libra.titech.ac.jp/cgi-bin/z3950/gakui_detail_disp.cgi?REG_NO=117193144]] -[[システムのリプレース案件が最も危険な理由>http://forza.cocolog-nifty.com/blog/2008/02/post_6234.html]] 2008.2.24 --運用していくうちに、バグフィックスや機能追加で、恐竜のように馬鹿でかくなった中身は、最新のオブジェクト指向言語で、同じようにたくさんのバグフィックスを重ねて積み上げたものに変わる。 同じソースコードの断片は一つもないはず。 --プログラムの保守性や移植性、再利用性が、どの時代になっても、言語がいくら発展しても難しいこと。 --特に再利用性は、そのライブラリの粒度に大きく依存する。 --再利用できる程度は、フレームワーク程度ぐらいで、昔から夢想するビジネスオブジェクトレベルまでなかなか辿り着けない。 -[[ドキュメントに「夜間バッチ」と書いてはいけない>http://enterprisezine.jp/article/detail/15?p=1]] 2007.7.30 --「○○ジョブ」には、「これらを整形し直し、本社DBに格納する」という意味が推測できるような名前をつけなければならない。「夜間バッチ」では単に「夜間にまとめて行う処理」というだけの意味しか表していないため、その推測ができない。これではいけないわけだ。 -[[オブジェクト指向の基本設計を理解する>http://itpro.nikkeibp.co.jp/article/lecture/20070702/276411/?ST=lecture&P=1]] --UP:ユニファイド・プロセス -[[DOA法による基本設計の解説>http://itpro.nikkeibp.co.jp/article/lecture/20070702/276410/?ST=lecture&P=1]] **画面設計 [#p5d3b47d] -[[Figmaのコンポーネントに動きをつける - Qiita>https://qiita.com/tomo_oe/items/89b617a5988f19adc33f]] 2022.10 * 要件定義と基本設計の違い [#od43245f] -要件定義とは、そのシステムで実現したい（および実現しない）ことをまとめたもの。そのシステムで何ができるのか、何が実現できるのかという効能を整理したもので、システムの具体的な動き、仕様までは書かないのが普通。 -要件定義をインプットとしてシステムの外部仕様を決めるのが基本設計。そのシステムを「外側から見たときの」具体的な振る舞いを定義する。 --どういうデータ項目がDBや画面、帳票などに対してどのように出し入れされるか、画面遷移、各機能の整理など -要件定義の一般的項目→要件定義書の一般的な項目 ・業務要件：現状、新業務フロー等 ・システム要件：インフラ系を中心にネットワークやシステム構成等 ・セキュリティー要件：セキュリティに関しての要求事項等 ・機能要件：大まかな機能や、「これを実現して欲しい」等の要求 ・非機能要件：性能要件や障害発生時にどうなるかなど ・運用要件：運用まわり、バックアップ、容量見積等 ・その他：ケースバイケースで他に何かあれば ・昔はレスポンス要件等もあったがＷＥＢでは保証できない -基本設計の一般的項目 ・システム設計：インフラ、ネットワーク、機器構成、プロダクト構成等 ・画面設計：デザイン、項目定義等 ・ＤＢ設計：論理／物理設計、ＥＲ図等 ・インターフェイス設計：他システムとの外部インターフェイス、ファイル、帳票設計等 ・処理設計：ＤＦＤ、ＩＰＯ、ＣＲＵＤ、コード設計等 ・業務・運用設計：サービススケジュール、バックアップ、リカバリー方法 新業務フローの詳細等 ・テスト設計：テスト方法、ツール等の設計 ・その他：補足資料他
