Необходимость понятия жизненного цикла разработки связана с тем что
Что такое Жизненный Цикл Разработки ПО и какие проблемы возникают на каждом этапе SDLC?
Жизненный цикл разработки ПО (англ. SDLC – Software development lifecycle) – это серия из шести фаз, через которые проходит любая программная система.
Абсолютно любое ПО проходит через 6 основных шагов, начиная от простой идеи и заканчивая использованием её конечным пользователем.
Но как это выглядит изнутри? С какими сложностями сталкивается команда разработчиков и как их решает на каждой фазе Жизненного Цикла ПО? Об этом расскажет Павел Гапонов, Project Manager компании-разработчика SolveIt.
Типичный жизненный цикл разработки состоит из следующих фаз:
Это, пожалуй самый ответственный и важный из всех шагов к созданию успешной программной системы. Вся собранная информация используется для планирования базового проектного подхода.
Дополнительно идет планирование требований по обеспечению качества и выявления различных рисков, связанных с проектом. Результатом анализа является определение различных технических подходов, которые можно использовать для успешной реализации проекта с минимальными рисками. Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода ко второму этапу.
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
Как только базовый анализ требований будет выполнен, следующим шагом будет четкое определение и документирование требований к продукту, утверждение со стороны клиента. Если одной из целей первого этапа является понимание и анализ требований, то на этом этапе все цели должны быть прописаны, это защита обеих сторон.
Важно четко определить и прописать, что требуется выполнить, это делается с помощью SRS (Software Requirement Specification). Документ содержит все требования к продукту, которые должны быть спроектированы и разработаны в течение жизненного цикла проекта.
Проблема: Большой многостраничный список требований
Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.
В SolveIt мы всегда стараемся быть гибкими и подстраиваться под клиента. Работающий продукт важнее исчерпывающей документации.
SRS это ориентир для разработчиков, чтобы предложить лучшую архитектуру для продукта. Обычно предлагается несколько подходов к проектированию архитектуры продукта. Все предложенные подходы документируются в спецификации DDS (Design Document Specification) и выбирается наилучший подход к проектированию. Данный подход очень четко определяет все архитектурные модули продукта, а также его связь с внешними и сторонними модулями.
Проблема: Выбрали неправильную архитектуру.
Решение: Наличие в команде разработчиков опытных лидов, которые смогли бы предложить подходящую архитектуру, на основе своего успешного опыта в схожих проектах.
Здесь начинается разработка и сборка продукта. Весь программный код, новые модули и фичи разрабатываются на основании DDS. Чем лучше написана эта документация, тем быстрее будет идти имплементация. На этом этапе подключается команда разработчиков. Написанный код должен покрываться Unit-тестами, а взаимодействие новых фич с другими модулями тестироваться с помощью интеграционных тестов. Эти активности выполняются именно командой разработчиков, а не QA специалистами.
Проблема №1: Слабая коммуникация между командой
Разработчик не интересуется прогрессом проекта, проблемами коллег.
Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).
Проблема №2: Невыполнимые сроки
Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.
Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.
Проблема №3: Добавление не оговоренных фич
Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.
Именно тестирование, в основном, затрагивает все этапы жизненного цикла. Дефекты продукта регистрируются, отслеживаются, исправляются и повторно тестируются. Это происходит до тех пор, пока продукт не достигнет стандартов качества, которые прописаны в SRS. На данном этапе в процесс разработки подключается команда мануальных тестировщиков или автоматизаторы.
Проблема: Тратится слишком много времени на поиск причин багов. Попытки найти и исправить дефекты после завершения разработки – сложный процесс, который может привести к большому количеству исправлений.
Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.
Как только продукт протестирован, он выходит в релиз. Иногда внедрение происходит поэтапно, в соответствии с бизнес-стратегией. Продукт сначала может быть выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, это UAT-тестирование (User Acceptance Testing). Затем, основываясь на отзывах, продукт может быть выпущен как есть, или с предлагаемыми улучшениями. После того, как продукт выпущен на рынок его обслуживание выполняется для существующей клиентской базы, и на этом этапе подключаются Support-команды.
Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.
Решение: Не ждать конца разработки, а как можно скорее запускать продукт, чтобы получить отзывы от реальных пользователей и на основе их предпочтений приоритезировать дальнейший функционал.
Проблема №2: Слабая инфраструктура проекта на стороне клиента.
Часть заказчиков предпочитают размещать сервера приложений не на Azure, AWS, Google и т.д, а в своей внутренней сети. Команда не может гарантировать стабильную работу, из-за сбоев, которые происходят на стороне клиента.
Решение: Предупредить клиента, о возможных проблемах, предложить решения для их устранения.
Если вам нужен качественный продукт, свяжитесь с нами и мы сделаем оценку вашего проекта!
Принципы построения системы деятельностей программного проекта
Системы и элементы проектных деятельностей
Динамика — одна из основных характеристик процесса развития проекта, которая наряду с разбиением функций позволяет рассматривать проект как систему взаимосвязанных целенаправленных видов деятельности субъектов-исполнителей, выполняющих функции. С точки зрения теории деятельности каждая работа этой системы характеризуется следующими элементами.
Кратко: субъект — это тот, кто в состоянии выполнять данную деятельность.
Кратко: цель — это то, для чего данная деятельность выполняется.
Кратко: материалы и ресурсы — это то, из чего в данной деятельности продуцируются результаты.
Распределение ограниченных ресурсов — одна из основных задач управления проектом.
Средства и инструменты могут быть внешними по отношению к системе деятельностей проекта или могут разрабатываться в рамках проекта (он предусматривает включение в систему деятельности с соответствующими результатами). В последнем случае нужно различать ситуации, когда разработка ведется с расчетом на независимое использование вне проекта и когда внешнее применение создаваемых средств и инструментов не предполагается.
Кратко: средства и инструменты — это то, с помощью чего в данной деятельности продуцируются результаты.
Кратко: методы — это то, что указывает на способ выполнения данной деятельности.
Кратко: результат — это то, что фактически продуцируется в данной деятельности.
Введенные понятия сами по себе почти не связаны со спецификой разработки программного обеспечения. Эта специфика может проявиться при интерпретации системы деятельностей на данной предметной области. Что, собственно говоря, и является предметом обсуждения в данном курсе.
На абстрактном уровне деятельность выполнения любого программного проекта можно изобразить в виде схемы, представленной на рис. 4.1.
Схема взаимодействия процессов согласно PMBOK показана на рис. 4.2.
Жизненный цикл программного изделия и его модели
Из сказанного следует, что контрольные точки являются постоянной заботой менеджера проекта и моментами, когда интенсивность его работы возрастает. Вместе с тем определение контрольных точек — это элемент планирования, который находится в компетенции менеджера. В первую очередь планирования времени, а на базе его — распределения остальных ресурсов. Имеется определенная свобода в выборе этапов и контрольных точек, ограниченная обязательствами перед заказчиками, разработчиками, а также планировщиками компании. Это означает целесообразность приспособления этапов развития проекта к его специфике и к специфике условий выполнения задания.
Таким образом, в рамках обсуждения менеджмента программных проектов вопросы жизненного цикла должны рассматриваться как первостепенные. В этой и последующих лекциях они разбираются в той мере, которой достаточно для самостоятельного изучения конкретных подходов и методов, рекомендуемых для применения при производстве программных систем.
Мотивация изучения жизненного цикла и его моделей
Еще хуже, когда работа над проектами не подчиняется заранее оговоренным регламентам, т.е. используемая методология складывается стихийно. В этом случае у разработчиков нет оснований для самоограничения, и переход к стандартизованным приемам и методам, который объективно необходим, может стать болезненным до такой степени, что продуктивная совместная работа коллектива окажется невозможной.
Сгладить указанные противоречия можно только путем изучения различных подходов к разработке программного обеспечения и, в частности, различных вариантов моделей жизненного цикла и их мотиваций.