Верификация программных требований к по. Инструменты автоматизации этапа



Скачать 238.67 Kb.
Дата16.09.2014
Размер238.67 Kb.
ТипДоклад

Министерство образования Российской Федерации

Государственное образовательное учреждение высшего профессионального образования

"Ижевский государственный технический университет"

Кафедра "Программное обеспечение"





ДОКЛАД

на тему: «Верификация программных требований к ПО. Инструменты автоматизации этапа»

по дисциплине: Системы автоматизированного проектирования ПО

Выполнил: студент гр. 9-19-1з

Сергеева Н.М.

Принял: Растегаев. Н.В.
СОДЕРЖАНИЕ


1 Методологии разработки ПО 3

2 Виды деятельности в разработке ПО 5

3 Верификация 7

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

2.требования высокого уровня правильно переработаны в архитектуру ПО и в спецификации требований к функциональным компонентам низкого уровня, которые удовлетворяют требованиям высокого уровня; 8

3.спецификации требований к функциональным компонентам ПО, расположенным между компонентами высокого и низкого уровня, удовлетворяют требованиям более высокого уровня; 8

4.архитектура ПО и требования к компонентам низкого уровня корректно переработаны в удовлетворяющие им исходные тексты программных и информационных модулей; 8

5.исходные тексты программ и соответствующий им исполняемый код не содержат ошибок. 8

4 Тестирование, верификация и валидация (сравнение понятий) 10

5 Технологические процессы верификации и роли в проекте, документация 12

1.типы входных и выходных документов; 12

6.общая процедура верификации; 12

7.роли и ответственности; 12

8.форматы и соглашения по идентификации выходных документов; 12

9.критерии оценки результативности этапа. 12

1.план верификации системных требований; 13

10.план верификации архитектуры; 13

11.план тестирования программного кода; 13

12.план тестирования модулей и их интеграции; 13

13.план системного тестирования; 13

14.план нагрузочного тестирования; 13

15.план полунатурных испытаний; 13

16.план приемо-сдаточных испытаний. 13

4 Формальные инспекции 16

5 Уровни процесса верификации 18

6 Способы автоматизации процесса верификации 19



6.1 Системное тестирование. 19

6.2 Интеграционное тестирование. 19

6.3 Модульное тестирование. 22

6.
4 Примеры инструментов 23

Приложение А 25





1 Методологии разработки ПО


В таблице 1.1 представлены основные модели процесса разработки программного обеспечения.

Таблица 1.1 - Модели процесса разработки ПО




Модель (методология)

Преимущество

Недостаток

1

Водопадная (каскадная)- разработка ПО делится на фазы, каждая из которых характеризуется своим набором работ. Фазы выполняются последовательно.

Переход от одной фазы к другой предполагает полное завершение предыдущего этапа.

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

2

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

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

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

3

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

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




4

Гибкая разработка — собственно итеративная разработка с длиной итерации до 2 недель (как правило)

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

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



2 Виды деятельности в разработке ПО


В таблице 2.1 представлены виды деятельности в разработке ПО.

Таблица 2.1 - Виды деятельности в разработке ПО



Название

Роль исполнителя

Автоматизируется ли?

Средства автоматизации

Пример

1

Сбор и выявление бизнес-требований пользователей

Бизнес - аналитик

нет







2

Анализ бизнес-процессов

Бизнес - аналитик

да

Пункт 6




3

Составление концепции

Бизнес - аналитик

нет







4

Сбор и выявление требований пользователей к ПО

Системный аналитик

нет







5

Анализ требований пользователей

Системный аналитик

да







6

Проектирование архитектуры

Архитектор приложения

да

Технологии структурного анализа и дизайна (SADT), системы графического обозначения, автоматизированные системы моделирования и проектирования

DFD, IDEF, UML
MagicDraw, Enterprise Architect, Microsoft Visio, Rational Rose, Visual Paradigm for UML, Rhapsody Modeler

7

Проектирование ПО и информационной системы

