К системами более высокого уровня развития жизненного цикла, с универсального применения

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

Введение

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

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

Все системные исследования начать с выявления проблемных областей или идеи для улучшения. Уровень детализации, порожденные этой неофициальной стадии планирования, возможно, колеблется от простого словесного описания с небольшое или никакое расследование более официальное письменное заявление с изложением сути проблемы, а также руководящие принципы для дальнейшего расследования. В любом случае, этот неофициальный процесс планирования результатов проекта, который прошел на группу исследования систем официального расследования, которое обычно следует за гораздо более формальной методологии, о чем свидетельствуют "Предварительное расследование" шагом в SDLC выбор для организации. По Брага (2001, стр. 95), "... SDLC есть, на самом высоком уровне, о процессе приверженности проекта системы ...." То, что команда системное исследование предоставляется для официального расследования, однако, существенно различается и во многих случаях не хватает какого-либо официального определения. Это отсутствие формального определения иногда приводит к повторению на этапе планирования в ходе официального расследования. Есть проблемы с этим подходом: дублирование усилий, неэффективное использование ресурсов, и часто выявление и исследование области полностью отличается от 1 намерению составителя, ..

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

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

Проблемы

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

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

Решение

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

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

Новая парадигма

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

Структура UDP

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

Анализ

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

Планирование

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

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

Дизайн используется как общий термин, с момента его коннотацию оно не может быть подходящей для конкретного проекта. В приобретение новой бизнес-единицы или приобретение программного продукта, дизайн не является основным направлением является приобретение. Тем не менее, дизайн играет важную роль в любом проекте. Как это новое подразделение, чтобы он соответствовал текущей корпоративной состав? Как можно взаимодействия необходимо от приобретения лучше всего достичь? В области развития систем, как это может приобрели продукт укладывается в смесь систем в настоящее время в эксплуатации? Что должно быть сделано, чтобы максимально использовать преимущества этого нового приобретения программного обеспечения? Продукты разные, но проблем совпадают. Дизайн, как правило, рассматривать как процесс проектирования всего приложения системы, а не приобретение всей прикладной системы. Вместо приобретения вспомогательных заполнить потребность в цели организации, компания может разработать новые заводы и операций. Будь покупку или строительство решение 1, дизайн требуется только уровень конструктивных изменений.

Осуществление

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

Когда графики были созданы, выделяемых ресурсов, и осуществление планов, направленных, фактическое выполнение, или осуществление этих планов раскрывается, в результате чего к желаемому результату в плоды. Колеса приводятся в движение. Приобретение предложение представлено. Рекламная программа уже осуществляется. Программа развития начинается. Ведь подготовка, D-день приезжает.

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

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

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

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

Преимущества и приложения

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

Такой же принцип, то применяется, хотя Существуют различия в программу, основанную на площади концентрации. Исполнительной рассматривает приобретение другого бизнеса связана с синергизм понял, путем слияния двух компаний. Менеджер по маркетингу, а с другой стороны, такие вопросы, как определение доступных рынке для продукта. В обоих случаях процесс после прийти к выводу то же самое. В настоящее время мутации SDLC, применяются в различных приложениях, включая, но не ограничиваясь, для разработки учебных мультимедиа и развития (Бисли, 1999/2000), финансового обеспечения системы (Smokovich и Каррингтон, 2002), планирования ресурсов предприятия (ERP) осуществления (Ахитувом, Неймана и Zviran, 2002), а также систему хроматографии обновления данных проекта (Томпсон, Матч, Брэдли, и Стивенс, 2003).

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

Три утверждения возникнуть: (1) Все методики похожи на макро-уровне. (2) Многие методологические различия существуют на микроуровне. (3) Все методики зависит от задачи и возможности решения.

Заключение

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

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

Ссылки

Бисли, Роберт Э. (1999/2000). Учебные программы мультимедиа развитие: последствия для анализа и проектирования этапах SDLC. Журнал по компьютерным информационным системам, 40 (2), 2.

Брага, Cathal (2001). Последствия от принятия Наука системы Жизненный цикл разработки в области информационных систем. Информационные системы границ, 3 (1), 91.

Smokovich Михаил и Ангелы Каррингтон (2002). Rx для управления 21-го века финансового обеспечения системы: Семь M на успех. Журнал управления государственными финансами, 51 (2), 36.

Ахитувом, Нив, Seev Неймана, и Моше Zviran (2002). Методология разработки системы для систем ERP. Журнал по компьютерным информационным системам, 42 (3), 56.

Томпсон, Терри, Мариан Матч, Джейн Брэдли, и Никола Стивенс (2003). Утверждение и внедрение системы хроматографии данных. Фармацевтическая технология Европы, Кливленд: Mar, стр. 46.

Уильям Мур

Айви Тек Стейт Колледж

Эрнест Нолан

Университет Южной Индианы

Sharlett Гиллард

Университет Южной Индианы