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

Материал из wikixw
Перейти к навигации Перейти к поиску

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

Жизненный цикл разработки программного обеспечения (SDLC)

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

Жизненный цикл разработки систем состоит из ряда четко определенных и четко определенных этапов работы, которые используются системными инженерами и разработчиками систем для планирования, проектирования, построения, тестирования и доставки информационных систем . Как и все, что производится на сборочной линии, SDLC стремится производить высококачественные системы, которые удовлетворяют или превышают ожидания клиентов, основанные на требованиях клиентов, поставляя системы, которые проходят через каждый четко определенный этап, в запланированные сроки и сметы расходов.[3] Компьютерные системы сложны и часто (особенно с недавним подъемом сервис-ориентированная архитектура) связывает несколько традиционных систем, потенциально поставляемых различными поставщиками программного обеспечения. Для управления этим уровнем сложности был создан ряд моделей или методологий SDLC , таких как waterfall , spiral , Agile Software development , rapid prototyping , incremental, synchronize и stabilize.[4]

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

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

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

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

История и детали[править]

Жизненный цикл продукта описывает процесс построения информационных систем очень продуманным, структурированным и методичным образом, повторяя каждый этап жизненного цикла продукта. Жизненный цикл развития систем, согласно Elliott & Strachan & Radford (2004), "возник в 1960-х годах, чтобы развивать крупные функциональные бизнес-системы в век крупных бизнес-конгломератов . Деятельность информационных систем вращалась вокруг тяжелых процедур обработки данных и обработки чисел".[6]

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

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

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

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

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

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

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

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

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

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

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

Analysis[править]

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

Design[править]

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

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

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

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

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

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

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

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

Ниже приведены типы тестирования, которые могут быть актуальными, в зависимости от типа разрабатываемой системы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этапы SPIU, связанные с управлением

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

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

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

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

Разбивочная структура работы

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

Базовые показатели[править]

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

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

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

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

Сравнение методологических подходов (Post, & Anderson 2006 См. на англ.википедии.

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

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

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

Сила и слабости SDLC См.на англ. википедии .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пруф[править]

ambysoft.com/essays/agileLifecycle.html

Источник — https://wikixw.ru/index.php?title=Жизненный_цикл_разработки_систем&oldid=3667