Взаимоотношения заказчик-исполнитель при разработке ПО

Содержание
Выбор исполнителя
Требования и техническое задание
Контроль за выполнением проекта приемка работ
Внедрение, поддержка и сопровождение
Вопросы и ответы

ВЫБОР ИСПОЛНИТЕЛЯ

Идеальный подрядчик. Кто он?
Определить требования
Отобрать кандидатов
Провести конкурс
Пилотный проект

Требования к подрядчику
Опыт в предметной области
Знание необходимых технологий
Положительные отзывы на рынке
Гибкость
Эмоциональный интеллект
Общие ценности
Корпоративная культура

Организация тендера
Паспорт проекта
Бизнес-требования
Выбор претендентов
Критерии оценки предложений
План проведения
Подведение итогов

Действующие стандарты
ГОСТ 19 и ГОСТ 34
Протокол отношений заказчик-исполнитель
Не задают требований к процессу разработки
Ключевые документы – ТЗ и ПМИ

Виды контрактов
Повременная оплата (time and material)
Риск и управление требованиями на заказчике
Время – признак конца этапа
Фиксированная цена (fixed price)
Все риски на подрядчике
Возмещение затрат (cost reimbursable)
Риски распределяются между заказчиком и подрядчиком

“Методологии” разработки
Code-and-Fix
Agile (Scrum, XP)
Evolutionary Prototyping
RUP
Spiral
Waterfall

Цикл разработки
Определяет структуру плана
Поэтапный план – часть ТЗ
Этап – единица оплаты
Подходы:
Iterative
Mix
Grand Design

ТРЕБОВАНИЯ И ТЗ

Управление требованиями
Требования:
бывают функциональными и не функциональными
разные по ценности (MoSCow)
разные по стоимости реализации
должны полны и непротиворечивы
и они меняются…
Требованиями надо управлять!

ТЗ по ГОСТ 19
Цели и задачи работы
Ключевые технические требования
Поэтапный план работ
Соглашение по организации работ

Составление поэтапного плана
План – последовательность этапов
Этап – единица оплаты
Этап определяется результатами, а не процессом
Результаты имеют критерии приемки
Общие критерии приемки расписаны в ПМИ. ПМИ – результат одного из этапов
Внедрение и поддержка – тоже этапы

Типовые этапы
Эскизный проект
Результаты: прототип, техническая документация
Технический проект
Рабочий проект
Внедрение
Сопровождение
Состав этапов может меняться

Оценка срока и бюджета
Детальнее задачи – точнее план
понимаем структуру работ и рисков
Методы оценки трудозатрат
PERT-Estimation
COCOMO II
Функциональные точки
Общая стоимость владения
Разработка + внедрение (CAPEX)
Эксплуатация + поддержка (OPEX)

Управление рисками
Что такое риск?
Процесс управления рисками
Конструкция «Условие-Последствие»
Распределение ответственности
Основные риски ИТ-проекта
Выгоды возмещают риски

КОНТРОЛЬ ЗА ВЫПОЛНЕНИЕМ ПРОЕКТА И ПРИЕМКА РАБОТ

Способы оценки прогресса
План работ (готово на 90%!)
Степени готовности:
Cпроектировано
Готово к демонстрации
Работают!
Считаем количество:
функций, имеющие бизнес-ценность
use cases
Аудит архитектуры на соответствие

Мониторинг эффективности
Точность оценки трудозатрат
Оценка качества тестирования
Ограничение текучести персонала
Лимиты по видам активностей
Когда требования превращаются в спам
Сегодняшние проблемы – это вчерашние риски

Программа и методика испытаний
Принимать все сразу, или по частям?
Методика – способы тестирования (как)
Программа – план тестирования (что)
Каждый пункт программы соответствует ТЗ
Детализирует требования ТЗ
ПМИ составляется как можно раньше

Организация процесса приемки
Составляется протокол «испытаний»
Выявленные недостатки устраняются
Подписывается акт приемки-передачи
Важно для внедрения:
Привлечение конечных пользователей
Процедура постановки в эксплуатацию
Процедуры обработки экстренных ситуаций
Наличие документации согласно ТЗ
Внедрение и поддержка – тоже этапы

ВНЕДРЕНИЕ, ПОДДЕРЖКА И СОПРОВОЖДЕНИЕ

Процесс поддержки ПО
Непрерывный процесс доработок и исправлений ошибок
Доработки могут быть существенны
Инциденты отличаются по срочности:
«Немедленно» – релиз вне графика
«Обязательно» - в ближайшем релизе
«Обычный» – эти можно двигать

Планирование релиза
Оценка сроков решения инцидентов затруднена
Инцидентов много, они не связаны друг с другом
Релиз планируется на основе среднего темпа исправления
Релиз жестко ограничен временем, выходит регулярно

Организация процесса поддержки
Первая линия поддержки (Helpdesk)
консультирует пользователей
регистрирует ошибки и доработки
Вторая линия поддержки (программисты)
Исправляет ошибки
Реализует доработки
Третья линия поддержки (архитектора)
Решают сложные ошибки
Следят за целостностью архитектуры

Метрики оценки поддержки
SLA (Service Level Agreement)
Гарантированное время реагирования на инциденты
Размер очереди открытых инцидентов
Средний темп исправления инцидентов

Свойства инцидента
Severity – серьезность проблемы, оценивается автором
Общесистемный сбой, потеря данных
Функция не работает
Часть функции не работает
Косметика
Priority – приоритет, назначается исполнителем

Триаж: назначение приоритета
Триаж – процесс сортировки раненых на поле боя по степени тяжести ранения.
Критерии:
Объем затронутого функционала
Критичность затронутых функций
Наличие workaround
Частота проявления инцидента
Количество затрагиваемых пользователей
Затраты на исправление

Вопросы и ответы