Жизненный цикл разработки систем

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

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

Обзор

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

Методологии SDLC соответствуют диапазону гибкости: от гибкого до итеративного и последовательного. Гибкие методологии, такие как XP и Scrum , ориентированы на облегченные процессы, позволяющие быстро вносить изменения. Итеративные методологии, такие как Rational Unified Process и метод разработки динамических систем , ориентированы на стабилизацию объема проекта и итеративное расширение или улучшение продуктов. Последовательные модели или модели с предварительным масштабным проектированием (BDUF), такие как водопад, фокусируются на полном и правильном планировании для управления более крупными проектами и ограничения рисков для достижения успешных и предсказуемых результатов. Анаморфная разработка определяется объемом проекта и адаптивными итерациями.

В управлении проектами проект может включать как жизненный цикл проекта (PLC), так и SDLC, во время которого происходят несколько разные действия. По словам Тейлора (2004), «жизненный цикл проекта охватывает все виды деятельности проекта , в то время как жизненный цикл разработки системы фокусируется на реализации требований к продукту ».

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

История

По словам Эллиотта (2004), SDLC «возникла в 1960-х годах для разработки крупномасштабных функциональных бизнес-систем в эпоху крупных бизнес-конгломератов . Деятельность информационных систем вращалась вокруг тяжелой обработки данных и процедур обработки чисел ».

Метод структурированного системного анализа и проектирования (SSADM) был разработан для Управления государственной торговли Великобритании в 1980-х годах. С тех пор, по словам Эллиотта (2004), «традиционные подходы к разработке систем на основе жизненного цикла все чаще заменяются альтернативными подходами и структурами, которые пытались преодолеть некоторые из присущих традиционным SDLC недостатков».

Модели

Десятифазная версия жизненного цикла разработки системы

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

Водопад

Самая старая и известная — водопадная модель , в которой используется линейная последовательность шагов. Водопад имеет разные разновидности. Одна из разновидностей выглядит следующим образом:

Предварительный анализ

Проведите предварительный анализ, рассмотрите альтернативные решения, оцените затраты и выгоды и представьте предварительный план с рекомендациями.

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

Системный анализ, определение требований

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

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

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

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

Развитие

Напишите код.

Интеграция и тестирование

Соберите модули в тестовой среде. Проверьте наличие ошибок, ошибок и совместимости.

Приемка, установка, внедрение

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

Техническое обслуживание

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

Оценка

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

Утилизация

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

На следующей диаграмме эти этапы разделены на десять шагов: от определения до создания и модификации рабочих продуктов ИТ:

и

Системный анализ и проектирование (SAD) можно рассматривать как метаразработку, которая служит для подготовки почвы и решения проблемы. SAD может помочь сбалансировать конкурирующие требования высокого уровня. SAD взаимодействует с распределенной архитектурой предприятия, корпоративной ИТ-архитектурой и бизнес-архитектурой и в значительной степени полагается на такие концепции, как разделение, интерфейсы, персонажи и роли, а также моделирование развертывания / эксплуатации для получения высокоуровневого описания системы. Это высокоуровневое описание затем разбивается на компоненты и модули, которые можно анализировать, проектировать, создавать отдельно и интегрировать для достижения бизнес-цели. SDLC и SAD являются краеугольными камнями планирования полного жизненного цикла продукта и системы.

Объектно-ориентированный анализ и проектирование

Объектно-ориентированный анализ и проектирование (ООАД) — это процесс анализа проблемной области для разработки концептуальной модели , которую затем можно использовать для руководства разработкой. На этапе анализа программист разрабатывает письменные требования и формальный документ о концепции посредством интервью с заинтересованными сторонами.

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

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

Некоторые типичные артефакты ввода для OOAD:

• Концептуальная модель . Концептуальная модель является результатом объектно-ориентированного анализа. Он фиксирует концепции в проблемной области. Концептуальная модель явно не зависит от деталей реализации.
• Варианты использования . Вариант использования — это описание последовательности событий, которые в совокупности выполняют требуемую задачу. Каждый вариант использования предоставляет сценарии , описывающие, как система должна взаимодействовать с участниками (пользователями). Субъектами могут быть конечные пользователи или другие системы. Варианты использования могут быть дополнительно детализированы с помощью диаграмм. Такие диаграммы идентифицируют субъекта и процессы, которые он выполняет.
• Диаграмма последовательности системы . Диаграмма последовательности системы (SSD) — это изображение, которое для конкретного варианта использования показывает события, генерируемые субъектами, их порядок, включая межсистемные события.
• Документ пользовательского интерфейса: документ, показывающий и описывающий пользовательский интерфейс.
• Модель данных . Модель данных описывает, как элементы данных связаны друг с другом. Модель данных создается до этапа проектирования. Объектно-ориентированные проекты отображаются непосредственно из модели данных. Реляционные проекты более сложны.

Жизненный цикл системы

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

Концептуальный дизайн

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

Ключевые этапы этапа концептуального проектирования включают в себя:

• Нужна идентификация
• Анализ осуществимости
• Анализ системных требований
• Спецификация системы
• Обзор концептуального дизайна

Предварительный проект системы

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

Ключевые этапы предварительного проектирования включают в себя:

• Функциональный анализ
• Распределение требований
• Подробные исследования компромиссов
• Синтез вариантов системы
• Предварительное проектирование инженерных моделей
• Спецификация разработки
• Предварительный анализ проекта

Например, вам как системному аналитику банка «Вити» было поручено изучить действующую информационную систему. Viti Bank — быстрорастущий банк на Фиджи . Клиенты в отдаленных сельских районах испытывают трудности с доступом к банковским услугам. Им требуются дни или даже недели, чтобы добраться до места, где можно получить доступ к банковским услугам. Стремясь удовлетворить потребности клиентов, банк обратился к вам за услугами по изучению существующей системы и выработке решений или рекомендаций относительно того, как существующая система может быть предоставлена ​​для удовлетворения его потребностей.

Детальный проект и разработка

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

Ключевые этапы этапа детального проектирования и разработки включают в себя:

• Детальный дизайн
• Детальный синтез
• Разработка инженерных и прототипных моделей
• Пересмотр спецификации разработки
• Спецификация продукта, процесса и материала
• Критический обзор дизайна

Производство и строительство

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

Ключевые этапы на этапе создания продукта включают в себя:

• Производство и/или изготовление компонентов системы
• Приемочное тестирование
• Распространение и эксплуатация системы
• Эксплуатационные испытания и оценка
• Оценка системы

Использование и поддержка

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

Ключевые этапы этапа использования и поддержки включают в себя:

• Работа системы в пользовательской среде
• Управление изменениями
• Модификации системы для улучшения
• Оценка системы

отказ

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

Фазы

Системное расследование

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

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

Анализ

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

Дизайн

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

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

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

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

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

Могут быть актуальны следующие виды тестирования:

• Тестирование пути
• Тестирование набора данных
• Модульное тестирование
• Тестирование системы
• Интеграционное тестирование
• Тестирование «черного ящика»
• Тестирование белого ящика
• Регрессионное тестирование
• Автоматизация тестирования
• Приемочное тестирование пользователей
• Тестирование производительности программного обеспечения

Обучение и переход

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

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

Эксплуатация и обслуживание

Техническое обслуживание включает в себя изменения, исправления и улучшения.

Оценка

Заключительный этап SDLC заключается в измерении эффективности системы и оценке потенциальных улучшений.

Жизненный цикл

Управление и контроль

Этапы SDLC, связанные с управленческим контролем

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

Чтобы управлять и контролировать значительную инициативу SDLC, структура декомпозиции работ (WBS) фиксирует и планирует работу. WBS и все программные материалы следует хранить в разделе «Описание проекта» блокнота проекта. Менеджер проекта выбирает формат WBS, который лучше всего описывает проект.

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

Структурированная организация работы

Структура декомпозиции работ

В верхнем разделе WBS представлен обзор объема и сроков проекта. В нем также следует кратко изложить основные этапы и этапы. Средний раздел основан на фазах SDLC. Элементы WBS состоят из этапов и задач, которые необходимо выполнить, а не из действий, которые необходимо предпринять и имеют крайние сроки. Каждая задача имеет измеримый результат (например, аналитический документ). Задача WBS может зависеть от одного или нескольких действий (например, кодирования). Части проекта, нуждающиеся в поддержке со стороны подрядчиков, должны иметь техническое задание (SOW). Разработка ТЗ не происходит на определенном этапе SDLC, а включает в себя работу процесса SDLC, которая может выполняться подрядчиками.

