Что такое разработка и управление ПО и почему приложение дороже проекта

Зачем разработка и управление ПО

ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 отвечает за жизнь приложений целиком: от замысла до вывода из эксплуатации, включая всё, что раньше называли сопровождением. Масштаб задан сразу: жизнь приложения длится от нескольких месяцев до нескольких десятилетий, в среднем десять-пятнадцать лет 1.

Оттуда же цифра, которая переворачивает разговор о бюджете. Исторически на разработку приходилось около 20% совокупной стоимости владения приложением, а остальное — на управление им; при этом около 20% затрат на управление уходило на исправление дефектов 1. Иными словами, решение написать приложение — это решение о расходах на годы вперёд, а не о цене проекта.

В современных услугахУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation доля разработки в стоимости владения растёт: изменения идут постоянно, и всё, что раньше было сопровождением, стало частью разработки 1.

Ещё одно наблюдение, которое стоит знать заказчику: тенденция отдавать разработку на сторону в последние годы развернулась — банки, страховые и торговые компании возвращают критичную и стратегическую разработку к себе 1.

Когда практика работает

Три вопроса, ответы на которые видны по тому, как принимаются решения о доработках.

Известно, чем приходится расплачиваться за спешку. Как проверить: технический долг назван, где-то записан и обсуждается при планировании.

Изменения идут потоком, а не проектами по случаю. Как проверить: у приложения есть очередь работ и понятный ритм выпусков.

Качество определено словами, а не ощущением. Как проверить: для приложения названы требования к пригодности, надёжности, сопровождаемости и соответствию требованиям 1.

Что входит и что рядом

Технический долг: определение, с которым можно работать

Есть формулировка, которую полезно принести на разговор с руководством: технический долг — накопленный объём переделок, возникший из-за того, что выбирали обходные путиОбходное решениеСпособ снизить или устранить последствия инцидента, когда полного решения ещё нет.ITIL 4, практическое руководство по управлению инцидентами вместо системных решений, требующих больше времени 1.

Механика оттуда же: быстрые заплатки предпочитают правильным, но долгим изменениям; при высоком темпе изменений это накапливается в объём работы, которую всё равно придётся сделать 1.

Практический ход: долг перестаёт быть метафорой, когда его записывают в ту же очередь работ, что и новые возможности, и обсуждают при планировании наравне с ними. Пока он живёт в разговорах разработчиков, для бизнеса его не существует — до дня, когда простая доработка внезапно занимает месяц.

Что на входе и что на выходе

Практика получает требования и правила, отдаёт работающие приложения и сведения о них. Особенность в том, что она отдаёт не только код: инструкции, описания интерфейсов, сведения для наблюдения и поддержки — часть результата, без которой услугу нельзя эксплуатировать.

Отсюда честный признак зрелости: готовность приложения оценивается не только тем, что оно работает, но и тем, можно ли им управлять.

Что называют качеством программ

В основе лежит международная модель качества программного обеспечения; ITIL приводит её деление 1:

ЦенностьЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation деления практическая: первая строка проверяется в тестовой среде, вторая — только на живых людях в их работе. Требования к первой попадают в задание почти всегда, ко второй — почти никогда.

Виды сопровождения

ITIL разбирает сопровождение на четыре вида, и это разделение помогает планировать 1:

• исправляющее — устранение дефектов, которые уже привели к сбоям;
• предупреждающее — устранение дефектов до того, как они проявились;
• приспосабливающее — приведение приложения в соответствие с изменившейся инфраструктурой;
• улучшающее — расширение возможностей, удобства и производительности.

В современных условиях всё это стало частью разработки и обычно уже не называется сопровождением 1. Но разделение остаётся полезным при планировании — оно показывает, какая доля усилий уходит на исправление чужих и своих прошлых решений.

Как это работает

Единой схемы у практики нет и быть не может. ITIL перечисляет подходы — от водопадных моделей до итеративных и наращиваемых — и замечает, что организация обычно сочетает несколько, чтобы работа шла повторяемо и управляемо 1.

Цвет шага: приём, учёт, работа с обращением техническая работа проверка, разбор, улучшение работа с людьми и сторонами

Две строки этой таблицы стоит развернуть.

Первый шаг не про моду. Выбор между водопадом и итеративной работой определяется предметом: приложение с редкими изменениями и жёсткими требованиями регуляторов живёт иначе, чем продукт с еженедельными выпусками.

