шпоргалка исис. Билет 1. Платформа Microsoft. Net Framework 0
 Скачать 151.37 Kb.
|
|
Билет №32. Содержание работ на этапах создания ИС. Организация предпроектного обследования. Организация работ на стадии технического проектирования. Содержание работ на этапах создания АИС Основная цель рабочего проекта - это разработка технической, рабочей документации, необходимой для отладки и внедрения АИС, проведение приемно-сдаточных мероприятий и обеспечение нормального функционирования системы. Внедрение разработанной системы - это процесс постепенного перехода от существующей системы обработки данных к новой, автоматизированной. Организация предпроектного обследования Предпроектная стадия включает комплекс научно-исследовательских работ и организационно-технических мероприятий по обследованию объекта автоматизации. На этой стадии исследуются экономические показатели работы предприятия или учреждения, его организационная структура, информационные потоки, документооборот, методы учета и планирования. Обследование способствует определению основных параметров проектируемой системы и подразумевает сбор данных об объекте автоматизации в соответствии с конкретно выбранными методами. Важным этапом на этой стадии является анализ результатов обследования, который учитывая характер собранных данных, их объем, и, как правило, жесткие сроки, целесообразно проводить с применением ВТ. Цель такого обследования заключается в определении экономической целесообразности автоматизации и подготовке научно обоснованных, рациональных направлений по совершенствованию управления. От качества проведенного обследования зависит весь дальнейший ход проектных работ. На этой стадии можно выделить два этапа, которые завершаются подготовкой и утверждением двух документов: ТЭО и ТЗ. ТЭО – первый документ, создаваемый на предпроектной стадии разработки системы, подтверждающий ее экономическую целесообразность и производственную необходимость. Разработка ТЭО базируется на результатах обследования объекта автоматизации и имеет вид пояснительной записки. В него включены: обоснование цели проектирования и состава комплекса подсистем и задач, перечень организационно-технических мероприятий по разработке и внедрению системы, оценка экономической эффективности. ТЗ – документ, завершающий предпроектную стадию создания АИС и включающий в себя правовое обоснование проектирования, к которому относятся издаваемые вышестоящими организациями постановления и приказы; описание цели и расчет экономической эффективности разработки; требования к задачам, техническому комплексу, обеспечивающим подсистемам и их составу. В ТЗ определяется очередность проектирования и внедрения АИС с приложением сетевых графиков и указанием источников финансирования работ. На предпроектной стадии к работам привлекается заказчик проекта, который заключает договор с проектирующей организацией на создание ТЭО и ТЗ, составляет план организационно- технических мероприятий по обследованию организации, выполняет описание действующей системы управления и действующего документооборота, согласовывает предложения по изменению методов и организационной структуры управления объектом; утверждает ТЭО и ТЗ. На этой стадии разработчик участвует в разработке плана- графика совместных работ, составляет программу предпроектного обследования и принимает участие в его проведении. Кроме того, на предпроектной стадии проектировщик системы должен обеспечить обучение персонала объекта автоматизации современным методам управления с применением разнообразных средств ВТ и оргтехники. На этой стадии разработчик согласовывает вышеназванные документы с заказчиком, рассматривает и утверждает их. Организация работ на стадии технического проектирования На стадии технического проектирования разрабатываются основные положения создаваемой системы, формулируются основные принципы ее функционирования и взаимодействия с другими АИС, определяется структура АИС и ее подсистем, осуществляются проектные решения по комплексу технических средств, созданию информационной базы. Много внимания уделяется проектированию обеспечивающих подсистем. Документация технического проекта очень обширна и многообразна. В пояснительной записке дается краткое изложение содержания проекта с указанием его соответствия существующим нормам и правилам. Особое внимание уделяется проектным решениям по комплексу технических средств. В ТЗ указывается их состав, структура, организационные формы использования на различных уровнях создаваемой АИС, описываются методы обмена данными внутри системы и с другими АИС. Создается сборник заказных спецификаций на такие виды оборудования, как средства ВТ, периферийные технические средства, оргтехника и т.д. План мероприятий по подготовке объекта к внедрению должен содержать перечень работ, обеспечивающих внедрение системы, с указанием содержания и сроков их выполнения, ответственного исполнителя и формы завершения работ. По результатам первой стадии рассчитывается экономическая эффективность проекта. Результаты расчета, затрат на создание и эксплуатацию системы, определение коэффициента эффективности и срока окупаемости, дают основание сформулировать предложения по экономии средств. Описание организационной структуры содержит изменения в данной структуре объекта автоматизации и рекомендации для реорганизуемых и вновь создаваемых объектов. Техническим проектом раскрывается постановка автоматизируемых задач, их целевая функция и характеристика, даются алгоритмы и технология решения задач на ЭВМ, определяются эффективные меры контроля достоверности данных. Здесь же дается описание комплекса задач, реализуемых средствами пакетов прикладных программ, приводится подробное описание используемых экономико-математических методов. В техническом проекте формируются требования к обеспечивающим подсистемам, определяются способы сбора и организации данных, дается структура массивов информации на технических носителях, логическая структура баз данных. По программному обеспечению выбираются общесистемные решения, включая ОС, СУБД, определяется возможность настройки пакетов прикладных программ и т.д. На этом этапе заказчик завершает работу над созданием плана организационно- технических мероприятий по подготовке к внедрению АИС, проводит мероприятия по подготовке кадров к новым условиям работы, принимает участие в проектировании форм входных и выходных документов, под руководством проектировщиков разрабатывает систему классификации и кодирования, используемую на данном предприятии. Он также уточняет исходные данные по составу и структуре информационной базы, выполняет различные подготовительные мероприятия на объекте автоматизации. Основная задача разработчика на этом этапе заключается в создании технического проекта в соответствии с ТЗ. Он разрабатывает и сдает заказчику программы и рабочую документацию по организации и ведению первичных массивов данных, разрабатывает и согласовывает с заказчиком соответствующие разделы контрольного примера, уточняет состав применяемых пакетов прикладных программ, принимает участие в обучении персонала. Билет №33. Организация работ на стадии рабочего проектирования. Организация работ на стадии внедрения системы. Организация работ на стадии рабочего проектирования Основанием для начала работ на стадии рабочего проектирования является утвержденный технический проект. В связи с тем, что основная цель рабочего проекта - это разработка технической, рабочей документации, необходимой для отладки и внедрения АИС, проведение приемно-сдаточных мероприятий и обеспечение нормального функционирования системы, рабочий проект не утверждается. По своей структуре он аналогичен техническому проекту и содержит в принципе те же разделы. В него входят уточненные и детализированные общесистемные проектные решения, программы, локальные проектные решения по отдельным функциональным и обеспечивающим подсистемам, доведенные до инструктивных материалов, перечень мероприятий по подготовке объекта к внедрению. Программная документация рабочего проекта включает:
В состав технических инструкций, которые, как правило, являются типовыми, входят инструкции по: сбору, регистрации, контролю и передаче информации; переносу ее на машинные носители, ведению архива носителей документов; порядку передачи выходной, результатной информации. Должностные инструкции определяют права и обязанности производственного и управленческого персонала при эксплуатации АИС, регламентируют их действия в новых условиях производства. Организация работ на стадии внедрения системы Внедрение разработанной системы - это процесс постепенного перехода от существующей системы обработки данных к новой, автоматизированной. Ввод в эксплуатацию проводится силами заказчика при участии разработчика и осуществляется поэтапно:
В процессе опытной эксплуатации, которая не должна превышать 3 месяцев, выявляются результаты проектной работы, неточности и ошибки, допущенные на предыдущих стадиях и этапах, происходит их устранение. На основе реальной информации проверяется качество конкретных проектных решений, инструктивных материалов, подготовленность кадров к работе в новых условиях. Проверяется возможность выполнения комплекса организационно- правовых решений проекта, в частности, по использованию информации, ее защите, достоверности, полноты, соблюдение установленных сроков поступления данных и выдачи результатов расчета. Опытная эксплуатация проводится на основе специальной программы. По результатам эксплуатации, которые оцениваются специальной комиссией, осуществляется анализ внедрения представленных технического задания и рабочего проекта. При положительных результатах составляется двусторонний акт о приемке отдельных задач и их комплексов в промышленную эксплуатацию. После завершения приемки всех задач заказчиком происходит приемка комиссией системы в целом. Дата подписания акта о приемке системы является датой ввода АИС в промышленную эксплуатацию. С этого момента ответственность за функционирование АИС несет заказчик. Заказчик обязан обеспечить выполнение персоналом должностных и технологических инструкций, полностью подготовить объект автоматизации к внедрению АИС, внести изменения в его организационную структуру, проверить эффективность реализованных проектных решений в условиях промышленной эксплуатации и по результатам функционирования АИС подготовить рекомендации по ее дальнейшему развитию. Разработчик же на заключительном этапе проектирования корректирует рабочую документацию по результатам опытной эксплуатации, участвует в работе комиссии по приемке АИС в промышленную эксплуатацию. Внедрение АИС в промышленную эксплуатацию является ответственным процессом и означает, что система приступила к практической реализации возложенных на нее функций. Со временем она может быть модернизирована. Билет №34. Средства автоматизации проектирования ИС. Основные возможности СASЕ-средств. Максимально упростить и формализовать процессы формирования системы позволяют современные case-средства. Они основаны на применении наглядной графической техники ( схемы и диаграммы) предназначенные для описания различного рода моделей. Case-технология – это методология проектирования ИС, набор методов, нотаций и инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать модель системы на всех этапах разработки и сопровождение в соответствии с потребностями пользователя. Большинство современных case-средств поддерживает методологии структурного и объектно-ориентированного анализа и проектирования ИС. Основные функции case-средств: 1. Единый графический язык. Case-технологии обеспечивают всех участников проекта, включая заказчика, единым, строгим наглядным и интуитивно понятным графическим языком, позволяющим получить обозримые компоненты простой и ясной структуры. 2. Единая база данных проекта. Основа case-технологий это использование базы данных проекта (репозитория) для хранения всей информации о проекте , которая может совместно использоваться разработчиками в соответствии с их правами доступа. Содержимое репозитория включает графические объекты различных типов, отношения между их компонентами, правила использования ими обработки этих компонентов. 3. Поддержка коллективной разработки и управление проектом. Case-средства поддерживают групповую работу над проектом, обеспечивая возможность работы в сети, экспорт- импорт любых фрагментов проекта для их развития или модификации, также планирование, контроль, куроводство и взаимодействие. 4. Маркетирование. Позволяет быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на разных этапах разработки оценить насколько она приемлема для будущих пользователей. 5. Генерация документации. Вся документация по проекту генерируется автоматически на базе репозитория. 6. Верификация проекта. Обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки. 7. Автоматическая генерация программного кода. 8. Сопровождение и реинжирининг. Средства реинжиниринга и обратного инжиниринга позволяют создавать модель системы из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кода. Билет №35. Средства быстрой разработки приложений. Быстрая разработка приложений (RAD- Rapid Application Development) основывается на визуализации процесса создания программного кода. Технологии RAD представляют программисту средства ускоряющие разработку программ, их модификацию и оплату. Для максимального упрощения работы используются графические инструменты, основанные на компонентной архитектуре. Каждый компонент является объектом, объединяющих в себе данные, методы и свойства для работы с ними. При этом компоненты являются объектами, которые позволяют изменять данные и свойства объектов. Свойства позволяют работать с данными также как и с членами классов, а с другой стороны скрывают за операциями чтения и записи вызовы методов, переводя операции над объектами на более высокий уровень абстракции. Для разработки и проектирования пользовательского интерфейса используются инструменты визуального проектирования( экранный редактор…), которые позволяют выполнять следующие операции: размещение компонента интерфейса в нужном месте, задание моментов времени их появления на экране, настройка связанных с ними атрибутов и событий. Эффективность визуального программирования определено наличием визуальных компонентов и их взаимодействием с традиционными средствами. Интегрированная среда разработки является средством, с помощью которого выполняется проектирование, отладка, тестирование и дальнейшее распространение прикладных программ. Для повышения эффективности данного процесса каждое из средств (отладчик, конструктор,..) должны быть реализованы на высоком уровне. Лидером разработки RAD является Microsoft и Borland. Билет № 36. Разработка информационных систем на основе шаблонов. Шаблоны на этапе анализа, построения архитектуры решений, кода, шаблоны тестов. Шаблон проектирования или паттерн (англ. design pattern) в разработке программного обеспечения — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста. Обычно шаблон не является законченным образцом, который может быть прямо преобразован в код; это лишь пример решения задачи, который можно использовать в различных ситуациях. Объектно-ориентированные шаблоны показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться. Классификация паттернов Архитектурные паттерны, являются наиболее высокоуровневыми паттернами, описывают структурную схему программной системы в целом. В данной схеме указываются отдельные функциональные составляющие системы, называемые подсистемами, а также взаимоотношения между ними. Архитектурные паттерны (Architectural patterns) - множество предварительно определенных подсистем со спецификацией их ответственности, правил и базовых принципов установления отношений между ними. Архитектурные паттерны предназначены для спецификации фундаментальных схем структуризации программных систем. Наиболее известными паттернами этой категории являются паттерны GRASP (General Responsibility Assignment Software Pattern). Эти паттерны относятся к уровню системы и подсистем, но не к уровню классов. Как правило, формулируются в обобщенной форме, используют обычную терминологию и не зависят от области приложения. Паттерны проектирования (Design patterns) - специальные схемы для уточнения структуры подсистем или компонентов программной системы и отношений между ними. Паттерны проектирования описывают общую структуру взаимодействия элементов программной системы, которые реализуют исходную проблему проектирования в конкретном контексте. Паттерны проектирования описывают схемы детализации программных подсистем и отношений между ними, при этом они не влияют на структуру программной системы в целом и сохраняют независимость от реализации языка программирования. Паттерны GoF относятся именно к этой категории. Под паттернами проектирования объектно-ориентированных систем понимается описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте. В русскоязычной литературе обычно встречаются несколько вариантов перевода оригинального названия design patterns - паттерны проектирования, шаблоны проектирования, образцы. Здесь в основном используется первый вариант, иногда второй. Наиболее известными паттернами этой категории являются паттерны GoF (Gang of Four), названные в честь Э. Гаммы, Р. Хелма, Р. Джонсона и Дж. Влиссидеса, которые систематизировали их и представили общее описание. Паттерны GoF включают в себя 23 паттерна. Эти паттерны не зависит от языка реализации, но их реализация зависит от области приложения. Идиомы, являясь низкоуровневыми паттернами, имеют дело с вопросами реализации какой-либо проблемы с учетом особенностей данного языка программирования. При этом часто одни и те же идиомы для разных языков программирования выглядят по-разному или не имеют смысла вовсе. Например, в C++ для устранения возможных утечек памяти могут использоваться интеллектуальные указатели. Интеллектуальный указатель содержит указатель на участок динамически выделенной памяти, который будет автоматически освобожден при выходе из зоны видимости. В среде Java такой проблемы просто не существует, так как там используется автоматическая сборка мусора. Обычно, для использования идиом нужно глубоко знать особенности применяемого языка программирования. Паттерны реализации (Implementation patterns) - совокупность компонентов и других элементов реализации, используемых в структуре модели при написании программного кода. Эта категория паттернов делится на следующие подкатегории: паттерны организации программного кода, паттерны оптимизации программного кода, паттерны устойчивости кода, паттерны разработки графического интерфейса пользователя и др. Паттерны этой категории описаны в работах М. Гранда, К. Бека, Дж. Тидвелла и др. Некоторые из них реализованы в популярных интегрированных средах программирования в форме шаблонов создаваемых проектов. В этом случае выбор шаблона программного приложения позволяет получить некоторую заготовку программного кода. Паттерны анализа (Analysis patterns) - специальные схемы для представления общей организации процесса моделирования. Паттерны анализа относятся к одной или нескольким предметным областям и описываются в терминах предметной области. Наиболее известными паттернами этой группы являются паттерны бизнес-моделирования ARIS (Architecture of Integrated Information Systems), которые характеризуют абстрактный уровень представления бизнес-процессов. В дальнейшем паттерны анализа конкретизируются в типовых моделях с целью выполнения аналитических оценок или имитационного моделирования бизнес-процессов. процесса тестирования программных систем. К этой категории паттернов относятся такие паттерны, как тестирование черного ящика, белого ящика, отдельных классов, системы. Паттерны этой категории систематизировал и описал М. Гранд. Некоторые из них реализованы в инструментальных средствах, наиболее известными из которых является IBM Test Studio. В связи с этим паттерны тестирования иногда называют стратегиями или схемами тестирования. |