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

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

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

Обзор [ править ]

Жизненный цикл разработки системы состоит из ряда четко определенных и различных этапов работы, которые используются системными инженерами и разработчиками систем для планирования, проектирования, построения, тестирования и доставки информационных систем . Как и все, что производится на сборочной линии, SDLC направлен на производство высококачественных систем, которые соответствуют или превосходят ожидания клиентов, исходя из требований клиентов, путем доставки систем, которые проходят каждый четко определенный этап в запланированные сроки и сметы затрат. ^[3] Компьютерные системы сложны и часто (особенно с недавним ростом сервис-ориентированной архитектуры) связать несколько традиционных систем, потенциально поставляемых разными поставщиками программного обеспечения. Для управления этим уровнем сложности был создан ряд моделей или методологий SDLC, таких как водопад , спираль , гибкая разработка программного обеспечения , быстрое прототипирование , инкрементальное , синхронизация и стабилизация. ^[4]

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

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

Жизненный цикл разработки систем (SDLC) используется во время разработки ИТ-проекта, он описывает различные этапы, вовлеченные в проект, с чертежной доски до завершения проекта.

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

История и подробности [ править ]

Жизненный цикл продукта описывает процесс создания информационных систем в очень преднамеренном, структурированном и методично, повторяя каждый этап жизненного цикла продукта. Системы Жизненный цикл разработки, в соответствии с Elliott & Строона & Рэдфорд (2004), «возникла в 1960 - е годы, развивать крупномасштабные функциональные бизнес - системы в эпоху крупных бизнес - конгломератов . Системы деятельности Информационные вращалась вокруг тяжелых обработки данных , и число хруст рутины ". ^[7]

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

Фазы [ править ]

Структура жизненного цикла разработки системы обеспечивает последовательность действий, которым должны следовать проектировщики и разработчики систем. Он состоит из набора шагов или фаз, в которых каждая фаза SDLC использует результаты предыдущей. ^{[8] [9]}

SDLC придерживается важных этапов, которые важны для разработчиков, таких как планирование , анализ , проектирование и реализация, и объясняются в следующем разделе. Это включает в себя оценку используемой в настоящее время системы, сбор информации, технико-экономические обоснования и запрос утверждения. Был создан ряд моделей SDLC, включая водопад, фонтан, спираль, сборку и исправление, быстрое прототипирование, инкрементальную, синхронизацию и стабилизацию. ^{[10] [11]} Самая старая и самая известная из них - это водопадная модель , последовательность стадий, в которой выходные данные каждой стадии становятся входными данными для следующей. ^[9]Эти этапы можно охарактеризовать и разделить по-разному, включая следующие: ^{[8] [9] [12] [13]}

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

1. Проведите предварительный анализ: узнайте цели организации, а также характер и масштаб исследуемой проблемы. Даже если проблема касается только небольшого сегмента самой организации, выясните, каковы цели самой организации. Затем посмотрите, насколько им соответствует изучаемая проблема.
2. Предложите альтернативные решения: после изучения целей и конкретных проблем организации можно найти несколько решений. Однако альтернативные предложения могут по-прежнему поступать в результате собеседований с сотрудниками, клиентами, поставщиками и / или консультантами. Понимание также можно получить, изучив, что делают конкуренты.
3. Анализ затрат и выгод: проанализируйте и опишите затраты и выгоды от внедрения предложенных изменений. В конце концов, окончательное решение о том, оставить ли систему как есть, улучшить ее или разработать новую, будет зависеть от этих и остальных данных предварительного анализа.

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

Разработчик должен выполнить следующие действия: ^[14]

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

• Проектирование системы : на этом этапе подробно описываются желаемые функции и операции, включая макеты экранов, бизнес-правила , диаграммы процессов , псевдокод и другую документацию.
• Разработка : Здесь написан реальный код.
• Интеграция и тестирование : все модули объединяются в специальную среду тестирования, затем проверяются на наличие ошибок, ошибок и совместимости.
• Принятие, установка, развертывание : это заключительный этап начальной разработки, на котором программное обеспечение запускается в производство и ведет реальный бизнес.
• Сопровождение : на этапе сопровождения SDLC система оценивается / оценивается, чтобы гарантировать, что она не устареет. Здесь также вносятся изменения в исходное программное обеспечение.
• Оценка : некоторые компании не рассматривают это как официальный этап SDLC, в то время как другие считают его продолжением этапа сопровождения, и в некоторых кругах его можно назвать обзором после внедрения. Здесь оценивается система, которая была разработана, а также весь процесс. Некоторые из вопросов, на которые необходимо ответить, включают: соответствует ли новая внедренная система первоначальным бизнес-требованиям и целям, является ли система надежной и отказоустойчивой и функционирует ли она в соответствии с утвержденными функциональными требованиями. Помимо оценки выпущенного программного обеспечения, важно оценить эффективность процесса разработки. Если есть какие-либо аспекты всего процесса (или определенных этапов), которые не устраивают руководство, самое время улучшить.
• Утилизация: на этом этапе разрабатываются планы прекращения использования системной информации, оборудования и программного обеспечения и перехода на новую систему. Целью здесь является правильное перемещение, архивирование, удаление или уничтожение информации, оборудования и программного обеспечения, которые заменяются, таким образом, чтобы предотвратить любую возможность несанкционированного раскрытия конфиденциальных данных. Действия по утилизации обеспечивают надлежащий переход на новую систему. Особое внимание уделяется надлежащему сохранению и архивированию данных, обработанных предыдущей системой. Все это должно выполняться в соответствии с требованиями безопасности организации. ^[15]

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

