Interested Article - Процесс разработки программного обеспечения

Разработка программного обеспечения
Ключевые процессы
Парадигмы и модели
Методологии
Инструменты

Процесс разработки программного обеспечения ( англ. software development process ) — процесс, посредством которого потребности пользователей преобразуются в программный продукт . Процесс разработки программного обеспечения является составной частью программной инженерии .

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

Подпроцессы

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

Модели процесса

Модель жизненного цикла — структура процессов и действий, связанных с жизненным циклом, организуемых в стадии .

Водопадная (каскадная, последовательная) модель

Водопадная модель жизненного цикла ( англ. waterfall model ) была описана Уинстоном Ройсом в статье " Managing the Development of Large Software Systems " в 1970 г. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

  1. Формирование требований;
  2. Проектирование;
  3. Реализация;
  4. Тестирование;
  5. Внедрение;
  6. Эксплуатация и сопровождение.

Преимущества :

  • Полная и согласованная документация на каждом этапе;
  • Легко определить сроки и затраты на проект.

Недостатки :

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

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

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки ( англ. iterative and incremental development, IID ), получившей также от Т. Гилба в 70-е гг. название эволюционной модели . Также эту модель называют итеративной моделью и инкрементальной моделью .

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

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

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно висит ощущение, что «всё равно всё можно будет переделать и улучшить позже» .

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки ( RUP , MSF , XP ).

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

Спиральная модель ( англ. spiral model ) была разработана в середине 1980-х годов Барри Боэмом . Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования .

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

На каждой итерации оцениваются:

  • риск превышения сроков и стоимости проекта;
  • необходимость выполнения ещё одной итерации;
  • степень полноты и точности понимания требований к системе;
  • целесообразность прекращения проекта.

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

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

  1. Дефицит специалистов.
  2. Нереалистичные сроки и бюджет.
  3. Реализация несоответствующей функциональности.
  4. Разработка неправильного пользовательского интерфейса.
  5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
  6. Непрекращающийся поток изменений.
  7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
  8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
  9. Недостаточная производительность получаемой системы.
  10. Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек :

  1. Concept of Operations (COO) — концепция (использования) системы;
  2. Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;
  3. Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
  4. Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;
  5. Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Примечания

  1. Software development process // ISO /IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary:
    the process by which user needs are translated into a software product
  2. ГОСТ Р ИСО/МЭК 12207-2010 Процессы жизненного цикла программных средств
  3. Брукс Ф. Мифический человеко-месяц или как создаются программные системы : пер. с англ. / Ф. Брукс. — Санкт-Петербург : Символ-Плюс, 1999. — 304 с.: ил.
  4. Мирошниченко Е. А. Технологии программирования: учебное пособие / Е. А. Мирошниченко. — 2-е изд., испр. и доп. — Томск: Изд-во Томского политехнического университета, 2008. — 128 с.
  5. Ларман К. от 13 октября 2016 на Wayback Machine / К. Ларман, В. Базили // Открытые системы. — 2003.— N 9.
  6. Орлик С. Введение в программную инженерию и управление жизненным циклом ПО. от 17 ноября 2015 на Wayback Machine

Литература

  • Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504—СММ). — М. : Книга и бизнес, 2001. — 348 с. — ISBN 5-212-00884-0 .
  • ACM , IEEE . (англ.) / ACM Computing Curricula Task Force. — ACM, Inc, 2013. — ISBN 978-1-4503-2309-3 .
  • ACM , IEEE . (англ.) . — ACM, 2015.


Источник —

Same as Процесс разработки программного обеспечения