«система». Лекция автоматизированные экономические информационные системы
Скачать 0.87 Mb.
|
ЛЕКЦИЯ 4.ЖИЗНЕННЫЙ ЦИКЛ АЭИС.Стадии жизненного цикла АЭИС.Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла. АЭИС существуют, как правило, на протяжении длительного отрезка времени, последовательно проходя в своем развитии несколько стадий. Жизненный цикл – период создания и использования АЭИС, охватывающий ее различные состояния, начиная с момента возникновения необходимости в данной автоматизированной информационной системе и заканчивая моментом ее полного выхода из употребления у пользователей. На протяжении всего ЖЦ система должна эффективно выполнять свои функции при их изменениях в пределах требований, обусловленных развитием системы, и адекватно реальным информационным потребностям пользователей. В нее также должны быть заложены свойства, которые позволяют оперативно и без существенных затрат модернизировать функционирующую АЭИС в соответствии с изменениями в организационной структуре, методах управления, плановых, учетных и отчетных показателей. Жизненный цикл АЭИС позволяет выделить несколько стадий. В разных источниках приводится от 3 до 8 основных стадий жизненного цикла. предпроектная стадия; проектная стадия; реализация и внедрение; функционирование. От качества проектных работ зависит эффективность функционирования системы. Поэтому каждая стадия разделяется на несколько этапов, в течение которых выполняется определенная последовательность работ. Результаты работ фиксируются в соответствующих документах. Основными работами, выполняемыми на стадиях и этапах проектирования, можно считать: 1 стадия – предпроектное обследование (анализ предметной области) 1 этап – сбор материалов для проектирования: изучение объекта проектирования; формирование требований пользователей к АЭИС; проведение необходимых научно-исследовательских работ; технико-экономическое обоснование необходимости разработки АЭИС; 2 этап – анализ материалов и формирование документации: детальный анализ автоматизируемых бизнес-процессов; разработка и выбор варианта концепции системы; разработка и утверждение технического задания. 2 стадия – проектирование 1 этап – эскизное проектирование – разработка предварительных проектных решений по системе и её частям (мнемосхемы): разработка вариантов структурной схемы системы; состав и способы формирования информационного обеспечения; укрупненные схемы алгоритмов обработки данных; 2 этап – техническое проектирование (логическое проектирование): поиск наиболее рациональных проектных решений по всем аспектам разработки; создание и описание компонентов системы; создание и утверждение технического проекта; 3 этап – рабочее проектирование (физическое проектирование): разработка и доводка программ; корректировка структур БД; создание рабочего проекта; подготовка инструкций пользователей; 3 стадия – ввод системы в действие: 1 этап – подготовка к внедрению: установка и ввод в эксплуатацию технических средств; наполнение баз данных; опытная эксплуатация программ; обучение персонала; строительно-монтажные работы; пусконаладочные работы; проведение предварительных испытаний; 2 этап – опытные испытания системы перед сдачей в промышленную эксплуатацию; 3 этап – проведение приемочных испытаний; 4 стадия – промышленная эксплуатация: сопровождение программных средств; оперативное обслуживание системы; администрирование баз данных. Модели жизненного цикла АЭИС.ЖЦ носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т.п. На каждом этапе ЖЦ порождается определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Каждый этап завершается верификацией порожденных документов и решений с целью проверки их соответствия исходным. Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ: каскадная модель; поэтапная модель с промежуточным контролем; спиральная модель. Каскадная модельКаскадная модель (70-80г.г.) - предполагает переход на следующий этап после полного окончания работ по предыдущему этапу. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Каскадная схема разработки Положительные стороны применения каскадного подхода заключаются в следующем: на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; этапы работ выполняются в логичной последовательности; возможно жестко планирование сроков завершения работ и соответствующих затрат. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружилось, что реальный процесс создания системы никогда полностью не укладывался в такую жесткую схему. В процессе создания системы постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания системы принимал следующий вид: Реальный процесс разработки по каскадной схеме Недостатки каскадной схемы Существенная задержка с получением конечного результата. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания АЭИС, пользователи получают систему, не удовлетворяющую их потребностям. Функциональные и информационные модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут устареть одновременно с их утверждением. Несоответствие разработанной системы ожиданиям заказчика. Разработчики делали не ту систему, о которой мечтал заказчик или, тем более, пользователи, а ту, которую представляли себе проектировщики-аналитики, а затем программисты. Превышение сроков и сметы разработки или искажение требований к системе. Примитивная автоматизация существующих производственных процессов. Система часто фиксировала неправильные способы работы, может быть, наносящие вред предприятию. По словам аналитиков, до сих пор при проектировании системы легче идти по проторенному пути документирования сложившегося бумажного потока, чем определять насущные потребности производственной деятельности. Разработчики не могли, а зачастую не могут и до сих пор добиться с помощью системы качественно новых результатов, позволяющих оптимально управлять производством в целом, динамически менять управление производственными процессами на предприятии. Кроме всего прочего, такой подход встречал скрытое и явное сопротивление работников предприятий. До сих пор в большинстве случаев реальная польза отечественных АСУ и зарубежных MIS для производства была минимальна. В значительной степени в этом были повинны методы организации разработки информационных систем, в том числе - "каскадная" схема разработки. Несмотря на то, что информационные системы в идеале были предназначены для повышения эффективности производства, различные способы совершенствования собственно процессов управления производством развивались параллельно и почти независимо от информационных технологий. Классические методологии стали неприемлемы из-за того, что они порождают системы, обладающие следующими недостатками: Монолитность. Приложения, которые трудно разделяются на части и тяжелы в сопровождении, потому что изменение любой части такой системы непредсказуемо влияет на другие части. Повторное использование особенно труднодостижимо, каждое новое приложение нужно писать сначала, даже если большие части были уже написаны для других приложений. Монолитные приложения часто характеризуются как жесткие, негибкие и в то же время хрупкие - это побочный эффект существующей монолитности. Централизованность. Приложения не могли быть распределены на отдельные компьютеры. Это тоже побочный эффект существующей монолитности. Трудность использования. Приложения были ориентированы на неинтеллектуальный терминал, тяжелы в обучении и использовании. Поэтапная модель с промежуточным контролем.Поэтапная модель с промежуточным контролем (80-85 гг.) - итерационная модель разработки АЭИС с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; однако время жизни каждого из этапов растягивается на весь период разработки. Спиральная модельСпиральная модель (86-90 гг.) делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Специалистами отмечаются следующие преимущества спиральной модели: накопление и повторное использование программных средств, моделей и прототипов; ориентация на развитие и модификацию системы в процессе ее проектирования; анализ риска и издержек в процессе проектирования. Именно поэтому спиральная модель служит в настоящее время основой для создания методологий проектирования систем. |