В бизнес процессах выделяют классы процессов тест

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

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

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

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

Тема:
Инструментальные средства разработки
программ. 2015-16 г._ВТиП

A)
Software
eingineering

B)
Инструменты создания программного
обеспечения

C)
Коллектив инженеров-программистов,
разрабатывающих программное обеспечение
для компьютеров

D)
Дисциплина, изучающая применение
строгого систематического количественного
подхода к разработке, эксплуатации и
сопровождению программного обеспечения

E)
Комплекс программ, предназначенный
для решения инженерных задач, связанных
с большим количеством расчетов

F)
Инженерная индустрия применения
прикладного программного обеспечения

G)
Совокупность инженерных методов и
средств создания программного обеспечения

H)
Прикладное программное обеспечение
для решения офисных задач

Верный
ответ: A, D, G

2.
Построение SADT-модели включает в себя
выполнение следующих действий:

A)
Написание программного обеспечения
для разрабатываемой системы по требованиям
заказчика

B)
Сбор информации об объекте и определение
его границ

C)
Определение цели и точки зрения модели,
построение, обобщение и декомпозиция
диаграмм

D)
Представление исследуемой системы в
графическом виде

E)
Представление исследуемого объекта
средствами системного моделирования

F)
Критическая оценка, рецензирование и
комментирование

G)
Разработка, отладка и тестирование
программного обеспечения

H)
Использование графических пакетов для
представления системы в виде модели

Верный
ответ: B, C, F

3.
Моделирование основывается на принципах:

A)
Выбор модели оказывает определяющее
влияние на подход к решению проблемы и
на то, как будет выглядеть это решение

B)
Декомпозиция системы на отдельные
подзадачи

C)
Инкапсуляция и полиморфизма

D)
Децентрализации управления системой

E)
Каждая модель может быть представлена
с различной степенью точности, лучшие
модели — те, что ближе к реальности

F)
Открытой трансформируемой системы

G)
Использование совокупности нескольких
моделей, почти независимых друг от друга

H)
Анализа и синтеза проектирования систем

Верный
ответ: A, E, G

4.
В бизнес-процессах выделяют классы:

A)
Решающие

B)
Регламентирующие

C)
Основные

D)
Поведения системы

E)
Программируемые

F)
Экономические

G)
Обеспечивающие

H)
Управления

Верный
ответ: C, G, H

5.
CASE-средства классифицируются по
следующим признакам:

A)
По применяемым методологиям, моделям
систем и БД

B)
По используемому программному обеспечению

C)
По этапам жизненного цикла программного
обеспечения

D)
По степени интегрированности с СУБД

E)
По уровням детализации и декомпозиции
проектируемой системы

F)
По доступным системам

G)
По используемым языкам программирования

H)
По степени сложности моделируемой
системы

Верный
ответ: A, D, F

6.
К малым интегрированным средствам
моделирования относятся:

A)
ARIS Toolset

B)
Design/IDEF

C)
ERwin

D)
BPwin

E)
Designer/2000

F)
Paradigm Plus

G)
Model Mart

H)
Rational Rose

Верный
ответ:
C, D, G

7.
К средним интегрированным средствам
моделирования относятся:

A)
Rational Rose

B)
Design/IDEF

C)
BPwin

D)
Designer/2000

E)
ARIS Toolset

F)
Model Mart

G)
Paradigm Plus

H)
ERwin

Верный
ответ: B, D, E

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

A)
Объектно-ориентированный анализ

B)
Объектно-ориентированный подкласс

C)
Объектно-ориентированное проектирование

D)
Объектно-ориентированная парадигма

E)
Объектно-ориентированная экспозиция

F)
Объектно-ориентированное моделирование

G)
Объектно-ориентированное программирование

H)
Объектно-ориентированная декомпозиция

Верный
ответ: A, C, G

9.
Основные понятия объектно-ориентированного
подхода:

A)
Обобщение

B)
Полиморфизм

C)
Инкапсуляция

D)
Реализация

E)
Агрегирование

F)
Наследование

G)
Ассоциация

H)
Композиция

Верный
ответ: B, C, F

10.
Главные принципы объектного подхода:

A)
Абстрагирование

B)
Наследование

C)
Ограничение доступа или инкапсуляция

D)
Безграничный доступ

E)
Модульность и иерархия

F)
Агрегирование

G)
Композиция

H)
Обобщение и специализация

Верный
ответ: A, C, E

11.
Дополнительные принципы объектного
подхода:

A)
Реализация

B)
Типизация

C)
Параллелизм

D)
Внедрение

E)
Перпендикулярность

F)
Сохраняемость или устойчивость

G)
Несохраняемость или устойчивость

H)
Динамичность

Верный
ответ: B, C, F

12.
К инструментальным средствам
объектно-ориентированного анализа и
проектирования относятся:

A)
Rational Rose

B)
Model Mart

C)
MS Visio

D)
ARIS

E)
IDEF1X

F)
ERwin

G)
BPwin

H)
JAM

Верный
ответ: A, C, D

13.
BPwin позволяет создавать на диаграмме
DFD типы граничных стрелок:

A)
Обычная граничная стрелка

B)
Специальная стрелка

C)
Внутренняя стрелка

D)
Межстраничная ссылка и тоннельная
стрелка

E)
Внешняя ссылка

F)
Страничная ссылка и теневая стрелка

G)
Контрольная стрелка

H)
Стрелка механизм

Верный
ответ: A, D, E

14.
В BPwin 4.0 отчеты могут быть экспортированы
в распространенные форматы:

A)
Текстовый

B)
Символьный

C)
MS Office

D)
Графический

E)
HTML

F)
Internet Explorer

G)
Acrobat

H)
IBM Rational

Верный
ответ:
A, C, E

15.
Поддерживаемые в RPTwin форматы операторов:

A)
Символ

B)
Текст

C)
Дата

D)
Арифметические

E)
Графический оператор конкатенации (&)

F)
Логические

G)
Текстовый оператор конкатенации (&)

Верный
ответ: D, F, G

16.
Инструментальное средство ERwin позволяет:

A)
Редактировать и отлаживать программы

B)
Проектировать на физическом и логическом
уровне модели данных

C)
Управлять процессом конструирования
ПО

D)
Проектировать диаграммы вариантов
использования и взаимодействий

E)
Проводить процессы прямого и обратного
проектирования баз данных

F)
Управлять процессом трансляции и
отладки программ

G)
Выравнивать модель и содержимое
системного каталога после редактирования

H)
Проектировать контекстные диаграммы
и диаграммы декомпозиции

Верный
ответ: B, E, G

17.
ERwin позволяет создавать модель, имеющую:

A)
Только логический уровень

B)
Абстрактный уровень

C)
Абстрактный и физические уровни

D)
Только физический уровень

E)
Абстрактный и логический уровни

F)
Как логический, так и физический уровень

G)
Концептуальный уровень

H)
Контекстный уровень

Верный
ответ: A, D, F

18.
Для создания моделей ERwin используют
международно-признанные системы
обозначений (нотации):

A)
IDEF0

B)
IDEF1X

C)
IDEF3

D)
DFD

E)
IE

F)
DM

G)
IDEFDFD

H)
IDEF3

Верный
ответ: B, E, F

19.
К основным компонентам диаграммы ERwin
относятся:

A)
Сущности

B)
Переходы

C)
Атрибуты

D)
Классы

E)
Слияния

F)
Разветвления

G)
Использования

H)
Связи

Верный
ответ: A, C, H

20.
Точки зрения организации в ARIS:

A)
Структура внедрения и структура потоков

B)
Организационная структура

C)
Управленческая структура

D)
Поведенческая структура

E)
Функциональная структура

F)
Коммуникационная структура

G)
Структура данных и структура процессов

H)
Обобщенная структура

Верный
ответ: B, E, G

21.
Уровни точки зрения в ARIS — это описание:

A)
Структуры

B)
Требований

C)
Поведения

D)
Разработки

E)
Спецификации

F)
Внедрения

G)
Процессов

H)
Классов

Верный
ответ: B, E, F

22.
«Взгляды» ARIS:

A)
Процессы

B)
Потоки

C)
Функции (с целями)

D)
Данные и организация

E)
Процедуры

F)
Управление и внедрение

G)
Нити

H)
Память

Верный
ответ: A, C, D

23.
MS Visio позволяет создавать схемы, чертежи,
диаграммы с помощью:

A)
Встроенных шаблонов

B)
Панели инструментов

C)
Трафаретов

D)
Графических редакторов

E)
Дополнительного программного обеспечения

F)
Панели рисования

G)
Стандартных модулей

H)
Панели автофигур

Верный
ответ: A, C, G

24.
Язык UML — это:

A)
Язык логического программирования

B)
Унифицированный язык моделирования

C)
Язык для разработки систем искусственного
интеллекта

D)
Unified Modeling Language

E)
Язык управления базами данных

F)
Язык для визуализации, специфицирования,
конструирования и документирования
артефактов программных систем

G)
Язык создания запросов в базах данных

H)
Язык программирования низкого уровня

Верный
ответ: B, D, F

25.
Моделирование в UML позволяет решить
задачи:

A)
Анализа и синтеза систем управления

B)
Разработать и отладить программное
обеспечение

C)
Визуализировать систему в ее текущем
или желательном для нас состоянии

D)
Провести тестирование разработанного
программного обеспечения

E)
Описать структуру или поведение системы;
получить шаблон, позволяющий сконструировать
систему

F)
Смоделировать разрабатываемую
информационную систему

G)
Документировать принимаемые решения,
используя полученные модели

H)
Рассчитать экономическую эффективность
от внедрения программного обеспечения

Верный
ответ: C, E, G

26.
Словарь UML включает строительные блоки:

A)
Зависимости

B)
Сущности

C)
Слияния

D)
Разветвления

E)
Связи

F)
Группировки

G)
Диаграммы

H)
Декомпозиции

Верный
ответ: B, E, G

27.
UML, как язык документирования, помимо
исполняемого кода производит и другие
продукты, включающие:

A)
Требования, архитектуру, проектные
решения

B)
Спецификацию технических средств

C)
Дизайн, исходный код, проектные планы

D)
Требования к уровню квалификации
разработчиков

E)
Набор заданий для тестирования
программного обеспечения

F)
Требования к уровню квалификации
персонала сопровождения

G)
Тесты, прототипы, релизы (версии)

H)
Требования к выбору языка программирования

Верный
ответ: A, C, G

28.
UML включает синтаксические и семантические
правила для:

A)
Агрегации

B)
Тестирования

C)
Имен, областей действия

D)
Сборки

E)
Сопровождения

F)
Видимости, целостности

G)
Вывода из эксплуатации

H)
Исполнения

Верный
ответ: C, F, H

29.
Применение языка UML существенно упрощает
последовательное использование
механизмов:

A)
Спецификации, дополнения

B)
Принятые разделения

C)
Выработки требований

D)
Создания плана работ

E)
Механизмы расширения

F)
Тестирования программного обеспечения

G)
Конструирования ПО

H)
Сопровождения ПО

Верный
ответ: A, B, E

30.
Механизмы расширения UML включают:

A)
Исключения

B)
Стереотипы

C)
Дополнения

D)
Управления

E)
Помеченные значения

F)
Слияния

G)
Ограничения

H)
Объединения

Верный
ответ: B, E, G

31.
Язык UML предназначен для:

A)
Визуализации

B)
Тестирования

C)
Сопровождения

D)
Специфицирования

E)
Снятия с эксплуатации

F)
Конструирования, документирования

G)
Анализа требований

H)
Обучения персонала

Верный
ответ: A, D, F

32.
В объектно-ориентированном моделировании
между классами существуют типы связей:

A)
Слияние

B)
Линейность

C)
Зависимость

D)
Разветвление

E)
Цикличность

F)
Обобщение

G)
Ассоциация

H)
Агрегация

Верный
ответ: C, F, G

33.
В состав графического представления
класса в языке UML входят части:

A)
Отношения

B)
Имя

C)
Связи

D)
Атрибуты

E)
Описание

