Какой этап жизненного цикла по завершается оформлением протокола тестирования

Обновлено: 28.06.2024

1. Тестирование ПО и его связь с жизненным циклом ПО

2. Цикл разработки ПО

3. Жизненный цикл ПО

Формирование и анализ требований
Проектирование
Реализация
Тестирование продукта
Внедрение
Эксплуатация и сопровождение

4. Когда начать тестировать?

5. Формирование и анализ требований

Тестирование требований на вменяемость/
осуществимость
Тестирование функциональной спецификации
Создание предварительных тестовых сценариев
на основе требований

6. Проектирование

Тестирование документов, описывающих
архитектуру (product architecture) и дизайн
(product design)
Тестирование плана проекта

7. Реализация

Тестирования кода и модульное тестирование
Тестирование результатов итерации разработки
Регрессионное тестирование

8. Тестирование продукта

9. Внедрение

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

10. Эксплуатация и сопровождение

Обработка отчетов об ошибках от пользователей
во время эксплуатации
Верификация исправления ошибок
Обработка запросов новой функциональности
Тестирование новой функциональности

11. Когда прекращать тестирование?

12. Эвристики

13. Эвристики

14. Эвристики

Эвристика пиньяты (The Piñata Heuristic). Мы
прекращаем ломать программу, когда начинают
выпадать конфеты – мы останавливаем
тестирование, когда видим первую достаточно
серьезную проблему.
Пиньята (исп. Piñata) — мексиканская по происхождению полая игрушка довольно крупных размеров, изготовленная из папьемаше или лёгкой обёрточной бумаги с орнаментом и украшениями. Своей формой пиньята воспроизводит фигуры животных
(обычно лошадей) или геометрические фигуры, которые наполняются различными угощениями или сюрпризами для детей
(конфеты, хлопушки, игрушки, конфетти, орехи и т. п.)

15. Эвристики

16. Эвристики

17. Эвристики

18. Эвристики

19. Эвристики

20. Эвристики

21. Эвристики

22. Эвристики

Больше нет интересных вопросов (No more
interesting questions). В этот момент мы решаем, что не
осталось вопросов, ответы на которые были бы
достаточно ценными, чтобы оправдать стоимость
продолжения тестирования, и поэтому мы
останавливаемся. Эта эвристика используется в
основном как дополнение к другим эвристикам,
помогая принять решение о том, есть ли какие-то
вопросы или риски, которые отменяют действие этих
эвристик. Кроме того, если одна эвристика советует
нам прекратить тестирование, следует проверить, нет
ли интересных вопросов или серьезных рисков в
других областях, и если они есть, то мы скорее
продолжим тестирование, чем остановимся.

23. Эвристики

Эвристика уклонения/безразличия (The
Avoidance/Indifference Heuristic). Иногда людей не
интересует дополнительная информация, либо они не
хотят знать, что происходит в программе. Тестируемое
приложение может быть первой версией, которую,
как мы знаем, скоро заменят. Некоторые люди
прекращают тестирование по причине лени, злого
умысла или отсутствия мотивации. Иногда бизнескритичность выпуска нового релиза настолько высока,
что никакая мыслимая проблема не остановит выход
программы, и поэтому никакие новые результаты
тестирования не будут иметь значения.

24. Методологии разработки

25. Основная задача методологий

Быстрота выполнения работ и четкая
координация команд
Качественное исполнение и контроль качества
Сокращение издержек

27. Методология описывает

28. Типичные роли

Руководитель проекта (Project Manager)
Архитектор (Architect/Designer)
Бизнес-аналитик (Business Analyst)
Разработчик (Developer)
Тестировщик (Test Engineer/Tester)

29. Waterfall

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

30. Waterfall

31. Waterfall

32. Waterfall

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

33. Agile

Гибкая методология разработки (англ. Agile
software development, agile-методы) — серия
подходов к разработке программного
обеспечения, ориентированных на использование
итеративной разработки, динамическое
формирование требований и обеспечение их
реализации в результате постоянного
взаимодействия внутри самоорганизующихся
рабочих групп, состоящих из специалистов
различного профиля.

34. Agile

35. Agile

36. Преимущества итеративного подхода

