Что такое жизненный цикл программы в программировании

Обновлено: 07.07.2024

Жизненный цикл разработки ПО (англ. SDLC – Software development lifecycle) – это серия из шести фаз, через которые проходит любая программная система.

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

Но как это выглядит изнутри? С какими сложностями сталкивается команда разработчиков и как их решает на каждой фазе Жизненного Цикла ПО? Об этом расскажет Павел Гапонов, Project Manager компании-разработчика SolveIt.

Типичный жизненный цикл разработки состоит из следующих фаз:

1. Сбор и анализ требований (Planning and Requirement Analysis)

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

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

Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.

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

2. Документирование требований (Defining Requirements)

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

Важно четко определить и прописать, что требуется выполнить, это делается с помощью SRS (Software Requirement Specification). Документ содержит все требования к продукту, которые должны быть спроектированы и разработаны в течение жизненного цикла проекта.

Проблема: Большой многостраничный список требований

Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.

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

SRS это ориентир для разработчиков, чтобы предложить лучшую архитектуру для продукта. Обычно предлагается несколько подходов к проектированию архитектуры продукта. Все предложенные подходы документируются в спецификации DDS (Design Document Specification) и выбирается наилучший подход к проектированию. Данный подход очень четко определяет все архитектурные модули продукта, а также его связь с внешними и сторонними модулями.

Проблема: Выбрали неправильную архитектуру.

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

4. Разработка ПО (Building or Developing the Product)

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

Проблема №1: Слабая коммуникация между командой

Разработчик не интересуется прогрессом проекта, проблемами коллег.

Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).

Проблема №2: Невыполнимые сроки

Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.

Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.

Проблема №3: Добавление не оговоренных фич

99% заказчиков ошибаются именно в этом месте . В ходе разработки клиент отклоняется от оговоренного тз и хочет добавить ещё фич в продукт. В результате вместе с ростом скопа фич, увеличиваются сроки и бюджет на разработку, деньги заканчиваются, а готово только 50% продукта.

Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.

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

Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.

6. Внедрение и поддержка продукта (Deployment in the Market and Maintenance)

Как только продукт протестирован, он выходит в релиз. Иногда внедрение происходит поэтапно, в соответствии с бизнес-стратегией. Продукт сначала может быть выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, это UAT-тестирование (User Acceptance Testing). Затем, основываясь на отзывах, продукт может быть выпущен как есть, или с предлагаемыми улучшениями. После того, как продукт выпущен на рынок его обслуживание выполняется для существующей клиентской базы, и на этом этапе подключаются Support-команды.

Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.

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

Проблема №2: Слабая инфраструктура проекта на стороне клиента.

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

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

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

Если вам нужен качественный продукт, свяжитесь с нами и мы сделаем оценку вашего проекта!

Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC) — процесс, состоящий из конкретных этапов, который начинается в момент принятия решения о необходимости создания ПО и заканчивается в момент прекращения поддержки ПО разработчиками.

Применение SDLC позволяет:

  1. Визуализировать сложный процесс разработки
  2. Управлять проектом
  3. Предсказывать и планировать доставку рабочих продуктов в ходе всего процесса разработки
  4. Управлять рисками выхода за рамки бюджета / превышения срока реализации
  5. Быстро определять, на каком этапе находится разработка в данный момент

В статье рассмотрим основные этапы жизненного цикла разработки ПО (SDLC) и их предназначение.

Этапы жизненного цикла разработки ПО

Всего выделяют 7 основных этапов разработки [1]:

  1. Идея
  2. Определение требований
  3. Дизайн (архитектура) системы
  4. Разработка
  5. Тестирование
  6. Развертывание
  7. Поддержка

Этап закрытия представлен на изображении, но он не является обязательным и зависит от проекта.

Этап 1: Идея

Разработка любой системы или ПО начинается с генерации идей для решения какой-то конкретной проблемы пользователя.

Этот процесс может быть формальным (например, brainstorming в компании) или не формальным (например, за барной стойкой с друзьями).

Этап 2: Определение требований

На этом этапе “идея” принимает более осмысленный и конкретный вид.

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

Бизнес-аналитики (BA) прорабатывают полученную информацию, детализируют ее и преобразовывают в технические требования к системе. Эти требования называются Software Requirement Specification (SRS).

Кроме SRS на этом этапе:

  1. Определяются требования к качеству (SQA, Software Quality Attributes)
  2. Проводится анализ рисков (RA, Risk Analysis)
  3. Создаются планы валидации и верификации (V&V Plans, Test Plans)
  4. Определяются критерии приемки ПО (AC, Acceptance Criteria)

Этап 3: Дизайн (архитектура) системы

Дизайн - этап SDLC

Дизайн и архитектура системы в SDLC

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

В итоге определяется спецификация по дизайну (Design Document Specification, DDS) с описанием что и как нужно делать с технической точки зрения.

DDS может состоять их двух частей — высокоуровневый дизайн (High-Level Design, HLD) и низкоуровневый дизайн (Low-Level Design, LLD).

Этап 4: Разработка

Разработка - этап SDLC

Этап разработки в SDLC

Разработчики получают требования (SRS), спецификацию по дизайну (DDS) и создают требуемое ПО.

Этап 5: Тестирование

Тестирование - этап SDLC

Этап тестирования в SDLC

Тестировщики, основываясь на требованиях (SQA, SRS, DDS) и готовом продукте производят проверку качества ПО (Quality Control).

Если находятся отклонения от требований / ошибки — они оформляются в виде отчетов о дефектах, исправляются и перепроверяются.

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