F)
Сущности

G)
Операции

H)
Механизмы

Верный
ответ: B, D, G

34.
Программное обеспечение делится на
классы:

A)
Системное ПО и прикладное ПО

B)
Системное ПО, прикладное ПО и
инструментальные средства разработки
программ

C)
Операционные системы, прикладное ПО,
утилиты и драйверы

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

E)
Системное ПО и инструментальные
средства разработки программ

F)
Системное ПО, прикладное ПО и системы
программирования

G)
Операционные оболочки, операционные
системы, офисные программы

H)
Системное ПО, прикладное ПО и
инструментальное ПО

Верный
ответ: B, F, H

35.
Инструментальные средства разработки
программ-это:

A)
Средства создания новых программ

B)
Сервисные средства разработки ПО

C)
Аналитические средства разработки ПО

D)
ПО, предназначенное для разработки и
отладки новых программ

E)
Средства отладки ПО

F)
Средства тестирования ПО

G)
Аппаратные и программные инструменты
разработки нового ПО

H)
Технические и инструментальные средства
разработки ПО

Верный
ответ: A, D, G

36.
Программные инструментальные средства
разработки ПО — это:

A)
Программы, позволяющие выполнить все
работы, определенные методологией
проектирования ПО

B)
Системное программное обеспечение,
позволяющее сопровождать офисные
программные пакеты

C)
Средства создания текстовых документов

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

E)
Программное обеспечение для настройки
офисных приложений на условия конкретного
применения

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

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

H)
Средства создания и редактирования
текстовых документов

Верный
ответ: A, D, F

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Программная инженерия:

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

Моделирование в UML позволяет решать задачи:

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

Построение SADT-модели включает в себя выполнение следующих действий:

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

В бизнес-процессах выделяют классы процессов:

• Решающие бизнес-процессы
• Регламентирующие бизнес-процессы
• Основные бизнес-процессы
• Бизнес-процессы поведения системы
• Программируемые бизнес-процессы
• Экономические бизнес-процессы
• Обеспечивающие бизнес-процессы
• Бизнес-процессы управления

CASE-средства классифицируются по следующим признакам:

• По применяемым методологиям и моделям систем и БД
• По используемому программному обеспечению
• По этапам жизненного цикла программного обеспечения
• По степени интегрированности с СУБД
• По уровням детализации и декомпозиции проектируемой системы
• По доступным платформам
• По используемым языкам программирования
• По степени сложности моделируемой системы

К малым интегрированным средствам моделирования относятся:

• ARIS Toolset
• Design/IDEF
• Erwin
• BPwin
• Designer/2000
• Paradigm Plus
• Model Mart
• Rational Rose

К средним интегрированным средствам моделирования относятся:

• Rational Rose
• Design/IDEF
• BPwin
• Designer/2000
• ARIS Toolset
• Model Mart
• Paradigm Plus
• ERwin

Объектно-ориентированная методология (ООМ) включает в себя составные части:

• Объектно-ориентированный анализ
• Объектно-ориентированный подкласс
• Объектно-ориентированное проектирование
• Объектно-ориентированная парадигма
• Объектно-ориентированная экспозиция
• Объектно-ориентированное моделирование
• Объектно-ориентированное программирование
• Объектно-ориентированная декомпозиция

К основным понятиям объектно-ориентированного подхода относятся:

• Обобщение
• Полиморфизм
• Инкапсуляция
• Реализация
• Агрегирование
• Наследование
• Ассоциация
• Композиция

Главные принципы объектного подхода:

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

Дополнительные принципы объектного подхода:

• Реализация
• Типизация
• Параллелизм
• Внедрение
• Перпендикулярность
• Сохраняемость или устойчивость
• Несохраняемость или неустойчивость
• Динамичность

К инструментальным средствам объектно-ориентированного анализа и проектирования относятся:

• Rational Rose
• Model Mart
• MS Visio
• ARIS
• IDEF1X
• Erwin
• BPwin
• JAM

К инструментальным средствам представления функциональных моделей относятся:

• JAM
• Model Mart
• MS Visio
• ARIS
• IDEF0
• Erwin
• BPwin
• Rational Rose

