40 ファンクションポイントの年: 過去, 現在, 未来

ルイ・ブイヨンにより、

ただ 40 年前の10月で 1979, 博士. アラン・アルブレヒトは、初めてのソフトウェア・システムの機能をサイジングするための手法を提案しています. 彼の技術が採用されました, 国際標準になりました, そして、いくつかの他の技術にインスピレーションを与え、より. 本論文では、過去を示し, 現在と (可能) ファンクションポイント分析の将来の拠出.

過去: オリジンズ, 動機や理由

1970年代, コードの行 (LOC) 不適切なソフトウェアシステムサイジングのために使用されました (そして、まだ、このような軍事やリアルタイムおよび自動車システムなど、いくつかの機能ドメインに今日あります, ちょうど数名に) それはケーパージョーンズは、「生産性のパラドックス」というラベルの付いたものに導きました [1]: より多くのLOCを書くこと...プログラミングスタイル必ずしもより生産的であることを意味するものではありません, 特定のプログラミング言語の表現力, LOCをカウントするためのルール (物理的または論理的, /コメント行なし...) プロジェクト内の巨大な変動を作成 (はい, プロジェクト!) 推定. そのため、その時点で, 我々は唯一のメインフレームを持っていました, PCやミニコンピュータではありません. こうして, インクルード (ソフトウェア) 展開するための製品の努力はプロジェクト全体の努力とソフトウェアの機能のほとんどは、ソフトウェアプロジェクトの主な成果として意図されていたました. 結果として, 長年 (そして、まだ多くの契約で), ファンクションポイント (FP) ました (そして、されています) 彼らは唯一の製品機能規模を表現しながら、誤って「プロジェクトのサイズ」として意図. とにかく, アルブレヒトの目標は「生産性のパラドックス」を克服し、ビジネスの観点から、生産性の計算を正規化する方法を見つけることでした [2]. 素晴らしいアイデアは、技術に依存しない何かに彼の技術をベースにしました: プロセスとデータ. こうして, FP計算 (および関連製品の機能規模) 利用者機能要件のセットの分析から得られ (毛皮) 採用技術と組織的なスタイルにもかかわらず同じです, 努力中, 期間やコスト/価格されています, もちろん, このような要素に応じて可変. 長年にわたって提案されている典型的な例は、フラットの「大きさ」を測定するための平方メートルとしてFPを見てました: 平方メートルの数は、2つの異なる場所に2つのフラットについて同じとすることができます, しかし、それらを構築するための時間が異なる場合があります (例えば. フラットはレンガで構築することができますかプレハブこと), 並びにそれらの生産コストと商業的価値 (マンハッタンのフラット, ニューヨーク, 別の場所で別のものよりも平方メートルあたりより多くの費用がかかるもの); コストは、値ではありません.

最初の論文, 付け 1979, そのような目標のための基盤を提起, そのタイトルに記載されているように (「測定アプリケーション開発の生産性」). これは、推定のためのビッグバンを表現しました, 後に、このような新しい番号は、プログラミングの前に導出されている可能性があるため、特に機能解析からの入力/出力/クエリとデータを抜粋しようとしていません, LOC数で行ったように. あなたは精度のあるレベルでのLOCの数を予測することはできませんので、あなたのチームは...明日あまり変動が生成されます!

多くの利点だけでなく、いくつかの未解決の問題があります。: プロジェクトの取り組みとの相関関係 (男性/日) 製品の機能サイズ (FPで) それほど高くありませんでした, そして、価値調整係数 (VAF) 線形回帰分析でこのような関係とR2の値を改善するために導入されました. VAFは、最初に計算しました。 10 一般的なシステム特性 (GSCs) 最初に±25%の変動と 1979 紙, へ拡大 14 第二および最終紙でGSCs, 付け 1983 [3], 初期の「未調整」FP値の±35%の変動で. VAFました, 故に, 間接的「サイズ」非機能要件の寄与への最初の道 (NFRs), 製品にだけでなく、プロジェクトレベルの両方. アラン・アルブレヒトからこの第二および最終紙は、最終的なFPAの構造を述べました, ILFとEIFへの最初のマスタデータの関数型を分割します, 最終的な重み付けシステムを記載 (現在IFPUG CPMのv4.3.1のバージョンのように、まだ有効, 付け 2010 [4]) その時から. こうして, それは、機能サイジング視点を-from比較することが可能です- ベンチマークの目的のために数年前にリリースされ、別の1で、今日実現するソフトウェア製品.

に 1987, IFPUGが生まれ、その手の中にアルブレヒトの技術の管理と進化を開催しました. 次の年に, いくつかの技術は、離れアルブレヒトのアイデアから移動しました, そしてわずか数は、ISO規格となりました, 図2に示すように. 1:

