「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>Open棟梁とは]] *目次 [#n0ac398a] #contents *概要 [#ja5c4920] Open棟梁の適用効果について説明します。 **QCDF向上 [#jb30674b] 以下の効果によるのQCDF向上を図ることが出来ます。 -標準化と共通化 -再利用 --設計情報 --ライブラリ --開発支援ツール **生産性向上 [#j88939c0] ***生産性向上の効果 [#gc4dda38] 生産性向上の効果としては、 -[[新規開発時>#d987aaf9]]は、1割程度の効率向上が可能と考えています。 -保守・運用から、[[マイグレーション>#f5261284]]、[[再構築>#a82d038c]]なども含め、~ ソフトウェア・ライフサイクル全体で、3割程度の効率向上が可能と考えています。 ***データから見る生産性向上の実績 [#t8199e06] -[[新規開発時の生産性向上>#d987aaf9]]~ 1割程度の効率向上が可能(これは、2.1 KS/人月 -> 2.3 KS/人月程度のインパクト) --[[パーキンソンの法則>https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%BD%E3%83%B3%E3%81%AE%E6%B3%95%E5%89%87]]~ 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。」~ により、工数が、品質向上工数に回されたりすることがあるので、~ MAXの生産性データが測定できないという問題もあります。 --実績データを分析してみると、以下に起因する、~ 生産性低下の影響が大きく、下振れのバラツキは大きいです。 ---要件が纏まらない ---不良の多数 ---デグレも多発 -[[マイグレーション時>#f5261284]] --新規開発のn倍以上の生産性を観測している。 --ただし、スコープ(特にテスト)に依存する。 -[[再構築時>#a82d038c]] --新規開発の約2倍以上の生産性を観測している。 --以下が工数削減根拠として大きい。 ---設計・チェックリストの再利用 ---ビジネス・ロジックの流用 *定量的効果(削減工数) [#y72d8e92] 少なく見積もっても、 >40.0人月のアプリケーション開発工数のうちの12.5%前後の工数削減が可能 と考えます。 これにより、QCD(quality, cost, delivery)が向上します。 以下、内訳についての説明です。 **前提の工程別工数比率 [#ye1bdaa0] ソフトウェア開発の工程範囲での工程別工数比率は、 >設計 : PG : テスト = 3 : 4 : 3 前後になる。というのが一般的。 **設計工程 [#b0a60113] ***工数削減根拠 [#r215cd15] 実績ある設計情報を再利用できます。 -「[[プロジェクト・テンプレート]]」に蓄積された、~ アーキテクチャごとのデザイン・パターン -提供される各種ドキュメント、 --[[利用ガイド>https://github.com/OpenTouryoProject/OpenTouryoDocuments/tree/master/documents/1_User_Guide]] --[[チュートリアル]] --[[設計のポイント]] また、 -当サイト -「[[マイクロソフト系技術情報 Wiki>https://techinfoofmicrosofttech.osscons.jp/]]」 のサポート技術情報を再利用できます。 ***工程別工数比率 [#k886574f] 全工程の30%程度 ***削減工数の例 [#k842f698] 40.0人月のアプリケーション開発工数のうち、最小で2.0人月の工数削減が可能~ (全体工数と、使用する機能によっては10人月以上の削減も可能)。 **プログラミング工程 [#yd651547] ***工数削減根拠 [#x5533ccc] -1リクエストで動作するコードの内、40%程度を共通化が可能。 --[[共通部品群>機能一覧#p47bdfe6]]の再利用~ --[[ベースクラス1]]・[[2>ベースクラス2]]の[[制御の反転(IoC)>https://techinfoofmicrosofttech.osscons.jp/index.php?IoC]]による標準化/共通化 >※ 40%という数字は共通化などの工数削減施策により、削減された~ "ステップ数"なので、そのまま削減された"工数"とはなりませんのでご注意下さい。 -自動生成機能 --また、[[D層(Dao)自動生成機能>D層自動生成ツール]]を使用することで、テーブル単位のCRUD部品が生成できる。~ これにより、更新系処理(テーブル単位)のデータアクセスは全て部品化できる(大量データの追加・更新・削除は別途)。 --これに加えて、[[テーブル・メンテナンス、データ・メンテナンス画面の自動生成機能>P層自動生成ツール]]を使用することで、更なるQ/C/Dの向上が期待できる。 ***工程別工数比率 [#e0010de1] 全工程の40%程度~ ※プログラミング工程は、単体テスト工程を含む。 ***削減工数の例 [#t5491f71] -最小で10%の工数削減が可能。 -大規模案件になればなるほど大きくなるプログラミング工程の工数を削減できる。 **テスト工程 [#c928f512] ***工数削減根拠 [#w565095b] -以下を利用しテスト工程の効率向上が可能。 --デバッグログ --アクセストレースログ --SQLトレースログ -共通化により、 --プログラムの修正が容易。 --ビジネス・ロジックの実装に専念できる。 ***工程別工数比率 [#te6e1e79] 全工程の30%程度 ***削減工数の例 [#b72aaf57] -最小で10%の工数削減が可能。 -大規模案件になればなるほど大きくなるテスト工程の工数を削減できる。 *生産性向上効果の計算 [#vd53a0a3] **新規開発時 [#d987aaf9] 40.0人月のアプリケーション開発工数に対して、5.0人月 (≒12.5%前後)程度の工数削減が可能。 -設計工数(全体工数の3割 = 12.0人月)のうちの~ アーキテクチャ設計工数である2.0人月程度の工数を削減可能~ アーキテクチャの決定、プロジェクト・テンプレートの開発、共通部品の開発に関わる工数。 -開発・テスト工数(全体の7割 = 28.0人月)の10.0%程度の工数を削減可能 --プロジェクト・テンプレートに準拠した開発、[[制御の反転(IoC)>https://techinfoofmicrosofttech.osscons.jp/index.php?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%前後)の工数削減。 # 電卓への入力式:[削減工数]人月 = [削減アーキテクチャ設計工数]人月 + ([適用前工数]人月 * ( 0.4 + 0.3 ) * 0.1) ----------------------------------------------------------- ※ 適用前工数とは、Open棟梁を適用しなかった場合のアプリケーション開発工数。 **マイグレーション時 [#f5261284] -定義: マイグレーション ≒ ストレート・コンバージョン(.NETバージョンアップ)。 --マイグレーションの一般的な見積もりは以下の通りですが、 ---[[移行・マイグレーション - マイクロソフト系技術情報 Wiki > 移行見積もりの概要>https://techinfoofmicrosofttech.osscons.jp/index.php?%E7%A7%BB%E8%A1%8C%E3%83%BB%E3%83%9E%E3%82%A4%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3#ze0be0ea]] --コチラに書いたように、Open棟梁を使用して開発したアプリケーションの~ P層以下のB層・D層のポータビリティは高く、簡単に移行することができます。 ---.NET Core2.0移行の移行性に関する報告 - OSSコンソーシアム~ https://www.osscons.jp/jofbwaon0-537/ -マイグレーション ≒ ストレート・コンバージョンの生産性 --スコープ(特にテスト部分)に依存することが多い。 --疎通確認までの範囲なら、.NETの高い下位互換性のため、~ 殆ど工数がかからないケースも多く、その場合、新規開発のn倍以上になる。 **再構築時 [#a82d038c] -既存パッケージやシステムの再構築に利用したケースが何個かアリ、~ 既存の設計・チェックリストの再利用と、ビジネス・ロジックの流用ができるので、~ 生産性の実績値は新規開発の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人月の案件を例に取ると、新規開発と比べ24.0人月前後の工数削減が可能。 ----------------------------------------------------------- (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) )) ----------------------------------------------------------- ***移行手順 [#qd378235] 手順としては、 Open棟梁のテンプレートがあるので、 -それを案件ごとカスタマイズし、 -そこに既存のビジネス・ロジックを移植していく というカタチになります。 ***[[マイグレーション時>#f5261284]]との比較 [#mfe60d73] [[マイグレーション時>#f5261284]]の場合と比べると、再構築はコードの移植・修正と、そのテスト工数が余分にかかりますが、~ 新規開発時と比べ、2倍以上の生産性が出るので、再構築が必要なケースでは適用する価値があります。 *参考 [#m1d40a98] **定性的効果 [#lb3141dc] ***[[開発基盤のKPIとKGI]] [#l19ed70f] ***業務系ソフトウェア開発の生産性についての話 [#w606d44d] -業務系ソフトウェア開発の生産性についての話 - OSSコンソーシアム~ https://www.osscons.jp/joba6c0jr-537/ **事例 [#od918e12] ***大林組 営業情報システム再構築 [#s335d184] -大林組の営業情報システムを再構築し、情報共有と業務効率向上を実現~ 国内外の土木・建築の工事計画情報と関連情報を集約し、~ 営業体制の強化と受注拡大を支援|株式会社日立ソリューションズ~ http://www.hitachi-solutions.co.jp/company/press/news/2017/0330_2.html ***[[Open棟梁の開発利用者の感想>営業コンテンツ#ae21fb44]] [#nfcf66c2]