ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 13463
Скачиваний: 411
Глава 8
КОЛЛЕКТИВНАЯ РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Из-за больших объемов проектов разработка программного обеспечения ведется коллективом специалистов. Работая в коллективе, отдельные специалисты должны взаимодействовать друг с другом, обеспечивая целостность проекта, что при отсутствии удовлетворительных средств описания поведения сложных систем, упоминавшемся выше, достаточно сложно. Причем чем больше коллектив разработчиков, тем сложнее организовать процесс работы [8].
8.1. Пакеты прикладных программ
Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения. Рассмотрим наиболее применяемые пакеты прикладных программ для коллективной разработки программного обеспечения.
8.1. U Система контроля версий Microsoft Visual SourceSafe
Microsoft Visual SourceSafe (Visual SourceSafe, VSS) — программный продукт компании Майкрософт, файл-серверная система управления версиями, предназначенная для небольших команд разработчиков. VSS позволяет хранить в общем хранилище файлы, разделяемые несколькими пользователями, для каждого файла хранится история версий.
VSS входит в состав пакета Microsoft Visual Studio и интегрирован с продуктами этого пакета. Доступен только для платформы Windows. Версию для Unix поддерживает компания MainSoft.
Visual SourceSafe нацелен на индивидуальных разработчиков либо небольшие команды разработчиков. Там, где VSS недостаточно, ему на замену предлагается новый продукт Майкрософт — Visual Studio Team Foundation Server входящий в состав Visual Studio Team System.
8Л.2. Система контроля версий Subversion
Subversion — свободно распространяемая система управления версиями с открытым кодом. Subversion разработана специально для замены CVS, самой распространенной открытой системы управления версиями. Она обладает всеми основными функциями CVS (хотя некоторые из них выполняет другими способами) и лишена ряда ее недостатков.
Subversion часто называют «svn» — по названию клиентской программы, входящей в ее дистрибутив.
Subversion — централизованная система. Данные хранятся в едином хранилище. При сохранении новых версий используется дельта-компрессия, т. е. система находит отличия новой версии от предыдущей и записывает только их, избегая ненужного дублирования данных. Хранилище может располагаться на локальном диске или на сетевом сервере. К локальному хранилищу клиент Subversion обращается непосредственно. Для доступа к удаленному серверу может использоваться собственный сетевой протокол или стандартный протокол WebDAV, поддерживаемый с помощью специального модуля для веб-сервера Apache.
Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем модифицируют их и публикуют изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. При использовании доступа с помощью WebDAV опционально поддерживается прозрачное управление версиями — если любой клиент WebDAV открывает для записи и затем сохраняет файл, хранящийся на сетевом ресурсе, автоматически создается новая версия.
Коннтрольные вопросы
-
Что такое коллективная разработка ПО?
-
Что такое система контроля версий?
-
Расскажите об основных особенностях известных вам систем контроля версий.
Глава 9
ЭКОНОМИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ И ИСПОЛЬЗОВАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ
9.1. Оценка стоимости разработки программного обеспечения
Процесс оценки стоимости ПО является весьма сложной задачей. Он начинается на стадии анализа требований к программному обеспечению и продолжается даже на этапе реализации. Существует множество подходов к решению этой задачи, но до сих пор не существует универсальной методики, дающей гарантированный результат. Можно только утверждать, что чем точнее сформулированы требования к разрабатываемому программному продукту, тем вернее можно оценить его стоимость.
Одним из способов получения достоверного результата является применение разных методов на этапе анализа требований или проектирования, а затем усреднение результатов, полученных этими методами [57].
9.1.1. Линейный метод
Этот довольно старый метод, несмотря на свою простоту (и даже примитивность), активно применяется по сей день. Стоимость разработки определяется следующим образом:
С = ТхЦ, (9.1)
где С — стоимость; Т — трудозатраты (например, в человеко-часах или человеко-месяцах); Ц — их удельная стоимость, которую
определяют, в основном исходя из заработной платы и связанных с ней начислений.
Трудозатраты вычисляют по следующей формуле:
Т = РхП. (9.2)
Здесь Р — размер кода программы, чаще всего измеряется в строках (LOC — Lines Of Code); П — временная производительность.
Недостаток такого подхода кроется в способе, которым измеряется результат. Получается, что у программиста отсутствует стимул для повышения своего мастерства и написания лаконичного кода, более простого в отладке и соответственно более дешевого [8].
Р. /.2, Метод функциональных точек
Этот метод используется для измерения производительности взамен устаревшего линейного подхода, где производительность измерялась количеством строк программного кода. Впервые функциональные точки (function points) были предложены сотрудником IBM Аланом Альбрехтом в 1979 г. [58].
Преимуществом данного метода является то, что поскольку применение функциональных точек основано на изучении требований, то оценка необходимых трудозатрат может быть выполнена на самых ранних стадиях работы над проектом. Для поддержки и развития данного метода в 1986 г. была создана Международная группа пользователей функционального измерения (IFPUG — International Function Point User Group).
Метод заключается в следующем.
Сначала выделяются функции разрабатываемого программного обеспечения, причем на уровне пользователей, а не программного кода. Например, рассмотрим программный комплекс, реализующий различные методы сортировки одномерных массивов. Одной из функций пользователя данного комплекса будет выбор метода, ее мы и будем описывать в качестве примера [61].
Следующим шагом метода будет подсчет количества факторов, приведенных ниже:
• внешние входы. Различаются только те входы, которые по-разному влияют на функцию. Функция выбор метода имеет один внешний вход;
-
внешние выходы. Различными считаются выходы для различных алгоритмов. Представим, что наша функция выдает сообщение — текстовое описание выбранного метода, и вызывает другую функцию, непосредственно реализующую выбранный алгоритм сортировки, следовательно, она имеет два выхода;
-
внешние запросы. В нашем примере таковых нет;
-
внутренние логические файлы — группа данных, которая создается или поддерживается функцией, считается за единицу. В качестве внутреннего логического файла для нашей функции примем текстовый файл, содержащий описания алгоритмов;
-
внешние логические файлы — пользовательские данные, находящиеся во внешних по отношению к данной функции файлах. Каждая группа данных принимается за единицу. Внешним по отношению к нашей функции является файл с результатом обработки.
Далее полученные значения умножаются на коэффициенты сложности для каждого фактора (по данным 1РРиО) и суммируются для получения полного размера программного продукта. Значения этих коэффициентов приведены в табл. 9.1.
Таблица 9.1. Значения коэффициентов сложности
|
Параметр |
Просто |
Средне |
Сложно |
|
Внешние входы |
3 |
4 |
6 |
|
Внешние выходы |
4 |
5 |
7 |
|
Внешние запросы |
3 |
4 |
6 |
|
Внутренние логические файлы |
7 |
10 |
15 |
|
Внешние логические файлы |
5 |
7 |
10 |
Для рассматриваемого нами примера возьмем значения, приведенные в табл. 9.2.
Размер нашей функции составит:
ФР =1x3+1x4+1x5+1x7+1x7 = 26.
Это число является предварительной оценкой и нуждается в уточнении.
Следующим шагом в определении размера программного кода методом функциональных точек является присвоение веса (от 0 до 5) каждой характеристике проекта. Перечислим эти характеристики:
-
Требуется ли резервное копирование данных?
-
Требуется обмен данными?
-
Используются распределенные вычисления?
-
Важна ли производительность?
5. Программа
выполняется на сильно загруженном
оборудо-
вании?
-
Требуется ли оперативный ввод данных?
-
Используется много форм для ввода данных?
-
Поля базы данных обновляются оперативно?
-
Ввод, вывод, запросы являются сложными?
-
Внутренние вычисления сложны?
-
Код предназначен для повторного использования?
-
Требуется преобразование данных и установка программы?
-
Требуется много установок в различных организациях?
14. Требуется
поддерживать возможность настройки и
про-
стоту использования?
Значения для данных характеристик определяются следующим образом: 0 — никогда; 1 — иногда; 2 — редко; 3 — средне; 4 — часто; 5 — всегда.
Эти характеристики для примера функции сведены в табл. 9.3.
Определяется 5 — сумма всех весов.
И наконец, уточненный функциональный размер вычисляется по формуле
УФР = ФР х (0,65 + 0,01 х 5). (9.3)
Уточненный функциональный размер функции выбор метода будет следующим:
УФР = 26х (0,65 + 0,01 х 29)= 17,19.
Получившийся результат показывает, что функция выбор метода достаточно проста и не требует больших трудозатрат. Полученные значения затем используются для оценки стоимости проекта.
В настоящее время существует несколько модификаций метода функциональных точек [57].
Точки свойств
В случае, если вышеописанные характеристики не отражают истинной сложности реализации (например, при разработке операционных систем), вместо метода функциональных точек применяют его усовершенствованный вариант, предложенный в 1988 г. Кейперсом Джонсом, — метод точек свойств. Этот метод корректирует оценки, полученные методом функциональных точек с учетом алгоритмической сложности программного продукта.
Метод Mark II
Метод Mark II был представлен Чарльзом Саймонсом также в 1988 г. Этот метод более пригоден для оценки сложных систем, чем классический метод функциональных точек. Он позволяет добиться одного и того же результата как при оценке системы в целом, так и при суммировании оценок, полученных для составляющих ее подсистем.
Трехмерные функциональные точки
В 1991 г. софтверным подразделением корпорации Boeing было предложено еще одно решение — метод трехмерных функциональных точек. Отличием от классического метода является то, что сложность программного продукта оценивается по трем направлениям — данные, функции и управление. Достоинством метода является его применимость не только к оценке программных проектов, но и к оценке трудоемкости задач в других сферах деятельности.
Объектные точки
Метод объектных точек адаптирует оригинальный метод функциональных точек к объектно-ориентированной технологии программирования.
Р./.3. Оценка с использованием эмпирических данных
Альтернативой методам, описанным выше, являются методы, основанные на уже имеющемся опыте, которые позволяют добиться хороших результатов при относительно невысоких затратах.
Метод Демарко
Метод, разработанный Томом Демарко в 1982 г., основан на использовании так называемой «бэнг-метрики». Этот простой, но эффективный подход к оценке стоимости ПО, близок по содержанию к методу функциональных точек с тем отличием, что полученные оценки корректируются с учетом хронологических данных по выполненным ранее проектам. Такой подход позволяет получить не абстрактные показатели, а приближенные значения реальных затрат ресурсов и времени.
SLIM
В 1978 г. Лоуренс Патнам предложил нелинейную модель, использующую эмпирические данные при оценке стоимости ПО — SLIM (Software Life-cycle Model). Данная методика, созданная на основе реальных данных, собранных в Министерстве обороны США, предназначена для определения трудоемкости крупных программных проектов. Несмотря на то что широкого распространения эта модель не приобрела, некоторые фирмы до сих пор используют ее для расчета трудозатрат.
Согласно модели SLIM трудозатраты на разработку ПО вычисляются по следующей формуле: