Всё для Учёбы — студенческий файлообменник
1 монета
docx

Студенческий документ № 030892 из МАЭП

Проектирование информационных систем.

1. Советов В.Я. Теоретические основы автоматизированного управления.

2. Хетакуров Я.А. Проектирование АСОИиУ.

Структурное представление автоматизированной системы. Отражает её укрупнённый состав с точки зрения взаимодействия человека и машины или компьютера. Независимо от архитектуры системы количества рабочих мест функциональности применяемой технологии обработки информации и др. факторов обязательно учитываемой при создании любой системы, в составе АИС выделяют .

Структурное представления АИС.

Именно конечные пользователи играют важнейшую роль, подавляющее большинство систем создаётся для поддержки выполнения должностными лицами предприятия своих обязанностей. Выступающие как пользователи АИС занимают конкретные ячейки в организационной структуре предприятия вне зависимости от наличия или отсутствия АИС независимо от наличия и отсутствия АИС, именно для этих пользователей АИС является инструментом более эффективного выполнения своих функции. В тоже время эксплуатационный персонал АИС решает вспомогательный задачи его цель обеспечение функционирования систем. Любые должности связанный с эксплуатацией АИС,( системных администраторов, программистов, электронщиков, контент менеджеров) только в связи с необходимостью поддержки эксплуатации системы именно для них аппаратно программный комплекс это основной объект приложения профессиональных усилий, эффективное и длительное функционирование которого является залогом и условием.

Аппаратное программный комплекс, состоящий из комплекса технических средств и установленное на нём программной обеспечение и машинных баз данных.

Интерфейс АИС это необходимое средство взаимодействия между персоналом и АПК, программной - аппаратным комплекс, характер и степень сложности интерфейса, зависит от применяемого оборудования и программного обеспечения , характеры и сложности решаемых задач, уровня информационной и общей культуры разработчика. А так же от уровня компетентности в области ИТ конечных пользователей и эксплуатационного канала АИС. Чем ниже ожидаемый уровень компетентности пользователя, тем более избыточным дружественным и интуитивно понятным должен быть пользовательский интерфейс и наоборот средства технического интерфейса между АПК и специалистами по эксплуатации АИС чаще всего обладают лаконичности и строгостью. При этом реализуют сложные функции поддержания работоспособности, и восстановления живучести АИС.

Жизненный цикл АИС.

Современный подход к проектированию АИС, основан на понятии жизненного цикла которая построена на комплексном взаимодействии. Связанных между собой модели. При создании любой автоматизированной системы разработчик всякий раз повторяет одну и ту же последовательность действий, связанную с установлением отношений заказчиком, выявлением и формализацией требовании к АИС, выполнением проектных и внедренческих процедур. В процессе эксплуатации АИС пользователи с заданной периодичностью, решают функциональный задачи, а эксплуатационный персонал, выполняет регламентные работы, в соответствии. Жизненным циклом автоматизированной системой или АИС называется совокупность связанных процессов создания и последовательного изменения состояния АИС от формирования исходных требовании к ней, до окончания эксплуатации и утилизации комплекса средств. Характеризуется универсальной необходимой и достаточной для применения любым видам систем обработки данных.

И эксплуатацией АИС, предметным областям и историческим периодам их применения жизненный, к придметным областям историческим их применения, жизненный цикл обладает полнотой так как он охватывает все этапы существования АИС от зарождения её замысла до фактического отказа от использования и утилизации компонентов аппаратно программного комплекса и технологии меняются или реорганизации, важным элементом концепции жизенного цикла, является воз производимость допускающая повторения всех необходимых действии в случии принятия соответствующего решения. Ещё одно важной свойство АИС реализация этапов по спирали, то есть возможность выполнения очередного видка " не только с чистого листа" но и возможность развития уже существующей АИС. Возможность тем самым развивать на более высоком уровне АИС используя опыты и потенциал накопленный предыдущими разработчиками и пользователями. Существующую структуру жизненного цикла АИС можна изобразить следующим образом. Жизненный цикл состоит из пяти фаз. Каждый из которых соответствует конкретное состояние системы, предопределённое периодом жизни АИС и целями стоящими перед закупщиком и разработчиком. Фазе обосновании АИС находится в состоянии замысла, заказчик и разработчик формулируют и сближают свои представления о целесообразности АИС согласуют условия будущего взаимодействия и документально закрепляют отношения и взаимные обязательства на следующих фазах жизненного цикла.

