Бизнес – модель – это описание предприятия как сложной системы с заданной точностью. В рамках бизнес – модели отображаются все объекты, процессы, правила выполнения операций, существующие стратегии развития, а также критерии оценки эффективности функционирования системы. Форма представления бизнес – модели и уровень ее детализации определяются целями моделирования и принятой точкой зрения.
Информационная модель – это подмножество бизнес – моделей, описывающие все существующие, в том числе не формализованные в документальном виде информационные потоки на предприятии, правила обработки и алгоритмы маршрутизации всех элементов информационного поля.
Информационная система – это вся инфраструктура предприятия, задействованная в процессе управления всеми информационно – документальными потоками, включающие в себя следующие обязательные документы.
1) Информационная модель, представляющая собой совокупность правил и алгоритмов функционирования информационной системы. Информационная модель включает в себя все формы документов, структуру справочников и данных и т. д.
2) Регламент развития информационной модели и правила внесения в нее изменений.
3) Кадровые ресурсы, отвечающие за формирование и развитие информационной модели.
4) Программный комплекс, конфигурация которого соответствует требованию информационной модели.
5) Кадровые ресурсы, отвечающие за конфигурирование ПК и их соответствие утвержденной информационной модели.
6) Регламент внесения изменений в конфигурацию ПК и в состав их функциональных моделей.
7) Аппаратно – техническая база, соответствующая требованиям по эксплуатации ПК – это компьютеры на рабочих местах, периферийные устройства, каналы телекоммуникаций, системное ПО и СУБД.
8) Эксплуатационно – технические кадровые ресурсы – включают персонал по обслуживанию аппаратно – технической базы.
9) Правила использования ПК и пользовательские инструкции, регламент обучения и сертификации пользователей.
Существует 3 использующихся подхода к оценке эффективности инвестиций в реализацию информационной системы:
1) Бенчмаркинг – это анализ результатов похожих проектов.
2) Экспертная оценка.
3) Применение метода сбалансированной оценочной стоимости.
Последняя методика позволяет рассматривать ИС как элемент кампании, представляющий собой одно из главных стратегических преимуществ с точки зрения технологичности бизнеса. При создании ИС возникают следующие вопросы: 1) какие новые бизнес – процессы необходимо внедрить, а какие реорганизовать для того, чтобы отдача от использования ИС была максимальной; 2) по каким правилам будет осуществляться управление информационными потоками в новом режиме; 3) не будет ли проявляться сопротивление персонала нововведениям; 4) какой программный комплекс приобретать, стоит ли инвестировать средства, многофункциональное и дорогостоящее решение, или можно обойтись компромиссным вариантом; 5) что делать со старыми программами обработки информации и управления БД: интегрировать приобретаемые решения или уничтожать?
ОСНОВНЫЕ ПОНЯТИЯ И ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТАМИ.
Проект – это временное предприятие, предназначенное для создания уникальных продуктов или услуг.
Управление проектами – это приложение знаний, опыта, методов и средств для удовлетворения требований, предъявляемых к проекту и ожиданий участников проекта. Чтобы удовлетворить этим требованиям и ожиданиям необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта. У проекта обязательно имеется одна или несколько целей. Под целями понимается не только конечный результат проекта, но и выбранные пути достижения этих результатов. Достижение целей проекта может быть реализовано различными способами. Для сравнения этих способов необходимы критерии успешности достижения поставленных целей.
Обычно в число основных критериев оценки вариантов исполнения проекта входят сроки и стоимость достижения результатов, при этом запланированные цели и качества обычно служат основными ограничениями при рассмотрении и оценке различных вариантов.
Для управления проектом необходимы рычаги. Влиять на пути достижения результатов проекта, цели, качество, сроки и стоимость исполнения работ можно выбирая применяемые технологии, состав, характеристики и назначение ресурсов на выполнение тех или иных работ. Информация, использующаяся в управлении проектами обычно не бывает абсолютно достоверной. Учет неопределенности исходной информации необходим и при планировании проекта и для грамотного заключения контрактов. Анализу и учету неопределенностей посвящен анализ рисков.
Любой проект в процессе своей реализации проходит различные стадии, называемые в совокупности жизненным циклом проекта. Для реализации различных функций управления проектом необходимы действия, которые в дальнейшем именуются процессами управления проектами.
ПРОЦЕССЫ УПРАВЛЕНИЯ ПРЕКТАМИ.
Проект состоит из процессов. Процесс – это совокупность действий, приносящая результат. Процессы проекта обычно выполняются людьми и распадаются на две основные группы: 2) процессы управления проектами, касающиеся организации и описания работ проекта; 2). Проекты, ориентированные на продукт, касающиеся спецификации и производства продукта. Эти процессы определяются жизненным циклом проекта и зависят от области приложений.
Процессы управления проектами могут быть разбиты на 6 основных групп.
1)Процессы инициации – это принятие решения о начале выполнения проекта.
2) Процессы планирования – это определение целей и успеха проекта и разработка рабочих схем, их достижения.
3) Процессы исполнения – это координация людей и других ресурсов для выполнения плана.
4) Процессы анализа – это определение соответствия плана и исполнение проекта по поставленным целям и критериям успеха, и принятие решений о необходимости применения корректирующих воздействий.
5) Процессы управления – это определение необходимости корректирующих воздействий, их согласование, применение и утверждение.
6) Процессы завершения – это формализация выполнения проекта и подведение его к упорядоченному финалу.
Процессы управления проектами накладываются друг на друга и происходят с разной степенью интенсивности на всех стадиях проекта.
Процессы управления проектами связаны своими результатами. Результат выполнения одного становится исходной информацией для другого. В реальном проекте фазы могут не только предшествовать друг другу, но и накладываться. Повторение инициации на разных фазах проекта помогает контролировать актуальность выполнения проекта.
I) Процессы инициации.
Инициация включает единственный подпроцесс – авторизацию, т. е. решение начать следующую фазу проекта. Повторение инициации на разных фазах проекта помогает контролировать актуальность выполнения проекта. Если необходимость его осуществления отпала, очередная инициация позволяет вовремя это установить и избежать излишних затрат.
II) Процессы планирования.
Следует различать цели проекта и цели продукта проекта, под которым понимается продукция или услуги, созданные в результате исполнения проекта. Цели продукта – это свойства и функции, которыми должна обладать продукция проекта. Цели проекта – работа, которую нужно выполнить для производства продукта с заданными свойствами. В ходе исполнения проектов процессы планирования многократно повторяются. Изменениям могут подвергнуться цели проекта, его бюджет, ресурсы и т. д. Цели. Кроме того, планирование проекта – это не точная наука, различные команды проекта могут разработать различные планы для одного и того же проекта. Так же может быть составлено различное расписание выполнения работ при одних и тех же исходных данных. Основными процессами планирования являются сроки выполнения и стоимость проекта Они выполняются по несколько раз на протяжении каждой фазы проекта. Кроме основных процессов планирования имеются вспомогательные процессы, необходимость в использовании которых зависит от природы проекта.
1)Планирование качества, т. е. Определение того, какие стандарты качества использовать в проекте и как этих стандартов достичь.
2)Планирование организации, т. е. Определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации.
3) Назначение персонала.
4) Планирование взаимодействия – определение потоков информации и способов взаимодействия, необходимых для участников проекта.
5)Идентификация риска – определение и документирование событий риска, которые могут повлиять на проект.
6) Оценка риска, т. е. Оценка вероятностей наступления событий риска и их характеристик и влияние на проект.
7)Разработка реагирования – определение необходимых действий для предупреждения рисков и реакции на угрожающие события.
8) Планирование поставок.
9) Подготовка условий – выработка требований к поставкам и определение потенциальных поставщиков.
III) Процессы исполнения и контроля.
Под исполнением подразумеваются процессы реализации составленного плана. Исполнение проекта должно регулярно измеряться и анализироваться для того, чтобы выявить отклонения от намеченного плана и оценить их влияние на проект. Регулярное измерение параметров проекта и идентификация возникших отклонений также относится к процессам исполнения и именуется контролем исполнения. Контроль исполнения следует проводить по всем параметрам, входящим в план проекта.
Процессы исполнения можно разделить на основные и вспомогательные. К основным относится сам процесс исполнения плана проекта, а к вспомогательным относятся:
1)Учет исполнения – это подготовка и распределение необходимый для участников проектов информации с требуемой периодичностью.
2) Подтверждение качества – регулярная оценка исполнения проекта с целью подтверждения соответствия принятым стандартам качества.
3) Подготовка предложений – сбор рекомендаций, отзывов, заявок и т. д.
4) Выбор поставщиков – это оценка предложений, выбор поставщиков и подрядчиков, и заключение контрактов.
5) Контроль контрактов.
6) Развитие команды проекта – это повышение квалификации участников проекта.
IV) Процессы анализа.
Включает в себя как анализ плана, так и анализ исполнения проекта. Анализ плана означает определение того, удовлетворяет ли составленный план исполнения проекта предъявляемым к проекту требованиям и ожиданиям участников проекта. Он выражается в оценке показателей плана участниками проекта.
На стадии планирования результатом анализа плана может быть принятие решения о необходимости изменения начальных условий и составлении новой версии плана. Процессы анализа и исполнения предназначены для оценки состояния и прогноза успешности исполнения проекта согласно критериям и ограничениям, определенным на стадии планирования.
Для большинства проектов в число основных ограничений и критериев успеха входят цели, сроки, качество и стоимость работ проекта. При отрицательном прогнозе принимается решение о необходимости корректирующих воздействий, выбор которых осуществляется в процессах управления изменениями.
К основным процессам анализа относятся те процессы, которые непосредственно связаны с целями проекта и показателями, характеризующими успех исполнения проекта.
1)Анализ сроков – это определение соответствия фактических и прогнозных сроков исполнения операций проектом, директивным или запланированным.
2) Анализ стоимости.
3) Анализ качества – это мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определение путей устранения причин нежелательных результатов исполнения качества проектов.
4) Подтверждение целей – это процесс формальной приемки результатов проекта его участниками.
Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:
1)Оценку исполнения, т. е. Анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта.
2) Анализ ресурсов – это определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов в плановом значении. В результате анализа либо принимается решение о продолжении исполнения проекта по намеченному заранее плану, либо определяется необходимость применения корректирующих воздействий.
V) Процессы управления.
Управление исполнением проекта - это определение и применение необходимых управляющих воздействий с целью успешной реализации проекта. Если исполнение проекта происходит с намеченным планом, то управление фактически сводится к исполнению, т. е. доведение до участников проекта плановых заданий и контролю за их реализацией. Если в процессе реализации возникли отклонения, анализ которых показал, что необходимо определение и применение корректирующих воздействий, то требуется найти оптимальное корректирующее воздействие, скорректировать план оставшихся работ и согласовать намеченные изменения со всеми участниками проекта.
Процессы управления предназначаются для определения согласования и внесения необходимых изменений в план проекта. Такие процессы управления называется управлением изменениями и инициируется процессами анализа.
К основным процессам управления, встречающихся практически в каждом проекте относятся:
1)Общее управление изменениями, т. е. определение, согласование, утверждение и принятие к исполнению корректирующих воздействий и координация изменений по всему проекту.
2) Управление ресурсами, т. е. внесение изменений в состав и назначение ресурсов на работы проекта.
3) Управление целями – это корректировка целей проекта по результатам процессов анализа.
4) Управление качеством, т. е. разработка мероприятий по устранению причин неудовлетворительного исполнения.
Среди вспомогательных процессов можно выделить два:
а) управление рисками, т. е. реагирование на события и изменение рисков в процессе исполнения проектов.
б) управление контрактами – это координация работы подрядчиков, корректировка контрактов и разрешение конфликтов.
VI) Процессы завершения.
Завершение проекта сопровождается следующими процессами:
а) закрытие контрактов, включая разрешение всех возникших споров.
б) административное завершение – подготовка, сбор и распределение информации, необходимой для формального завершения проектов.
Все перечисленные процессы приложимы к проектам любой природой, однако имеются и существенные отличия в управлении проектами различных типов.
Успешное внедрение системы управления проектами связано с определенной перестройкой и с внедрением специализированных программных средств.
Модели жизненного цикла.
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:
каскадная модель (70-85 г.г.);
спиральная модель (86-90 г.г.).
В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем [2]:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. 1.1. Каскадная схема разработки ПО
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид (рис. 1.2):
Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Рис 1.3. Спиральная модель ЖЦ
Методологии и технологии проектирования информационных систем.
Общие требования к методологи и технологии.
Методологические, технологические и инструментальные средства проектирования составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность трех составляющих:
1)Пошаговой процедуры, определяющей последовательность технологических операций проектирования;
2) Критериев и правил, используемых для оценки результатов выполнения технологических операций;
3) Нотаций, т. е. графических и текстовых средств, используемых для описания проектируемой системы.
Технологические инструкции, составляющие основное содержание технологии должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция и описание самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:
1)Технология должна поддерживать полный ЖЦПО.
2) Технология должна обеспечивать гарантированные достижения, цели разработки ИС с заданным качеством и в установленное время.
3) Технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем, т. е. возможность декомпозиции проекта на составные части, разрабатываемые группой исполнителей ограниченной численности с последующей интеграцией составных частей.
Для повышения эффективности работ при разработке крупных ИС необходимо разбить проект на отдельные слабосвязанные по данным им функциям подсистемам. При этом необходимо обеспечить координацию ведения общего проекта исключить дублирование результатов работ каждой проектной группы, которая может возникнуть из–за наличия общих данных и функций.
4) Технологи должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3 –7 человек).
Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей. Технология должна обеспечивать минимальное время получения работоспособной ИС.
Здесь речь идет о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечение большого числа разработчиков. При этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков.
Практика показывает что даже при наличии полностью завершенного проекта внедрение идет последовательно по отдельным подсистемам.
5) Технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта, возможность автоматического выпуска проектной документации и синхронизации ее версий с версиями проекта.
6) Технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС. Технология должна быть поддержана комплексом согласованных Case-средств, обеспечивающих автоматизацию процесса, выполняемых на всех стадиях ЖЦ.
Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов, которые должны соблюдаться всеми участниками проекта.
К таким стандартом относятся:
а)Стандарт проектирования.
б) Стандарт оформления проектной документации.
в) Стандарт последовательного интерфейса.
Стандарт проектирования должен устанавливать:
1)Набор необходимых моделей на каждой стадии проектирования и степень их детализации.
2) Правила фиксации проектных решений на диаграммах, в том числе правила именования объектов, набор атрибутов для всех объектов и правила их заполнения на каждой стадии; правила оформления программ включая требования к форме и размерам проекта.
3) Требования конфигурации рабочих мест разработки, включая настройки операционной системы, настройки Case-средств и общие настройки проекта.
4) Механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии. Правила проверки проектных решений на непротиворечивость.
Стандарт оформления проектной документации должен устанавливать:
1)Комплектность, состав и структуру документации на каждой стадии проектирования.
2) Требования к оформлению документации, включая требования к содержанию разделов, подразделов, пунктов, таблиц и т. д.
3) Правила подготовки рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии.
4) Требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации.
5) Требования к настройке Case-средств для обеспечения подготовки документации в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
1)Правила оформления экранов (шрифты, цветовая палитра, состав и расположение окон и элементов управления).
2) Правила использования клавиатуры и мыши.
3) Правила оформления текстов помощи.
4) Перечень стандартных сообщений.
5) Правила обработки реакции пользователя.
Методология RAD.
Одним из возможных подходов к разработке ПО, в рамках спиральной модели ЖЦ, является метод быстрой разработки приложений RAD (Rapid Application Development).
Под ним, обычно понимается процесс разработки ПО, содержащего 3 элемента:
небольшую команду программистов;
короткий, тщательно проработанных, производственный график;
повторяется цикл, при котором разработчики, по мере разработки приложения, запрашивают и реализуют в продукте требования, получаемые через взаимодействие с заказчиком.
Команда разработчиков – группа профессионалов, имеющих опыт в анализе, проектировании, генерации кода, тестировании ПО с использованием CASE- средств.
ЖЦ ПО, по методологии RAD, состоит из 4 фаз:
1. Фаза анализа и планирования требований. Пользователи системы определяют функции, которые она выполняет, выделяют наиболее приоритетные из них (которые прорабатываются в первую очередь). Описывают информационные потребности. Требования определяют пользователи под руководством специалистов – разработчиков. Ограничивается масштаб проекта. Определяются временные рамки для каждой фазы разработки. Определяются возможности реализации данного проекта в установленных рамках финансирования на данных аппаратных средствах и т. д.
Результат фазы: список приоритетов функций будущей ИС. Предварительное функциональное и информационное моделирование ИС.
2. Фаза проектирования. Часть пользователей принимает участие в техническом проектировании системы под руководством специалистов – разработчиков. CASE- средства используются для быстрого получения работающих прототипов приложения. Пользователи, взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и корректируется функциональная модель. Каждая процедура рассматривается более детально. При необходимости для каждого элемента процедуры создаётся частичный прототип, устраняются неясности или неоднозначности. Определяются требования к разграничению доступа к данным. Определяется набор необходимой документации. Оценка количества функциональных элементов. Принимается решение о разделе ИС на подсистемы, поддающиеся обработки одной команды разработчиков за приемлемое время (60 – 90 дней). С использованием CASE- средств проект распределяется между разработчиками.
Результат фазы:
общая информационная модель системы;
функциональные модели в целом и подсистем, реализованные командами разработчиков;
точно определённые, с помощью CASE- средств интерфейсы между подсистемами;
построен прототипы экранов, отчётов, диалогов.
Все модели и прототипы должны быть получены с применением CASE- средств, которые будут использованы в дальнейшем при построении системы. Это требование вызвано тем, что при передаче информации с этапа на этап может произойти неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволит этого избежать. В отличие от традиционных подходов (использование специфических средств прототипирования не предназначенных для построения реальных приложений) в методологии RAD каждый прототип развивается как часть бедующей системы. Таким образом на следующую фазу передаётся более полная и полезная информация.
3. Фаза построения. Быстрая разработка приложения. Разработчики производят интерактивное построение реальной системы на основе полученных в предыдущей фазе моделей, требований не функционального характера. Конечные пользователи на этой фазе оценивают полученные результаты и вносят коррективы, если в процессе разработки система перестаёт удовлетворять определённым требованиям. Тестирование системы осуществляется в процессе разработки. После окончания работ производится интегрирование частей системы с остальными, формирование полного программного кода, тестирование совместной работы данной части приложения с остальными, тестирование системы в целом.
Завершение физического проектирование системы:
1. определяется необходимость распределённых данных;
2. анализ используемых данных;
3. производится физическое проектирование БД;
4. определяются требования к аппаратным ресурсам;
5. определяются способы повышения производительности;
6. завершение разработки документации проекта.
Результат фазы: готовая система, удовлетворяющая всем требованиям.
4. Фаза внедрения. Обучение пользователей. Внедрение новой системы и обслуживание существующих систем.
Так как фаза не продолжительна, от планирование и подготовка к внедрению должны начинаться заранее не этапе проектирования. При разработке рельных проектов возможны различные варианты, напрямую зависящие от начальных условий, в которых ведётся разработка.
Методология RAD применяется для небольших проектов, разрабатываемых для конкретных заказчииков. Она не применима для разработки типовых систем или для построения сложных расчётных программ, разработки ОС и т. д., то есть программ требующих большого объёма уникального кода. Методология так же не подходит для разработки приложений реального времени и приложений от которых зависит безопасность людей. Оценка размера приложения производится на основе функциональных элементов. Она не зависит от языка программирования, на котором ведётся разработка. Размер приложения, который может быть выполнен по методологии RAD для хорошо отлаженной среды разработки ИС, с максимально повторяющимися используемыми программой компонентами, определяется следующим образом:
<1000 функциональных элементов – один человек;
1000 – 4000 функциональных элементов – одна команда разработчиков;
>4000 функциональных элементов – 4000 функциональных элементов на одну команду разработчиков.
Основные принципы методологии RAD:
разработка приложений итерациями;
необязательно полное завершение работ на каждом этапе ЖЦ;
обязательное вовлечение пользователей в процесс разработки ИС;
необходимость применения CASE- средств, обеспечивающих целостность проекта;
применение средств управления конфигурацией, облегчающих внесение изменения в проект и сопровождение готовой системы;
необходимость использования генераторов кода;
использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечных пользователей;
тестирование и развитие проекта, осуществляющее одновременно с разработкой;
ведение разработанного проекта, немногочисленной, хорошо управляемой командой разработчиков;
грамотное руководство разработкой системы, чёткое планирование и контроль выполнения работ.
Структурный подход к проектированию И.С.
Сущность подхода: декомпозиция на автоматические функции. Система разбивается на функции подсистем, которые делятся на подфункции, которые подразделяются на задачи и т. д. Процесс разбиения продолжается до конкретных процедур. И.С. сохраняет целостное представление, в котором все составные компоненты взаимосвязаны. Метод, используемый при разработке системы, называется «сверху–вниз».
При разработке системы «снизу–вверх», от отдельных задач ко всей системе, целостность теряется, возможны проблемы при стыковки отдельных компонентов.
Всё наиболее распространённые методологии структурного подхода базируются на ряде общих принципов, из них два основных:
Разделяй и властвуй – решение сложных проблем путём их разбиения на множество меньших независимых задач легких для понимания и решения.
Иерархическое упорядочивание – организация составных частей проблемы в иерархические древовидные структуры с добавлением новых действий на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы второстепенны, так как игнорирование любого из них может привести к непредсказуемым последствиям, в том числе, к провалу проекта.
Принципы:
Абстрагирование – выделение существенных аспектов системы и отвлечение от несущественных.
Формализация – необходимость строгого методического подхода к решению проблемы.
Непротиворечивость – обоснованность и согласованность элементов.
Структурирование данных – данные должны быть структурированы и иерархичны.
В структурном анализе используются две группы средств, иллюстрирующие функции, выполняемые системой и отношения между данными. К каждой группе средств соответствуют определённые виды модулей (диаграмм), наиболее распространённые:
SADT модели и соответствующие функциональные диаграммы;
DFD – диаграммы потоков данных;
ERD – диаграммы «сущность–связь».
На стадии проектирования И.С. модели расширяются, уточняются и дополняются диаграммами, отражающими структуру ПО: архитектуру ПО, структурные схемы программы и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание И.С., независимо от того является ли она существующей или разрабатываемой.
Состав диаграммы зависит от необходимой полноты описания системы.
Методология функционального моделирования SADT.
Разработана Дугласом Руссом.
Сейчас известна как IDF0.
Методология представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объектов любой предметной области.
Функциональная модель отображает функциональную структуру объекта, то есть производимые им действия и связь между этими действиями.
Основные элементы методологии основываются на следующих концепциях:
Графическое представление блочного моделирования. Графика блоков и дуг SADT диаграммы, отображает функцию в виде блока, а интерфейс входа–выхода – дугой, входящей в блок и выходящей из него. Взаимодействие блоков описывается посредством интерфейсных дуг, выражающих ограничения, которые определяют когда и каким образом функции выполняются и управляются.
Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности. не накладывая чрезмерных ограничений на действия аналитика.
Правила SADT:
ограниченное количество блоков на каждом уровне декомпозиции (3 – 6 блоков);
связность диаграмм;
уникальность меток и наименований;
синтаксические правила для графики;
разделение входов и управлений – правильное определение входных данных;
отделение организаций от функций – исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций. Для разработки системы, удовлетворяющей этим требованиям и реализует эти функции. для уже существующих систем, методология может быть использована для анализа функций, выполняемых системой. Для указания механизмов, посредством которых они осуществляются. Результат применения методологии SADT – модель. которая состоит из диаграмм, фрагментов текстов и глоссариев (словарей) имеющих ссылки друг на друга.
Построение SADT модели начинается с представления всей системы в виде простейшей компоненты одного блока и дуг, изображающих интерфейсы с функциями вне системы. Так как единственный блок представляет всю систему как единое целое, то имя указанное в блоке, является общим. Это и для интерфейсных дуг, они так же представляют полный набор внешних интерфейсов системы в целом. Затем блок детализируется на следующие диаграммы.
При декомпозиции каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Модель не может опустить элементы, так как родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить и ничего удалять.
Дуги, входящие и выходящие из блока, на диаграмме верхнего уровня являются теми, что и дуги входящие в диаграмму нижнего уровня и выходящие из неё. Потому что блок и диаграммы представляют одну часть системы.
Некоторые дуги, присоединённые к блокам диаграммы обоими концами, у других один конец не присоединён. Не присоединённые дуги соответствуют входам, управлению и выходам родительского блока. источник или получатель этих программных дуг может быть обнаружен только на родительской диаграмме. не присоединённые концы должны соответствовать дугам на исходной диаграмме. Все граничащие дуги должны продолжаться на родительской диаграмме, что бы она была полной и не противоречивой.
На SADT не указаны явно ни последовательность ни время. обратные связи, итерации, продолжающиеся процессы, перекрывающиеся по времени функции могут изображаться с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т. д.
Типы связей межу функциями.
Одним из важных моментов проектирования ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают, по крайней мере, 7 типов связывания:
“0” – тип случайной связности- наименее желательный. Случайная связь возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT – дугах в одной диаграмме имеют малую связь друг с другом. В крайнем варианте связь вообще отсутствует.
“1” – тип логической связности. Логическое связывание происходит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается.
“2” – тип временной связности. Связанные во времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.
“3” – тип процедурной связанности. Процедурно связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла и процесса.
“4” – тип коммуникационной связности. Диаграммы демонстрируют коммуникационные связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные или производят одни и те же
выходные данные.
“5” – тип последовательной связности. На диаграммах, имеющих последовательные связи выход одной функции служит входными данными для следующей функции. Связь между элементами диаграммы является более тесной, чем на рассмотренных выше уровнях связок; поскольку моделируются причинно-следственные зависимости.
“6” – тип функциональной связности. Диаграмма отражает полную связность при наличии полной зависимости одной функции от другой. Диаграмма, которая является чисто функциональной не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связности. Одним из способов определения функциональной связности диаграмм является рассмотрение двух блоков, связанных через управляющие дуги.
В математических терминах необходимые условия для простейшего типа функциональной связности имеет следующий вид: C=g(B) = g(f(A))
Значимость |
Тип связности |
Для функции |
Для данных |
0 |
Случайная |
Случайная |
Случайная |
1 |
Логическая |
Функция одного и того же множества или типа |
Данные одного и того же множества или типа |
2 |
Временная |
Функции одного и того же периода времени (операции инициализации) |
Данные используются в каком-либо временном интервале |
3 |
Процедурная |
Функции, работающие в одной и той же фазе или итерации |
Данные, используемые во время одной и той же фазе или итерации |
4 |
Коммуникационная |
Функция, использующая одни и те же данные |
Данные, на которые воздействует одна и та же деятельность |
5 |
Последовательная |
Функции, выполняющие последовательное преобразование одних и тех же данных |
Данные, преобразуемые последовательными функциями |
6 |
Функциональная |
Функции, объединяемые для выполнения одной функции |
Данные, связанные с одной функцией |
Уровни 4-6 устанавливают типы связностей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.
Диаграммы потоков данных (DFD).
DFD являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов или процессов, связанных потоками данных. Главная цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. В основе данной методологии лежит построение модели, анализируемой ИС, проектируемой или реально существующей.
В соответствии с методологией модель системы определяется иерархией диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от её ввода в систему до выдачи пользователю.
Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нужного уровня. Декомпозиция продолжается до тех пор, пока не будет, достигнут такой уровень, на котором процессы становятся элементарными и детализировать их далее невозможно.
Логически диаграмма потоков данных показывает внешние по отношению к системе источники и приемники данных, идентифицирует логические функции и группы элементов данных, связывающую одну функцию с другой, а также идентифицирует хранилища данных, к которым осуществляется доступ.
Структура потоков данных ________________ их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция или процесс может быть детализирована, а содержимое каждого хранилища сохраняет в словаре данных модель данных хранилища ________________.
На DFD не показаны процессы, которые управляют собственным потоком данных и не приводятся различия между допустимыми и недопустимыми путями. DFD позволяют представить систему с точки зрения данных. Они иллюстрируют внешние механизмы подачи данных, а кроме того, позволяют представить как автоматизированные, так и ручные процессы системы и выполняют ориентирование на данные секционирования всей системы.
Потоки данных используют для моделирования передачи информации из одной части системы в другую.
Основные компоненты диаграммы:
внешние сущности;
системы и подсистемы;
процессы;
накопители данных;
потоки данных.
Диаграммы декомпозиций создаются, если родительский процесс не раскрывает структуры системы.
Признаками сложности могут быть:
Наличие большого количества внешних сущностей.
Распределённая природа системы.
Многофункциональность системы с уже сложившимися или выявленной группировкой функций в отдельной подсистеме.
Главная цель построения DFD диаграммы – сделать требования к системе ясными и понятными на каждом уровне детализации, разбить эти требования на части с точно определёнными отношениями между ними. Для достижения этого надо пользоваться правилами:
Не загромождать диаграмму не существенными на данном уровне деталями.
Декомпозиция потоков данных осуществляется параллельно с декомпозицией процессов. Они должны выполняться одновременно, а не последовательно.
Выбирать имена процессов и потоков, отражающих суть.
Размещение на каждой диаграмме от 3 до 6 процессов.
Для проверки контекстной диаграммы можно составить список событий – он должен состоять из описаний действий внешних сущностей и соответствующих реакций системы на события.
Каждое событие должно соответствовать одному или более потоку данных. То есть входные потоки – воздействие, выходные реакция системы на входные потоки.
Каждый процесс может быть детализирован с помощью DFD диаграмм или спецификаций. При детализации должны выполняться правила балансировки и правила нумерации.
Спецификация процесса должна формулировать его основные функции, таким образом, что бы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить эти функции или разработать соответствующую программу.
Спецификация – конечная вершина иерархии DFD. Решение о завершении детализации процесса и использование спецификации принимается аналитиком из-за:
Наличие у процесса относительно небольшого количества входных и выходных потоков данных (2 – 3 потока).
Возможность описания преобразования данных процесса в виде последовательного алгоритма.
Выполнение процессом единственной логической функции преобразования входной информации в выходную.
Возможность описания логики процесса при помощи спецификации небольшого объёма.
Спецификация должна удовлетворять требованиям:
для каждого процесса нижнего уровня должна существовать одна спецификация;
спецификация должна определять способ преобразования входной информации в выходную;
нет необходимости определять метод реализации этого преобразования;
специализация должна стремиться к ограничению избыточности – не следует переопределять то, что уже было определено на диаграмме;
конструктор для построения спецификации должен быть простой и понятный.
Спецификации представляют собой описание алгоритма задачи, выполняемых процессами. Они содержат номер и имя процесса, списки входных и выходных данных и описание процесса, являющиеся спецификацией алгоритма или операции преобразования потока входных данных в выходные.
После построения законченной модели системы, необходимо проверить её на полноту и согласованность. В полной модели все её объекты должен быть подробно описаны и детализированы. В согласованной модели для всех потоков данных должны выполняться правила сохранения информации, то есть все поступающие данные должен быть считаны, все считанные данные должен быть записаны.
Этапы разработки автоматических И.С.
При проектировании А.И.С, вначале необходимо выбрать метод проектирования. После этого необходимо спланировать комплекс работ по созданию системы, в соответствии с типовыми этапами разработки А.И.С.
Наименование этапа |
Основные характеристики |
Метод решения |
Результат |
Разработка и анализ бизнес модели. |
Определение основной задачи А.И.С., проведение декомпозиции задач по модулям, определение функции с помощью которой решаются эти задачи. |
Функциональное моделирование. |
Концептуальная модель А.И.С, состоящая из описания предметной области, ресурсов и потоков данных. Содержит перечень требований и ограничений технической реализации А.И.С, аппаратно – технический состав А.И.С. |
Формализация бизнес модели, разработка логической модели бизнес процесса. |
Разработка концептуальной модели, то есть воплощается в виде логической модели А.И.С. |
Разработка диаграммы «сущность-связь». |
Разработка информационного обеспечения, включающее системы и структуры данных для всех уровней модульности А.И.С., документация по логической структуре А.И.С., сгенерированный скрипты для создания объектов БД. |
Выбор лингвистического обеспечения и разработка программного обеспечения А.И.С. |
Выбирается лингвистическое обеспечение, то есть среды разработки и инструментарий. Проводятся разработки программного и методологического обеспечения, разработанных на втором этапе логическая схема воплощается в реальную. Объекты, логические схемы реализуются в виде объектов БД, а функциональные схемы – в пользовательские формы и приложения. |
Разработка программного кода с использованием выбранного инструментария. |
Работоспособная А.И.С. |
Тестирование и отладка А.И.С. |
Осуществляется корректировка информации аппаратного и программного обеспечения, разрабатывается Оическое обеспечение – разрабатываются документации разработчика и пользователя. |
Оптимальный состав и эффективное функционирование А.И.С. |
Комплект документации, разработчика, администратора и пользователя. |
Эксплуатация и контроль версий. |
Особенность А.И.С. созданной по технологии «клиент-сервер» – их многоуровнивость и многомодульность, при их эксплуатации и развитии на первое место выходит вопрос контроля версий, то есть добавление новых и развитие старых модулей с выводом из эксплуатации устаревших модулей. Если контроль версий не ведётся, то в БД за год эксплуатации насчитывается более тысячи таблиц из которых эффективно работает 20 – 30% |
|
Без избыточный состав гибкой масштабируемой А.И.С. |
Основные понятия электронного документооборота
Документ – это совокупность трех составляющих:
1)Физическая регистрация информации
2) Форма представления информации
3) Активизация определенной деятельности
Именно некоторая деятельность и превращает информацию в документ. Документ перестает существовать, если в дальнейшем не подразумевает процедуры обработки, при этом форма документа тесно связана с характером дальнейшей деятельности.
Документ – это слабоструктурированная совокупность блоков или объектов информации, понятная человеку.
Бюрократическая технология – это технология взаимодействия людей, служб и подразделений внутри и вне организации.
Собственно документооборот может быть двух типов:
1)Универсальный, т. е. Автоматизирующий существующие информационные потоки слабоструктурированной информации.
2) Операционный, т. е. Ориентированный на работу с документами, содержащими операционную атрибутику, вместе с которой ведется слабоструктурированная информация.
Кроме документов важен регламент работы с ними, т.к. работа не по регламенту отнимает больше времени, чем производственная деятельность. Правильно рассматривать документ как инструмент распределения функций между работниками.
К основным преимуществам электронного документооборота можно отнести следующие:
1)полный контроль за перемещением и эволюцией документа, регламентация доступа и способ работы пользователей с различными документами и их отдельными частями.
2) уменьшение расходов на управление за счет высвобождения людских ресурсов, занятых различными видами обработки бумажных документов, снижения бюрократической волокиты за счет маршрутизированного перемещения документов и жесткого контроля за порядком и сроками прохождения документов.
3) Быстрое сохранение новых документов из уже существующих.
4) Поддержка одновременной работы многих пользователей с одним и тем же документом, предотвращение его потери или порчи.
5) Сокращение времени поиска нужных документов.
6) Использование автоматизированной ИС может рассматриваться в качестве базы для общего совершенствования управления предприятием, при этом управление предприятием реализует следующие основные функции:
а) обслуживание клиентов;
б) разработка продукции;
в) учет и контроль за деятельностью предприятия;
г) финансовое обеспечение деятельности предприятия.
Комплексная автоматизация этих функций требует создания единого информационного пространства предприятия, в котором сотрудники и руководство могут осуществлять свою деятельность руководствуясь едиными правилами представления и обработки информации в документном и бездокументном виде. Для этого в рамках предприятия требуется создать единую ИС по управлению информацией или единую систему управления документами, включающую следующие возможности:
1) возможность удаленной работы, когда члены одного коллектива могут работать в разных местах;
2) возможность доступа к информации, когда разные пользователи должны иметь доступ к одним и тем же данным без потерь в производительности и независимо от своего местоположения в сети;
3) возможности средств коммуникации;
4) возможность сохранения целостности данных в общей БД;
5) возможность полного текстового и реквизитного поиска информации;
6) открытость системы, когда пользователи должны иметь доступ к привычным средствам создания документов и уже существующим документам, созданным в других системах;
7) защищенность информации;
8) удобство настройки на конкретные задачи пользователей;
9) возможность __________________ системы для поддержки роста организации и защиты вложенных инвестиций.
Начальным этапом создания такой системы является построение модели предметной области или модели документооборота для конкретного бизнеса или позиционирования в ней своего предприятия. Направление автоматизации документооборота – это поддержка фактографической информации, возможность работы с полнотекстовыми документами и поддержка регламента прохождения документов определяют трехмерное пространство свойств программного продукта данного класса.
Ось “F” характеризует уровень организации хранения фактографической информации, которая привязана к специфике конкретного рода деятельности кампании или организации.
Информация из операционных документов используется при аналитической обработке и может быть получена пользователем через систему отчетов.
Ось “D” отражает необходимость организации взаимодействия, т. е. Формирования и передачи товаров, услуг или информации как внутри организации, так и вне ее.
В этих документах наряду с фактографической информацией содержится слабоструктурированная информация не подлежащая автоматизированной аналитической обработке. Вне взаимоотношения между субъектами бизнеса сопровождаются документами. Которые становятся отражением результата взаимодействия.
О
сь
“R” вносит в пространство
документооборота регламент процессов
прохождения документов, а именно –
описание того, какие процедуры, когда
и как должны выполняться.
Точка в пространстве осей RFD определяет состояние системы документооборота и положение этой точки зависит от уровня развития и стадии внедрения системы документооборота на предприятии, а также от его специфики и самих масштабов бизнеса.
Представив одель документооборота именно таким образом, можно, зная текущее положение дел с организацией делопроизводства на каждом конкретном предприятии , четко представить в каких направлениях нужно двигаться дальше, чего не достает в текущий момент и каким образом использовать уже существующие системы автоматизации.
Чем круче кривая, представленная в трехмерном пространстве координат RFD, тем быстрее идет процесс модернизации, а чем больше значение всех трех координат, тем выше уровень автоматизации на предприятии, как следствие. Тем меньше проблем с организацией своей совместной деятельности.
Эволюция модели.
Модель документооборота имеет три основных фазы своей эволюции.
1) Фактографическая. Начало любой деятельности характеризуется обычным периодом накопления первичной информации, имеющую жесткую структуру и атрибутику. Точка оси “F” – это текущее состояние системы документооборота организации. Движение по этой оси вверх характеризует накопление фактографической информации и начиная с определенного момента можно отметить возникновение понятия операция. На этом этапе начинается процесс возникновения неравенства между ранее равноправными документами. После возникновения привязки к конкретным бизнес процессам ____________________ Дальнейшая эволюция документооборота в одномерном пространстве уже невозможна. Необходим переход к новой фазе.
2) Полнотекстовая. Расширение функций и круга решаемых задач требует использования полнотекстовых документов включающих тексты и любые другие способы представления (графики, таблицы, видео и т. д.).
Кроме фактографической базы документов имеются архивы и хранилища информации.
Хранилища позволяют накапливать документы различных форматов, наличие их структуризации и поиск. Организация разграничения доступа, расширение средств поиска, иерархия хранения, возникновение понятия «электронная подпись», шифрование.
С определённого момента развития хранилища, можно говорить не об индивидуальном, а о корпоративном архиве, обслуживающий деятельность рабочей группы. Доступ к документам может быть осуществлен по маршруту любого уровня сложности с соблюдением различных уровней конфиденциальности.
Состояние системы документооборота соответствующее точке А позволяет осуществить синхронизацию работы различных групп сотрудников. Система для этой точки, предполагает структурирование информации по уровням управления и наличие средств репликации данных. Именно из этой точки осуществляется переход к очередной фазе.
3) Регламентирующая. Нормальный документооборот не возможен без решения вопросов согласования или без соблюдения регламента работы. Если на второй фазе присутствовал один простейший регламент: каждый сотрудник имел доступ к архиву или его части, то сейчас этого не достаточно. Требуется контроль за тем, как работник выполнил задание или как продвигается документ в условиях процесса своего согласования.
Третья ось в пространстве документооборота предприятия имеет своё деление на этапы.
Первоначальный этап движения по оси характеризуется наличием упрощённого регламента, отображающего появления атрибутов, отвечающих за регламент (например: оплатить до).
Количество накопленных атрибутов и расширение возможностей по управлению регламентом сопровождается постепенным переходом ко второму этапу, отличительная черта которого – появление системы, специально предназначенной для отслеживания процессов соблюдения регламента. Далее появление единой системы управления проектом. Теперь документ в системе документооборота становиться вторичным, а первичным – цель бизнес процесса, то есть сам процесс реализации бизнес процедур, оставляющих после себя документы.
Оси F и D определяют специфику деятельности организации, регламентируемую положением третей координаты r в пространственной модели документооборота. Модель не зависит от технологии обработки документов, принятых на предприятии. Всё решает только цель деятельности: будь-то государственная организация, торговая компания или промышленная фирма.
В общем случае можно определить три типа организаций:
Банк и торговая компания – приобретение, наценка, продажа, получения прибыли – главный объект деятельности.
Бюджетные организации – формирование документов.
Промышленные предприятия – операция, то есть закупка сырья, переработка, создание нового продукта, реализация, получения прибыли.
Если задачи организации – формирование документов, то её позиция в модели будет занимать достаточной высокое положение, относительно осей F и D.
Если рассматривать деятельность банка или производственного предприятия, задача которой производство операций и материальных ценностей, то здесь все три координаты должны иметь сбалансированное значение.
Методология создания И. С.
Цель: организация процесса построения И. С. и обеспечения управления этим процессом для гарантии выполнения требований к самой И. С. и к характеристикам процесса разработки.
Основные задачи методологии создания И. С. вместе с соответственным набором инструментов:
Обеспечение создания И. С., отвечающих предъявленным требованиям по автоматизации деловых процессов и отвечающих целям и задачам организации.
Гарантировать создание системы с заданным качеством в заданные сроки и в рамках бюджета.
Поддерживать удобную дисциплину сопровождения модификаций и наращивание системы, чтобы И. С. могла отвечать на быстро изменяемые требования работы компании.
Обеспечить создание И. С., отвечающей требованиям открытости, переносимости и масштабируем ости.
Обеспечит использование в разработанной И. С., за дела в области технологий, существующих в организации: программное обеспечение, БД.
Методология должна обеспечивать снижение сложности процесса создания И. С., за счёт полного и точного описания этого процесса и применение современных методов и технологий создания И. С. на всём жизненном цикле И. С. от замысла до реализации.
Методология описывает процесс создания и сопровождения И. С. в виде жизненного цикла И. С., представленного в виде последовательности стадий, каждая из которых разбита на этапы и выполняемых на них процессах. Для каждого этапа определяется последовательность выполняемых работ, полученные результаты, методы и средства, необходимых для выполнения работ, роли и ответственность участников. Такое формальной описание жизненного цикла И. С. позволяет спланировать и организовать процесс коллективной разработки и обеспечит управление этим процессом.
Процесс создания И. С. представляет собой процесс построения и последовательного преобразования согласованных моделей, на всех этапах жизненного цикла начиная от системы моделей, описываемых деятельность организации, до готовой И. С. Модели должны создаваться, преобразовываться, контролироваться с помощью соответствующих CASE средств и сохраняться в репозитории (архиве).
Отправной точкой в процессе создания И. С. – модели бизнес процессов, протекающих в организации и реализующих её цели и задачи. Если построенная компьютерная модель организации, описанная в терминах бизнес процессов и бизнес функций, то из этой модели может быть получено большинство важнейших требований к И. С.
Это фундаментальное положение методологии позволяет объективно подойти к требований и проектировании И. С. Создание системы моделей, описание требований к И. С., которая преобразуется в систему моделей, описываемых проектирование И. С. Формируются модели архитектуры И. С., требования к программному обеспечению и информационному обеспечению. Затем формируется архитектура программного и информационного обеспечения, выделяется Б. Д. и отдельные приложения, их разработка, тестирование и внедрение.
Методология анализа И. С. на основе бизнес процессов.
Целью начальных этапов создания И. С., выполняемых на стадии анализа, является формирование требований к И. С., корректно и точно отражающих цели и задачи организации.
Для описания процесса создания И. С., отвечающей целям и задачам организации, нужно выяснить в чём заключаются эти цели и задачи, выяснить требования закащика к И. С. и преобразовать их на языке моделей в требования к разработке проекта И. С. так, чтобы обеспечить соответствие целям и задачам организации.
Основу деятельности любой организации составляют ее деловые процессы или бизнес-процессы, которые определяются целями и задачами организации. Процессы обеспечивают реализацию всех видов деятельности организации, связанных с производством товаров и услуг, которые предприятие либо производит, либо продает и поставляет, либо делает все это в совокупности.
Каждый бизнес-процесс характеризуется четкоопределенными во времени началом и завершением, нешними интерфейсами, которые либо связывают связывают его с другими бизнес-процессами внутри организации, либо описываю выход во внешнее окружение и последовательностью выполняемых работ, а также бизнес-правилами их выполнения.
Для каждой работы, входящей в бизнес процесс, определены временные характеристики, определяющие ее место в общей последовательностиработ, условия инициации и время выполнения. В отличии от описания организациина основе иерархической, функциональной структуры, которую невозможно объективно оценить, описание на основе процессов, позволяет точно представить цели, характеристики, в том числе динамические, и конечный результат каждого вида деятельности организации.
Исходя из того, что основные бизнес-процессы реализуют по своей природе цели и задачи организации, методология предлагает строить описание деятельности организаии какпроцесс создания и развития систем согласованных моделей, основанных на моделях бизнесс-процессов.
В процессе детализации моделей и их последующей интеграции должно обеспечиваться сохранение всех функциональных свойств, отражающих цели и задачи организации и согласованности модели. Такая согласованность обеспечивается методолоргией и поддерживающими ее современными Case-средствами.
В процессе описания организации и ее деятельности формируются три основных системы моделей организации: 1)Стратегическая; 2)Укрупненная; 3)Детальная. Все эти системы моделей, описывая основные аспекты организации и ее детальности, базируются на бизнесс-процессах. В систему моделей описания организации добавлена также дополнительная система моделей для того, чтобы можно было учесть аспекты, не связанные с бизнес-процессами, но необходимые при создании ИС.