Информатика и выч. техника \ Разработка и стандартизация программных систем и информационных технологий

Методы оценки размера программной системы, страница 8

Часть 2 стандарта предоставляет схему для оценивания степени соответ­ствия определенного метода измерения функционального размера обязательным требованиям части 1 этого стандарта. Схема включает требования к составу и ква­лификации экспертных групп, входным документам для выполнения оценивания, процедурам оценивания и к оформлению результатов. Выполнение оценивания по этой схеме гарантирует объективность, беспристрастность, последовательность и повторяемость оценок.

Часть 3 стандарта нужна, прежде всего, тем, кто хочет выбрать метод оценивания размера, пригодный для использования по отношению к программным системам определенного класса, разрабатываемым для конкретной функциональной области. Для этого метод-кандидат на использование должен быть протестирован (верифицирован) путем сопоставления результатов вычислений этим методов и другим (ранее утвержденным) методом. Оцениваются такие показатели эффектив­ности метода:

•  проверяемость метода,

•  повторяемость результатов,

•  воспроизводимость процедур,

•  точность оценок,

•  конвертируемость меры в другую меру размера,

•  порог распознаваемости  изменений   в   функциональных  требованиях
пользователя,

•  применимость в рамках определенной функциональной области.

Потребители различных методов измерения функционального размера ино­гда имеют претензии к разработчикам методов FSM, поскольку на практике эти методы дают плохие результаты. Это связано с тем, что не действует никакого со­глашения о стандартных эталонных наборах требований пользователя (RUR, Ref­erence User Requirements), применительно к которым претензии потребителей мог­ли бы рассматриваться.

Цель части 4 стандарта - дать потребителям ориентиры, относительно ко­торых можно было бы оценить эффективность методов FSM для различных классов программного обеспечения в различных программных средах.

Используя эту часть стандарта

•  разработчики метода FSM будут иметь возможность проверить его соот­
ветствие функциональные области, в которой он может эффективно использовать­
ся, и отшлифовать метод на эталонных RUR;

•  оценщики методов FSM будут располагать эталонными объектами, по
отношению к которым FSM может быть применен и сопоставлен;

•  пользователи прекратят неправомерное использование непригодных для
их классов ПС методов измерения размера;

•  менеджеры проектов смогут использовать улучшенные эталонные дан­
ные для контрольного тестирования качества ПС и продуктивности проекта.


Эталонные требования пользователя включают функциональные требования пользователя (FUR, от Functional User Requirements), требования к качеству (QR, от Quality Requirements) и технические требования (TR, от Technical Requirements).

Стандарт содержит примеры эталонных требований пока только для двух крупных классов ПС - деловых (офисных) информационных систем и систем ре­ального времени/управления.

Схема использования эталонной модели FSM показана на рисунке 7.5.

Цель части 5 стандарта - определить подход к классификации функцио­нальных требований потребителя для применения в FSM. Используя эту часть стандарта

•  потребители FSM смогут оценить особенности функциональных требова­
ний к собственным ПС и категоризировать их по принадлежности к одной или
больше функциональным областям;

•  потребители смогут выбрать метод FSM, зарекомендовавший себя как
подходящий для функциональных областей, отвечающих тем FUR, по которым
оценивается размер;

•  разработчики метода FSM будут способны четко определить функцио­
нальные области, для которых их метод может использоваться эффективно;

•  оценщики методов и эксперты по методам измерения функционального
размера будут обеспечены четкими руководствами для определения функциональ­
ных областей, применительно к которым нужно определять эффективность мето­
дов;

•  разработчики ПС смогут использовать эталонные требования в качестве
ориентира для проверки полноты набора исходных функциональных и нефункцио­
нальных требований пользователя разрабатываемых ПС определенного класса.

Первым методом, который признан полностью соответствующим требовани­ям стандарта ISO/IEC 14143, стал метод COSMIC Full Function Points, представлен­ный в разделе 7.2.


Литературакглаве 7

1.    Park R. Software Size Measurement: A Framework for Counting Source Statements
// Tech. Report CMU/SEI-92-TR-020. - Software Eng. Inst., Pittsburgh, 1992. - 242

p.

2.  Santillo L. Early FP Estimation and the Analytic Hierarchy Process // ESCOM-
SCOPE 2000, Munich, Germany, April 18-20. - 2000. - 9 p.

3.  Jones C., A short history of Function Points and Feature Points // Cmbridge, Massa­
chusetts: Software Productivity Research, Inc.- 1988.- 45 p.

4.  Symons C., Software Sizing and Estimating: Mk II FPA // Chichester: John Willey
&Sons Ltd.-1991.-57p.

5.  Whitmire S., An Introduction to 3D Function Points // Sottware Development - 1995.-
V.3, N.4.- P. 43-53.

6.  Banker D. et al., Automation Output Size and Reuse Metrics in a Repository-Based
CASE Environment // IEEE Trans. Soft.Eng. - 1994.- SE - 20, N.3.- P.169-186.

7.  Santillo L.,Meli R. Early Function Points: some practical experiences of use //
ESCOM-ENCRESS 98, Project Control for 2000 and Beyond, Rome, Italy, May 27-
29.-1998.-13 p.

8.  Full Function Points: Counting Practices Manual / St-Pierre D., Maya M., Abran A.,
Desharnais J.-M., Bourque P.// Technical Report 1997-04, Quebec, Montreal, Canada
(www.lrgl.uqam.ca/ffp.html).

9.  Meli R., Abran A. et al. On the applicability of COSMIC-FFP for measuring software
throughout its life cycle // ESCOM-SCOPE 2000, April 18-20. - 2000. - 10 p.

10.  Reifer D. J. Web development: Estimating Quick-to-Market Software // IEEE Soft­
ware. - nov/dec. - 2000. - P. 57-54.

Скачать файл