Модель жизненного цикла - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ.
Наибольшее распространение получили две основные модели ЖЦ:
· каскадная модель (70-85 гг.);
· спиральная модель (86-90 гг.).
Каскадная модель
Каскадный способ - разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис.2).
Положительные стороны применения каскадного подхода:
· на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
· выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи.
Рис.2 Схема каскадного подхода
Однако реально в процессе создания ИС постоянно возникает потребность в возврате к предыдущим этапам, уточнении или пересмотре ранее принятых решений. Реальный процесс создания информационной системы принимает следующий вид (рис.3):
Рис.3 Реальный процесс создания ИС на базе каскадной модели
Одно из использовавшихся в западной литературе названий такой схемы организации работ: "водопадная модель" (waterfall model).
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Другой недостаток - такое проектирование информационной системы ведет к примитивной автоматизации (по сути - "механизации") существующих производственных действий работников.
В спиральной модели жизненного цикла (рис.4) делается упор на начальные этапы ЖЦ: анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов.
Рис 4.
Каждый виток спирали соответствует созданию нового фрагмента или версии информационной системы, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также "Продолжающимся проектированием". Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это называлось: "быстрое прототипирование", rapid prototyping approach или "fast-track".
Однако применение таких методов наряду с быстрым эффектом дает снижение управляемости проектом в целом и стыкуемости различных фрагментов информационной системы. Основная проблема спирального цикла - определение момента перехода на следующий этап. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Тема 1.2 Жизненный цикл АИС и модели жизненного цикла АИС
Жизненный цикл АИС – это непрерывный процесс с момента принятия решения о необходимости принятия решения о необходимости ее создания до полного завершения ее эксплуатации.
Продолжительность жизненного цикла современных АИС составляет около 10 лет, что значительно превышает сроки морального и физического старения технических и системных программных средств, используемых при реализации АИС. Поэтому, как правило, в течение ЖЦ системы проводится ее модернизация, после чего все функции системы должны выполняться с не меньшей эффективностью.
Добиться этого на протяжении всего ЖЦ АИС - довольно сложная по ряду объективных и субъективных причин задача, в результате подавляющее большинство проектов АИС внедряется с нарушениями качества, сроков или сметы; почти треть проектов прекращают свое существование незавершенными. По данным Standish Group в 1996 г. 84 % проектов АИС не были завершены в установленные сроки, в 1998 г. это число сократилась до 74 %, после 2000 г. оно не опускается ниже 50 %. Главной причиной такого положения является то, что уровень технологии анализа и проектирования систем, методов и средств управления проектами не соответствует сложности создаваемых систем, которая постоянно возрастает в связи с усложнением и быстрыми изменениями бизнеса.
Из мировой практики известно, что затраты на сопровождение прикладного программного обеспечения АИС составляют не менее 70 % его совокупной стоимости на протяжении ЖЦ, поэтому крайне важно еще на проектной стадии предусмотреть необходимые методы и средства сопровождения, включая методы конфигурационного управления.
Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями):
ГОСТ 34.601-90 - стандарт на стадии и этапы создания АИС, соответствующие каскадной модели ЖЦ ПО (рассматривается ниже). Приводится описание содержания работ на каждом этапе;
180/1ЕС 12207:1995 - стандарт на процессы и организацию жизненного цикла; распространяется на все виды заказного программного обеспечения; не содержит описания фаз, стадий и этапов;
Custom Develoment Method (методология Oracle) - технологический материалпо разработке прикладных АИС, детализированный до уровня заготовок проектных документов в расчете на использование Oracle.Применяется для классической модели ЖЦ (предусмотрены все работы, задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.
Rational Unified Process (методология RUP )- технологический материал по реализации итеративной модели разработки, включающей четыре фазы (цикл разработки): начало, исследование, построение и внедрение. Каждая фаза разбита на этапы (итерации), результатами которых являются версии для внутреннего или внешнего использования. Каждый цикл завершается генерацией очередной версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова проходит те же фазы. Суть работы в рамках RUP-методологии - создание и сопровождение моделей на базе UML;
Microsoft Solution Framework (методология MSF ) - технологический материал по реализации итеративной модели разработки, аналогично RUP включает четыре фазы: анализ, проектирование, разработку, стабилизацию; предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений;
Extreme Programming (ХР) - экстремальное программирование (самая новая среди рассматриваемых методологий); сформировалось в 1996 г. Основой методологии является работа в команде, эффективные коммуникации между заказчиком и исполнителем в течение всего проекта; разработка АИС ведется с использованием последовательно дорабатываемых прототипов.
Стандарт ISO/IЕС 12207 в структуре жизненного цикла определяет процессы, которые выполняются при создании ПО АИС. Эти процессы подразделяют на три группы:
основные (приобретение, поставка, разработка, эксплуатация и сопровождение);
вспомогательные (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит и решение проблем);
организационные (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).
Среди основных процессов жизненного цикла самыми важными являются разработка, эксплуатация и сопровождение. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами.
Разработка АИС включает все работы по созданию программного обеспечения и его компонентов в соответствии с заданными требованиями. Этот процесс также предусматривает:
Оформление проектной и эксплуатационной документации;
Подготовку материалов, необходимых для тестирования разработанных программных продуктов;
Разработку материалов, необходимых для обучения персонала.
Как правило, составляющими процесса разработки являются стратегическое планирование, анализ, проектирование и реализация (программирование).
К процессу эксплуатации относятся:
Конфигурирование базы данных и рабочих мест пользователей;
Обеспечение пользователей эксплуатационной документацией;
Обучение персонала.
Основные эксплуатационные работы включают:
Непосредственно эксплуатацию;
Локализацию проблем и устранение причин их возникновения;
Модификацию программного обеспечения;
Подготовку предложений по совершенствованию системы;
Развитие и модернизацию системы.
Профессиональное, грамотное сопровождение - необходимое условие решения задач, выполняемых АИС. Службы технической поддержки играют весьма заметную роль в жизни любой АИС. Ошибки на этом этапе могут привести к явным или скрытым финансовым потерям, сопоставимым со стоимостью самой системы.
К предварительным действиям при организации технического обслуживания АИС относятся:
Выделение наиболее ответственных узлов системы и определение для них критичности простоя (это позволит выделить наиболее критичные составляющие АИС и оптимизировать распределение ресурсов для технического обслуживания);
Определение задач технического обслуживания и их разделение на внутренние, решаемые силами обслуживающего подразделения, и внешние, решаемые специализированными сервисными организациями (таким образом, четко ограничивается круг исполняемых функций и производится распределение ответственности);
Проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции (основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала);
Подготовка плана организации технического обслуживания с определением этапов исполняемых действий, сроков их исполнения, затрат на этапах, ответственности исполнителей.
Обеспечение качественного технического обслуживания ШС требует привлечения специалистов высокой квалификации, которые в состоянии решать не только ежедневные задачи администрирования, но и быстро восстанавливать работоспособность системы при сбоях и авариях.
Среди вспомогательных процессов одним из главных является управление конфигурацией, которое поддерживает основные процессы жизненного цикла АИС, прежде всего процессы разработки и сопровождения.
Разработка сложных АИС предполагает независимую разработку компонентов системы, что приводит к появлению многих вариантов и версий реализации как отдельных компонентов, так и системы в целом. Таким образом, возникает проблема обеспечениясохранения единой структуры в ходе разработки и модернизации АИС. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты АИС на всех стадиях ее ЖЦ.
Организационные процессы имеют очень большое значение, так как современные АИС - это большие комплексы, в создании и обслуживании которых занято много людей разных специальностей.
| Процесс(исполнитель процесса) | Действия" | Вход | Результат |
| Приобретение (заказчик) | Инициирование. Подготовка заявочных предложений. Подготовка договора. Контроль деятельности поставщика. Приемка АИС | Решение о начале работ по внедрению АИС. Результаты обследования деятельности заказчика. Результаты анализа рынка АИС/тен-дера. План поставки/разработки. Комплексный тест АИС | Технико-экономическое обоснование внедрения АИС. Техническое задание на АИС. Договор на поставку/разработку. Акты приемки этапов работы. Акт приемо-сдаточных испытаний |
| Поставка (разработчик АИС) | Инициирование. Ответ на заявочные предложения. Подготовка договора. Планирование исполнения. Поставка АИС | Техническое задание на АИС. Решение руководства об участии в разработке. Результаты тендера. Техническое задание на АИС. План управления проектом. Разработанная АИС и документация | Решение об участии в разработке. Коммерческие предложения/конкурсная заявка. Договор на поставку/разработку. План управления проектом. Реализация/корректировка. Акт приемо-сдаточных испытаний |
| Разработка (разработчик АИС) | Подготовка. Анализ требований к АИС. Проектирование архитектуры АИС. Разработка требований к ПО. Проектирование архитектуры ПО. Детальное проектирование ПО. Кодирование и тестирование ПО. Интеграция ПО и квалификационное тестирование ПО. Интеграция ИС и квалификационное тестирование АИС | Техническое задание на АИС. Техническое задание на АИС, модель ЖЦ. Техническое задание на АИС. Подсистемы АИС. Спецификации требования к компо-" нентам ПО. Архитектура ПО. Материалы детального проектирования ПО. План интеграции ПО, тесты. Архитектура ИС, ПО, документация на ИС, тесты | Используемая модель ЖЦ, стандарты разработки. План работ. Состав подсистем, компоненты оборудования. Спецификации требования к компонентам ПО. Состав компонентов ПО, интерфейсы с БД, план интеграции ПО. Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам. Тесты модулей ПО, акты автономного тестирования. Оценка соответствия комплекса ПО требованиям ТЗ. Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ |
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков, конроля сроков и качества выполнения работ. Техническое и организационное обеспечение проекта включает:
Выбор методов и инструментальных средств реализации проекта;
Определение методов описания состояния процесса разработки;
Разработку методов и средств испытаний созданного программного обеспечения;
Обучение персонала.
Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов АИС.
Верификация - процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.
Проверка - процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидаемыми результатами, а также для оценки соответствия характеристик АИС исходным требованиям.
В 2002г. Был опубликован стандарт на процессы ЖЦ автоматизированных систем (ISO/IEC 15288 System Life cycle processes). В разработке стандарта участвовали специалисты из различных областей деятельности; учитывался практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ включены следующие группы процессов.
1. Договорные процессы:
Приобретение (внутренние решения или решения внешнего поставщика);
Поставка (внутренние решения или решения внешнего поставщика).
2. Процессы предприятия:
Управление окружающей средой предприятия;
Инвестиционное управление; в управление ЖЦ ИС;
Управление ресурсами;
Управление качеством.
3. Проектные процессы:
Планирование проекта;
Оценка проекта;
Контроль проекта;
Управление рисками;
Управление конфигурацией;
Управление информационными потоками;
Принятие решений.
4. Технические процессы:
Определение требований;
Анализ требований;
Разработка архитектуры;
Внедрение;
Интеграция;
Верификация;
Переход;
Аттестация;
Эксплуатация;
Сопровождение;
Утилизация.
5. Специальные процессы:
Определение и установка взаимосвязей исходя из задач и целей.
В табл. 1.4 приведены перечень стадий и основные результаты к моменту их завершения в соответствии с указанным стандартом.
В 1970-х гг. корпорация IBM предложила методологию Business System Planning (BSP) или методологию организационного планирования.
Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений систем обработки данных (ИС), информационных объектов, документов и баз данных, предложений в BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить процессы классы данных, привести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.
Таблица 1.4. Стадии создания АИС (ISO/IEC 15288)
По опубликованным данным каждый этап разработки АИС требует определенных затрат времени. В основном (45-50 %) время уходит на кодирование, комплексное и автономное тестирование (рис.14). В среднем разработка АИС занимает одну треть всего ЖЦ системы (рис.1.5).
Рис.1.4. Распределение времени при разработке АИС
ЖЦИС - это период создания и использования ИС, начиная с момента возникновения потребности в ИС и заканчивая моментом полного ее выхода из эксплуатации.
Стадии жизненного цикла информационной системы:
1. Предпроектное обследование:
· сбор материалов для проектирования, при этом выделяют формулирование требований, с изучения объекта автоматизации, даются предварительные выводы предпроектного варианта ИС;
· анализ материалов и разработка документации, обязательно дается технико экономическое обоснование с техническим заданием на проектирование ИС.
2. Проектирование:
2.1 предварительное проектирование;
· выбор проектных решений по аспектам разработки ИС;
· описание реальных компонент ИС;
· оформление и утверждение технического проекта (ТП).
2.2 детальное проектирование:
· выбор или разработка математических методов или алгоритмов программ;
· корректировка структур БД;
· создание документации на доставку и установку программных продуктов;
· выбор комплекса технических средств с документацией на ее установку.
2.3 разработка техно-рабочего проекта ИС (ТРП).
2.4 разработка методологии реализации функций управления с помощью ИС и описанием регламента действий аппарата управления.
3. Разработка ИС:
· получение и установка технических и программных средств;
· тестирование и доводка программного комплекса;
· разработка инструкций по эксплуатации программно-технических средств.
4. Ввод ИС в эксплуатацию:
· ввод технических средств;
· ввод программных средств;
· обучение и сертификация персонала;
· опытная эксплуатация;
· сдача и подписание актов приемки-сдачи работ.
5. Эксплуатация ИС:
· повседневная эксплуатация;
· общее сопровождение всего проекта.
Модели жизненного цикла информационной системы :
· каскадная модель - предлагает переход на следующие этапы после полного осуществления работ по предыдущему этапу. Модель демонстрирует классический подход в любых прикладных областях;
· итерационная модель - поэтапная модель с промежуточным контролем и циклами обратной связи. Преимущество данной модели - поэтапные корректировки, которые обеспечивают меньшую трудоемкость по сравнению с каскадной. Однако время жизни каждого из этапов рассчитывается на весь период разработки;
· спиральная модель - данная модель делает упор на начальные этапы анализа и проектирования. Эта модель представляет собой итерационный процесс разработки, где каждая итерация (цикл), представляет собой законченный цикл разработки, приводящий к выпуску версии изделия (версии проекта ИС), который совершенствуется от итерации к итерации, чтобы стать значимой информационной системой. При этом каждый виток спирали соответствует поэтапной модели создания информационной системы. Т.о. углубляется и последовательно конкретизируется обоснованный вариант ИС, который и доводится впоследствии до реализации.
Основные способы построения ИС:
· разработка системы "под себя";
· использование прототипов - вместо полной системы создается прототип, отвечающий основным потребностям пользователей:
Определение основных запросов;
Создание рабочего прототипа;
Использование рабочего прототипа;
Пересмотр и улучшение прототипа;
Работа с окончательной версией прототипа;
· использование услуг сторонней организации для передачи функций управления ИС - организация использует специализированную фирму, которая выполняет управляющие функции по функционированию и развитию ИС компании.
Плюсы:
· гарантийное качество обслуживания;
· экономия денежных средств;
· человеческие ресурсы.
Минусы:
· не дешево;
· утечка информации;
· зависимость;
· потеря контроля за ИТ.
Систему управления экономическим объектом можно рассматривать как совокупность двух взаимосвязанных элементов (двух составных частей): субъекта управления (СУ) и объекта управления (ОУ).
Субъект управления представляет собой управленческий аппарат, объединяет в себе сотрудников, разрабатывающих планы, вырабатывающих требования к принимаемым решениям, а также контролирующих их выполнение.
Объект управления представляет собой непосредственно предприятие, которое осуществляет выполнение поставленных перед ним задач. В задачу объекта управления входит выполнение планов, выработанных управленческим аппаратом, т.е. реализация той деятельности, для которой создавалась система управления.
Субъект управления и объект управления связаны прямой и обратной связями. Прямая связь выражается потоком директивной информации, направляемой от управленческого аппарата к объекту управления, а обратная представляет собой поток отчетной информации о выполнении принятых решений, направляемый в обратном направлении (см. рис.12).
Директивная информация порождается управленческим аппаратом в соответствии с целями управления и информацией о сложившейся экономической ситуации, об окружающей среде. Отчетная информация формируется объектом управления и отражает внутреннюю экономическую ситуацию, а также степень влияния на неё внешней среды (задержки платежей, нарушения подачи энергии, погодные условия, общественно - политическая ситуация в регионе и т.д.). Таким образом, внешняя среда влияет не только на объект управления: она поставляет информацию и управленческому аппарату, решения которого зависят от внешних факторов (состояние рынка, наличие конкуренции, величина процентных ставок, уровень инфляции, налоговая и таможенная политика).
Взаимосвязь информационных потоков (П и О), средств обработки, передачи и хранения данных, а также сотрудников управленческого аппарата, выполняющих операции по переработке данных, и составляет информационную систему экономического объекта.
Потребность в управлении возникает при необходимости координации деятельности членов трудового коллектива, объединенных для достижения поставленных перед ними локальных и глобальных целей. Первоначально любая цель носит обобщенный характер и лишь в процессе уточнения она формализуется управленческим аппаратом в виде целевых функций.
В процессе управления экономическим объектом принимаются оперативные , тактические и стратегические решения. В соответствии с этим, обычно говорят, что управленческий аппарат состоит из трех уровней управления: оперативного , среднего ивысшего .
На высшем уровне управления экономическим объектом находятся менеджеры-руководители. Они определяют цели управления, внешнюю политику, материальные, финансовые и трудовые ресурсы, разрабатывает долгосрочные планы и стратегию их выполнения. В их компетенцию обычно входит проведение анализа рынка, уровня конкуренции, конъюнктуры и поиск альтернативных стратегий развития предприятия на случай выявления угрожающих тенденций в сфере его интересов.
На среднем уровне управления экономическим объектом находятся менеджеры-исполнители. На этом уровне основное внимание сосредоточено на составлении тактических планов, контроле за их выполнением, слежении за ресурсами и разработке управляющих директив для вывода предприятия на требуемый планами уровень.
На оперативном уровне управления экономическим объектом находятся менеджеры структурных подразделений (отделов, служб, цехов и т.д.). На данном уровне происходит реализация планов и составляются отчеты о ходе их выполнения. Основная задача оперативного управления заключается в согласовании всех элементов производственного процесса во времени и пространстве с необходимой степенью его детализации.
На каждом из уровней управления экономическим объектом выполняются работы, в комплексе обеспечивающие управление. Эти работы принято называть функциями. В зависимости от целей можно выделить функции различной степени общности. Типичными являются следующие функции: планирование , учет и контроль , анализ и регулирование .
Планирование - функция, посредством которой в идеальной форме реализуется цель управления. Планирование занимает значительное место в деятельности высшего руководства, меньшее - на среднем и минимальное - на оперативном уровне. Планирование на высшем уровне управления касается будущих проблем и ориентировано на длительный срок. На среднем уровне планирование осуществляется на более короткий срок, при этом план высшего уровня управления детализируется. Показатели на этом уровне более точные. Оперативное управление предполагает самую детальную проработку плана.
Учет и контроль - функции, направленные на получение информации о ходе работы предприятия проверки соответствия достигнутых результатов с плановыми. Учет принято подразделять на оперативный , бухгалтерский и статистический . Бухгалтерский учет в свою очередь может подразделяться на финансовый и управленческий . Учет в основном осуществляется на оперативном и среднем уровнях управления. На высшем уровне управления учет отсутствует, однако на его основе в полной мере выполняются анализ результатов производства и регулирование его ходом.
Анализ и регулирование - это сопоставление фактических показателей с нормативными (директивными, плановыми), определение отклонений, выходящих за пределы допустимых параметров, установление причин отклонений, выявление резервов, нахождение путей исправления создавшейся ситуации и принятие решения по выводу объекта управления на плановую траекторию. Действенным инструментом для выявления причин отклонений является факторный анализ, а для поиска путей выхода из создавшейся ситуации -э кспертные системы.
Взаимосвязь между уровнями управления и осуществляемыми ими функциями по объему выполняемых работ представлена в табл.7.
Н а рис. 12 представлена взаимосвязь основных этапов процесса управления экономическим объектом.
Любая деятельность компании отражается в документах, и, чтобы улучшить качество рабочих бизнес-процессов, необходимо улучшить документооборот, т. е. оптимизировать его. Под оптимизацией документооборота понимается комплекс мер организационного, технического, программно-технического и проектного характера, выполняемых организацией.
Применение данных методологий в ходе построения моделей бизнес-процессов в виде иерархии диаграмм, обеспечивает наглядность и полноту их отображения, позволяет анализировать деятельность предприятия.
IDEF0 - первый информационный разрез -- функциональность системы. Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 она может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок.
Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:
- - Стрелки входа (входят в левую грань работы) -- изображают данные или объекты, изменяемые в ходе выполнения работы.
- - Стрелки управления (входят в верхнюю грань работы) -- изображают правила и ограничения, согласно которым выполняется работа.
- - Стрелки выхода (выходят из правой грани работы) -- изображают данные или объекты, появляющиеся в результате выполнения работы.
- - Стрелки механизма (входят в нижнюю грань работы) -- изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы).
- - Стрелки вызова (выходят из нижней грани работы) -- изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.
Все работы и стрелки должны быть именованы. Первая диаграмма в иерархии диаграмм IDEF0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными. В контекст диаграммы входит описание цели моделирования, области (описания того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точки зрения (позиции, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.
В данной работе именем модели «Учет посещаемости в детском саду», имя проекта «Учет посещаемости в детском саду», имя автора и тип модели - Ощепков Максим и Time Frame: AS - IS (Как есть).
Цель работы (Purpose) - Моделировать текущие бизнес-процессы сотрудника IT-отдела, точку зрения (Viewpoint) - инженера-системотехника. Внесем определение модели: «Это модель, ведет учет посещаемости в детском саду» и цель: «Ведение учета посещаемости, регистрация выполненных работ, организация поиска и отчетности».
Первая диаграмма в иерархии диаграмм IDEF0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными (рисунок 2).
Рисунок 2. Контекстная диаграмма «Учет посещаемости в детском саду»
В соответствии с методом IDEF0 определим входные данные, выходные данные, управление и механизм, которые изображаются на диаграмме стрелками:
- - Входные данные: Заявка сотрудника с указанием причины неработоспособности ПК и его номера.
- - Выходные данные: Различные виды отчетности, исправленные и неисправленные комплектующие.
- - Управление: Законодательство, правила и инструкций.
- - Механизм: Сотрудники IT-отдела и других отделов организаций.
После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на рисунке 3.
Рисунок 3. Диаграмма декомпозиции «Учет посещаемости в детском саду»
Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции.
Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS-IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO-BE).
BPwin автоматически синхронизирует изменения объектов диаграмм на всех уровнях детализации, тем самым освобождая пользователя от ручного ведения словаря объектов модели. Так если мы исправим на верхнем уровне название объекта, то получим изменение на всех уровнях, где данный объект встречается. Также невозможным является случайное дублирование наименований работ. При появлении такой ситуации BPwin генерирует предупреждающее сообщение.
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации.
Описание презентации Этапы создания АИС Модели жизненного цикла АИС по слайдам
Жизненный цикл АИС -совокупность стадий и этапов, которые проходит АИС в своем развитии от момента принятия решения о создании системы до момента прекращения ее функционирования.
Этапы жизненного цикла 1 Планирование и анализ (предпроектная стадия) – определение того, что должна делать система. Оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ).
2 Проектирование (техническое и логическое проектирование) – определение того, как система будет функционировать (спецификация* подсистем, функциональных компонентов и способов их взаимодействия). Оформление технического проекта. * Спецификация — точное, полное, ясно сформулированное описание требований для данной задачи.
3. Реализация (рабочее проектирование, программирование) — Создание функциональных компонентов и отдельных подсистем, соединение подсистем в единое целое. Заполнение БД. Создание инструкций для персонала. Оформление рабочего проекта
4 Внедрение (тестирование, опытная эксплуатация) – установка и ввод системы в действие, отладка подсистем, обучение персонала. Оформление акта о приемо-сдаточных испытаниях.
Замечания 1. Этапы 2 и 3 можно объединить в одну: техно-рабочее проектирование или системный синтез. 2. На каждом этапе жизненного цикла используется определенный набор технических решений и соответствующих документов
3. Для каждого этапа исходными являются документы и решения принятые на предыдущем этапе. 4. Модели жизненного цикла определяют порядок исполнения этапов в процессе создания системы и критерии перехода от этапа к этапу.
Модель жизненного цикла — это модель создания и использования АИС, которая отражает различные состояния системы с момента возникновения до момента его полного выхода из употребления.
Основные модели ЖЦ Каскадная – предполагает переход на следующий этап после полного завершения работ предыдущего. Эта модель используется при построении АИС для которых с самого начала точно и полно сформулированы все требования. Недостатки: жесткая схема – невозможность возврата к предыдущим этапам и использование для сложных систем.
Поэтапная итерационная модель Предполагает наличие обратной связи между циклами. Преимущество в том, что межэтапные корректировки обеспечивают большую гибкость и меньшую трудоемкость. Недостаток – время жизни каждого из этапов может растянуться на весь период создания системы.Трудности и недостатки спиральной модели ЖЦ Основная проблема — определение перехода на следующий этап: для ее решения вводятся временные ограничения на каждый из этапов. Переход осуществляется в соответствии с планом составленным на основе статистических данных предыдущих проектов и опыта разработчиков. Недостатки: ошибки, допущенные на этапах анализа и проектирования, могут привести к проблемам на следующих этапах и к неуспеху всего проекта.
Роль пользователя АИС создается для удовлетворения информационных потребностей конкретного пользователя. Он принимает непосредственное участие в ее работе. .
Пользователь участвует в постановке задачи и проводит опытную эксплуатацию, в ходе которой может обнаружить недостатки постановки, корректировать входную и выходную информацию, формы выдачи результатов и оформление документов.
Участие пользователя в создании АИС обеспечивает оперативное и качественное решение задач, сокращает время на внедрение новых технологий