Инструментальные средства разработки программного обеспечения вопросы к экзамену

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №1

Теоретические вопросы:

1. Дайте определение понятия репозитория проекта. Опишите классы уровней репозиториев.
2. Расскажите об инструментарии анализа качества программных продуктов в среде разработки

Практическое задание:

• Составить программу для вычисления площадь треугольника по формуле Герона

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №2

Теоретические вопросы:

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

Практическое задание:

• Дана последовательность действительных чисел. Выяснить, будет ли она возрастающей.

Преподаватель ________________________ФИО

________________________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №3

Теоретические вопросы:

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

Практическое задание:

• Составить программу для вычисления площадь треугольника по через синус угла и двум прилежащим к нему сторонам.

Преподаватель ________________________ФИО

________________________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №4

Теоретические вопросы:

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

Практическое задание:

•  Найти произведение положительных элементов одномерного массива A размера N.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №5

Теоретические вопросы:

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

Практическое задание:

• Определить время года по номеру месяца. Номер месяца вводить с клавиатуры

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №6

Теоретические вопросы:

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

Практическое задание:

• Составить программу для анализа, введенного пользователем числа (целое или нет; положительное, отрицательное или нуль; четное или нечетное).

Преподаватель ________________________ФИО

________________________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №7

Теоретические вопросы:

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

Практическое задание:

• В переменную последовательно вводятся N вещественных чисел. Вычислить максимальное значение.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №8

Теоретические вопросы:

1. Опишите процесс разработки модульной структуры проекта (диаграммы модулей).
2. Дайте определение понятия «Качество продукции», перечислите показатели качества.

Практическое задание:

• В массив A[N] занесены натуральные числа. Найти сумму тех элементов, которые кратны данному K.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №9

Теоретические вопросы:

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

Практическое задание:

• Составить программу вычисления факториала введенного с клавиатуры числа. // результат вывести в таком виде: fact=1*2*3=6 ( при n =3)

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №10

Теоретические вопросы:

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

Практическое задание:

• Определить максимальный элемент массива А[10] и его порядковый номер.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №11

Теоретические вопросы:

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

Практическое задание:

• Составить программу для вычисления суммы всех натуральных чисел, кратных числу b и меньших 100.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №12

Теоретические вопросы:

1. Сформулируйте понятие и принципы работы с инструментальными средствами разработки ПО.
2. Дайте определение понятий «Отладка», «Локализация Ошибки». Какие виды ошибок существуют? Охарактеризуйте их.

Практическое задание:

• В переменную последовательно вводят числа, отличные от нуля. Окончание ввода — ноль. Определить среднее арифметическое отрицательных чисел.

Преподаватель ________________________ФИО

________________________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №13

Теоретические вопросы:

1. Опишите инструментальные средства создания Windows-приложений.
2. Опишите процесс разработки тестовых модулей проекта для тестирования отдельных модулей.

Практическое задание:

• С клавиатуры вводятся числа. Суммировать числа до тех пор, пока сумма не станет больше 100. Вывести сумму и количество просуммированных чисел.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №14

Теоретические вопросы:

1. Опишите процесс разработка приложений Windows.Forms в среде программирования Microsoft Visual Studio.
2. Перечислите и охарактеризуйте нефункциональные виды тестирования.

Практическое задание:

• Составить программу, которая запрашивает дату (число, месяц, год) и проверяет корректность введенным пользователем данных.

Преподаватель ________________________ФИО

________________________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №15

Теоретические вопросы:

1. Расскажите про инструменты разработки программных средств. Перечислите и охарактеризуйте группы инструментов ПС.
2. Сформулируйте определение понятия тестирование. Опишите методы и средства организации тестирования.

Практическое задание:

• Найти сумму положительных элементов одномерного массива A размера N.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №16

Теоретические вопросы:

1. Перечислите и охарактеризуйте основные классы инструментальных сред разработки и сопровождения ПС.
2. Расскажите о методах проведения тестирования пользовательского интерфейса.

Практическое задание:

• В массиве целых чисел есть нулевые элементы. Создать массив из номеров этих элементов.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №17

Теоретические вопросы:

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

Практическое задание:

•   Написать программу вывода на экран четных чисел из интервала от 0 до100.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №18

Теоретические вопросы:

1. Дайте определение понятию отладки программного средства.
2. Опишите методы и способы идентификации сбоев и ошибок.

Практическое задание:

• Составить программу, которая по номеру дня недели выводит на экран расписание уроков в вашей группе в соответствующий день.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №19

Теоретические вопросы:

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

Практическое задание:

• Написать программу для подсчета суммы чисел, кратных 3 в диапазоне от 30 до 60.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №20

Теоретические вопросы:

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

Практическое задание:

• Составить  программу для нахождения минимального значения среди элементов, стоящих до первого четного элемента.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №21

Теоретические вопросы:

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

Практическое задание:

• Составить программу для поиска произведения положительных элементов массива.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №22

Теоретические вопросы:

1. Перечислите стандарты качества программных средств.  
2. Опишите процесс выявление ошибок системных компонентов.

Практическое задание:

• Написать программу для нахождения в массиве из N элементов количества нулевых элементов.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №23

Теоретические вопросы:

1. Дайте определение понятия «Качество программного обеспечения». Перечислите критерии оценки качества ПО.
2. Перечислите основные средства проектирования интерфейса пользователя и опишите принцип из работы.

Практическое задание:

• Найти количество положительных элементов одномерного массива A размера N.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №24

Теоретические вопросы:

1. Дайте определение свойств качественного программного обеспечения: понятность, осмысленность, завершенность. Поясните их назначение.
2. Дайте определение понятий ручное и автоматизированное тестирование. Расскажите об их преимуществах и недостатках.

Практическое задание:

• Написать программу для определения максимального элемента массива А[20].

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Междисциплинарный курс МДК.02.02. Инструментальные средства разработки программного обеспечения                              

Специальность 09.02.07 Информационные системы и программирование

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ №25

Теоретические вопросы:

1. Перечислите и поясните принципы отладки программного обеспечения.
2. Дайте определение понятий ручное и автоматизированное тестирование. Расскажите об их преимуществах и недостатках.

Практическое задание:

• Определить минимальный элемент массива А[15] и его порядковый номер.

Преподаватель ________________________ФИО

____________________________________________________________________

КРИТЕРИИ ОЦЕНКИ:

• оценка «отлично» выставляется, если студент строит ответ логично, обнаруживает глубокое знание основных понятий и в полной мере раскрывает содержание вопросов. Уверенно отвечает на дополнительные вопросы. При ответе грамотно использует научную лексику. Студент успешно справляется с практическим вопросом;
• оценка «хорошо» выставляется, если студент строит ответ в соответствии с планом, обнаруживает хорошее знание основных понятий и достаточно полно раскрывает содержание вопросов. Ответ содержит ряд несущественных неточностей. Наблюдается некоторая неуверенность или неточность при ответе на дополнительные вопросы. Речь грамотная с использованием научной лексики. Студент успешно справляется с практическим вопросом или допускает незначительные ошибки;
• оценка «удовлетворительно» выставляется, если ответ студента недостаточно логически выстроен. Обнаруживается слабость в развернутом раскрытии содержательных вопросов, хотя основные понятия раскрываются правильно. Наблюдается сильная степень неуверенности при ответе на дополнительные вопросы. Научная лексика используется ограниченно. Студент успешно справляется с практическим вопросом или допускает существенные ошибки;
• оценка «неудовлетворительно» выставляется, если студент оказывается неспособным правильно раскрыть содержание основных понятий. Проявляет стремление подменить научное обоснование проблемы рассуждением бытового плана. Ответ содержит ряд серьезных неточностей. Преобладает бытовая лексика. Студент не способен выполнить практическую часть билета.

Team System Profiler, средства, встроенные в Android Studio. 1

14.Инструмент измерения производительности и поиска утечек памяти valgrind.

15.Инструмент автоматизации тестирования AutoIT.

16.UNIT-тестирование. Инструментальные средства для UNIT-тестирования. Пример.

17.Статический анализ кода. Инструментальные средства статического анализа кода. Примеры. Особенности шести из следующих инструментальных средств: cppcheck, dafny, coverity, kiuwan, LDRA, Malpas, Polyspace, Klockwork, SemmleCode, продукты AdaCore, VeraCode, CodeRush Classic, CODAN в Eclipse, PVS-Studio, Goanna, продукты PRQA, средства IntelliJ IDEA, Astr´ee

18.Инструментльные средства управления требованиями (на примере, выбранном студентом).

19.DOCBOOK. Краткое описание способа использования. Достоинства и недостатки.

20.Технология wiki.

21.Особенности шести из следующих средств/способов подготовки документации: texinfo, docutils, Dr. Explain, wiki, StepShot, Help&Manual,Makrdown, AuthorIT, ClickHelp, FrameMaker, MadCap Flare, Doc-to-Help, Help Generator, StepShot, HelpStudio, FastHelp, Doc-O-Magic, Helpinator, HelpSmith, Softany Software, Daux.io, Latex

22.Инструментальные средства отслеживания ошибок. Назначение. Возможности. Примеры.

23.Инструментальные средства проектирования. Назначение. Возможности. Примеры. Особенности шести из следующих инструментальных средств: Rational Rhapsody, Astah, Papyrus, StarUML, Software Ideas Modeler, UML Designer, Enterprise Architect, Edraw Max, Modelio, Glifty, yEd, BOUML, MagicDraw, PlantUML, LucidChart, Real Time Developer Studio, Umbrello, UMLet, Prosa UML Modeller, Visual Paradigm for UML, Rational Software Architect, UModel, CaseComplete, Rational System Architect, NetBeans, Microsoft Visio.

24.Средства обратной разработки. Назначение. Возможности. Пример.

25.Примеры средств автоматического и автоматизированного программирования.

26.Средство автоматизированного программирования LEX. Назначение. Возможности.

27.Инструментальные средства, используемые на базе практики

28.Выбор инструментальных средств в проекте (на примере)

Практическая часть.

Во всех заданиях практической части предполагается, что вы создаете репозиторий git и заносите в него все исходные файлы, разрабатываемые в рамках выполнения задания. Для программ, написанных на языке C или C++ осуществите статический анализ кода с использованием cppcheck.

1.Осуществите исследование влияния опций компиляции транслятора gcc на программу, осуществляющую вычисление суммы ряда:

√√

1	21 1	2	22 2
		+				+ . . .
	1!			2!

Здесь 1 = 2 = 1, а последовательность в целом – последовательность Фибоначчи. Суммирование следует прекращать тогда, когда слагаемое становится меньше = 0.000000001

Программу следует написать оптимально. 2

3

4

ИСРП | Вопросы с ответами

Вопросы с ответами по дисциплине «Инструментальные средства разработки программ».

1. Программная инженерия:
+ software engineering
— Инструменты создания программного обеспечения
— Коллектив инженеров-программистов, разрабатывающих программное обеспечение для компьютеров
+ Дисциплина, изучающая применение строгого систематического количественного подхода к разработке, эксплуатации и сопровождению программного обеспечения
— Комплекс программ, предназначенный для решения инженерных задач, связанных с большим количеством расчетов
— Инженерная индустрия применения прикладного программного обеспечения
+ Совокупность инженерных методов и средств создания программного обеспечения
— Прикладное программное обеспечение для решения офисных задач

2. Построение SADT-модели включает в себя выполнение следующих действий:
— Написание программного обеспечения для разрабатываемой системы по требованиям заказчика
+ Сбор информации об объекте, определение его границ
+ Определение цели и точки зрения модели, построение, обобщение и декомпозиция диаграмм
— Представление исследуемой системы в графическом виде
— Представление исследуемого объекта средствами системного моделирования
+ Критическая оценка, рецензирование и комментирование
— Разработка, отладка и тестирование программного обеспечения
— Использование графических пакетов для представления системы в виде модели

3. Моделирование основывается на принципах:
+ Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение
— Декомпозиции системы на отдельные подзадачи
— Инкапсуляции и полиморфизма
— Децентрализации управления системой
+ Каждая модель может быть представлена с различной степенью точности; лучшие модели – те, что ближе к реальности
— Открытой трансформируемой системы
+ Нельзя ограничиваться созданием только одной модели. Наилучший подход при разработке любой нетривиальной системы – использовать совокупность нескольких моделей, почти независимых друг от друга
— Анализа и синтеза проектирования систем

4. В бизнес-процессах выделяют классы процессов:
— Решающие бизнес-процессы
— Регламентирующие бизнес-процессы
+ Основные бизнес-процессы
— Бизнес-процессы поведения системы
— Программируемые бизнес-процессы
— Экономические бизнес-процессы
+ Обеспечивающие бизнес-процессы
+ Бизнес-процессы управления

5. CASE-средства классифицируются по следующим признакам:
+ По применяемым методологиям и моделям систем и БД
— По используемому программному обеспечению
— По этапам жизненного цикла программного обеспечения
+ По степени интегрированности с СУБД
— По уровням детализации и декомпозиции проектируемой системы
+ По доступным платформам
— По используемым языкам программирования
— По степени сложности моделируемой системы

6. К малым интегрированным средствам моделирования относятся:
— ARIS Toolset
— Design/IDEF
+ ERwin
+ BPwin
— Designer/2000
— Paradigm Plus
+ Model Mart
— Rational Rose

7. К средним интегрированным средствам моделирования относятся:
— Rational Rose
+ Design/IDEF
— BPwin
+ Designer/2000
+ ARIS Toolset
— Model Mart
— Paradigm Plus
— ERwin

8. Объектно-ориентированная методология (ООМ) включает в себя составные части:
+ Объектно-ориентированный анализ
— Объектно-ориентированный подкласс
+ Объектно-ориентированное проектирование
— Объектно-ориентированная парадигма
— Объектно-ориентированная экспозиция
— Объектно-ориентированное моделирование
+ Объектно-ориентированное программирование
— Объектно-ориентированная декомпозиция