На фазе создания система прибывает на стадий объекта разработки разработчик предлагает реализует и документирует решение по всех аспектам и компонентам АИС, а заказчик проводит экспертизу оценивает качество этих решений. Можно характеризовать как работа способный продукт, в процесе ведрения заказчик принимает окончательное решении о соответствии АИС изначально сформулированным требованиям. На фазе эксплуатации АИС находится на базе функционального элемента предприятия она интегрирована и реализуют свои возможности в максимальной степени длительность фазы эксплуатации зависит от профессионализма разработчика и качества предложеных им решения- чем дольше эксплуатируется система тем выше эффективность вложения в её создание. На стадии упадки систма может оказаться в состоянии агонии, либо внезапные изменения окружающей среды, функциональный или организационной структуры предприятия, либо инфраструктуры самой АИС оказывается настолько серьёзными что её внутренние механизмы оказываются не достаточными для адаптации к происходящим переменам. Результаты перестают соответствовать ожиданиям руководства предпрития оно перестают указывать на устаревшую версию АИС, как правило очередной виток жизненного цикла завершается принятием следующего по спирали решения о реализации очередного проекта АИС. Либо на новых принципах и методических подходах либо в порядке реконструкции ранее эксплуатриуевших АИС границы между фазами чаще всего размыты и не являются чёткими. От фазы обоснования к фазе создания. Этот переход обычно точно определён даты вступления в силу договора о создании АИС. В тоже время реализация и документирование решении могут совпадать по времени подготовкой объекта к воду АИС в эксплуатацию и даже с опытной эксплуатацией отдельных компонентов систем.

Наиболее не чёткой является граница между фазами эксплуатации и упадка, Поскольку деградация системы происходит постепенно и её осознание часто определяется способностью руководства предприятия реально оценивать эффективность функционирования объекта и принимать жёсткие и ответственные решения.

Разделение жизненного цикла имеют в первую очередь разделения жизненного цикла фаз имеют концептуальное решение но оно не годится для практического решения, в повседневной практике каждый этап по этой причине государственным стандартом гост32.003 введены термины , стадия и этап создание автоматизированных систем в настоящее время понятие жизненный цикл АИС, эти термина входят следующим образом.

Одна из частей цикла выделенная с учётом конкретной цели и стоящей перед исполнителями работой определённой период жизни АИС. Этап это часть жизненного цикла АИС выделенная по соображению единства работ или конкретного завершающего результата, отдельные элемента жизненного цикла, можно обнаружить в нормативных документах по созданию АИС, разработанных ещё в 80-х годах прошлого века и формально действующих до нашего времени.

Выделены следящие стадии создания АИС:

1. Формирования требования к автоматизированной системе.

2. Разработка концепции автоматизированной системе.

3. Техническое задание.

4. Эскизный проект.

5. Технический проект.

6. Рабочая документация.

7. Ввод действие

8. Сопровождения работы автоматизированных систем.

Недостатками такого разделения на стадии при создании АИС, являются следующие причины.

