Документация по сопровождению  ПС (system documentation)  описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ.

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

Документация по сопровождению  ПС можно разбить на две группы:

1) документация, определяющая  строение программ и структур  данных ПС и технологию их  разработки;

2)  документацию, помогающую  вносить изменения в ПС.

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

• Внешнее описание ПС (Requirements document).
• Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы.
• Для каждой программы ПС - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
• Для каждого модуля - его спецификация и описание его строения (design description).
• Тексты модулей на выбранном языке программирования (program source code listings).
• Документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС. Документы установления достоверности ПС включают прежде всего документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ.

Документация второй группы содержит:

·  Руководство по сопровождению  ПС (system maintenance guide), которое описывает известные проблемы вместе с ПС, описывает, какие части системы являются аппаратно- и программно-зависимыми, и как развитие ПС принято в расчет в его строении (конструкции).

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

 

35. Методы оценки продукта. Оценка  трудозатрат и длительности проекта.

Процесс оценки стоимости (для фиксированных возможностей, уровня качества и расписания) часто начинается в начале проекта и продолжается даже на стадии написания программного кода. При открытии проекта у команды может быть весьма расплывчатое представление об его стоимости. Если оценку стоимости можно отложить до тех пор, пока проект не наберет полного хода, то так и нужно сделать, но всегда есть необходимость хотя бы грубой оценки диапазона стоимости уже на фазе анализа требований. Чем больше мы знаем о требованиях, предъявляемых к продукту, и чем дальше продвинуто проектирование, тем точнее мы можем оценить стоимость проекта (рис. 2.11).

Несколько методов оценки, в особенности СОСОМО, базируются на числе строк кода (LoC — Lines of Code). Конструктивная модель стоимости (СОСОМО — Constructive cost model) была предложена Боэмом. Может показаться, что на ранних стадиях проекта оценивать количество строк кода не имеет смысла, поскольку до кодирования еще далеко. Но если есть возможность сравнить один продукт с другим, то использование данной метрики становится вполне оправданным. Например, допустим, что у нас был проект по управлению спутниками и мы хотим сравнить наш новый проект, который предусматривает дополнительные возможности — мониторинг ураганов. Старый проект содержит три миллиона строк кода на Фортране. Дополнительная возможность потребует 100 ООО строк на Фортране, что видно из сравнения с другими программами отслеживания ураганов. Если новый проект потребуется сделать на другом языке, то можно использовать средние по отрасли коэффициенты для пересчета количества строк кода.

В 1979 году Альбрехт [2] предложил  фундаментальное понятие функционального размера (FP — functional points), для измерения размера любого проекта независимо от проектирования. Метод измерения функционального размера состоит в единообразном измерении всех возможностей приложения и выражении размера приложения в виде одного числа. Это число можно далее использовать для оценки числа строк кода, стоимости и сроков проекта. Функциональный размер — это весьма привлекательное понятие, поскольку оно претендует на то, чтобы измерить саму суть возможностей будущей программы. Однако нужно иметь определенный навык, чтобы применять этот метод аккуратно и последовательно.

Метод определения функционального  размера состоит из следующих  шагов.

Вычисление функционального размера: шаг 1

Идентифицируйте функции (например, «поиск данных», «отображение данных»), которые должно иметь приложение. Международная группа пользователей функционального измерения (IFPUG — International Function Point Users Group) опубликовала критерии, по которым выделяются «функции» в этом смысле. Рассматривается функциональность на уровне пользователя, а не на уровне программного кода. Обычная функция соответствует обработке одной экранной формы.

Вычисление функционального размера: шаг 2

Для каждой выделенной функции, сосчитайте количество факторов каждого  типа. Ниже приведены объяснения для  каждого фактора.

Внешние входы. Только такие входы, которые по-разному влияют на выполняемую функцию, считаются отдельными. Например, если функция заключается в сложении двух чисел, то она имеет один вход, а не два, то есть EI = 1. С другой стороны, если на вход можно подать букву А для выполнения сложения или букву S для выполнения вычитания, то такая функция будет иметь два входа, EI = 2.

Внешние выходы. Отдельно считаются только выходы для существенно различных алгоритмов и нетривиальной функциональности. Например, вывод сообщения различными шрифтами нужно считать за 1. Сообщения об ошибках не учитываются. Диаграмма, представляющая данные, считается за 2 (1 для данных и 1 для формата диаграммы). Если выходные данные посылаются на существенно разные устройства (например, принтер и монитор), то они считаются отдельными выходами.

Внешние запросы. Каждый независимый внешний запрос считается за 1.

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

