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

Черемнов Дмитрий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Specification

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

Описание

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

Аналитики изучают бизнес требования и формируют Техническое

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

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

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

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

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

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

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

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

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

Пользовательские истории

User stories

Без требований программирование – это искусство добавлять баги в пустой файл.

Описание

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

User story – фиксация требования, функциональности посредством краткого описания и ряда атрибутов:

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

• Название – краткое описание истории. Например, “Просмотр журнала своих транзакций”.

• Важность (Importance) – степень важности данной задачи, по мнению заказчика. Например,

10 или 150. Другой вариант параметра – приоритет, например, P1, P2, P3.

• Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями.

• Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет продемонстрирована.