Что такое SDLC и как он может вам помочь?

ИТ-индустрия наводнена аббревиатурами.

Даже само название отрасли является аббревиатурой. Что я нформация T ехнологии даже средний, на самом деле ?

Но я отвлекся. Давайте выясним настоящую причину, по которой вы здесь.

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

Итак… что такое SDLC?

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

Похлопайте себя по спине, опытный инженер

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

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

Бьюсь об заклад, если бы я нажал на вас, вы могли бы сами назвать все эти фазы. Но расслабься хоть раз и позволь мне сделать здесь тяжелую работу.

Каковы этапы жизненного цикла разработки программного обеспечения?

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

Планирование

Это часть каждого проекта, в котором я лично застреваю. Потому что интересно делать наброски или генерировать идеи, которые вы, вероятно, никогда не будете использовать, вместо того, чтобы выполнять реальную работу!

Когда я думаю о совершенно бесполезной идее

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

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

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

Ваши следующие действия могут выглядеть так:

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

Этап планирования также включает в себя постановку задач и определение или согласование сроков завершения проекта.

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

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

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

Почему этот этап важен

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

Определение

Фаза определения SDLC - это момент, когда вы берете все утвержденные требования и документируете их. (Документирование будет постоянной, повторяющейся фазой SDLC. Вы должны документировать все, что делаете, чтобы знать, что вы сделали, как вы это сделали и когда вы это сделали.)

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

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

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

Почему этот этап важен

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

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

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

Ты на все смотришь, да!

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

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

Почему этот этап важен

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

Строительство

Фаза построения - это часть, в которой вы выполняете всю работу, о которой так долго говорили на всех остальных этапах.

Вы приступаете к делу

Со всеми элементами, такими как ваши требования и одобренные дизайнерские идеи, вы теперь можете собрать что-то, что можно использовать и делать то, что нужно. Иди ты!

Это также самый сложный этап любого проекта разработки, поскольку именно здесь вы должны проверить все свои идеи.

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

Почему этот этап важен

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

Тестирование

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

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

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

При тестировании нужно пройти через все гипотезы.

Почему этот этап важен

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

Развертывание

Да да! Вы готовы к запуску!

Ты сделал это! Вы протестировали свои прототипы и можете кое-что представить своему клиенту.

Что вы чувствуете, когда закончили проект

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

Почему этот этап важен

Это та часть, где ваш конечный продукт встречается в реальной жизни! На данный момент вы и ваша команда изучали эту систему так долго, что не понимаете, каково это - впервые с ней взаимодействовать. Люди, которые будут использовать систему каждый день, могут дать вам честную обратную связь о том, создали ли вы высококачественный продукт и есть ли возможности для улучшения.

Обслуживание

Важно отметить, что ваша работа в качестве разработчика программного обеспечения не заканчивается после окончательного срока или после запуска продукта.

Это твоя жизнь сейчас

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

Если вы создали программное обеспечение для клиента, убедитесь, что условия обслуживания системы четко определены. Получите ли вы оплату за поддержание системы или обслуживание включено? Отвечает ли техническая команда клиента за внедрение обновлений? Может ли клиент позвонить вам в 2 часа ночи, если система не работает?

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

Почему этот этап важен

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

Как вы должны продвигать свой проект через SDLC?

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

Ниже мы рассмотрим некоторые из наиболее распространенных методов управления проектами при разработке программного обеспечения.

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

Поэкспериментируйте, чтобы увидеть, какой из этих методов лучше всего подходит для вас. Или, черт возьми, придумайте свою версию. Мир это твоя устрица! Ты сам отвечаешь за свою судьбу!

Гибкий

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

Вы можете спросить себя: «Разве это не отменяет всю идею SDLC? Неужели я зря потратил время на чтение всей этой глупой статьи? »

На что я говорю: «Нет!»

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

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

Однако методология Agile основана на постоянном сотрудничестве и общении как внутри вашей команды, так и с вашими клиентами.

Agile в работе

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

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

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

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

Недостатки Agile

• Отсутствие жесткого плана может привести к срыву сроков реализации проекта.
• Снижение акцента на планировании может привести к нечеткому пути к готовому продукту.

Водопад

Методология Waterfall почти полная противоположность методологии Agile. Огромный упор делается на планирование и дизайн еще до того, как вы начнете создавать свое программное обеспечение.

В режиме водопада вы следуете жестко структурированному плану и временной шкале. В то время как в Agile вы можете очень плавно перемещаться по фазам, создавая план дизайна для одной функции при кодировании другой, в Waterfall вы можете перейти к шагу B только после завершения шага A.

Что скажет ваш менеджер после того, как вы закончите Шаг А!

В этом случае вы будете проходить этапы SDLC в основном в том же порядке, в каком я их перечислял, редко переходя к фазе не по порядку.

Преимущества водопада

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

Недостатки водопада

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

Большой взрыв

Существует множество вариаций методологий Waterfall и Agile. Но есть еще больше вариаций методологии Большого взрыва.

Это потому, что методология Большого взрыва в основном означает отсутствие плана.

Все, что связано с методологией Большого взрыва

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

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

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

Вы можете создавать продукт поэтапно и представлять детали своему клиенту, как в случае с Agile. Или вы можете просто попытаться создать конечный продукт и вернуться к клиенту только тогда, когда он будет готов.

Big Bang - это методология, основанная на разбивке по ходу дела. Вы можете проходить этапы SDLC в любом порядке и уделять каждому этапу столько времени, сколько у вас есть. Но, в конце концов, хороший программный продукт прошел все этапы SDLC, независимо от того, в каком порядке они выполняются.

Преимущества большого взрыва

• Не нужно соблюдать правила!
• Работает с небольшими проектами, которые могут не нуждаться в тщательном планировании

Недостатки Big Bang

• Может легко дезорганизоваться
• Очень высокий риск сбиться с пути

Дополнительные инструменты для ваших проектов по разработке программного обеспечения

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

• Для тех, кто не уверен, какая методология лучше: Agile Vs Waterfall: Showdown for Software Development Domination
• Для менеджеров проектов, отвечающих за новичков: 5 способов научить вашу техническую команду методологии Agile
• Для удаленных Agile-команд: 5 предупреждающих сигналов о том, что ваша виртуальная команда не работает
• Когда вы достигли этапа тестирования или обслуживания: 8 лучших бесплатных программных решений для отслеживания ошибок с открытым исходным кодом
• Для ИТ-менеджеров, стремящихся улучшить командную работу: 10 фундаментальных книг для повышения ваших навыков ИТ-лидерства

Послушаем разработчиков!

Для тех из вас, кто прошел через этапы SDLC, где вы столкнулись с самыми сложными соперниками? Что вам больше всего нравится в проектах разработки? Какую методологию управления проектами вы предпочитаете?

Дай мне знать в комментариях!