Модели управления разработкой ПО
Введение в урок
В этом уроке вы узнаете, по каким принципам может быть устроено управление процессом разработки ПО и как это влияет на работу системного аналитика.
Классификация моделей управления разработкой ПО
Управление разработкой ПО — в основном задача менеджера. При этом все члены команды разработки должны понимать и принимать принятые принципы управления. Так уменьшится недопонимание, повысится эффективность совместной работы — команда будет чётко знать, в какой точке сейчас находится, и в итоге сможет достичь поставленных целей.
Модели управления разработкой ПО можно классифицировать по глубине планирования:
- Каскадная модель. Позволяет планировать реализацию сразу всего проекта.
- Метод набегающей волны. Позволяет составлять примерный план на весь проект и детальный план на ближайший период.
- Гибкие методологии. Позволяют планировать только на ближайший период.
Работа системного аналитика в каждой из этих моделей выстраивается по-разному, поэтому мы рассмотрим их особенности подробнее.
Каскадная модель
Несмотря на сходство названия, каскадная модель управления разработкой ПО применяется не только в каскадной модели жизненного цикла. Её также можно применять в инкрементальном подходе итерационной модели.
В основе каскадной модели управления — «его величество план», который включает в себя задачи по реализации приложения и сроки их выполнения.
Как правило, подробный план появляется по завершении этапа анализа — сложно планировать что-либо детально, если ещё неизвестно, что должно делать программное обеспечение. Часто по завершении этапа проектирования план уточняют и корректируют, поскольку способ реализации может повлиять на длительность и трудоёмкость задач.
В ходе разработки требуется постоянный анализ: что нужно сделать по плану и что выполнено по факту. Если менеджер замечает, что команда отстаёт от плана, он принимает меры, чтобы нагнать упущенное, например, привлекает дополнительных специалистов, оптимизирует процессы, предлагает упростить функциональность.
Строительство многоквартирных домов, как правило, организовано по каскадной модели управления.
Всё начинается с анализа и определения того, какой дом необходимо построить (высотный или средней этажности, эконом или бизнес-класса), есть ли рядом с местом строительства магазины или их нужно запланировать на первом этаже здания. Затем наступает этап проектирования — разрабатывается проектно-сметная документация. По завершении этапа проектирования появляется подробный план и начинаются строительно-монтажные работы. Когда они закончатся, происходит приёмка. Когда дом принят, счастливые новосёлы получают ключи от своих квартир.
Особенности работы системного аналитика в каскадной модели управления:
- Задачи известны наперёд, а значит, системный аналитик всегда знает, что будет делать завтра или через неделю.
- Не придётся переключаться между разными типами задач — в любой момент времени работа однородна. Если проект находится на этапе анализа, системный аналитик занимается только анализом, если на этапе проектирования — только проектированием.
- Есть чёткий план работы, и нужно стараться ему следовать. Умение придерживаться плана — один из критериев качества работы системного аналитика в каскадной модели.
- Нагрузка распределяется неравномерно. При каскадной модели управления самые активные этапы для системного аналитика — анализ и проектирование. На следующих этапах его загруженность может снижаться.
Метод набегающей волны
Такая модель управления разработкой предполагает не один, а сразу два плана — долгосрочный (примерный план на весь проект) и краткосрочный (детальный план по текущим и будущим работам). При этом план всего проекта регулярно пересматривается и уточняется. Своё название эта модель управления разработкой получила по аналогии с движением волны: подобно тому, как волна набегает на берег, детализация «набегает» на примерный план всего проекта.
Метод набегающей волны может применяться в любой из итерационных моделей жизненного цикла ПО, но чаще его используют при инкрементальном подходе, когда известен требуемый результат, или при итеративно-инкрементальном, когда есть хотя бы общее представление о том, что нужно в итоге.
По методу набегающей волны проводят строительство жилых комплексов.
Для всего комплекса есть примерный план (например, проект планировки и межевания территории) и известны сроки строительства каждого дома с точностью до года. Это означает, что можно представить, к какому результату нужно прийти и в какой срок.
Первый дом жилого комплекса находится на этапе строительно-монтажных работ — по нему уже готов детальный план и известен срок сдачи.
На второй дом разрабатывается проектно-сметная документация, план ещё не такой детальный, но уже известны сроки сдачи с точностью до квартала.
Все остальные дома существуют только в общем примерном плане и конкретики по ним нет — только плановый год завершения строительства, который может меняться.
Особенности работы системного аналитика по методу набегающей волны:
- Основные задачи известны наперёд, но их могут разбавлять другие задачи. Они иногда появляются спонтанно.
- Работа не будет однородной. Часть функциональности приложения может быть ещё на этапе анализа, в то время как другая уже пойдёт в разработку. Тогда системному аналитику понадобится, например, метаться между сбором и анализом требований и ответами на вопросы разработчиков.
- Есть чёткий план ближайших работ, и нужно стараться ему следовать.
- Сравнительно равномерная загрузка на протяжении всего проекта — всегда есть чем заняться.
Гибкие методологии
В этой модели управления разработкой вообще нет плана на длительное время. Гибкие методологии можно применять в любой из итерационных моделей жизненного цикла ПО, но чаще всего их используют при итеративном и итеративно-инкрементальном подходах, где не до конца известен требуемый результат.
Как происходит планирование в гибких методологиях? Есть регулярно пополняемый и обновляемый список того, что хотелось бы сделать. На этапе планирования итерации из этого списка отбирают самое важное — что нужно сделать прямо сейчас. Команда занимается выбранным набором задач, а когда они выполнены, планируется следующая итерация. Как правило, итерация длится не более двух-трёх недель.
Можно ли построить дом по гибким методологиям? Скорее всего, да, но такая модель применима только для частного дома. Всё потому, что на строительство многоквартирных домов нужно получить разрешение, которое выдадут только при наличии подробной проектно-сметной документации. Для строительства дома на собственном участке такой детальный документ не требуется.
Как будут применяться гибкие методологии при строительстве частного дома? Есть общий список того, что нужно сделать, чтобы построить дом. Каждые две недели из него выбираются работы, которые уместно делать прямо сейчас:
— Если на дворе лето, лучше покрасить стены, поскольку краска высохнет быстрее.
— Если можно одолжить шуроповёрт и бетономешалку, стоит сделать электрическую проводку и залить отмостку.
— Если на хорошую черепицу сделали скидку, надо покрывать крышу и так далее.
В таком подходе может гибко меняться как последовательность работ, так и способы их реализации. Но есть риск, что получится что-то такое:
Особенности работы системного аналитика в гибких методологиях:
- Системный аналитик не знает, какой задачей будет заниматься через неделю, но может быть уверен в том, что это будет самая важная и нужная задача.
- Разнородная работа. В рамках итерации придётся заниматься сразу анализом, проектированием, обработкой макетов дизайнеров, обсуждением деталей реализации с разработчиками и тестировщиками.
- Равномерная загрузка на протяжении всего проекта — всегда есть чем заняться.