9. К основным понятиям объектно-ориентированного подхода относятся:
— Обобщение
+ Полиморфизм
+ Инкапсуляция
— Реализация
— Агрегирование
+ Наследование
— Ассоциация
— Композиция

10. Главные принципы объектного подхода:
+ Абстрагирование
— Наследование
+ Ограничение доступа или инкапсуляция
— Безграничный доступ или инкапсуляция
+ Модульность и иерархия
— Агрегирование
— Композиция
— Обобщение и специализация

11. Дополнительные принципы объектного подхода:
— Реализация
+ Типизация
+ Параллелизм
— Внедрение
— Перпендикулярность
+ Сохраняемость или устойчивость
— Несохраняемость или неустойчивость
— Динамичность

12. К инструментальным средствам объектно-ориентированного анализа и проектирования относятся:
+ Rational Rose
— Model Mart
+ MS Visio
+ ARIS
— IDEF1X
— Erwin
— BPwin
— JAM

13. К инструментальным средствам представления функциональных моделей относятся:
— JAM
+ Model Mart
— MS Visio
— ARIS
— IDEF0
+ Erwin
+ BPwin
— Rational Rose

14. Методологии, поддерживаемые в BPwin:
— IDEF1Х
+ IDEF0
— IDEF1
+ IDEF3
— IDEFХ
— IDEF5
+ DFD
— DFD1Х

15. Диаграмма IDEF0 может содержать следующие типы диаграмм:
— Диаграмму классов
+ Контекстную диаграмму, диаграмму декомпозиции
— Диаграмму компонентов
+ Диаграмму дерева узлов
— Диаграмму взаимодействий
+ Диаграмму только для экспозиции (FEO)
— Диаграмму последовательности, диаграмму кооперации
— Диаграмму узлов

16. Уровни логической модели:
— Диаграмма сущность
— Диаграмма связь
— Диаграмма пакетов
+ Диаграмма сущность-связь
— Модель данных, основанная на классах
+ Модель данных, основанная на ключах
— Полная операционная модель
+ Полная атрибутивная модель

17. Внутренние стрелки не входящие в состав диаграммы IDEF0:
+ mechanism- output
— output-input
+ mechanism- input
— output-control
— output-input feedback
— output-control feedback
— output-mechanism
+ control feedback- mechanism

18. Типы стрелок не входящие в состав диаграммы IDEF0:
— Input
+ Editor
— Control
+ Properties
— Output
— Mechanism
— Call
+ Dictionary

19. Quick Reports – создание простейших отчетов – позволяет создавать отчеты:
— Group/Totals. Табличный отчет с автоматической группировкой и сортировкой данных
— Report Header. Печатается единожды в начале отчета
+ Columnar. Простой табличный отчет
— Page Header. Печатается в верхней части каждой страницы
+ Vertical. Простой вертикальный отчет
— Group Header. Печатается в начале каждой группы
+ Blank Report. Бланк. Создается пустой бланк отчета, в который не включаются данные
— Detail. Печатается для каждой строчки набора данных

20. BPwin допускает следующие переходы с одной нотации на другую:
— IDEF3 → DFD
— DFD → IDEF0
+ IDEF0 → DFD
— DFD → DFD
— IDEF3 → IDEF0
+ IDEF0 → IDEF3
— IDEF3 → IDEF3
+ DFD → IDEF3

21. DFD описывает:
— Функции обработки стрелок (arrow)
+ Функции обработки информации (работы)
— Внешние ссылки (external references), объекты, сотрудников или отделы, которые участвуют в обработке информации
+ Документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации
— Функции обработки внешних ссылок
+ Внешние ссылки (external references), таблицы для хранения документов (хранилище данных, data stor+ E)
— Функции обработки документов
— Документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке внешних стрелок

22. BPwin позволяет создавать на диаграмме DFD типы граничных стрелок:
+ Обычная граничная стрелка
— Специальная стрелка
— Внутренняя ссылка
+ Межстраничная ссылка и тоннельная стрелка
+ Внешняя ссылка
— Страничная ссылка и теневая стрелка
— Контрольная стрелка
— Стрелка механизм

23. Создать отчет в BPwin возможно с помощью:
+ Встроенных шаблонов
— Программных модулей, создаваемых разработчиком на языке Visual Basic
— Создать отчет в BPwin не возможно
+ Report Template Builder
— Отчет создается разработчиком
— Отдельно поставляемых программ
— Встроенных мастер-функций
+ RPTwin

24. В BPwin 4.0 отчеты могут быть экспортированы в распространенные форматы:
+ Текстовый
— Символьный
+ MS Office
— Графический
+ HTML
— Internet Explorer
— Acrobat
— IBM Rational

25. Поддерживаемые в RPTwin типы операторов:
+ Текстовый оператор конкатенации (&)
— Символ
— Текст
— Дата
+ Арифметические
— Графический оператор конкатенации (&)
+ Логические
— Номер

26. Инструментальное средство ERwin позволяет:
— Редактировать и отлаживать программы
+ Проектировать на физическом и логическом уровне модели данных
— Управлять процессом конструирования ПО
— Проектировать диаграммы вариантов использования и взаимодействий
+ Проводить процессы прямого и обратного проектирования баз данных
— Управлять процессом трансляции и отладки программ
+ Выравнивать модель и содержимое системного каталога после редактирования
— Проектировать контекстные диаграммы и диаграммы декомпозиции

27. ERwin позволяет создавать модели следующих типов:
+ Модель, имеющую только логический уровень
— Модель, имеющую абстрактный уровень
— Модель, имеющую абстрактный и физический уровни
+ Модель, имеющую только физический уровень
— Модель, имеющую абстрактный и логический уровни
+ Модель, имеющую как логический уровень, так и физический уровень
— Модель, имеющую концептуальный уровень
— Модель, имеющую контекстный уровень

28. Для создания моделей ERwin используют международно признанные системы обозначений (нотации):
— IDEF0
+ IDEF1X
— IDEF3
— DFD
+ IE
+ DM
— IDEFDFD
— IDEF3

29. К основным компонентам диаграммы ERwin относятся:
+ Сущности
— Переходы
+ Атрибуты
— Классы
— Слияния
— Разветвления
— Использования
+ Связи

30. Точки зрения организации в ARIS:
— Структура внедрения и структура потоков
+ Организационная структура
— Управленческая структура
— Поведенческая структура
+ Функциональная структура
— Коммуникационная структура
+ Структура данных и структура процессов
— Обобщенная структура

31. Уровни точки зрения в ARIS:
— Описание структуры
+ Описание требований
— Описание поведения
— Описание разарботки
+ Описание спецификации
+ Описание внедрения
— Описание процессов
— Описание классов

32. Методы описания, используемые в ARIS:
— ЕРТ – метод описания потоков
+ EPC — метод описания процессов
— ERM — модель сущность-связь для описания структуры объектов
+ ERM — модель сущность-связь для описания структуры данных
— ЕРР – метод описания пакетов
— ЕРС – метод описания компонентов
+ UML — унифицированный язык моделирования
— ЕРТ – метод описания нитей

33. К основным компонентам инструментов ARIS Toolset относятся:
— Internet (интернет)
— WordPad (ввод текстовых данных)
— Media (средство для медиа описания моделей)
+ Explorer (проводник)
— Acrobat (чтение текстовых данных)
+ Designer (средство для графического описания моделей)
— Document (для ввода различных параметров и атрибутов) и выноски
+ Таблица (для ввода различных параметров и атрибутов) и мастер (Wizards)

34. ARIS Business Optimizer позволяет:
+ Определять целевые затраты и рассчитывать стоимость продукта: во что компании обходится предоставление отдельных продуктов
— Принимать решения о времени начала и окончания работы над проектом
+ Принимать решения по аутсорсингу: стоит ли поручить выполнение бизнес-процессов внешнему поставщику услуг
— Определять последовательность работ , выполняемых в ходе работы над проектом
— Определять требования к персоналу компании, которая в дальнейшем будет эксплуатировать программное обеспечение
— Рассчитывать заработную плату сотрудников компании после внедрения программного обеспечения
— Планировать требования к обслуживающему персоналу, сопровождающему программное обеспечение
+ Планировать требования к персоналу: сколько необходимо сотрудников для оптимального выполнения работ

35. «Взгляды» ARIS:
+ Процессы
— Потоки
+ Функции (с целями)
+ Данные и организация
— Процедуры
— Управление и внедрение
— Нити
— Память

36. Уровни анализа ARIS для каждого «взгляда»:
— Поведение
+ Требования
+ Спецификации
— Функции
— Процедуры
— Проверка
+ Внедрение
— Тестирование

37. MS Visio позволяет создавать схемы, чертежи, диаграммы с помощью:
+ Встроенных шаблонов
— Панели инструментов
+ Трафаретов
— Графических редакторов
— Дополнительного программного обеспечения
— Панели рисования
+ Стандартных модулей
— Панели автофигур

38. Язык UML – это:
— Язык программирования высокого уровня
+ Унифицированный язык моделирования
— Язык для разработки систем искусственного интеллекта
+ Unified Modeling Language
— Язык управления базами данных
+ Язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем
— Язык создания запросов в базах данных
— Язык программирования низкого уровня

39. Моделирование в UML позволяет решать задачи:
— Анализа и синтеза систем управления
— Разработать и отладить программное обеспечение
+ Визуализировать систему в ее текущем или желательном для нас состоянии
— Провести тестирование разработанного программного обеспечения
+ Описать структуру или поведение системы; получить шаблон, позволяющий сконструировать систему
— Смоделировать разрабатываемую информационную систему
+ Документировать принимаемые решения, используя полученные модели
— Рассчитать экономическую эффективность от внедрания программного обеспечения

40. Словарь UML включает строительные блоки:
— Зависимости
+ Сущности
— Слияния
— Разветвления
+ Связи
— Группировки
+ Диаграммы
— Декомпозиции

41. UML, как язык документирования, помимо исполняемого кода производит и другие продукты, включающие:
+ Требования, архитектуру, проектные решения
— Спецификацию технических средств
+ Дизайн, исходный код, проектные планы,
— Требования к уровню квалификации разработчиков
— Набор заданий для тестирования программного обеспечения
— Требования к уровню квалификации персонала сопровождения
+ Тесты, прототипы, релизы (версии)
— Требования к выбору языка программирования

42. UML включает синтаксические и семантические правила для:
— Агрегации
— Тестирования
+ Имен, областей действия
— Сборки
— Сопровождения
+ Видимости, целостности
— Вывода из эксплуатации
+ Исполнения

43. Применение языка UML существенно упрощает последовательное использование механизмов:
+ Спецификации, дополнения
+ Принятые разделения
— Выработки требований
— Создания плана работ
+ Механизмы расширения
— Тестирования программного обеспечения
— Конструирования ПО
— Сопровождения ПО

44. Механизмы расширения UML включают:
— Исключения
+ Стереотипы
— Дополнения
— Управления
+ Помеченные значения
— Слияния
+ Ограничения
— Объединения

45. Язык UML предназначен для:
+ Визуализации
— Тестирования
— Сопровождения
+ Специфицирования
— Снятия с эксплуатации
+ Конструирования, документирования
— Анализа требований
— Обучения персонала

46. В объектно-ориентированном моделировании между классами существуют типы связей:
— Слияние
— Линейность
+ Зависимость
— Разветвление
— Цикличность
+ Обобщение
+ Ассоциация
— Агрегация

47. В состав графического представления класса в языке UML входят части:
— Отношения
+ Имя
— Связи
+ Атрибуты
— Описание
— Сущности
+ Операции
— Механизмы

48. Программное обеспечение делится на классы:
— Системное ПО и прикладное ПО
+ Системное ПО, прикладное ПО и инструментальные средства разработки программ
— Операционные системы, прикладное ПО, утилиты и драйверы
— Прикладное ПО и инструментальные средства разработки программ
— Системное ПО и инструментальные средства разработки программ
+ Системное ПО, прикладное ПО и системы программирования
— Операционные оболочки, операционные системы, офисные программы
+ Системное ПО, прикладное ПО и инструментальное ПО

49. Инструментальные средства разработки программ – это:
+ Средства создания новых программ
— Сервисные средства разработки ПО
— Аналитические средства разработки ПО
+ Программное обеспечение, предназначенное для разработки и отладки новых программ
— Средства отладки ПО
— Средства тестирования ПО
+ Аппаратные и программные инструменты разработки нового ПО
— Технические инструментальные средства разработки ПО

50. Аппаратные инструментальные средства разработки ПО – это:
— Система для разработки новых программ на конкретном языке программирования
— Средства создания и редактирования текстов программ
+ Микропроцессор и подключаемые (внешние) устройства
+ Устройства вычислительной системы, специально предназначенные для поддержки разработки ПО
+ Периферийные устройства, микропроцессор вычислительного комплекса, предназначенные для разработки нового ПО
— Программное обеспечение, написанное на языках программирования низкого уровня
— Программы, которые используются в ходе разработки, корректировки или развития других прикладных или системных программ
— Программы, используемые для корректировки и тестирования других прикладных или системных программ

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

52. Транслятор – это:
+ Программа, выполняющая перевод программы с одного языка программирования на другой
— Комплекс программ мультимедийных технологий
+ Программа, которая выполняет перевод программы с одного языка программирования на машинные коды
— Программа-переводчик с одного иностранного языка на другой
— Техническое устройство передачи и преобразования аудио и видеосигналов
— Техническое устройство для кодирования и декодирования информации
— Программное обеспечение для обеспечения защиты информации на компьютере
+ Одно из основных средств автоматизации программирования для преобразования программы, написанный на машинно-независимом языке, в программу на машинном языке конкретной ЭВМ

