В настоящее время информационная индустрия стала новой отраслью технологий, приносит пользователям большую выгоду. Поэтому в современных условиях руководитель организации должен владеть знаниями методических основ создания ИС. Знание методических основ создания и использования ИC тесно связано с развитием и совершенствованием управленческих процессов.
Основоположником кибернетики (науки о системах и методы управления) является Норберт Винер (США). Труды его последователей стали фундаментом теории автоматического управления. Это наука об общих законах получения, хранения, передачи и преобразования информации в сложных системах управления. Применение компьютерной техники для решения задач управления привело к развитию теории информации, теории кодирования, сформировался самостоятельное научное направление информатика. Результаты этих исследований легли в основу разработки методологии применения технических и программных средств для решения задач различной практической направленности.
Экономические объекты стали рассматриваться как сложные системы, а управление ими отождествляться с информационным процессом. Интенсивное развитие возможностей компьютерной техники и сферы ее применения привел к созданию в экономических объектах человеко-машинных ИС. Назначением ИС стал не только информационное сопровождение производственных и хозяйственных процессов, решения функциональных задач управления внутри организации, но и информационное взаимодействие между различными связанными между собой организациями в производственной, хозяйственной и информационном аспектах.
Основоположником единых методических подходов в проектировании ИС был академик В.М. Глушков, который сформулировал научно-методические положения и практические рекомендации по созданию автоматизированной информационной системы. Основными принципами единых методических подходов является :
1. Принцип системности, который является важнейшим при создании, функционировании и развитии ИС. Он рассматривает исследуемый экономический объект, как единое целое. При этом, устанавливает направления производственно-хозяйственной деятельности организации и конкретные функции, реализуемые ею; обнаруживает различные типы связей между его структурными элементами обеспечивая целостность системы. Принцип системности предполагает проведение в организации двух аспектного анализа, а именно макро- и микроанализа. При макроанализе система и (или) ее "элементы рассматриваются как часть системы более высокого порядка. Особое внимание уделяется информационным связям: устанавливаются их направления движения, выделяются и анализируются те связи, которые обусловлены целью функционирования и исследования объекта, а затем выбираются наиболее предпочтительны, учитываемых в процессе проектирования ИС. При макроанализе изучаются все аспекты деятельности организации, анализируются ее структурные составляющие (включая деятельность на каждом рабочем месте) с целью их функциональных характеристик, проявляющихся через связи с другими элементами и внешней средой.
При проектировании ИС для организационной структуры управления экономическим объектом наиболее характерна многоуровневая иерархическая структура. Иерархическая структура для каждого уровня системы дает возможность различных сочетаний локальных критериев оптимальности с глобальным критерием оптимальности функционирования системы в целом; обеспечивает относительную гибкость системы управления и возможность приспосабливаться к изменяющимся условиям; повышает надежность за счет возможности введения элементной избыточности, упорядочения направлений потоков информации. Преимущества иерархических структур способствовали их широкому распространению в системах управления и определяли организационно - функциональный подход к созданию ИС. Накопленный при этом опыт оказал влияние на современный процессный подход при проектировании ИС.
Практическое значение применения системного принципа заключается в том, что он позволяет в доступной для анализа форме не только выявить интересует создателей системы, но и использовать компьютерное моделирование для исследования поведения проектируемой системы в конкретных, заданных экспериментатором условиях. Поэтому в основе создания ИС лежит метод моделирования, позволяет находить наиболее приемлемые и обоснованные проектные решения, варианты построения системы и тем самым обеспечивать наибольшую эффективность функционирования экономического объекта.
2. Принцип развития, который заключается в том, что ИС создается с учетом возможности постоянного пополнения и обновления функций системы и видов ее обеспечения. Его суть в том, что развивающиеся производственные и управленческие процессы, усложняются и перестраиваются организационные структуры экономических объектов - это вызывает необходимость наращивания вычислительных мощностей ИС, оснащение их новыми техническими и программными средствами для постоянного пополнения и обновления решаемых задач, расширение информационного фонда, создается в виде баз и хранилищ данных, баз знаний.
3. Принцип информационный, который направлен на детальное и всестороннее изучение информации и информационных процессов, сопровождающих процессы управления в экономическом объекте. Информация изучается в семантическом (содержательном), синтаксическом (знаковом) и прагматическом (полезном) аспектах. Кроме этого, изучение информации необходимо для проектирования автоматизированных рабочих мест, систем передачи, хранения и обработки данных, защиты информации, где основными являются знания объемов, содержания и полезности сведений.
В настоящее время на информационном подходе основывается объектно ориентированный метод моделирования информационных процессов и автоматизации проектных работ для анализа управленческих процессов и проектирования информационных электронных потоков.
4. Принцип совместимости, который заключается в обеспечении взаимодействия ИС различных видов, назначений, уровней в процессе функционирования экономического объекта. Поэтому в процессе проектирования должна быть обеспечена системная единство методических подходов в решении проблем информационной, технической, программной совместимости всех ИС, используемых. Единство методических подходов отражается в нормативно-правовых документах, регламентирующих процесс разработки, документирования, приема и эксплуатации ИС. Это международные и отечественные стандарты (ГОСТ), отраслевые и ведомственные нормативные материалы, регламенты, протоколы, стандарты организаций.
Широко используются стандарты, регламентирующие языковые средства информационной обработки, коммуникационные технологии и организации вычислений, между объектная взаимодействие и тому подобное.
5. Принцип стандартизации и унификации, который заключается в необходимости применения типовых, унифицированных и стандартизованных элементов функционирования ИС. Это прежде всего относится к составляющим информационного, технического, программного и других обеспечительных подсистем IT. Этот принцип позволяет сократить временные, трудовые и стоимостные затраты на создание ИС при максимально возможном использовании накопленного опыта в формировании проектных решений и внедрении автоматизации проектировочных работ, обеспечивает многоаспектную взаимодействие ИС.
6. Принцип декомпозиции, который основан на разделении системы на части и выделении отдельных комплексов работ, создает условия для более эффективного анализа существующего состояния управленческой деятельности, изучение особенностей решения функциональных задач для дальнейшего моделирования конкретных аспектов управленческой деятельности и перевода их на автоматизированную технологию. Принцип используется как при изучении особенностей свойств элементов и системы в целом, так и при создании ИС на новой информационно-технологической базе.
7. Принцип эффективности, который заключается в достижении рационального соотношения между затратами на создание ИС и целевым эффектом, получаемый при ее функционировании.
Описание жизненного цикла информационной системы предполагает оперирование такими понятиями:
Процесс - цепочка работ, последовательно выполняются;
Этапы - последовательные отрезки времени, в течение которого выполняются работы. В течение этапа могут выполняться работы, относящиеся к разным процессам. В основе деятельности по созданию и использования автоматизированной информационной системы управления экономическим объектом лежит понятие ее жизненного цикла (ЖЦ). Жизненный цикле моделью создания и использования, автоматизированной информационной системы управления экономическим объектом, отражающим различные ее состояния, начиная с момента возникновения и необходимости в ней и заканчивая моментом полного выхода из использования всех без исключения пользователей .
Традиционно выделяют следующие основные этапы ЖЦ АИС :
Анализ требований;
Проектирование;
Программирование / внедрения;
Тестирование и отладка;
Эксплуатация и сопровождение.
Рассмотрим подробнее основные этапы ЖЦ АИС:
1. Анализ требований является первой фазой разработки АИС, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?", А это успехом всего проекта. В практике создания больших систем известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.
Перечень требований к АИС должен включать:
1) совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования, состав работников и работ, имеющих к ней отношение)
2) описание функций, которые должен выполнять система;
3) ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
Целью анализа является преобразование общих, нечетких знаний о требованиях к будущей системе в точные (по возможности) определения.
Результатом этапа должна быть модель требований к системе (то есть - системный проект), что значит:
1) архитектуру системы, ее функции, внешние условия, разделение функций между аппаратной и программной частями;
2) интерфейсы и разделение функций между человеком и системой;
3) требования к программным и информационных компонентов программной части: необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент программной части, их интерфейсы.
Модель требований должна включать;
1) полное функциональную модель требований к будущей системе с глубиной обработки до уровня каждой операции каждого должностного лица;
2) спецификации операций нижнего уровня;
3) пакет отчетов и документов по функциональной модели, включающей характеристику объекта моделирования, перечень подсистем, требования к способам и средствам связи для информационного обмена между компонентами, требования к характеристикам взаимосвязей системы со смежными системами, требования к функциям системы;
4) концептуальную информационную модель требований;
5) пакет отчетов и документов по информационной модели;
6) архитектуру системы с привязкой к концептуальной информационной модели;
7) предложения по организации структуры для поддержки системы.
Таким образом, модель требований содержит функциональную, информационную и, возможно, событийный (в случае, если целевая система является системой реального времени) модели. Это обеспечивает ряд преимуществ по сравнению с традиционной моделью, а именно:
1) Для традиционной разработки характерно осуществление начальных этапов кустарными неформализованными способами. Поэтому заказчики и пользователи впервые могут увидеть систему после того, как она уже в значительной мере реализована. Естественно, эта система будет отличаться от той, которой они ожидали. Поэтому дальше иметь место еще несколько итераций ее разработки или модификации, требует дополнительных (и значительных) затрат денег и времени. Ключ к решению этой проблемы и дает модель требований, позволяет
Описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;
Уменьшить затраты на разработку и внедрение системы;
Оценить разработку по времени и результатам;
Достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами)
Улучшить качество разрабатываемой, а именно: выполнить ее функциональную декомпозицию и спроектировать оптимальную структуру интегрированной базы данных.
2) Модель требований полностью независимая и отделена от конкретных разработчиков, не требует сопровождения ее создателями и может быть безболезненно передана другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации системы на основе модели требований, она может быть оставлена "на полке" до тех пор, пока в ней не возникнет необходимость.
3) Модель требований может быть использована для самостоятельной разработки или корректировки уже реализованных на ее основе программных средств силами программистов отдела автоматизации предприятия.
4) Модель требований может использоваться для автоматизированного и быстрого обучения новых работников конкретному направлению деятельности предприятия, поскольку ее технология содержится в модели.
Этап анализа требований является важнейшим среди всех этапов ЖЦ. Он существенно влияет на все последующие этапы, оставаясь в то же время наименее изученным и понятным процессом. На этом этапе, во-первых, нужно понять, что именно нужно сделать, а во-вторых, задокументировать это, потому что если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должна быть достаточно простой и понятной заказчику.
2. Разработка технического задания выполняется после построения модели, содержит требования к будущей системе. На ее основе разрабатывается техническое задание по созданию системы, включающей в себя:
Требования к автоматизированным рабочим местам, их состава и структуры, а также к способам и схем информационного взаимодействия между ними;
Разработку требований к техническим средствам;
Определение требований к программным средствам;
Разработку топологии, состава и структуры локальной вычислительной сети;
Требования к этапам и срокам выполнения работ.
3. Проектирование. Этот этап дает ответ на вопрос: "Как (каким образом) система будет удовлетворять требованиям, предъявляемым к ней? Задачей этого этапа
Есть исследования структуры системы 1 логических взаимосвязей элементов, причем здесь не затрагиваются вопросы, связанные с реализацией на конкретной платформе. Проектирование рассматривается как итерационный процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед ней, а также написание спецификаций физической системы, удовлетворяет этим требованиям. Этот этап обычно разделяют на два подэтапа:
Проектирование архитектуры системы, включая разработку структуры и интерфейсов компонентов, согласование функций и технических требований к компонентам, методов и стандартов проектирования;
Детальное проектирование, которое предусматривает разработку спецификаций каждого компонента, интерфейсов между компонентами, разработку требований к тестам и плана интеграции компонентов.
Иными словами, проектирование является этапом ЖЦ, на котором определяется, как следует реализовывать требования к ЛЕС, порожденные и зафиксированы на этапе анализа. В результате должна быть построена модель реализации, которая демонстрирует, как система будет удовлетворять предъявленные к ней требования (без технических подробностей). Фактически модель реализации является развитием и уточнением модели требований, а именно проектирования является мостом между анализом и реализацией.
4. Реализация (программирование / адаптация). На этом этапе осуществляется создание ЛЕС, как комплекса программно-аппаратных средств (начиная с проектирования и создания телекоммуникационной инфраструктуры и заканчивая разработкой и установкой приложений).
5. Тестирование и отладка. Корректность АИС является ее важнейшим свойством и главным предметом заботы разработчиков. В идеальном случае под корректностью 1C подразумевают отсутствие в ней ошибок. Однако для большинства сложных программных продуктов достичь этого невозможно (в каждой программе содержится хотя бы одна ошибка). Поэтому под "корректным" обычно понимают программный продукт, работающий в соответствии с предъявленных к нему требований, то есть - продукт, для которого пока еще не найдены такие условия, в которых он окажется неработоспособным.
Установление корректности является главной целью этапа жизненного цикла, рассматривается. Надо отметить, что этап тестирования и отладки - один из самых трудоемких, утомительных и непредсказуемых этапов разработки ИС. В среднем за разработки традиционными методами этот этап занимает от 1/2 до 1/3 всего времени разработки. С другой стороны, тестирования и отладки представляют собой серьезную проблему: в некоторых случаях тестирования и отладки программы требуют в несколько раз больше времени, чем непосредственно программирования.
Тестирование - это набор процедур и действий, предназначенных для демонстрации корректной работы ИС в заданных режимах и внешних условиях. Цель тестирования - выявить наличие ошибок или убедительно продемонстрировать их отсутствие, что возможно лишь в отдельных тривиальных случаях. Важно различать тестирования и сопутствующее понятие "отладка". Отладка - это набор процедур и действий, которые начинаются с выявления самого факта наличия ошибки и заканчиваются установлением точного места, характера этой ошибки и способов ее устранения.
Важнейшим и наиболее часто применяемым на практике является метод детерминированного тестирования. При этом в качестве эталонов тестов используются конкретные исходные данные, состоящие из взаимосвязанных входных и результирующих величин и правильных последовательностей их обработки. В процессе тестирования с заданными начальными величинами надо установить соответствие результатов их обработки эталонным значениям.
Для сложных систем требуется большое количество тестов, и возникает проблема оценки их необходимого количества и использования методов их сокращения. Поэтому тестирование (как и любой другой вид деятельности) целесообразно планировать. План тестирования должен содержать:
1) формулировка целей тестирования;
2) критерии качества тестирования, позволяющие оценить его результаты;
3) стратегию проведения тестирования, обеспечивающий достижение заданных критериев качества;
4) потребности в ресурсах для достижения заданного критерия качества по выбранной стратегии.
Существуют системы автоматизация тестирования и отладки (Сатна). Они представляют собой сложный комплекс алгоритмических и программных средств, предназначенных для автоматизации анализа АИС, тестирования, отладки и оценок ее качества, и позволяет облегчить модификацию компонент АИС, обеспечить выявление ошибок на ранних стадиях отладки, повысить процент ошибок, автоматически оказываются.
6. Эксплуатация и сопровождение. Основными задачами этого этапа являются:
Обеспечение устойчивости работы системы и сохранения информации - администрирование;
Своевременная модернизация и ремонт отдельных элементов - техническая поддержка;
Адаптация возможностей системы, эксплуатируемого с текущими потребностями бизнеса предприятия - развитие системы.
Эти работы необходимо включать в оперативный план информатизации предприятия, который должен формироваться обязательно с соблюдением всех условий стратегического плана. В противном случае в рамках существующей системы могут появиться фрагменты, которые в будущем сделают эффективную эксплуатацию системы невозможной. Сейчас за рубежом стало общепринятым передавать функции технической поддержки и частично администрирования поставщикам системы или системным интеграторам. Эта практика получила название "аутсорсинг". Часто в пределах аутсорсинга сторонним предприятиям передаются и такие функции, как создание и поддержка резервных хранилищ данных и центров выполнения критических бизнес-приложений, которые задействуются в случае стихийного бедствия или других особых условий.
Особое внимание на этапе эксплуатации и сопровождения нужно уделить вопросам обучения персонала и, соответственно, планированию инвестиций в этот процесс.
ЖЦ образуется в соответствии с принципом нисходящего проектирования и обычно имеет итерационный характер: реализованные этапы, начиная с самых первых, циклически повторяются в соответствии с изменениями требований и внешних условий, введение ограничений и т. На каждом этапе ЖЦ порождается определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Каждый этап завершается верификацией порожденных документов и решений с целью проверки соответствия их выходным.
Существующие модели ЖЦ определяют порядок выполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили следующие три модели ЖЩ4]:
1. Каскадная модель (70 - 80-е годы) предусматривает переход к следующему этапу после полного завершения работ на предыдущем этапе и характеризуется четким разделением данных и процессов их обработки (рис. 2.6).
Рис. 2.6. Каскадная модель жизненного цикла ИС
2. Поэтапная модель с промежуточным контролем (80 - 85-е годы) - итерационная модель разработки с циклами обратной связи между этапами. Преимущество такой модели в том, что между этапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жизни каждого из этапов растягивается на весь период разработки.
3. Спиральная модель (86 - 90-е годы) - заостряет внимание на начальных этапах ЖЦ: анализе требований, проектировании спецификаций, предыдущем и детальном проектировании. На этих этапах проверяется и обосновывается реализуемость технических решений созданием прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации (рис. 2.7.).
Рис. 2.7. Спиральная модель жизненного цикла ИС
Специалисты отмечают такие преимущества спиральной модели:
Накопление и повторное использование программных средств, моделей и прототипов;
Ориентация на развитие и модификацию системы в ходе ее проектирования;
Анализ риска и издержек в процессе проектирования.
При использовании спиральной модели происходит накопление и повторное использование проектных решений, средств проектирования, моделей и прототипов информационной системы и информационной технологии; осуществляется ориентация на развитие и модификацию системы и технологи в процессе их проектирования; проводится анализ риска и издержек в процессе проектирования систем и технологий.
Особенности проектирования информационной технологии. Современная информационная технология реализуется в условиях спроектированной информационной системы.
Аспекты проектирования: техническое (аппаратно-коммуникационный комплекс), программно-математический (модели и программы), методический (совокупность средств реализации функций управления), организационный (описание документооборота и регламента действий аппарата управления), пооперационный (совокупность технологических, логических, арифметических действий, реализуемых в автоматическом режиме).
Методологии, технологии и инструментальные средства проектирования (САSЕ-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла (ЖЦ).
ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации. Структура ЖЦ ПО по стандарту ISO/IEC базируется на трех группах процессов: основных процессах (приобретение, поставка, разработка, эксплуатация, сопровождение); вспомогательных процессах, обеспечивающих выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем); организационных процессах (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка проекта включает в себя все работы по созданию по и его компонентов в соответствии с заданными требованиями. В разработку ПО входят, как правило, анализ, проектирование и реализация (программирование). Эксплуатация содержит работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование базы данных и рабочих мест пользователей. Управление проектом связано с вопросами планирования и организации работ. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО. Верификация - это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа.
Проверка позволяет оценить соответствие параметров разработки исходным требованиям Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и Сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. К настоящему времени наибольшее распространение получили следующие основные модели ЖЦ: каскадная модель спиральная модель итерационная модель
Каскадная модель- основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Достоинства каскадной модели: на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. Выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты.
Недостатки каскадной модели: задержка получения результатов(может оказаться, что разрабатываемая информационная система не соответствует требованиям пользователей) возврат на предыдущую стадию(ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на следующих стадиях работы над проектом) сложность параллельного ведения работ. информационная перенасыщенность(при внесении изменений в одну из частей проекта необходимо оповещать всех разработчиков, которые могли использовать её в своей работе) сложность управления проектом
Спиральная модель Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап до полного завершения работы на текущем. Главная задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.
Достоинства спиральной модели: итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика отдельные элементы информационной системы интегрируются в единое целое постепенно(интеграция происходит непрерывно) уменьшение уровня рисков итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие
Недостаток спиральной модели: это определение момента перехода на следующий этап. Для решения этой проблемы необходимо ввести временные ограничения на каждый из этапов жизненного цикла ИС, иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного.
Итерационная модель Подход к проектированию снизу-вверх обусловливает необходимость таких итерационных возвратов, когда проектные решения по отдельным задачам комплектуются в общие системные решения, и при этом возникает потребность в пересмотре ранее сформулированных требований. Запутанность функциональной и системной архитектуры созданной ИС, трудность в использовании проектной документации вызывают на стадиях внедрения и эксплуатации сразу необходимость перепроектирования всей системы.
Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF) и Extreme Programming (XP). RUP предлагает итеративную модель разработки, вклю чающую четыре фазы: начало, исследование, построение и внедрение. Прохождение через четыре основные фазы называется циклом разработки. Используется объектно- ориентированный анализ, объектно-ориентированное программирование. MSF сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно- ориентированного моделирования.
Экстремальное программирование(ХР) является самым новым среди рассматриваемых методологий. В основе лежит командная работа, эффективная коммуникация между заказчиком и исполнителем в течении всего проекта по разработке ИС, а разработка ведется с использованием последовательно разрабатываемых прототипов.
Под проектированием автоматизированных ИС понимается процесс разработки технической документации, связанный с организацией системы получения и преобразования исходной информации в результатную, Т.е. с организацией автоматизированной информационной технологии. Документ, полученный в результате проектирования, носит название проект. Целью проектирования является подбор технического и формирование информационного, математического, про граммного и организационно-правового обеспечения.
Основными задачами проектирования являются: О казание влияния на улучшение организации учетной, плановой и аналитической работы; Выбор оборудования и разработка рациональной технологии решения задач и получения результатной информации; Составление графиков прохождения информации как внутри производственных и функциональных подразделений, так и между ними; Создание БД, обеспечивающей оптимальное использование информации, касающейся планирования, учета и анализа хозяйственной деятельности; Создание нормативно-справочной информации.
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. В зависимости от сложности объекта, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта, а также начинать выполнение работ следующей стадии до окончания предыдущей.
Стадии и этапы создания ИС: Стадия 1. Формирование требований к ИС: - обследование объекта и обоснование необходимости создания ИС. - Формирование требования пользователей к ИС. - Оформление отчета о выполненной работе и тактико- технического задания на разработку Стадия 2. Разработка концепции ИС: - Изучение объекта автоматизации. - Проведение научно-исследовательских работ. - Разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей - Оформление отчета и утверждения концепции
Стадия 3. Техническое задание: - Разработка и утверждение тех. Задания на создание ИС Стадия 4. Эскизный проект: - Разработка предварительных проектных решений по системе и её частям - Разработка эскизной документации на ИС и её части Стадия 5. Технический проект: - Разработка проектных решений по системе и её частям - Разработка документации на ИС и её части - Разработка и оформление документации на постановку комплектующих изделий - Разработка заданий на проектирование в смежных частях проекта
Стадия 6. Рабочая документация: - Разработка рабочей документации на ИС и её части - Разработка и адаптация программ Стадия 7. Ввод в действие: - Подготовка объекта автоматизации - Подготовка персонала - Комплектация ИС поставляемыми изделиями(Программно техническими средствами, комплексами, информационными изделиями) - Строительно-монтажные и пусконаладочные работы - Предварительные испытания - Опытная эксплуатация - Приемочные испытания
Стадия 8. Сопровождение ИС: - Выполнение работ в соответствии с гарантийными обязательствами - Послегарантийное обслуживание Обследование это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются: для обоснования разработки и поэтапного внедрения систем; составления технического задания на разработку систем; разработки технического и рабочего проектов систем.
Основная задача первого этапа обследования оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Результатом этапа определения стратегии является документ (технико-экономическое обоснование проекта), в котором четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ)
Ориентировочное содержание этого документа: ограничения, риски совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы; сроки завершения отдельных этапов, привлекаемые ресурсы, меры по защите информации; описание выполняемых системой функций; возможности развития системы; информационные объекты системы; интерфейсы и распределение функций между человеком и системой; требования к программным и информационным компонентам ПО, требования к СУБД
По результатам обследования устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки. На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации MuSCoW. Эта аббревиатура расшифровывается так: Must have необходимые функции(критичны для успешной работы); Should have желательные функции; Could have возможные функции; Won *t haveотсутствующие функции(необходимо четко представлять границы проекта и набор функций которые будут отсутствовать в системе).
На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач: получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения разработки плана работ по обеспечению надежности информационной системы и ее тестирования Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы
Техническое задание это документ, определяющий Цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления. При разработке технического задания необходимо решить следующие задачи: установить общую цель создания ИС, определить состав подсистем и функциональных задач; разработать и обосновать требования, предъявляемые к подсистемам Требования к информационной базе, математическому и программному обеспечению, комплексу тех. Средств Установить общие требования к проектируемой ИС Определить перечень задач создания системы и исполнителей определить этапы создания системы и сроки их выполнения; провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.
Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям. Выполнение стадии эскизного проектирования не является строго обязательным. Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются: Функции ИС; Функции подсистем, их цели и ожидаемый эффект от внедрения состав комплексов задач и отдельных задач; концепция информационной базы и ее укрупненная структура; функции системы управления базой данных состав вычислительной системы и других технически средств; функции и параметры основных программных средств
На основе технического задания (и эскизного проекта) разрабатывается технический проект ИС. Технический проект ИС это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятии по подготовке объекта к внедрению. Технический проект содержит: пояснительную записку, функциональную и организационную структуру системы, постановку задачи и алгоритмы решения, организацию информационной базы, альбом форму документов, систему математического обеспечения, принцип построения комплекса тех. Средств, расчеты экономической эффективности, мероприятия по подготовке объекта к внедрению системы, ведомость документов.
На стадии рабочей документации осуществляется создание программного продукта и разработка всей сопровождающей документации. Документация должна содержать все необходимые и достаточные сведения для обеспечения вы полнения работ по вводу ИС в действие и ее эксплуатации. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена. Для ИС, которые являются разновидностью автоматизированных систем, устанавливают следующие основные виды испытаний: предварительные, опытная эксплуатация и приемочные. В зависимости от взаимосвязей частей ИС и объекта автоматизации испытания могут быть автономные(охватывают часть системы) или комплексные(для системы в целом).
Для планирования проведения всех видов испытаний разрабатывается документ «Программа и методика испытаний». Разработчик документа устанавливается в договоре или ТЗ. Предварительные испытания проводят для определении работоспособности системы и решения вопроса о возможности ее приемки в опытную эксплуатацию. Опытную эксплуатацию системы проводят для определения фактической эффективности и корректировки при необходимости документации Приемочные испытания проводят для определения соответствия системы техническому заданию
Типовое проектное решение (ТПР) это тиражируемое (пригодное к многократному использованию) проектное решение. Выделяются следующие классы ТПР: Элементные ТПР – типовые решения по задаче или по отдельному виду обеспечения задачи Подсистемные ТПР – в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей Объектные ТПР – типовые отраслевые проекты, включающие полный набор функциональных и обеспечивающих подсистем ИС
Достоинства и недостатки ТПР: Элементные(библиотеки методо-ориентированных программ) + Обеспечивается применение модульного подхода к проектированию - Большие затраты времени на сопряжение разнородных элементов Подсистемные(пакеты прикладных программ) + Высокая степени интеграции элементов ИС + Сокращение затрат на проектирование и программирование взаимосвязанных компонентов - Адаптивность ТПР недостаточна - Проблемы в комплексировании разных функциональных подсистем
Параметрически-ориентированное проектирование включает следующие этапы: Определение критериев оценки годности пакетов прикладных программ(ППП) Анализ и оценка доступных ППП по сформулированным критериям Выбор и закупка наиболее подходящего пакета Настройка параметров(доработка) закупленного ППП
Модельно-ориентированное проектирование предполагает построение модели объекта автоматизации с использованием специального программного инструментария(например, SAP Business Engineering Workbench(BEW), BAAN Enterprise Modeler). Также создание системы возможно на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом. Репозиторий содержит базовую(ссылочную) модель ИС, типовые(референтные) модели определенных классов ИС, модели конкретных ИС предприятий
Базовая модель ИС содержит описание бизнес функций, процессов, объектов, правил, а также описание орг. структуры, которые поддерживаются программными модулями типовой ИС Типовые модели описывают конфигурации ИС для определенных отраслей или типов производства Модель конкретного предприятия стоится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса(SAP Business Engineering Workbench)
Реализация типового проекта предусматривает выполнение следующих операций: Установку глобальных параметров системы Задание структуры объекта автоматизации Определение структуры основных данных Задание перечня реализуемых функций и процессов Описание интерфейсов Описание отчетов Настройку авторизации доступа Настройку системы архивирования
Проектирование информационных систем всегда начинается с определения цели проекта . В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:
- требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;
- требуемой пропускной способности системы;
- требуемого времени реакции системы на запрос;
- безотказной работы системы;
- необходимого уровня безопасности;
- простоты эксплуатации и поддержки системы.
Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта , сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль , преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.
Процесс создания ИС делится на ряд этапов (стадий [ 1.1 ]), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).
Обычно выделяют следующие этапы создания ИС : формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение [ 1.1 ] [ 1.2 ] . (Последние два этапа далее не рассматриваются, поскольку выходят за рамки тематики курса.)
Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению ( ПО ) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция .
Целью начальных этапов создания ИС , выполняемых на стадии анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.
На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных . Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных .
Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню , вид окон, горячие клавиши и связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
- схема базы данных (на основании ER-модели, разработанной на этапе анализа);
- набор спецификаций модулей системы (они строятся на базе моделей функций).
Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:
- будет ли это архитектура "файл-сервер" или "клиент-сервер";
- будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
- будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
- будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
- будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).
Этап проектирования завершается разработкой технического проекта ИС.
На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.
Этап тестирования обычно оказывается распределенным во времени.
Создание ИС и ИТ представляет собой сложный процесс проектирования. Целью проектирования являются подготовка проектных документов и внедрение человекомашинной системы управления организацией. В процессе проектирования выявляются наиболее существенные характеристики экономического объекта, изучаются его внешние и внутренние информационные потоки, создаются математические и физические аналоги исследуемой системы и ее элементов, устанавливаются условия взаимодействия человека и технических средств управления.
Рассматривая ИС в технологическом аспекте, можно выделить аппарат управления (АУ). Оставшиеся компоненты - информационная технология (ИТ), информационная система решения функциональных задач (ИСФЗ) и система поддержки принятия решений (СППР) - информационно и технологически взаимоувязаны и составляют основу архитектуры ИС.
Тщательно спроектированное технологическое обеспечение информационной технологии позволяет не только успешно решать функциональные задачи управления, но и в рамках СППР менеджерам и руководителям организаций проводить в интерактивном режиме аналитическую и прогнозную работу для последующего принятия управленческих решений.
Обязательными элементами проектируемого технологического обеспечения информационной технологии являются: информационное, лингвистическое, техническое, программное, математическое, организационное, правовое, эргономическое.
Информационное обеспечение (ИО) - представляет собой совокупность проектных решений по объемам, размещению, форма организации информации, циркулирующей в ИС.
Лингвистическое обеспечение (ЛО) - объединяет совокупность языковых средств для формализации естественного языка, построения и сочетания информационных единиц в ходе общения пользователей со средствами вычислительной техники.
Техническое обеспечение (ТО) - представляет собой комплекс технических средств (технические средства сбора, регистрации, передачи, обработки, отображения, тиражирования информации, оргтехника и др.), обеспечивающих работу ИТ.
Программное обеспечение (ПО) - включает совокупность программ, реализующих функции и задачи ИС и обеспечивающих устойчивую работу комплексов технических средств.
Математическое обеспечение (МО) - совокупность математических методов, моделей и алгоритмов обработки информации, используемых при решении функциональных задач и в процессе автоматизации проектировочных работ.
Организационное обеспечение (ОО) - представляет собой комплекс документов, составленный в процессе проектирования ИС, утвержденный и положенный в основу эксплуатации.
Правовое обеспечение (ПрО) - представляет собой совокупность правовых норм, регламентирующих правоотношения при создании и внедрении ИС и ИТ.
Эргономическое обеспечение (ЭО) - как совокупность методов и средств, используемых на разных этапах разработки и функционирования ИС и ИТ, предназначено для создания оптимальных условий высококачественной, высокоэффективной и безошибочной деятельности человека в ИТ, для ее быстрейшего освоения.
Под бизнес-инжинирингом понимается выполнение комплекса проектировочных работ по разработке методов и процедур управления бизнесом, когда без изменения принятой структуры управления в организации (предприятии, фирме) достигается улучшение ее финансового положения.
Инжиниринг располагает для проектирования бизнеса рядом методик:
выделение пошаговых процедур проектируемого бизнеса;
внедрение описывающих процедуры систем обозначений;
использование эвристик и прагматических решений, позволяющих описывать степень соответствия спроектированного варианта бизнеса заданным целям.
Под бизнес-процессомпонимается целостное описание основных видов деятельности организации (предприятия, фирмы, корпорации) и их проекция на организационные структуры с учетом развития взаимодействия между участниками во времени.
Проект по реинжинирингу бизнеса, как правило, включает следующие этапы:
разработку образа будущей организации;
анализ существующего бизнеса;
разработку нового бизнеса;
внедрение нового бизнеса.
Имитация - наиболее удачный подход, обеспечивающий как точность анализа, так и наглядность, различий при сравнении альтернативных решений. Немаловажным является и тот факт, что имитационное моделирование успешно реализуется на персональном компьютере, которым обеспечивается автоматизированное рабочее место менеджера.
Под единыминформационным пространством понимается совокупность методических, организационных, программных, технических и телекоммуникационных средств, обеспечивающих оперативный доступ к любым информационным ресурсам предприятия в пределах компетенции и прав доступа специалистов.
Контроллинг - комплекс методов поиска решений - концепция системного управления и способ мышления менеджеров, в основе которых лежит стремление обеспечить долгосрочное эффективное функционирование организации. Для реализации задач контроллинга в процессе проектирования СППР создается специализированная информационная модель, получившая название контроллер.
Контроллер - это совокупность методов и средств для реализации задач стратегического и оперативного контроля в системе управления, а также решения стратегических и тактических задач по направлениям управленческой деятельности (маркетинг, обеспечение ресурсами, инвестиции и т.п.).
Согласно приведенным подходам формируются основные принципы создания ИС и ИТ управления:
системность и логичность построения обеспечивающих и функциональных элементов ИС;
широкое применение экономико-математических методов и стандартных программ прогнозно-статистического характера. Задачи управления производственной, финансовой деятельностью организации в большинстве своем ставятся как аналитические, оптимизационные или как задачи планирования.
предполагает декомпозицию системы на ряд комплексов (модулей) задач, каждый из которых моделирует определенную сферу управленческой деятельности.
использование новых методов и включение вновь созданных программных модулей в систему автоматизации управленческих работ. Проектирование ИС должно изначально базироваться на модульных принципах, а компьютерная реализация - допускать расширение за счет совершенствования структуры программного обеспечения.
это принцип адаптации всех элементов и системы в целом. Он должен полностью пронизывать идеологию построения ИС управления - от анализа задач, технико-экономических показателей и их группировок в модули до формулирования целей.
Конечный продукт работы любого менеджера - это решения и действия. Принятое им решение ведет либо к преуспеванию предприятия, либо к неудачам. Принятие решения - это всегда выбор определенного направления деятельности из нескольких возможных. Так как процесс управления любой организацией в экономике реализуется исключительно посредством формирования и реализации управленческих решений, поэтому остановимся на типах решений, которые имеют различные характеристики и требуют различных источников данных.
Оперативные решения - периодические: одна и та же задача возникает периодически. В результате процесс принятия решения становится относительно рутинным и почти беспроблемным. Параметры (характеристики) хозяйственных процессов, используемые в ходе принятия решения, определены, их оценка известна с высокой точностью, а взаимосвязь параметров с принимаемым решением понятна. Принятие оперативных решений ведет к вполне ожидаемым и прогнозируемым результатам. Оперативные решения являются краткосрочными.
Тактические решения обычно принимаются управленцами среднего уровня, ответственными за обеспечение средствами для достижения целей и намерений, поставленных ЛПР верхнего звена. Тактические решения не так рутинны и структурированы, как оперативные решения. Все главные параметры объекта управления, входящие в состав тактических решений, неизвестны; оценки характеристик, определенные как важные, могут быть неизвестны, а взаимосвязь между характеристиками и решениями может быть не ясна.
Стратегические решения принимаются на основе целей компании, определенных в его уставе и уточненных высшим руководством предприятия. Эти цели определяют основу, на которой должно базироваться долгосрочное планирование, а также определение критических факторов деятельности предприятия. Эти решения обеспечивают базу для принятия тактических и оперативных решений.
Рассмотрим модели и методы, используемые на каждом из этапов. На первом этапе применяются в основном неформальные методы для того, чтобы:
сформулировать проблему;
выявить цель;
сформулировать критерий оценки принятия решений.
Если проблема осознана и идентифицирована количественными показателями или качественными признаками, то далее можно сформулировать цели. Цель - это антипод проблемы. Если проблема это то, чего не хочет ЛПР, то цель - это то, что оно хочет.
На втором этапе формирования решений происходит поиск различных вариантов - альтернатив. Варианты могут отыскиваться в различных формах и шкалах измерений. Варианты, как правило, задаются либо перечислением, если таковых не очень много, либо описанием их свойств.
На третьем этапе согласно сформулированному на втором этапе критерию выбора происходят сопоставление, оценка и выбор решения. Все методы оценки вариантов можно разделить на две группы:
методы, используемые в условиях определенности;
методы, используемые в условиях риска.
Этапами проектирования СППР при наличии программной оболочки являются:
Описание предметной области, целей создания системы и выполнение постановки задачи.
Составление словаря системы.
Разработка базы знаний и базы данных.
Внедрение системы.
Этап 1. Описание предметной области, целей создания системы и выполнение постановки задачи. Описание должно отражать специфику предметной области в нескольких формах. Первая из них - это текстовое представление содержание процессов, объектов и связей между ними. Вторая форма описания представляет собой графическое представление дерева целей, стоящих перед пользователем, или дерева И-ИЛИ.
Постановка всякой задачи предполагает указание результатов функционирования системы, исходных данных, а также общее описание процедур, формул и алгоритмов преобразования исходных данных в результирующие данные.
Этап 2. Составление словаря системы. Словарь системы - это набор слов, фраз, кодов, наименований, используемых разработчиком для обозначения условий, целей, заключений и гипотез. Благодаря словарю пользователь понимает результаты работы системы. Составление словаря - важная работа, ибо четко сформулированные условия и ответы резко повышают эффективность эксплуатации системы.
Этап 3. Разработка базы знаний и базы данных. База знаний, как правило, состоит из двух компонентов: дерева целей с расчетными формулами и базы правил (сеть вывода). База правил создается на основании графа целей и сформулировавши ранее гипотез. Главное внимание здесь уделяется коэффициентам определенности исходных условий и правил их обработки.
Этап 4. Внедрение. Проверяется и оцениваются правильность работы системы. Устанавливаются результаты, которые затем сравниваются с полученными в процессе запуска системы. Проверяются также промежуточные расчеты с помощью блока, отвечающего на вопросы как и почему.
Под технологией проектирования информационных систем (ИС) понимают упорядоченный в логической последовательности набор методических приемов, технических средств и проектировочных методов, нацеленных на реализацию общей концепции создания или доработки проекта системы и ее компонентов. Для разработки ИС управления большое значение имеют качество и состав базы проектирования.
Элементарной базовой конструкцией технологической цепочки проектирования ИС и ее главного компонента - ИТ является так называемая технологическая операция - отдельное звено технологического процесса.
Это понятие определяется на основе кибернетического подхода к процессу разработки ИТ. Автоматизация данного процесса предопределяет необходимость формализации технологических операций, последовательного объединения их в технологических цепь взаимосвязанных проектных процедур и их изображение.
Предпроектное обследование предметной области предусматривает выявление всех характеристик объекта и управленческой деятельности в нем, потоков внутренних и внешних информационных связей, состава задач и специалистов, которые будут работать в новых технологических условиях, уровень их компьютерной и профессиональной подготовки как будущих пользователей системы.
Рассмотрим первый из путей, т.е. возможности использования типовых проектных решений, включенных в пакеты прикладных программ. Наиболее эффективно информатизации поддаются следующие виды деятельности:
бухгалтерский учет, включая управленческий и финансовый;
справочное и информационное обслуживание экономической деятельности;
организация труда руководителя;
автоматизация документооборота;
экономическая и финансовая деятельность;
обучение.
Автоматизированные системы проектирования - второй, быстроразвивающийся путь ведения проектировочных работ.
В области автоматизации проектирования ИС и ИТ за последнее десятилетие сформировалось новое направление - CASE (Computer- Aided Soft-ware/System Engineering). CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ИС, прочно вошедший в практику создания и сопровождения ИС и ИТ. Основная цель CASE состоит в том, чтобы отделить проектирование ИС и ИТ от ее кодирования и последующих этапов разработки, а также максимально автоматизировать процессы разработки и функционирования систем.
Помимо автоматизации структурных методологий и как следствие возможности применения современных методов системной и программной инженерии CASE обладают следующими основными достоинствами:
улучшают качество создаваемых ИС (ИТ) за счет средств автоматического контроля (прежде всего, контроля проекта);
позволяют за короткое время создавать прототип будущей ИС (ИТ), что позволяет на ранних этапах оценить ожидаемый результат;
ускоряют процесс проектирования и разработки системы;
освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части проектирования;
поддерживают развитие и сопровождение уже функционирующей ИС (ИТ);
поддерживают технологии повторного использования компонентов разработки.
Большинство CASE-средств основано на научном подходе, получившем название "методология/метод/нотация/средство". Методология формулирует руководящие указания для оценки и выбора проекта разрабатываемой ИС, шаги работы и их последовательность, а также правила применения и назначения методов. К настоящему моменту CASE-технология оформилась в самостоятельное наукоемкое направление, повлекшее за собой образование мощной CASE-индустрии, объединившей сотни фирм и компаний различной ориентации.
Своевременность характеризует временные свойства ИС и ИТ и имеет количественное выражение в виде суммарного времени задержки информации, необходимой пользователю в текущий момент времени в реальных условиях для принятия решений. Чем меньше величина временной задержки поступления информации, тем лучше ИС отвечает данному требованию.
Общий показатель надежности ИС концентрирует в себе ряд важных характеристик:
частоту возникновения сбоев в техническом обеспечении;
степень адекватности математических моделей;
верификационную чистоту программ;
относительный уровень достоверности информации;
интегрированный показатель надежности эргономического обеспечения ИС.
Адаптационные свойства системы отражают ее способность приспосабливаться к изменениям окружающего внешнего фона внутренней управленческой и производственной среды организации. Важная задача заказчика - сформулировать на этапе проектирования границы допущения отклонений в значениях управляющих и выходных параметров, имеющих принципиальное значение для функционирования всей системы.
В общем виде постановка задачи состоит из четырех принципиально важных компонентов:
организационно-экономической схемы и ее описания;
свода применяемых математических моделей;
описания вычислительных алгоритмов;
концепции построения информационной модели системы.
Математическая модель и разрабатываемые на ее основе алгоритмы должны удовлетворять трем требованиям: определенности (однозначности), инвариантности по отношению к различным альтернативным ситуациям в задаче и результативности (возможности ее решения за конечное число шагов). Результатом алгоритмизации является логически построения и отлаженная блок-схема.
Постановка и дальнейшая компьютерная реализация задач требуют усвоения основных понятий, касающихся теоретических основ, информационных технологий. К ним относятся:
свойства, особенности и структура экономической информации;
условно-постоянная информация, ее роль и назначение;
носители информации, макет машинного носителя;
средства формализованного описания информации;
алгоритм, его свойства и формы представления;
назначение и способы контроля входной и результатной информации;
состав и назначение устройств компьютера;
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Подобные документы
Основные методологии проектирования, модели жизненного цикла локальных систем, сущность структурного подхода. Моделирование потоков процессов и программные средства поддержки их жизненного цикла. Характеристика и технология внедрения CASE средств.
курсовая работа , добавлен 13.12.2010
Основы методологии проектирования информационных систем, понятие их жизненного цикла. Основные модели жизненного цикла. Методология функционального моделирования SADT. Состав функциональной модели. Моделирование данных, характеристика case-средств.
реферат , добавлен 28.05.2015
Методология структурного анализа и проектирования информационных систем. Базовый стандарт процессов жизненного цикла программного обеспечения. Цели и принципы формирования профилей информационных систем. Разработка идеальной модели бизнес-процессов.
презентация , добавлен 07.12.2013
Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.
курсовая работа , добавлен 20.11.2010
Особенности проектирования информационных систем основанных на базах данных. Использование CASE-средств и описание бизнес процессов в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и визуальное представление web-сайта.
курсовая работа , добавлен 25.04.2012
Основные области проектирования информационных систем: базы данных, программы (выполнение к запросам данных), топология сети, конфигурации аппаратных средств. Модели жизненного цикла программного обеспечения. Этапы проектирования информационной системы.
реферат , добавлен 29.04.2010
Жизненный цикл автоматизированных информационных систем. Основы методологии проектирования автоматизированных систем на основе CASE-технологий. Фаза анализа и планирования, построения и внедрения автоматизированной системы. Каскадная и спиральная модель.
курсовая работа , добавлен 20.11.2010
Системы автоматического проектирования. Сравнительный анализ средств для проектирования автоматизированных информационных систем. Экспорт SQL-кода в физическую среду и наполнение базы данных содержимым. Этапы развития и характеристика Case-средств.
курсовая работа , добавлен 14.11.2017
