search

haseryo0403 / TIL

1 stars 0 forks source link

プロジェクト計画から詳細設計までの勉強について #1

Open haseryo0403 opened 4 months ago

haseryo0403 commented 4 months ago

入門、超実践編以外に、 ・【超初心者向け】【システム開発の流れから学ぶ】エンジニアとして活躍するための知識・スキルを明確化！【現場を知る】 ・手を動かして学ぶITプロジェクトの資料作成！システム開発のドキュメンテーション技術と成果物テンプレート ・はじめてのテーブル設計・データベース設計【わかりやすい解説 + 身近なテーマでレッスン】 を学習していますが、これまで学習してきた内容の足りていない知識を補うレベル感の内容だったのでレポジトリは作成していません。

このレポジトリに簡単にメモした内容のみ記載します。

これ以降もレポジトリを作成するほどではないと判断した場合はこのレポジトリに簡潔に記載します。

haseryo0403 commented 4 months ago

手を動かして学ぶITプロジェクトの資料作成！システム開発のドキュメンテーション技術と成果物テンプレート

プロジェクト計画書 いろいろな項目はあるが、 大体は要件定義と同じだが、それにプラス プロジェクトの責任範囲を決めること、成果物をきめること、チームと責任者を決めること、プロジェクトのルールをきめることがある。あと詳細なスケジュールとか

現在の業務課題とソリューション
    課題：納得感のある現場に寄り添った課題
    ソリューション：これをやったらなぜ解決できるのかというWhyの部分
    上記二つが重要

マイルストーン 何がいつ始まっていつ終わるのか明記する ライセンス契約：クラウドサービスをいつ契約するか 仕様確定：それ以降は要件などはかえない リリース判断：リリースしていいか判断してもらう

    要件定義が終わるまでは正確なスケジュールは作れないが
    =>ソフトウェア開発データ白書にどのくらい開発に時間がかかったかの実績が載っているので
    参考にする

タスクと成果物 タスクと成果物を紐づけて一覧をつくる

プロジェクト体制 リーダーやそのチームの役割などを作成する

進捗・課題管理方針 いつ何をどのくらいの頻度で行うか 進捗確認会とか

品質管理方針 レビューなどの方針を決める

業務要件一覧 業務フローの箱一つ一つでだれが何をしているのかを記載

    ライセンス一覧
        必要なもの、契約を記載する

モレがあると数か月止まってしまうことも

テスト計画書 ・テストスコープの定義 ・各テストの開始、終了条件 ・テストスケジュール ・不具合発生時のフロー ・テスト体制（リーダーとか） ・情報連携（週次報告とか）

haseryo0403 commented 4 months ago

はじめてのテーブル設計・データベース設計【わかりやすい解説 + 身近なテーマでレッスン】

論理設計とは どんなデータをどのように持たせるか うまく設計するためには豊富な経験が必要だが、経験を積むのが難しい

コースで学べること 短時間で基本プロセスを体験 身近なテーマで論理設計を学ぶ方法を知れる=>つまり無限に練習できる 丁寧に一から教えてくれる

3層スキーマ 外部スキーマ：ビュー 概念スキーマ：テーブル =>概念スキーマがあるおかげで外部と内部で起きた変更がお互いに影響を及ぼさない =>データの独立性 内部スキーマ：DBMS =>外部と内部はかかわりがない

    論理設計：概念スキーマの設計
    物理設計：内部スキーマの設計

論理設計の4つのステップ エンティティの抽出 どんなテーブル（エンティティ）が必要か エンティティの定義 どんなカラムが必要か 正規化 データの冗長性をなくす ER図 エンティティ間の関係性をわかりやすく図にする

テーブルと二次元表の違い テーブルは共通点を持ったレコードの集まり テーブル名はすべて複数形で表せる

テーブルの構成要素 行と列 キー

正規形 第一～第五正規形があるが、業務では第三まで使用 第一正規形 一つのフィールドに一つの値まで 全ての列が関数従属性を満たすように整理する 関数従属性：xが決まれはyが決まる{x}=>{y}

    第二正規形
        部分関数従属をなくして完全関数従属のみにする
        部分関数従属：複数の主キーがあってその複数の主キーで値が定まるのではなく一部の主キーだけで値が定まる
        異なるレベルのエンティティをわける作業でもある

    第三正規形
        推移的関数従属を解消する
        推移的関数従属：2段階の従属{会社ID,社員ID}=>{部署ID}=>{部署名}

大事なこと ビジネスルールをテーブルで表現する

ER図 リレーション 1対多 正規化がちゃんと行われていればほとんどのリレーションはこれになる 1対1 一つのテーブルとして表現できるので論理設計がきちんと行われていれば基本ありえない IE表記法 〇：0 一：一 鳥の足みたいな：多

実際にやってみよう

    論理設計の流れ
        ①UIを確認
        ②これはなにをするためのエンティティなのか？を考えて中心のエンティティを抽出する
        ③5W1Hを考えて周りのエンティティを抽出する
        ④インターフェース中の項目と仕様書中の項目をエンティティにいれていく
        ⑤主キーと外部キーを設定。外部キーを設定するときにその個数が増えてしまいそうな外部キーがないか確認する。あるならテーブルわける

⑥テーブルに落とし込み、正規化できているか確認する

DML　データ操作言語 DDL　データ定義言語 DCL　データ制御言語

DDL CREATE DROP ALTER

迷ったらvarchar