Проектировщик ПО

да

8

Написание кода

Программист

да

Интегрированные среды разработки (IDE`)

Visual Studio, NetBeans, Eclipse, ZendStudio, Kdevelop, MonoDevelop, Aptana, Delphi

9

Тестирование

Тестировщик

да

Unit-тесты, функциональные тесты, приемочное тестирование, системы непрерывной интеграции, системное тестирование, нагрузочное тестирование

Xunit, Selenium, Hudson, Bamboo, CruiseControl

10

Документирование

Технический писатель

да

Документирование кода,
Технологии документирования

JavaDoc, phpDoc, PLSQLDoc,

DITA, DocBook



11

Внедрение

Системный администратор

нет







12

Техническая поддержка и сопровождение

Специалист технической поддержки

нет








3 Верификация


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

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

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

Рисунок 3.1 - Процессы и документы при разработке программных систем

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



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

В состав задач процесса верификации входит последовательная проверка того, что в программной системе:

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

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

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

4.архитектура ПО и требования к компонентам низкого уровня корректно переработаны в удовлетворяющие им исходные тексты программных и информационных модулей;

5.исходные тексты программ и соответствующий им исполняемый код не содержат ошибок.

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

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

4 Тестирование, верификация и валидация (сравнение понятий)


Рисунок 4.1 иллюстрирует связь тестирования, верификации и валидации с их объектами.

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


Рисунок 4.1 - Тестирование, верификация и валидация в связи с объектами процессов

Верификация программного обеспечения - более общее понятие, чем тестирование. Целью верификации является достижение гарантии того, что верифицируемый объект (требования или программный код) соответствует требованиям, реализован без непредусмотренных функций и удовлетворяет проектным спецификациям и стандартам. Процесс верификации включает в себя инспекции, тестирование кода, анализ результатов тестирования, формирование и анализ отчетов о проблемах. Таким образом, принято считать, что процесс тестирования является составной частью процесса верификации.

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


5 Технологические процессы верификации и роли в проекте, документация


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

Перед началом верификации менеджером тестирования (test manager) создается документ, называемый планом верификации (или планом тестирования, но это не то же самое, что тест-план).

План верификации содержит последовательное описание всех этапов верификации, процедур на каждом этапе и связей с этапами разработки. Для каждого этапа определяется:


  1. типы входных и выходных документов;

6.общая процедура верификации;

7.роли и ответственности;

8.форматы и соглашения по идентификации выходных документов;

9.критерии оценки результативности этапа.

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


  1. план верификации системных требований;

10.план верификации архитектуры;

11.план тестирования программного кода;

12.план тестирования модулей и их интеграции;

13.план системного тестирования;

14.план нагрузочного тестирования;

15.план полунатурных испытаний;

16.план приемо-сдаточных испытаний.

На рисунке 5.1 изображена схема документации, сопровождающей процесс верификации.



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

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

В данном документе также определяются требования собственно к тестовой документации - тест-требованиям, тест-планам, отчетам о выполнении тестирования.

Согласно этим требованиям по системным и функциональным требованиям разработчиками тестов (test procedure developers) создаются тест-требования - документы, в которых подробно описано то, какие аспекты поведения системы должны быть протестированы. На основании описания архитектуры создаются низкоуровневые тест-требования, где описываются аспекты поведения конкретной программной реализации системы, которые необходимо протестировать.






Рисунок 5.1 - Документация, сопровождающая процесс верификации

На основании тест-требований разработчиками тестов (test developers) создаются тест-планы - документы, которые содержат подробное пошаговое описание того, как должны быть протестированы тест-требования.

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

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

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

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

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

4 Формальные инспекции


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

Такие экспертные исследования обычно называют инспекциями или просмотрами. Существует два типа инспекций - неформальные и формальные.

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

Формальная инспекция, напротив, является четко управляемым процессом, структура которого обычно четко определяется соответствующим стандартом проекта. Таким образом, все формальные инспекции имеют одинаковую структуру и одинаковые выходные документы, которые затем используются при разработке.

Факт начала формальной инспекции четко фиксируется в общей базе данных проекта. Также фиксируются документы, подвергаемые инспекции, и списки замечаний, отслеживаются внесенные по замечаниям изменения. Этим формальная инспекция похожа на автоматизированное тестирование: списки замечаний имеют много общего с отчетами о выполнении тестовых примеров.

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

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

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


5 Уровни процесса верификации


Как уже было сказано ранее, процесс верификации активен в течение практически всего жизненного цикла системы и работает параллельно с процессом разработки.

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



Процесс верификации также разбивается на отдельные уровни:

  • системное тестирование, в ходе которого тестируется система в целом;

  • интеграционное тестирование, в ходе которого тестируются группы взаимодействующих модулей и компонент системы;

  • модульное тестирование, в ходе которого тестируются отдельные компоненты.


6 Способы автоматизации процесса верификации

6.1 Системное тестирование.


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

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

Можно выделить два подхода к системному тестированию:


  1. на базе требований (requirements based)

  2. на базе случаев использования (use case based)

6.2 Интеграционное тестирование.


Интеграционное тестирование — фаза тестирования, при котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного и до системного.

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



Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приёмным и требованиям надежности. Тестирование этих проектируемых единиц— объединения, множества или группа модулей— выполняются через их интерфейс, используя тестирование «чёрного ящика».

Автоматизация интеграционного тестирования осуществляется средствами систем непрерывной интеграции. Функции систем непрерывной интеграции (CIS):

  1. CIS производит мониторинг системы контроля версий;

  2. при изменении исходных кодов в репозитории производится обновление локального хранилища;

  3. выполняются необходимые проверки и модульные тесты;

  4. исходные коды компилируются в готовые выполняемые модули;

  5. выполняются тесты интеграционного уровня;

  6. генерируется отчет о тестировании.

На рисунке 6.1 представлена схема реализации интеграционного тестирования. Назначение элементов схемы:

  1. рабочая машина программиста — написание кода,

  2. сервер SVN — хранение кода,

  3. сервер Staging — установка и тестирование собранных проектов,

  4. сервер Selenium — тестирование web-интерфейса,

  5. сервер Repo — хранение собранных пакетов,

  6. сервер CI — соединение всех узлов системы в единое целое.





Рисунок 6.1 - Вариант реализации системы непрерывной интеграции

6.3 Модульное тестирование.


Модульное тестирование (unit-тестирование)— процесс разработки, позволяющий проверить на корректность отдельные модули системы.

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



Сегодня почти для каждого языка существуют библиотеки и инструменты модульного тестирования. Часто возможность модульного тестирования интегрируется с IDE. В приложении А даны скриншоты модульного модульного тестирования в среде Visual Studio 2008.

6.4 Примеры инструментов


В таблице 6.1 дан перечень наиболее известных инструментов автоматизации процесса тестирования.

Таблица 6.1 – Инструменты автоматизации процесса верификации




Название

Технологии

ОС

Язык тестов

Приложение

Вид тестирования

1

Selenium

DHTML, JS, AJAX

MacOS, MS Windows, Linux, Solaris

HTML, Java, C#, Perl, PHP, Python, Ruby

веб-приложения

Функциональное тестирование

2

Testing Anywhere

VB.NET, C#, C++, Win32, VB6, AJAX, ActiveX, JavaScript, HTML, Delphi, Java, Perl, 32 bit apps, 64 bit apps, Oracle Forms, PHP, Python, Macromedia Flash 1.0-8.0, Adobe Flash 9.0 & later

MS Windows

визуальное проектирование

веб- приложения, windows приложения

Универсальный инструмент

3

PHPUnit (+много аналогичных инструментов для других языков — Ruby, C#, Perl, Python, Java и т.д)

PHP

MacOS, MS Windows, Linux, Solaris

PHP

веб-приложения

модульное тестирование

4

Watin

.NET, HTML, JavaScript

MS Windows

C# и др. языки, NET

веб-приложения

Функциональное тестирование

5

Watit

HTML, JavaScript

MS Windows, Linux, Mac OS

Ruby, Java, .NET, Perl

веб-приложени

Функциональное тестирование

6

TOSCA TestSuite

HTML, Java, .NET

MS Windows

VB6, Java, C#

Бизнес-приложения (CRM, SAP)

Универсальный инструмент

7

Hudson

CVS, Subversion, Mercurial, GIT, Apache Tomcat, GlassFish, Apache Ant, Apache Maven, Java, PHP

Linux




Универсальный инструмент, но чаще веб-приложения

Интеграционное тестирование

Приложение А


e:\учеба\ижгту\учеба 5 курс\трпо\скрины модульное тестирование\image_thumb.png

Рисунок А1 – Создание нового тестового проекта

e:\учеба\ижгту\учеба 5 курс\трпо\скрины модульное тестирование\image_thumb_1.png

Рисунок А2 – Пустой тест-метод

e:\учеба\ижгту\учеба 5 курс\трпо\скрины модульное тестирование\image_thumb_2.png

Рисунок А3 – Добавление нового unit-теста

e:\учеба\ижгту\учеба 5 курс\трпо\скрины модульное тестирование\image_thumb_5.png

Рисунок А4 – Окно результатов запуска тестов

e:\учеба\ижгту\учеба 5 курс\трпо\скрины модульное тестирование\image_thumb_6.png

Рисунок А5 – Генерация тестов по существующему коду

e:\учеба\ижгту\учеба 5 курс\трпо\скрины модульное тестирование\image_thumb_7.png

Рисунок А6 – Создание Private Aaccessor

Ижевск 2011


Похожие:

Верификация программных требований к по. Инструменты автоматизации этапа iconОптимизация контроля в программных проектах разработки больших систем
Целью исследования является разработка метода построения оптимального набора контрольных точек для программных комплексов автоматизации...
Верификация программных требований к по. Инструменты автоматизации этапа iconРазработка программных средств автоматизации технических и технологических расчетов в среде Pascal
«Разработка программных средств автоматизации технических и технологических расчетов в среде Pascal»
Верификация программных требований к по. Инструменты автоматизации этапа iconОсобенности стандарта omg corba3, mda и соответствующих программных инструментов интеграции приложений
С ее помощью решаются многие актуальные задачи информатизации и автоматизации современного бизнеса
Верификация программных требований к по. Инструменты автоматизации этапа iconСпецификация программных требований
...
Верификация программных требований к по. Инструменты автоматизации этапа iconМавлеев И. Р., Гончаров М. И
Данный факт и повышение требований к таким эксплуатационным свойствам как комфортабельность автомобиля требуют поиска путей автоматизации...
Верификация программных требований к по. Инструменты автоматизации этапа iconСистема оценки знаний по вступительному испытанию «Сольфеджио» (диктант и устно) для поступающих по специализациям «Оркестровые струнные инструменты», «Оркестровые духовые и ударные инструменты», «Фортепиано»
Для поступающих по специализациям «Оркестровые струнные инструменты», «Оркестровые духовые и ударные инструменты», «Фортепиано»,...
Верификация программных требований к по. Инструменты автоматизации этапа iconРешение задач интеграции программных решений в финансовой индустрии
Таким образом, от простой автоматизации импорта/экспорта до построения обмена сообщениями между десятком программ, задачи интеграции...
Верификация программных требований к по. Инструменты автоматизации этапа iconМетодические рекомендации по разработке заданий и требований к проведению школьного этапа всероссийской олимпиады школьников по астрономии в 2011-2012 учебном году

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

Верификация программных требований к по. Инструменты автоматизации этапа iconВводная лекция Термином вычислительная машина
Термином вычислительная машина будем обозначать комплекс технических и программных средств, предназначенный для автоматизации подготовки...
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org