'

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

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

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


Слайд 23

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


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


Слайд 30

СПАСИБО


×

HTML:





Ссылка: