Калайда В.Т., Романенко В.В. Технология разработки программного обеспечения (2007), страница 5

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

Такой полуалгоритмический процесс может бытьскомбинирован с такими методами, как метод экспертных оценок.Закон Паркинсона. Во многих случаях для выполнениянекоторой работы (задачи) затрачивается то время, которое отведено для нее, независимо от того, является ли выполнениеэтой работы необходимым. Каждый исполнитель вносит какой-27то вклад в работу над системой и расходует определенное время. Подобный подход опирается на использование других методов, т.е.

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

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

В подобных случаях разработчики просто осведомлены о наличии средств у заказчика.В общем случае точную оценку затрат можно дать лишьна основе опыта.3.1.2.2 Оценка на основе распределения РэлеяВ настоящее время некоторые результаты теории надежности аппаратных средств ЭВМ начинают использовать дляоценки сроков и затрат при разработке программного обеспече-28ния.

Было установлено, что зависимость суммарных затрат отвремени при разработке больших систем (свыше 50 человеколет) хорошо отображается следующим уравнением:(E ( t ) = K 1  e at2),гдеE(t) — суммарные затраты к моменту времени t;К — общая стоимость системы;а — характеристика максимальных затрат на единичномотрезке времени.Такая зависимость, выраженная в дифференциальнойформе, отображается кривой РэлеяE ( t) = 2 K a t e at 2,Ежегодные затратыгде E’(t) — плотность затрат или ежегодные затраты (рис. 3.4).0,50,40,30,20,10147 10 13 16 19 22 25 28 31 34 37 40ВремяРис.

3.4 — Отображение ежегодных затрат кривой РэлеяПоскольку 60 % затрат производится на этапе сопровождения, нет ничего удивительного, что максимум кривой близок к моменту создания системы, т.е. к тому моменту, когдатрадиционно считается, что работы завершены.Пусть P(T > t) вероятность того, что в интервале [0, t] событие не произошло. Тогда в соответствии с законом ПуассонаP ( T > t ) = e lt .29Поскольку P(T ≤ t) + P(T > t) = 1, вероятность того, что событие произошло в интервале [0, t], можно представить в следующем виде:P(Tt ) = 1  P ( T > t ) = 1  elt .Частота событий, или скорость решения задач, выражается как производная функции распределения, т.е.f ( t ) = lelt .Допустим, что если событие произошло, p есть вероятность решения задачи (вероятность получения правильного решения). Тогда получим следующие соотношения:t ) = 1  elt ,f ( t ) = ple plt .P( TПоложим, что вероятность p является функцией времени.В этом случае имеемtP( T > t) = el p ( t ) d t0,tP(Tt) = 1 el p ( t ) d t0,tf ( t ) = lp ( t ) el p ( t ) d t0.Опыт разработки больших программных систем показывает, что зависимость вероятности правильного решения задачиот времени можно выразить в видеp ( t ) = at .При этом получимP(Tt) = 1  e( lat 2)2.Вводя обозначение a = (λα)/2 и умножая последнюю формулу на общую стоимость системы K, получим приведеннуювыше формулу для суммарных затрат E(t) к моменту времени t.Таким образом, для ежегодных затрат имеем:E ( t ) = 2at K  E ( t ) .30Это уравнение содержит две переменные величины — t и[K – E(t)].

По мере приближения работ к завершению (с возрастанием t) скорость решения задач f(t) увеличивается. Это происходит вследствие эффекта «обучения», поскольку по мере знакомства исполнителей с задачами работа становится более эффективной.Противоположную тенденцию имеет выражение [K – E(t)],которое определяет незавершенную работу. С приближениемработ к завершению сложность системы увеличивается, вследствие чего снижается производительность труда исполнителей.Кривая Рэлея имеет два параметра — K и a. В начале работы Kможно оценить, используя величину планируемых затрат, а aможно определить, исходя из состава исполнителей.

Дату завершения работ определяют по достижению максимума расходов(максимум кривой Рэлея).3.1.3 Контрольные точкиКонтрольные точки указывают на моменты завершенияработ; они позволяют судить о состоянии разработки системы.Контрольные точки планируются руководителем проекта с целью осуществления контроля за разработкой. Ситуацию типа«программа завершена на 90 %» нельзя отнести к контрольнойточке, поскольку руководитель проекта не может знать, какойобъем составляют 90 % программы до тех пор, пока программане завершена.Существуетбольшоеколичество«стандартных»контрольных точек: выпуск функциональных спецификаций; завершение проектирования отдельных модулей; компилирование модулей без ошибок; успешное проведение тестирования модуля и т.д.В техническом задании, кроме срока разработки программ, обязательно должны быть указаны контрольные точки,для того чтобы раньше выявить возможные недоработки.Для каждой контрольной точки должны быть рассчитаныобщие характеристики системы, такие, как стоимость, сроки завершения, сложность.31При работе с библиотекарем должна быть разработана соответствующая форма отчетных документов по контрольнымточкам.3.1.4 Средства разработкиКомпиляторы и отладочные средства известны уже достаточно давно.

В настоящее время создано (и создается) ряд новых программных средств, помогающих разработке.Среди таких средств следует особо выделить системыуправления базами данных (СУБД), которые помогают управлять организацией разрабатываемого программного обеспечения. Весьма удобны для контроля таблицы перекрестных ссылок, атрибутивные листинги, таблицы распределения памяти.Одной из первых систем управления базой данных с возможностью ведения библиотеки модулей в исходном коде является разработанная в Мичиганском университете системаISDOS, включающая в себя язык определения задач и анализатор определения задач (PSL/PSA). В эту систему входит языкдля описания интерфейса при проектировании программ, позволяющий осуществлять автоматическую проверку взаимосвязипрограмм.

Схожа с указанной система RSL (язык определениятребований), предназначенная для определения требований иинтерфейсов посредством системы управления данными. Нижеэти системы будут рассмотрены подробнее.3.1.5 НадежностьОдним из основных параметров надежности разрабатываемой программной системы является концептуальная целостность, т.е. единообразие стиля и простота структуры.Обычно она достигается за счет минимизации числа разработчиков. Организация бригады главного программиста такжеспособствует концептуальной целостности системы, т.к.

основная работа по проектированию в этом случае выполняется главным программистом.Среди проектировщиков этот метод называется интеллектуальным программированием. Техническим документом, отражающим этот подход, является логическая структура программы (структурная схема).32Аттестация системы должна осуществляться на всех стадиях разработки. Для каждого уровня проектирования, кодирования или тестирования необходимо показать, что правильностьсистемы сохраняется при добавлении в нее любых новых частей. Это должно быть отражено в структурной схеме. Дляконтроля правильности используется так называемый контрольный анализ. Проведение контрольного анализа периодически планируется для всех исполнителей. Для просмотра выбирается какая-то часть системы.