イチジク. 1: ISO規格FSM (点線の青い線で)

イチジク. 1: ISO規格FSM (点線の青い線で)

彼らです (外観のために): マークII (1988), NESMA FPA (1990), FISMA (199バツ) そして、COSMIC (1998), マイナーなバリエーションの多いです (ここに [5] それらのいくつかのリスト).

FPAの最初の用法は推定とベンチマークの目的のためのソフトウェア製品の機能規模を決定し、簡素化-toました- ICT契約でのお支払いのための契約単位として.

に 1998, ISOは、いわゆる機能性サイジング測定のための共通の原則を「14143」ラベルの下の規格のファミリの作成を開始しました (FSM) 方法, このような方法は、製品のサイズにすることを明確な方法で知らせます (ないプロジェクト) および製品毛皮から移動した場合にのみ, 最初にそのようなVAFのような調整係数が含まれ、関連するISOバージョンを除外しました [6]. 根拠? このような「調整/キャリブレーション」の要因はNFRsから来ました, こうして, FSM法の範囲外です. 証拠として: ISO 20926:2003 IFPUGのCPM v4.1のためのISO標準だった「未調整。」バージョン4.xの-from 1999 に- 洗練されたバージョン定義と基本的な概念, 具体的には、「ユーザー」および「境界。」バージョンV4.3 (2010) 決定的規範的なテキストからVAFを落としました (また、ISO / IECで 20926:2009) 付録Cでの歴史的な目的のためにそれを維持.

その間, 毛皮とNFRsは並列方法で処理する必要があるため, ソフトウェアの非機能評価プロセス (スナップ) プロジェクトが始まっ中 2007, v1.0のを解放するには 2011 [7], 新しいのための, 最初の非機能サイズ測定 (NFSM) 方法, これは製品のソフトウェア品質にISO規格から移動 (9126 前 [8], そして現在へと進化 25010:2011 標準 [9]) できるだけ多くの機能のサイジングを補完しようとしているとき. イチジク. 2 右プロジェクトのスコープを決定するのに役立ちます, 要件の3種類の:

イチジク. 2: 要件の三種類 (「ABC」のスキーマから)

イチジク. 2: 要件の三種類 (「ABC」のスキーマから)

情報は、CPM v4.1のとは異なる方法で書かれていました. 私は明確にして述べました 2012 私が書いた紙 MetricViews [10], 「ABC」のスキーマ; そのような分類はまたに使用されました 2015 紙より良いNFRsのための分類法を表現するためIFPUG / COSMICによる共著 [11]. この分類は適切に分析し、優れたベンチマーク分析とそれらを比較するための任意のプロジェクトの当初から重要です. イチジク. 3 ユーザーの要求が展開して分割する方法をまとめたもの, より広い場合, 3つのチャンクに: 製品毛皮 (A), 製品NFRs (B) そして、プロジェクトの制約/要件 (C).

イチジク. 3: ABCスキーマ [10]

イチジク. 3: ABCスキーマ [10]

ユーザーの要件から、最終的なプロジェクト全体の努力とコストへ – 「ABC」のスキーマ [10] に 1997 ISBSG (isbsg.org) 生まれ、最も有効なソフトウェア測定協会のすべてのました (SMA) このベンチマーク構想に付着. ザ・ 2019 解除 [12] 以上のものを含んでいます 9,000 プロジェクト, ほとんどIFPUGとCOSMIC FPAメソッドを使用してサイズの. 別の補完的な規範は、ISO / IECました 14143-5:2004 [13], 「機能的ドメイン」を定義するための基準を提案し、要件タイプによって同様の特性と労力分布を有するソフトウェアシステムの間で合理的な比較を可能にします (ABC). それはオレンジとリンゴを比較しても意味がありません...

 

現在: どうしたの?

FSMの方法は、びまん情報で使用されています & 通信技術 (ICT) 契約, いくつかの国では高濃度の (例えば. イタリア, ブラジル, ポーランド, インド), そして製品機能規模をサイジングするための定量的基礎を表すとすることができたかを決定するためにベンチマーク分析に役立てることができます (約) プロジェクト内の非機能的な努力, 図4に示すように、:

イチジク. 4: 要件タイプによってエフォート配信 (ABC) 機能ドメインあたり: 例

イチジク. 4: 要件タイプによってエフォート配信 (ABC) 機能ドメインあたり: 例

要件タイプによって努力分布の例 (ABC) 機能ドメインごとにABCスキーマに従って非機能が何であるかを分割しています. B型要件を実現し、IT専門家によって展開することができます (例えば. データベース管理者, ユーザビリティの専門家...) その一般的に他のプロより少ないコスト (例えば. プロジェクト/サービスマネージャ, 測定の専門家, 品質保証人...) C型の要件を実行しているが、プロより (例えば. アナリスト/プログラマ) A型の要件を実行しています. イチジク. 5 プロの種類ごとに要件タイプと男/日あたりのコストによるプロジェクトの努力の代表的な分布のための2つの反対のピラミッドを示し [14].

