Вы находитесь на странице: 1из 38

Лекция 3 Часть 1

Где мы находимся?
Что делаем дальше?
Не упустить важных стейкхолдеров
Методы выявления требований
Группирование требований
Part 3. Identifying Stakeholders
Предыдущая лекция

 Специфика ИТ проектов
 Методы управления ИТ проектами (классические)
 Гибкие методологии (AGILE)
 Инициирование проекта
WATERFALL MODEL
https://youtu.be/Y_A0E1ToC_I

Преимущества и недостатки???
https://youtu.be/mp22SDTnsQQ
https://youtu.be/gcpOZi6Hz38
АДАПТИВНЫЙ ЖИЗНЕННЫЙ ЦИКЛ
РАЗРАБОТКИ СИСТЕМ
• В ОТЛИЧИЕ ОТ ПРОГНОЗИРУЮЩИХ МОДЕЛЕЙ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛЬ ЖИЗНЕННОГО
ЦИКЛА АДАПТИВНОЙ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (ASD) ПРЕДПОЛАГАЕТ,
ЧТО РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СЛЕДУЕТ АДАПТИВНОМУ ПОДХОДУ:
• ТРЕБОВАНИЯ НЕ МОГУТ БЫТЬ ЧЕТКО ВЫРАЖЕНЫ В НАЧАЛЕ ЖИЗНЕННОГО ЦИКЛА.
• ЭТО ОБЕСПЕЧИВАЕТ БОЛЬШЕ СВОБОДЫ, ЧЕМ ПРЕДПИСЫВАЮЩИЕ ПОДХОДЫ.
• КОМАНДНАЯ ОТВЕТСТВЕННОСТЬ
• ПОРЦИОННАЯ ДОСТАВКА ПРОДУКТА
• ТЕСНОЕ СОТРУДНИЧЕСТВО СО ВСЕМИ СТЕЙКХОЛДЕРАМИ
• ИЗМЕНЕНИЯ ПРИНИМАЮТСЯ ВСЕГДА

• AGILE МЕТОДОЛОГИЯ ЯВЛЯЕТСЯ РАСШИРЕНИЕМ ASD


ЧТО ТАКОЕ AGILE?
• МОДЕЛЬ AGILE ПРЕДПОЛАГАЕТ, ЧТО КАЖДЫЙ ПРОЕКТ НУЖНО ВЫПОЛНЯТЬ ПО-РАЗНОМУ, А СУЩЕСТВУЮЩИЕ
МЕТОДЫ ДОЛЖНЫ БЫТЬ АДАПТИРОВАНЫ К ТРЕБОВАНИЯМ ПРОЕКТА.
• SDLC ПРЕДСТАВЛЯЕТ СОБОЙ КОМБИНАЦИЮ ИТЕРАТИВНЫХ И ИНКРЕМЕНТНЫХ МОДЕЛЕЙ ПРОЦЕССОВ С
АКЦЕНТОМ НА АДАПТИРУЕМОСТЬ ПРОЦЕССА И УДОВЛЕТВОРЕНИЕ ПОТРЕБНОСТЕЙ КЛИЕНТОВ ЗА СЧЕТ БЫСТРОЙ
ДОСТАВКИ РАБОТАЮЩЕГО ПРОГРАММНОГО ПРОДУКТА
• В AGILE ЗАДАЧИ РАЗДЕЛЕНЫ НА ВРЕМЕННЫЕ РАМКИ (НЕБОЛЬШИЕ ВРЕМЕННЫЕ РАМКИ), ЧТОБЫ ПРЕДОСТАВИТЬ
ОПРЕДЕЛЕННЫЕ ФУНКЦИИ ДЛЯ ВЫПУСКА.
• КАЖДАЯ ИТЕРАЦИЯ ОБЫЧНО ДЛИТСЯ ОТ ОДНОЙ ДО ТРЕХ НЕДЕЛЬ.
• КАЖДАЯ ИТЕРАЦИЯ ВКЛЮЧАЕТ В СЕБЯ КРОСС-ФУНКЦИОНАЛЬНЫЕ КОМАНДЫ, РАБОТАЮЩИЕ ОДНОВРЕМЕННО В
РАЗЛИЧНЫХ ОБЛАСТЯХ, НАПРИМЕР:
• ПЛАНИРОВАНИЕ
• АНАЛИЗ ТРЕБОВАНИЙ
• ДИЗАЙН
• КОДИРОВАНИЕ
• МОДУЛЬНОЕ ТЕСТИРОВАНИЕ И
• ПРИЕМОЧНОЕ ТЕСТИРОВАНИЕ.

• В КОНЦЕ ИТЕРАЦИИ РАБОЧИЙ ПРОДУКТ ДЕМОНСТРИРУЕТСЯ ЗАКАЗЧИКУ И ВАЖНЫМ ЗАИНТЕРЕСОВАННЫМ


СТОРОНАМ.
ИНИЦИИРОВАНИЕ ПРЕКТА
Part 3. Identifying Stakeholders
Инициирование проекта

 Понять, что собой представляет проект.


 Что ожидается (цели проекта)?
 Возможно ли проект осуществить?
 Собрать первоначальную информацию – поговорить с заказчиком и потенциальными
