設計書の品質を高めるには-2

次に基本設計について

• 入出力の確定(必要とするものは網羅）
• 処理概要
• 処理方式(あくまで概要)
  システム方式、ネットワーク方式、運用方式、システム障害、共通処理
• ハードウェアの全体概要
• 共通アプリケーション処理(概要)

全体構成をまず考えて、概要全般をかき、あとから詳細化。
整合性から、全体像から部分を構成

さらに性能などの諸要件は、総合テスト仕様書全般の概要を記載しておく。
要は設計書に具体的な処理内容に触れるものや例文は総合テスト仕様書に記載し、品質管理面の強化を図ることが重要です。

設計書はあくまで対顧客、そして総合テスト仕様書の結果が全てです。
これを忘れると、単なる言葉遊びではないですが、顧客側の思いとシステムを作る側の思いが整合していない場合が多いです。
顧客によっては、例文のほうが理解しやすいし、システムを作る側の品質も向上します。

設計書の品質を高めるには-1

設計書をかくことが下手な人が多い。ベンダーなどによってさまざまな書式があるが、なぜ必要とする設計書なのかを理解していない人が多い。
各工程は連続にあり、それぞれが独立しているのではない。

また要件定義などで未確定事項が多い、また新技術で、どのように設計書をかくか悩むことも多いだろう。
基本を忘れないでほしいことがある。

要件定義で必要なのは、何をするのか、どのように行うのかを明確にする。
単なる要望書でもなく、希望的憶測でもないのは確かであるが、多くのものは憶測や、希望的見解を述べて、技術的根拠がないものも見受けられる。
技術的検証などの工程があれば問題はないが、これがない場合はどうするのか。

ベンダーによっては、
1)予算などが豊富なベンダはパイロットチームが、先に技術的検証をしながら、工程単位に確認を行う。
2)予算のなし、や製造で何とかしようとするベンダーは確認をせずに設計書を固める
圧倒的に多いのは、2)のほうで、1)を行うベンダが少ないのが実情
品質が悪くなったり、手戻りが多く、工数が激増するのはこのことも一つの要因。

基本的には小さくともパイロットを作成し、確認を行うことが重要である。

Spring - 01

DIについて、
基本的な事項は省略

DIの目的について
①POJOの利用
②DIコンテナからnew演算子を消す
　⇒FactoryMethodなどのデザインパターンの排除
③DIコンテナから渡されるインスタンスをインタフェースで受け取る
　⇒インタフェースのコンポーネント化
　⇒クラス(インタフェースの実装)が変更・拡張されても、それを利用しているクラスのへの影響範囲を極小化できる。
　⇒利用しているクラス(インタフェースの実装)を置き換えてもテストが可能。

DIの利用範囲
①コントローラとサービスとの依存関係
②サービスとDAOとの依存関係

アノテーションとDI
①インスタンス変数の前に@Autowiredをつけると、DIコンテナがそのインスタンス変数の型に代入できるクラスを@Componentがついているクラスの中から見つける
　⇒インジェクションをする
　⇒インスタンス変数以外にメソッド宣言前でも可能
②DI方法はXML定義
　⇒Bean定義ファイルが必要
　
　　@Autowired、@Resourceを利用する場合の宣言

　　@Conpmnent、@Serviceなどのコンポーネントを利用する場合の宣言
③インジェクション可能なクラスは1個
　⇒複数名がある場合、@Qualifierを使用する(@Componentに名前を使用する)
　⇒Bean定義ファイルを利用する

プロジェクト管理など

プロジェクト計画とは
簡単の述べれば、
①何を作成するのかを明確にする
②いつまでに作成するのかを明確にする
③作成する人たちの手配を明確にする
④作成すべきものの内容を明確にする
⑤どこで行うのかを明かうにする
上記が必要なことです。

簡単そうに思えるがいざ大規模システムになると、課題管理や変更管理、問題管理、そして全体に情報の共有化が難しい。

コミニュケーションは難しいし、作成するないものもバラバラになる。
それぞれ思い込みが激しい。

そこで計画を作成する際に、完成物に対する内容・・・つまりは品質を統一するためにレビューなどが行われる。
またスケジュールについてどれだけ進捗しているかなどを図る必要性がある。
これが進捗管理
品質管理や進捗管理などが運営管理ということになる。
方向などぶれないようにコントロールが必要となる。

管理、運営とは、簡単ではなく、理解をしている人が少ない。
PMPの試験はあくまで管理の試験、しかも一般的であるのでIT業界など、業界に置き換えることが必要なり、また運営も簡単ではない。

当社ではこのような問題を解決する施策をもっております。

システム開発：プロジェクト体系

プロジェクト体系について

(1)計画
計画とは，プロジェクト目標に従ってプロジェクト全体を見通した
「対象範囲」，
「スケジュール」，
「コスト」，
「組織と要員」
を明らかにするプロセスのことである。

「プロジェクト目標の明確化」，「開発環境の最適化」，「開発方法論と工程の決定」，「見積り」，「リスクの識別と対応策の策定」，「WBS（Work Breakdown Structure）とスケジューリングの策定」，「組織計画と要員計画」，「品質管理計画」，「文書化計画」，「教育計画」，「システムの大まかな稼働計画」などを決める。
これらの計画は，「プロジェクト計画書」と呼ぶドキュメントにまとめられる。

(2)トラッキングとコントロール
トラッキングとは，プロジェクトの状況と実績を，的確かつ継続的に把握することを指す。一方，コントロールとは，プロジェクトが計画から逸脱したときに適切な対策を講じることを意味する。
プロジェクトにおけるトラッキングの対象としては「品質」，「進ちょく」，「コスト」，「リスク」の4つがある。これらの状況と実績は，「プロジェクト報告」（週次報告，月次報告など）で共有する。

トラッキングとコントロールの基本的な方法は，「プロジェクト管理」の時代とあまり変わっていない。ただし，トラッキングとコントロールを効果的に実現するため，グループウエアを始めとするPMS（プロジェクトマネジメント・システム）を活用するのが最近の傾向だ。また，進ちょく管理の手法として，EV（Earned Value：出来高）で進ちょくを測るEVM（Earned Value Management）が脚光を浴びているのも，最近の特徴だ。

(3)リスク管理
リスクとは，プロジェクトにおける品質・納期・コストの目標達成を阻害する「潜在的な問題」のことである。プロジェクトの「リスク管理」とは，リスクを前もって予測し，現状のリスクを評価して危険度を定量化し，その回避策を作成・実行するプロセスを指す。

(4)契約管理
情報システム開発にかかわる契約の準備・締結から契約の履行までを管理するプロセスが「契約管理」である。顧客を対象にした契約管理だけではなく，協力企業との契約管理も行う。

「プロジェクトの計画」，「トラッキングとコントロール」，「リスク管理」，「契約管理」の各プロセスの結果は，すべて「プロジェクト計画書」にまとめられる。