grischenko-proj-management / lectures / lecture-02-conspect

1

Менеджмент проектов программного обеспечения Лекция №2: «Классическая подход к управлению проектом»

1.Любой проект — баланс между ограничениями

2.Тройственная ограниченность

1.Содержание

2.Стоимость

3.Время

4.Качество *

3.Цель управления проектом

1.Успешно завершить проект

4.Успешность проекта

1.Выполнен с соблюдением объема, сроков, качества

2.Заказчик удовлетворен

3.Финансовая успешность

1.Проект успешен, если принес денег больше, чем в него вложили

2.Проект может быть выполнен в срок, в заданном объеме и качестве, но не заинтересовать пользователей и, как следствие, не окупиться.

---------

4.В зависимости от причин провала проекта ответственность может лежать как на исполнителе, так и на заказчике.

5.Классический подход в управлении проектом (каскадный, водопад)

1.Длинный цикл разработки

2.Строгая последовательность этапов

3.Предельная формализация всех требований и ограничений

--------

4.Кроме классического существуют еще гибкие (итерационные) методики ведения проектов

1.Короткие, повторяющиеся фазы

2.Гибкие переходы между фазами

3.Быстрое предоставление функционала

4.Легкая адаптация к меняющимся условиям

5.Высокая степень коммуникации в команде

6.Когда актуален классический подход?

1.Требования стабильны

1.Реализация драйвера

2.Интеграция с уже существующей системой

2

2.Проект не чувствителен к срокам

1.Нет необходимости строго укладываться в сроки

3.Большой проект с большой командой

1.При гибком подходе огромная часть времени будет уходить на коммуникацию

4.Распределенная команда разработчиков

1.Коммуникация затруднена

5.Критические ресурсы

1.Проект требует участия эксперта либо технических средств, доступ к которым не может быть предоставлен по первому требованию

7.Этапы управления проектом

1.Определение требований

2.Проектирование

3.Реализация

4.Тестирование и отладка

5.Инсталляция

6.Поддержка

8.План проекта?

1.Содержание и границы проекта

2.Ключевые вехи проекта

3.Плановый бюджет проекта

4.Предположения и ограничения

5.Требования и стандарты

9.После определения требований необходимо разбить проект на задачи и распределить их по этапам разработки

10.Разбиение проекта на задачи

11.Пример на основе интернет-магазина

1.Определение требований заказчика

1.Каталог товаров

1.Перечни товаров

2.Возможность отслеживать историю изменения цены по товарам (отключаемая)

3.Возможность пользователей оставлять комментарии по товарам

4.Возможность для каждого товара указывать аналогичные и сопутствующие товары

2.Раздел новостей и акций

3

1.События интернет-магазина

2.Текущие, будущие и прошедшие акции

3.Корзина и заказ товаров

1.Оформление заказа

2.Выбор способа оплаты

3.Интеграция с системами онлайн-оплаты

4.Выбор способа доставки

5.Отслеживание статуса заказа и доставки

6.История заказов

4.Интеграция с внешними баннерными системами

1.Yandex.Direct

2.Google Ad-Sense

5.Маркетинг

1.Легкое создание распродаж и акций со снижением цен не некоторые группы товаров

2.Подарки при покупке определенных групп товаров

3.Внутренняя баннерная система

4.Отслеживание поведения пользователей на сайте

6.Механизм рассылок

1.Оповещение о будущих и текущих акциях

2.Предложение сопутствующих товаров к уже приобретенным

3.Поздравление с днем рождения и прочими праздниками

7.Интеграция с внутренней системой учета

1.Обновление структуры каталога

2.Выгрузка информации о заказах

8.Требования к подсистеме интеграции:

1.Обеспечение актуальности информации

2.Авторизация всех сторон взаимодействия

9.Какие бывают внутренние системы?

1.1С

2.MSAccess

3.Самописная

10.Интеграция с агрегаторами цен

1.Yandex.Market

2.Hotline

3.Price.ua

2.Дизайн

1.Оформление

4

2.Структура и навигация по сайту

3.Проектирование (Архитектура)

1.Выбор платформы

2.Функции ядра и модулей

3.Структура и иерархия модулей

4.Интерфейсы взаимодействия модулей

4.Оставшиеся этапы

1.Реализация

2.Тестирование и отладка

3.Инсталляция

4.Интеграция с внутренней системой предприятия

12.Определение последовательности реализации этапов и требований к подсистемам.

1.ТЗ помогает разбить требования на группы

2.Группы объединяются в этапы разработки

3.Разные этапы выстраиваются в очередь выполнения с учетом зависимостей

4.-------

5.Разработка дизайна может идти параллельно с разработкой архитектуры

6.Разработка ядра может быть только после разработки архитектуры

7.Реализация интерфейса может быть только после завершения разработки дизайна

13.Приоретизация функционала

1.Каталог товаров

2.Интеграция с внутренней системой предприятия

1.Чем раньше будет реализовано, тем раньше программисты заказчика смогут тестировать свою часть работы

3.Корзина и заказ товаров

4.Раздел новостей и акций

5.Маркетинг

6.Механизм рассылок

7.Интеграция с внешними баннерными системами

8.Интеграция с агрегаторами цен