事業紹介

開発プロセス

高品質・高生産性を実現するネットワーク21オブジェクト指向開発の概要。
 
  ネットワーク21オブジェクト指向開発 その他開発プロジェクト
開発プロセス ユースケース駆動による、要求仕様に明確に基づいたシステム化を実施。
要求から分析→設計→実装→テスト→運用の各フェーズへのブレイクダウンの起点はユースケースとなる。 		一般的には、要件定義→基本設計→詳細設計→テスト→運用といったウォータフォール型でシステム化を実施。
 
要求フェーズ ユースケース分析、ドメイン分析を実施し、
要求の明確化を実施。
 クライアントの要求リストをもとに画面イメージを作成。要求の具体化（視覚化）に注力。

■リスク要因
クライアントの要望があいまいなため整合性のない要求を吸収してしまう。
 
分析フェーズ ユースケース、ドメインモデルをもとに100%要求に準じたシステム化分析を実施。

そのシステム化に準じた画面設計、ER設計を行っていく。

新たな仕様が判明した場合は要求フェーズに反映するためユースケース、ドメインモデルの見直しも実施する。要求フェーズと分析フェーズをイテレーティブに進める。
 過去の実績などから応用できそうな情報をもとにER設計、画面設計等を実施。

■リスク要因
設計的なフィット＆ギャップに陥りやすいため、過去の実績に依り過ぎることで本来の仕様を吸収できないシステム化となってしまう。
 
設計フェーズ 分析フェーズの論理設計情報をもとに、採用する技術に対する物理化を実施。

オブジェクトモデル→RDB等のようにインスピレーションミスマッチに対する指針、量産化を意識したリファレンスコードの作成、各種ツールの開発･採用を実施。
 画面設計、ER設計の物理化を実施。
マンパワーを前提とした工数スケジューリングを実施。

■リスク要因
既にスケジュールの遅れが発生していて必要なマンパワーを用意する予算確保できなくなっている。
非現実的な実装スケジュールが組まれる。
 
実装フェーズ 単純なコーディング作業は極力削減されているため、機能仕様を実現するコアな処理の開発に注力できる。

明確に記述された機能仕様書からテストケースを作成→実装することで、確実に機能を実現するプログラムが作成される。バグの原因となるような不要なプログラミングが組み込まれない。

JUnit等テストツールによるテストの自動化を進める。		 基本的には、リファレンスコードを真似（コピー）しながら実装していく。

■リスク要因
単純作業、高度なアルゴリズムに対する実装が混在していて、効率的なマンパワーの配分ができない。
期待通りの実装パフォーマンスが出せない。

既プログラムの流用が難しい場合でも、無理やり利用してしまう。結果、機能が満たされない（動かない）プログラムが実装される。
 
設計フェーズ 分析フェーズの論理設計情報をもとに、採用する技術に対する物理化を実施。

オブジェクトモデル→RDB等のようにインスピレーションミスマッチに対する指針、量産化を意識したリファレンスコードの作成、各種ツールの開発･採用を実施。
 画面設計、ER設計の物理化を実施。
マンパワーを前提とした工数スケジューリングを実施。

■リスク要因
既にスケジュールの遅れが発生していて必要なマンパワーを用意する予算確保できなくなっている。
非現実的な実装スケジュールが組まれる。
 
テストフェーズ 単体テストで保証されたモジュールを連結してユースケースの実装を確認する。マンパワーに依らないテストの自動化も実施。

障害が発生した場合、その機能を表現するユースケースから分析を進め、どのフェーズでミスマッチが発生しているか把握することで、問題を局所化した対応が可能。 		できているところから随時連結しながらテストを実施。

■リスク要因
実装完了の歩調が合わず正確な連結テストが実施できない。

機能が分散してしまっていて障害が発生した場合、その原因の究明が困難になってしまっている。

プログラムが流量（コピー）されてしまっているため、一つの障害が随所で発生する。
 
運用フェーズ 運用時に機能追加・変更があった場合、ユースケースのフィット＆ギャップを実施。

論理設計から物理設計までのシステム化がトレース性が高いため、必要工数の見極めを迅速に対応できる。当然、実装もスピーディに対応。 		できているところから随時連結とにかくカットオーバー。
詳細以降のドキュメント残作業を実施。テストを実施。

■リスク要因
障害に対して場当たり的に対応。

この時点で要求フェーズの内容とはまったく異なった機能が実装されている。論理設計と物理設計がマッチしなくなっている。

ドキュメント整備が途中となり、月日がたつにつれ立ち上げメンバーが抜けていくなどシステムのブラックボックス化が進む。

結果、要求変更・追加が不可能なシステムとなる。
 
テストフェーズ 単体テストで保証されたモジュールを連結してユースケースの実装を確認する。マンパワーに依らないテストの自動化も実施。

障害が発生した場合、その機能を表現するユースケースから分析を進め、どのフェーズでミスマッチが発生しているか把握することで、問題を局所化した対応が可能。 		できているところから随時連結しながらテストを実施。

■リスク要因
実装完了の歩調が合わず正確な連結テストが実施できない。

機能が分散してしまっていて障害が発生した場合、その原因の究明が困難になってしまっている。

プログラムが流量（コピー）されてしまっているため、一つの障害が随所で発生する。
   
さらに、ここまでのフェーズを短期間で実施。
プロトタイプの開発→インクリメンタルなシステム拡張開発するスパイラルで進めます。

実績はこちら 		 
ぺージトップへ