- Главная
- Разное
- Дизайн
- Бизнес и предпринимательство
- Аналитика
- Образование
- Развлечения
- Красота и здоровье
- Финансы
- Государство
- Путешествия
- Спорт
- Недвижимость
- Армия
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
ТЕМА 2. Технологии проектирования информационных систем презентация
Содержание
- 1. ТЕМА 2. Технологии проектирования информационных систем
- 2. Начальная стадия ЖЦ ИС Существуют следующие наименования
- 3. Проектирование Стадии
- 4. Методы анализа предметной области Методы изучения и
- 5. Этап сбора данных Основные участники: бизнес-аналитики; руководство
- 6. Основные работы I этапа Основной результат – ответ на вопрос: «Стоит ли продолжать данный проект?»
- 7. Понятие требования Требования – это исходные данные,
- 8. Строжайшее и единственное правило построения систем программного
- 9. Классификация требований Нефункциональные требования
- 10. Бизнес- требования Назначение: Формулировка цели проектирования
- 11. Требования пользователей Назначение: определяют набор пользовательских
- 12. Функциональные требования Назначение: определяют способы реализации
- 13. Нефункциональные требования – это требования к характеру
- 14. Особенности нефункциональных требований Заказчики часто забывают про
- 15. Категории нефункциональных требований Основные: Удобство использования Надежность
- 16. Требование «Удобство использования»
- 17. Требование «Надежность»
- 18. Требование «Производительность»
- 19. Требование «Эксплуатационная пригодность» Тестируемость Приспособляемость Совместимость
- 20. Дополнительные требования
- 21. Источники требований Федеральное и муниципальное отраслевое законодательство
- 22. Заинтересованные лица эксперты предметной области, авторы документов,
- 23. Использование требований при разработке ИС
- 24. Свойства требований Полнота Ясность (краткость, простота,
- 25. Полнота требования означает, что текст требования не
- 26. Ясность – недвусмысленность, определенность, однозначность спецификаций.
- 27. Требование 1 (неясное): Система не должна
- 28. Требование 2 (неясное): Иногда пользователь будет
- 29. Верифицируемость – пригодность к проверке. Тестировщики должны
- 30. Необходимым считается требование, невыполнение которого угрожает работоспособности
- 31. Осуществимость (выполнимость) Требование должно быть выполнимо в
- 32. Требование считается элементарным, если оно содержит только
- 33. Требование является независимым, если для его понимания
- 34. Корректность – согласованность, непротиворечивость. Требования не должны
- 35. Прямые конфликты возникают, когда ожидается различное поведение
- 36. Каких требований не должно быть Спецификация
- 37. Атрибуты требований Уникальный идентификатор. Приоритет,
- 38. Методы сбора требований Интервью Анкетирование Наблюдение Самостоятельное описание требований Совместные семинары Прототипирование
- 39. Интервью Подготовка – планирование процесса опроса и
- 40. Интервью Подготовка – планирование процесса опроса и
- 41. Анкетирование Преимущество: наименее затратный способ извлечения информации.
- 42. Наблюдение Применяется для непосредственного сбора сведений о
- 43. Самостоятельное описание требований Используется при наличии: хорошо
- 44. Совместные семинары Групповое обсуждение по методу
- 45. Прототипирование Прототипирование является ключевым компонентом технологии быстрой
- 46. SWOT-анализ Stregths, Weaknesses, Opportunities, Threats) (сильные стороны,
- 47. Пример SWOT-таблицы
- 48. Схема Захмана
- 50. ISA (Information Systems Architecture ) Ответственный за
- 51. Методы детального анализа предметной области Методика обследования бизнес-процессов
- 52. I этап Цель этапа: Зафиксировать (идентифицировать) структуру
- 53. II этап Цель этапа: Выявить общую структурную
- 54. Содержание отчета по II этапу Структура организации.
- 55. III этап Цель этапа: зафиксировать необходимые детали
- 56. Положение о бизнес-процессе Название бизнес-процесса. Условия
- 57. Положение о документообороте Схема документооборота Номер
Начальная стадия ЖЦ ИС Существуют следующие наименования начальной стадии жизненного цикла ИС: Формирование концепции Предпроектная стадия Информационное обследование Анализ предметной области Анализ требований к системе Основная задача обследования – оценка реального
Слайд 1ТЕМА 2.
Технологии проектирования информационных систем
Лекция 7-8.
Методы анализа предметной области
Слайд 2Начальная стадия ЖЦ ИС
Существуют следующие наименования начальной стадии жизненного цикла ИС:
Формирование
концепции
Предпроектная стадия
Информационное обследование
Анализ предметной области
Анализ требований к системе
Основная задача обследования – оценка реального объема проекта по созданию ИС, ее целей и задач, состава функциональных подсистем и возможностей реализации проекта.
Предпроектная стадия
Информационное обследование
Анализ предметной области
Анализ требований к системе
Основная задача обследования – оценка реального объема проекта по созданию ИС, ее целей и задач, состава функциональных подсистем и возможностей реализации проекта.
Слайд 3Проектирование
Стадии ЖЦ
по ISO/IEC 15288:2002
Формирование концепции
Разработка
Реализация
Эксплуатация
Поддержка
Снятие с эксплуатации
по ГОСТ 34.601-90
Формирование требований
к АС
Разработка концепции АС.
Техническое задание.
Эскизный проект.
Технический проект.
Рабочая документация.
Ввод в действие.
Сопровождение АС
Разработка концепции АС.
Техническое задание.
Эскизный проект.
Технический проект.
Рабочая документация.
Ввод в действие.
Сопровождение АС
Анализ требований
Реализация
Внедрение
Эксплуатация
Слайд 4Методы анализа предметной области
Методы изучения и анализа фактического состояния экономического объекта
и перспектив его развития
Методы сбора требований пользователей;
SWOT-анализ;
Схема Захмана;
Метод ISA
Методы детального анализа предметной области
Методы формирования нового заданного состояния экономического объекта.
Методы сбора требований пользователей;
SWOT-анализ;
Схема Захмана;
Метод ISA
Методы детального анализа предметной области
Методы формирования нового заданного состояния экономического объекта.
Слайд 5Этап сбора данных
Основные участники:
бизнес-аналитики;
руководство предприятия-заказчика;
ключевые пользователи будущей ИС;
эксперты
Объекты изучения:
организационная и функциональная
структура;
технико-экономические характеристики;
материальные и информационные потоки между подразделениями и внутри них;
методы планирования, учета и управления.
технико-экономические характеристики;
материальные и информационные потоки между подразделениями и внутри них;
методы планирования, учета и управления.
Слайд 6Основные работы I этапа
Основной результат – ответ на вопрос:
«Стоит ли продолжать
данный проект?»
Слайд 7Понятие требования
Требования – это исходные данные, на основании которых проектируются и
создаются ИС.
Требование – условие или особенность, которой должна удовлетворять ИС:
функциональность, необходимая заказчику или пользователю для разрешения проблем или получения прибыли;
функциональность, которая должна быть реализована в системе в соответствии с официальным документом;
ограничение, наложенное заинтересованным лицом.
Требование – условие или особенность, которой должна удовлетворять ИС:
функциональность, необходимая заказчику или пользователю для разрешения проблем или получения прибыли;
функциональность, которая должна быть реализована в системе в соответствии с официальным документом;
ограничение, наложенное заинтересованным лицом.
Слайд 8Строжайшее и единственное правило построения систем программного обеспечения (ПО) - решить
точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.
Ф. Брукс
Слайд 10Бизнес- требования
Назначение:
Формулировка цели проектирования ИС
Где описываются:
Концепция системы (границы и
содержание проекта)
Пример:
система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза.
Пример:
система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза.
Слайд 11Требования пользователей
Назначение:
определяют набор пользовательских задач, которые должна решать ИС, а
также способы (сценарии) их решения в системе.
Где описываются:
Диаграммы вариантов использования, сценарии взаимодействия, функциональные модели в различных нотациях
Пример:
система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение.
Где описываются:
Диаграммы вариантов использования, сценарии взаимодействия, функциональные модели в различных нотациях
Пример:
система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение.
Слайд 12Функциональные требования
Назначение:
определяют способы реализации ИС.
Где описываются:
системные спецификации (system
requirement specification, SRS)
Пример:
заказ может быть создан, отредактирован, удален и перемещен с участка на участок.
Пример:
заказ может быть создан, отредактирован, удален и перемещен с участка на участок.
Слайд 13Нефункциональные требования – это требования к характеру поведения системы
Удобство использования
Надежность
Производительность
Эксплуатационная пригодность (способность к сопровождению)
Интерфейс пользователя,
Аппаратные интерфейсы,
Программные интерфейсы,
Коммуникационные интерфейсы
Требования, выдвигаемые ИС к среде своего функционирования (объем требуемой памяти, требования к выбору операционной системы)
Слайд 14Особенности нефункциональных требований
Заказчики часто забывают про эти требования и не предоставляют
их, пока не будут заданы соответствующие вопросы.
Заказчики обычно не в курсе стоимости улучшения определенных возможностей.
У нетехнических пользователей часто возникают проблемы с пониманием смысла некоторых технических требований.
Некоторые требования являются сложными в измерении, например: «Система должна быть простой для обучения».
Заказчики обычно не в курсе стоимости улучшения определенных возможностей.
У нетехнических пользователей часто возникают проблемы с пониманием смысла некоторых технических требований.
Некоторые требования являются сложными в измерении, например: «Система должна быть простой для обучения».
Слайд 15Категории нефункциональных требований
Основные:
Удобство использования
Надежность
Производительность
Эксплуатационная пригодность
Дополнительные:
Ограничение на дизайн
Требования реализации
Требования интерфейса
Требования аппаратного
обеспечения
Требования документации
Требования лицензий и юридических норм
Требования документации
Требования лицензий и юридических норм
Слайд 19Требование «Эксплуатационная пригодность»
Тестируемость
Приспособляемость
Совместимость
Способность к обновлению
Расширяемость
Переносимость
Возможность многократного применения
Взаимодействие с другими ИС
Способность
к аудиту
Способность к локализации
Способность к локализации
Слайд 21Источники требований
Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
Нормативное обеспечение организации
(регламенты, положения, уставы, приказы)
Текущая организация деятельности объекта автоматизации
Модели деятельности (диаграммы бизнес-процессов)
Журналы использования существующих программно-аппаратных систем
Конкурирующие программные продукты
Заинтересованные лица
Текущая организация деятельности объекта автоматизации
Модели деятельности (диаграммы бизнес-процессов)
Журналы использования существующих программно-аппаратных систем
Конкурирующие программные продукты
Заинтересованные лица
Слайд 22Заинтересованные лица
эксперты предметной области, авторы документов, собственники сайтов
Лица, вовлеченные в процесс
настройки и сопровождения системы
(хостинговая компания, справочная служба)
(хостинговая компания, справочная служба)
бизнес-аналитики, дизайнеры, кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению
Государственные
органы контроля,
поставщики стандартов
и регламентов
Слайд 24Свойства требований
Полнота
Ясность (краткость, простота, точность, недвусмысленность)
Верифицируемость (тестируемость, возможность проверки)
Необходимость и
полезность при эксплуатации
Осуществимость (выполнимость, правдоподобность, реализуемость)
Элементарность и трассируемость (прослеживаемость)
Независимость от других требований (атомарность),
Независимость от реализации (абстрактность)
Корректность (согласованность, непротиворечивость)
Постоянство (стабильность).
Осуществимость (выполнимость, правдоподобность, реализуемость)
Элементарность и трассируемость (прослеживаемость)
Независимость от других требований (атомарность),
Независимость от реализации (абстрактность)
Корректность (согласованность, непротиворечивость)
Постоянство (стабильность).
Слайд 25Полнота требования означает, что текст требования не требует дополнительной детализации, то
есть, в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
Различают полноту отдельного требования и полноту системы требований.
Различают полноту отдельного требования и полноту системы требований.
Слайд 26Ясность – недвусмысленность, определенность, однозначность спецификаций.
Требование обладает свойством ясности, если
оно сходным образом воспринимается всеми заинтересованными лицами.
Слайд 27Требование 1 (неясное):
Система не должна принимать слишком короткие пароли.
Требование 1
(ясное):
Система не должна принимать пароли менее 8 символов. Если пользователь вводит менее 8 символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.
Система не должна принимать пароли менее 8 символов. Если пользователь вводит менее 8 символов при выборе пароля, сообщение об ошибке должно информировать пользователя о необходимом исправлении пароля.
Слайд 28Требование 2 (неясное):
Иногда пользователь будет вводить Код Аэропорта, который система
будет распознавать. Но иногда код можно заменить близлежащим городом, и тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название города.
Требование 2 (ясное):
Система должна идентифицировать аэропорт на основании Кода Аэропорта или Названия Города.
Слайд 29Верифицируемость – пригодность к проверке. Тестировщики должны иметь возможность проверить, было
ли требование реализовано корректно.
Треб.1: Функция поиска должна позволять пользователю искать заказ на основе Фамилии, Имени, Даты, и т.д.
Треб. 2 Система должна препятствовать одновременному доступу большого числа пользователей.
Треб.3: Код аэропорта должен быть введен.
Треб.1: Функция поиска должна позволять пользователю искать заказ на основе Фамилии, Имени, Даты, и т.д.
Треб. 2 Система должна препятствовать одновременному доступу большого числа пользователей.
Треб.3: Код аэропорта должен быть введен.
Слайд 30Необходимым считается требование, невыполнение которого угрожает работоспособности или эффективности ИС.
В
требовании нет необходимости, если:
Ни одному заинтересованному лицу требование не нужно.
Пример. Пользователь должен иметь возможность просмотра карты аэропорта.
Удаление требования не повлияет на систему, т.к. оно не предоставляет никакой новой информации:
Пример. Все требования, указанные в документе Концепция, должны быть реализованы и протестированы.
Полезность при эксплуатации – требование, выполнение которого повышает эргономические качества продукта.
Ни одному заинтересованному лицу требование не нужно.
Пример. Пользователь должен иметь возможность просмотра карты аэропорта.
Удаление требования не повлияет на систему, т.к. оно не предоставляет никакой новой информации:
Пример. Все требования, указанные в документе Концепция, должны быть реализованы и протестированы.
Полезность при эксплуатации – требование, выполнение которого повышает эргономические качества продукта.
Слайд 31Осуществимость (выполнимость)
Требование должно быть выполнимо в рамках существующих ограничений, таких как
время, деньги и доступные ресурсы.
Пример: Система должна иметь интерфейс на естественном языке, который будет понимать команды на русском языке.
Пример: Система должна иметь интерфейс на естественном языке, который будет понимать команды на русском языке.
Выполнимость требования
определяется разумным
балансом между степенью
необходимости и требуемыми
ресурсами.
Слайд 32Требование считается элементарным, если оно содержит только один трассируемый элемент, который
дает возможность отследить связь между ним и другими элементами информационной системы.
Пример: Система должна предоставлять возможность бронировать рейс, покупать билет, бронировать номер в гостинице, бронировать машину, а также предоставлять информацию о развлечениях.
Пример: Система должна предоставлять возможность бронировать рейс, покупать билет, бронировать номер в гостинице, бронировать машину, а также предоставлять информацию о развлечениях.
Слайд 33Требование является независимым, если для его понимания не нужно знать другие
требования.
Пример Треб.1: Список доступных рейсов должен включать номер рейса, время отправления и время прибытия для каждого отрезка пути.
Треб.2: Он должен быть отсортирован по ценам.
Требования должны быть независимыми от реализации
Пример: Информация должна храниться в текстовом файле.
Пример Треб.1: Список доступных рейсов должен включать номер рейса, время отправления и время прибытия для каждого отрезка пути.
Треб.2: Он должен быть отсортирован по ценам.
Требования должны быть независимыми от реализации
Пример: Информация должна храниться в текстовом файле.
Слайд 34Корректность – согласованность, непротиворечивость. Требования не должны противоречить требованиям своего уровня
иерархии и требованиям "родительского" уровня.
Если требование содержит факты, эти факты должны быть достоверны:
Треб.1: Цена заказа должна включать все соответствующие платежи (включая стоимость пересылки – 200 руб.)
Требование считается корректным, если не существует конфликтов между ним и другими требованиями.
Если требование содержит факты, эти факты должны быть достоверны:
Треб.1: Цена заказа должна включать все соответствующие платежи (включая стоимость пересылки – 200 руб.)
Требование считается корректным, если не существует конфликтов между ним и другими требованиями.
Слайд 35Прямые конфликты возникают, когда ожидается различное поведение системы в одной и
той же ситуации:
Треб.1(конфл.): Дата должна отображаться в формате ММ/ДД/ГГ.
Треб.1 (конфл.): Дата должна отображаться в формате ДД/ММ/ГГ.
Косвенный конфликт возникает, когда требования описывают разную функциональность, но выполнить оба этих требования одновременно невозможно:
Треб.1: Система должна иметь интерфейс на естественном языке.
Треб.2: Система должна быть разработана в течение трех месяцев.
Треб.1(конфл.): Дата должна отображаться в формате ММ/ДД/ГГ.
Треб.1 (конфл.): Дата должна отображаться в формате ДД/ММ/ГГ.
Косвенный конфликт возникает, когда требования описывают разную функциональность, но выполнить оба этих требования одновременно невозможно:
Треб.1: Система должна иметь интерфейс на естественном языке.
Треб.2: Система должна быть разработана в течение трех месяцев.
Слайд 36Каких требований не должно быть
Спецификация требований не должна содержать деталей
проектирования или реализации.
Требования должны отвечать на вопрос: "что должна делать система", абстрагируясь от вопроса "как она это должна делать".
Требования должны отвечать на вопрос: "что должна делать система", абстрагируясь от вопроса "как она это должна делать".
Слайд 37Атрибуты требований
Уникальный идентификатор.
Приоритет, важность реализации с точки зрения пользователей.
Критичность для построения и успешности системы с точки зрения аналитиков.
Осуществимость с точки зрения готовности пользователей к новой функции, имеющихся технологий и стоимости реализации.
Риски (высокой стоимости, последствий использования для окружающей среды и пользователей, конфликтов со стандартами и законодательством).
Источник (кто предложил это требование).
Тип требования.
Слайд 38Методы сбора требований
Интервью
Анкетирование
Наблюдение
Самостоятельное описание требований
Совместные семинары
Прототипирование
Слайд 39Интервью
Подготовка – планирование процесса опроса и выработка стратегии управления этим процессом.
выбор нужного собеседника;
договоренность о встрече;
формирование предварительной программы встречи;
изучение сопутствующей информации;
согласование плана опроса с группой проектирования.
Проведение опроса.
Завершение.
Слайд 40Интервью
Подготовка – планирование процесса опроса и выработка стратегии управления этим процессом.
Проведение опроса.
Завершение. Опрос нужно завершать, если:
получен достаточно большой объем информации;
поступает большой объем неподходящей информации;
информация перестает усваиваться;
эксперт начинает уставать;
с экспертом возник конфликт.
Слайд 41Анкетирование
Преимущество: наименее затратный способ извлечения информации.
Недостаток: наименее эффективный способ сбора данных.
В
анкетах могут использоваться следующие виды вопросов:
Многоальтернативные вопросы.
Рейтинговые вопросы.
Вопросы с ранжированием.
Многоальтернативные вопросы.
Рейтинговые вопросы.
Вопросы с ранжированием.
Слайд 42Наблюдение
Применяется для непосредственного сбора сведений о параметрах, признаках и объектах в
соответствующей предметной области.
Различают пассивное и активное наблюдение.
Достоинство: сбор информации, которую невозможно получить путем опроса или изучения документации.
Недостаток: наблюдатель «вносит помехи» в результаты измерений.
Различают пассивное и активное наблюдение.
Достоинство: сбор информации, которую невозможно получить путем опроса или изучения документации.
Недостаток: наблюдатель «вносит помехи» в результаты измерений.
Слайд 43Самостоятельное описание требований
Используется при наличии:
хорошо структурированной документации, описывающей устоявшиеся в организации
бизнес-процессы;
большого опыта разработки ИС в схожих предметных областях.
Достоинство: предварительное формирование требований происходит в удобном для аналитика режиме.
Недостаток: возможность пропуска важной информации, связанной с выполнением бизнес-процессов в реальной жизни и не вошедшей в документы.
большого опыта разработки ИС в схожих предметных областях.
Достоинство: предварительное формирование требований происходит в удобном для аналитика режиме.
Недостаток: возможность пропуска важной информации, связанной с выполнением бизнес-процессов в реальной жизни и не вошедшей в документы.
Слайд 44Совместные семинары
Групповое обсуждение по методу «мозгового штурма» проводится с целью
обобщения и обсуждения важных для решения проблем вопросов.
Недостаток: одна из наиболее затратных стратегий сбора данных.
Достоинства: быстрота принятия решений, снижение количества ошибок, выработка нетривиальных идей.
Недостаток: одна из наиболее затратных стратегий сбора данных.
Достоинства: быстрота принятия решений, снижение количества ошибок, выработка нетривиальных идей.
Слайд 45Прототипирование
Прототипирование является ключевым компонентом технологии быстрой разработки приложений (RAD – Rapid
Application Development).
RAD базируется на следующих принципах:
эволюционное прототипирование;
использование CASE-средств, обладающих возможностями прямого и обратного проектирования и автоматической генерации кода;
высококвалифицированные специалисты;
совмещение живого общения с разработкой в режиме on-line;
жесткие временные рамки.
RAD базируется на следующих принципах:
эволюционное прототипирование;
использование CASE-средств, обладающих возможностями прямого и обратного проектирования и автоматической генерации кода;
высококвалифицированные специалисты;
совмещение живого общения с разработкой в режиме on-line;
жесткие временные рамки.
Слайд 46SWOT-анализ
Stregths, Weaknesses, Opportunities, Threats) (сильные стороны, слабые стороны, возможности, угрозы)
Этапы SWOT-анализа:
определение
уникального характера организации, ее миссии;
определение внутренних сильных и слабых сторон организации по отдельным направлениям деятельности;
определение внешних возможностей и угроз;
определение практических приоритетных целей на среднесрочный период.
определение внутренних сильных и слабых сторон организации по отдельным направлениям деятельности;
определение внешних возможностей и угроз;
определение практических приоритетных целей на среднесрочный период.
Слайд 50ISA (Information Systems Architecture )
Ответственный за ИТ у заказчика ИС –
определяет границы ИС;
Представитель высшего руководства заказчика ИС – определяет соответствие ИС задачам данной организации;
Ответственный представитель исполнителя (проектировщик) – определяет физическую модель системы, ее основные компоненты;
Представитель исполнителя (конструктор) – обеспечивает предложения по детализации технологических решений;
Поставщик (субподрядчик) – поставляет компоненты системы.
Представитель высшего руководства заказчика ИС – определяет соответствие ИС задачам данной организации;
Ответственный представитель исполнителя (проектировщик) – определяет физическую модель системы, ее основные компоненты;
Представитель исполнителя (конструктор) – обеспечивает предложения по детализации технологических решений;
Поставщик (субподрядчик) – поставляет компоненты системы.
Почему объект существует? (Мотивация существования организации).
Кто работает с объектом? (Кто будут пользователи?)
Что представляет собой объект автоматизации? (С какими данными будет работать ИС?)
Как функционирует объект автоматизации? (Какие бизнес-процессы присутствуют, какие задачи решаются?)
Где расположен объект автоматизации? (Компоненты ИС и их размещение)
Когда с объектом что-либо происходит? (Изменение данных, распределение событий и состояний во времени)
Респонденты
Вопросы
Метод «5х6»
Слайд 52I этап
Цель этапа: Зафиксировать (идентифицировать) структуру организации и общие закономерности ее
деятельности.
Запрос документов,
регламентирующих
деятельность
организации
Систематизация
информации
документы, определяющие функционирование организации в целом;
документы, определяющие направления ее деятельности;
документы, определяющие правила и принципы осуществления стратегического управления;
стратегический план развития организации.
Общие принципы функционирования организации.
Направления деятельности.
Правила взаимодействия с внешними организациями.
Перечень основных бизнес-процессов.
Отчет
Слайд 53II этап
Цель этапа: Выявить общую структурную схему бизнес-процессов организации, зафиксировать функции
подразделений.
Предварительный
запрос информации о
функционировании
подразделений
Формирование
отчета
Название подразделения.
Документы, определяющие условия работы подразделения и выполнение конкретных функций (регламенты, должностные инструкции, кодексы).
Функции подразделения.
Документы других подразделений (отчеты, справки, заказы, заявки и т.п.), поступающие в данное подразделение, необходимые для его работы.
Документы, появляющиеся в результате работы подразделения, которые используются в других подразделениях, передаются поставщикам, клиентам или архивируются.
Запросная
форма
Подготовка
положения
о классификации
бизнес-процессов
Слайд 54Содержание отчета по II этапу
Структура организации.
Классификация бизнес-процессов.
Описание деятельности подразделений:
название
подразделения;
документы, регламентирующие деятельность;
выполняемые функции;
входящие документы;
исходящие документы;
ревизия имеющихся организационных документов;
результаты деятельности подразделения.
документы, регламентирующие деятельность;
выполняемые функции;
входящие документы;
исходящие документы;
ревизия имеющихся организационных документов;
результаты деятельности подразделения.
Слайд 55III этап
Цель этапа: зафиксировать необходимые детали бизнес-процессов.
Запрос информации о
выполнении
бизнес-процесса
Разработка
положений
о
документообороте
в подразделениях
документообороте
в подразделениях
Первоначальные данные или информация, с поступления которых начинается выполнение функции
Данные, необходимые для выполнения функции. Их источники;
Данные, формируемые при выполнении функции. Их получатели;
Сотрудники организации, а также клиенты, поставщики и иные внешние организации, участвующие в выполнении функции;
Материалы и другие материальные ценности, необходимые и потребляемые при выполнении функции;
Материалы и другие материальные ценности, получаемые в результате выполнения функции;
Степень важности процесса в рамках работы подразделения.
Проблемы, возникающие при выполнении процесса:
насколько критичны (влияют на общую деятельность организации; влияют на функционирование отдела; не значительны);
зависят от работы: сотрудников/смежных подразделений/ поставщиков/клиентов,
неблагоприятно влияют на: стоимость/время/качество выполнения процесса.
Время выполнения процесса.
Последовательность действий выполнения процесса.
Подготовка
положения
о бизнес-процессах
Слайд 56Положение о бизнес-процессе
Название бизнес-процесса.
Условия начала выполнения бизнес-процесса.
Документы и данные,
необходимые для выполнения бизнес-процесса и их источники.
Документы, создаваемые в результате выполнения бизнес-процесса и их получатели.
Действующие лица, принимающие участие в выполнении бизнес-процесса.
Материальные ценности, необходимые для выполнения бизнес-процесса, если таковые есть.
Материальные ценности – результат выполнения бизнес-процесса, если таковые есть.
Результаты выполнения бизнес-процесса (кроме вошедших в п.7).
Цель данного бизнес-процесса, его место и роль в общих задачах (процессах) компании.
Проблемы, возникающие при выполнении бизнес-процесса.
Нештатное завершение (выполнение) бизнес-процесса.
Последовательность действий выполнения бизнес-процесса.
Документы, создаваемые в результате выполнения бизнес-процесса и их получатели.
Действующие лица, принимающие участие в выполнении бизнес-процесса.
Материальные ценности, необходимые для выполнения бизнес-процесса, если таковые есть.
Материальные ценности – результат выполнения бизнес-процесса, если таковые есть.
Результаты выполнения бизнес-процесса (кроме вошедших в п.7).
Цель данного бизнес-процесса, его место и роль в общих задачах (процессах) компании.
Проблемы, возникающие при выполнении бизнес-процесса.
Нештатное завершение (выполнение) бизнес-процесса.
Последовательность действий выполнения бизнес-процесса.
Слайд 57Положение о документообороте
Схема документооборота
Номер (код) документа
Наименование документа
Источник документа (откуда приходит)
Получатель
(получатели) документа
Информация, документы, используемые при формировании документа
Операции, выполняемые над документом
Ответственный за выполнение операций над документом
Табель документооборота
Номер документа
Наименование документа
Тип документа (Внутренний/внешний; Входящий/исходящий; транзитный)
Частота документа за временной период
Ответственный за документ (сотрудник или отдел)
Альбом форм документов
Номер формы
Наименование формы (классы документов)
Поля формы
Обязательные для заполнения поля
Типовая форма (ссылки на образец и шаблон)
Таблица соответствия форм и документов
Номер формы
Наименование формы
Код документа
Информация, документы, используемые при формировании документа
Операции, выполняемые над документом
Ответственный за выполнение операций над документом
Табель документооборота
Номер документа
Наименование документа
Тип документа (Внутренний/внешний; Входящий/исходящий; транзитный)
Частота документа за временной период
Ответственный за документ (сотрудник или отдел)
Альбом форм документов
Номер формы
Наименование формы (классы документов)
Поля формы
Обязательные для заполнения поля
Типовая форма (ссылки на образец и шаблон)
Таблица соответствия форм и документов
Номер формы
Наименование формы
Код документа