53. Компилятор – это:
+ Один из видов трансляторов
— Прикладное программное обеспечение
— Специальная утилита системного ПО
— Операционная оболочка
+ Переводит в коды сразу всю программу и создает независимый исполняемый файл
— Программное обеспечение, используемое в издательских системах
+ Программа, которая переводит программу, написанную на языке программирования высокого уровня в программу на машинном языке не участвуя в ее исполнении
— Переводит в машинные коды 1 строчку программы и сразу ее выполняет

54. Интерпретатор:
— Программа для создания и редактирования электронных таблиц
+ Программа, анализирующая команды или операторы исходной программы и немедленно выполняющая их
— Переводит в коды сразу всю программу и создает независимый исполняемый файл
+ Переводит в машинные коды 1 строчку программы и сразу ее выполняет
— Программа для создания и редактирования текстовых документов
+ Один из видов трансляторов
— Программа создания и управления базами данных
— Программа создания файлов мультимедиа

55. Компоновщик – это:
— Программа для компоновки и оформления тестовых документов
+ Редактор связей
— Комплекс программ, для создания и ведения баз данных
+ Программа, которая из одного или нескольких объектных модулей с привлечением библиотечных программ и стандартных подпрограмм формирует загрузочный модуль
— Программное обеспечение для создания презентаций
+ Программа сборки загрузочного модуля из полученных в результате раздельной компиляции объектных модулей с автоматическим поиском и присоединением библиотечных подпрограмм и процедур
— Программа для поиска синтаксических и семантических ошибок в программе
— Программа

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

57. К этапам развития технологии разработки программного обеспечения относятся:
+ «Процедурное» программирование
— Программирование на алгоритмических языках высокого уровня
+ Структурный подход к программированию
— Программирование на языках низкого уровня
+ Компонентный подход и CASE-технологии
— Машинно-ориентированное программирование
— Машинно-независимое программирование
— Подход к разработке ПО, основанный на стратегии поиска

58. «Стихийное» программирование:
— Разработка программного обеспечения без предварительного составления плана-графики работ
+ Первый этап в истории развития технологии разработки программного обеспечения, когда программирование фактически было искусством
+ Период в истории разработки программного обеспечения, когда программа создавалась одним программистом, способным отслеживать последовательность выполняемых операций и местонахождения данных в программе
— Разработка программ с использованием различных языков программирования низкого и высокого уровня
— Разработка программ с элементами случайного выбора алгоритмов решения задачи
+ Характеризуется тем, что типичная программа этого периода состояла из основной программы, области глобальных данных и набора подпрограмм (в основном библиотечных), выполняющих обработку всех данных или их части
— Разработка программного обеспечения для решения задач теории вероятностей и математической статистики
— Разработка программного обеспечения для решения задач, построенных на алгоритмах случайного поиска

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

60. Объектный подход к программированию – это:
— Технология создания сложного программного обеспечения, основанная на представлении задачи исследования как объекта
— Технология создания сложного программного обеспечения, предназначенного для автоматизации технологических объектов
+ Технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств
— Технология создания сложного программного обеспечения, основанная на представлении программы как единого объекта
+ Технология создания сложного программного обеспечения, позволяющая вести практически независимую разработку отдельных частей (объектов) программы
— Технология создания сложного программного обеспечения, основанная на объектном представлении кода программы
+ Технология создания сложного программного обеспечения, в основе которой лежат новые способы организации программ, основанные на механизмах наследования, полиморфизма, композиции, наполнения
— Технология создания сложного программного обеспечения, основанная на
объектно-ориентированном программировании

61. Компонентный подход:
+ Предполагает построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения
+ Предполагает взаимодействие между компонентами через стандартизованные двоичные интерфейсы и позволяет использовать исполняемые файлы в любом языке программирования, поддерживающем соответствующую технологию
— Позволяет рассматривать объект исследования, как структуру, состоящую из отдельных компонент
— способ написания исходного кода программного обеспечения
+ Позволяет собрать объекты-компоненты в динамически вызываемые библиотеки или исполняемые файлы, и распространять в двоичном виде (без исходных текстов)
— Способ отладки и тестирования программного обеспечения
— Способ внедрения и опытной эксплуатации программного обеспечения.
— Метод выработки требований к разработке программного обеспечения

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

63. К методам выявления требований относятся:
— Беседы с первыми руководителями предприятия, для которого разрабатывается программное обеспечение
— Анализ научной и технической литературы, посвященной вопросам разработки программного обеспечения
— Личные встречи и беседы со всеми сотрудниками предприятия
— Анализ технической документации и на основе нее разработка требований к системе
— На начальном этапе требования не выявляются, а формируются по мере разработки программного обеспечения
+ Интервьюирование и анкетирование, мозговой штурм и отбор идей
+ Совещания, посвященные требованиям, создание прототипов
+ Раскадровки, прецеденты, обыгрывание ролей

64. Требования к разрабатываемой системе должны включать:
— Разработку программного обеспечения и выработка требований к изменению работы системы заказчика
+ Совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение)
— Построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения
+ Описание выполняемых системой функций
— Технологию создания сложного программного обеспечения, основанную а объектном представлении кода программы
+ Ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации)
— Совокупность рекомендуемых технологических приемов, охватывающих выполнение всех этапов разработки программного обеспечения
— Технологию разработки программного обеспечения на базе структурной
схемы развития языков программирования

65. Типы средств, иллюстрирующие цели моделирования системы:
+ Функции, которые система должна выполнять
+ Отношения между данными
+ Зависящее от времени поведение системы (аспекты реального времени)
— Способы отладки и тестирования программного обеспечения
— Создание программного обеспечения на основе структурной схемы исследуемого объекта или процесса
— Выявление требований заказчика и управление ими
— Технология разработки программного обеспечения на базе структурной схемы развития языков программирования
— Построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения

66. Преимущества объектно-ориентированного подхода:
— Быстрота написания программного кода
— Статичность конфигурации системы
+ Возможность многократного использования
— Низкая стоимость проекта
+ Восприимчивость к изменениям
— Отсутствие необходимости документирования
— Простота реализуемых моделей
+ Реалистичное моделирование

67. Требования – это:
— Документ, регулирующий отношения между заказчиком информационной системы и проектировщиком
+ Некоторое свойство программного обеспечения, необходимое пользователю для решения проблемы при достижении поставленной цели
— Оформленное заказчиком в виде документа задание на проектирование программного обеспечения
+ Возможность, которую должна обеспечивать система
— Характеристика проектируемого программного обеспечения с точки зрения разработчика
+ Некоторое свойство программного обеспечения, которым должна обладать система или ее компонент, чтобы удовлетворить требования формальной документации
— Оформленное разработчиком в виде документа задание на проектирование программного обеспечения
— Характеристика проектируемого программного обеспечения с точки
зрения заказчика

68. Типичная схема процесса анализа С-требований включает в себя:
+ Идентификацию заказчика и проведение интервью с представителями заказчика
— Разработку программного обеспечения в соответствии с требованиями заказчика
— Изложение заказчику требований к системе на основе разработанного программного обеспечения
+ Написание С-Требований в форме стандартного документа
— Верификацию разработанного программного обеспечения в соответствии с требованиями заказчика
— Составление плана мероприятий по анализу С-требований
+ Проверку С-Требований и согласование их с заказчиком
— Адаптацию разработанного программного обеспечения в соответствии с
требованиями заказчика

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

70. Процесс определения и анализа требований включает в себя:
— Анализ работы систем с аналогичной предметной областью
+ Анализ предметной области, сбор и классификацию требований
— Проведение совместных совещаний с представителями заказчика
+ Разрешение противоречий и определение приоритетов
— Адаптацию требований к разрабатываемому программному обеспечению
— Декомпозицию общей задачи на подзадачи
+ Проверку, специфицирование и документирование требований
— Верификацию требований в соответствии с разработанным программным
обеспечением

71. Опорные точки зрения конечных пользователей системы программного обеспечения можно трактовать как:
+ Источник информации о системных данных
— Структуру требований
— Источник событий
— Структуру событий
+ Структуру представлений
— Получателей требований
— Источник сценариев
+ Получателей системных сервисов

72. При аттестации требований выполняются следующие типы проверок документации требований:
— Проверка на совместимость
— Проверка на управляемость
+ Проверка правильности требований
+ Проверка на непротиворечивость
— Проверка на соответствие
— Проверка на обратимость
+ Проверка на полноту и на выполнимость
— Проверка на заменяемость

73. К методам аттестации требований относится:
— Тестирование
+ Обзор требований
— Верификация
— Сравнительный анализ
+ Прототипирование
— Генерация случайных данных
+ Генерация тестовых сценариев
— Декомпозиция

74. Уровни организационного управления при планировании разработки системы:
+ Стратегический
+ Тактический
+ Оперативный
— Основной
— Вспомогательный
— Дополнительный
— Системный
— Аналитический

75. Для различных представлений проектируемой системы используют типы моделей:
— Статическая модель
— Динамическая модель
+ Модель классов
— Модель декомпозиции
— Модель размещения
+ Модель состояний
+ Модель взаимодействия
— Модель агрегации

76. Классификация бизнес-процессов включает следующие классы процессов:
— Вспомогательные бизнес-процессы
+ Основные бизнес-процессы
— Дополнительные бизнес-процессы
+ Обеспечивающие бизнес-процессы
— Обслуживающие бизнес-процессы
— Бизнес-процессы согласования
+ Бизнес-процессы управления
— Руководящие бизнес-процессы

77. Типы D-требований:
+ Функциональные требования
— Интерфейсные требования
+ Нефункциональные требования
— Программные требования
+ Обратные требования
— Ограниченные требования
— Производительные требования
— Надежность

78. Возможные способы организации D-требований:
— По атрибутам, по компонентам
— По взаимоотношениям сущности
— По пакетам и по иерархии компонентов
+ По свойствам, по классам
+ По вариантам использования
— По узлам и по использованным процессам
+ По состояниям и по иерархии функции
— По прецедентам, по кооперациям

79. К моделированию относится:
+ Система обозначений
— Система атрибутов
+ Синтаксис языка моделирования
— Система свойств
— Совокупность поведении обьектов
+ Совокупность графических объектов
— Семантика языка моделирования
— Совокупность текстовых объектов

80. Классификация имитационных моделей:
— Статистическая
— Адаптивная
+ Статическая или динамическая
— Структурная
+ Сетерминированная или стохастическая
+ Непрерывная или дискретная
— Объединенная
— Декомпозиционная

81. Принципы разработки эффективного пользовательского интерфейса:
— Сложность, графика
+ Структура, простота
— Связь, обработка
+ Видимость, обратная связь
— Невидимость, сложность
+ Толерантность, повторное использование
— Первое использование, итерация
— Интеграция, повторение

82. Принципы разработки программного обеспечения:
— Коллективный процесс разработки
+ Индивидуальный процесс разработки
— Параллельный процесс разработки
+ Командный процесс разработки
— Промежуточный процесс разработки
+ Модель зрелости возможностей
— Модель законченности возможностей
— Модель готовности процессов

83. Типы интерфейсных требований:
+ Пользовательские требования
+ Аппаратные требования
— Административные требования
— Требования к производительности
+ Программные и коммуникационные требования
— Требования к надежности
— Требования к устойчивости
— Атрибуты программной системы и другие требования

84. Технология проектирования определяется как совокупность составляющих:
— Поэтапная процедура
+ Пошаговая процедура
— Модели и правила
+ Критерий и правила
— Тестирование
+ Нотаций
— Прецеденты
— Классы

85. Разработка и сопровождение ИС в конкретной организации и конкретном проекте должна поддерживаться стандартами:
— Стандарт организации
— Стандарт конкретного проекта
+ Стандарт проектирования
— Стандарт оценки
+ Стандарт оформления проектной документации
— Стандарт аудита
— Стандарт оформления разработки
+ Стандарт пользовательского интерфейса

86. Результатами проектирования архитектуры являются:
— Модель административного интерфейса
+ Модель процессов
— Модель потоков
— Модель классов
+ Модель данных
+ Модель пользовательского интерфейса
— Модель компонентов
— Модель узлов

87. Какие работы включает процесс разработки программного обеспечения:
— Документирование, управление конфигурацией
— Управление, создание инфраструктуры
— Структура из процессов, работ, задач
— Обеспечение качества, верификация
+ Анализ требований, проектирование
+ Программирование, сборка, тестирование
+ Ввод в действие, приемка
— Совместный анализ, аудит

88. Какие технологии разработки программ используются в современном программировании:
+ Визуальные
+ Событийные
— Структурные
+ Объектно-ориентированные
— Модульные
— Текстуальные
— Графические
— Машинно-ориентированное

89. Объектно-ориентированное проектирование использует инструментальные средства:
— Model mart
+ Rational Rose
— Bpwin
+ ARIS
— Idef1X
— Erwin
+ MS Visio
— Jam

90. Проектирование функциональных моделей поддерживается инструментальными средствами:
— Jam
+ Model Mart
— MS visio
+ ERwin
— Idef0
— Aris
— Rational rose
+ BPwin

91. IEEE – это:
— Коммерческая организация ученых и исследователей
— Просто принятое обозначение, расшифровки не имеет
— Обозначение всемирной компьютерной сети
+ Всемирная некоммерческая техническая профессиональная ассоциация ученых и исследователей
— Такая аббревиатура нигде не используется
+ Institute Of Electrical and Electronic Engineers, Inc
— Американская организация ученых-экономистов
+ Институт инженеров радиоэлектроники и электротехники

92. Ядро знаний SWEBOK – это:
— ГОСТ на разработку программного обеспечения
+ Нормативный документ, разработанный IEEE
— ГОСТ на разработку информационных систем
— Документ, устанавливающий правовые отношения между заказчиком и разработчиком программного обеспечения
+ Основополагающий научно-технический документ, который отображает мнение специалистов в области программной инженерии
— Документ, устанавливающий методику тестирования и испытания программного обеспечения
+ Документ, который согласуется с современными регламентированными процессами жизненного цикла ПО стандарта ISO/IEC 12207
— ГОСТ на разработку и комплектацию сопровождающей документации