Методологии, поддерживаемые в BPwin:

• IDEF1Х
• IDEF0
• IDEF1
• IDEF3
• IDEFХ
• IDEF5
• DFD
• DFD1Х

Диаграмма IDEF0 может содержать следующие типы диаграмм:

• Диаграмму классов
• Контекстную диаграмму, диаграмму декомпозиции
• Диаграмму компонентов
• Диаграмму дерева узлов
• Диаграмму взаимодействий
• Диаграмму только для экспозиции (FEO)
• Диаграмму последовательности, диаграмму кооперации
• Диаграмму узлов

Уровни логической модели:

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

Внутренние стрелки не входящие в состав диаграммы IDEF0:

• Mechanismoutput
• Output-input
• Mechanisminput
• Output-control
• Output-input feedback
• Output-control feedback
• Output-mechanism
• Control feedbackmechanism

Типы стрелок не входящие в состав диаграммы IDEF0:

• Input
• Editor
• Control
• Properties
• Output
• Mechanism
• Call
• Dictionary

Quick Reports – создание простейших отчетов – позволяет создавать отчеты:

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

BPwin допускает следующие переходы с одной нотации на другую:

• IDEF3 → DFD
• DFD → IDEF0
• IDEF0 → DFD
• DFD → DFD
• IDEF3 → IDEF0
• IDEF0 → IDEF3
• IDEF3 → IDEF3
• DFD → IDEF3

DFD описывает:

• Функции обработки стрелок (arrow)
• Функции обработки информации (работы)
• Внешние ссылки (external references), объекты, сотрудников или отделы, которые участвуют в обработке информации
• Документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации
• Функции обработки внешних ссылок
• Внешние ссылки (external references), таблицы для хранения документов (хранилище данных, data storE)
• Функции обработки документов
• Документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке внешних стрелок

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

• Обычная граничная стрелка
• Специальная стрелка
• Внутренняя ссылка
• Межстраничная ссылка и тоннельная стрелка
• Внешняя ссылка
• Страничная ссылка и теневая стрелка
• Контрольная стрелка
• Стрелка механизм

Создать отчет в BPwin возможно с помощью:

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

В BPwin 4.0 отчеты могут быть экспортированы в распространенные форматы:

• Текстовый
• Символьный
• MS Office
• Графический
• HTML
• Internet Explorer
• Acrobat
• IBM Rational

Поддерживаемые в RPTwin типы операторов:

• Текстовый оператор конкатенации (&)
• Символ
• Текст
• Дата
• Арифметические
• Графический оператор конкатенации (&)
• Логические
• Номер

Инструментальное средство ERwin позволяет:

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

ERwin позволяет создавать модели следующих типов:

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

Для создания моделей ERwin используют международно признанные системы обозначений (нотации):

• IDEF0
• IDEF1X
• IDEF3
• DFD
• IE
• DM
• IDEFDFD
• IDEF3

К основным компонентам диаграммы ERwin относятся:

• Сущности
• Переходы
• Атрибуты
• Классы
• Слияния
• Разветвления
• Использования
• Связи

Точки зрения организации в ARIS:

• Структура внедрения и структура потоков
• Организационная структура
• Управленческая структура
• Поведенческая структура
• Функциональная структура
• Коммуникационная структура
• Структура данных и структура процессов
• Обобщенная структура

Уровни точки зрения в ARIS:

• Описание структуры
• Описание требований
• Описание поведения
• Описание разработки
• Описание спецификации
• Описание внедрения
• Описание процессов
• Описание классов

Методы описания, используемые в ARIS:

• ЕРТ – метод описания потоков
• EPC метод описания процессов
• ERM модель сущность-связь для описания структуры объектов
• ERM модель сущность-связь для описания структуры данных
• ЕРР – метод описания пакетов
• ЕРС – метод описания компонентов
• UML унифицированный язык моделирования
• ЕРТ – метод описания нитей

К основным компонентам инструментов ARIS Toolset относятся:

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

Инструмент разработки программ выбирается на основе:

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