Этап 6: Развертывание

Развертывание и запуск - этап SDLC

Этап развертывания и запуска системы в SDLC

После успешного тестирования готовый продукт передается заказчику.

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

Этап 7: Поддержка

Этап Поддержки в SDLC

Этап поддержки и работы системы в SDLC

После запуска продукта он начинает развиваться, изменяться, дополняться новыми функциями.

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

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

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

Именно на этом этапе умирает большинство стартапов.

Дополнительный этап: Закрытие

Закрытие - этап SDLC

Этап закрытия и остановки системы в SDLC

Закрытие — последний этап жизни ПО. На нем происходит вывод продукта из эксплуатации, его замена на современные аналоги, либо новые версии.

Как пример, можно вспомнить браузер Internet Explorer (был замен на Edge) или Windows XP (заменена на Windows 7).

Длительность разработки ПО

Для простых проектов разработка длится несколько месяцев (например, не “взлетевшие” стартапы, небольшие сайты, и т.п.).

Для сложных — более 15 лет (например, ПО для космических аппаратов).

Но, для большинства проектов, активная разработка продолжается на протяжении 6-8 лет. [2]

Учитывайте это, когда устраиваетесь на работу 🙂

Резюме

В статье мы разобрались, что такое жизненный цикл разработки ПО (SDLC), рассмотрели его этапы и их особенности.

Мы поняли, что создание программного обеспечения — это не только написание кода. В этот процесс входит много подготовительной (анализ, создание требований) и дополнительной работы (тестирования, разворачивание), а самым важным этапом является поддержка.

Далее, можем рассмотреть методологии разработки ПО которые реализуют этапы жизненного цикла ПО.

Что такое SDLC?

Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC) — процесс, состоящий из конкретных этапов, который начинается в момент принятия решения о необходимости создания программного продукта и заканчивается в момент прекращения поддержки ПО разработчиками.

Какие основные этапы SDLC?

Основными этапами SDLC являются:
1. Идея
2. Определение требований
3. Дизайн (архитектура) системы
4. Разработка
5. Тестирование
6. Развертывание
7. Поддержка (самый важный этап)

Модели Жизненного цикла программного обеспечения

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

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

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

Жизненный цикл традиционно разделяют на следующие основные этапы :

  1. Анализ требований,
  2. Проектирование,
  3. Кодирование (программирование),
  4. Тестирование и отладка,
  5. Эксплуатация и сопровождение.
  • стабильность требований в течение всего жизненного цикла разработки;
  • на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
  • определенность и понятность шагов модели и простота её применения;
  • выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие ресурсы (денежные. материальные и людские).

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

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

Область применения Каскадной модели

Ограничение области применения каскадной модели определяется её недостатками. Её использование наиболее эффективно в следующих случаях:

  1. при разработке проектов с четкими, неизменяемыми в течение жизненного цикла требованиями, понятными реализацией и техническими методиками;
  2. при разработке проекта, ориентированного на построение системы или продукта такого же типа, как уже разрабатывались разработчиками ранее;
  3. при разработке проекта, связанного с созданием и выпуском новой версии уже существующего продукта или системы;
  4. при разработке проекта, связанного с переносом уже существующего продукта или системы на новую платформу;
  5. при выполнении больших проектов, в которых задействовано несколько больших команд разработчиков.

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

(поэтапная модель с промежуточным контролем)

Поэтапная модель с промежуточным контролем

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

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

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

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

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

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

Спиральная модель жизненного цикла

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

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

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

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации [1] . Этот цикл — процесс построения и развития ПО.

Содержание

Стандарты жизненного цикла ПО

  • ГОСТ 34.601-90
  • ISO/IEC 12207:1995 (российский аналог — ГОСТ Р ИСО/МЭК 12207-99)

Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

  1. Формирование требований к АС
    1. Обследование объекта и обоснование необходимости создания АС
    2. Формирование требований пользователя к АС
    3. Оформление отчета о выполнении работ и заявки на разработку АС
    1. Изучение объекта
    2. Проведение необходимых научно-исследовательских работ
    3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
    4. Оформление отчета о проделанной работе
    1. Разработка и утверждение технического задания на создание АС
    1. Разработка предварительных проектных решений по системе и ее частям
    2. Разработка документации на АС и ее части
    1. Разработка проектных решений по системе и ее частям
    2. Разработка документации на АС и ее части
    3. Разработка и оформление документации на поставку комплектующих изделий
    4. Разработка заданий на проектирование в смежных частях проекта
    1. Разработка рабочей документации на АС и ее части
    2. Разработка и адаптация программ
    1. Подготовка объекта автоматизации
    2. Подготовка персонала
    3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
    4. Строительно-монтажные работы
    5. Пусконаладочные работы
    6. Проведение предварительных испытаний
    7. Проведение опытной эксплуатации
    8. Проведение приемочных испытаний
    1. Выполнение работ в соответствии с гарантийными обязательствами
    2. Послегарантийное обслуживание

    Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

    Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)

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

    Процессы жизненного цикла ПО

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

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


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

    1. Инициирование приобретения
    2. Подготовка заявочных предложений
    3. Подготовка и корректировка договора
    4. Надзор за деятельностью поставщика
    5. Приемка и завершение работ

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

    Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

    Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

    Модель ЖЦ ПО включает в себя:

    1. Стадии;
    2. Результаты выполнения работ на каждой стадии;
    3. Ключевые события — точки завершения работ и принятия решений.

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

    На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

    Модели жизненного цикла ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Читайте также: