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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31 СПАСИБО