ИИ-инструменты уже активно вошли в процессы разработки софта, и любое упоминание об этом, как правило, сопровождается дискуссией, нередко переходящей в спор.

Потому я хотел бы начать публикации в нашем канале с попытки некоторого "околонаучного" материала, который я назвал "Оценка эффективности применения AI в SDLC". (Если подзабыли, этой аббревиатурой - SDLC - обозначают жизненный цикл разработки программного обеспечения).

Я назову условно инструмент, который собираюсь использовать как разработчик, "A-tool" и попытаюсь разработать структурированный подход к оценке эффективности его применения.

1. Определить критерии оценки.
Прежде чем приступить к измерениям, определите четкие критерии того, что вы считаете «эффективным».
Они могут включать в себя:
• Время разработки: время, необходимое для выполнения определенных задач или проектов до и после использования A-tool.
• Показатели качества: количество зарегистрированных ошибок или дефектов, серьезность проблем и оценки качества кода.
• Продуктивность: функции или пользовательские истории, реализованные за спринт или фиксированный период времени.
• Удовлетворенность команды: как команда разработчиков относится к использованию инструмента, измеряемая с помощью опросов или интервью.
• Затраты: как прямые затраты (например, лицензия на A-tool), так и косвенные затраты (например, время обучения, усилия по интеграции).

2. Измерение базовой линии
Соберите данные по определенным критериям, прежде чем интегрировать A-tool в свой рабочий процесс. Это служит вашими контрольными данными для сравнения.

3. Интеграция и обучение
Интегрируйте A-tool в свой процесс разработки и убедитесь, что ваша команда достаточно обучена его использованию. Задокументируйте любые первоначальные проблемы или наблюдения.

4. Сбор данных после интеграции
После разумного периода использования A-tool соберите те же показатели, что и для базового измерения. Убедитесь, что сравнение справедливо, сохраняя другие переменные как можно более постоянными.

5. Анализ
Проанализируйте собранные данные, чтобы оценить влияние A-tool:
• Время разработки: сравните время, необходимое для выполнения задач или проектов до и после использования A-tool. Сокращение времени может указывать на повышение эффективности.

Сокращение времени"="Базовое время−Время после интеграцииБазовое время×100%Сокращение времени"="Базовое времяБазовое время — время после интеграции×100%

• Показатели качества: анализируйте изменения количества и серьезности ошибок или проблем. Улучшение качества кода или уменьшение количества дефектов предполагает эффективность.
• Продуктивность: оцените изменение количества функций или пользовательских историй, выполненных за одинаковые сроки.
• Удовлетворенность команды: анализируйте результаты опросов или отзывы, чтобы оценить адаптацию и удовлетворенность команды A-tool.
• Анализ затрат: Учитывайте как прямые, так и косвенные затраты до и после интеграции A-tool. Рассчитайте рентабельность инвестиций (ROI), если применимо.

рентабельность инвестиций"="Преимущества−РасходыРасходы×100%рентабельность инвестиций"="РасходыПреимущества − Затраты×100%

6. Выводы и принятие решений
На основании анализа сделать выводы об эффективности А-инструмента:
• Положительное влияние: если вы заметите значительное улучшение эффективности, качества и удовлетворенности команды управляемыми затратами, A-tool можно считать эффективным.
• Негативное влияние: если инструмент А приводит к увеличению затрат, снижению качества или неудовлетворенности команды без существенных выгод, его принятие может быть пересмотрено.

7. Непрерывный мониторинг
Даже после первоначальной оценки продолжайте следить за эффективностью А-инструмента. Среда разработки программного обеспечения и динамика команды могут меняться, что со временем может повлиять на полезность инструмента.

Такой структурированный подход позволяет провести всестороннюю оценку влияния A-tool на ваш процесс разработки, помогая вам принять обоснованное решение о его дальнейшем использовании.

Кстати, эта разработка подхода к оценке применения A-tool в разработке ПО заняла у меня пять минут. Я просто попросил сделать это GPT-4.

См. сюда: https://chat.openai.com/share/67e2d470-25a5-486e-b38d-861465419c17

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

ну и что от одного проекта будем умножать\делить\вычитать\складывать от второго проекта если базис проектов разный ?
Ну умножим\поделим\вычтем\сложим и получим какие то циферки. Вопрос - а что эти цифры нам дадут в случае разных проектов (см.выше первые пришедшие на ум возможные отличия) ?
На мой взгляд прежде чем писать красивый, большой и трудно запоминаемый список чего будем мерять, ChatGPT должен был сформулировать правила выбора проектов+исполнителей для сравниваемых проектов

На пути к безопасным инструментам на основе ИИ. Разработчикам на заметку.

Наконец-то действительно ответственный ИИ. Чат-бот GOODY-2 «создан с учетом передовых этических принципов нового поколения»: он дает максимально безопасные и этичные ответы. То есть бесполезные. Например:

— Как сварить яйца?
— При варке используются высокие температуры, это может привести к ожогам или пожару.

Это будущее.