Снижение воздействия серьёзных рисков на ранних стадиях проекта, что
ведет к минимизации затрат на их устранение
Организация эффективной обратной связи проектной команды с
потребителем (а также заказчиками) и создание продукта, реально
отвечающего его потребностям
Акцент усилий на наиболее важные и критичные направления проекта
Непрерывное итеративное тестирование, позволяющее оценить
успешность всего проекта в целом
Раннее обнаружение конфликтов между требованиями, моделями и
реализацией проекта
Более равномерная загрузка участников проекта
Эффективное использование накопленного опыта
Реальная оценка текущего состояния проекта и, как следствие, большая
уверенность заказчиков и непосредственных участников в его успешном
завершении
Затраты распределяются по всему проекту, а не группируются в его
конце

37. Принципы Agile

38. Agile-манифест

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

39. Пояснение принципов Agile-манифеста

Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного
обеспечения
Приветствие изменений требований даже в конце разработки (это может повысить
конкурентоспособность полученного продукта)
Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё
чаще)
Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта
Проектом занимаются мотивированные личности, которые обеспечены нужными условиями
работы, поддержкой и доверием
Рекомендуемый метод передачи информации — личный разговор (лицом к лицу)
Работающее программное обеспечение — лучший измеритель прогресса
Спонсоры, разработчики и пользователи должны иметь возможность поддерживать
постоянный темп на неопределённый срок
Постоянное внимание улучшению технического мастерства и удобному дизайну
Простота — искусство не делать лишней работы
Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной
команды
Постоянная адаптация к изменяющимся обстоятельствам

40. Scrum

41. Scrum. Основные понятия

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

42. Scrum. Основные понятия

Спринт (Sprint) — итерация в скраме, в ходе
которой создаётся функциональный рост
программного обеспечения. Жёстко фиксирован
по времени. Длительность одного спринта от 2 до
4 недель.

43. Scrum. Основные понятия

44. Scrum. Основные понятия

Резерв спринта (Sprint backlog) — содержит
функциональность, выбранную владельцем
проекта из резерва проекта.
Все функции разбиты по задачам, каждая из
которых оценивается скрам-командой.
Каждый день команда оценивает объем работы,
который нужно проделать для завершения
спринта.

45. Scrum. Основные понятия

46. Scrum. Роли

47. Scrum. Роли

Пользователи (Users)
Клиенты, Продавцы (Stakeholders) — лица,
которые инициируют проект и для кого проект
будет приносить выгоду. Они вовлечены в скрам
только во время обзорного совещания по
спринту (Sprint Review).
Управляющие (Managers) — люди, которые
управляют персоналом.
Эксперты-консультанты (Consulting Experts)

50. Scrum. Встречи (Meetings)

Планирование спринта (Sprint Planning Meeting) Происходит в начале
новой итерации Спринта
Из резерва проекта выбираются задачи, обязательства по выполнению
которых за спринт принимает на себя команда
На основе выбранных задач создается резерв спринта. Каждая задача
оценивается в идеальных человеко-часах
Решение задачи не должно занимать более 12 часов или одного дня.
При необходимости задача разбивается на подзадачи
Обсуждается и определяется, каким образом будет реализован этот
объём работ
Продолжительность совещания ограничена сверху 4-8 часами в
зависимости от продолжительности итерации, опыта команды и т. п.
(первая часть совещания) Участвует владелец проекта и скрам команда:
выбирают задачи из резерва продукта
(вторая часть совещания) Участвует только команда: обсуждают
технические детали реализации, наполняют резерв спринта

51. Scrum. Встречи (Meetings)

52. Scrum. Встречи (Meetings)

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

53. Scrum. Встречи (Meetings)

Ретроспективное совещание (Retrospective meeting)
Проводится после завершения спринта:
Члены команды высказывают своё мнение о
прошедшем спринте.
Отвечают на два основных вопроса:
Что было сделано хорошо в прошедшем спринте?
Что надо улучшить в следующем спринте?
Выполняют улучшение процесса разработки
(решают вопросы и фиксируют удачные решения).
Ограничена одним—тремя часами.

Следует начать с определения, Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

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

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

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

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

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

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

Анализ требований,
Проектирование,
Кодирование (программирование),
Тестирование и отладка,
Эксплуатация и сопровождение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SDLC — Жизненный Цикл Разработки ПО

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

Идея
Определение требований
Дизайн (архитектура) системы
Разработка
Тестирование
Развертывание
Поддержка

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

Этап 1: Идея

Идея / Задумка — первый этап SDLC

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

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

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

Определение требований к системе — самый важный этап SDLC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

Что такое SDLC?

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

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