пользователями
 Оценить осуществимость проекта
 Создать первый документ – ОБОСНОВАНИЕ, содержащий основные идеи проекта.
 И на основе ОБОСНОВАНИЯ – создадим 1-й официальный документ
 УСТАВ ПРОЕКТА
LAB 1 TASKS
Инициирование проекта: действия и артефакты
Часть 2. Разработка Устава
проекта
На основе обоснования
Role of the project Charter (Устав проекта)

 Устав проекта - это документ, который официально признает существование проекта;


 Он информирует все заинтересованные стороны о данном проекте
 Он определяет цели и управление проектом.
 Он уполномочивает руководителя проекта использовать организационные ресурсы для
выполнения и завершения проекта.
 Устав проекта является ключевым результатом процесса инициации
PMBOK рекомендации для содержания
устава проекта (на основе обоснования)
 Название, Назначение, Цели проекта и критерии успеха (SMART)
 High-level - описание содержания проекта
 Существенные Риски
 Приблизительный График
 Приблизительный бюджет
 Менеджер проектов
 Спонсор проекта
 Подписи ответственных сторон
Примеры Уставов проекта на страничке
курса
Share your experience…
На следующей лабораторной

 Закончим Обоснование – создание окончательной версии


 Создадим Устав проекта
 Загрузите оба документа
Part 3. Identifying Stakeholders
УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

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


включение в проект тех и только тех работ, которые необходимы для успешного
завершения проекта.
• Управление содержанием проекта непосредственно связано с определением и
контролем того, что включено и что не включено в проект.
ПРОЦЕССЫ УПРАВЛЕНИЯ СОДЕРЖАНИЕМ
ПРОЕКТА
• Сбор требований – процесс определения и документирования потребностей
заинтересованных сторон проекта для достижения целей проекта.
• Анализ требований – группирование требований и моделирование системы
• Определение содержания – процесс разработки подробного описания проекта и продукта.
• Создание иерархической структуры работ (ИСР) – процесс разделения результатов проекта
и работ проекта на более мелкие элементы, которыми легче управлять.
ЗАДАЧА – СОБРАТЬ КАК МОЖНО
БОЛЕЕ ДЕТАЛИЗИРОВАННУЮ
ИНФОРМАЦИЮ О ТРЕБОВАНИЯХ К
ПРОЕКТУ
ВАЖНO!
НЕ ПРОПУСТИТЬ ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ
• Как получить информацию о заинтересованных сторонах?
• HR
• Разговор с высшим руководством и сотрудниками (предварительное исследование)
• Рекомендуемая практика:
• составления списка заинтересованных сторон
• классификации заинтересованных сторон(реестр)

• Заинтересованные стороны (это зависит от сферы деятельности и содержания проекта) могут быть:
• Спонсоры
• Управляющие
• Сотрудники
• Внешние клиенты
• Вендоры
• Поставщики
• Субподрядчики и др.
ПОЧЕМУ ВАЖНО ИДЕНТИФИЦИРОВАТЬ ВСЕ
ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ?
КАКОВА ИХ ЦЕННОСТЬ ДЛЯ ПРОЕКТА?
• https://proficientlearning.com/4-ways-stakeholders-are-important-to-a-project/
ВИДЫ ТРЕБОВАНИЙ (МЫ
ОСТАНОВИМСЯ НА 3 ВИДАХ)
ЧТО ТАКОЕ ТРЕБОВАНИЯ?

• Способности системы, необходимые пользователю для решения проблемы или


достижения цели.
• Способности, которой должна соответствовать или обладать система или ее системный
компонент, чтобы выполнить договор, стандарт, спецификацию или другой официально
установленный документ.
• Требования могут выражаться в виде текстовых утверждений и графических моделей.
КЛАССИФИКАЦИЯ ТРЕБОВАНИЙ

• Основываясь на характерных признаках, требования к ПО классифицируются по


следующим категориям:
• «Бизнес» требования:
• определяют основное назначение продукта;
• Описывает бизнес-идею, без реализации которой продукт не будет нужен потребителю.
• Это описание возможностей, для решения или реализации которых создается продукт
• Бизнес-требования могут быть финансовыми или нефинансовыми.
ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

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


• пользовательские позволяют определить задачи, возложенные на программное
решение;
• Это перечень сервисов, которые должна выполнять система
ПРИМЕРЫ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

Определяют характер поведения, которые


включают требования к:
• Юзабилити – удобство пользования
• надежности;
• Производительности;
• Безопасности и защите данных;
• мобильности;
• Требования к компонентам;
Количественные показатели нефункциональных требований

Скорость
Количество выполненных транзакций в секунду;
время реакции на действия пользователя;
время обновления экрана

Простота эксплуатации
Время обучения персонала;
Подсказки и поддержка пользователей
Автоматическое исправление ошибок

Надежность
Средняя продолжительность времени между двумя последовательными проявлениями ошибок в системе;
вероятность выхода системы из строя;

Устойчивость к сбоям
Время восстановления системы после сбоя;
процент событий, приводящих к сбоям;
вероятность порчи данных при сбоях
НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

• Требования к СУБД
• Требования к интерфейсам
• Требования к языким программирования