Жизненный цикл разработки систем - Systems development life cycle

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

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

Обзор

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

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

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

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

История и подробности

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

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

Фазы

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

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

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

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

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

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

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

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

Анализ

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

Дизайн

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

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

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

Среды

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

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

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

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

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

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

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

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

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

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

Оценка

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

Системный анализ и дизайн

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

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

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

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

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

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

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

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

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

Этапы SPIU, относящиеся к управленческому контролю

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

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

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

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

Иерархическая структура работ

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

Исходные данные

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

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

Дополнительные методологии

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

Сравнение методологических подходов (Пост и Андерсон, 2006)
SDLC РАД Открытый исходный код Объекты JAD Прототипирование Конечный пользователь
Контроль Формальный MIS Слабый Стандарты Соединение Пользователь Пользователь
Период времени Длинный короткий Середина Любой Середина короткий короткий

-

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

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

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

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

Сильные и слабые стороны SDLC
Сильные стороны Недостатки
Контроль Увеличенное время разработки
Мониторинг крупных проектов Повышенная стоимость разработки
Подробные шаги Системы должны быть определены заранее
Оценить затраты и цели завершения Жесткость
Документация Затраты сложно оценить, перерасход средств
Четко определенный пользовательский ввод Пользовательский ввод иногда ограничен
Легкость обслуживания Небольшой параллелизм
Стандарты разработки и проектирования Автоматизация документации и стандартов ограничена
Переносит изменения в ИСУ кадрового обеспечения Не терпит изменения требований
Проекты, забронированные на раннем этапе, имеют небольшую ценность или вообще не имеют ценности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поэтапный отказ и утилизация

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

Смотрите также

использованная литература

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

  • Каммингс, Хааг (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 или новее.

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