えりつぃんのにっきちょうえりつぃんのにっきちょう読者になるえりつぃんのにっきちょうこの広告は、90日以上更新していないブログに表示しています。2018-08-16システム設計の基礎:外部設計で作るべきドキュメントを考えるシステム設計の基礎を学ぶ研修に会社のお金で行かせてもらったので、成果を書きます。今回のテーマ外部設計で作るべきドキュメントとはなにか?研修の内容を受けて、外部設計段階で作成する一般的なドキュメントをまとめました。それに対し、自分の開発チームがいま作っている資料を一般的なドキュメントの内容と比較・対応させて、外部設計にどんな資料が必要なのか考えました。要件定義のアウトプットとして作成されるドキュメントは以下のようなものがある。データフロー図(DFD)業務フロー図うちだと、要件を文章や図で書いたものと業務フロー図がサービス仕様書に表現されているはず。このサービス仕様書を最初のインプットとして外部設計を作成し、業務設計担当者との認識を合わせていく。要件定義の確認、サービス仕様書を読む。チームで読み合わせとかすると良い。足りていない部分があれば要件定義した人に聞いてみる。非機能要件、性能やSLAは設計に影響するので注意。要件に書ききれていない非機能要件を聞き出せるのが良いエンジニアとのこと。外部設計資料の一覧(一般)世の中にはいろんなドキュメントがある研修で習った各ドキュメントの名称と、表現したいことを簡単にまとめる。詳細(うちのチーム的に)必要な外部設計資料とはここからがサビ自分たちが作っているドキュメントと、研修で習ったドキュメントとを繋ぐ。単純に実装する機能の一覧。資料として明示的に作らない場合でも、チケット管理ツールのエピック等で表現されてるイメージ。ドメインモデルドメイン名は見ればわかる名前、そのものの本質を表す名前をつけるようにしている。そのため、用語の意味はドメイン名によって表現される。通常ドメイン名はなるべくサービス仕様書に記述されている言葉を用いるので、その場合はサービス仕様書内で意味も定義されているはず。システム的な都合で作成されたドメインの場合など、業務に現れないドメインの場合は、外部設計仕様書に別途記載する必要がありそう。データの関連性は、モデル中の多重度、依存関係で表現される。関連するサブシステムとの結合もドメインモデル中に表現している。これらを書くことで、開発領域も可視化できる。要求の機能をより具体的に落とし込んだドキュメントとして同じ位置だと考えた。Outputを表現できる。機能仕様書)ユースケース記述はロバストネス図のインプットになる。処理順序あたりが自然に表現できそう。機能とデータと人、それぞれどう関係しているかを表す分には十分かなと思う。(ずっとコンポ図と呼んでいたけど、ちゃんと調べたらなんか違う気がする...)。研修中はこれが似たような位置だと思ったけど、社内で聞いてみたら設計思想によって使い分けた方が良さそうという話になった。CRUDは外部のサブシステムの機能から呼ばれた場合とかも書ける。このエンティティはこの状態になれ!っていうのが後者の考え方。非機能要件の確認は冒頭に書いた上に、最近はデザインレビューの項目でもあるので、設計の初期段階で明確に検討するべきなのだと感じた。コーディング規約はうちのチームは放棄...わりと察する系(つらい)。このあたりまで外部設計の段階で書くものだとは思ってなかったので意外。いうレベルの話は要求者側に認識してもらっても良いのかもな〜と思った。特定のイベントが起きたときのドメインの状態を書くさいごにこの研修を受けた目的は、標準を知らない自分が、社外で標準的な開発プロセスを学んできた人と話せるようになることでした。「自分の中に標準があることの安心感、自信」を感じられるようになったこと。いう裏付けがある状態になったので、多少自信を持って話せるようになった。いうような気づきを得られるようになり、最近は読書もすごく楽しくなっているのですが、研修もとても良いインプットになりました。忙しくて死ぬかと思ったけど本当に行ってよかった。あと余談ですが最近ユースケース駆動開発実践ガイドを読んでるのでもろ影響されてる(ロバストネス図のくだりとか)。以上、ここまでお読みいただきありがとうございました。この内容に対する見解がありましたらぜひ教えてください。6はてなブログをはじめよう!eri-twinさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。