Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • Open棟梁の適用効果について説明します。
  • 以下の効果によるのQCDF向上を図ることが出来ます。
    • 標準化と共通化
    • 各種支援機能(ツールやライブラリ)の再利用
  • ソフトウェア・ライフサイクル上で3割程度の効率向上が可能と考えています。

定量的効果(削減工数)

少なく見積もっても、

40.0人月のアプリケーション開発工数のうちの12.5%前後の工数削減が可能

と考えます。

これにより、QCD(quality, cost, delivery)が向上します。

以下、内訳についての説明です。

工程別工数比率

設計 : PG : テスト = 3 : 4 : 3

設計工程

実績ある設計情報を再利用できます。

また、

のサポート技術情報を再利用できます。

工程別工数比率

全工程の30%程度

削減工数

40.0人月のアプリケーション開発工数のうち、最小で2.0人月の工数削減が可能
(全体工数と、使用する機能によっては10人月以上の削減も可能)。

プログラミング工程

  • ベースクラス12による標準化/共通化、共通部品群の利用により、1リクエストで動作するコードの内、40%程度を共通化が可能。
    ※40%という数字は共通化などの工数削減施策により、削減された"ステップ数"なので、そのまま削減された"工数"とはなりませんのでご注意下さい。
  • また、D層(Dao)自動生成機能を使用することで、テーブル単位のCRUD部品が生成できる。
    これにより、更新系処理(テーブル単位)のデータアクセスは全て部品化できる(大量データの追加・更新・削除は別途)。

工程別工数比率

全工程の40%程度
※プログラミング工程は、単体テスト工程を含む。

削減工数

  • 最小で10%の工数削減が可能。
  • 大規模案件になればなるほど大きくなるプログラミング工程の工数を削減できる。

テスト工程

デバッグログ、アクセストレースログ、SQLトレースログなどを利用しテスト工程の効率向上が可能。

工程別工数比率

全工程の30%程度

削減工数

  • 最小で10%の工数削減が可能。
  • 大規模案件になればなるほど大きくなるテスト工程の工数を削減できる。

効果の計算

新規開発時

40.0人月のアプリケーション開発工数に対して、5.0人月 (≒12.5%前後)程度の工数削減が可能。

  • 設計工数(全体工数の3割 = 12.0人月)のうちの2.0人月程度の工数を削減可能
    アーキテクチャの決定、プロジェクト・テンプレートの開発、共通部品の開発に関わる工数。
  • 開発・テスト工数(全体の7割 = 28.0人月)の10.0%程度の工数を削減可能
    • プロジェクト・テンプレートに準拠した開発、制御の反転(IoC)による共通化。
    • 共通部品の再利用、データアクセスの自動生成、開発支援ツールによる生産性向上。
    • 10.0%は、開発・テスト工程のステップ生産性で、2.1 KS/人月 → 2.3 KS/人月程度のインパクト
-----------------------------------------------------------
e.g.:40人月の案件を例に取ると、従来と比べ5人月前後の工数削減が可能。
-----------------------------------------------------------
2.0人月 + ( 40.0人月 * ( 0.4 + 0.3 ) * 0.1 ) ≒ 5.0人月 (≒12.5%前後)の工数削減。
# 電卓への入力式:
# [削減工数]人月 = 2.0人月 + ([適用前工数]人月 * ( 0.4 + 0.3 ) * 0.1)
-----------------------------------------------------------

再構築時

既存パッケージやシステムの再構築に利用したケースが何個かアリ、
既存の設計の再利用と、ビジネス・ロジックの流用ができるので、
生産性の実績値は新規開発の2倍以上になることを確認しています。

工程別工数比率 ( 設計 : 開発 : テスト = 3 : 4 : 3 ) から、

  • 設計の再利用のため、設計工数(全体工数の3割 = 12.0人月)。
  • ビジネス・ロジックの流用のため、開発工数(全体工数の4割 = 16.0人月)の一部。
    • 開発工数4割の内訳として、プログラミング : テスト = 3 : 1 程度になる。
    • テスト自体は通常通り実施、プログラミング工数を1/2に削減できたとする。
    • すると、この場合、開発工数は、全体工数の1.5割 = 6.0人月の工数を削減できる。
  • 設計・ビジネス・ロジック流用のため、テスト工数(全体工数の3割 = 12.0人月)の半分(6.0人月)。

を削減した値に近似するため、実績値が、新規開発の2倍以上になると考えています。

-----------------------------------------------------------
e.g.:40人月の案件を例に取ると、従来と比べ5人月前後の工数削減が可能。
-----------------------------------------------------------
(40.0人月*0.3)+(40.0人月*(0.3/2))+((40.0人月*0.3)/2) ≒ 24.0人月 (≒60.0%前後)の工数削減。
# 電卓への入力式:
# [削減工数]人月 = [適用前工数]人月 * ( 0.3 + (0.3/2) + (0.3/2) ))
-----------------------------------------------------------

移行手順

手順としては、

Open棟梁のテンプレートがあるので、

  • それを案件ごとカスタマイズし、
  • そこに既存のビジネス・ロジックを移植していく

というカタチになります。

マイグレーションとの比較

マイグレーションの場合と比べると、再構築はコードの移植・修正と、そのテスト工数が余分にかかりますが、
新規開発時と比べ、2倍以上の生産性が出るので、再構築が必要なケースでは適用する価値があります。

マイグレーション

定義: マイグレーション ≒ ストレート・コンバージョン(.NETバージョンアップ)。

  • マイグレーションの一般的な見積もりは以下の通りですが、
  • コチラに書いたように、Open棟梁を使用して開発したアプリケーションの
    P層以下のB層・D層のポータビリティは高く、簡単に移行することができます。

参考

定性的効果

開発基盤のKPIとKGI」を参考にして下さい。

事例


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-11 (木) 09:48:57 (6d)