Об оценках параметров модели выбора метода реализации этапа  жизненного цикла программного проекта

А.Ю. Заложнев,
д.т.н., проф., zalozhnev@yandex.ru,
Д.В. Перемежко,

соиск., denis_fa@mail.ru,
ИПУ РАН, Финансовый университет, г. Москва

Важной характеристикой компьютерного проекта является полное время его выполнения, которое зависит от выбора метода его реализации. В докладе рассматривается проблема оценки параметров математической модели, которая предназначена для выбора метода реализации этапа разработки жизненного цикла программного проекта.

 

Important characteristic of the computer project implementation is the project implementation overall time. It depends on the choice of implementation method. The report addresses to the parameters estimation problem for the mathematical model that is designed to select the implementation method of the development phase for software life cycle.

Введение

В работе [1] представлена процедура, позволяющая осуществить выбор между двумя в определенном смысле «крайними» подходами к реализации этапа разработки жизненного цикла программного проекта – методами Scrum и Turkey. Реализация этой процедуры выбора, предполагает использование математической модели, также представленной в [1], оценка параметров которой и является предметом обсуждения в данном докладе.

Формулировка, формализация и исследование проблемы

Важнейшей характеристикой того или иного компьютерного проекта является полное время его выполнения, которое зависит от выбора метода его реализации. Проблема выбора метода реализации компьютерного проекта, позволяющего выполнить проект за минимальное время, является весьма сложной и трудноразрешимой в общем случае, поскольку имеется достаточно большое число подходов к реализации подобного рода проектов. Однако, при сравнительном анализе методов Scrum и Turnkey, как двух в определенном смысле «крайних» методических подходов, эта проблема, по-видимому, может быть решена путем развития соображений, предложенных, например, в работе [1].

Метод Turnkey предполагает разработку «с нуля» и продажу покупателю полностью законченного продукта. Это означает, что поставщик (vendor) полностью «закрывает» все стадии жизненного цикла компьютерного проекта. Первой работой, где указанная методология сформулирована в достаточно общем виде, хотя и применительно к строительным инженерным проектам, принято считать работу [2]. Методология Scrum («схватка» – один из способов розыгрыша стандартных положений при игре в регби), впервые сформулированная в [3], предполагает осуществление итеративного процесса пошаговых улучшений (incremental), реализуемого самоорганизующимися (self-organize) командами внутри самой организации-потребителя и/или разработчика. В применении к разработке программного обеспечения метод Scrum является наиболее формализованным из достаточно широкого набора т.н. Agile-методологий – гибких методов реализации компьютерных проектов [4,5].

В работе [1] показано, что полное время реализации проекта на основе методологии Turnkey («под ключ») является случайной величиной, распределенной по нормальному закону с математическим ожиданием:

                       (1)

и среднеквадратическим отклонением:

                         (2)

где  и sτTr – математическое ожидание и среднеквадратическое отклонение случайной величины τTr – времени разработки и согласования технического задания компьютерного проекта J, реализуемого методом Turnkey;

 и stTr – математическое ожидание и среднеквадратическое отклонение случайной величины tTr – времени непосредственного выполнения проекта J, реализуемого методом Turnkey.

В работе [6] также показано, что полное время реализации программного проекта на основе методологии Scrum является случайной величиной распределенной по нормальному закону с математическим ожиданием:

        (3)

и среднеквадратическим отклонением:

          (4)

где  и si – математическое ожидание и среднеквадратическое отклонение случайной величины ti, i=1,m –времени выполнения работ для i-й итерации или спринта, реализуемого методом Scrum;

Методология Scrum предполагает, что продолжительность sprint planning meeting ограничена 8 рабочими часами или 1 рабочим днем. Если время реализации проекта измеряется в рабочих днях, то время планирования работ для i-й итерации или спринта проекта J, реализуемого методом Scrum τi ≤ 1, i=1,m. В работе [6] предполагается, что τi = 1, т.е. равно максимально допустимому в рамках данной методологии времени, т.е. считается, что τi является детерминированной величиной, среднеквадратическое отклонение которой, очевидно, равно нулю, что и объясняет наличие слагаемого m в формуле (3).

В работе [6] также показано, что для того, чтобы произвести сравнение методов Turnkey и Scrum, зная ожидаемое (желаемое) время выполнения проекта J – TJ и используя свойство нормальности распределения случайных величин t1 и t2, следует вычислить значения нормированных величин tJ1 и tJ2:

        (5)

         (6)

Подставляя значения tJ1 и tJ2 в таблицу значений функции нормального распределения, найдем вероятности pJ1 и pJ2 выполнения проекта J за время меньшее или равное TJ, соответственно, при использовании методов Turnkey (при подстановке tJ1) и Scrum (при подстановке tJ2).

В случае, если имеет место соотношение (7):     

             (7)