Не для каждого проекта требуется последовательное выполнение этапов. Однако фазы взаимозависимы. В зависимости от размера и сложности проекта фазы могут быть объединены или перекрываться. ^[8]

Системное исследование [ править ]

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

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

• Оперативная осуществимость
• Финансовая осуществимость
• Техническая осуществимость
• Возможность человеческого фактора
• Юридическая / политическая осуществимость

Анализ [ править ]

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

Дизайн [ править ]

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

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

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

Среды [ править ]

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

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

Тестирование [ править ]

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

В зависимости от типа разрабатываемой системы могут иметь значение следующие типы тестирования:

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

Обучение и переход [ править ]

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

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

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

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

Оценка [ править ]

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

Системный анализ и дизайн [ править ]

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

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

Объектно-ориентированный анализ (OOA) - это процесс анализа задачи (также известной как проблемная область ) с целью разработки концептуальной модели, которую затем можно использовать для выполнения задачи. Типичная модель OOA будет описывать компьютерное программное обеспечение, которое можно использовать для удовлетворения набора требований, определенных заказчиком. На этапе анализа решения проблем программист может рассмотреть письменное заявление о требованиях, формальный документ о видении или интервью с заинтересованными сторонами или другими заинтересованными сторонами. Решаемую задачу можно разделить на несколько подзадач (или доменов), каждая из которых представляет различные области бизнеса, технологии или другие области интересов. Каждая подзадача будет анализироваться отдельно. Ограничения реализации (например, параллелизм , распределение ,устойчивость или способ построения системы) не рассматриваются на этапе анализа; скорее, они решаются во время объектно-ориентированного проектирования (OOD).

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

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

Некоторые типичные (но общие для всех типов анализа проекта) входные артефакты для объектно-ориентированного подхода:

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

Жизненный цикл [ править ]

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

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

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

Есть несколько ключевых областей, которые должны быть определены в WBS как часть политики SDLC. Следующая диаграмма описывает три ключевые области, которые будут рассмотрены в WBS в порядке, установленном менеджером проекта. ^[17] На схеме показано, что покрытие охватывает многочисленные фазы SDLC, но связанный MCD имеет подмножество первичных сопоставлений с фазами SDLC. Например, анализ и проектирование в основном выполняются как часть области приобретения и внедрения, а создание системы и прототипа в основном выполняется как часть поставки и поддержки.

Структурированная организация работ [ править ]

Верхняя часть иерархической структуры работ (WBS) должна в краткой форме идентифицировать основные фазы и этапы проекта. Кроме того, в верхнем разделе должен быть представлен обзор всего объема и сроков проекта, и он будет частью начального описания проекта, ведущего к утверждению проекта. Средняя часть WBS основана на семи фазах жизненного цикла разработки систем в качестве руководства для разработки задач WBS. WBS-элементы должны состоять из этапов и «задач», а не «действий», и иметь определенный период (обычно две недели или более). Каждая задача должна иметь измеримый результат (например, документ, решение или анализ). Задача WBS может полагаться на одно или несколько действий (например, программная инженерия, системная инженерия) и может требовать тесной координации с другими задачами,либо внутренние, либо внешние по отношению к проекту. Любая часть проекта, требующая поддержки со стороны подрядчиков, должна иметьтехническое задание (SOW), написанное для включения соответствующих задач из этапов SDLC. Разработка SOW не происходит на определенной фазе SDLC, но разрабатывается для включения работы из процесса SDLC, которая может выполняться внешними ресурсами, такими как подрядчики. ^[17]

Исходные данные [ править ]

Базовые показатели - важная часть жизненного цикла разработки системы. Эти базовые параметры устанавливаются после четырех из пяти этапов SDLC и имеют решающее значение для итеративного характера модели. ^[18] Каждая базовая линия считается вехой в SDLC.

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

Дополнительные методологии [ править ]

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

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

Сильные и слабые стороны [ править ]

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

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

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

Жизненный цикл системы [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Производство и строительство [ править ]

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

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

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

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

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

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

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

Поэтапный отказ и утилизация [ править ]

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

См. Также [ править ]

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

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Каммингс, Хааг (2006). Информационные системы управления для информационного века . Торонто, Макгроу-Хилл Райерсон
• Бейнон-Дэвис П. (2009). Информационные системы для бизнеса . Пэлгрейв, Бейзингсток. ISBN 978-0-230-20368-6 
• Computer World, 2002 г. , получено 22 июня 2006 г. из Интернета:
• Management Information Systems, 2005 г. , получено 22 июня 2006 г. из Интернета:
• Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL версии 1.3 или новее.

Внешние ссылки [ править ]

Викискладе есть медиафайлы по теме жизненного цикла разработки систем .

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