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

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

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

Обзор

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

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

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

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

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

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

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

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

Фазы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ

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

Дизайн

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

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

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

Среды

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

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

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

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

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

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

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

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

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

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

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

Оценка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иерархическая структура работ^[17]

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

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

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

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

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

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

• Создание прототипов программного обеспечения
• Совместная разработка приложений (JAD)
• Быстрая разработка приложений (РАД)
• Экстремальное программирование (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
• Компьютерный мир, 2002 г., Получено 22 июня 2006 г. из Интернета:
• Информационные системы управления, 2005 г., Получено 22 июня 2006 г. из Интернета:
• Статья основана на материалах, взятых из Бесплатный онлайн-словарь по вычислительной технике до 1 ноября 2008 г. и зарегистрированы в соответствии с условиями «перелицензирования» GFDL, версия 1.3 или новее.

внешняя ссылка

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

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