Внешние логические файлы. Каждая уникальная логическая группа пользовательских данных, размещенная во внешних по отношению к приложению файлах, считается за 1.

Вычисление функционального размера: шаг 3

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

Вычисление функционального размера: шаг 4

Теперь нужно определить веса для 14 общих характеристик проекта. Каждой общей характеристике присваивается  вес от 0 до 5.

Вычисление функционального размера: шаг 5

Наконец, уточненный функциональный размер вычисляется по следующей  формуле.

Уточненный функциональный размер = [Приближенный функциональный размер] х [0,65+0,01 х (Сумма общих характеристик)].

Суть этой формулы состоит  в том, что если к приложению не предъявляется никаких специальных  требований (все общие характеристики равны нулю), то неуточненный функциональный размер нужно уменьшить на 35 %. В противном случае неуточненный размер нужно увеличить на 1 % на каждую единицу значения общих характеристик.

Оценка трудозатрат и длительности проекта по количеству строк кода

Как только мы оценили количество строк программного кода (либо с  помощью единиц функционального  размера, либо методом, приведенным  в разделе 2.8.2), мы можем использовать его при оценивании затрат труда  и продолжительности проекта. Боэм обнаружил, что на самом деле трудозатраты на разработку приложений растут быстрее, чем размер приложений. Для представления данного соотношения используется экспоненциальная функция со значением показателя, близким к 1,12. Модель Боэма также гласит, что длительность проекта возрастает экспоненциально вместе с прилагаемыми к проекту усилиями. Однако в данном соотношении значение экспоненты меньше единицы и составляет около 0,35. Это отражает тот факт, что после достижения некоторого значения («колена» на кривой 2 на рис. 2.13) дополнительные усилия только растягивают время, необходимое для завершения проекта. Это проиллюстрировано на рис. 2.13 (LOC обозначает количество строк программного кода).

Используя данные из многочисленных проектов, Боэм оценил параметры рассматриваемых выше соотношений, предложив экспоненциальную зависимость. Полученные им формулы приводятся в табл. 2.13 (KLOC обозначает тысячу строк кода). Органические приложения — это самостоятельные приложения, такие как классические (например, без привлечения Web) текстовые редакторы или игра Встреча из нашего примера. Встроенные приложения являют собой интеграцию аппаратного и программного обеспечения (антиблокировочная система тормозов в автомобиле). Промежуточные — нечто среднее. Игра Встреча для случая игры в Интернете будет промежуточной: она уже не органическая, но еще и не так жестко встроена, как система управления тормозами.

В модели Боэма утверждается, прежде всего, что для разных типов  приложений длительность и трудозатраты по-разному зависят от размера приложений (отличаются множителем и показателем экспоненты). Например, разработка приложения в 20 000 строк потребует 2,4 х 20^1,05 ≈ 51 человеко-месяц, если приложение органично, и потребует 3,6 х 20^1,2 ≈ 76 человеко-месяцев, если это встроенное приложение.

Формула для длительности может быть прямо выражена через  количество строк кода:

Длительность = с * Трудозатраты^d = с * (а * KLOC^b)^d = с * a^d * KLOC^bd

На первый взгляд, формула  Боэма для расчета длительности проекта может показаться несколько  странной, так как зависимость  между продолжительностью и прилагаемыми усилиями представляется намного проще. Если мы знаем, что работа требует 120 человеко-месяцев, и имеем в распоряжении 10 человек, не будет ли она сделана через 12 месяцев? Это может произойти, только если мы сумеем с пользой полностью занять 10 человек в проекте с первого и до последнего из 365 дней. Обычно это просто невозможно. Например, представьте себе первый день проекта: вы еще ничего не знаете о проекте, тогда какой же полезной деятельностью могут заниматься в этот день все 10 разработчиков? Таким образом, становится ясно, что при найме 10 разработчиков с первого дня проекта работа, рассчитанная на 120 человеко-месяцев, будет идти намного дольше 12 месяцев.

Формула Боэма обладает следующим  интересным свойством: длительность проекта  не зависит от количества привлекаемого в проект персонала! Она зависит только от объема работ. Вообще-то, формула предполагает, что в проекте имеется приблизительно необходимое количество персонала в каждый конкретный момент (один человек на первый день, 30 человек на сотый день, в соответствии с потребностями).

Модель Боэма интенсивно проверялась, получила широкое признание  и уточнялась со временем. Тем не менее для ее эффективного использования нужен изрядный опыт и постоянная коррекция в соответствии со здравым смыслом.

 

36. Система стандартов, регламентирующая  требования к программной документации.