イチジク. 5: 要件タイプとコスト/人・日の努力分布 (ABCスキーマに従って)

要件タイプとコスト/人・日の努力分布 (ABCスキーマに従って). 再び, レッスンはから学びました 40 長年の経験をよりよく定義するために役立ちました (そして絞り込みます) アプリケーションのFPAの範囲についての原則とルール. 「123」のスキーマは、別の分類です [15] これを知らせるための要件の種類は、プロジェクトの特定の段階で存在することができます (1: デベロッパー, 2: オプス, 3: SVC, メンテナンス).

イチジク. 6: 「ABC」のスキーマと共同で「123」スキーマ

こうして, OPS段階でソフトウェアが使用されています, 生成/変更されません, そして「ゼロFP」のカウントを生成し、, だけでなく、変更要求はB型の要件が含まれる時 (例えば. 是正/完全化保守のための, ISO / IECで述べたように 14764:2006 標準 [16], また、CPMのv4.3.1で引用 – 部 3, 章 4, ページ 20-21). たとえFURまたはNFRが作成されたかについての定義と判断基準, 時間をかけて説明して拡散, 測定の少なくとも1つのユニットを使用するには、契約上の慣行やビジネスにおける文化的債務は依然として存在しています (UOM) A型の要件をサイジングするための (FP, どんな種類) 共同UOMとB型の要件をサイジングするための (例えば. ISO / IECからIFPUG SNAPポイントや対策と 25023 [17], プロジェクトのスコープのために必要な全体の努力を推定するためのスコープを完了だけでなく、C型活動. 3のためのすべての要件をサイジングする場合にのみ、 (ABC) タイプ, それは、「スコープクリープを低減することが可能です,」それはない何FPの大きさと内容に関する歴史的誤解が依然として存在する一方、. しかし、FSMの方法で知るのに十分だろう, その基本機能コンポーネントれています (BFCs) 含むため (か否か) こうした活動や活動.

少なくとも最後のではなく, FPと自動化. 博士. アルブレヒトは、ライフサイクルの初期段階での評価を可能にするための「設計対策」を作成しました. いくつかのツール今日, 後に 40 年, FPを導き出すだろう (どんな種類) ソフトウェアコードを解析またはFUR表記のある形に取り組んで. 一部 (常識的な) 観察と思考: それは4つの基準の尊重だ場合は自動化が便利です: もっと早く, より正確な, よりタイムリーかつ低コストで. 我々は大き新しいFURに必要がある場合, ツールの解析コード (新しいISOに述べたように 19515 自動化されたFPの標準 [18]) 役に立たないとコストがかかります. 若しくは, 入力として、いくつかのUMLの表記法を想定したツールを使用すると、より多くの工数を暗示します (および関連費用) メタ言語形式に人間ベースの書かれた要件を変換します. さらに, 組織は、慎重な選択のための投資に対するリターンを分析する必要があります(S) 4つの上記の基準に従って. 迅速な時間と労力が重要な資産である、ドラフト基準を作成することは、それがスコープの下で、人間CFPSによっておよびUOMていることが確認された前提条件の下でOKかもしれないと同じです. さもないと, 自動化は管理するのは危険や困難になる可能性.

 

未来: 私たちは何を期待することができます?

多くの人が言う通り, 未来は今ある...しかし、我々は近い将来にFPAから何を期待することができます? FPAは、強力な基盤を持っており、それが独立した技術であり、; 私たちは過去から学んだことは、次の手順があるべきであるということです:

  • より良く、より手頃な価格のユーザ要件 (UR) 管理, プロジェクトの初期段階でスコープと測定: これは、達成すべきメインと第一の目標であります.
  • 新技術へのFPAの採用, FPAの基本的なルールの適切な解釈から貫通 1979/84. 我々はまだ、このようなクラウドコンピューティングなどFPA新技術により測定し、サイズをすることはできません [19], モノのインターネット (IoT) [20], 人工知能や、新しい技術の今後数年は、私たちをもたらします.

私たちの最善の策は何か新しいものを発明することではありません, しかし深くソフトウェアシステムを設計するための新しい、さまざまな方法を決定するために私たちの現在のプロセスやデータを分析し、まだFPAとFURをサイズに!

私たちは、機能を使用して改善していきたいです 測定.” (アラン・アルブレヒト, 10月 1979)

 

リファレンス

  1. ジョーンズ, C., ファンクションポイントは何ですか? SPRのウェブサイト, URL: http://tiny.cc/tgur7y
  2. アルブレヒトA. J., “アプリケーション開発の生産性を測定します” PROCで. 共同SHARE, ガイド, そして、IBMアプリケーション開発 , 1979, PP. 83-92. http://tiny.cc/2ywacz
  3. アルブレヒトA. J. & ガフニーJ. E., “ソフトウェアの機能, コードのソース線, および開発努力予測: ソフトウェア科学の検証,” IEEEトランス. ソフトウェア工学。, 巻. 9, いいえ. 6, 十一月 1983, PP. 639-647. http://tiny.cc/1zwacz
  4. IFPUG, ファンクションポイントカウンティング実践マニュアル (CPM), 解除 4.3.1, 1月 2010, URL: ifpug.org
  5. Lother M., Dumke R., ポイント・メトリック: 比較と分析」, に: ソフトウェアの測定における現在の動向, シェーカー公開, 2001, pp.228-267
  6. ISO / IEC, 国際標準 14143-1 – 情報技術 – ソフトウェアの測定 – 機能規模測定 – 部 1: 概念の定義, 2月 2007
  7. IFPUG, ソフトウェアの非機能評価プロセス (スナップ) アセスメントの実践マニュアル (APM), バージョン 1.0, 九月 2011, URL: ifpug.org
  8. ISO / IEC, IS 9126-1:2001 – ソフトウェア工学 – 製品の品質 – 部 1: 品質モデル, 国際標準化機構, 2001
  9. ISO / IEC, IS 25010:2011 -システムおよびソフトウェアエンジニアリング・システムおよびソフトウェアの品質要件と評価 (平方)-システムとソフトウェア品質モデル, 国際標準化機構, 行進 2011
  10. ブイヨンL., 次のフロンティア: 非機能的な生産性の測定と評価, MetricViews, 八月 2012, URL:https://www.ifpug.org/Metric%20Views/MVBuglione.pdf
  11. COSMIC / IFPUG, ソフトウェアプロジェクトのパフォーマンスの測定に使用される非機能要件とプロジェクトの要件のための用語集, ベンチマークと推定, v1.0を, 九月 2015
  12. ISBSG, D&E (開発 & エンハンスメント) 倉庫, R2019, URL:isbsg.org
  13. ISO / IEC, テクニカルレポート 14143-5 – 情報技術 – ソフトウェアの測定 – 機能規模測定 – 部 5: 機能サイズ測定で使用するための機能的ドメインの決意, 2004 (R2019)
  14. ブイヨンL., 均一かつ測定可能なプロジェクトを処理する方法: 種類と要件に焦点を当て, ZeroUnoWeb, かもしれません 3 2019, URL: http://tiny.cc/y1tr7y
  15. ブイヨンL., 良く測定するDevOpsチームを解釈 (そして最高) プロジェクト, PMExpo2017, プレゼンテーション, 10月 2017, URL:https://www.pmexpo.it/2017/programma/009tk
  16. ISO / IEC, 国際標準 14764:2006 - ソフトウェア工学 - ソフトウェアライフサイクルプロセス – メンテナンス, 2006
  17. ISO / IEC, 国際標準 25023:2016 – システムとソフトウェア工学 – システムとソフトウェアの品質要件と評価 (平方) – システムおよびソフトウェア製品の品質の測定, 六月 2016
  18. ISO / IEC, 国際標準 19515:2019 – 情報技術 – 管理グループ自動ファンクションポイントオブジェクト (AFP), 1.0, かもしれません 2019
  19. ウッドワードS., 曇りの世界でポイント分析明確ファンクション, Metricas 2012, サンパウロ (ブラジル), 11月 28-29 2012, URL:http://www.bfpug.com.br/metricas2012/woodward.pdf
  20. Cagley T., ファンクションポイントとIOT, または私のキッチンは私をスパイされていますどのように!, IFPUG ISMA17, バンガロール (インド), 行進 8, 2019

著者について

ルイジBuglioneはグルッポUtentiのファンクションポイントイタリアの会議/教育と社長のためのIFPUGディレクターであります – イタリアのソフトウェアメトリクス協会 (GUFPI-ISMA) (www.gufpi-isma.org). 彼は、エンジニアリングのIngでの測定とプロセス改善スペシャリストとして働きます. infファイル. ローマのスパ, イタリアとエコール・ド・テク高等准教授 (ETS) - ケベック州の大学, カナダ. 彼はいくつかの認定を達成しました, IFPUG CFPS含みます, CSP, CSMS, ソフトウェアの測定についてとCOSMIC CCFL. 彼は、SW /サービスの測定に関する国際会議で定期的に講演です, プロセス改善と品質と、このような問題に積極的に国際と国立技術協会の一部です。. 彼は博士号を受けました. MIS中と経済学の学位を優等. ルイージはで到達することができます luigi.buglione@eng.it.

あなたも好きかも...