Файл: Модели разработки.pdf

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

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

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

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

Прототипы не обязательно должны быть исполняемыми, чтобы быть полезными. Бумажные макеты пользовательского интерфейса^{^[11]} могут быть эффективными, помогая пользователям усовершенствовать дизайн интерфейса и прорабатывать сценарии использования. Они очень дешевы в разработке и могут быть построены в течении нескольких дней. Одним из расширений этого метода является прототип “Волшебника страны Оз”, в котором разрабатывается только пользовательский интерфейс. Пользователи взаимодействуют с этим интерфейсом, но их запросы не обрабатываются программно, а передаются человеку, который их интерпретирует и выдает соответствующий ответ.

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

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

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

Поэтапная доставка имеет ряд преимуществ:

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

Тем не менее, есть у поэтапной доставки и недостатки:

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

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

Заключение

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

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

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