Базовые показатели

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

• Функциональная базовая линия: устанавливается после этапа концептуального проектирования.
• выделенный базовый уровень: установлен после этапа предварительного проектирования.
• Базовый уровень продукта: устанавливается после этапа детального проектирования и разработки.
• обновленная базовая линия продукта: устанавливается после этапа строительства производства.

методологии

Альтернативные методы разработки программного обеспечения жизненному циклу разработки систем:

• Прототипирование программного обеспечения
• Совместная разработка приложений (JAD)
• Быстрая разработка приложений (RAD)
• Экстремальное программирование (XP);
• Разработка с открытым исходным кодом
• Разработка для конечных пользователей
• Объектно-ориентированного программирования

Сравнение методологических подходов (Пост и Андерсон, 2006 г.)

	СДЛК	РАД	Открытый источник	Объекты	ДЖАД	Прототипирование	Конечный пользователь
Контроль	Формальный	ЧТО	Слабый	Стандарты	Соединение	Пользователь	Пользователь
Временные рамки	Длинный	Короткий	Середина	Любой	Середина	Короткий	Короткий –
Пользователи	Много	Немного	Немного	Варьируется	Немного	Один или два	Один
сотрудники МИС	Много	Немного	Сотни	Расколоть	Немного	Один или два	Никто
Транзакция/ DSS	Сделка	Оба	Оба	Оба	ДСС	ДСС	ДСС
Интерфейс	Минимальный	Минимальный	Слабый	Окна	Ключевой	Ключевой	Ключевой
Документация и обучение	Жизненно важный	Ограниченное	Внутренний	В объектах	Ограниченное	Слабый	Никто
Честность и безопасность	Жизненно важный	Жизненно важный	Неизвестный	В объектах	Ограниченное	Слабый	Слабый
Многоразовое использование	Ограниченное	Некоторый	Может быть	Жизненно важный	Ограниченное	Слабый	Никто

Сильные и слабые стороны

По сути, SDLC обменивает гибкость на контроль, навязывая структуру. Он чаще используется для крупномасштабных проектов со многими разработчиками.

Сильные и слабые стороны SDLC

Сильные стороны	Недостатки
Контроль	Увеличенное время разработки
Мониторинг крупных проектов	Повышенная стоимость разработки
Подробные шаги	Системы должны быть определены заранее
Оцените затраты и цели завершения	Жесткость
Документация	Трудно оценить затраты, перерасход проекта
Четко определенный пользовательский ввод	Пользовательский ввод иногда ограничен
Простота обслуживания	Маленький параллелизм
Стандарты разработки и проектирования	Автоматизация документации и стандартов ограничена.
Допускает изменения в MIS кадрового обеспечения	Не терпит изменения требований
	Проекты, консервированные на ранних стадиях, приводят к незначительной или нулевой ценности

См. также

• Управление жизненным циклом приложений
• Цикл принятия решения
• Модель IPO
• Методологии разработки программного обеспечения

Дальнейшее чтение

• Каммингс, Хааг (2006). Информационные системы управления в эпоху информации . Торонто, МакГроу-Хилл Райерсон
• Бейнон-Дэвис П. (2009). Бизнес-информационные системы . Пэлгрейв, Бейзингсток. ISBN   978-0-230-20368-6
• Компьютерный мир, 2002 г. Получено 22 июня 2006 г. из Всемирной паутины:
• Информационные системы управления, 2005 г. Получено 22 июня 2006 г. из Всемирной паутины:

Внешние ссылки

• Жизненный цикл разработки гибкой системы
• Корпорация гарантирования пенсионных пособий - Методология жизненного цикла решений в области информационных технологий
• Схема интегрированной структуры Министерства обороны США IFC ( спереди , сзади )
• Структура жизненного цикла FSA
• Структура жизненного цикла производительности предприятия HHS
• Жизненный цикл разработки открытых систем
• Моделирование эволюции жизненного цикла разработки системы
• Жизненный цикл нулевого отклонения
• Схема управления жизненным циклом интегрированной обороны AT&L , форма этой концепции Министерства обороны США.