👋

ソフトウェア設計 2023

2023/10/14に公開

システムが重視する物

これを1~10で表現していくと、グループA,Bのそれぞれの組み合わせのどれかになる

グループA

グループB

企業として必要なシステム
基本的にパッケージが強い(規格を満たす目的なのでパッケージ化し易い)
規格への準拠が高く、更新速度はそれほど高くない

基幹システム
その企業の業務・業態・やりたいことが詰まっているのでパッケージ化し難い
ERP等で切り出せる部分についてはパッケージ化も進む
規模とデータモデルが高く、更新速度が比較的高め

情報システム
企業としてやりたいことを実現する事を「考えるため」のシステム
最小のツールはExcel
色んな会社がシステムを提供している
データモデルとアーキテクチャが高い

コミュニケーションシステム
企業内外とスムーズなやりとりをする為のシステム
Mailとかビデオチャットとか、カレンダーとか
基本的にパッケージが強い
アーキテクチャと規模と更新速度が高い、物によっては規格への準拠も

他(ゲームとか)
大抵の場合は数年程度で保守含めて寿命を迎える
足回り含めての変化が激しいので保守よりも完成後の品質が重要
足回りのフレームワーク等が充実しているのでそれを利用する
基本的にアイデア勝負なソフトウェア
更新速度が高い

この分類上では「開発する数」としては会社毎に固有の事情を取り込むために基幹システムが多くなる
そして比較的寿命も長い(最短5年、最長は可能な限りというのが基本的な希望)

ということで、ここから基幹システムの話

要件定義
企業内で使われるシステムなので抑えるべき重要なポイント

思いつかないとか、難しい場合は画面をイメージしながら作っていく
（この時点では画面の正しさ・使いやすさ等に深入りしないこと

ビジネスフローと要望機能をデータモデル軸でこんな感じで分類する

サマリーは色んな情報を集計して集めた物
一次情報はユーザのアクションにより操作されたもの
二次情報は特定の物を対象にして複数のデータモデルを集約した物
マスタはシステム内では比較的変動の少ない情報
ログは記録として一定期間保持することが目的な物

最初の設計時点ではマスタと一次情報と二次情報に注力する（ログとサマリーはその時の参考情報

データモデルを仮で作る
ここで作ったデータモデルは機能を詳細に分析してるとあとから大きく変化することもある

それぞれのデータの状態遷移を作る
状態遷移をシンプルにする

二次情報と一次情報を切り分ける
本当はモデルを分離したり、状態遷移として分割したりしたデータモデルを二次情報として扱う
二次情報を作る為の設計と検証はこの辺りの段階で大まかに実施する

マスタとログについてのデータモデルを追加する（この場合の状態遷移は作成・更新・削除の基本パターンになる
他に管理目的で必要なデータモデルも追加する

ここまででできたデータモデルを正規化する
少なくとも第三正規化まではする

要件定義で定義した内容が今まで作ったデータモデルと状態遷移で表現できるのかを確認する
ポイントは過不足がないこと、広範囲に複雑さが無いこと、可能な限りシンプルなこと
必要に応じて追加修正する

作るべき機能一覧から、それぞれの機能の中身にマッピングする
扱うデータと状態遷移Actionを入れ込む