93. Каждая область ядра знаний SWEBOK представляется:
— Структурной схемой
+ Общей схемой описания
— Диаграммой UML
— Описанием и комментариями
+ Определением понятийного аппарата, методов и средств инженерной деятельности
— Определением языка программирования
+ Определением инструментов поддержки инженерной деятельности
— Иерархической диаграммой

94. К основным областям знаний SWEBOK относятся:
+ Инженерия требований, проектирование ПО
— Анализ деятельности системы
— Управление проектами
+ Конструирование ПО
— Управление персоналом
+ Тестирование ПО, сопровождение ПО
— Управление конфигурацией
— Инженерия качества программных средств

95. К организационным областям знаний SWEBOK относятся:
— Инженерия требований
+ Управление конфигурацией, управление проектами
— Конструирование ПО
+ Процесс инженерии программных средств, методы и средства программной инженерии
— Проектирование ПО
— Сопровождение ПО
— Тестирование ПО
+ Инженерия качества программных средств

96. В рамках Rational Unified Process (RUP) набор действий по разработке программ включает этапы:
— Создание структурных схем
— Определения входных, выходных данных
— Согласование стоимости проекта
— Согласования требований с заказчиком
— Создания бизнес-моделей
+ Определение требований
+ Проектирование, программирование
+ Тестирование, внедрение

97. Этапы разработки консалтинговых проектов включают в себя:
+ Анализ первичных требований и планирование работ
— Снятие программного продукта с эксплуатации
— Декомпозицию задачи на подзадачи
— Разработку спецификации и документации
+ Проведение обследования деятельности предприятия
— Тестирование и сопровождение программного обеспечения
+ Построение моделей деятельности предприятия (модели AS – IS – “как есть” и модели TO – BE – “как должно быть”)
— Разработку программного обеспечения

98. Концепции, лежащие в основе модульного программирования:
— Объем реализации и время исполнения (реакции)
— Мера автоматизма в работе реализации и инструментах разработки
— Визуальность и тестируемость разработки
+ Функциональная декомпозиция, пространственная и временная группировка информации (модульность)
+ Упрощение связей
+ Комментируемость функций и данных
— Надежность, устойчивость
— Безопасность

99. Инструмент разработки программ выбирается на основе:
— Визуальности, набора реализуемых технологий
— Мощности множества элементов разработки
— Системного подхода к анализу, проектированию и реализации ПО
— Функциональной декомпозиции, пространственной и временной группировка информации (модульность)
— Упрощения связей, комментируемости функций и данных
+ Объема реализации и времени исполнения (реакции), надежности, устойчивости, безопасности
+ Меры автоматизма в работе реализации и инструментах разработки
+ Визуальности и тестируемости разработки

Комментарии:

Предложите, как улучшить StudyLib

(Для жалоб на нарушения авторских прав, используйте

другую форму
)

ДЕПАРТАМЕНТ ОБРАЗОВАНИЯ И НАУКИ ПРИМОРСКОГО КРАЯ

КРАЕВОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ «НАХОДКИНСКИЙ ГОСУДАРСТВЕННЫЙ ГУМАНИТАРНО-ПОЛИТЕХНИЧЕСКИЙ КОЛЛЕДЖ»

МЕТОДИЧЕСКАЯ РАЗРАБОТКА

УЧЕБНО – МЕТОДИЧЕСКИЙ КОМПЛЕКС МДК 03.02 Инструментальные средства разработки программного обеспечения

ДЛЯ СПЕЦИАЛЬНОСТИ 09.0.03 Программирование в компьютерных системах

Находка

2018

Учебно-методический комплекс по МДК 03.02 Инструментальные средства разработки программного обеспечения составлен в соответствии с требованиями к минимуму результатов освоения дисциплины, изложенными в Федеральном государственном стандарте среднего профессионального образования по специальности 09.0.03 Программирование в компьютерных системах, утвержденном приказом Министерства образования и науки РФ.

Учебно-методический комплекс по МДК 03.02 Инструментальные средства разработки программного обеспечения (далее МДК 03.02) входит в профессиональный цикл и является частью программы подготовки специалистов среднего звена КГБ ПОУ «НГГПК» по специальности 09.02.03 Программирование в компьютерных система.

Учебно-методический комплекс по МДК 03.02 Инструментальные средства разработки программного обеспечения адресован студентам очной формы обучения.

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

Разработчик: преподаватель первой категории Ким Е.Л

Председатель ПЦК Нагина Т.А

СОДЕРЖАНИЕ

Наименование разделов	стр.
1. Введение	6
2. Образовательный маршрут	8
3. Содержание дисциплины Раздел 3. Проектирование программного обеспечения с использованием специализированных программных пакетов Тема 3.1 Проектирование процесса разработки программного продукта Тема 3.2 Использование основных методологий процессов разработки ПО Тема 3.3 Инструментальные средства отладки и тестирования
4. Контроль и оценка результатов освоения учебной дисциплины	49
5 Глоссарий	50
6. Информационное обеспечение дисциплины	55

Уважаемый студент!

Учебно-методический комплекс по МДК 03.02 Инструментальные средства разработки программного обеспечения создан Вам в помощь для работы на занятиях, при выполнении домашнего задания и подготовки к текущему и итоговому контролю по дисциплине.

УМК по МДК 03.02 Инструментальные средства разработки программного обеспечения включает теоретический блок, перечень практических занятий и лабораторных работ, задания для самостоятельного изучения тем дисциплины, вопросы для самоконтроля, перечень точек рубежного контроля.

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

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

Основные понятия, используемые при изучении содержания МДК, приведены в глоссарии.

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

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

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

По итогам изучения МДК 03.02 Инструментальные средства разработки программного обеспечения проводится экзамен

Экзамен: В зачетную книжку выставляется оценка полученная на экзамене. Допуск у экзамену выставляется на основании оценок за практические и лабораторные работы и точки рубежного контроля.

В результате освоения МДК Вы должны уметь:

• владеть основными методологиями процессов разработки программного обеспечения;

• использовать методы для получения кода с заданной функциональностью и степенью качества.

В результате освоения МДК Вы должны знать:

• модели процесса разработки программного обеспечения;

• основные принципы процесса разработки программного обеспечения;

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

• основные методы и средства эффективной разработки;

• концепции и реализации программных процессов;

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

• методы организации работы в коллективах разработчиков программного обеспечения;

• стандарты качества программного обеспечения;

• методы и средства разработки программной документации

В результате освоения дисциплины у Вас должны формироваться общие компетенции (ОК):

Название ОК	Результат, который Вы должны получить после изучения содержания дисциплины
ОК 1. Понимать сущность и социальную значимость своей будущей профессии, проявлять к ней устойчивый интерес.	демонстрация интереса к будущей профессии
ОК 2. Организовывать собственную деятельность, выбирать типовые методы и способы выполнения профессиональных задач, оценивать их эффективность и качество.	выбор и применение методов и способов решения профессиональных задач оценка эффективности и качества выполнения
ОК 3. Принимать решения в стандартных и нестандартных ситуациях и нести за них ответственность.	решение стандартных и нестандартных профессиональных задач в области разработки программных модулей
ОК 4. Осуществлять поиск и использование информации, необходимой для эффективного выполнения профессиональных задач, профессионального и личностного развития.	эффективный поиск необходимой информации; использование различных источников, включая электронные
ОК 5. Использовать информационно-коммуникационные технологии в профессиональной деятельности.	разрабатывать, программировать программные модули
ОК 6. Работать в коллективе и в команде, эффективно общаться с коллегами, руководством, потребителями.	взаимодействие с обучающимися, преподавателями и мастерами в ходе обучения
ОК 7. Брать на себя ответственность за работу членов команды (подчиненных), за результат выполнения заданий.	самоанализ и коррекция результатов собственной работы
ОК 8. Самостоятельно определять задачи профессионального и личностного развития, заниматься самообразованием, осознанно планировать повышение квалификации.	организация самостоятельных занятий при изучении профессионального модуля
ОК 9. Ориентироваться в условиях частой смены технологий в профессиональной деятельности.	анализ инноваций в области интеграции программных модулей
ОК 10. Исполнять воинскую обязанность, в том числе с применением полученных профессиональных знаний (для юношей).	решение ситуативных задач, связанных с использованием профессиональных компетенций

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

Название ПК	Результат, который Вы должны получить после изучения содержания дисциплины
ПК 1. Анализировать проектную и техническую документацию на уровне взаимодействия компонент программного обеспечения..	-Грамотно выполненный анализ требований -Правильность определения функциональной структуры ПО -Правильность определения состава компонент ПО
ПК 2. Выполнять интеграцию модулей в программную систему.	Проектирование многомодульных программ Выполнение интеграции программ в программную систему
ПК 3. Выполнять отладку программного продукта с использованием специализированных программных средств.	— Умение выполнять различные виды отладки — Умение находить и распознавать ошибки с помощью отладки
ПК 4. Осуществлять разработку тестовых наборов и тестовых сценариев.	Умение разрабатывать тестовые наборы и сценарии тестирования Умение выполнять тестирование с помощью различных методик Умение выполнять тестирование с помощью специализированных средств
ПК 5. Производить инспектирование компонент программного продукта на предмет соответствия стандартам кодирования.	Выполнение оценки качества программных компонент Умение выполнять оптимизацию программного кода
ПК 6. Разрабатывать технологическую документацию.	Грамотное составление технической и проектной документации Знание стандартов в области документирования и умение их использовать

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

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

Образовательный маршрут по

МДК 03.02 Инструментальные средства разработки программного обеспечения

Таблица 1

Формы отчетности, обязательные для сдачи	Количество
практические занятия	20
Точки рубежного контроля	3
Итоговая аттестация (при наличии)	экзамен

Желаем Вам удачи!

СОДЕРЖАНИЕ ДИСЦИПЛИНЫ

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

Тема 3.1 Проектирование процесса разработки программного продукта

Основные понятия и термины по теме: инструментальными средства разработки ПО , ресурсы, программное обеспечение, коллективная разработка, календарное планирование

План изучения темы: (перечень вопросов, обязательных к изучению):

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

2. Методы организации коллективной разработки ПО.

3. Основы календарного планирования работы.

4. Понятие ресурсов.

Краткое изложение теоретических вопросов:

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

В настоящее время компьютерную технологию разработки ПС можно характеризовать [16.1] использованием

• программной поддержки для разработки графических требований и графических спецификаций ПС,

• автоматической генерации программ на каком-либо языке программирования или в машинном коде (частично или полностью),

• программной поддержки прототипирования.

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

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

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

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

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

Рис. Жизненный цикл программного средства для компьютерной технологии.

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

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

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

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

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

Аттестация ПС имеет прежнее содержание.

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

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

• конструкторы пользовательских интерфейсов;

• инструмент работы со словарем именованных сущностей;

• графические и тестовые редакторы спецификаций;

• анализаторы спецификаций;

• генератор программ;

• документаторы.

Методы организации коллективной разработки ПО.

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

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

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

Во время разработки любого проекта необходимым действием является регулярное сохранение предыдущих версий файлов (backup) с возможностью быстрого их восстановления. Необходимость в этом возникает, в частности, при поиске причины появления новых ошибок между версиями (bug tracking). Самым простым решением является использование для этих целей мощного архиватора, стримера и т.п., но их работа при больших размерах проекта может растянуться на часы. Более того, часто желательно сохранять каждую версию каждого файла, снабжая ее для избежания путаницы комментарием: кто изменил этот файл и зачем. Для этих целей используются системы контроля версий (Version Control Systems).

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

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

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

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

2. все происходит, как в случае a), только объединение разработок дозволено нескольким людям;

3. все программисты имеют дело с файлами всего проекта, точно зная только свои обязанности (намеренности) и не зная обязанности других (обычно в таких случаях основная копия исходного кода проекта находится в доступной им сети). Каждый программист самостоятельно занимается добавлением своих изменений в проект;

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

Данная статья обсуждает в основном средства автоматизации объединения и контроля версий для случаев c) и d), характерных для достаточно больших и долгосрочных проектов. Также рассматривается возможность использования этих средств для случаев a) и b), обычных при разработке ПО более мелких масштабов, а также для ситуаций, когда передача информации затруднена (например, люди в основном работают дома и приносят на работу результаты своего труда на дискетах).

Основы календарного планирования работы.

Календарное планирование – это разработка и доведение до структурных подразделений и рабочих мест оперативных плановых заданий по выпуску продукции и обеспечению их необходимыми для этого ресурсами [1,c.603]. Календарный план производства – это документ, который устанавливает последовательность и сроки выполнения производственных операций, а также определяет потребность в трудовых ресурсах во времени. Объемно-календарный план или, как он именуется в зарубежной практике MPS (Master Production Schedule) имеет следующие значения: 1. Предполагаемый план производства изделий. Это строго производственный план компании (в отличие от прогноза и потребности), выраженный в определенном для производства ассортименте изделий, объемах и сроках их производства. При составлении объемно-календарных планов следует принимать во внимание прогноз, укрупненный производственный план, маркетинговые планы и планы замены продуктовых линий и другие исходные данные, такие как незавершенное производство готовой продукции, наличие материалов, производственных мощностей. 2. Результат процесса объемно-календарного планирования. План, регулирующий производство и закупку изделий, обусловленных данным методом планирования. 3. План более высокого порядка, чем производственный. Планирование осуществляется, как правило, в интервале от месяца до пяти лет. Может быть подготовлен как фактический, так и сценарный MPS. Р. Фатхутдинов выделяет следующие цели и задачи оперативно-календарного планирования (ОКП): Рис. 1. Цели и задачи календарного планирования. Календарный график – это графическая интерпретация календарного плана, конкретизирующая его относительно состава, объемов, последовательности, сроков выполнения работ. При построении календарного графика необходимо учитывать наличие ресурсов, так как одновременное выполнение некоторых операций из-за ограничений, связанных с рабочей силой, оборудованием и другими видами ресурсов, может оказаться невозможным На производстве календарный план часто называют планом-графиком. Выделяют четыре вида календарных графиков в зависимости от решаемых задач:

