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


The Presentation inside:

Slide 0

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


Slide 1

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


Slide 2

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


Slide 3

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


Slide 4

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


Slide 5

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


Slide 6

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


Slide 7

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


Slide 8

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


Slide 9

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


Slide 10

Требования и ТЗ


Slide 11

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


Slide 12

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


Slide 13

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


Slide 14

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


Slide 15

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


Slide 16

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


Slide 17

Контроль за выполнением проекта и приемка работ


Slide 18

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


Slide 19

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


Slide 20

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


Slide 21

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


Slide 22

Внедрение, поддержка и сопровождение


Slide 23

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


Slide 24

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


Slide 25

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


Slide 26

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


Slide 27

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


Slide 28

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


Slide 29

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


Slide 30

СПАСИБО


×

HTML:





Ссылка: