В системной инженерии , информационных системах и программной инженерии жизненный цикл разработки систем ( SDLC ), также называемый жизненным циклом разработки приложений , представляет собой процесс планирования, создания, тестирования и развертывания информационной системы . [1] Концепция SDLC применяется к ряду конфигураций оборудования и программного обеспечения, поскольку система может состоять только из оборудования, только из программного обеспечения или из их комбинации. [2] Обычно в этом цикле есть шесть этапов: анализ требований, проектирование, разработка и тестирование, реализация, документирование и оценка.
«Организация по разработке программного обеспечения следует определенному процессу при разработке программного продукта в зрелой организации, который четко определен и управляется. В жизненном цикле разработки программного обеспечения мы разрабатываем программное обеспечение систематическим и дисциплинированным образом ».
Жизненный цикл разработки систем состоит из отдельных рабочих фаз, которые используются системными инженерами и разработчиками систем для поставки информационных систем . Как и все, что производится на сборочной линии, SDLC направлен на создание высококачественных систем, которые соответствуют или превосходят ожидания, основанные на требованиях, путем поставки систем в запланированные сроки и сметы расходов. [3] Компьютерные системы сложны и часто связывают компоненты с различным происхождением. Были созданы различные методологии SDLC, такие как водопад , спираль , гибкая , быстрое прототипирование , инкрементальная и синхронизация и стабилизация. [4]
Методологии SDLC вписываются в спектр гибкости от agile до итеративного и последовательного. Agile-методологии, такие как XP и Scrum , фокусируются на легких процессах, которые позволяют быстро вносить изменения. [5] Итеративные методологии, такие как Rational Unified Process и метод разработки динамических систем , фокусируются на стабилизации объема проекта и итеративном расширении или улучшении продуктов. Последовательные или крупномасштабные модели проектирования (BDUF), такие как каскадная модель, фокусируются на полном и правильном планировании для руководства более крупными проектами и ограничения рисков для успешных и предсказуемых результатов. [6] Анаморфная разработка направляется объемом проекта и адаптивными итерациями.
В управлении проектами проект может включать как жизненный цикл проекта (PLC), так и SDLC, в течение которых происходят несколько различные действия. По словам Тейлора (2004), «жизненный цикл проекта охватывает все действия проекта , в то время как жизненный цикл разработки систем фокусируется на реализации требований к продукту ». [7]
SDLC не является методологией как таковой, а скорее описанием фаз, которые должна охватывать методология. Список фаз не является окончательным, но обычно включает планирование, анализ, проектирование, сборку, тестирование, реализацию и обслуживание/поддержку. В фреймворке Scrum [8] , например, можно сказать, что одна пользовательская история проходит через все фазы SDLC в течение двухнедельного спринта. В отличие от методологии водопада, где каждое бизнес-требование [ нужна цитата ] переводится в описания функций/функций, которые затем все реализуются, как правило, в течение месяцев или дольше. [ нужна цитата ]
По словам Эллиотта (2004), SDLC «возник в 1960-х годах для разработки крупномасштабных функциональных бизнес-систем в эпоху крупных бизнес-конгломератов . Деятельность информационных систем вращалась вокруг сложных процедур обработки данных и обработки чисел ». [9]
Метод структурированного системного анализа и проектирования (SSADM) был разработан для Управления правительственной торговли Великобритании в 1980-х годах. С тех пор, по словам Эллиотта (2004), «традиционные подходы жизненного цикла к разработке систем все чаще заменялись альтернативными подходами и фреймворками, которые пытались преодолеть некоторые присущие традиционному SDLC недостатки». [9]
SDLC предоставляет набор фаз/шагов/действий для системных проектировщиков и разработчиков. Каждая фаза основывается на результатах предыдущей. [10] [11] [12] [13] Не каждый проект требует, чтобы фазы были последовательными. Для небольших, более простых проектов фазы могут быть объединены/перекрыты. [10]
Самая старая и известная модель водопада , которая использует линейную последовательность шагов. [11] Водопад имеет различные разновидности. Одна из разновидностей следующая: [10] [11] [14] [15]
Проведите предварительный анализ, рассмотрите альтернативные решения, оцените затраты и выгоды и представьте предварительный план с рекомендациями.
Разложить цели проекта [ требуется уточнение ] на определенные функции и операции. Это включает сбор и интерпретацию фактов, диагностику проблем и рекомендации изменений. Проанализировать потребности конечного пользователя в информации и устранить несоответствия и неполноту: [16]
На этом этапе детализируются желаемые функции и операции, включая макеты экранов, бизнес-правила , диаграммы процессов , псевдокод и другие результаты.
Напишите код.
Соберите модули в тестовой среде. Проверьте наличие ошибок, багов и совместимость.
Запустить систему в эксплуатацию. Это может включать обучение пользователей, развертывание оборудования и загрузку информации из предыдущей системы.
Контролировать систему для оценки ее текущей пригодности. Вносить небольшие изменения и исправления по мере необходимости. Поддерживать качество системы. Постоянный мониторинг и обновления гарантируют, что система остается эффективной и высококачественной. [17]
Проверяются система и процесс. Соответствующие вопросы включают в себя: соответствует ли вновь внедренная система требованиям и достигает ли она целей проекта, является ли система пригодной к использованию, надежной/доступной, правильно масштабируемой и отказоустойчивой. Проверки процесса включают в себя проверку сроков и расходов, а также принятие пользователем.
В конце срока службы разрабатываются планы по прекращению работы системы и переходу к ее замене. Сопутствующая информация и инфраструктура должны быть перепрофилированы, архивированы, выброшены или уничтожены, при этом должным образом защищая безопасность. [18]
На следующей диаграмме эти этапы разделены на десять шагов — от определения до создания и модификации рабочих продуктов ИТ:
Системный анализ и проектирование (SAD) можно считать деятельностью мета-разработки, которая служит для установки сцены и ограничения проблемы. SAD может помочь сбалансировать конкурирующие высокоуровневые требования. SAD взаимодействует с распределенной корпоративной архитектурой, корпоративной ИТ-архитектурой и бизнес-архитектурой и в значительной степени опирается на такие концепции, как разбиение, интерфейсы, персоны и роли, а также развертывание/операционное моделирование, чтобы прийти к высокоуровневому описанию системы. Это высокоуровневое описание затем разбивается на компоненты и модули, которые можно анализировать, проектировать и конструировать отдельно и интегрировать для достижения бизнес-цели. SDLC и SAD являются краеугольными камнями полного жизненного цикла продукта и планирования системы.
Объектно-ориентированный анализ и проектирование (OOAD) — это процесс анализа проблемной области для разработки концептуальной модели , которая затем может использоваться для руководства разработкой. На этапе анализа программист разрабатывает письменные требования и формальный документ видения посредством интервью с заинтересованными сторонами.
Концептуальная модель, которая получается в результате OOAD, обычно состоит из вариантов использования , а также диаграмм классов и взаимодействий . Она также может включать макет пользовательского интерфейса .
Выходной артефакт не обязательно должен быть полностью определен, чтобы служить входом объектно-ориентированного проектирования; анализ и проектирование могут происходить параллельно. На практике результаты одного вида деятельности могут питать другой в итеративном процессе.
Некоторые типичные артефакты ввода для OOAD:
Жизненный цикл системы — это представление системы или предлагаемой системы, которое охватывает все фазы ее существования, включая концепцию системы, проектирование и разработку, производство и/или строительство, распространение, эксплуатацию, техническое обслуживание и поддержку, вывод из эксплуатации, поэтапный отказ и утилизацию. [19]
Этап концептуального проектирования — это этап, на котором исследуется выявленная потребность, определяются требования к потенциальным решениям, оцениваются потенциальные решения и разрабатывается системная спецификация. Системная спецификация представляет собой технические требования, которые будут обеспечивать общее руководство для системного проектирования. Поскольку этот документ определяет всю будущую разработку, этап не может быть завершен, пока обзор концептуального проектирования не определит, что системная спецификация должным образом отвечает мотивирующей потребности.
Ключевые этапы этапа концептуального проектирования включают в себя:
На этом этапе жизненного цикла системы подсистемы, которые выполняют желаемые системные функции, проектируются и специфицируются в соответствии со спецификацией системы. Определяются интерфейсы между подсистемами, а также общие требования к тестированию и оценке. [20] По завершении этого этапа создается спецификация разработки, достаточная для выполнения детального проектирования и разработки.
Ключевые этапы этапа предварительного проектирования включают в себя:
Например, как системный аналитик Viti Bank, вам было поручено изучить текущую информационную систему. Viti Bank — быстрорастущий банк на Фиджи . Клиенты в отдаленных сельских районах испытывают трудности с доступом к банковским услугам. Им требуются дни или даже недели, чтобы добраться до места, чтобы получить доступ к банковским услугам. С целью удовлетворения потребностей клиентов банк запросил ваши услуги по изучению текущей системы и выработке решений или рекомендаций о том, как текущая система может быть предоставлена для удовлетворения его потребностей.
Эта стадия включает разработку детальных проектов, которые переводят начальные проектные работы в завершенную форму спецификаций. Эта работа включает спецификацию интерфейсов между системой и ее предполагаемой средой, а также комплексную оценку требований к логистике, обслуживанию и поддержке систем. Детальное проектирование и разработка отвечают за создание спецификаций продукта, процесса и материалов и могут привести к существенным изменениям в спецификации разработки.
Ключевые этапы на этапе детального проектирования и разработки включают в себя:
На этапе производства и/или строительства продукт создается или собирается в соответствии с требованиями, указанными в спецификациях продукта, процесса и материалов, и развертывается и тестируется в целевой операционной среде. Оценки системы проводятся с целью исправления недостатков и адаптации системы для постоянного совершенствования.
Ключевые этапы на этапе создания продукта включают в себя:
После полного развертывания система используется по своему прямому назначению и обслуживается в своей операционной среде.
Ключевые этапы на этапе использования и поддержки включают в себя:
Эффективность и результативность системы должны постоянно оцениваться, чтобы определить, когда продукт достиг своего максимально эффективного жизненного цикла. [21] Необходимо учитывать: постоянное существование эксплуатационной потребности, соответствие эксплуатационных требований и производительности системы, осуществимость поэтапного отказа от системы по сравнению с ее обслуживанием и доступность альтернативных систем.
На этом этапе рассматриваются текущие приоритеты, которые будут затронуты, и то, как с ними следует обращаться. Исследование осуществимости определяет, является ли создание новой или улучшенной системы целесообразным. Это помогает оценить затраты, выгоды, требования к ресурсам и конкретные потребности пользователей.
В технико-экономическом обосновании следует рассмотреть эксплуатационные , финансовые , технические , человеческие факторы, а также правовые/политические вопросы.
Цель анализа — определить, где находится проблема. Этот шаг включает в себя разложение системы на части, анализ целей проекта, разбивку того, что необходимо создать, и привлечение пользователей для определения требований.
В системном проектировании функции и операции подробно описываются, включая макеты экранов, бизнес-правила, диаграммы процессов и другую документацию. Модульное проектирование снижает сложность и позволяет выводам описывать систему как совокупность подсистем.
Этап проектирования принимает в качестве входных данных уже определенные требования. Для каждого требования создается набор элементов дизайна.
Проектные документы обычно включают в себя диаграммы функциональной иерархии, макеты экранов, бизнес-правила, диаграммы процессов, псевдокод и полную модель данных со словарем данных . Эти элементы описывают систему достаточно подробно, чтобы разработчики и инженеры могли разработать и предоставить систему с минимальным дополнительным вводом.
Код тестируется на разных уровнях в тестировании программного обеспечения . Обычно проводятся модульные, системные и пользовательские приемочные тесты. Было принято много подходов к тестированию.
Могут быть актуальны следующие типы тестирования:
После стабилизации системы путем тестирования SDLC обеспечивает подготовку и проведение надлежащего обучения перед передачей системы персоналу поддержки и конечным пользователям. Обучение обычно охватывает операционное обучение для персонала поддержки, а также обучение конечных пользователей.
После обучения системные инженеры и разработчики переносят систему в производственную среду.
Техническое обслуживание включает в себя изменения, исправления и улучшения.
Заключительный этап SDLC заключается в измерении эффективности системы и оценке потенциальных улучшений.
В этом разделе описываются цели фазы SDLC с ключевыми результатами, описанием рекомендуемых задач и резюме связанных целей контроля для эффективного управления. Для менеджера проекта критически важно устанавливать и контролировать цели контроля при выполнении проектов. Цели контроля представляют собой четкие заявления о желаемом результате или цели и должны определяться и контролироваться на протяжении всего проекта. Цели контроля можно сгруппировать в основные категории (домены) и соотнести с фазами SDLC, как показано на рисунке. [22]
Для управления и контроля существенной инициативы SDLC структура декомпозиции работ (WBS) фиксирует и планирует работу. WBS и все программные материалы должны храниться в разделе «описание проекта» проектной записной книжки. [ необходимо уточнение ] Менеджер проекта выбирает формат WBS, который наилучшим образом описывает проект.
Диаграмма показывает, что покрытие охватывает многочисленные фазы SDLC, но связанный MCD (домены управления и контроля) показывает сопоставления с фазами SDLC. Например, анализ и проектирование в основном выполняются как часть домена приобретения и внедрения, а сборка и прототипирование системы в основном выполняются как часть поставки и поддержки. [22]
Верхний раздел WBS содержит обзор области действия и временной шкалы проекта. Он также должен суммировать основные фазы и вехи. Средний раздел основан на фазах SDLC. Элементы WBS состоят из вех и задач, которые необходимо выполнить, а не из действий, которые необходимо предпринять, и имеют крайний срок. Каждая задача имеет измеримый результат (например, аналитический документ). Задача WBS может опираться на одно или несколько действий (например, кодирование). Части проекта, требующие поддержки со стороны подрядчиков, должны иметь описание работы (SOW). Разработка SOW не происходит во время определенной фазы SDLC, а разрабатывается для включения работы из процесса SDLC, которая может быть выполнена подрядчиками. [22]
Базовые линии [ необходимо разъяснение ] устанавливаются после четырех из пяти фаз SDLC и имеют решающее значение для итеративной природы модели. [23] Базовые линии становятся вехами.
Альтернативными методам разработки программного обеспечения для жизненного цикла разработки систем являются:
По сути, SDLC жертвует гибкостью ради контроля путем навязывания структуры. Чаще всего используется для крупномасштабных проектов с большим количеством разработчиков.
