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

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

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

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

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

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

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

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

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

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

Мы только что описали процесс продажи товара постоянному покупателю и этот процесс можно представить в виде 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. Потребуется выстраивание всех бизнес-процессов в гибкую систему, чтобы они не дублировали друг друга, и одновременно с тем не было никаких аспектов деятельности предприятия, не охваченных никакими бизнес-процессами.

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

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

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

Как видно из рисунка, бизнес-процессы
организации могут быть сгруппированы
по разным признакам.

По протеканию во времени бизнес-процессы
организации могут быть:

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

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

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

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

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

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

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

Рисунок 2.8 – Классификация
бизнес-процессов

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

Согласно стандарту ГОСТ Р ИСО 9001:2001 и
модели системы менеджмента качества
основанной на процессном подходе, можно
выделить:

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

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

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

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

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

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

Управление

Управление

Развитие

Доходы

Обеспечение

Обеспечение

Рисунок 2.9 – Классификация бизнес-процессов

• Основные бизнес-процессы — генерируют
  доходы компании;

• Обеспечивающие бизнес-процессы —
  поддерживают инфраструктуру компании,

• Бизнес-процессы управления — управляют
  компанией,

• Бизнес-процессы развития — развивают
  компанию.

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

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

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

К группе основных относят следующие
бизнес-процессы:

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

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

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

• Процессы, за которые внешний клиент
  готов платить деньги.

Последнее определение предложили
классики реинжиниринга бизнес-процессов
М. Хаммер и Д. Чампи. Ими было предложено
использовать данное определение как
один из методов определения, того —
является ли процесс основным или нет.
Согласно этому методу у внешнего клиента
нужно спросить готов ли тот платить
деньги за данный бизнес-процесс или
нет. Если клиент ответит «да», значит
данный процесс является основным, если
«нет», то процесс относят к одной из
трех оставшихся групп.

Какова отличительная особенность
основных бизнес-процессов, какова их
роль, каково их предназначение? (Таблица
2.4) Отличительной особенностью основных
процессов является то, что они прямым
образом участвуют в реализации
бизнес-направлений компании. В большинстве
случаев перечень основных бизнес-процессов
представляет зеркальное отражение
дерева бизнес-направлений компании.
Далее это будет рассмотрено на практических
примерах.

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

Таблица 2.4 – Характеристики основных
бизнес-процессов

Давайте рассмотрим пример построения
дерева основных бизнес-процессов на
примере компании «Эврика». Первый
вариант дерева бизнес-процессов состоит
из следующих элементов:

• Закупка.

  • Закупка чая;

  • Закупка одежды;

  • Закупка мебели.

• Хранение.

• Хранение чая;

• Хранение одежды;

• Хранение мебели.

• Продажа.

  • Продажа чая;

  • Продажа одежды;

  • Продажа мебели.

При построении данного варианта дерева
основных бизнес-процессов на первом
уровне был применен критерий декомпозиции
— функция», а на втором уровне – продукт
(Рисунок 2.10).

1-ый вариант
декомпозиции

Критерий
декомпозиции:

Функция

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

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

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

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

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

Внешние и внутренние бизнес-процессы

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

Классификация бизнес-процессов по их роли

Существуют бизнес-процессы функциональные и структурные.

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

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

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

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

Основные напрямую связаны с производством товаров и услуг. Они:

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

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

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

Вспомогательные (обеспечивающие) бизнес-процессы подразумевают управление:

• финансами
• персоналом
• логистикой

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

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

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

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

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

Не менее важным моментом является выработка стратегии дальнейшего развития компании.

Фактически, управление состоит из планирования и контроля за тем, как и насколько достигаются эти планы.

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

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

Один процесс – один руководитель

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

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

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

Бизнес-процессов не должно быть слишком много

Оптимальным вариантом является такой, когда одновременно существует не более 7 (плюс-минус 2) основных бизнес-процессов, и около 5 дополнительных.

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

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

Формализация и классификация бизнес-процессов как шаг к внедрению системы BPM

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

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