Ваше полное руководство по разработке программного обеспечения на все случаи жизни
Опубликовано: 2020-08-13Насколько похожи заводской цех и офис разработчиков программного обеспечения?
Представьте себе комнату, полную программистов, печатающих код на своих компьютерах. Что, если вы относитесь к их продукции, как к собранным изделиям с заводской сборочной линии? Будут ли и здесь работать те вещи, которые максимизируют производство? Или процесс разработки больше похож на другие инженерные дисциплины?
Руководители проектов пытались решить эту проблему с самого начала разработки программного обеспечения. Из этих вопросов возникло определение жизненного цикла разработки программного обеспечения.
Что такое разработка программного обеспечения?
Это процесс создания программного обеспечения с нуля. Хотя написание кода является основной деятельностью, это гораздо больше.
Процесс разработки включает в себя создание идей и дизайн перед написанием кода. Планирование легко упустить из виду. Это не похоже на разработку, как написание кода. Тем не менее, ответы на важные вопросы в первую очередь укрепляют конечный продукт. Стоит ли продолжать проект? Если да, то как лучше всего это сделать? Какие функции необходимы и какие функции приятно иметь? Ответы дают проекту больше шансов на успех.
Хотя шаги постоянны, их применение варьируется. Причина, по которой разработка программного обеспечения является новой дисциплиной. Инженерные дисциплины имеют зрелую историю сотен лет. Разработка программного обеспечения восходит к концу 1940-х годов. Это все еще новая дисциплина. Гибкому методу всего 20 лет. Тем не менее, это одно из самых влиятельных событий в теории создания программного обеспечения. Несмотря на это, шесть этапов жизненного цикла разработки программного обеспечения являются общими для всех систем.
6 этапов жизненного цикла разработки программного обеспечения (SDLC)
Команда разработчиков может использовать жизненный цикл разработки программного обеспечения для всего проекта или одной функции. Эволюция использования SDLC заключалась в снижении риска за счет сокращения длины каждого шага. Через мгновение мы более подробно рассмотрим различные методологии. Во-первых, давайте рассмотрим сами шаги.
Кроме того, стоит отметить, что вы увидите варианты с точки зрения количества шагов или их названий. Иногда этапы объединяются, например, разработка и тестирование. В других случаях вы увидите, как один шаг делится на два, например, планирование становится планированием и анализом. В нашем случае мы будем придерживаться этих шести, поскольку они четко определяют фазы.

1. Планирование
Этап планирования является наиболее важным шагом. Заинтересованные стороны должны учитывать все, включая осуществимость самого проекта. Здесь можно убить весь проект. Здоровая организация предоставит возможность заинтересованным сторонам сделать это, если это необходимо. На этом этапе программисты будут менее вовлечены в корпоративную среду. На этом этапе владельцы продуктов, бизнес-аналитики и другие заинтересованные лица озвучивают свои потребности.
2. Дизайн
Этап планирования является наиболее важным шагом. Заинтересованные стороны должны учитывать все, включая осуществимость самого проекта. Здесь можно убить весь проект. Здоровая организация предоставит возможность заинтересованным сторонам сделать это, если это необходимо. На этом этапе программисты будут менее вовлечены в корпоративную среду. На этом этапе владельцы продуктов, бизнес-аналитики и другие заинтересованные лица озвучивают свои потребности.
3. Развитие
Этап проектирования также включает в себя дизайн пользовательского опыта (UX). Если в приложении есть какие-либо компоненты, ориентированные на пользователя, UX-дизайн является обязательным. Это включает в себя исследование пользователей путем наблюдения за тем, как реальные люди взаимодействуют с макетами продуктов. Причина, по которой это происходит на этапе проектирования, а не на этапе разработки, заключается во времени. Сеансы пользователей требуют времени. Часто на основе собранных данных также происходит более активное обсуждение с заинтересованными сторонами бизнеса.
4. Тестирование
Затем команда разработчиков тестирует код. Кодрайтер и тестировщик должны быть разными людьми. Еще лучше — тестер обеспечения качества, не являющийся разработчиком. Разработчики склонны думать только о сценариях счастливого пути. Специалисты по тестированию QA, как правило, лучше думают о том, как они могут сломать программное обеспечение. Таким образом, у них больше шансов найти ошибки до развертывания. Результатом является более стабильное программное обеспечение при выпуске.
Автоматическое и ручное тестирование
Модульные тесты и интеграционные тесты часто автоматизированы. Часто платформа DevOps запускает эти тесты для нового кода перед его слиянием с основной ветвью.
Ручное тестирование далеко не устарело. Автоматические тесты делают одно и то же снова и снова. Тем не менее человек, занимающийся ручным тестированием, может случайно найти ошибки во время тестирования. В вариативности ручного тестирования заключается его сила.
Модульное тестирование
Модульный тест проверяет только метод, не более того. Тестируемая функция является границей. Разработчик пишет модульные тесты, и некоторые платформы SDLC требуют их. Экстремальное программирование требует их. Он также предписывает разработку через тестирование. Это практика написания модульных тестов в первую очередь. Затем написание фактического программного кода.
Интеграционное тестирование
Интеграционные тесты проверяют разделы или функции кодовой базы. Обычно они автоматизированы и управляются платформой DevOps. То, что они проверяют, охватывает более одного метода. Примером является проверка того, что вызов API сохранил новую запись в базе данных. Сравните это с модульным тестом, который также проверяет метод API. Модульный тест сможет только проверить, что вызов базы данных должен произойти. Интеграционный тест может подтвердить, что данные проходят через приложение, как и ожидалось.
Тестирование системы
Последней формой тестирования является полное тестирование системы. Напомним, модульное тестирование проверяет только функцию. Интеграционное тестирование проверяет функцию. Но системное тестирование рассматривает все приложение как единое целое. Дымовое тестирование — это упрощенная форма системного тестирования. В нем тестер взаимодействует с системой, как обычный пользователь, и обеспечивает ее ожидаемое поведение. В отличие от полного сквозного тестирования системы, которое является более строгим. Полное системное тестирование проверяет все части системы как единое целое. Кроме того, набор интеграционных тестов может служить полным системным тестом.
5. Развертывание
Этап развертывания — это запуск протестированного кода в производство. Автоматизация развертывания делает его более надежным. Кроме того, практика развертывания в производственной среде также увеличивает шансы на гладкое развертывание. Команда разработчиков работает со средой тестирования, которая называется промежуточной средой. Он должен быть идентичен производственному. Чем больше похожи две среды, тем большую ценность имеет практическое развертывание.
6. Техническое обслуживание
Все, что до этого момента в SDLC, будет составлять лишь около четверти от общей стоимости владения. Первоначальная стоимость разработки программного обеспечения составляет 25% от суммы, которую потратит бизнес. Этап обслуживания обойдется бизнесу примерно в 75% от общей стоимости владения. Защита от раздувания затрат на техническое обслуживание заключается в том, чтобы уделять больше внимания более ранним этапам. Это означает лучший технический дизайн, разработку и более тщательное тестирование. Альтернативой является технический долг. Как и настоящий долг, он со временем дорожает.
5 основных методологий разработки программного обеспечения
В то время как шаги SDLC неизменны, их реализация и порядок выполнения различаются. Давайте рассмотрим самые популярные способы организации процесса разработки программного обеспечения.
1. Проворный
Что делает Agile уникальным, так это ориентация на людей. Методологии Agile переориентировали внимание отрасли. Раньше основное внимание уделялось продукту, программному обеспечению. Agile бросил вызов этому и сосредоточился на людях, выполняющих этот процесс. Кроме того, до Agile Manifesto экстремальное программирование (XP) и Scrum не имели никакой связи. Тем не менее, впоследствии их практикующие объединились под знаменем Agile.
Agile — это не фреймворк сам по себе. Это фреймворк для фреймворков. По сути, речь идет о концентрации на людях и быстрых итерациях. Это именно то, что говорит название, проворный. Сделано хорошо есть гибкость в достижении результата. Процессы никогда не осуществляются за счет людей, которые вместо этого извлекают из них пользу.

