Yvision.kzYvision.kz
kk
Разное
Разное
399 773 постов41 подписчиков
Всяко-разно
1
05:14, 28 октября 2013

Разработка ПО: этапы, модели разработки

Разработка ПО. 1950-1980

Этап вплоть до конца 1970х годов можно считать «темными веками» индустрии разработки ПО. Особенностями данного периода ее развития являются:

▪    Общая неразвитость индустрии. Это вызвано несовершенством как технических средств, так и отсутствием теоретического базиса.

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

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

▪    Постановка задачи.

▪    Ее выполнение до получения требуемого результата.

▪    Если результат не удовлетворяет, возврат к первому шагу.

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

Также в 1976 году выходит ставшая классикой книга Брукса «Мифический человеко-месяц», которая не утратила своей актуальности и поныне, и всячески рекомендуется к прочтению.

Разработка ПО. 1980-1996

Данный период отрасли можно охарактеризовать как «осознание того, что так жить дальше нельзя». Аппаратные средства стали доступными как организациям, так и индивидуальным пользователям, что вызвало грандиозное увеличение объема рынка для программного обеспечения. И можно по праву назвать это время эпохой «триумфального шествия бизнес-приложений″. ПО стали «потреблять» не только в местах его разработки, что вызывало, ужесточение требований как к самому ПО, так и усложнению процесса разработки. Чаще всего часто заказчик располагался за сотни миль от места воплощения его идей в жизнь. Более того, разработчики перестали являться специалистами в предметной области заказчика (как это было ранее). Вместе с повышенной сложностью ПО и увеличившимися трудозатратами на его создание эти факторы привели к тому, что на выходе, после водопадной модели, чаще всего заказчик получал совсем не то, что ему нужно, и продукт отправлялся в мусорную корзину, а вместе с ним – и миллионы долларов.

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

Одновременно делается попытка приспособить существующие в промышленности стандарты качества для ИТ-индустрии. На западе – это стандарты ISO, в СССР – ГОСТы.

Разработка ПО. Современность

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

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

Итеративная модель была впервые предложена широким массам ИТ-специалистов компанией Rational (сейчас IBM), и является основой ее методологии RUP. Также она лежит в основе MSF (Microsoft Solutions Framework) и борландовской ALM (Application Lifecycle Management).

Подробнее…

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

- Водопадная (каскадная) модель;

- V-образная модель;

- Инкрементальная модель;

- Спиральная модель;

- Итеративная модель.

Каскадная модель

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

Рис. 1. Модифицированная каскадная модель предусматривала возможность возвращения к предыдущим этапам.

Blog post image

Спустя непродолжительное время после своего появления на свет каскадная модель была доработана Уинстом Ройсом с учетом взаимозависимости этапов и необходимости возврата на предыдущие ступени, что может быть вызвано, например, неполнотой требований или ошибками в формировании задания. В таком «обратимом» виде каскадная модель просуществовала долгое время и явилась основой для многих проектов (рис. 1).

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

V-образная модель

Была предложена именно для того, чтобы устранить недостатки каскадной модели, а название – V-образная, или шарнирная – появилось из-за ее специфического графического представления (рис. 2).

Рис. 2. V-образная модель позволяет гораздо лучше контролировать результат на предмет его соответствия ожиданиям, поскольку сфокусирована на тестировании.

Blog post image

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

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

Инкрементная модель

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

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

Спиральная модель

Предложенная Барри Боэмом в 1988 г., она стала существенным прорывом в понимании природы разработки ПО, хотя, по большому счету, является объединением двух моделей: каскадной и на основе создания прототипов (рис. 3).

Рис. 3. Спиральная модель Боэма объединяет каскадный подход и итерационный процесс проектирования на основе создания прототипов.

Blog post image

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

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

Итеративная модель

Впервые предложенная Филиппом Крачтеном в 1995 г., данная модель объединяет главные преимущества спиральной, инкрементной, каскадной моделей, а также методов разработки на основе создания прототипов и объектно-ориентированного подхода (рис. 4). Она завоевала большую популярность и в том или ином виде используется во многих современных проектах.

Рис. 4. Итеративная модель предлагает использование итераций на всех этапах жизненного цикла.

Blog post image

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

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

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

 
1
2137
0