1. Сводный календарный план или график. В нем указываются уточнённые сроки выполнения работ всем предприятием.

2. Объёмный календарный график. Он определяет очерёдность и сроки выполнения каждого вида работ в конкретном подразделении предприятия.

3. Рабочие календарные графики. Формируются конкретным подразделением предприятия и разрабатывается на неделю. Иногда имеют интеграцию в виде недельных графиков. Основной целью является предупреждение отклонения в работе предприятия. Рабочие графики — наиболее распространенный вид календарного планирования. Как правило, они составляются очень быстро и зачастую имеют упрощенную форму, т.е., как показывает практика, не всегда должным образом оптимизируются.

4. Часовые календарные графики. Используются в технологических картах и картах трудовых процессов, для формирования оптимальной загрузки ОПФ и трудовых ресурсов на предприятии. Данные графики оптимизированы или ориентированы на типичные или наиболее вероятные условия работы и в конкретных условиях требуют уточнения. При формировании годового календарного плана выпуска продукции необходимо, чтобы календарное распределение обеспечивало: Установленные сроки выпуска и поставки готовых изделий, обусловленные договорами; Возможность внесения корректив в связи с колебанием спроса; Минимальное незавершённое производство путем уплотнения производственного цикла изготовления изделий; Максимально возможное использование производственных мощностей цехов в каждом месяце; Создание предпосылок для слаженной и сопряжённой работы производственных подразделений и условий для эффективного функционирования предприятия в целом. Процесс календарного планирования осуществляется обратно ходу технологического процесса, т.е. плановые решения начинают формироваться на стадии готовой продукции. При этом он зависит от организационного типа и условий производства, учитываются сроки окончания технической подготовки производства, обеспечивается параллельное изготовление тех видов продукции, которые, с одной стороны, имеют максимальную конструктивно-техническую общность, а с другой – дополняют друг друга по трудоёмкости, обеспечивая в совокупности достаточно полную загрузку оборудования и рабочей силы. Основные ресурсы учитываемы в формировании календарного плана:

1. Трудовые ресурсы (руководители, сотрудники плановых служб).

2. Технические средства.

3. Экономико-математическое обеспечение

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

5. Календарно-плановые нормативы.

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

Лабораторные работы/ Практические занятия:

-Создание календарного плана в MS Project

-Оптимизация ресурсов планирования в MS Project

-Выравнивание ресурсов в MS Project

-Отслеживание проекта

-Анализ выполнения плана в MS Project

Задания для самостоятельного выполнения:

-Подготовка реферата «Обзор инструментальных средств различных направлений»

-Подготовка сообщения «Распределение обязанностей при командной работе над проектом»

-Составление календарного плана работы над собственным проектом

-Подготовка сообщения «Методы оптимизации календарного планирования»

Форма контроля самостоятельной работы:

-Подготовка реферата

-Подготовка сообщения

-Взаимопроверка студентов

Вопросы для самоконтроля по теме:

• Что представляют собой CASE-средства разработки ИС?

• Какие модели можно построить с помощью CASE-средств BPwin и ERwin?

• Перечислите требования, предъявляемые к методикам и программным инструментальным средствам разработки ИС.

• Что позволяет коллективное владение кодом

• Как повысить эффективность коллективной работы

• Какие существуют психологические командные роли

• В чем отличие авторской разработки от коллективной

• Дайте определение понятию коллективной разработки Какие методы существуют календарного планирования

• В чем их отличие

• В чем заключаются задачи календарного планирования

Тема 3.2 Использование основных методологий процессов разработки ПО

Основные понятия и термины по теме: методология IDEF0, Методология DFD, процессы IDEF3, методология ARIS eEPC.

План изучения темы: (перечень вопросов, обязательных к изучению):

1. Принципы методологии IDEF0

2. Методология DFD.

3. Методология описания процессов IDEF3

4. Имитационное моделирование

5. Методологии моделирования данных.

6. Генерация кода клиентской части с помощью ERwin.

7. Основные понятия методологии ARIS.

8. Моделирование требований к ПО с помощью ARIS eEPC

Краткое изложение теоретических вопросов:

Принципы методологии IDEF0

Принципы построения модели IDEF0

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT — Structured Analysis and Design Technique.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графи­ческое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.

Модели AS-IS и ТО-ВЕ.Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятель­ности организации, анализе преимуществ новых бизнес-процессов и сте­пени изменения существующей структуры организации бизнеса. Анализ недостатков и «узких мест» начинают с построения модели AS-1S (Как есть), т.е. модели существующей организации работы. Модель AS-IS может строиться на основе изучения документации (должностных инструкций, положений о предприятии, приказов, отчетов и т.п.), анке­тирования и опроса служащих предприятия, создания фотографии рабочего дня и других источников. Полученная модель AS-IS служит для выявления неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности предприятия. Исправ­ление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели ТО-ВЕ (Как будет) — модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей ТО-ВЕ, среди которых определяют наилучший вариант.

Следует указать на распространенную ошибку при создании модели AS-IS — это создание

Методология DFD.

Целью методики является построение модели рассматриваемой системы в видедиаграммы потоков данных (Data Flow Diagram – DFD). Диаграммы потоков данных предназначены прежде всего для описания документооборота и обработки информации, хотя допускают и представление других объектов.

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

– потоки данных,

– процессы (работы) преобразования входных потоков данных в выходные,

– внешние сущности,

– накопители данных (хранилища).

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

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

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

Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником данных. Ее имя должно содержать существительное, например, «склад товаров». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

Словари данных являются каталогами всех элементов данных, присутствующих в DFD, включая потоки данных, хранилища и процессы, а также все их атрибуты. Миниспецификации обработки – описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы.

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

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

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

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

– наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

– возможности описания преобразования данных процессов в виде последовательного алгоритма;

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

– возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк).

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

Методология описания процессов IDEF3

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

Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

1. Документировать данные о технологии процесса.

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

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

4. Содействовать принятию оптимальных решений при реорганизации технологических процессов.

5. Разрабатывать имитационные модели технологических процессов, по принципу «КАК БУДЕТ, ЕСЛИ…» Такая возможность существует при использовании, например, системы имитационного моделирования ARENA.

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы, относящиеся к первому типу, называются диаграммами потокового описания процесса(Process Flow Description Diagrams, PFDD), а ко второму – диаграммами сети изменения состояний объектов (Object State Transition Network, OSTN).

Таблица 3.4. Типы связей IDEF3

Изображение	Название	Назначение
	Временное предшествование (Temporal precedence)	Исходное действие должно завершиться, прежде чем конечное действие сможет начаться
	Объектный поток (Object flow)	Выход исходного действия является входом конечного действия (исходное действие должно завершиться, прежде чем конечное действие сможет начаться)
	Нечеткое отношение (Relationship)	Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения

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

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

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

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

 Таблица 3.5. Типы перекрестков

Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
	Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Synchronous AND	Все предшествующие процессы должны быть завершены одновременно	Все следующие процессы запускаются одновременно
	Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следу­ющих процессов должны быть запущены
	Synchronous R	Один или несколько предшествующих процессов завершаются одновременно	Один или несколько следу­ющих процессов запускаются одновременно
	XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий про­цесс запускается

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J».

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

Имитационное моделирование

Среди разнообразных инструментов компьютерных систем поддержки принятия решений (КСПР) важное место занимает имитационное моделирование как основа многовариантного прогнозирования и анализа систем высокой степени сложности.

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

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

Преимущества системно-динамического моделирования заключаются в следующем: системно-динамический подход начинается с попытки понять ту систему причин, которая породила проблему и продолжает поддерживать ее. Для этого собираются необходимые данные из различных источников, включая литературу, информированных людей (менеджеров, потребителей, конкурентов, экспертов), и проводятся специальные количественные исследования. После того как элементарный анализ причин проблемы произведен, формальная модель считается построенной. Первоначально она представляется в виде логических диаграмм, отражающих причинно-следственные связи, которые затем преобразуются в сетевую модель, изображенную например графическими средствами системы «Ithink». Затем эта сетевая модель автоматически преобразуется в ее математический аналог – систему уравнений, которая решается численными методами, встроенными в систему моделирования. Полученное решение представляется в виде графиков и таблиц, которые подвергаются критическому анализу. В результате модель пересматривается (изменяются параметры некоторых узлов сети, добавляются новые узлы, устанавливаются новые или изменяются существовавшие ранее связи и т.д.), затем модель вновь анализируется и так до тех пор, пока она не станет в достаточной мере соответствовать реальной ситуации. После того как модель построена, в ней выделяются управляемые параметры и выбираются такие значения этих параметров, при которых проблема либо снимается, либо перестает быть критически важной.

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

Методологии моделирования данных.

Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения. Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию. Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС. Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:  время решения задач;  стоимостные затраты на обработку данных;  надежность процессов;  косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д. Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования. В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования. Рассмотрим особенности построения моделей предметной области на трех уровнях детализации. Объектная структура Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования и т.д.). Объекты могут иметь динамическую или статическую природу: динамические объекты используются в одном цикле воспроизводства, например заказы на продукцию, счета на оплату, платежи; статические объекты используются во многих циклах воспроизводства, например, оборудование, персонал, запасы материалов. На внешнем уровне детализации модели выделяются основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги) и основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.). На концептуальном уровне построения модели предметной области уточняется состав классов объектов, определяются их атрибуты и взаимосвязи. Таким образом строится обобщенное представление структуры предметной области. Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС. Причем динамические объекты представляются единицами переменной информации или документами, а статические объекты — единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Модель базы данных как постоянно поддерживаемого информационного ресурса отображает хранение условно-постоянной и накапливаемой переменной информации, используемой в повторяющихся информационных процессах. Функциональная структура Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс. Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные). Причем бизнес-процессы и информационные процессы, как правило, неразрывны, то есть функции материального процесса не могут осуществляться без информационной поддержки. Например, отгрузка готовой продукции осуществляется на основе документа «Заказ», который, в свою очередь, порождает документ «Накладная», сопровождающий партию отгруженного товара. Функция может быть представлена одним действием или некоторой совокупностью действий. В последнем случае каждой функции может соответствовать некоторый процесс, в котором могут существовать свои подпроцессы, и т.д., пока каждая из подфункций не будет представлять некоторую недекомпозируемую последовательность действий. На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20. На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций. На внутреннем уровне отображается структура информационного процесса в компьютере: определяются иерархические структуры программных модулей, реализующих автоматизируемые функции. Структура управления В совокупности функций бизнес-процесса возможны альтернативные или циклические последовательности в зависимости от различных условий протекания процесса. Эти условия связаны с происходящими событиями во внешней среде или в самих процессах и с образованием определенных состояний объектов (например, заказ принят, отвергнут, отправлен на корректировку). События вызывают выполнение функций, которые, в свою очередь, изменяют состояния объектов и формируют новые события, и т.д., пока не будет завершен некоторый бизнес-процесс. Тогда последовательность событий составляет конкретную реализацию бизнес-процесса. Каждое событие описывается с двух точек зрения: информационной и процедурной. Информационно событие отражается в виде некоторого сообщения, фиксирующего факт выполнения некоторой функции изменения состояния или появления нового. Процедурно событие вызывает выполнение новой функции, и поэтому для каждого состояния объекта должны быть заданы описания этих вызовов. Таким образом, события выступают в связующей роли для выполнения функций бизнес-процессов. На внешнем уровне определяются список внешних событий, вызываемых взаимодействием предприятия с внешней средой (платежи налогов, процентов по кредитам, поставки по контрактам и т.д.), и список целевых установок, которым должны соответствовать бизнес-процессы (регламент выполнения процессов, поддержка уровня материальных запасов, уровень качества продукции и т.д.). На концептуальном уровне устанавливаются бизнес-правила, определяющие условия вызова функций при возникновении событий и достижении состояний объектов. На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей. Организационная структура Организационная структура представляет собой совокупность организационных единиц, как правило, связанных иерархическими и процессными отношениями. Организационная единица — это подразделение, представляющее собой объединение людей (персонала) для выполнения совокупности общих функций или бизнес-процессов. В функционально-ориентированной организационной структуре организационная единица выполняет набор функций, относящихся к одной функции управления и входящих в различные процессы. В процессно-ориентированной структуре организационная единица выполняет набор функций, входящих в один тип процесса и относящихся к разным функциям управления. На внешнем уровне строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимодействующих подразделений. На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала). На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы. Техническая структура Топология определяет территориальное размещение технических средств по структурным подразделениям предприятия, а коммуникация — технический способ реализации взаимодействия структурных подразделений. На внешнем уровне модели определяются типы технических средств обработки данных и их размещение по структурным подразделениям. На концептуальном уровне определяется способы коммуникаций между техническими комплексами структурных подразделений: физическое перемещение документов, машинных носителей, обмен информацией по каналам связи и т.д. На внутреннем уровне строится модель «клиент-серверной» архитектуры вычислительной сети. Описанные модели предметной области нацелены на проектирование отдельных компонентов ИС: данных, функциональных программных модулей, управляющих программных модулей, программных модулей интерфейсов пользователей, структуры технического комплекса. Для более качественного проектирования указанных компонентов требуется построение моделей, увязывающих различные компоненты ИС между собой. В простейшем случае в качестве таких моделей взаимодействия могут использоваться матрицы перекрестных ссылок: «объекты-функции», «функции-события», «организационные единицы — функции», «организационные единицы — объекты», «организационные единицы — технические средства» и т д. Такие матрицы не наглядны и не отражают особенности реализации взаимодействий. Для правильного отображения взаимодействий компонентов ИС важно осуществлять совместное моделирование таких компонентов, особенно с содержательной точки зрения объектов и функций. Методология структурного системного анализа существенно помогает в решении таких задач. Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – «разделяй и властвуй» и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых «черных ящиков») и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа. Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте. Функция – совокупность операций, сгруппированных по определенному признаку. Бизнес-процесс — связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя. Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя. Бизнес-модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия. Существуют различные методологии структурного моделирования предметной области, среди которых следует выделить функционально-ориентированные и объектно-ориентированные методологии. Функционально-ориентированные и объектно-ориентированные методологии описания предметной области Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные). Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия. Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных. С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации.