Еще одним ключевым преимуществом Agile является итеративный подход. Идея состоит в том, чтобы выполнять блоки работы за более короткие промежутки времени. Таким образом, бизнес может быстрее адаптироваться к изменениям на рынке. Способность быстро менять направление развития делает его гибким. В то же время команда разработчиков может учиться на том, что она делала в каждой итерации, и совершенствоваться. Agile-команды делают это на ретроспективных встречах после каждой итерации.
2. Экстремальное программирование
Экстремальное программирование (часто сокращенно XP) зародилось в начале 1990-х. Мартин Фаулер был одним из первых, кто подписал Манифест Agile. Он считает, что Agile получил свою популярность благодаря фреймворку XP. Кроме того, он утверждает, что это лучший способ начать гибкую разработку программного обеспечения.
XP получил свое название из-за своего подхода. Он использует общие передовые методы работы с программным обеспечением и требует их. Вот что делает его «экстремальным». XP требует таких вещей, как модульные тесты, парное программирование, более частые выпуски.
Что делает XP уникальным методом:
- Короткие итерационные циклы (обычно от 1 до 2 недель)
- Открытость к замене рабочих элементов в текущей итерации (что не позволяет Scrum)
- Акцент на автоматизированном тестировании и парном программировании
3. Бережливый
Технически Lean не был Agile, но на практике он похож на него. Теперь это принято большинством как часть Agile. Его фокус отличается от традиционного Agile. Согласно манифесту Agile, «Люди и взаимодействие важнее процессов и инструментов». Бережливое производство больше фокусируется на программном обеспечении, чем на производителях.
Его корни лежат в принципах бережливого производства от Toyota. Вот семь частей, которые определяют его. Если вы знакомы с бережливым производством, это будет звучать похоже. Они есть:
- Устранение отходов
- Расширение обучения
- Решайте как можно позже
- Доставить как можно быстрее
- Расширение возможностей команды
- Воспитывать целостность в
- Оптимизировать все
4. Скрам
Scrum — самый популярный метод Agile. Согласно отчету 14th State of Agile, 58% компаний-разработчиков программного обеспечения используют Scrum. Если вы включите гибриды Scum, процент подскакивает до 84%. Напрашивается вопрос, почему он самый популярный?
Ответ заключается в том, что Scrum предназначен для выполнения большего объема работы за меньшее время. Это привлекает бизнес. Каждая итерация в Scrum — это «спринт». Название усиливает идею скорости. Обычно спринт длится от 2 до 3 недель. После того, как Scrum-команда запланировала спринт, никто не должен его менять. Новую работу приходится ждать до начала следующего спринта. Это требует дисциплины со стороны заинтересованных сторон. На практике это правило Scrum часто нарушается. Вот почему команды часто сообщают о гибридном Scrum.
Еще одной характеристикой Scrum является Scrum Master. Это один из членов команды, назначенный ответственным за поддержание цели в спринте. Часто скрам-мастером является разработчик из команды разработчиков.
Наиболее распространенным вариантом Scrum является ScrumBan, представляющий собой смесь Scrum и Kanban. Канбан берет свое начало в производственном процессе японской Toyota, подобно бережливому производству. Это система работы точно в срок.
Каждый элемент работы похож на собственную итерацию. Разработчик работает только над одной вещью за раз. Правило — один «незавершенный» элемент для каждого разработчика. Этот строгий предел незавершенного производства проливает свет на любые узкие места. Разработчики отслеживают выполнение рабочих задач с помощью канбан-доски. Кстати, отсюда и название. На японском Канбан означает «вывеска».
5. Водопад
Метод водопада — самый ранний из всех методов разработки программного обеспечения. Он предшествует Agile как минимум на несколько десятилетий. Этот метод также старше своего названия.
Это естественный способ работы компаний. Это линейный процесс, и вы начинаете с самого начала. Сначала заинтересованные стороны составляют требования. Они не делают этого для функции или двух. Нет, заинтересованные стороны бизнеса охватывают весь проект сразу. После этого начинается работа. Разработчики делают всю работу без каких-либо итераций до завершения.
Метод водопада проще всего понять концептуально. Люди делают одно дело за раз. Тем не менее, это самый рискованный для успеха в бизнесе. Если что-то идет не по плану, заинтересованные стороны не могут это исправить до завершения проекта. Причина в том, что до завершения проекта его даже не заметят.
3 основных подтипа программного обеспечения
Готовое программное обеспечение бывает одного из трех типов. Эти типы являются системным, программным и прикладным программным обеспечением. Для иллюстрации приведем аналогию с выпечкой торта. Миксер или шпатель - это программное обеспечение для программирования. Это позволяет вам сделать больше тортов или больше программных приложений по этой аналогии. При сборке торта нижним слоем является системное ПО. Это основа. Без него не получится слоеный пирог. Тогда верхний уровень будет прикладным программным обеспечением. Это то, что видно большинству случайных наблюдателей.
Программное обеспечение
Операционная система компьютера — это системное программное обеспечение. Это имеет решающее значение для его полезности. Представьте себе компьютер без операционной системы. Вы сможете взаимодействовать с ним только через машинный язык. Это чистый двоичный код — только единицы и нули. Вы обнаружите, что с ним невозможно работать на любом уровне масштаба. Системное программное обеспечение открывает возможности использования компьютера.
Windows, macOS и Linux являются наиболее популярными примерами системного программного обеспечения. Драйверы устройств также являются системным программным обеспечением. Они расширяют базовую функциональность операционной системы. Интеллектуальные устройства без операционной системы используют микропрограмму для обеспечения своей функциональности. Это также системное программное обеспечение.
Программное обеспечение для программирования
Программное обеспечение для программирования является подмножеством прикладного программного обеспечения. Любая программа, которую разработчик использует для создания новых программ, будет классифицироваться. Они варьируются от простых текстовых редакторов до сложных интегрированных сред разработки (IDE). Большинство разработчиков предпочитают более сложные программные инструменты. Такие программы, как Microsoft Visual Studio, помогают ускорить разработку.

