2. Объектно-ориентированный подход
Сущность подхода
Принципиальное различие между структурным и объектно-ориентированным (ОО) подходом заключается в способе декомпозиции системы (рис.2). ОО подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщений между объектами
Ответ Милы
+ дополнительно см. вопрос 11.
Цель методологии создания информационных систем (ИС) заключается в организации процесса построения ИС и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки.
Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки программного обеспечения (ПО) и системы в целом. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
К настоящему времени наибольшее распространение получили следующие основные модели ЖЦ:
Задачная модель;
каскадная модель (или системная) (70-85 г.г.);
спиральная модель (настоящее время).
Задачная модель
При разработке системы "снизу-вверх" от отдельных задач ко всей системе (задачная модель) единый поход к разработке неизбежно теряется, возникают проблемы при информационной стыковке отдельных компонентов. Как правило, по мере увеличения количества задач трудности нарастают, приходится постоянно изменять уже существующие программы и структуры данных. Скорость развития системы замедляется, что тормозит и развитие самой организации. Однако в отдельных случаях такая технология может оказаться целесообразной:
Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново);
Эксперимент и адаптация заказчика (не ясны алгоритмы, решения нащупываются методом проб и ошибок).
Общий вывод: достаточно большую эффективную ИС таким способом создать невозможно.
Каскадная модель
В ранних не очень больших по объему однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем [2]:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. 1. Каскадная схема разработки
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания систем никогда полностью не укладывался в такую жесткую схему. В процессе создания постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид (рис. 2):
Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Сущность системного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Таким образом, данная модель основным достоинством имеет системность разработки, а основные недостатки - медленно и дорого.
Спиральная модель
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [1] (рис. 3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Рис 3. Спиральная модель ЖЦ ИС
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
фаза определения требований и анализа;
фаза проектирования;
фаза реализации;
фаза внедрения.
Основные принципы методологии RAD:
разработка приложений итерациями;
необязательность полного завершения работ на каждом из этапов жизненного цикла;
обязательное вовлечение пользователей в процесс разработки ИС;
необходимое применение CASE-средств, обеспечивающих целостность проекта;
применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
необходимое использование генераторов кода;
использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
тестирование и развитие проекта, осуществляемые одновременно с разработкой;
ведение разработки немногочисленной хорошо управляемой командой профессионалов;
грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Последовательность этапов создания ИС на фазе определения требований и анализа:
Описание предметной области, структура организации, задачи, решаемые подразделениями, ДПД для существующей информационной технологии.
Назначение ИС.
Построение начальной контекстной диаграммы потоков данных (DFD).
Формирование матрицы списка событий (ELM) и таблицы потоков данных.
Построение иерархии контекстных диаграмм.
Диаграмма структур данных.
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Результатами проектирования архитектуры являются:
модель процессов (диаграммы архитектуры системы (SAD) и миниспецификации на структурированном языке);
модель данных (ERD и подсхемы ERD);
модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах SAD.
Типовой процесс разработки и внедрения информационной системы включает следующие этапы: (ссылка на подробное описание процесса внедрения)
заключение договора (предварительный контакт, экспресс обследование, определение границ проекта и согласование условий договора).
обследование бизнеса предприятия заказчика.
проектирование модели бизнеса.
разработка специализированного ПО.
технологическое внедрение (установка оборудования и программного обеспечения у заказчика).
сопровождение и развитие.
Основные функции, выполняемые с помощью CASE-средств:
формирование функциональной модели информационной системы. Наиболее распространенный метод реализации данной функции – метод SADT (технология IDEF0), позволяющий описать процесс в ИС в виде иерархии функций, связанных между собой входящими/исходящими потоками (материальными, финансовыми, информационными), управляющими воздействиями, исполнителями;
формирование информационной модели, в том числе выделение объектов, описание их поведения и связей друг с другом. Наиболее распространенный метод реализации данной функции – метод IDEF1X, с помощью которого создается описание информационного пространства выполнения бизнес-процессов, содержащего информационные объекты (сущности), их свойства (атрибуты), отношения с другими объектами (связи);
формирование архитектуры информационной системы. Наиболее распространенный метод реализации данной функции - DFD (Data Flow Diagrams – диаграммы потоков данных) - методология структурно- функционального анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных;
структурирование (моделирование) данных, в том числе создание концептуальной модели структуры базы данных, автоматическая генерация физической модели БД и др. Наибольшее распространение получили: метод построения ER (Entity-Relationship)-диаграмм Чена и методология Уорнера-Орра DSSD (Data Structured Systems Development);
быстрая разработка приложений (визуальное программирование). Средства, обеспечивающие данную функцию, называются RAD-средствами (Rapid Application Development). Они представляют собой визуальные дизайнеры приложений с автоматической кодогенерацией и позволяют создавать приложения в интерактивном режиме с помощью набора визуальных средств.
Последовательность разработки информационных систем:
а) каскадная схема; б) спиральная схема; в) макетная схема
Ответ прошлых лет (Ден)
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность трех составляющих:
пошаговой процедуры, определяющей последовательность технологических операций проектирования;
критериев и правил, используемых для оценки результатов выполнения технологических операций;
нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:
технология должна поддерживать полный ЖЦ ПО;
технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам;
технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС.
Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.
Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).
Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы.
Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.
Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия.
Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций. Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.
Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение различных бизнес-процессов.
Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала.
19. Проектирование ИС []
№ | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
19 | 11.2. | Проектирование информационных систем. Инфраструктура ИС. Платформы ИС. | Алексеев Пётр Сергеевич | Саша Хохрина | ОПЛ (Ден), готовый ответ Саши Хо |
Готовый ответ Саши Хо
Инфраструктура ИС
Определения
Инфраструктура
Определение из Википедии:
Инфраструктура - комплекс взаимосвязанных обслуживающих структур или объектов, составляющих и/или обеспечивающих основу функционирования системы.
По ГОСТ Р 53114-2008 «Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения»:
Инфраструктура – совокупность зданий, оборудования и служб обеспечения, необходимых для функционирования организации
Информационная инфраструктура
По ГОСТ Р 53114-2008
Информационная инфраструктура – совокупность объектов информатизации, обеспечивающая доступ потребителей к информационным ресурсам.
Объект информатизации – совокупность информационных ресурсов, средств и систем обработки информации, используемых в соответствии с заданной информационной технологией, а также средства их обеспечения, помещений или объектов (зданий, сооружений, технических средств), в которых эти средства и системы установлены, или помещений и объектов, предназначенных для ведения конфиденциальных переговоров (по ГОСТ Р 51275-2006 «Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения»)
Информационная инфраструктура:
включает совокупность информационных центров, банков данных и знаний, систем связи;
обеспечивает доступ потребителей к информационным ресурсам.
Из Википедии:
В качестве примеров информационной инфраструктуры можно привести такие общеизвестные сферы нашей жизни как:
Интернет
Дистанционное образование
Сетевые СМИ
Реклама, пиар
Вышеуказанные примеры являются общими для всех стран. В то же время есть примеры-результаты работы конкретных организаций:
Science Citation Index от фирмы Institute for Scientific Information.
Science Citation Index – это индекс цитирования, введенный в 1961 году и охвативший на тот момент информацию порядка 600 журналов. Сегодня данный индекс является одним из крупнейшим и охватывает более 16 000 источников информации.
STN от фирмы Thomson Scientific.
STN (Scientific and Technical Network) – европейская база данных, содержащая более 10 млн документов по самым разным наукам: физика, биофизика, химия, технологии, медицина и др. База является одной из самых крупных в мире.
Scopus от фирмы Elsevier.
Scopus – это библиографическая и реферативная база данных, отслеживающая публикации более 18 000 источников, выпускаемых более, чем 5 000 издательствами. Следует отметить, что база учитывает как технические, так и гуманитарные и медицинские науки, а разработчик проекта, компания Elsevier, позиционирует Scopus как наиболее полный и исчерпывающий ресурс для поиска научной информации.
В России большой вклад в развитие информационной инфраструктуры вносят компании из сферы телекоммуникационного бизнеса. Например, оператор связи “МегаФон” инвестирует в развитие сети Центров обработки данных. Этот же оператор приобрел одного из крупнейших операторов фиксированной связи, что позволит создать единую магистральную сеть протяженностью более 100 тыс. км. вместе с обширной спутниковой инфраструктурой.
Инфраструктура ИС
Определение из http://ssofta.narod.ru/bd/ets2.htm
Под инфраструктурой информационной системы будем понимать все то, что обеспечивает ее бесперебойное функционирование.
Таким образом, к инфраструктуре следует отнести:
системное и сетевое программное обеспечение,
СУБД,
операционные платформы,
компьютеры, сетевое оборудование,
другие необходимые для функционирования ИС периферийные устройства,
средства связи,
электро-, тепло- и водоснабжение,
кондиционеры,
помещения,
обслуживающий персонал,
дополнительное оборудование, необходимое для работы персонала.
Определение с http://www.sb-serv.ru/itinfrastructure.html (ссылка на сохранённую копию ниже)
Инфраструктура информационных систем (ИТ–инфраструктура) - это совокупность информационных центров, баз данных и систем связи, обеспечивающая доступ пользователей к информационным ресурсам предприятия.
Понятие инфраструктуры с течением времени претерпевало значительные изменения.
Действительно, во времена майнфреймов инфраструктура представляла собой линии связи, модемы, системы энергообеспечения и кондиционирования. В период развития локальных сетей LAN инфраструктура осталась прежней, однако сложность ее элементов усложнилась. Переход к глобальным сетям еще более усложнил это понятие. При этом сложность возрастала не только за счет увеличения числа элементов и связей между ними, но и за счет усложнения внутренней структуры элементов и перераспределения функций между ними. Например: программы управления каналами переместились на управления сетевыми устройствами. То есть параллельно усложнению аппаратуры усложнялась математика - программы управления инфраструктурой.
ИТ-инфраструктура является не просто фундаментом для существования любой современной компании, ИТ в настоящее время становятся стратегическим активом, который является движущей силой бизнеса. Построение надежной ИТ-инфраструктуры, удовлетворяющей бизнес процессам компании – сложная задача, практически не решаемая собственными силами ИТ-отдела компании. Самое главное, что ИТ-инфраструктура должна удовлетворять потребностям бизнеса компании. Для того, чтобы организовать действительно надёжную, высокопроизводительную и масштабируемую ИТ-инфраструктуру, нужно обладать большим числом высококвалифицированных специалистов, а также немалым опытом построения ИТ-инфраструктур.
ИТ-инфраструктура должна соответствовать трем параметрам: доступности, надежности и безопасности:
Доступность для инфраструктуры означает, что всегда можно получить оперативную информацию, найти файл там, где его положили, и пользоваться всеми ресурсами и сервисами круглосуточно и круглогодично.
Надежность – это понятие несколько шире, чем «у-нас-все-всегда-исправно». Так попросту не бывает: все, что может сломаться — обязательно рано или поздно сломается. Другое дело, что это не должно стать катастрофой для вашего бизнеса. Что бы не случилось, пользователь не должен замечать всех этих проблем — данные не исчезнут, базы данных останутся в работе, обмен сообщениями продолжится.
Безопасность – параметр, о котором все говорят, но очень немногие знают, чего же они хотят. Данные, накопленные вашим предприятием слишком ценны, чтобы позволять украсть их или испортить. Их нужно защищать, защищать и еще раз защищать! Причем делать это нужно таким образом, чтобы это не влияло на текущую работу, не вызывало излишних неудобств, и чтобы обоснованные ограничения нельзя было обойти.
Корпоративная информационная система (КИС) – составная часть ИТ-инфраструктуры, которая включает в себя информационные центры, базы данных, системы связи и совместной работы. При построении корпоративной информационной системы (КИС) необходимо учитывать ряд важных факторов. Так, например, распространенной ошибкой многих компаний является то, что сначала производится внедрение ERP системы, а затем компании оказываются перед фактом, что инфраструктура не готова для обслуживания этой системы. ИТ-инфраструктура является ядром всех остальных информационных систем или бизнес приложений. И именно от того, как построена ИТ-инфраструктура, насколько она надёжна и производительна, будет зависеть работа всех остальных приложений, ERP систем, баз данных, а как следствие, и бизнеса в целом.
Основные этапы создания ИТ инфраструктуры (с сайта компании, предоставляющей данные услуги):
Создание инженерных систем и Структурированной кабельной системы (СКС). СКС—это совокупность локальной, телефонной и электрической сетей. На данном этапе производится монтаж кабельных трасс, укладка кабелей, установка розеток, кроссирование патч–панелей, разводка и подключение электрических сетей, установка оборудования серверной комнаты.
Создание сетевой инфраструктуры. Выполняется установка и пуско-наладка активного сетевого оборудования и создание беспроводных сетей Wi-Fi.
Установка и настройка автоматической телефонной станции (миниАТС). Производится установка пуско-наладка миниАТС, программирование, подключение к городским телефонным сетям.
Закупка оборудования и программного обеспечения.
Установка серверного оборудования. Производится установка и пуско-наладочные работы серверного оборудования.
Запуск основных сетевых служб на основе протокола TCP/IP. Выполняется установка служб DHCP (Dynamic Host Configuration Protocol) — это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP, DNS (Domain Name System). — компьютерная распределённая система для получения информации о доменах компании, WINS (Windows Internet Name Service) — служба сопоставления NetBIOS-имён компьютеров с IP-адресами узлов.
Внедрение службы каталогов Active Directory. Служба каталогов AD является управляющим центром корпоративной информационной системы. Active Directory обеспечивает хранение и управление информацией обо всех пользователях и устройствах и является единой точкой аутентификации и авторизации. Реализация службы каталогов производится на базе операционных систем Windows Server 2003 R2 или Windows Server 2008.
Внедрение файловых серверов. Файловые сервера являются основным хранилищем общих документов предприятия, благодаря чему эти документы становятся доступны всем сотрудникам компании. Файловые сервера позволяют создать отдельную папку для каждого сотрудника/отдела/подразделения и назначить ей уникальные разрешения доступа.
Развертывание систем управления базами данных (СУБД). Система управления базами данных обеспечивают хранение, доступ и управление базами данных приложений. Развертывание СУБД осуществляется на основе Microsoft SQL Server.
Внедрение систем учета и управления Интернет трафиком. Системы учета и управления Интернет трафиком позволяют контролировать и управлять доступом каждого сотрудника компании в сеть Интернет и доступом к внутренним ресурсам компании из сети Интернет. Данные системы внедряются на основе следующих продуктов: Microsoft ISA Server, Kerio WinRoute Firewall, Linux/FreeBSD. Для компаний малого бизнеса данные задачи можно реализовать с помощью роутеров на базе оборудования CISCO, 3COM, D-link, LinkSys и прочее
Внедрение систем корпоративной почты.
Внедрение системы резервного копирования. Система резервного копирования обеспечивают защиту всей электронной информации предприятия.
Внедрение систем информационной безопасности Данные системы внедряются для обеспечения безопасности информационной сети предприятия и позволяют вести управление всем антивирусным ПО как на серверах, так и на рабочих станциях.
Организация рабочих мест. На данном этапе производится установка и пуско-наладка рабочих станций и другого оборудования, необходимого конечному пользователю.
Установка и настройка периферийной техники. Подключение и настройка принтеров, сканеров, многофункциональных устройств и т.д.
Примечание Саши: Как я понимаю, смысл информационной инфраструктуры и инфраструктуры ИС похож, но ИИ глобальна, а ИИС локальна.
Архитектура ИС
По ГОСТ Р ИСО 15704-2006 «Промышленные автоматизированные системы. Требования к стандартным архитектурам и методологиям предприятия»:
Архитектура - Описание (модель) основного устройства (структуры) и связей частей системы (физического или концептуального объекта или сущности).
Примечание - Существует только два типа архитектур, имеющих отношение к интеграции предприятия, а именно:
a) системные архитектуры (называемые иногда архитектурами "типа 1"), действие которых распространяется на проектирование системы, например, на компьютеризированную, являющуюся частью системы интеграции предприятия;
b) стандартные проекты предприятия (называемые иногда архитектурами "типа 2"), действие которых распространяется на организацию разработки и выполнения проекта, например, интеграцию предприятия или другую программу развития предприятия.
Архитектура ИС конструктивно обычно определяется как набор ответов на следующие вопросы:
что делает система;
на какие части она разделяется;
как эти части взаимодействуют;
где эти части размещены1.
Системная архитектура (ИТ-архитектура, архитектура ИС предприятия) — определяет совокупность технологических и технических решений для обеспечения информационной поддержки работы банка в соответствии с правилами и концепциями, определенными бизнес-архитектурой.
Системная архитектура состоит из трех взаимосвязанных компонентов — прикладной архитектуры, архитектуры данных и технической архитектуры. Системная архитектура в системе стандартов данного предприятия определяет правила формирования своих компонентов и обеспечения взаимодействия между ними.
Прикладная архитектура включает в себя:
прикладные системы (приложения), обеспечивающие исполнение бизнес- функций и бизнес-процессов;
интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками или потребителями данных;
средства и методы разработки и сопровождения приложений.
Архитектура данных включает в себя:
автоматизированные базы данных, обеспечивающие накопление, хранение и обработку данных, определяемых бизнес-архитектурой;
применяемые для этого системы управления базами данных или хранилищами данных;
правила и средства санкционирования доступа к данным.
Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.
Сетевая архитектура включает в себя:
локальные и территориальные вычислительные сети, включая физические собственные и арендованные каналы связи и каналообразующую аппаратуру;
используемые в сетях коммуникационные протоколы, сервисы и системы адресации;
аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.
Архитектура платформ включает в себя:
аппаратные средства вычислительной техники - серверы, рабочие станции, накопители и другое компьютерное оборудование;
операционные и управляющие системы, утилиты и офисные программные системы;
аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом - серверов) и баз данных в условиях чрезвычайных обстоятельств.
Платформа ИС
Определение с сайта Аналитика СЭД
Платформа - это комплекс аппаратных и программных средств, на котором функционирует программное обеспечение пользователя ЭВМ, другими словами это тип процессора и операционной системы, на которых можно установить программный продукт.
Из статьи ERP: ПРОДУКТ ИЛИ ПЛАТФОРМА? (http://www.iteam.ru/publications/it/section_54/article_1843/)
Как определить продукт и платформу? Сегодня ни одну систему нельзя однозначно отнести ни к одному, ни к другому типу. Понятия "чистый продукт" и "чистая платформа" сродни понятию "сферического коня в вакууме" - его можно представить, но в реальности его не существует. Продукт - это такая система, внедрение которой сводится к установке ее в информационно-технологическую инфраструктуру предприятия и обучению пользователей работе с ней. Продукт в чистом виде способен решить ограниченный круг задач и не подразумевает никакой доводки под особенности компании, которая его внедряет. Платформа - среда разработки без каких-либо ограничений и предварительных наработок, которая позволяет сделать все что угодно и как угодно.
Понятно, что в реальности ни классических продуктов, ни платформ на рынке ERP нет и не было. Однако различия возможностей разных систем в части их модификации и реализации специфичных функциональных требований, а также позиционирование этих систем производителями позволяют достаточно уверенно расположить их на отрезке "продукт - платформа".
Задачей этой статьи не является сравнение платформы и продукта и тем более доказательство превосходства одного подхода над другим. Довольно часто предприятия выбирают между двумя-тремя предлагаемыми им ERP-системами, и почти всегда оказывается, что часть из них ближе к продукту, часть - к платформе. Объясняя выбор "продуктовой" системы, представители ИТ-служб предприятий часто прибегают к четырем аргументам, перечисленным ниже:
в "платформенной" системе можно многое переделать. Cлишком большой объем доработок может привести к невозможности протестировать все бизнес-кейсы и, как следствие, к отсутствию уверенности в правильности результата;
процессы нашей компании далеки от совершенства и поэтому тормозят развитие бизнеса. Если мы выберем платформу, будет велик соблазн (и возможность) отказаться от использования бизнес-процессов, заложенных в систему, и доработки системы "под бизнес", в то время как продукт более консервативен в вопросе модификаций;
приобретая платформенную систему X, которая не поддерживает нужные нам функции, мы обрекаем себя на разработку этих функций, которые уже есть в продукте Y. Зачем тратить лишние ресурсы и время?;
на системе X уже есть отраслевое решение, которое работает в компании N. Мы купим эту систему вместе с отраслевым решением, с минимальными затратами развернем его в нашей компании и тем самым решим задачи в области бизнеса и автоматизации.
Тем не менее, "продукт-ориентированные" аргументы не всегда определяют однозначный выбор продукта.
Примерами платформ, для развёртывания ИС могут быть:
Аналитическая (информационно-аналитическая) платформа - Специализированное программное обеспечение, которое содержит в себе все инструменты, необходимые для осуществления процесса извлечения скрытых закономерностей из массивов данных. Обычно такие системы реализуют их консолидацию в едином источнике (хранилище), извлечение, преобразование и трансформацию, аналитические алгоритмы и средства визуализации Data Mining, а также тиражирование результатов.
Представители: зарубежные компании - BusinessObjects (www.businessobjects.com), Cognos (www.cognos.com), MicroStrategy (www.microstrategy.com), Oracle (www.oracle.com), SAS (www.sas.com), Microsoft (www.microsoft.com), Hyperion (www.hyperion.com), а также российские разработчики - фирмы BaseGroup Labs (www.basegroup.ru) с пакетом Deductor и Intersoft Lab (www.iso.ru) с платформой хранилищ данных и аналитической платформой “Контур”.
Платформы построения ECM-систем и СЭД: платформы и приложения, на базе которых можно строить корпоративные системы (и системы электронного документооборота в частности): SharePoint, офисные пакеты, .NET, Java 2 EE, веб-платформы. Примеры разработчиков таких платформ - EMC, Oracle, Microsoft, 1С
Платформы построения учётных ИС (ERP)
Сохранённая ссылка:
http://webcache.googleusercontent.com/search?q=cache:7VEtiIbaL0UJ:www.sb-serv.ru/itinfrastructure.html+%D0%B8%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0+%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9+%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B&cd=20&hl=ru&ct=clnk&gl=ru&source=www.google.ru
Ответ прошлых лет (Ден)
Инфраструктура информационных систем - это система организационных структур, обеспечивающих функционирование и развитие информационного пространства и средств информационного взаимодействия.
Информационная инфраструктура:
включает совокупность информационных центров, банков данных и знаний, систем связи;
обеспечивает доступ потребителей к информационным ресурсам.
Качественная инфраструктура информационных систем – это такая система, которая обеспечивает всего три ключевых момента:
Доступность для инфраструктуры означает, что всегда можно получить оперативную информацию, найти файл там, где его положили, и пользоваться всеми ресурсами и сервисами круглосуточно и круглогодично.
Надежность – это понятие несколько шире, чем «у-нас-все-всегда-исправно». Так попросту не бывает: все, что может сломаться – обязательно рано или поздно сломается. Другое дело, что это не должно стать катастрофой для вашего бизнеса. Что бы не случилось, пользователь не должен замечать всех этих проблем – данные не исчезнут, базы данных останутся в работе, обмен сообщениями продолжится.
Безопасность – параметр, о котором все говорят, но очень немногие знают, чего же они хотят. Данные, накопленные вашим предприятием слишком ценны, чтобы позволять украсть их или испортить. Их нужно защищать, защищать и еще раз защищать! Причем делать это нужно таким образом, чтобы это не влияло на текущую работу, не вызывало излишних неудобств, и чтобы обоснованные ограничения нельзя было обойти.
Вопрос по платформам открыт
20. Проектирование ИС []
№ | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
20 | 2.2., 32.3., 35.3., 38.3., 42.2. | Проектирование информационных систем. Особенности методологии SADT. Основные виды диаграмм. Требования ГОСТ P 50.1.028 - 2001. | Маятин Александр Владимирович | Аня Тарасова | ОПЛ (Ден), ОПЛ (Мадина), готовый ответ Милы |
Готовый ответ Милы
Методология SADT (Structured Analisys and Design Technique - технология структурного анализа и проектирования) разработана Дугласом Т. Россом в 1969-1973 годах. Технология изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения. SADT - одна из самых известных и широко используемых методик проектирования. Новое название методики, принятое в качестве стандарта - IDEF0 (Icam DEFinition) - часть программы ICAM (Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства), проводимой по инициативе ВВС США.
Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы описаний.
В IDEF0 система представляется как совокупность взаимодействующих работ (или функций). Связи между работами определяют технологический процесс или структуру взаимосвязи внутри организации. Модель SADT представляет собой серию диаграмм, разбивающих сложный объект на составные части.
Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода – с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков.
Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 6 блоков.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.
Каждый блок на диаграмме имеет свой номер.
На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д..
Работы (activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты (изображается в виде прямоугольников). Каждая из работ на диаграмме может быть впоследствии декомпозирована.
Как отмечалось выше, в терминах IDEF0 система представляется в виде комбинации блоков и дуг. Блоки представляют функции системы, дуги представляют множество объектов (физические объекты, информация или действия, которые образуют связи между функциональными блоками). Взаимодействие работ с внешним миром и между собой описывается в виде стрелок или дуг. С дугами связываются метки на естественном языке, описывающие данные, которые они представляют. Дуги показывают, как функции системы связаны между собой, как они обмениваются данными и осуществляют управление друг другом. Дуги могут разветвляться и соединяться. Ветвление означает множественность (идентичные копии одного объекта) или расщепление (различные части одного объекта). Соединение означает объединение или слияние объектов. Пять типов стрелок допускаются в диаграммах:
Вход (Input) - материал или информация, которые используются работой для получения результата (стрелка, входящая в левую грань).
Управление (Control) - правила, стратегии, стандарты, которыми руководствуется работа (стрелка, входящая в верхнюю грань). В отличии от входной информации управление не подлежит изменению.
Выход (Output) - материал или информация, которые производятся работой (стрелка, исходящая из правой грани). Каждая работа должна иметь хотя бы одну стрелку выхода, т.к. работа без результата не имеет смысла и не должна моделироваться.
Механизм (Mechanism) - ресурсы, которые выполняют работу (персонал, станки, устройства - стрелка, входящая в нижнюю грань).
Вызов (Call) - стрелка, указывающая на другую модель работы (стрелка, исходящая из нижней грани).
Различают в IDEF0 пять типов связей работ.
Связь по входу (input-output), когда выход вышестоящей работы направляется на вход следующей работы.
Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление следующей работы. Связь показывает доминирование вышестоящей работы.
Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Используется для описания циклов.
Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. Является показателем эффективности бизнес-процесса.
Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой и показывает, что работа подготавливает ресурсы для проведения другой работы.
Из перечисленных блоков, как из отдельных кирпичиков, строится диаграмма. Пример SADT-диаграммы:
- Архитектура crm-систем
- 2. Архитектура кис []
- 3. Архитектура кис []
- 4. Архитектура кис []
- Готовый ответ. (Гриша) scm ( система управления сетями поставок ) -
- Scm надо рассматривать вне erp, а как отдельную систему с ней взаимодействующую.
- Функции scm
- Архитектура scm
- 5. Архитектура кис []
- Информационная система как производственная система
- 6. Архитектура кис []
- Классификация по архитектуре
- Классификация по степени автоматизации
- Классификация по характеру обработки данных
- Классификация по сфере применения
- 7. Архитектура кис []
- 8. Архитектура кис []
- 1С:Зарплата и Управление Персоналом
- 9. Архитектура кис []
- 2. Программно-аппаратная платформа
- 3. Системы документооборота
- 4. Информационные системы
- 10. Архитектура кис []
- § Iso/iec 12207:1995 – стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного по. Стандарт не содержит описания фаз, стадий и этапов.
- Каскадная модель
- Итеративная
- 8.2.3. Типы резервного копирования
- 8.2.3.1. Полные копии
- 8.2.3.2. Добавочные копии
- 8.2.3.3. Разностные копии
- 8.2.5. Хранение резервных копий
- Модели разработки ис
- Методы проектирования снизу-вверх и сверху-вниз
- Подходы к проектированию ис
- 1. Структурный (функциональный) подход
- 2. Объектно-ориентированный подход
- Диаграммы потоков данных dfd (Data Flow Diagrams)
- 1 Область применения
- 2 Определения
- Методология функционального моделирования работ sadt
- Диаграммы потоков данных dfd (Data Flow Diagrams)
- Особенности методологии uml
- Основные виды диаграмм, классификации
- Другая классификация (более поздняя, более полная)
- Детальное описание диаграмм
- 6) Диаграмма кооперации
- Особенности применения
- Способы применения uml при разработке по
- Методология объектного проектирования на языке uml (uml-диаграммы)
- Модель rup. Основные диаграммы модели rup.
- 3. Архитектура Системных Паттернов
- 3.1.1 Репозиторий
- 3.1.2 Клиент/сервер
- 3.1.3 Обьектно - ориентированный, Модель предметной области (Domain Model), модуль таблицы (Data Mapper)
- 3.1.4 Многоуровневая система (Layers) или абстрактная машина
- 3.1.5 Потоки данных (конвейер или фильтр)
- 4.1 Структурные паттерны интеграции
- 4.1.1 Взаимодействие "точка - точка"
- 4.1.2 Взаимодействие "звезда" (интегрирующая среда)
- 4.1.3 Смешанный способ взаимодействия
- 4.2 Паттерны по методу интеграции
- 4.2.1 Интеграция систем по данным (data-centric).
- 4.2.2 Функционально-центрический (function-centric) подход.
- 4.2.3 Объектно-центрический (object-centric).
- 4.2.4 Интеграция на основе единой понятийной модели предметной области (concept-centric).
- 4.3 Паттерны интеграции по типу обмена данными
- 4.3.1 Файловый обмен
- 4.3.2 Общая база данных
- 4.3.3 Удаленный вызов процедур
- 4.3.4 Обмен сообщениями
- Образец (паттерн) проектирования.
- Модель sadt. Основные диаграммы модели sadt.
- Все указанные требования должны быть трассируемыми.
- Документация, создаваемая на различных этапах жизненного цикла
- 1.7. Тестирование, верификация и валидация - различия в понятиях
- 1) Требования документации охватывают весь жизненный цикл программного обеспечения.
- 2) Документирование должно быть управляемым.
- 5) Должны быть определены и использованы стандарты по документированию.
- 6) Должны быть определены средства поддержки.
- 1) Требования документации охватывают весь жизненный цикл программного обеспечения.
- 2) Документирование должно быть управляемым.
- 5) Должны быть определены и использованы стандарты по документированию.
- 6) Должны быть определены средства поддержки.
- 1. Информация для управления
- 2. Связь между задачами
- 3. Этапы разработки системы бюджетирования
- 4. Главные этапы бюджетирования: формирование финансовой структуры, создание структуры бюджетов
- 5. Типичные причины, ведущие к снижению эффективности бизнес-процесса бюджетирования
- Что такое затраты
- Непосредственная классификация затрат
- Описание видов затрат
- 1) Входящие и истекшие
- 2) Прямые и косвенные затраты.
- 3) Основные и накладные.
- 4) Производственные и внепроизводственные.
- 5) Одноэлементные и комплексные затраты.
- 6) Постоянные, переменные и полупеременные.
- 7) Затраты, принимаемые и не принимаемые в расчет при оценках.
- 8) Безвозвратные затраты.
- 9) Вмененные (воображаемые) затраты.
- 10) Приростные и предельные затраты.
- 11) Планируемые и непланируемые затраты.
- Ещё одна классификация затрат
- Ещё одна классификация затрат в уу
- 1) Процесс принятия управленческих решений
- 2) Процесс прогнозирования
- 3) Процесс планирования
- 4) Процесс нормирования
- 5) Процесс организации
- 6) Процесс учета
- 7) Процесс контроля
- 8) Процесс регулирования
- 9) Процесс стимулирования
- 10) Процесс анализа
- Классификация затрат в отечественном управленческом учете.
- 2. Определение затрат. Как классифицировать затраты
- Методы учета затрат и калькулирования
- 1.Понятие себестоимости и калькулирования себестоимости
- 2. Попроцессный и позаказный методы калькулирования себестоимости
- 3.Методы калькулирования по полноте затрат
- Метод полных затрат
- Директ-костинг
- Ещё один метод - abc-костинг (дифференцированный метод учета себестоимости)
- Методы калькулирования себестоимости продукции.
- 1. Нормативный метод калькулирования
- 2. Метод (способ) прямого счета
- 3. Параметрический метод
- 4. Коэффициентный метод
- 5. Комбинированный и позаказный методы
- 6. Попередельный метод калькулирования
- 7. Позаказный и попроцессное калькулирования
- 9. «Директ-костинг» (direct costing)
- Что такое управленческий учет (уу)
- Цель и задачи уу
- Другое описание задач уу
- 1. Учет ресурсов организации
- 2. Контроль и анализ финансово-хозяйственной деятельности
- 3. Планирование
- 4. Прогнозирование и оценки прогноза
- Ещё одно описание задач уу
- Объекты
- Задачи управленческого учета
- 1. Учет ресурсов организации
- 2. Контроль и анализ финансово-хозяйственной деятельности
- 3. Планирование
- 4. Прогнозирование и оценки прогноза
- 1. Система учета и управления затратами
- 2. Система показателей деятельности
- 3. Система долгосрочных и текущих бюджетов
- 4. Система управленческих отчетов
- 1. Идентификация, измерение и накопление данных
- 2. Анализ, подготовка и интерпретация информации
- 3. Разработка и технологическое внедрение информационной системы
- 4. Администрирование системы управленческого учета
- 8. Факторы, оказывающие влияние на организацию системы управленческого учета в организациях
- Определение
- Какие затраты включаются
- Как ведётся учёт затрат
- Где используется
- Ключевые понятия
- Сущность
- Пример:
- Достоинства метода
- Недостатки метода
- Система «директ-костинг» в современном управленческом учете.
- 9. «Директ-костинг» (direct costing)
- Сущность и методика нормативного метода учета затрат.
- 1. Нормативный метод калькулирования
- Определение
- Состав себестоимости
- Виды себестоимости
- Структура себестоимости
- Структура себестоимости по статьям калькуляции
- Структура себестоимости по элементам затрат
- Состав и структура себестоимости продукции
- Показатели себестоимости продукции
- Базовые показатели финансового менеджмента.
- I классификация
- II классификация
- Эффект финансового левереджа;
- Этапы оптимизации структуры капитала Анализ капитала
- Определяется
- Определяют систему коэффициентов
- Эффективность использования капитала
- Оценка факторов, определяющих структуру капитала
- (Применить) Методы оптимизации
- Глава 1. Условия осуществления безналичных расчетов
- Глава 2. Расчеты платежными поручениями
- Глава 3. Расчеты по аккредитивам
- Глава 4. Расчеты чеками
- Глава 5. Расчеты по инкассо
- Глава 6. Заключительные положения
- Учет дебиторской задолженности
- 1. Учет кредиторской задолженности
- 1.1. Учет расчетов займам
- 1.2. Учет расчетов с поставщиками и подрядчиками
- 1.3. Учет задолженности по налогам
- 1.4. Учет прочей кредиторской задолженности
- 2 Базовые денежные потоки экономической системы.
- Государственный кредит.
- Источники образования государственных доходов.
- 7. Коммерческий кредит (кк) и его особенности
- Обязательное и добровольное страхование и их взаимодействие.
- Коммерческий кредит и его особенности.
- 1 Понятие ликвидности активов и ее связь с доходностью.
- Финансовый рынок и его макроэкономическая задача.