«Взгляды» ARIS:

• Процессы
• Потоки
• Функции (с целями)
• Данные и организация
• Процедуры
• Управление и внедрение
• Нити
• Память

Уровни анализа ARIS для каждого «взгляда»:

• Поведение
• Требования
• Спецификации
• Функции
• Процедуры
• Проверка
• Внедрение
• Тестирование

MS Visio позволяет создавать схемы, чертежи, диаграммы с помощью:

• Встроенных шаблонов
• Панели инструментов
• Трафаретов
• Графических редакторов
• Дополнительного программного обеспечения
• Панели рисования
• Стандартных модулей
• Панели автофигур

Язык UML – это:

• Язык программирования высокого уровня
• Унифицированный язык моделирования
• Язык для разработки систем искусственного интеллекта
• Unified Modeling Language
• Язык управления базами данных
• Язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем
• Язык создания запросов в базах данных
• Язык программирования низкого уровня
• эффективность от внедрения программного обеспечения

Словарь UML включает строительные блоки:

• Зависимости
• Сущности
• Слияния
• Разветвления
• Связи
• Группировки
• Диаграммы
• Декомпозиции

Преимущества объектно-ориентированного подхода:

• Быстрота написания программного кода
• Статичность конфигурации системы
• Возможность многократного использования
• Низкая стоимость проекта
• Восприимчивость к изменениям
• Отсутствие необходимости документирования
• Простота реализуемых моделей
• Реалистичное моделирование

UML, как язык документирования, помимо исполняемого кода производит и другие продукты, включающие:

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

UML включает синтаксические и семантические правила для:

• Агрегации
• Тестирования
• Имен, областей действия
• Сборки
• Сопровождения
• Видимости, целостности
• Вывода из эксплуатации
• Исполнения

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

• Спецификации, дополнения
• Принятые разделения
• Выработки требований
• Создания плана работ
• Механизмы расширения
• Тестирования программного обеспечения
• Конструирования ПО
• Сопровождения ПО

Механизмы расширения UML включают:

• Исключения
• Стереотипы
• Дополнения
• Управления
• Помеченные значения
• Слияния
• Ограничения
• Объединения

Язык UML предназначен для:

• Визуализации
• Тестирования
• Сопровождения
• Специфицирования
• Снятия с эксплуатации
• Конструирования, документирования
• Анализа требований
• Обучения персонала

В объектно-ориентированном моделировании между классами существуют типы связей:

• Слияние
• Линейность
• Зависимость
• Разветвление
• Цикличность
• Обобщение
• Ассоциация
• Агрегация

В состав графического представления класса в языке UML входят части:

• Отношения
• Имя
• Связи
• Атрибуты
• Описание
• Сущности
• Операции
• Механизмы

Программное обеспечение делится на классы:

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

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

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

Аппаратные инструментальные средства разработки ПО – это:

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

Программные инструментальные средства разработки ПО – это:

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

Транслятор – это:

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

Компилятор – это:

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

Интерпретатор:

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

Компоновщик – это:

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

Отладчик:

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

К этапам развития технологии разработки программного обеспечения относятся:

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

«Стихийное» программирование:

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

Моделирование основывается на принципах:

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

Структурный подход к программированию – это:

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

Опорные точки зрения конечных пользователей системы программного обеспечения можно трактовать как:

• Источник информации о системных данных
• Структуру требований
• Источник событий
• Структуру событий
• Структуру представлений
• Получателей требований
• Источник сценариев
• Получателей системных сервисов

Объектный подход к программированию – это:

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

Компонентный подход:

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

Уровни организационного управления при планировании разработки системы:

• Стратегический
• Тактический
• Оперативный
• Основной
• Вспомогательный
• Дополнительный
• Системный
• Аналитический

Управление требованиями:

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

К методам выявления требований относятся:

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

Требования к разрабатываемой системе должны включать:

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

Типы средств, иллюстрирующие цели моделирования системы:

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

ARIS Business Optimizer позволяет:

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

Требования – это:

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

Типичная схема процесса анализа С-требований включает в себя:

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

В классификацию требований к программной системе входят:

• Требования заказчика
• Требования, накладываемые условиями эксплуатации
• Функциональные требования
• Требования, накладываемые аппаратными средствами
• Нефункциональные требования
• Требования предметной области
• Экономические требования
• Требования разработчиков

Процесс определения и анализа требований включает в себя:

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

При аттестации требований выполняются следующие типы проверок документации требований:

• Проверка на совместимость
• Проверка на управляемость
• Проверка правильности требований
• Проверка на непротиворечивость
• Проверка на соответствие
• Проверка на обратимость
• Проверка на полноту и на выполнимость
• Проверка на заменяемость

К методам аттестации требований относится:

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

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

• Статическая модель
• Динамическая модель
• Модель классов
• Модель декомпозиции
• Модель размещения
• Модель состояний
• Модель взаимодействия
• Модель агрегации

Классификация бизнес-процессов включает следующие классы процессов:

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

Типы D-требований:

• Функциональные требования
• Интерфейсные требования
• Нефункциональные требования
• Программные требования
• Обратные требования
• Ограниченные требования
• Производительные требования
• Надежность

Возможные способы организации D-требований:

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

К моделированию относится:

• Система обозначений
• Система атрибутов
• Синтаксис языка моделирования
• Система свойств
• Совокупность поведении объектов
• Совокупность графических объектов
• Семантика языка моделирования
• Совокупность текстовых объектов

Классификация имитационных моделей:

• Статистическая
• Адаптивная
• Статическая или динамическая
• Структурная
• Сетерминированная или стохастическая
• Непрерывная или дискретная
• Объединенная
• Декомпозиционная

Принципы разработки эффективного пользовательского интерфейса:

• Сложность, графика
• Структура, простота
• Связь, обработка
• Видимость, обратная связь
• Невидимость, сложность
• Толерантность, повторное использование
• Первое использование, итерация
• Интеграция, повторение

Принципы разработки программного обеспечения:

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

Типы интерфейсных требований:

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

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

• Поэтапная процедура
• Пошаговая процедура
• Модели и правила
• Критерий и правила
• Тестирование
• Нотаций
• Прецеденты
• Классы

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

• Стандарт организации
• Стандарт конкретного проекта
• Стандарт проектирования
• Стандарт оценки
• Стандарт оформления проектной документации
• Стандарт аудита
• Стандарт оформления разработки
• Стандарт пользовательского интерфейса

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

• Модель административного интерфейса
• Модель процессов
• Модель потоков
• Модель классов
• Модель данных
• Модель пользовательского интерфейса
• Модель компонентов
• Модель узлов

Какие работы включает процесс разработки программного обеспечения:

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

Какие технологии разработки программ используются в современном программировании:

• Визуальные
• Событийные
• Структурные
• Объектно-ориентированные
• Модульные
• Текстуальные
• Графические
• Машинно-ориентированное

Объектно-ориентированное проектирование использует инструментальные средства:

• Model mart
• Rational Rose
• Bpwin
• ARIS
• Idef1X
• Erwin
• MS Visio
• Jam

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

• Jam
• Model Mart
• MS visio
• Erwin
• Idef0
• Aris
• Rational rose
• BPwin

IEEE – это:

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

Ядро знаний SWEBOK – это:

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

Каждая область ядра знаний SWEBOK представляется:

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

К основным областям знаний SWEBOK относятся:

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

К организационным областям знаний SWEBOK относятся:

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

В рамках Rational Unified Process (RUP) набор действий по разработке программ включает этапы:

• Создание структурных схем
• Определения входных, выходных данных
• Согласование стоимости проекта
• Согласования требований с заказчиком
• Создания бизнес-моделей
• Определение требований
• Проектирование, программирование
• Тестирование, внедрение

Этапы разработки консалтинговых проектов включают в себя:

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

Концепции, лежащие в основе модульного программирования:

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

Виды процессов

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

Хаос невозможно автоматизировать. Автоматизация хаоса приводит к еще большему хаосу

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

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

Мы только что описали процесс продажи товара постоянному покупателю и этот процесс можно представить в виде 3 шагов:

