#author("2023-01-08T13:16:35+09:00","default:irrp","irrp") →上流工程一般 →要件定義 →詳細設計 #contents * 基本設計と詳細設計の違い [#jdd1e783] -基本設計は大雑把な設計、詳細設計は細かい設計だと思っている人がいるが、それは誤り -基本設計は、システムを外から見たときどういう動きをするか(=外部設計、What)を決めるもの。詳細設計は基本設計で決められた動きをどうやって実現するか(=内部設計、How)を決めるもの、と考えるとよい。 -基本⇔詳細という言葉に惑わされず、外部から見たときの動きについての話なのであれば、どんなに細かいことでも基本設計に書く。 *一般 [#p99f0dd0] -[[「設計」で大事なのはこれだった!半年間で40本レビューして分かった 5つのポイント - Link and Motivation Developers' Blog>https://link-and-motivation.hatenablog.com/entry/2022/10/05/181858]] 2022.10 -[[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] -要件定義とは、乱暴に言うとそのシステムで実現したい(および実現しない)ことをまとめたもの -要件定義の一般的項目→要件定義書の一般的な項目 ・業務要件:現状、新業務フロー等 ・システム要件:インフラ系を中心にネットワークやシステム構成等 ・セキュリティー要件:セキュリティに関しての要求事項等 ・機能要件:大まかな機能や、「これを実現して欲しい」等の要求 ・非機能要件:性能要件や障害発生時にどうなるかなど ・運用要件:運用まわり、バックアップ、容量見積等 ・その他:ケースバイケースで他に何かあれば ・昔はレスポンス要件等もあったがWEBでは保証できない -基本設計の一般的項目 乱暴に言うと、要件定義をインプットとしてシステムの外部仕様を決めるのが基本設計 ・システム設計:インフラ、ネットワーク、機器構成、プロダクト構成等 ・画面設計:デザイン、項目定義等 ・DB設計:論理/物理設計、ER図等 ・インターフェイス設計:他システムとの外部インターフェイス、ファイル、帳票設計等 ・処理設計:DFD、IPO、CRUD、コード設計等 ・業務・運用設計:サービススケジュール、バックアップ、リカバリー方法 新業務フローの詳細等 ・テスト設計:テスト方法、ツール等の設計 ・その他:補足資料他 *アーキテクチャ [#ua38b434] -一般的にアーキテクチャとは、設計時の大きな方向性や方針を意味する。 -要件は実現しようとする機能の内容に重点を置くが、アーキテクチャは機能の実現方式に重点がおかれる。 -アーキテクチャ選定は基本設計で行うものかというと必ずしもそうではなく、基本設計レベルのアーキテクチャと詳細設計レベルのアーキテクチャとで、それぞれ存在する。 --例えばオブジェクト指向やドメイン駆動設計はアーキテクチャの一種とも言えるが、基本設計というよりは詳細設計時に使うアーキテクチャだろう。 -[[「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった: プログラマの思索>https://forza.cocolog-nifty.com/blog/2022/09/post-808092.html]] 2022.9 -[[SOLIDを代替する設計原則、CUPIDについて - Qiita>https://qiita.com/devneko/items/b9d8c734099f5e2b510c]] 2022.9 -[[The Software Architecture Chronicles – @hgraca>https://herbertograca.com/2017/07/03/the-software-architecture-chronicles/]] 2017 --[[DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together – @hgraca>https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/]] 2017 -[[アーキテクチャの「なぜ?」を記録する!ADRってなんぞや? - Qiita>https://qiita.com/fuubit/items/dbb22435202acbe48849]] 2019 --[[Architectural Decision Records | adr.github.io>https://adr.github.io/]] -[[アーキテクチャと設計は全然違う⋯ただしあなたの想像する”違い”とは多分全然違う【輪読会発表紹介】 - エムスリーテックブログ>https://www.m3tech.blog/entry/software-architecture-chap2]] 2022.6 -[[「ソフトウェアアーキテクチャの基礎」を読んだので、その要点 - Qiita>https://qiita.com/e99h2121/items/1844f5ed8da453a6dfb0]] 2022.3 -[[アーキテクチャに関してのありがちなギモンに答えていく - Qiita>https://qiita.com/SDTakeuchi/items/14b0a227f1bf30c71f66]] 2022.2 -[[DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien>https://digitalsoul.hatenadiary.org/entry/20100131/1264925022]] 2010 -[[ソフトウェアアーキテクチャの歴史>https://scrapbox.io/tasuwo/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%81%AE%E6%AD%B4%E5%8F%B2]] 2019.7 --GUI アーキテクチャの話.MVC, MVVM, -[[ソフトウェアアーキテクトが知るべき97のこと>https://ソフトウェアアーキテクトが知るべき97のこと.com/]] ** クリーンアーキテクチャ [#b9c3c60d] -[[Hexagonal Architecture and Clean Architecture (with examples) - DEV Community>https://dev.to/dyarleniber/hexagonal-architecture-and-clean-architecture-with-examples-48oi]] 2022.8 -[[PythonでLayered ArchitectureとClean Architectureを使ってカレーと肉じゃがを作ってみた - Qiita>https://qiita.com/c0ridrew/items/41f0566b676d8092a9fb]] 2022.7 -[[「Clean Architecture」を読んだので、その要点 - Qiita>https://qiita.com/e99h2121/items/6cd719b6b871d1c3d03b]] 2022.2 -[[最速でアプリケーションアーキテクチャの答えであるクリーンアーキテクチャを理解する - Qiita>https://qiita.com/izzonn/items/c06492a3e4bdc58b4ca8]] 2021.12 -[[Clean Architecture の勘所は『鎖国』だ。>https://qiita.com/t2-kob/items/02a76572693130c9a66e]] 2021.8 -[[クリーンアーキテクチャをミニマルで実装可能な形にした Simple Clean Architecture という考え方>https://qiita.com/genki-sano/items/4538383c7b52ba19ebe6]] 2021.6 -[[実装クリーンアーキテクチャ>https://qiita.com/nrslib/items/a5f902c4defc83bd46b8]] 2020.5