Седьмой шаг длиннее всех остальных вместе взятых. При средней жизни приложения в десять-пятнадцать лет 1 решения, принятые на четвёртом шаге ради экономии недели, оплачиваются годами.

Что с чем путают

Разработка и управление приложениями. Управление — понятие шире: в него входят стратегия и планирование приложений, эксплуатация, хранение артефактов и вывод из эксплуатации 1.

Разработка и проектирование услуги. Приложение — часть услуги. Замысел услуги целиком, включая людей и поставщиков, живёт в SDSПроектирование услуги.

Сопровождение и поддержка пользователей. Сопровождение меняет приложение, поддержка помогает людям им пользоваться.

Технический долг и плохой код. Долг — осознанный обмен скорости на будущую работу 1. Плохой код — просто плохой код; он тоже становится долгом, но незапланированным.

Кто участвует

Как измерять

Самая полезная связка — доля усилий на исправления и объём долга. Вместе они показывают то, что не видно из отчётов о выпущенных возможностях: сколько сил уходит на прошлое.

У половины метрик Брукса тревожит недобор, а не превышение. Опасное значение там стоит НИЖЕ целевого 4:

• разобранных программных ошибок — цель 4, тревога 2;
• оптимизаций — цель 20, тревога 10;
• дефектов, найденных по журналам, — цель 4, тревога 2;
• ошибок, пойманных при разработке и тестировании, — цель 20, тревога 10. Направление обратное привычному, и оно верное: мало найденных дефектов — это не хорошая новость, а либо никто не искал, либо не записали.

Отсюда следствие для панели. Показатели разработки нельзя красить одним правилом «растёт — плохо»: половина набора именно должна увеличиваться, и раскраска по общему шаблону будет врать в самых важных местах.

Обучение пользователей он считает метрикой разработки — учебные занятия по новым выпускам: цель 10, тревога 5 4. Мысль неочевидная и полезная: команда, выпустившая возможность, которой никто не умеет пользоваться, работу не закончила. Обоснование у него ещё жёстче — обучением пренебрегают, потому что не считают критерием успеха, и метрика заведена ровно затем, чтобы этот пробел стал видимым.

Одно место в книге стоит проверить смыслом. У числа временных решений, возвращённых на доработку, обоснование гласит, что это показатель низкого уровня тестирования, — а целевое значение стоит выше опасного 4. Одно из двух неверно, и правым выглядит обоснование. Числа Брукса вообще даны образцами для настройки, а не отраслевой нормой; этот случай просто напоминает, что переносить их молча не стоит.

Зрелость разработки и управления ПО

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Долг не назван. О нём говорят разработчики между собой, в планах он не появляется, и однажды простая доработка занимает месяц 1.

Требования к управляемости не собирались. Приложение работает, но его нельзя наблюдать, обновлять без простоя и восстанавливать быстро.

Сопровождение считают исключением. Планируются только новые возможности, а исправления и приспособление к среде занимают половину времени 1.

Один подход на все приложения. Продукт с еженедельными выпусками и учётная система с редкими изменениями живут по одному регламенту.

Артефакты не хранятся централизованно. Собранное лежит у разработчика, и повторить сборку прошлой версии нельзя.

Вывод из эксплуатации не планируется. Приложение доживает годы после того, как перестало быть нужным, и тянет за собой поддержку и лицензии.

Что говорят своды

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит разработку и управление приложениями одной практикой, охватывающей всю их жизнь, и вводит понятия технического долга и видов сопровождения 1.

COBIT выделяет разработку и создание решений отдельной целью управленияЦель управленияЕдиница описания COBIT: цель с проверяемым содержанием, у которой есть процесс того же имени.COBIT 2019, книга Governance and Management Objectives 3.

ГОСТ Р ИСО/МЭК 20000-1 разработку отдельно не описывает: он говорит о проектировании, построении и перенесении сервисов и требует испытаний на соответствие критериям приёмки 2.

Модель качества программного обеспечения даёт язык для требований: качество продукта и качество в использовании 1.

Вывод для практики: своды управления услугами описывают разработку рамкой, а содержание берётся из инженерных подходов. Это нормально — но означает, что договариваться о моделях жизненного цикла придётся самим, ссылаясь не на них.

Где описано

Что почитать дальше

Три соседние практики, между которыми живёт разработка: BANБизнес-анализ — откуда берутся требования, TSTПроверка и тестирование услуг — как проверяют результат, RLSУправление релизами — как он попадает к людям.