1. Обсуждение потребности клиента и подбор товара (менеджер по продажам и клиент)
2. Оформление документов и прием оплаты (бухгалтер и клиент)
3. Сборка товара на складе и его выдача клиенту (кладовщик и клиент)

Схематически это выглядит так:

Только что мы с вами описали сквозной бизнес-процесс.

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

Еще один пример:

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

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

Вложенный бизнес-процесс (подпроцесс) — cамостоятельный бизнес-процесс, инициируемый в ходе выполнения некоторого родительского бизнес-процесса.

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

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

Категории процессов

Категория процесса определяется по его цели и добавочной ценности создаваемой в ходе процесса.

Для определения категории процессов можно пользоваться разными подходами:

• по потребительской ценности для клиента — основные бизнес-процессы;
• по результату деятельности (продукту) — вспомогательные процессы;
• по виду деятельности — процессы управления и вспомогательные процессы.

Для определения того к какой категории относится наш процесс надо ответить на 3 вопроса:

1. С какой целью мы выполняем тот или иной процесс?
2. Какую добавочную ценность мы создаем внутри процесса?
3. Для кого мы выполняем данный процесс, то есть кто клиент процесса?

По ответам на эти вопросы можно выделить три категории  процессов: основные, вспомогательные и управления

Теперь давайте дадим определение того, кто является клиентом процесса и каким (внешним или внутренним)

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

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

1. клиенты;
2. собственники;
3. персонал;
4. поставщики;
5. общество.

Внутренними клиентами процесса являются подразделения (исполнители процессы) использующие результат выполнения (выход) процесса

Основные бизнес-процессы

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

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

Каждый основной бизнес-процесс можно рассматривать как решение определенной задачи или проблемы клиента. Но как определить является ли процесс основным? Для этого есть несколько критериев:

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

Пример процесса «Отгрузка товара клиенту с отстрочкой платежа»

Вспомогательные бизнес-процессы

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

К таким процессам можно отнести:

1. Процессы маркетинга
2. Процессы продаж
3. Процессы работы с сотрудниками
4. Процессы учета (бухгалтерского, налогового, управленческого)
5. Процессы закупки
6. Производственные процессы
7. Складские процессы
8. Логистические процессы
9. Процессы IT-сопровождения
10. Административно-хозяйственные процессы
11. …

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

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

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

Процессы управления

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

Выделение в качестве объектов описания процессов управления  требует измерения их эффективности и результативности. Но для большинства организаций (до 300-500 сотрудников) выделение таких процессов будет нецелесообразным и большинство таких процессов будут выступать в роли вспомагательных.

Выводы

Классификация бизнес-процессов на предприятии важна по нескольким причинам:

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

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

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

Главная / Менеджмент /
Моделирование бизнес-процессов / Тест 7

Каков основной недостаток функционального подхода?

Система управления по Тейлору

Что такое процессный подход к управлению?

Стандартное определение бизнес-процесса:

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

В соответствии со стандартом организация - это:

С точки зрения процессного подхода менеджмент - это:

Непрерывная серия задач, выполняемых с целью создания выхода с целью удовлетворения запросов внутренних или внешних клиентов - это определение:

Хорошая связь «начальник-подчиненный»:

Функции работника выходят за рамки регламентированных трудовых обязанностей - это:

В чем суть концепции процессного управления BPM (Business Process Management)?

Что служит основой для описания деятельности?

Эмерджентность - это:

Референтная модель:

Укажите количество фаз цикла Шухарта-Деминга

Как классифицируются процессы верхнего уровня?

Референтная модель отражает: 

Первичный вход процесса

Вторичные выходы процесса

Владелец процесса

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

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

Понятие «бизнес-процесс» определяется, как ...

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

BPM заключается в

Эмерждентность заключается в

Вертикальное сжатие процесса заключается в

Количество основных процессов 13-процессной эталонной модели

Количество фаз цикла Шухарта-Деминга

Количество взглядов на организацию в «доме» методологии ARIS

Количество уровней описания (моделирования) деятельности от верхнего уровня процессов к их подгруппам и процедурам организации в методологии ARIS