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

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

Анализ осуществимости

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

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

На основании описания проблемы во время предварительного анализа, разработчики определяют альтернативные решения. Для каждого предложенного решения оцениваются затраты и даты поставки.

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

1. Определение проблемы.

2. Альтернативные решения и ожидаемые от них преимущества.

3. Необходимые ресурсы, затраты и сроки поставки для каждого предложенного альтернативного решения.

Выявление, понимание и спецификация требований

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

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

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

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

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

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

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

Ниже приведен возможный перечень пунктов документа спецификации требований, который может быть руководством специалиста по программному обеспечению:

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

2.Функциональные требования. Описывают действия программного продукта, используя неформальные, полуформальные, формальные представления либо их комбинацию.

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

4.Требования к процессу разработки и сопровождения. Сюда входят процедуры управления качеством (в частности процедуры тестирования системы), приоритеты необходимых функций, возможные изменения процедур обслуживания системы и прочие требования.

Определение архитектуры программного обеспечения и рабочий проект

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

Кодирование и тестирование модулей

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

Сборка и системное тестирование

Интегрирование (сборка) заключается в компоновке программного приложения из набора отдельно разработанных и протестированных компонентов. Сборка не всегда рассматривается как операция, отдельная от кодирования. Фактически пошаговые разработки могут постепенно интегрировать и тестировать компоненты по мере их разработки. Несмотря на то, что два этих этапа можно объединить, они принципиально различаются по масштабу проблем, которые призваны решать: первая относится к локальному программированию, тогда как вторая — к программированию системы в целом.

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

Поставка, развертывание и сопровождение ПО

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

Техническое обслуживание заключается в исправлении ошибок, оставшихся в системе (корректирующее сопровождение), в адаптации приложения к изменениям внешней среды (настраивающее сопровождение), а также в совершенствовании, изменении или добавлении в программу новых функций и качеств (усовершенствующее сопровождение). Не стоит забывать, что цена сопровождения часто превышает 60 % от общей цены продукта и что до 20 % затрат на сопровождение составляет доля корректирующего и настраивающего сопровождения, а 50 % приходится на долю усовершенствующего сопровождения. На основании этой статистики можно сделать вывод о том, что развитие здесь, возможно, — более уместный термин, нежели сопровождение (хотя последний используется чаще).

Другой тип классификации затрат на сопровождение был описан в работе Линца (Lienz) и Свонсона (Swanson) в 1980 г. Их анализ показал, что порядка 42 % затрат относятся на внесение изменений в требования пользователей, 17 % — на изменение формата данных, 12 % — на устранение аварийных неполадок, 9 % — на отладку процедур, 6 % — на модификацию аппаратных средств, 5 % — на исправление документации, 4 % — на повышение производительности и остальное — на прочие причины.

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

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

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

- Подверженность изменениям — это характерное свойство любого программного продукта, однако поддерживать изменения в программных продуктах довольно сложно.

Контрольные вопросы

1. Что такое жизненный цикл ПО?

2. Какой нормативный документ регламентирует ЖЦ ПО?

3. На каких трех группах процессов базируется структура ЖЦ ПО?

4. Опишите процесс разработки ЖЦ ПО

5. Опишите процесс эксплуатации ЖЦ ПО

6. Опишите процесс управления проектом ЖЦ ПО

7. Опишите процесс управления конфигурацией ЖЦ ПО

8. Опишите этапы процесса проектирования ЖЦ ПО

9. Каким требованиям должна удовлетворять функциональная спецификация?

10. Опишите основные характеристики и структуру каскадной модели ЖЦ

11. Назовите недостатки каскадного подхода