Генерация кода клиентской части с помощью ERwin.

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

ERwin поддерживает не только проектирование сервера БД, но и автоматическую генерацию клиентского приложения в средах разработки MS Visual Basic и Power Builder. Технология генерации состоит в том, что на этапе разработки физической модели данных каждой колонке присваиваются расширенные атрибуты, содержащие информацию о свойствах объектов клиентского приложения (в том числе и визуальных), которые будут отображать информацию, хранящуюся в соответствующей колонке. Эта информация записывается в файле модели. На основе информации, содержащейся в расширенных атрибутах, генерируются экранные формы. Полученный код может быть откомпилирован и выполнен без дополнительного ручного кодирования.

Каждой колонке в модели ERwin можно задать предварительно описанные и именованные свойства:

• правила валидации (проверка значений);

• начальные значения, устанавливаемые по умолчанию;

• стиль визуального объекта (например, радиокнопка, поле ввода и др.);

• формат изображения.

Для описания каждого свойства ERwin содержит соответствующие редакторы.

Основные понятия методологии ARIS.

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

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

Изначально, фирма IDS Prof. Scheer существовала как отделение Института Информационных Систем германского Университета Саарланд. Данный институт является одним из наиболее известных германских исследовательских центров в области информационных систем. Этот факт позволил обеспечить тесную связь методологии ARIS с теорией информационных систем с учетом практики их применения в конкретных условиях.

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

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

В семейство ARIS входят следующие модули:

• ARIS Toolset — базовая инструментальная среда;

• ARIS Easy Design — упрощенная среда моделирования;

• ARIS Simulation — модуль динамического имитационного моделирования;

• ARIS Link for R/3 — модуль, обеспечивающий интеграцию с репозиторием R/3;

• ARIS Analyzer for R/3 — модуль проверки создаваемых моделей на соответствие методологии SAP;

• ARIS Promt — модуль стоимостного анализа;

• дополнительные модули-интерфейсы, обеспечивающие интеграцию с системами Microsoft Project, ER/win, Designer/2000, IBM Flowmark (класс workflow), Staffware и т.д.

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

Методология моделирования ARIS

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

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

 функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;

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

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

Моделирование требований к ПО с помощью ARIS eEPC

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

Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций и т.п., а детальное описание процессов само по себе не представляет ценности.Реинжиниринг бизнес-процессов (англ. Business process reengineering) — это фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимальной эффективности производственно-хозяйственной и финансово-экономической деятельности, оформленное соответствующими организационно-распорядительными и нормативными документами. Бизнес-инжиниринг состоит из моделирования бизнес-процессов (разработка модели «как есть», её анализ, разработка модели «как надо») и разработки и реализации плана перехода к состоянию «как надо».

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique — метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam — это Integrated Computer-Aided Manufacturing) и алгоритмические языки. Основные типы методологий моделирования и анализа бизнес-процессов:

· Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов — стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.

· Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.

· Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.

Модель состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, всефункции иинтерфейсы на них представлены какблоки и дуги. Место соединения дуги с блоком определяет тип интерфейса:

· Управляющая информация входит в блок сверху.

· Входная информация входит в блок слева.

· Результаты выходят из блока справа.

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

Лабораторные работы/ Практические занятия:

-Анализ документации на создание программной системы с помощью IDEF0

-Проектирование внешнего окружения системы с помощью IDEF0

-Проектирование процессов программной системы с помощью IDEF0

-Оптимизация организационной структуры с помощью IDEF0

-Моделирование системы интеграции модулей с помощью DFD

-Моделирование потоков данных с помощью DFD

-Проектирование сценариев взаимодействия программных модулей с помощью IDEF3

-Проектирование процессов программной системы с помощью IDEF3

-Моделирование данных с помощью ERD

-Моделирование требований к ПО с помощью ARIS eEPC

-Моделирование структуры ПО с помощью ARIS eEPC

Задания для самостоятельного выполнения:

-Изучение методик проектирования по учебнику

-Применение методологии IDEF0 для собственного проекта

-Применение методологии DFD для собственного проекта

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

-Применение методологии ERD для собственного проекта

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

-Применение методологии ARIS для собственного проекта

Форма контроля самостоятельной работы:

-Подготовка сообщения

-Взаимопроверка студентов

Вопросы для самоконтроля по теме:

1. Как применяется методология IDEF0

2. Как применяется методология DFD

3. Как применяется методология ERD

4. Как применяется методология ARIS

5. Как происходит процесс моделирование потоков данных

Тема 3.3 Инструментальные средства отладки и тестирования

Основные понятия и термины по теме: Отладка, RubyWatir

План изучения темы: (перечень вопросов, обязательных к изучению):

1. Инструментальные средства отладки.

2. Виды отладки.

3. Средства повышения эффективности.

4. Автоматизация тестирования ПО.

5. Техники тестирования.

6. Основные инструменты автоматизированного тестирования.

7. Тестирование ПО с помощью RubyWatir.

Краткое изложение теоретических вопросов:

Инструментальные средства отладки.

Инструментальные средства поддержки технологии проектирования и аудита информационных систем и сервисов

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

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

• обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по авто­матизации деловых процессов;

• гарантия создания системы с заданными параметрами в течение заданного вре­мени в рамках оговоренного заранее бюджета;

• простота сопровождения, модификации и расширения системы с целью обес­печения ее соответствия изменяющимся условиям работы предприятия;

• обеспечение создания корпоративных информационных систем, отвечающих требованиям открытости, переносимости и масштабируемости;

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

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

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

Технология проектирования может быть представлена как совокупность трех со­ставляющих:

• заданной последовательности выполнения технологических операций проек­тирования;

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

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

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

• данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;

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

• программными и техническими средствами;

• исполнителями.

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

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

• поддерживать полный жизненный цикл информационной системы;

• обеспечивать гарантированное достижение целей разработки системы с заданным качеством и в установленное время;

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

• технология должна обеспечивать возможность ведения работ по проектирова­нию отдельных подсистем небольшими группами (3-7 человек). Это обуслов­лено принципами управляемости коллектива и повышения производительно­сти за счет минимизации числа внешних связей;

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

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

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

CASE-технологии

CASE(Computer-AidedSoftware/SystemEngineering) как новое направление в программировании сформировалось за последние 10-15 лет.

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

Виды отладки.

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

Отладка = Тестирование + Поиск ошибок + Редактирование.

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

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

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

Рис. 10.1. Спектр подходов к проектированию тестов.

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

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

Средства повышения эффективности.

Важным фактором повышения темпов развития производства, снижения себестоимости продукции и повышения рентабельности является более эффективное использование ОПФ.

Основные направления повышения эффективности использования ОПФ:

1) рост уровня фондообеспеченности предприятия

2) совершенствование средств труда, повышение их надежности и долговечности

3) улучшение технического обслуживания

4) оптимизация структуры ОФ

5) установление оптимальной пропорции между ОПФ и оборотными средствами

6) внедрение прогрессивных технологий

7) повышение квалификации кадров, их стимулирование.

Автоматизация тестирования ПО.

Тестирование- это процесс выполнения программы, целью которого является выявление ошибок. Никакое тестирование не может доказать отсут­ствие ошибок в сложном ПО, поскольку выполнение полного тестирования становится не­возможным и имеется вероятность, что остались невыявленные ошибки. Соблюдение основных правил тестирования и научно обоснованный подбор тестов может уменьшить их количество. Процесс разработки согласно современной модели жизненного цикла ПО предполагает три стадии тестирования: автономное тестирование компонентов ПО; комплексноетестирование разрабатываемого ПО; системное или оценочное тестирование на соответствие основным критериям качества. Для повышения качества тестирования рекомендуется соблюдать следу­ющие основные принципы:

а) предполагаемые результаты должны быть известны до тестирования;

б) следует избегать тестирования программы автором;

в) необходимо досконально изучать результаты каждого теста;

г) необходимо проверять действия программы на неверных данных;

д) необходимо проверять программу на неожиданные побочные эффекты на неверных данных.

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

Существуют два принципиально различных подхода к формированию тестовых наборов: структурный и функциональный.Структурный подходбазируется на том, что известна структуратести­руемого ПО, в том числе его алгоритмы («стеклян­ный ящик»). Тесты строятся для проверки правильности реализации заданной логики в коде программы. Функциональный подходосновывается на том, что структура ПО не известна («черный ящик»). В этом случае тесты строят, опираясь на функциональные спецификации. Этот подход называют также подходом, управляемым данными, так как при его использовании тесты строят на базе различных способов декомпозиции множества данных. Наборы тестов, полученные в соответствии с методами этих подходов, объединяют, обеспечивая всестороннее тестирование ПО.

Ручной контроль используют на ранних эта­пах разработки. Все проектные решения анализируются с точки зрения их правильности и целесообразности как можно раньше, пока их можно легко пересмотреть. Различают статический идинамический подходы к ручному контролю. При статическомподходе анализируют структуру, управляющие и инфор­мационные связи программы, ее входные и выходные данные. При динамическом — выполняют ручное тестирование (вручную моделируют про­цесс выполнения программы на заданных исходных данных). Исходными данными для таких проверок являются: техническое зада­ние, спецификации, структурная и функциональная схемы программного продукта, схемы отдельных компонентов, а для более поздних этапов — алгоритмы и тексты программ, а также тестовые наборы. Доказано, что ручной контроль способствует существенному увеличе­нию производительности и повышению надежности программ и с его помо­щью можно находить от 30 до 70 % ошибок логического проектирования и кодирования. Основными методами ручного контроля являются: инспекции исходного текста, сквозные просмотры, проверка за столом, оценки программ.

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

Тестирование ПО с помощью RubyWatir.

Тестирование web-приложений является неотъемлемой частью процесса их разработки. Существуют различные уровни тестирования, вот некоторые из них:

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

• интеграционное тестирование;

• системное тестирование;

• приемочное тестирование.

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

В этой статье рассказывается о высокоуровневой методике тестирования web-приложений которую можно использовать как для приемочного так и для системного тестирования. Ключевую роль при этом играет Ruby-библиотека Watir (Web Application Testing In Ruby). Библиотека Watir позволяет запрограммировать действия браузера Internet Explorer на языке Ruby. Таким образом можно автоматизировать значительную часть ручной работы тестеров по заполнению форм, переходу по ссылкам, проверке User-Stories т.д.

Библиотека Watir

Для управления браузером библиотека Watir использует протокол OLE. Это накладывает определенные ограничения как на выбор платформы, так и на выбор браузера. Так, на момент написания этих строк Watir работает только под Windows и только с Internet Explorer. Не отчаивайтесь раньше времени если у вас другая система или вы пользуетесь другим браузером! Существуют версии Watir для Firefox и для Safari:

• FireWatir — работает с Firefox под Linux, Windows и Mac;

• SafariWatir — работает с Safari под Mac.

В перспективе разработчики планируют объединить все три версии в один проект. Отмечу, что аналоги Watir есть и для других языков программирования:

• Watij — версия Watir для Java;

• WatiN — версия Watir для .Net;

• BrowserUnit — еще одна версия Watir для .Net.

Лабораторные работы/ Практические занятия:

-Отладка программ с помощью встроенного отладчика Delphi

-Повышение эффективности программного кода с помощью инструментов среды Delphi

-Тестирование программы с помощью RubyWatir

Задания для самостоятельного выполнения:

-Аналитический обзор средств отладки. Работа с ресурсами Интернет

-Подготовка реферата «Основные методы отладки»

-Подготовка сообщения «Средства повышения эффективности программ»

-Обзор средств автоматизированного тестирования по материалам сети Интернет.

-Отладка программ для собственного проекта

Форма контроля самостоятельной работы:

-Подготовка реферата

-Подготовка сообщения

-Взаимопроверка студентов

Вопросы для самоконтроля по теме:

1. Для чего необходимо тестирование проекта

2. Что необходимо для отладки программ

3. Какие средства повышения эффективности разработки ПО

КОНТРОЛЬ И ОЦЕНКА РЕЗУЛЬТАТОВ ОСВОЕНИЯ ДИСЦИПЛИНЫ

Текущий контроль

Перечень точек рубежного контроля	Охват тем (указать номера тем, подлежащих контролю)	Форма контроля
1	3.1	Тестовые задания
2	3.2.	Тестовые задания
3	3.3.	Контрольная работа

Итоговый контроль по дисциплине

3.3.1. Теоретические вопросы

1. Дайте определение понятия проект. Охарактеризуйте состав и структуру коллектива разработчиков, их функции.

2. Охарактеризуйте структурный подход к проектированию ИС. CASE — средства разработки ПО.

3. . Опишите как осуществляется моделирование потоков данных (процессов). Внешние сущности. Системы и подсистемы. Процессы. Накопители данных. Потоки данных. Построение иерархии диаграмм потоков данных.

4. Охарактеризуйте метод моделирования IDEF3.

5. Охарактеризуйте, что представляет собой методология DFD как инструмент моделирования потоков данных.

6. Опишите инструменты функционального моделирования бизнес-процессов и использованием стандарта IDEF0.

7. Сформулируйте понятие и принципы работы с инструментальными средствами разработки ПО

8. Опишите методы организации коллективной разработки ПО

9. Охарактеризуйте процесс разработки сетевой модели

10. Опишите элементы Microsoft Office Project 2007

11. Опишите элементы графической нотации DFD

12. Опишите элементы методологии IDEF0

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

14. Опишите Case-метод Баркера

15. Объясните как осуществляется генерация кода клиентской части с помощью ERwin

