ПРОЦЕСС РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

Модель зрелости возможностей CMM является одной из ведущих моделей. CMM постепенно заменило CMMI. ISO 9000 описывает стандарты для процессов с документацией. ISO 15504, также известный как определение возможностей процесса разработки программного обеспечения SPICE, является «основой для оценки программных процессов». Этот стандарт, направлен на создание четкой модели для сравнения процессов. SPICE используется так же, как CMM и CMMI. Он моделирует процессы управления, контроля, руководства и мониторинга программного обеспечения.

Six Sigma - это методология управления вариациями процесса, которая использует статистические данные для анализа измерения и повышения эффективности работы компании.

Основные этапы разработки программного обеспечения

Анализ домена. Часто, первый шаг в попытке разработать новую часть программного обеспечения, будь то дополнение к существующему программному продукту или новая система, это то, что обычно называют «Domain Analysis». Первая задача - исследовать так называемый «домен» программного обеспечения. Чем больше разработчики осведомлены о домене, тем меньше требуется над ним работать. Эта фаза является важной частью к извлечению и сбору требований.

Анализ элементов программного обеспечения

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

Спецификация

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

Архитектура программного обеспечения

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

Тестирование

Тестирование частей программного обеспечения, особенно если над проектом работало нескольких программистов, приходится на инженера-программиста.

Документация

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

Обслуживание

Поддержание и совершенствование программного обеспечения, для решения новых проблем или новых требований, может занять гораздо больше времени, чем первоначальная разработка программного обеспечения, поэтому около 60% всей работы по разработке программного обеспечения - это обслуживание, но это не всегда так. Небольшая часть этого - исправление ошибок. Обслуживания также служит для расширения системы.

Модель жизненного цикла программного обеспечения характеризует подход команды к разработке программного продукта. Она отражает акценты и приоритеты во всём процессе изготовления программы, а самое главное, порядок следования этапов создания программных продуктов [2].

Водопадные процессы

Самый известный и самый старый процесс - это модель водопада, где разработчики выполняют следующее:

• государственные требования

• анализ требований

• разработка подхода к решению проблемы

• создание программной среды для этого решения

• разработка кода

• тестирование

• развертывание

• реализация.

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

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

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

Итерационные процессы

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

Список литературы:

1. Процесс разработки программного обеспечения [Электронный ресурс] - Режим доступа. - URL: https://goo.gl/AjEQMP (дата обращения: 04.06.18).
2. Технология разработки программного обеспечения [Электронный ресурс] – Режим доступа. – URL: https://goo.gl/8xbM4B (дата обращения: 04.06.18).