1. С формальное точки зрения создание АИС , возможно только после принятия соответствующего решения подтверждённого поступившую в силу юридически значим договором между заказчиком и разработчиком. Поэтому все работы предшествующие заключению такого договора ( в том числе и подготовка к ТЗ на АИС, Лишь предваряет вид такой деятельности и не могут включаться в его состав.

2. Учтены не все стадии и этапы нет упоминания о фазе упадок, а в фазах обоснования создания и эксплуатации перечислены не все важнейшие стадии этапа.

3. Вызывает сомнение целесообразность выделения в отдельную стадию весьма важной и конкретной работы по разработке ТЗ, которая фактически завершает формулирование требовании к системе и открывает возможность заключения договора между разработчиком и заказчиком систем.

4. Название стадии рабочая докментация не соответсвуюет состову и содержанию работ в частности по причине включения в эту стадии этапа , разработка или адаптация программы, отсутствует упоминание о такиких видах деятельности как разработка эксплуатационных документов и контрольных примеров.

5. С формально точки зрения сопровождение не может считаться стадией создания АИС, по скольку, осуществляется только после внедрения полностью готовой системы и предписания соответствующего акта.

Перечисленные причины свидетельствуют о необходимости уточнения содержания фаз жизненного цикла АИС.

Для согласования и утверждения проет технического задания, содержащее важнейшие требования к системе и технические условия её разработки и внедрения . Заключения договора, если заказчик утверждает ТЗ то разработчик согласовывает с ним, финансовые организационные и другие создания АИС, которые вносят текст договора о создании системы, пописание этого договора определяет завершение первой фазы жизненого цикла АИС.

Для успешного точки зхрения разработчика фазы обоснования необходимо согласие заказчика со всеми предложениями рекоминдациями и выводами разработчика, поскольку, финансовыми обезательствами. До заключении оговора до создания АИС разработчик находится в ситуации характер, на фазе создания. В зависимости от принятой концепции АИС , на базе типовых проектных решений решений или создания оригинальной системы, выполнения работ на этой стадий или фазе если принята концепция использования, то на фазе создания выделяют следующие стадии, дополнительное обследования объекта и ескизное проектирование., адаптация . Дополнительное обследование объекта автоматизациии и дополнительное проектирование на этом этапе уточняются требования к создаваемой АИС и наличие необходимой аппаратно программной инфра структуры; составляются функциональная организационная, выясняется степень их отличий от принятых в NGY? И разрабатывается проект согласования этих моделей и разрабатывается проект согласования, состовляются заявки на приобретение необходимых програмных и аппаратных средств, состовляются задание на реализацию смежных частей проекта АИС, строительно монтажные электро технические и др. работы специализированные оргианизациями или суб подрячками. Здесь формируется конфигурация типового проектного решения , в максимальной степени соответсвующая требованию и состоянию объекта, автоматизации, и составляется проект дороботки этой конфигурации адаптация для ПР конкретным условиям приминения на этом этапе доробатывается в случае необходимости информационное программное обеспечение ТП; разрабатывается проект настройки то есть выбор и задание конкретных значений всех параметров выбора параметров конкретной системы; готовятся контрольные примеры функционирования АИС, состовляется или дорабатывается и согласовывается заказчиком рабачая и эксплутационная документация; приобретацию на объект автоматизации необходимые и аппаратные средства; реализуются смежные части проекта АИС.

В случае разработки оригинальной системы фаза создания подразделяется на следующие стадии. Реализация. На этом этапе уточняются требования к АИС и наличе аппаратной инфра структуры строятся ианализируются функциональная оргинизационная и информационная структура объекта автоматизации; формулируются рекомендации по совершенствованию этих моделей без применения комьютерныхинформационных и комуникационных технологий; высняется степень готовиности заказчика к реинжинирингу информационной системе предприятия.

Эскизное проектирование выбираются и описываются и предлогаются заказчику для обсуждения альтернативные варианты структуры и технологии функционирования АИСЯ; после принятия заказчиком решения о выборе для реализации конкретного варианта АИС состовляются заявки на приобретение конкретных програмных и аппаратных средств; состовляются задания на реализацию смежных частей проекта АИС, они должны выполнятся в согласовванные сроки.

Техническое проектирование , здесь формулируются и документируются заказчиком решения по всем компонентам АИС; Состовляются задания на смежных АИС решения организациями или суб подрячиками реализация здесь разарабатывается оригинальное програмное обеспечние; готовятся контрольные примеры, проверки функционирования АИС состовляется и согласовывается заказчиком, рабочий и эксплутационно документальный; Приобритаются и постовляются на объект автоматизации необходимые аппаратные средства; реализуются смежные части проекта АИС результаты реализации системы передаются заказчику по актам приёмки и передачи.

Представленая схема реализация фазы создания соответствует наоболее популряному среди отечественных разработчиков, так называемому каскадному подходу к построению систем. На ряду с ним созданны и успешно используются альтернативные подходы сперальный, подход с созданием прототипов или называемый быстрой разработкой приложении и возможно других.

Этапы и стадии работ при реализации стадии внедрения распределены следующим образом, подготовка объекта к воду АИС действия, предварительные испытания , опытная эксплуатация. По результатам которых акт окончательный

На первом этапе принимаются в эксплуатацию смежные части проекта АИС, выполняются и пуско наладочные работы на комплексе технических средств. Инсталлируется программное обеспечение. Проводится обучение и переподготовка персонала на этапе п предварительных испытаний формируется и предступает к работе приёмочная комисия, которая проверяет комплекстность и оценивает качество предложенных разработчиком решений ; выясняется готовность объекта автоматизации к эксплуатации АИС; по результатам работы комиссии принимается решение о приёмке АИС опытною эксплуатацию, на этапе опытной эксплуатации проверяется функционирование АИС в реальных производственных условиях с необходимой подстраховкой на случай возможных сбоев и аварийных ситуации, на случай возможных сбоев и аварийных систуации вызванных ошибками разработчика или не компетентными действиями работника объекта автоматизации, оценивается качество полученных решении функциональных задач а так же комфортность работы конечных пользователей и эксплуатационного персонала, это сотрудники предприятия или заказчика. На последнем этапе, анализиурет результаты опытной эксплуатации АИС или системы и с учётом мнения заказчика и конечными пользвателями и принимает решения. По завершении периуда гарантийного обслуживания, заказчик может предложить разработчику взять на себя функции сопровождения, то есть поддержания жизни способности АИС. Эта работа так же имеет договорную основу и разработчик может ( но не обяязан) согласится заключить договор, если его удовлетворяют предложенные заказчиком финансовые и прочие условия , перечень объём и сроки обязательств, по сопровождению не регламентирвонны какими-либо нормативными документами и опредеяются только соглашением сторон.

Чёткие границы между экпслуатциями фазы и упадка не существует, при грамотном сопровождении АИС, её персонал и руководители предприятия, должны отслеживать нигативные изминения или внутренних компонентов системы, при появлении таких изменении принимаются меры по модификации АИС, для предупреждения, либо минимизации влияния на результаты решения задач или заменены оборудования выработавшего свой ресурс, в этом случае АИС может функционировать сколь угодно долго. Если же модификация оказывается не возможной. Либо используется обработки информации признаётся не эффективной или устаревшей, то ранно или поздно. Текущий виток жизненного цикла АИС завершается. Дальнейшая судьба предприятия определяется принятой стратегией предприятия и взглядами руководства на способы и направления реализации этой стратегии. Создание АИС это сложный длительный и трудоёмкий процесс. Участники которго, связанны разнообразными договорными финансовыми и другими отношениями, для реализации этого процесса привликаются значительные материальные , трудовые и финансовые ресурсы, поэтому грамотная кординация дейтельности его участников и юредически коректная построение отношений между ними имеет важное значение, сотсав участников создания, каждой конкретной АИС формируется в индивидуальном порядке. Тем не менее можно говорить о существовании некоторой универсальной среды создания АИС, структура и свойства которой, достаточно стабильны. Каждый разработик АИС должен учитывать и эффективно использовать возможности этой среды. В качсетве элементов среды создания АИС обычно рассматривают наиболее важных участников этого процесса, а качсетво свзяи между ними, каналы, покторым участники получают необходимые ресурсы.

Ключевые роли в процессе создания АИС играют, разработчик и заказчик, в качестве разработчика как правило, выступает проектно конструкторская или внедренческая организация обладающая полномочиями, профессиональными знаниями и при необходимости лицензиями на право выполнения соответствующих работ в области создания АИС. В качестве заказчика обычно выступает предприятие для которгго должна создаваться АИС. Вкачестве оифицальных представителей на переговорах, между заказчиком и разработчиком, чаще всего выступают руководители предприятии, их заместители которые по своим должностным обязоностям обладают полномочиями принятия соответствующим решениям или инные должностные лица полномочия которых подтверждены оформленными в уставном порядке довереностями, эти же лица в приделах своих полномочий, согласовывают и утверждают представленные к предписанию документы.

Источники информации об аналогах и протатипах- на ряду с собственным опытом разработчик активно пользуется информацией о методах технологиях и средствах проектирования. А так же о результатах проектной деятельности коллег разработчиков и внедренческих фирм, публикуемых в открытой печати (специальных научно технических издании, интернет публикации, нормативно технической документации ввиде гостов, международных, национальных ведомственных руководящие материалы и др. ещё одной категорией источников информации является конференции встречи специалисты, а так же участие в качестве экспертов в различных разработках, необходимо отметить что из открытых бесплатных источников, чаще всего удаётся получить лишь общую информации обзорного характера более детальные сведения, такие как методика проектирования, схемы чертежей как правило составляет коммерческую тайну их разработчиков и предоставляется при условии приобретения соответствующей лицензии. Поставщики инструментальных средств разработки приложении - для автоматизации преприятного обследования и проектирования расследования, а так же для разработки оригинальных проектных решении полностью программного и инфокоммуникационного обеспечения разработчик приобретает необходимые инструментальные средства ( системы программирования на определённом языке) системы программирования или rar средства. Системы проектирования баз данных лицензия на их использования у фирм разработчиков, либо у их законных представителей дилера или дистрибьюторов при согласовании условии соответсвующих лицензионных соглашении необходимо особое внимание на срок действия лицензии который может быть как ограниченным так и не ограниченным а так же на условие применения продукта в рассматриваемой ситуации лицензия должна разрешать для коммерческого .

Поставщики технологии, для использования в АИС апробированных решении предлагаемых решении производители и программного обеспечения разработчик должен приобрести технологии реализации решении в таком случае на ряду с необходимыми инструментальными средствами покупатель получает детальное описание методики выполнения всех необходимых проектных и внедренческих, готовые решения в организационной структуре объекта автоматизации, алгоритмы и технологические схемы обработки информации , образцы входных и выходных документов и видео кадров и другие элементы и другой степени готовности, часто сотрудников разработчика предоставляется возможность пройти обучения поставщика технологии и получить соответствующий сертификат, что существенно повышает статус специалист на рынке услуг. Поставщики компонентов, аппаратные средства , периферийное оборудование и пакеты программ. Поставщики компоненты- включаемые в состав АИС элементы выпускаемая как продукции, системное ПО, пакеты прикладных программ выбирается разработчиком на основании информации из фирменной и рекомендуется заказчику для приобретения непосредственного поставщика, такая схема взаимодействия капитальные затраты на создание АИС. И обеспечивает гарантийное обслуживание купленных изделии, на фазе эксплуатации АИС , бланки бумагу красящие , необходимые для обеспечения бесперебойного функционирования системы информации о характеристиках исходных материалов и периодическом пополнении запасов приводится разработчиком в документации описывающей комплекс технических средств АИС. Если у заказчика отсутствуют собственные высоко квалицированные специалисты в области технологии, то для оценивания предложенных разработчиков решении он может привлечь в качестве экспертов сторонних консультантов сотрудников других организации или физических лиц. Экспертиза заключается в индивидуальном изучении материалов документации или программного обеспечения и формулировании заключения об их достоенствах и недостатках или в колигиальном оценивании созданной АИС в составе приёмной комиссии, в большиенстве случаев экспертиза произваодится на платной основе. Пресдтавлена на ресунке общая схема может мотивироваться в зависимости от конкретной ситуации которая создаётся АИС. Наиблоее часты изминения в наиболее финансовых и материальных потоков, если разработчик не заинтересован в многократном использовании и других инструментальных средств разработки и тиражирования , то он может предложить заказчику приобрести их напрямую на условиях однократного применения, оборудование может приобретутся заказчиком не только по прямым договорам с рекомендацией разработчика, но и на конкурсной основе системных интегратор, могут поставлятся разработчиком в комплексе и другими компонентами АИС. Предприятие - предприятие, бизнес- бизнес- предпрнриятие- администрация. Система автоматизированные системы технологиечской подготовки производства. Автоматизированные обучающие системы, контроля знаний, информационно поисковые системы. По уровню типизации проектных решений, орегинальные и смешенные, огрна. Широко распростроненна и повсеместно используется в практике создание и внедреение АИС,классификация систем по характеру автоматизированных функции.

Модель информационных систем и процессов . ITSM Reference model.

Первая компания которая на основе рекомендаций ITIL предложила, типовую модель информационных процессов и сервисов Serves Managements. Это модель носит рекомендательный характер, однако одна из ключевых методологии состоит в том что, несмотря на разнообразие информационных систем, их работа на 80% может быть построена на базе стандартизированных процессов и регламентов, а 20% отводится на настройку системы.

Методология ITSM в общем жизненном цикле обслуживания информационных систем выделяется 5 основных групп процессов

Рис.1 Блоки процессов модели ИТСМ.

Первые 4 блока, принято рассматривать как следующие друг за другом, в рамках жизненного цикла работы ИТ службы, а в центр помещать 5- блок, отвечающий за предоставление услуг.

Блок процессов согласование, задач и бизнеса ИТ обеспечивают реализацию ИТ стратегии в соответствии с целями бизнеса и создаёт основу для количественной оценки эффективности затрат на ИТ. В данный блок входят следующие процессы:

1. Анализ потребностей бизнеса, подразумевает анализ рынка ИТ услуг. С точки зрения и применения ИТ

2. Разработки стратегии ИТ предприятия- позволяют сформировать стратегию, на основе оценки бизнеса и спланировать ИТ архитектуру.

3. Управление клиентами, позволяет организовывать свою деятельность на партнёрских отношениях с бизнес пользователями информационных систем,

4. Планирование ИТ сервиса, позволяет сформировать необходимые этапы внедрения сервисов, оценить риски связанные с этим, и наметить пути возврата инвистиции.

Блок процессов планирования и управления ИТ-сервисами формирует детализированную информацию по проектированию новых ИТ- сервисов, управлению доступностью и качеством этим сервисов а так же поддержание баланса, между качеством и стоимостью, даный блок включает следующие процессы:

1. Управление безопасностью

2. Управление непрерывностью

3. Управление готовностью

4. Управление производительностью

5. Финансовое управление

6. Блок процесса разработки и внедрения ит-сервисов обеспечивает создание и тестирование новых сервисов и используемых ими инфраструктурных компонентов, включая: установку оборудования и ПО, разработку приложении и обучении, сюда входит 2 процесса:

1. Разработка и тестирование

2. Ввод в эксплуатацию.

Блок процессов оперативное управление ИТ- сервисами, обеспечивает ежедневный мониторинг, предоставляеммый ИТ-Сервисом, управления запросами пользователей и другие ввиды сервисных работ, в этот блок входят следующие процессы:

1. Оперативное управление

2. Управление инцидентами

3. Управление проблемами

4. Блок процессов обеспечения ИТ-сервисами, описывает предоставление соглашении и информации процедуры взаимодействия для выполнения соглашении об уровне сервиса и в состав этой группы входят 3 процесса:

1. Управление конфигурациями

2. Управление изменениями

3. Управление уровнями услуг

При внедрении процессного управления ИТ- службы предприятие методологии ITSM выделяют 3 уровня эволюции ИТ-служб:

1. Управление инфра структурой

2. Управление сервисами

3. Управление деловыми характеристиками.

Стадия управления инфра структурой, включает в себя реализацию следующих процессов:

1. Управление операциями

2. Управление конфигурациями

3. Управление изменениями

4. Управления инцидентами и сервисными запросами

Стадия управления сервисами рекомендует внедрение следующих процессов:

1. Создание и тестирование сервисов

2. Сервис ориентировано важное управление

3. Управление непрерывностью

4. Управление готовностью

5. Управление партнёрами услуг

6. Управление финансами

7. Управление проблемами

Стадии управления деловыми характеристиками определяет, уровень стратегического бизнес партнёра руководства компании и ИТ службы.

Важная характеристика этой стадии- полная интеграция ИТ - процессов в общую бизнес модель организации. Важно знать как те или иные инвестиции в ИТ могут способствовать развитию основного бизнеса компании. На этой стадии должны быть реализованны следующие процессы:

1. Бизнес оценка

2. Управление отношениями с пользователями

3. Планирование ИТ стратегии и развития архитектуры

4. Планирование развития сервиса

Программные решения HP Open View.

Программные решение, предназначены для централизованного управления ИТ ресурсами предприятия обеспечивают прозрачность управления и тесную интеграцию с бизнес процессами.

Набор решении включает:

1. Управление бизнесом

2. Управление приложениями

3. Управление ИТ службой

4. Управление ИТ инфра структурой

5. Управление перекрёстными функциями.

Гост-Р Исо_мэг государственные стандарты РФ, в основы которых положены стандарты международной организации ISO и MEG эти стандарты представляют собой, практически дословный перевод англо язычных орегиналов, орентация на международные нормативные документы соответствует очевидным тенденциям глобализации хозяйственной жизни, такой подход позволяет унифицировать к объектам стандартизации и в определённой степени упрощает интеграцию отечественных предприятии в мировую экономическую систему. Наиболее важное методическое значение имеют следующие стандарты/

Устанавливает временные рамки и за срыв сроков всегда можно предусмотреть изменения платы, соответственно для успешного выполнения договора, деятельности по созданию автоматизированной ИС должна быть эффективно организованна в частности не мало важное значение имеет создание условии для успешной работы представителя разработчика на объекте автоматизации, и к сети.

1. Приказ о начале работ.

Важнейшими предпосылками для эффективного выполнения разработчика своими функциями может являться.

Предполагает частое посещение или длительное пребывание на объекте автоматизации должны получить документальное подтверждение предоставленным ему правом работы на объекте в течении. Особо актуальность эта проблема обретает когда в качестве объекта автоматизации выступает предприятие с ограниченным режимом посещениями посторонними лицами. В персональном пропуске выдаваемому каждому, должен быть указан период его действия и возможно перечень подразделений.

Доступ к необходимой информации сотрудники разработчика должны иметь определённый доступ, а так же для проверки эффективности принимаемых решений, в частности им должно быть предоставления право ознакомление с инструктивными и методическими документами, а так же изучение анализа структуры и организации структуры технологических процессов обработки данных. Сотрудники разработчики должны иметь возможность отпрашивать по вопросам создания автоматизированной ИС, им должны быть предоставлены образцы используемых на предприятии форм документов представители разработчики должны приглушатся на все совещания и другие мероприятия на которых обсуждается проблематика автоматизаци обработки информации при этом, при этом разработчик как правило не имеет доступа к самой служебной информации составляющие коммерческую или иную тайну, условии эффективных организация рабочего места. Цели углублённого иследования автоматизации, заключается в сборе данных, необходимых и достаточных для формирования ясного и однозначного представления об автоматизируемых информационных процессах и функциях, теоретически обследования предпологают выполняют двух видов работ:

а) Сбор первчиных данных б) анализ собранной информации

