шпоргалка исис. Билет 1. Платформа Microsoft. Net Framework 0
 Скачать 0.77 Mb.
|
|
Билет №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. В связи с этим паттерны тестирования иногда называют стратегиями или схемами тестирования. Билет №38. Современные технологии тестирования. Основные понятия тестирования. Фазы и этапы тестирования. Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения. С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных. Из сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. При разработки программ тестирование занимает 40 % от суммарной трудоемкости разработки продукта. Статическое тестирование выявляет формальными методами анализа без выполнения тестируемой программы неверные конструкции или неверные отношения объектов программы ( (ошибки формального задания) с помощью специальных инструментов контроля кода – CodeChecker. ) Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования (– Testbed или Testbench.) Фазы тестирования: • Модульное тестирование - это тестирование программы на уровне отдельно взятых модулей, функций или классов. Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. Модульное тестирование проводится по принципу "белого ящика", то есть основывается на знании внутренней структуры программы, и часто включает те или иные методы анализа покрытия кода. • Интеграционное тестирование - это тестирование части системы, состоящей из двух и более модулей. Основная задача интеграционного тестирования - поиск дефектов, связанных с ошибками в реализации и интерпретации интерфейсного взаимодействия между модулями. Основная разница между модульным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа. • Системное тестирование качественно отличается от интеграционного и модульного уровней. Системное тестирование рассматривает тестируемую систему в целом и оперирует на уровне пользовательских интерфейсов. Основная задача системного тестирования" в выявлении дефектов, связанных с работой системы в целом, таких как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство в применении и тому подобное. Системное тестирование производится над проектом в целом с помощью метода «черного ящика». Этапы тестирования: Каждая фаза тестирования включает в себя следующие этапы: 1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т.п. 2. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы. 3. Разработка тестов (тестового кода для тестируемой системы) 4. Выполнение тестов: реализация тестовых циклов. 5. Анализ результатов. Билет №39. Типы тестов. Разработка, управляемая тестами (Test Driven Development). Типы тестов: В тестовом плане определяются и документируются различные типы тестов. Типы тестирования по виду подсистемы или продукта: • Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом • Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т.п. • Тестирование пользовательской документации включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т.п. Типы тестирования по способу выбора входных значений: • Функциональное тестирование, при котором проверяется: – Покрытие функциональных требований. – Покрытие сценариев использования. • Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта. • Тестирование граничных значений. • Тестирование производительности. • Тестирование на соответствие стандартам. • Тестирование совместимости с другими программно-аппаратными комплексами. • Тестирование работы с окружением. • Тестирование работы на конкретной платформе • Test Driven Development: • Разработка через тестирование (Test Driven Development – TDD) - процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы. TDD определяет следующий порядок этапов программирования: • Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется. • Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал. • Рефакторинг – удалите из написанного вами кода любое дублирование. • Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными. |