16. Опишите нотацию ARIS eEPC

17. Охарактеризуйте модель AS-IS

18. Охарактеризуйте модель ТО-ВЕ

19. Дайте определение понятию отладки программного средства

20. Дайте определение понятию программного модуля.

21. Опишите методические аспекты проектирования ПО. Общие принципы проектирования систем.

22. Расскажите про основы объектно-ориентированного подхода к анализу и проектированию ПО. Унифицированный язык моделирования UML.

23. Объясните функциональное проектирование ИСО, IDEF0, синтаксис, особенности проектирования.

24. . Объясните функциональное проектирование ИСО, IDEF3, синтаксис, особенности проектирования.

25. Опишите методологию DFD для проектирования ИСО.

3.4. Перечень практических заданий

Задание 1.

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

№	Название задачи	Длит (дн)	Предшественники
1	Начало проекта	0
2	Утверждение проектов
3	Начало утверждения проектов	0	1
4	Утверждение проекта на строительство	90	3
5	Утверждение проекта на газ	60	3
6	Утверждение проекта на водопровод и канализацию	30	3
7	Утверждение проекта на отопление	45	3
8	Проекты утверждены	0	4; 5; 6; 7
9	Строительство фундамента
10	Начало закладки фундамента	0	8
11	Рытье траншей	10	10
12	Заливка фундамента	5	11
13	Фундамент завершен	0	12
14	Каркас и крыша
15	Начало каркаса	0	13
16	Кладка стен	60	15
17	Перекрытие стен	15	16
18	Установка крыши	30	17
19	Установка наружных дверей и окон	7	17
20	Установка полов	5	17
21	Каркас готов	0	18; 19; 20
22	Коммуникации
23	Начало установки коммуникаций	0	21
24	Проведение и подключение водопровода и канализации	10	23
25	Установка и подключение электропроводки	5	23
26	Установка и подключение газовых коммуникаций	5	23
27	Коммуникации готовы	0	24; 25; 26
28	Внутренняя отделка
29	Начало отделки	0	27
30	Внутренние двери	10	29
31	Навесные потолки	5	30
32	Отделка стен	3	30
33	Монтаж отопления	10	30
34	Установка оборудования, приборов и сантехники	5	31; 33
35	Настил полов	15	32; 34
36	Конец отделки	0	35
37	Конец проекта	0	36

1. Между работами 12 и 13 установить задержку в 30 дней, необходимую для выдержки фундамента.

2. Для задачи 32 установить ограничение Как можно позже.

Задание2

• Создать проект Внедрение бухгалтерской системы, предназначенный для автоматизации бухгалтерии небольшого предприятия, состоящей из 10 человек. Дата начала проекта – 1 июля 2010 года. Перечень задач проекта, их связи и длительности приведены в таблице. Фазы выделены полужирным курсивом, а вехи имеют нулевую длину. Названия задач, входящих в фазу, выделены отступом слева.

  №	Название задачи	Длит (дн)	Предшественники
  1	Начало проекта	0
  2	Выбор системы
  3	Изучение рынка бухгалтерских систем	7	1
  4	Составление требований к бухгалтерским системам	7	1
  5	Консультации с фирмами-разработчиками	7	3;4
  6	Принятие окончательного решения	2	5
  7	Выбор завершен	0	6
  8	Приобретение программного обеспечения
  9	Заключение договоров	6	2
  10	Оплата за ПО	2	9
  11	Оформление ПО на баланс	3	10
  12	Приобретение ПО завершено	0	11
  13	Составление проекта сети
  14	Разработка архитектуры сети	7	7
  15	Проработка физического размещения сети	5	14
  16	Проект сети завершен	0	15
  17	Приобретение компьютеров и сетевого оборудования
  18	Сбор информации о поставщиках и предложениях	7	7
  19	Анализ и выбор поставщика	5	14;18
  20	Заключение договоров	5	19
  21	Оплата за оборудование	2	20
  22	Оформление оборудования на баланс	3	21
  23	Приобретение оборудования завершено	0	22
  24	Обучение администратора и программиста
  25	Курсы администраторов	18	16
  26	Курсы программистов	18	12
  27	Сдача сертификационных экзаменов	3	25;26
  28	Обучение завершено	0	27
  29	Монтаж локальной сети
  30	Установка компьютеров на рабочих местах	3	23;28
  31	Монтаж кабеля	10	23;28
  32	Монтаж сетевых устройств	10	23;28
  33	Подключение кабеля к компьютерам и сетевым устройствам	5	30;31;32
  34	Монтаж завершен	0	33
  35	Установка ПО на компьютеры
  36	Установка сервера	5	34
  37	Создание доменов и пользователей	7	36
  38	Проверка и настройка работы сети	5	37
  39	Настройка сети завершена	0	38
  40	Ввод начальных данных
  41	Ввод справочников	40	39
  42	Ввод начальных остатков	40	41
  43	Ввод начальных данных завершен	0	42
  44	Обучение персонала
  45	Принципы работы системы	3	39
  46	Изучение интерфейса	5	45
  47	Изучение справочников	20	41;46
  48	Изучение документов и журналов	30	42;47
  49	Обучение завершено	0	48
  50	Передача в эксплуатацию
  51	Формирование тестовой отчетности	5	49
  52	Акт ввода в эксплуатацию	3	51
  53	Передача в эксплуатацию завершена	0	52
  54	Конец проекта	0	53

• Между задачами 10 и 11 установить задержку в 5 дней, необходимую для прохождения безналичной оплаты.

• Между задачами 21 и 22 установить задержку в 7 дней, необходимую для прохождения безналичной оплаты и доставки оборудования.

• Установить тип связи между задачами 41 и 47 начало-начало и задержку в 5 дней.

• Установить ограничение для задачи 42 ограничение не ранее 1.01.2011.

Задание 3

• Создать проект Ремонт квартиры, предназначенный для проведения ремонта в двухкомнатной квартире. Дата начала проекта – 1 февраля 2010 года. Перечень задач проекта, их связи и длительности приведены в таблице. Фазы выделены полужирным курсивом, а вехи имеют нулевую длину. Названия задач, входящих в фазу, выделены отступом слева.

№	Название задачи	Длит (дн)	Предшественники
1	Начало проекта	0
2	Замена окон
3	Замер окон	2	1
4	Заказ и оплата окон	2	3
5	Установка окон	2	4
6	Отделка откосов	2	5
7	Замена окон завершена	0	6
8	Замена дверей
9	Замер дверей	2	1
10	Заказ и оплата дверей	2	9
11	Установка дверей	3	10
12	Замена дверей завершена	0	11
13	Замена отопительных приборов
14	Заказ и оплата отопительных приборов	3	1
15	Установка отопительных приборов	5	14
16	Замена отопительных приборов завершена	0	15
17	Выравнивание стен
18	Стены в спальне	4	7;12;16
19	Стены в гостиной	4	18
20	Стены в кухне	3	19
21	Стены в прихожей	4	20
22	Выравнивание стен завершено	0	21
23	Санузел
24	Снятие штукатурки в санузле	3	12;16
25	Отделка стен санузла	4	24
26	Отделка потолка санузла	2	25
27	Отделка пола санузла	2	25
28	Установка сантехнического оборудования	1	27
29	Ремонт санузла завершен	0	28
30	Ванная
31	Снятие штукатурки в ванной	3	12;16
32	Отделка стен ванной	5	31
33	Отделка потолка ванной	2	32
34	Отделка пола ванной	2	33
35	Установка сантехники	1	34
36	Ремонт ванной завершен	0	35
37	Отделка стен
38	Отделка стен в спальне	5	22;29;36
39	Отделка стен в гостиной	7	38
40	Отделка стен в кухне	5	39
41	Отделка стен в прихожей		40
42	Отделка стен завершена	0	41
43	Потолки
44	Замер	2	22
45	Заказ и оплата потолков	2	44
46	Навесной потолок в спальне	2	38;45
47	Навесной потолок в гостиной	2	39;45
48	Панельный потолок в кухне	2	40
49	Навесной потолок в прихожей	2	41;45
50	Монтаж потолков завершен	0	46;4;48;49
51	Полы
52	Отделка полов в спальне	6	46
53	Отделка полов в гостиной	6	47
54	Отделка полов на кухне	3	48
55	Отделка полов в прихожей	5	49
56	Отделка полов завершена	0	52;53;54;55
57	Оборудование кухни
58	Заказ и оплата кухонного оборудования	5	48
59	Замена кухонного оборудования	3	54;58
60	Оборудование кухни завершено	0	59
61	Конец проекта	0	60

Установить задержки между задачами в соответствии с таблицей

Предшественник	Последователь	Задержка
4	5	15
5	6	15
10	11	7
14	15	5
45	46	20
45	47	20
45	49	20
58	59	25

Задание 4

1. В проекте, находящимся в папке Antaris-lab6m-03.02ЭКЗАМЕН- Строительство дома создать список ресурсов в соответствии с параметрами, перечисленными в таблице

		Таблица норм	Станд.ставка	Ставка сверхур.	Затраты на исп.
Архитектор	Т	А	—		55000
МУП «Горгаз»	T	A	—		70000
МУП «Водоканал»	T	A	—		50000
АО «Водолей»	T	A	—		50000
Рабочий1	T	A	1000р/д		—
Рабочий2	T	A	1000р/д		—
Рабочий3	T	A	1000р/д		—
Подсобник1	T	A	400 р/д		—
Подсобник2	T	A	400 р/д		—
Трактор	T	A			7000
Плотник1	T	A B	1500 р/д –	200р./ч	– 7500
Плотник2	T	A B	1500 р/д –	200р./ч	– 7500
«Неопласт»	T	A	—		120000
Водопроводчик1	T	A	800 р/д		—
Водопроводчик2	T	A	800 р/д		—
Электрик	T	A	1000 р/д		—
АО «Газовик»	T	A	—		25000
ООО «Потолки»	T	A	—		150000
Песок	M	A	500 р/т		—
Щебень	M	A	600 р/т		—
Цемент	M	A	—
Кирпич	M	A	7 р/шт		—
Брус	M	A	—		25000
Доска обрезная	M	A	7000р/м3		—
Доска необрезная	M	A	5000р/м3		—
Шифер	M	A	—		40000
Электропровод	M	A	—		15000
Электросчетчик	M	A	—		5000
Труба водопроводная	M	A	—		35000
Труба канализационная	M	A	—		30000
Штукатурка	M	A	—		150000
Потолок	M	A	150 р/м2		—
Окно	M	A	10000		—
Дверь наружная	M	A	—		20000
Труба отопительная	M	A	—		20000
Котел	M	A	—		40000
Печь газовая	M	A	—		20000
Ванна	M	A	45000		—
Унитаз компакт	M	A	20000		—
Раковина	M	A	16000		—
Кран	M	A	7000		—
Паркет	M	A	550 р/м2		—
Труба газовая	M	A	—		50000
Дверь внутренняя	M	A	9000		—
Доставка	З

1. Создать назначения ресурсов в соответствии с таблицей

Задача	Ресурс	Единицы (затраты)	Таблица норм затрат
Утверждение проекта на строительство	Архитектор	100	A
Утверждение проекта на газ	МУП «Горгаз»	100	A
Утверждение проекта на водопровод и канализацию	МУП «Водоканал»	100	A
Утверждение проекта на отопление	АО «Водолей»	100	A
Рытье траншей	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Трактор	100 100 100 100 100 100	А А А А А А
Заливка фундамента	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Песок Щебень Цемент Доска необрезная Доставка	100 100 100 100 100 10т 10т 2500кг 3м3 25000р	А А А А А А А А А
Кладка стен	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Кирпич Песок Цемент Доставка	100 100 100 100 100 70000 6т 2000кг 25000р	А А А А А А А А
Перекрытие стен	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Брус Доска обрезная Доставка	100 100 100 100 100 1 7 м3 15000р	А А А А А А А
Установка крыши	Плотник1 Плотник2 Доска необрезная Шифер Доставка	100 100 10 1 12000р	А А А А
Установка наружных дверей и окон	ООО «Неопласт» Окно Дверь неружная	100 9 1	А А А
Установка полов	Плотник1 Плотник2 Доска обрезная Доставка	100 100 10 7000р	А А А
Проведение и подключение водопровода и канализации	Водопроводчик1 Водопроводчик2 Труба водопров Труба канализ	100 100 1 1	А А А А
Установка и подключение электропроводки	Электрик Электросчетчик Электропровод	100 1 1	А А А
Установка и подключение газовых коммуникаций	АО «Газовик» Труба газовая	100 1	А А
Отделка стен	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Штукатурка	100 100 100 100 100 1	А А А А А А
Навесные потолки	ООО «Потолки» Потолок	100 190	А А
Внутренние двери	Плотник1 Плотник2 Дверь внутренняя Доставка	100 100 10 10000р	В В А
Монтаж отопления	Водопроводчик1 Водопроводчик2 Труба отопит.	100 100 1	А А А
Установка оборудования, приборов и сантехники	Водопроводчик1 Водопроводчик2 Котел Печь газовая Ванна Унитаз компакт Раковина Кран	100 100 1 1 1 2 3 4	А А А А А А А А
Настил полов	Рабочий1 Рабочий2 Рабочий3 Подсобник1 Подсобник2 Паркет	100 100 100 100 100 190	А А А А А А

1. Установить профили загрузки ресурсов: МУП «Горгаз» – затраты в конце, МУП «Водоканал» – поздний пик, АО «Водолей» – колокол.

Задание 5

1. В проекте, находящимся в папке Antaris-lab6m-03.02ЭКЗАМЕН- Внедрение бухгалтерской системы создать список ресурсов в соответствии с параметрами, перечисленными в таблице

		Таблица норм	Станд. ставка	Ставка сверхур.	Затраты на исп
