Управление содержанием проекта (Project Scope)
Создание плана управления содержанием проекта
Свойства и функции проекта
План работ для достижения результата.
Сбор требований
Инструменты и методы сбора требований
Что такое бизнес-требования?
Определение функциональных требований
Определение нефункциональных требований
Правила описания требований
Как описывать нефункциональные требования
Структура документа для описания требованиий
Матрица отслеживания требований. (документация)
Управление содержанием проекта (Project Scope)
● Определение содержания
● Критерии приёмки продукта
● Допущения и ограничения поставляемого продукта.
● Создание ИСР
● Декомпозиция работ по созданию проекта.
● Примеры разбивки проекта на ИСР ● Подтверждение содержания
● Процесс мониторинга содержания проекта и продукта
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Фреймворк Scrum
Основные понятия фреймворка
Преимущества и недостатки фреймворка
Артефакты Scrum
Роли в Scrum
Event - ы в Scrum
Работа с Backlog. Приоритезация задач
Планирование и мониторинг спринта
Выбор методологии для проекта:
Подходы
Рекомендации
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Управление содержанием проекта (Project Scope)
● Определение содержания
● Критерии приёмки продукта
● Допущения и ограничения поставляемого продукта.
● Создание ИСР
● Декомпозиция работ по созданию проекта.
● Примеры разбивки проекта на ИСР ● Подтверждение содержания
● Процесс мониторинга содержания проекта и продукта
Модуль 2: Лекция 7-8. Обзор моделей, методологий и фреймворковYana Brodetski
Обзор моделей, методологий и фреймворков
● Введение
● Определение модели
● Определение методологии
● Определение фреймворка
● Каскадная модель (Waterfall)
● Модель прототипирования (Prototype)
● Итеративная модель ( Iterative)
● Спиральная модель (Spiral)
● V-образная модель (V-model)
● Agile методология (Agile Methodology)
Фреймворк Scrum
Основные понятия фреймворка
Преимущества и недостатки фреймворка
Артефакты Scrum
Роли в Scrum
Event - ы в Scrum
Работа с Backlog. Приоритезация задач
Планирование и мониторинг спринта
Выбор методологии для проекта:
Подходы
Рекомендации
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Денис Тучин - Пользовательские истории в Agile-проектахDenis Tuchin
Видеозапись вебинара: https://www.youtube.com/watch?v=YBjbaygwvBM&index=9&list=PLu7pKL8OAoRTTwi3KK2OmVmuX9VllOFwt
1. Что такое пользовательские истории (User Stories)
2. Зачем они нужны в ваших проектах?
3. Как пользовательские истории помогают повысить удовлетворённость заказчика?
4. Как применяются пользовательские истории в Scrum?
Для кого:
Вебинар будет полезен менеджерам продуктов, менеджерам проектов, бизнес-аналитикам, владельцам продуктов, проектировщикам и разработчикам систем, которые хотят начать использовать преимущества разработки требований и создания продуктов в стиле Agile в своих проектах
Якщо ви пишете звіт за проектом, ці поради точно стануть у нагоді. На що звертати увагу, які розділи потрібно додати та як організувати подачу інформації, чому історії успіху та описова частина - це важливо?
Что такое эмоциональный интеллект? (Автор термина Дэниел Гоулман). Как управлять эмоциями. Ключевые элементы эмоций. Виды эмоций. Знание своих чувств. Список рекомендуемой литературы по теме эмоционального интеллекта. Лекцию можно послушать на канале Ютуб. Психолог #Татьяна_Барнёва.
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Денис Тучин - Пользовательские истории в Agile-проектахDenis Tuchin
Видеозапись вебинара: https://www.youtube.com/watch?v=YBjbaygwvBM&index=9&list=PLu7pKL8OAoRTTwi3KK2OmVmuX9VllOFwt
1. Что такое пользовательские истории (User Stories)
2. Зачем они нужны в ваших проектах?
3. Как пользовательские истории помогают повысить удовлетворённость заказчика?
4. Как применяются пользовательские истории в Scrum?
Для кого:
Вебинар будет полезен менеджерам продуктов, менеджерам проектов, бизнес-аналитикам, владельцам продуктов, проектировщикам и разработчикам систем, которые хотят начать использовать преимущества разработки требований и создания продуктов в стиле Agile в своих проектах
Якщо ви пишете звіт за проектом, ці поради точно стануть у нагоді. На що звертати увагу, які розділи потрібно додати та як організувати подачу інформації, чому історії успіху та описова частина - це важливо?
Что такое эмоциональный интеллект? (Автор термина Дэниел Гоулман). Как управлять эмоциями. Ключевые элементы эмоций. Виды эмоций. Знание своих чувств. Список рекомендуемой литературы по теме эмоционального интеллекта. Лекцию можно послушать на канале Ютуб. Психолог #Татьяна_Барнёва.
Управление внедрением проекта
Разработка устава проекта
● 1. Описание работ (SOW)
● 2. Определение бизнес-ценности проекта
● 3. Определение высокоуровневых потребностей бизнеса
● 4. Определение допущений и ограничений проекта
● 5. Определение границ проекта
● 6. Определение списка заинтересованных сторон.
Методические рекомендации по внедрению проектного управления в органах властиAndrey Badin
Методические рекомендации по внедрению проектного управления в органах власти, презентация на Совете по внедрению проектного управления в органах власти. Подробности работы по Методическим рекомендациям см. в блоге http://www.pmservices.ru/#!blog/c1xai
Модуль 6. Лекция 25-26. Управление срока проектаYana Brodetski
Управление сроками проекта
● Планирование управление расписанием
● Входы
● Инструменты и методы
● Выходы
● Определение операций
● Инструменты: планирование методом набегающей волны. ● Выходы:
● Список и параметры операций
● Список контрольных событий
● Расписание согласно методологии
* Немного общей информации про проектное управление
* Детально - про классическое планирование по PMBoK (спасибо Рите Мулкахи и ее команде).
* Немного общей информации про SCRUM
Программа совмещает в себе достоинства консалтингового проекта и обучающего курса для менеджмента компании.
При необходимости предоставим референс-лист.
По статистике, три из четырех проектов заканчиваются неудачей. Из-за нечетких целей, плохого планирования, недоучета рисков и так далее и тому подобное.
И есть еще одна причина.
Плохое управление людьми. Проекты делают люди, поэтому, все управление проектами – это управление людьми. А вовсе не вырисовывание красивых картинок в MSProject. Об этом вы поговорите с Олегом Вайнбергом, экс CIO и тьютором факультета менеджмента Открытого Университета Великобритании.
Project Management Power Point Presentation.pptxvolkpsihpro
What Is Project Execution?
The term project execution, also known as project implementation, refers to the actions a team takes during the third phase of the project lifecycle. It is the active stage of the project, in which you produce deliverables for clients and stakeholders.
During the project execution phase, a project moves from planning to completion. This is part of the traditional project lifecycle as outlined by Project Management Institute (PMI), the publisher of the PMBOK guide, which outlines a project from initiation to closing. The project execution stage is the longest, most involved, and most crucial phase of the project lifecycle (it can add up to 70 percent of the project). It’s also common to spend the majority of the project’s budget during this phase. Read our guide to the PMI PMBOK method to find more information on project management lifecycle and best practices.
Project execution is central to delivering value to stakeholders and meeting business goals. Successful execution involves catching missteps before they happen and monitoring the project throughout. A well-executed project will meet budget and schedule goals, and deliver the expected quality. This phase meets the immediate needs of stakeholders and provides long-term value to an organization’s reputation.
For further clarity on how to plan before launching your project execution, read our guide on demystifying the five phases of project management.
What Happens During Project Execution?
During project execution, the project team delivers the agreed-upon products and services. Processes, frameworks, and methods support deliverable completion, as project execution calls for ongoing people management, flexibility, and communication.
A solid project plan provides the team with transparency on tasks, project needs, and strategy. It will also provide an understanding of the risk(s) involved and how the team should manage challenges as they arise. The planning stage is essential to keep the execution on track by providing a reference throughout the execution phase.
Activities during the project execution phase include the following:
People management
Ongoing communication
Delivering project goals
Reducing scope creep
Monitoring quality
Resource allocation
Schedule management
What Is the Project Execution Process?
The term project execution process refers to the set of tasks needed to produce deliverables. Team members decide and assign execution tasks during the project planning phase. The execution process uses structures (techniques, methodology, and frameworks) to organize the manner of delivery.
The project manager will decide which structure best supports the project at hand. Commonly used process models include the following:
Work Breakdown Structure (WBS): This is a visual tool that separates one or more items of a project’s data, services, or product, depending on project scope.
Gantt Chart: Use a Gantt chart as a timeline to view project task
Similar to Модуль 4. Лекция 19-20. Управление содержанием проекта (20)
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
Понятие юзабилити
● Работа с guidelines
● Особенности создания продукта/проекта
● Знакомство с юзабилити для e-commerce
● Знакомство с юзабилити для корпоративных сайтов
● Особенности юзабилити для форумов
● Особенности создания мобильных приложения
● Обзор языков программирования для IOS и Android
● Особенности разработки пользовательского интерфейса для
мобильных приложений
● Структура сборки приложения
● Обзор языков программирования:
● PHP
● .NET
● Python
● Ruby on Rails
● C#
Модуль 15. Лекция 57-58. Обзоры платформ для различных проектовYana Brodetski
Обзоры платформ для различных
проектов (e-commerce, corporate, forum):
● Prestashop
● Wordpress
● Joomla
● Opencart
● YII
● Bitrix 24
● WIX
● Saas – платформы
● Рекомендации по выбору CMS и фреймворков для
создания сайтов
Модуль 12. Лекция 51-52. Управление изменениями проектаYana Brodetski
Управление изменениями проекта
● Планирование управления изменениями
на проекте
● Составление плана управления
изменениями
● Разница между изменением и багом
● Методы оценки влияния изменения на
проект
● Утверждение и внесение изменений на
всех этапах проекта
Модуль 11. Лекция 49-50. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Планирование реагирования на риски:
● Входы
● Инструменты и методы
● Стратегия реагирования на угрозы
● Стратегия реагирования на возможности
● Стратегия реагирования на потери
● Выходы
● Контроль рисков
● Входы
● Инструменты и методы
● Аудиты и переоценка рисков
● Выходы
Модуль 11. Лекция 47-48. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Качественный анализ рисков:
● Входы
● Инструменты и методы
● Формирование матрицы вероятности и воздействия.
● Определение категорий рисков
● Выходы
● Количественный анализ рисков
● Входы
● Инструменты и методы
● Методы сбора и представления информации
● Методы количественного анализа и моделирования рисков
● Выходы
Модуль 11. Лекция 45-46. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Планирование управления рисками:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Идентификация рисков
● Входы
● Инструменты и методы
● Выходы
Модуль 10. Лекция 43-44. Управление коммуникация проектаYana Brodetski
Управление коммуникация проекта
● Планирование управления коммуникациями:
● Входы
● Инструменты и методы
● Коммуникационные технологии
● Коммуникационные модели
● Методы коммуникаций
● Выходы
● Управление коммуникациями
● Входы
● Инструменты и методы
● Выходы
● Контроль коммуникаций
● Входы
● Инструменты и методы
● Выходы
Модуль 9. Лекция 41-42. Управление человеческими ресурсами проектаYana Brodetski
Управление человеческими ресурсами проекта
● Развитие команды проекта:
● Входы
● Инструменты и методы
● Навыки межличностного общения
● Обучение
● Выходы
● Управление командой проекта
● Входы
● Инструменты и методы
● Выходы
Модуль 9. Лекция 39-40. Управление человеческими ресурсами проектаYana Brodetski
Управление человеческими ресурсами проекта
● Планирование управление
человеческими ресурсами:
● Входы
● Инструменты и методы
● Выходы
● Набор команды проекта
● Входы
● Инструменты и методы
● Выходы
Модуль 8. Лекция 37-38. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Планирование управление качеством
● Определение и характеристики дефекта;
● Задачи управления дефектами;
● Классификация важности дефектов;
● Виды тестирования;
● Правильное описание дефекта;
● Жизненный цикл дефекта;
● Работа с базами дефектов;
● Метрики на основе дефектов.
● Составление тест плана
Модуль 8. Лекция 35-36. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Обеспечение качества
● Входы
● Инструменты и методы
● Диаграммы сходства
● Диаграммы процесса осуществления программы
● Ориентированные графы взаимоотношений
● Древовидные диаграммы
● Матрицы приоритетов
● Диаграммы сети операций
● Матричные диаграммы
● Выходы
● Контроль качества
● Входы
● Методы и инструменты
● Выходы
Модуль 8. Лекция 33-34. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Определение управлением качества
● Качество продукта и проекта
● Принципы качество ISO 9000
● Планирование качества
● Входы
● Методы и инструменты
● Диаграмма причинно-следственных связей
● Блок –схемы
● Листы сбора данных
● Диаграмма Парето
● Гистограммы
● Контрольные карты
● Диаграммы разброса
● Выходы
Модуль 6. Лекция 29-30. Управление сроками проектаYana Brodetski
Разработка расписания
● Анализ сети расписания
● Метод критического пути
● Метод критической цепи
● Методы оптимизации ресурсов
● Методы моделирования: “что если”;имитация
● Опережения и задержки
● Сжатие расписания
● Диаграммы: Ганта, контрольных событий, сети расписания проекта
● Контроль расписания проекта
Модуль 6. Лекция 27-28. Управление сроками проектаYana Brodetski
Управление сроками проекта
● Определение последовательности операций
● Метод диаграмм предшествования (PDM)
● Определение зависимостей
● Опережение и задержки
● Оценка ресурсов операций
● Оценка “Снизу верх”
● Оценка длительности операций
● Аналоговая оценка
● Параметрическая оценка
● Оценка по 3 точкам
● Метод Дельфи
Модуль 3. Лекция 17-18. Управление интеграцией проектаYana Brodetski
Управление внедрением проекта
Разработка проектного плана (процессы планирования)
Создание и структура плана проекта
Содержание плана проекта
Правила составления технической документации
Написание технического задания
Руководство и управление работами проекта
Мониторинг и контроль работ проекта
Интегрированный контроль изменений проекта
Закрытие проекта или фазы проекта
Коммерческое предложение
Определение RFI, RFP (Proposal)
Определение MSA, SOW
Структура MSA, SOW
Структура КП (RFP Proposal)
Типы контрактов
Фиксированная стоимость (Fixed Price)
Время и стоимость (Time & Material)
Командный контракт (Dedicated Team)
Подходы к выбору контракта и методологии проекта
2. Лекция 19-20
Управление содержанием проекта (Project Scope)
● Создание плана управления содержанием проекта
● Свойства и функции проекта
● План работ для достижения результата.
● Сбор требований
● Инструменты и методы сбора требований
● Что такое бизнес-требования?
● Определение функциональных требований
● Определение нефункциональных требований
● Правила описания требований
● Как описывать нефункциональные требования
● Структура документа для описания требованиий
● Матрица отслеживания требований. (документация)
3. Управление содержанием проекта (Project Scope)
Управление содержанием проекта включает в себя процессы,
обеспечивающие включение в проект тех работ, которые необходимы для
успешного завершения проекта. Оно непосредственно связано с
определением и контролем того, что включено и что не включено в проекте.
Процессы управления содержанием проекта включают:
● Планирование управления содержанием — процесс создания плана управления
содержанием, документирующего, каким образом содержание проекта будет
определяться, подтверждаться и контролироваться.
● Сбор требований – процесс определения и документирования потребностей
заинтересованных сторон проекта для достижения целей проекта.
● Определение содержания – процесс разработки подробного описания проекта и
продукта.
● Создание иерархической структуры работ (ИСР) – процесс разделения
результатов проекта и работ проекта на более мелкие элементы, которыми легче
управлять.
● Подтверждение содержания – процесс формализованной приемки завершенных
результатов проекта.
● Управление содержанием – процесс мониторинга статуса проекта и содержания
продукта, а также управления изменениями базового плана по содержанию.
4. Термины
В контексте проекта термин «содержание» может
обозначать:
● Содержание продукта - свойства и функции, которые
характеризуют продукт, услугу или результат
● Содержание проекта - работы, которые необходимо
выполнить для создания продукта, услуги или результата с
указанными характеристиками и функциями.
В контексте проекта термин «требование» может
обозначать:
● Требования к проекту могут включать в себя бизнес
требования, требования к управлению проектом,
требования к поставке и т.д.
● Требования к продукту могут содержать информацию о
технических требованиях, требованиях к безопасности,
производительности и т.д
5. Планирование управления содержанием
● Планирование управления содержанием — процесс создания плана
управления содержанием, документирующего, каким образом содержание
проекта будет определяться, подтверждаться и контролироваться. Он
предоставляет руководство и указания относительно управления содержанием
проекта на протяжении всего проекта.
● План управления содержанием — компонент плана управления проектом или
программой, описывающий, каким образом содержание будет определяться,
разрабатываться, отслеживаться, контролироваться и проверяться. Разработка
плана управления содержанием и детализация содержания проекта начинается
с анализа информации, содержащейся в уставе проекта, последних одобренных
вспомогательных планов плана управления проектом, исторической
информации, которая содержится в активах процессов организации и других
соответствующих факторов среды предприятия. Данный план помогает снизить
риск расползания содержания проекта.
6. Планы управления содержанием и требованиями
Компоненты плана управления содержанием включают в себя:
● подготовка подробного описания содержания проекта
● процесс, который позволяет создавать ИСР из подробного описания содержания проекта;
● процесс, который определяет, как ИСР будет поддерживаться и одобряться;
● процесс, который устанавливает, как будет производиться формальная приемка
полученных поставляемых результатов проекта;
● процесс контроля обработки запросов на изменения в отношении подробного описания
содержания проекта.
План управления требованиями — это компонент плана управления проектом,
описывающий способы анализа, документирования требований и управления ими.
Включает:
● порядок планирования, отслеживания и составления отчетов о действиях в отношении
требований;
● действия по управлению конфигурацией, такие как порядок инициирования изменений
продукта, порядок анализа воздействий, их выявления, отслеживания и составления
отчетов о них, а также уровни полномочий, необходимые для одобрения данных
изменений;
● процесс приоритезации требований;
● используемые метрики продукта и обоснование их использования;
● структуру отслеживания, т. е. какие параметры требований будут отражены в матрице
отслеживания.
7. Сбор требований
Сбор требований — процесс определения, документирования и управления
потребностями и требованиями заинтересованных сторон для достижения целей
проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу
для определения и управления содержанием проекта, включая содержание продукта.
Требования должны быть:
● Однозначны
● Измеримы
● Проверяемы
● Отслеживаемы
● Полными
● Последовательными
● Приемлемы для ключевых заинтересованных
сторон проекта
8. Сбор требований
● На успех проекта напрямую влияет тщательность сбора и
управления требованиями к проекту и продукту. Требования
включают в себя количественно определенные и
формализованные потребности и ожидания спонсора,
заказчика и прочих заинтересованных сторон проекта.
● Данные требования должны быть выявлены,
проанализированы и зарегистрированы с достаточной
степенью детализации так, чтобы их можно было измерить
после начала исполнения проекта. Сбор требований
представляет собой определение ожиданий заказчика и
управление ими.
● Требования становятся базой для ИСР. Планирование
стоимости, расписания и качества строится на основе этих
требований. Разработка требований начинается с анализа
информации, содержащейся в уставе проекта и в реестре и
плане заинтересованных сторон
9. Сбор требований
Требования могут быть сгруппированы в классы. Данные
классы включают в себя:
● Бизнес-требования
● Требования заинтересованных сторон.
● Требования к решению, описывающие свойства, функции и
характеристики продукта, услуги или результата, который
удовлетворит бизнес-требованиям и требованиям
заинтересованных сторон. Делятся на:
● Функциональные требования описывают поведение продукта.
● Нефункциональные требования дополняют функциональные и
описывают условия или качества среды, необходимые для обеспечения
эффективности продукта.
● Требования к переходу
● Требования к проекту
● Требования к качеству
10. Сбор требований- инструменты
● Интервью
● Фокус-группы
● Анализ документов
● Анализ интерфейса
● Наблюдение
● Прототипирование
● Семинары с участием модератора
● Анкеты и опросы
● Бенчмаркетинг
● Методы группового принятия решений
● Методы группового творчества
● Контекстные диаграммы
11. Техники бизнес-анализа
5 Whys Technique ( Техника “5 Почему”) – простая техника,
которая помогает найти быстро источник проблемы. Просто
задавайте вопросы вашему клиенту. Это метод изучения
причинно-следственных связей.
Задавая вопрос «Почему?» пять раз, вы определяете
характер проблемы, решение становится понятным.
Первым делом формулируется исходная
проблема. Затем исследователь задаёт
вопрос: «Почему это произошло
(происходит)?» Получив ответ, он снова
спрашивает: «Почему это произошло?» —
выясняя таким образом причину причины. В
результате выстраивается логическая
цепочка, ведущая к первопричине.
Предполагается, что именно воздействие на
первопричину будет наиболее эффективным
для решения исходной проблемы
12. Техники бизнес-анализа
CATWOE Technique - согласно своему создателю Питеру
Чикленду — это простое перечисление (чек-лист) пунктов
одного из шести параметров, которое помогает стимулировать
мышление и находить самые простые решения для таких
вопросов как:
● Что бизнес пытается достичь?
● Какую проблему пытаемся решить?
● Какое решение внедрим?
C - Клиенты
A - Действующие лица
T – Преобразование
W - Миропонимание
O - Владелец
E - Ограничения внешнего окружения
13. Техники бизнес-анализа
HEPTALYSIS Technique - используется для глубокого анализа
бизнес-целей и возможностей. HEPTALYSIS- это
моделирование, в котором обсуждаются фундаментальные
элементы бизнес-процессов и предлагаются способы систе-
матизации результатов и процесса оценки.
HEPTALYSIS Факторы:
● Возможности рынка
● Продукт/Решение
● План выполнения
● Финансовые средства
● Человеческий капитал
● Потенциальная прибыль
● Маржа безопасности
14. Техники бизнес-анализа
MOST/VMOST Analysis- один из методов стратегического анализа
организации, позволяющий контролировать и обеспечивать
согласованность 5 внутренних элементов предприятия (видения и
миссии, целей, стратегии, тактик) с целью достижения желаемого
результата в процессе его деятельности. Компоненты анализа:
(V)Видение — это цель организации с точки зрения ее
предназначения
(M) Миссия — сформулированное утверждение
относительного того, для чего или по какой причине
существует организация
(O) Цели — это конкретные задачи, достижение
которых необходимо для реализации миссии
(S)Стратегия — это некий общий план,
которому необходимо следовать, чтобы
достигать поставленных целей
(Т) Тактика — это конкретный набор действий,
необходимых для выполнения стратегии
15. Техники бизнес-анализа
SWOT/TOWS Analysis- оба используются для анализа внешней
среды (угрозы и возможности) и вашей внутренней среды
(слабость и сильные стороны). На практическом уровне
единственная разница между TOWS и SWOT заключается в том,
что TOWS подчеркивает внешнюю среду, в то время как SWOT
подчеркивает внутреннюю среду.
Cильные стороны – Какие преимущества? Что сделано хорошо?
Слабые стороны- Что можно было
бы улучшить? Что сделано плохо?
Возможности - Какие хорошие
возможности стоят перед
организацией?
Угрозы - С какими препятствиями
сталкивается организация?
16. Техники бизнес-анализа
PEST Analysis- является инструментом, призванным выявлять
политические (Pоlicy), экономические (Ecоnomy), социальные
(Sоciety) и технологические (Technоlogy) аспекты, способные
оказать влияние на стратегическое развитие предприятия.
Анализ выполняется по схеме «фактор — предприятие».
Результаты анализа оформляются в виде матрицы,
подлежащим которой являются факторы макросреды,
сказуемым — сила их влияния, оцениваемая в баллах, рангах
и других единицах измерения.
Результаты PEST-анализа позволяют
оценить внешнюю экономическую
ситуацию, складывающуюся в
сфере производства и коммерческой
деятельности в ближайшей
перспективе нескольких лет.
17. Техники бизнес-анализа
GAP Analysis- комплексное аналитическое исследование,
изучающее, несоответствия, разрывы между текущим
состоянием компании и желаемым. Этот анализ позволяет
выделить проблемные зоны, препятствующие развитию, и
оценить степень готовности компании к выполнению
перехода от текущего состояния к желаемому.
Этапы GAP анализа:
1. Определение основного интереса фирмы, выраженного в терминах стратегического
планирования
2. Выяснение реальных возможностей фирмы с точки зрения текущего
состояния среды и предполагаемого будущего состояния
3. Определение конкретных показателей стратегического плана, соответствующих
основному интересу фирмы
4. Установление разницы между показателями
стратегического и возможностями, диктуемыми реальным положением фирмы
5. Разработка специальных программ и способов действий,
необходимых для заполнения разрыва
18. Техники бизнес-анализа
McKinsey 7S Framework -представляет собой удобный инструмент
анализа внутренней организационной структуры и принципов
работы компании. Модель анализирует 7 ключевых элементов
микросреды организации и позволяет сделать выводы о том:
насколько правильно выстроены и налажены бизнес-процессы
внутри компании, насколько эффективно используются имеющиеся
ресурсы. Может быть использован, когда необходимо :
● улучшить производительность компании
● изучить возможные последствия
будущих изменений внутри компании
● выровнять отделы и процессы во
время слияния или приобретения
● определить, как наилучшим
образом реализовать
предлагаемую стратегию
19. Функциональные требования
Функциональные требования — это перечень сервисов, которые должна выполнять
система, причём должно быть указано, как система реагирует на те или иные входные
данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях
указывается, что система не должна делать.
Стандартные формы для специфицирования функциональных требований:
● Описание функции или объекта.
● Описание входных данных и их источники.
● Описание выходных данных с указанием пункта их назначения.
● Указание, что необходимо для выполнения функции.
● Если это спецификация функции, необходимо описание предварительных условий
(предусловий), которые должны выполняться перед вызовом функции, и описание
заключительного условия (постусловия), которое должно быть выполнено после
завершения выполнения функции.
● Описание побочных эффектов (если они есть).
Функциональные требования (functional requirements) определяют функциональность
ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить
свои задачи в рамках бизнес-требований. Иногда они называются требованиями
поведения (behavioral requirements), они содержат положения с традиционным
«должен» или «должна»: «Система должна по электронной почте отправлять
пользователю подтверждение о заказе».
20. Нефункциональные требования
Определяют общие качества или атрибуты программной системы. Основными
нефункциональными ограничениями, которые имеют отношение к системе, являются
надежность, производительность, безопасность, удобство использования,
безопасность
Нефункциональные требования можно разделить на 3 основных типа:
● Продукт: удобство использования, надежность, безопасность,
производительность..
● Процессы: стандарты, поставка, внедрение
● Внешние требования: совместимость, законные и экономические ограничения
Требования к продукту указывают желаемые характеристики, которые должна иметь
система или подсистема:
● Надежность (Reliability)
● Безопасность (Security)
● Удобство использования (Usability)
● Производительность (Performance Efficiency)
● Удобство сопровождения (Maintainability)
● Совместимость (Compatibility)
● Требования безопасности (Safety)
21. Матрица отслеживания требований
Матрица отслеживания требований представляет собой таблицу,
которая связывает требования с их происхождением и отслеживает их на
протяжении жизненного цикла проекта. Применение матрицы отслеживания
требований помогает удостовериться, что каждое требование увеличивает
ценность бизнеса, связывая его с целями бизнеса и проекта. Это позволяет
отслеживать требования на протяжении жизненного цикла проекта, что
помогает удостовериться в том, что требования,
одобренные в документах
по требованиям,
выполнены в конце
проекта.
Наконец, матрица
отслеживания требований
обеспечивает структуру
для управления
изменениями содержания
продукта.
22. Матрица отслеживания требований
Параметры, связанные с каждым требованием, могут быть записаны в матрице
отслеживания требований. Данные параметры помогают определить ключевую
информацию относительно требований.
Типичные параметры, используемые в матрице отслеживания требований, могут
включать в себя:
● уникальный идентификатор,
● текстовое описание требования,
● обоснование включения в список требований,
● владельца,
● источник,
● приоритет,
● версию,
● текущий статус (активный, отменен, отложен, добавлен,одобрен)
● дату выполнения.
Дополнительные параметры, позволяющие удостовериться, что требование
удовлетворяет заинтересованные стороны проекта, могут включать также
стабильность, сложность и критерии приемки.