На практике эти оба вида деятельности оказываются тесно взаимно связанными и выполняются с большим количеством итерации и уточнений.

Углоблённого обследование объекта на фазе создания существенно отличается от экспресс обследования проводимого на фазе обоснования по следующим признакам:

1. Легитимность по сравнению со стадием обоснованием, статус разработчиков существенно повышен- он имеет законные основания требовать от должностных лиц предприятия предоставления необходимой информации

2. Объём - объект обследования чётко определён и оговорён техническим заданием на АИС и ограничен теми подразделениями деятельность которых подлежит автоматизации и непосредственно взаимодействующими с ними подразделениями и сторонними объектами

3. Длительность - в отличии отк экспресс обследования проводимых в жатые сроки, длительность углублённого обследования согласовывается разработчиком и заказчиком при планирование создании АИС, таким образом, чтобы обеспечить полноту собранных данных и качество их анализа.

4. Глубина - результаты обследования должны быть достоверными и служить надёжным основанием для принимаемых решений, поэтому разработчик стремится создать детальное состояние текущего состояния объекта, необходимы и достаточны, для построения адекватной модели создаваемой ИС.

5. Документирование результаты углублённого обследования документируются, как правило, ввиду отчёта по обследованию или технико-экономического обоснования по созданию АИС.