то при реализации компьютерного проекта J целесообразнее использовать метод Turnkey, если же имеет место соотношение (8):

             (8)

Следует отметить, что в силу монотонности функции распределения для принятия решения о выборе метода реализации проекта достаточно провести сравнение значений tJ1 и tJ2,

т.е.  если имеет место соотношение (9):    

            (9)

то при реализации компьютерного проекта J целесообразнее использовать метод Turnkey, если же имеет место соотношение (10):

                 (10)

При приблизительно известном объеме кодов реализуемого программного проекта J и/или отдельных его этапов для оценки длительности разработки в целом или её отдельных этапов могут быть использованы различные методы оценивания, например, COCOMO I или более совершенный и сложный COCOMO II [6]. Предварительная оценка объема программных кодов может производиться с помощью методов макрооценки функциональности программного обеспечения таких, например, как методы определения функциональных точек (Function points), алгоритмические объемы для достижения каждой из которой могут быть заранее приблизительно установлены. Существует ряд стандартов для оценки объемов ПО, основанных на использовании метода функциональных точек. Среди стандартов ISO из данного ряда могут быть выделены следующие: ISO/IEC 20968:2002 Software engineering (Mk II Function Point Analysis) [7], ISO/IEC 24570:2005 Software engineering (NESMA function size measurement method version 2.1) [8], ISO/IEC 29881:2008 (FiSMA 1.1 functional size measurement method) [9], ISO/IEC 20926:2009 (IFPUG functional size measurement method 2009) [10], ISO/IEC 19761:2011 (COSMIC: a functional size measurement method) [11].

Основной проблемой применения представленной выше модели является определение среднеквадратических отклонений оцениваемых случайных величин. Они могут быть получены с использованием нижеследующих соображений.

В случае, если более или менее достоверные оценки среднеквадратического отклонения случайных величин τTr, tTr и ti не могут быть получены непосредственно путем экспертного оценивания, поскольку число различных оценок одной и той же временной характеристики (количество экспертов) слишком мало, но если при этом экспертами могут быть оценены разумные оптимистическое (tопт) и пессимистическое(tпесс) времена выполнения каждого из этапов, которым соответствуют случайные величины τTr, tTr и ti, то величина среднеквадратического отклонения для каждой из них может быть найдена по обобщенной формуле (11):

              (11)

Эти же характеристики (tопт и tпесс) могут быть использованы для нахождения оценок математических ожиданий по обобщенной формуле (12):

    (12)

Если при этом эксперты (эксперт) могут оценить также наиболее вероятное время выполнения каждого из этапов – tнв (most likely time), то в соответствии с формулой (13) может быть определено так называемое «ожидаемое время» (expected time) – tнв выполнения для каждого из этапов работ:

                         (13)

Эта характеристика широко используется в методе PERT в качестве оценки времени выполнения многократно повторяемых работ. В нашем случае она может быть использована для оценки математического ожидания случайных величин, параметры распределений которых являются исходными данными для рассматриваемой здесь модели.

Заключение

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

Литература

1.  Заложнев А.Ю., Перемежко Д.В. О сравнении методов Scrum и Turnkey при реализации программно-технических организационных проектов / Системы проектирования, технологической подготовки производства и управления этапами жизненного цикла промышленного продукта (CAD/САМ/РDМ-2014). Труды 14-й международной конференции. М.: ООО «Аналитик», 2014. С. 74-76.

2.  Conference on building and civil engineering law/ Conference first held: Perth, 18 Sept. 1984 / by I.N. Duncan Wallace. Turner, N.S.W.: Master Builders' Federation of Australia, 1984. 70 pages.

3.  Takeuchi H.; Nonaka I. New New Product Development Game / Harvard Business Review. 1986 № 86116. Pp.137–146.

4.  Manifesto for Agile Software Development. DNS: http://agilemanifesto.org.

5.  AgileDays. URL: http://agiledays.ru.

6.  COCOMO II. Center for Systems and Software Engineering. University of Southern California. URL: http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html.

7.  ISO/IEC 20968:2002. Software engineering – Mk II Function Point Analysis – Counting Practices Manual. URL: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35603.

8.  ISO/IEC 24570:2005. Software engineering – NESMA functional size measurement method version 2.1 – Definitions and counting guidelines for the application of Function Point Analysis. URL: http://www.iso.org/ iso/catalogue_detail.htm?csnumber=37289.

9.  ISO/IEC 29881:2008. Information technology – Software and systems engineering – FiSMA 1.1 functional size measurement method. URL: http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=45724.

10.  ISO/IEC 20926:2009. Software and systems engineering – Software measurement – IFPUG functional size measurement method 2009. URL: http://www.iso.org/iso/catalogue_detail.htm?csnumber=51717.

11.  ISO/IEC 19761:2011. Software engineering – COSMIC: a functional size measurement method. URL: http://www.iso.org/iso/catalogue_detail.htm?csnumber=54849.