Дмитрий Николаевич Черемнов
Профессиональные компетенции разработки программного обеспечения

Профессиональные компетенции разработки программного обеспечения

Лучше научите людей, рискуя, что они уйдут, чем не делайте ничего, рискуя, что они останутся.

Факты

• Каждая профессиональная компетенция разработки программного обеспечения повышает квалификацию ИТ специалиста.

• Даже одна компетенция может повысить эффективность разработки ПО.

• Комплексное применение компетенций многократно усиливает продуктивность работы и качество ПО.

• Без ряда компетенций командная, удаленная разработка невозможна.

• Компетентная команда ИТ специалистов – залог успешного проекта.

Цель

• Познакомиться с профессиональными компетенциями разработки программного обеспечения.

• Получить рекомендации по формированию компетенций.

• Изучить дополнительные материалы и документацию для повышения квалификации.

• Ознакомиться с инструментами, используемыми в разработке программного обеспечения и получить базовые навыки по работе с ними.

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

Проект и задачи

Цель и содержание проекта

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

Описание

Каждый проект имеет набор документации. Есть документы, которые формируются иногда задолго до начала реализации, ряд других формируют по мере работы над проектом. Некоторые документы модифицируются со временем, иные становятся неактуальными. Одними из первых документов являются Цель и содержание проекта (часто они включаются в техническое задание в качестве раздела).

Цель и содержание проекта – это краткое описание, которое дает общее представление о назначении проекта и конечного планируемого результата разработки.

Цель проекта описывает какие задачи должны быть решены в результате проекта, а содержание проекта – что именно является результатом проекта.

Описание цели и содержания проекта (Project Scope) на примере проекта "Универсальная модульная платформа", в реализации которого принимают участие некоторые "выпускники" курса.

Проект "Универсальная модульная платформа"

Цель проекта

Много проектов имеют схожую многомодульную структуру, до 25% общего функционала.

Если выделить часто используемый общий функционал в модули, подключаемые по необходимости в разные проекты, то можно решить следующие задачи:

• быстрый старт разработки проекта на базе платформы;

• получение востребованного опыта и навыков разработки участниками;

• легкое вхождение участников команды разработки в однотипный проект;

• эффективное участие юниоров в разработке однотипных проектов;

• упрощение разработки и поддержки однотипных проектов;

• улучшение качества за счет многократного тестирования общего кода на разных проектах;

• уменьшение периода разработки за счет подключаемых модулей;

• финансовая экономия.

Описание проекта – Project Scope

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

• система заказов услуг или продуктов;

• система бронирования и продажи билетов;

• система логистики;

• e-commerce система;

• информационная система и прочие.

Можно выделить основные компоненты систем:

• SQL база данных;

• Backend с бизнес логикой;

• приложение администратора;

• REST (JSON) API сервер;

• Frontend с веб интерфейсом;

• мобильные приложения.

Список наиболее востребованных нефункциональных и функциональных требований:

• аутентификация и авторизация;

• логирование;

• уровень доступа к SQL базе данных;

• планировщики для запуска периодических процессов;

• инфраструктура и настройка REST контроллеров;

• создание, редактирование и просмотр администраторов и пользователей системы;

• загрузка в систему и скачивание из системы файлов (фото, документов и т.п.).

Нужно отметить, что платформа предъявляет более строгие требования к проектированию, реализации, тестированию системы. Важно соблюдать баланс между минимальностью и достаточностью платформы, с учетом использования в разных приложениях.

Открытыми для обсуждения с участниками проекта остаются аспекты:

• масштабируемость платформы – должна ли система, построенная на платформе легко масштабироваться при необходимости;

• мультиарендность платформы (multitenancy) – должна ли архитектура поддерживать множество арендаторов-владельцев.

Данные аспекты являются интересными, но повышают сложность и увеличивают время разработки. Для MVP (minimum viable product – минимально жизнеспособный продукт) данными аспектами можно пренебречь. Но часто заказчики программного обеспечения планируют маштабируемость системы. Мультиарендная платформа используется обычно в программном обеспечении как услуге (software as a service – SaaS).

Техническое задание или Спецификация

Specification

Ходить по воде и разрабатывать ПО из спецификации легко. Просто нужно заморозить и то, и другое.

Описание

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

Аналитики изучают бизнес требования и формируют Техническое задание (ТЗ) или Спецификацию, с участием дизайнеров, которое включает:

• функциональные требования – описание основной и дополнительной функциональности, которое требуется реализовать в программном обеспечении;

• не функциональные требования – требования к среде исполнения, производительности, защищенности, наличия мониторинга, логирования и т.п.

• мокапы – схематическое изображение экранов или страниц с графическими элементами представления (надписи, таблицы и т.п.), ввода (поля и окна ввода, таблицы и т.п.) и управления (кнопки, радио кнопки, чек-боксы и т.п.), со схемой переходов между экранами;

• дизайн – графическое представление страниц и экранов программного обеспечения может дополнительно прилагаться к ТЗ (либо создаваться дизайнерами позже).

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

С учетом как функциональных, так и не функциональных требований формируется архитектура проекта, проводится выбор технологий, инструментов разработки, баз данных и пр., определяется требуемый состав и число ИТ специалистов.

В классическом процессе разработки ТЗ или Спецификация для программиста является исходным документом, используемым в процессе разработки.

На основе Технического задания (или Спецификации) формируется список задач программистам для реализации.