И становится аналитическом обосновании, как для разработчика, так и для руководства предприятии заинтересованного в повышении эффективности заинтересованного объекта.

Сбор первичных данных ведётся по заранее составленному плану сотрудниками разработчика. Прошедшего специальную подготовку, по согласованию с работником заказчика в обследовании могут участвовать так же сотрудники объекта автоматизации заинтересованные в провидении навыков аналитической деятельности и обладающей достаточной квалификации и навыками.

Наиболее важными задачами исследования являются, выявления нормативной базы выявления объекта. Положение о его деятельности и другие материалы, которые содержат важную для разработчика информацию, о целях и задачах объекта а так же об условиях масштабах и ограничениях его функционирования. Собирается информации об организационной структуре объекта и связывающих эти элементы отношения к подчинения, выявляются служебные полномочия каждого элемента. Выявления функциональной структуры объекта между подразделениями в целом и должностями лицами внутри каждого подразделения. Выясняются различия между нормативным ( то есть оговорённым в положении и подразделении, и фактическим выполнением функции, выявляются почти выявляемые функции , которые не предусмотрены положениями и должностными инструкциями, а так же функции и задачи предусмотренными положениями и инструкциями.

Техническое проектирование.

Техническое проектирование-это одна из более трудоёмких создания АИС, цель этой стадии заключается в детальной проработке и подробном описании всех решений, реализация которых необходима для получения готовых к внедрению работоспособной версии автоматизированной ИС результат техинческого проектирования представляет собой технический проект - Технический проект комплект утвердённый заказчиком комплектации, содержащий строго формализованное и не допускающее различных толковании описания принятых решений к реализации, технический проект можно рассматривать как документальную реализацию создаваемой ИС в которой в каждом компоненте будущей системы соответствует её строгое описание.

На стадии технического проектирования деятельность разработчика носит в основном конструктивный характер преобладающая на предыдущей стадии творческая активность связанная с поиском и выработкой возможных вариантов наиболее важных решений сменяется планомерной обычной работой по детализации и документированию подлежащих реализации решений, особое значение на этой стадии приобретает такой вид деятельности как документирование, то есть представление проектных результатов виде соответствующих документов.

Можно перечислить следующие специфические особенности технического проектирования.

1. Интеграционный характер

2. Детализации описания

3. Однозначность формулировок и строгость языка

4. Соблюдение стандартов

Этапы технического проектирования.

Логику автоматизированных ИС можно описать тезисом сверху в низ или от настройку к базису, основная идея заключается в результате такой последовательности при которой в первую очредеь разрабатываются компоненты пользовательской оболочки, а её внутренней части с точки зрения пользователя имеет обеспечивающий характер инфраструктурный предметы структуры и в первую очередь комплекс технических средств и программное обеспечение - Должно не под определять а поддерживать и обеспечивать функционирование технологических способов и алгоритмов обработки информации а так же интерфейс пользователей. В частности нельзя признать удачной ситуацию в которой возможности разработчика по проектированию пользовательского экрана по интерфейсу ограничивают выборок монитора а решение по организации машинной информационной базы ограничение ёмкости накопителя на жёстком диске.

Интеграционный характер технического проектирование и взаимообусловленность решений по реализации разных компонентов ИС не позволяют сформулировать универсальную и окончательно определённую последовательность конкретных действии. Неоднократные уточнении и изменение решении принятых на более ранних этапах, их адаптация по желаниям пользователей или к изменившимся условиям, считаются нормальной практикой в деятельности разработчика ИС, общую логику технического проектирования можно представить схемой.

1. Технологический процессы обработки данных

2. Функицональя часть пользовательский интерфейс.

3. Организационное обеспечение ИС информационной системы которая требует разработки организационной структуры системы и временного регламента при решении задач,

4. информационное обеспечение которое требует разработки системы классификации кодирования и разработки информационных баз данных

5. Программное обеспечении

6. Техническое обеспечение на котором устанавливаются в системе комплекс технических средств и прорабатываются потребность в расходных материалах

7. Документирование на котором разрабатываются техническая документация

Первоочередная задача это проектирование технических процессов обработки данных, решение этой задачи нацелено на структурирование описание потоков, поддержание которых является основной задачей всей авторизированной ИС и здесь осуществляется распределение функции обработки информации между пользователями ИС.

Выбор конкретизации технологии обработки данных позволяет пред уступить к проектированию функциональной части, то есть к описанию автоматизированных функции, формулированию постановок задач и алгоритмов обработки данных, как правило это работа выполняется параллельно с разработкой внешних интерфейсов программы в первую очередь входных и входных документов и видео кадров а так же других инструментов взаимодействия пользователя с аппаратно-программным комплексом системы.

Функциональная часть автоматизированной ИС состоит из следующих компонентов:

1. Схема функциональной структуры в виде графической модели с разбиением функциональной части на отдельные блоки задач.

2. Описание автоматизируемых функции, здесь предполагается содержательное описание автоматизируемой деятельности и условии её существования.

3. Постановка задач которая предполагает содержательный и формализованные описания выполняемой функции.

4. Описание входных и выходных данных необходимых для выполнения функции.

5. Алгоритмы решаемых задач.

Организационное обеспечения ИС.

Техническое решения, такие факторы как внедрения новых и коммуникационных технологий изменение трудоёмкости ранее выполняющихся функции и необходимость решения новых задач, существенно изменения характера деятельности должностных лиц, обуславливают необходимость изменения структуры предприятия. Предварительный анализ возможных изменений проводится на этапе эскизного проектирования, в ходе технического проектирования предполагаемые изменения уточняются и после удобрения заказчиком и после их одобрения заказчиком фиксируются в документе схема организационной структуру. Дополняешься эту схему пояснительная записка к техническому проекту, внесённые в организационную структуру изменения должны так же найти отражения в должностных инструкциях пользователей АИС которые корректируется или составляется заново, при написании рабочей документации на следующей стадии, создания системы. Ещё одним важным аспектом функционированием создаваемой ИС является временный регламент, выполнения автоматизированных функции. Этот регламент определяет сроки решения задач автоматизированной системы. В совокупности с отражаемым в должностных инструкциям решения задач по исполнителям временной регламент дополняет схемы техническим процессов обработки данных информации о том кто в какие сроки и при каких условиях должен решать каждую конкретную задачу сводный временной регламент выполнения автоматизированных функции системы в целом или отдельных подсистем приводится в проектном документе описание технологического процесса обработки данных , что позволяет комплексно выбирать последовательность решения задач. При необходимости использовать общие ресурсы.

Информационное обеспечение.

Сущность функционирования любой автоматизированной системы заключается в обработки информации. Соответственно грамотно составлена организационная структура хранения данных, реализация эффективных средств доступа к ним удобства работы с информацией, а так же её надёжная защита от несанкционированного доступа критически для эксплуатации АИС в целом, в соответствии ГОСТ 24.003 информационным обеспечением ИС, называется совокупность реализованных решении по объёмам размещению и формам организации информации циркулирующей в автоматизированной системы при её функционировании. По сути это определение имеет общий или рамочный характер и предоставляет разработчикам большую свободу выбора и формулировки решения. При этом важнейшее деятельность можно считать:

1. Формулирования принципов организации машинного и вне машинного информационного обеспечения.

2. Разработка проекта пользовательского интерфейса автоматизированной ИС.

3. Разработка системы классификации кодирования информации.

4. Проектирования машинной и немашинной баз данных и процедур сопровождения этих баз.

5. Документирование принцип решений.

Выработка решений по информационному решения это один из трудоёмких этапов стадии системы, это деятельность сопровождается рядом противоречий между необходимостью учёта требовании нормативных документов и субъективными пожеланиями пользователей системы, между требованиям требованием приданием юридической силой придания решения задач и стремлением в основном использовать при сознаний пользовательского интерфейса бумажные технологии; между попытками в максимальной степени сохранить привычные формы создания данных и желаем активизировать структуры и процедуры доступа к базам данных. Поэтому процесс проектирования на этом этапе характерезуется большим количеством операции

Показать полностью…
70 Кб, 23 января 2015 в 10:17 - Россия, Москва, МАЭП, 2015 г., docx
Рекомендуемые документы в приложении