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