Взаимоотношения заказчик- исполнитель при разработке ПО Константин Кондратюк, Владислав Балин

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

Выбор исполнителя

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

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

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

Действующие стандарты ГОСТ 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 – серьезность проблемы, оценивается автором 1.Общесистемный сбой, потеря данных 2.Функция не работает 3.Часть функции не работает 4.Косметика Priority – приоритет, назначается исполнителем

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

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

СПАСИБО