Главбух	T	A B	90000р./мес	500р./ч	30000р
Администратор	Т	А В	70000р./мес	450р./ч	40000р
Программист	T	A B	60000р./мес	400р./ч	50000р
Техник	T	A	40000р./мес	250р./ч	—
Расчетчик1	T	A	40000р./мес	250р./ч	—
Расчетчик2	T	A	40000р./мес	250р./ч	—
Расчетчик3	T	A	40000р./мес	250р./ч	—
Бухгалтер мат. учета1	T	A	40000р./мес	250р./ч	—
Бухгалтер мат. учета2	T	A	40000р./мес	250р./ч	—
Бухгалтер учета ОС и НМА	T	A	40000р./мес	250р./ч	—
Бухгалтер учета ОС	T	A	40000р./мес	250р./ч	—
Бухгалтер учета реализации	T	A	40000р./мес	250р./ч	—
Бухгалтер производ-ственного учета	T	A	40000р./мес	250р./ч	—
Компьютер	M	A	15000		—
Сервер	M	A	50000		—
Принтер	M	A	5000		—
МФУ	M	A	7000		—
Сетевой кабель	M	A	—		15000
Сетевой концентратор	M	A	3000		—
Панель	M	A			10000
Разъемы и розетки	M	A	—		15000
Бухгалтерская система	M	A	—		100000
Офисный пакет	M	A	—		70000
ОС рабочей станции	M	A	—		60000
Серверная ОС	M	A	—		30000
DVD-матрица	M	A	10		—
Интернет	З
Междугородние переговоры	З
Оплата курсов	З

1. Создать назначения ресурсов в соответствии с таблицей

Задача	Ресурс	Единицы (затраты)	Таблица норм затрат
Изучение рынка бухгалтерских систем	Администратор Интернет	100	A 1500
Составление требований к бухгалтерским системам	Администратор Главбух	100 20	A A
Консультации с фирмами-разработчиками	Администратор Междугородние переговоры Интернет	100	A 2000 1000
Принятие окончательного решения	Администратор Главбух	100 100	A A
Заключение договоров	Администратор Программист Главбух	100 100 100	A A A
Оплата за ПО	Главбух Бухгалтерская система Офисный пакет ОС рабочей станции Серверная ОС	10	A A A A A
Оформление ПО на баланс	Бухгалтер учета ОС и НМА	30	A
Разработка архитектуры сети	Администратор Программист Техник	100 100 50	A A A
Проработка физического размещения сети	Администратор Программист Техник	100 100 100	A A A
Сбор информации о поставщиках и предложениях	Администратор Интернет Междугородние переговоры	50	A 1000 1500
Анализ и выбор поставщика	Администратор Главбух Интернет	50 20	A A 1000
Заключение договоров	Администратор Главбух	100 50	A A
Оплата за оборудование	Главбух Компьютер Сервер Принтер МФУ Сетевой кабель Сетевой концентратор Панель Разъемы и розетки	30 12 1 2 2 2	А А А А А А А А А
Оформление оборудования на баланс	Бухгалтер учета ОС	70	A
Курсы администраторов	Администратор Оплата курсов	100	A 25000
Курсы программистов	Программист Оплата курсов	100	A 2000
Сдача сертификационных экзаменов	Администратор Программист	100 100	A A
Установка компьютеров на рабочих местах	Техник	100	A
Монтаж кабеля	Техник	100	A
Монтаж сетевых устройств	Техник	100	A
Подключение кабеля к компьютерам и сетевым устройствам	Техник	100	A
Установка сервера	Администратор	100	A
Создание доменов и пользователей	Администратор	100	A
Проверка и настройка работы сети	Администратор Программист	100 100	A A
Ввод справочников	Администратор Программист Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета DVD-матрица	100 100 30 30 30 50 50 50 50 50 50 10	В В А А А А А А А А А А
Ввод начальных остатков	Администратор Программист Главбух DVD-матрица	100 100 50 10	В В А А
Принципы работы системы	Администратор Главбух Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета	50 50 50 50 50 50 50 50 50 50 50	А А А А А А А А А А А
Изучение интерфейса	Программист Главбух Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета	50 50 50 50 50 50 50 50 50 50 50	А А А А А А А А А А А
Изучение справочников	Программист Главбух Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета	50 50 50 50 50 50 50 50 50 50 50	А А А А А А А А А А А
Изучение документов и журналов	Программист Главбух Расчетчик1 Расчетчик2 Расчетчик3 Бухгалтер мат. учета1 Бухгалтер мат. учета2 Бухгалтер учета ОС и НМА Бухгалтер учета ОС Бухгалтер учета реализации Бухгалтер производственного учета	50 50 50 50 50 50 50 50 50 50 50	А А А А А А А А А А А
Формирование тестовой отчетности	Администратор Программист Главбух	100 100 100	А А А
Акт ввода в эксплуатацию	Администратор Главбух	50 50	А А

• Установить различные профили загрузки для ресурса Техник.

Задание 6

• В проекте, находящимся в папке Antaris-lab6m-03.02ЭКЗАМЕН — Ремонт квартиры создать список ресурсов в соответствии с параметрами, перечисленными в таблице

• 		Таблица норм	Станд.ставка	Ставка сверхур.	Затраты на исп.
  «Неопласт»	T	A B			12000p
  «Крепкие двери»	T	A B	2000р./д
  «Горгаз»	T	A			25000р
  Слесарь-водопроводчик	T	A B	/1000р./д	150р./ч	20000р
  Штукатур	T	A	800р./д	100р./ч	—
  Подсобник	T	A	400р./д	50р./ч	—
  Плиточник	T	A	1500р./д	200р./ч	—
  Плотник	T	A	1500р./д	200р./ч	—
  «Светлый потолок»	T	A	1000р./д	150р./ч	—
  Окно	M	A	10000		—
  Дверь	M	A	9000		—
  Двухконтурный котел	M	A	55000		—
  Отопительная батарея	M	A	5000		—
  Унитаз-компакт	M	A	15000		—
  Ванна	M	A	35000		—
  Раковина	M	A	25000		—
  Смеситель с душем	M	A	10000		—
  Плитка	M	A	1000р./кв.м		—
  Панель	M	A	500р./шт		—
  Обои	M	A	1500р./рулон		—
  Навесной потолок	M	A	—		70000
  Паркет	M	A	1500р./кв.м		—
  Газовая печь	M	A	—		25000
  Вытяжка	M	A	—		15000
  Мойка	M	A	—		10000
  Смеситель	M	A	—		12000
  Доставка	З

• Создать назначения ресурсов в соответствии с таблицей

  Задача	Ресурс	Единицы (затраты)	Таблица норм затрат
  Замер окон	«Неопласт»	100	A
  Заказ и оплата окон	Окно	3	A
  Установка окон	«Неопласт»	100	A
  Отделка откосов	«Неопласт»	100	B
  Замер дверей	«Крепкие двери»	100	A
  Заказ и оплата дверей	Дверь	6	A
  Установка дверей	«Крепкие двери»	100	B
  Заказ и оплата отопительных приборов	Двухконтурный котел Отопительная батарея	1 3	A A
  Установка отопительных приборов	Слесарь-водопроводчик Подсобник	100 100	A A
  Стены в спальне	Штукатур	100	A
  Стены в гостиной	Штукатур	100	A
  Стены в кухне	Штукатур	100	A
  Стены в прихожей	Штукатур	100	A
  Снятие штукатурки в санузле	Подсобник	100	A
  Отделка стен санузла	Плиточник Плитка	100 10	A A
  Отделка потолка санузла	Плиточник Панель	100 5	A A
  Отделка пола санузла	Плиточник Плитка	100 5	A A
  Установка сантехнического оборудования	Слесарь-водопроводчик Унитаз-компакт	100 1	B A
  Снятие штукатурки в ванной	Подсобник	100	A
  Отделка стен ванной	Плиточник Плитка	100 10	A A
  Отделка потолка ванной	Плиточник Панель	100 6	A A
  Отделка пола ванной	Плиточник Плитка	100 6	A A
  Установка сантехники	Слесарь-водопроводчик Ванна Раковина Смеситель с душем	100 1 1 1	B A A A
  Отделка стен в спальне	Штукатур Обои	100 8	A A
  Отделка стен в гостиной	Штукатур Обои	100 8	A A
  Отделка стен в кухне	Штукатур Плиточник Плитка Панель	100 100 5 10	A A A A
  Отделка стен в прихожей	Штукатур Плиточник Панель	100 100 15	A A A
  Замер	«Светлый потолок»	100	A
  Заказ и оплата потолков	Навесной потолок	1	A
  Навесной потолок в спальне	«Светлый потолок»	100	A
  Навесной потолок в гостиной	«Светлый потолок»	100	A
  Панельный потолок в кухне	Плиточник Панель	100 6	A A
  Навесной потолок в прихожей	«Светлый потолок»	100	A
  Заказ и оплата кухонного оборудования	Газовая печь Вытяжка Мойка Смеситель	1 1 1 1	A A A A
  Замена кухонного оборудования	Слесарь-водопроводчик	100	B
  Отделка полов в спальне	Плотник Паркет	100 20	A A
  Отделка полов в гостиной	Плотник Паркет	100 20	A A
  Отделка полов на кухне	Плотник Паркет	100 10	A A
  Отделка полов в прихожей	Плотник Паркет	100 15	A A

• Установить различные профили загрузки для ресурса Подсобник.

Задание 7

Разработать функциональную модель декомпозиции учета движения материалов на складе фирмы

Задание 8

Разработать функциональную модель работы информационной системы приемной комиссии института

Задание 9

Разработать функциональную модель декомпозиции работы информационно-справочной службы фирмы

Задание 10

Разработать функциональную модель работы информационной системы городского бюро медико-социальной экспертизы

Задание 11

Разработать функциональную модель декомпозиции работы информационной системы туристической фирмы

Задание 12

Разработать функциональную модель работы офиса продаж оператора сотовой связи

Задание 13

Разработать функциональную модель декомпозиции работы отдела бухгалтерии предприятия

Задание 14

Разработать функциональную модель работы переговорного пункта

Задание 15

Разработать функциональную модель декомпозиции работы регистратуры центральной районной больницы поселка городского типа

Задание 16

Разработать функциональную модель декомпозиции работы отдела кадров предприятия

Задание 17

Разработать функциональную модель работы учебного отдела вуза

Задание 18

Разработать функциональную модель декомпозиции работы деканата факультета вуза

Задание 19

Разработать в среде Rational Rose модель информационной системы страховой компании

Задание 20

Разработать в среде Rational Rose модель информационной системы пункта проката видеофильмов

Задание 21

Разработать в среде Rational Rose модель информационной системы начисления сдельной заработной платы

Задание 22

Разработать в среде Rational Rose модель информационной системы учета транспортных перевозок

Задание 23

Разработать в среде Rational Rose модель информационной системы кассы автостанции

Задание 24

Разработать в среде Rational Rose модель информационной системы учета заявок клиентов торговой фирмы

Задание 25

Разработать в среде Rational Rose модель информационной системы приемной комиссии института

ГЛОССАРИЙ

Иструментальные средства разработки ПО	Средства разработки программного обеспечения – совокупность приемов, методов, методик, а также набор инструментальных программ (компиляторы, прикладные/системные библиотеки и т.д.), используемых разработчиком для создания программного кода Программы, отвечающего заданным требованиям.
RubyWatir	WATIR (англ. Web Application Testing in Ruby) — бесплатная библиотека для интерпретатора Ruby с открытым кодом, позволяющая тестировать веб-приложения. Библиотека WATIR понимает структуру веб-страниц и позволяет получить доступ к её элементам. Библиотека WATIR используется для написания сценариев тестирования веб-страниц. С помощью набора таких сценариев можно автоматизировать процесс тестирования веб-приложений.
Методология ARiS eEPC	ARIS (акроним от англ. Architecture of Integrated Information Systems) — методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций. Продукт и методология принадлежат немецкой компании Software AG как результат поглощения компании IDS Scheer автора методологии Августа-Вильгельма Шеера.
Методология DFD	DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.
Методология IDEF0	IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ).
Отладка	Инструментальные средства отладки призваны дать разработчику максимально ясное представление о том, как работает его программа. И уже искусство разработчика состоит в том, чтобы, используя все имеющиеся в его распоряжении средства, быстро выявить ошибки. Набор средств отладки в Access широк: это и специальное меню Debug (Отладка), и во многом дублирующие его кнопки на панели инструментов, и специальные окна отладки. Далее кратко дается описание каждого средства.
Процессы IDEF3	DEF3 (англ. Integrated DEFinition for Process Description Capture Method) — методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов представляет собой механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие

ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ДИСЦИПЛИНЫ/МДК

Основные источники:

1. ГОСТ 2.105–79 Единая система конструкторской документации. Общие требования к текстовым документам.

2. ГОСТ 2.105–95 Единая система конструкторской документации. Общие требования к текстовым документам.

3. Валитов М. С., Валитов М. М. Инструментальные средства разработки программного обеспечения. М.:Академия ,2013

4. Гамма Э. Приемы объектно-ориентированного проектирования. – СПб.:Питер, 2013

5. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем. М.:Феникс, 2011

6. Голицына О.Л., Попов И.И., Партыка Т. Л. Программное обеспечение. М.:Форум, 2011

7. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Проектирование информационных систем. М.: Национальный открытый университет «ИНТУИТ», 2014

Информационные ресурсы сети Интернет:

1. Интернет – университет http://www.intuit.ru/

2. Программирование на JAVA, C++ http://www.kufas.ru/index.htm

3. Сетевая энциклопедия Википедия http://ru.wikipedia.org/;

4. Федеральный портал «Информационно-коммуникационные технологии в образовании» http://www.ict.edu.ru/;

5. Федеральный портал «Российский портал открытого образования»;

6. Федеральный портал «Российское образование» http://www.edu.ru/;

Журналы:

1. Вестник компьютерных и информационных технологий.

2. Компьютер-Пресс.

3. Мир ПК.

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

5. Практика функционального программирования.

6. Программные продукты и системы.

51