Программное обеспечение
Прикладное программное обеспечение является наиболее распространенным типом. Это программное обеспечение, которое позволяет вам делать что-то с компьютером. Это делает компьютеры полезными. Популярными примерами являются такие программы, как Microsoft Word и Excel.
Облачное программное обеспечение также попадает в эту категорию. Google Docs, Dropbox и даже Instagram — это прикладное программное обеспечение. Если вы когда-нибудь запутались, является ли что-то прикладным программным обеспечением или нет, вот простой тест. Нужно ли программе что-то еще для запуска? Виндовс или Андроид нет. Это системное программное обеспечение. PowerPoint или даже такая игра, как Call of Duty, для работы нуждаются в других запущенных вещах, что означает, что они являются прикладным программным обеспечением. Без драйверов устройств и операционной системы они не могут работать.
Вывод
Методы разработки программного обеспечения все еще развиваются. Тем не менее, независимо от используемого метода, шаги остаются теми же. Agile-команды могут перебирать их быстрее, а специалисты Waterfall медленно переходят от одного к другому. Тем не менее, чтобы создать лучшее программное обеспечение, вы должны усовершенствовать процесс на каждом этапе. Они строятся друг на друге. Жизненный цикл разработки программного обеспечения не обходится без одного из его этапов. Части составляют целое.
Подумайте о том, что произойдет, если вы пропустите какой-либо шаг. Без планирования того, что вы делаете? Без дизайна процесс разработки будет бессистемным. Пропустить этап разработки невозможно. Отсутствие тестирования гарантирует, что продукт не будет работать так, как ожидалось. Если нет развертывания, ни у кого не будет доступа к использованию продукта. Неподдерживаемое приложение выходит из употребления. Каждый шаг имеет решающее значение для успеха программного продукта.