Бывает, что есть задание, весьма конкретное, а с чего начинать – непонятно. Начинаешь представлять, какие будут пакеты и папки, по каким классам и функциям придётся всё разбить, и голова кругом идёт. Хочется схватиться и за логику, и за данные, и за интерфейс… Кажется, лучше всего начать с логики, но стоит сразу заняться основным алгоритмом или рюшечками? Такие проблемы часто встречаются, когда начинающие ребята (вроде меня) пишут и на ходу выдумывают учебные проекты (на платных курсах или всякие дипломные работы в универе) .
Бывает, что всё же довольно уверенно начинаешь что-нибудь писать и на ходу понимаешь, что упустил пару функций, а потом – ещё пару, и так бодрая поначалу разработка превращается в бесконечный процесс, затягивающий, как трясина, и порождающий всё более невнятный и запутанный код. Такое бывает, когда я кидаюсь выполнять тестовые задания или реализовывать заказанные работодателем новые фичи (хочется всё закончить побыстрее и затребовать деньги).
И чтобы таких проблем не было, чтобы не сомневаться и потом ничего не переписывать и не перекладывать файлы по новым пакетам, всегда лучше начать с нормального проектирования. Определитесь, для кого ваше приложение, что оно будет делать и какую ценность представлять для пользователей. Убедитесь, что вы и сами понимаете, что оно должно делать и что ваш заказчик (если он есть) тоже всё понимает…
Я буду описывать весь этот начальный процесс на примере приложения для брони билетов в кинотеатре.
Требования к приложению (FURPS)
Итак, начать разработку приложения лучше не с создания maven-проекта и не с написания первых очевидных функций, а с требований к приложению. Если вы пишете свой личный проект, то опишите свои собственные требования. Если клиенты рассказывают вам своё видение, то уточните самые важные детали – нужно чётко понимать, что конкретно хочет видеть клиент. И не пытайтесь сразу накрутить множество дополнительных функций – начните с самого базового и простого.
Также не задавайтесь вопросами о том, как это всё должно будет выглядеть и как вы это должны написать. Пока что неважно, каким образом мы будем исполнять конкретное требование – какие классы, библиотеки и инструменты в общем понадобятся. Не важно «как» что-то будет происходить. Важно «что».
Так что вместо размышлений о том, где поместить какие кнопочки да какую коллекцию лучше выбрать для представления данных, начните с FURPS.
Functionality — Функциональные требования. Что программа обязана делать: её главные возможности и самые очевидные функции.
Usability — Требования к использованию. Какой программа должна быть для юзера: эстетика, удобство. Нужно выдвинуть требования, которые обеспечат максимально интуитивное использование для вашего юзера (поэтому стоит учесть уровень его знакомства с технологиями: например, нужны ли подсказки или можно быть кратким?).
Reliability — Требования к надежности. Насколько стабильным является среда? Отсюда можно понять, как часто могут происходить сбои. Как справляться с нагрузкой и как восстанавливать систему после этих сбоев?
Performance — Требования к производительности. Как и надёжность, эти требования можно описать числами: время отклика, использование внешних ресурсов, эффективность, масштабируемость.
Supportability — Требования к поддержке. Нужно обеспечить возможность тестировать программу, масштабировать и изменять её.
На примере моего воображаемого приложения для брони билетов в кино требования к системе были бы следующими:
1. Должна позволять посмотреть свободные места на любой открытый сеанс
2. Должна позволять бронировать конкретное место на любой открытый сеанс.
3. Должна позволять бронировать блок мест.
4. Должна позволять отменять бронь
5. Должна оповещать зрителей о переносе или отмене запланированного сеанса.
6. Должна предоставлять информацию о сеансах и фильмах.
7. Должна предоставлять информацию о залах.
8. Должна позволять регистрироваться постоянным клиентам.
9. Должна хранить историю билетов зрителя.
10. Должна позволять дополнять расписание новыми сеансами.
11. Должна позволять обновлять информацию о сеансах и фильмах.
12. Должна позволять запрещать бронировать определённые места на некоторые сеансы.
Это всё функциональные требования, которые описали здесь и взгляд со стороны юзера, и со стороны администратора, который будет заниматься обновлением данных. Но кроме этого есть и требования из других категорий.
Приложение должно быть понятным пользователю Приложение должно быть доступным для людей с проблемами со зрением. (требование к юзабилити) Система должна быстро работать при нагрузке в несколько человек (скажем, не больше десяти – в жизни, этот момент, конечно, более серьёзно надо обдумать). Система должна работать 24/7 (неважно, когда работает кинотеатр – это как раз требование к надёжности) Система должна обеспечить защиту персональных данных зарегистрированных пользователей.
Пока хватит. Даже довольно много получилось. Но вроде бы я не сильно увлёкся. И вы тоже не увлекайтесь. Я вот ещё думал добавить функцию рассылки, но это всё можно добавить потом. Первичная функция приложения всё же – бронирование билетов, а все эти письма не так уж и важны, приложение вполне справится и без него.
Требования FURPS+
Также существует расширенная модель с четырьмя дополнительными категориями:
Design. Какие конкретные ограничения накладываются на структуру приложения: нужно ли использовать конкретные инструменты?
Implementation. Будет ли обязательно использоваться конкретный язык или это не так важно? Нужно ли применить конкретные методики? Или следовать стандартам?
Interface. Здесь речь не о пользовательском интерфейсе, как было ранее, а о внешних системах и форматах данных. Есть ли подобные ограничения?
Physical. Физические ограничения накладываются на аппаратные средства и окружающую среду. Например, температура и влажность в комнате, где будут находиться сервера или площадь серверной комнаты.
В случае с небольшими учебными и прочими схожими проектами эти требования опускаются, так как чаще всего требования выдвигаются заранее. Я вот пишу на Java, ноутбук у меня один, да и комната только та, в которой я буду сидеть.
Когда я был в универе, то требования также выдвигались к версии языка, рекомендовались приложения – самому думать об инструментах не приходилось. Но в более серьёзных моментах может быть важно заранее задокументировать информацию о стандартах, законах, физических возможностях машин в компании и т. д.
В общем, если FURPS больше про добавление интересных и полезных функций и характеристик, то этот + больше про ограничения, которые накладываются на ваше приложение (чаще всего) извне.
Сценарии использования/ Прецеденты. Use Case и User Story
Когда вы определитесь, что должна делать сама система, пора сместить фокус на юзеров и то, как они могут достичь своих целей. Итак, на этом этапе нужно ответить на три вопроса:
Какая цель, кто главное действующее лицо и как эту цель достичь
Сначала определить действующие лица. Кто будет взаимодействовать с вашей системой? Кто запускает процессы? Это может быть лишь один юзер/игрок в случае с компьютерной игрой. А если система сложнее, пользователей может быть больше.
В моём примере с системой брони отелей это, как минимум, ещё и администратор – ведь кому-то нужно будет обновлять данные! У кассира тоже будут немного другие мотивы и цели при пользовании системой, поэтому и его можно выделить отдельно. И, думаю, что уместно в моём случае сказать, что сторонние приложения тоже смогут пользоваться моей системой (отличный пример – это API, которые предоставляют информацию, а обрабатывают её уже приложения на стороне).
Цель обычно можно описать глаголом. Поэтому она получается короткой и ясной: Купить билет, проверить наличие мест, отменить заказ.
После этого составляется сценарий. Как же достичь эту цель? Можно описать алгоритм по пунктам или выдать всё текстом, но всё ещё нельзя вдаваться в технические подробности. Не нужно превращать этот курс в написание псевдокода.
Пример кейса:
Купить билет Актор: Зритель, стороннее приложение Условие: Известна дата и время 1. Проверить, есть ли свободные столики 2. Выбрать подходящий столик 3. Оформить бронь на имя/телефон 4. Получить код брони
Обратите внимание, что я добавил в кейс условие. Чтобы забронировать билет, пользователь должен уже определиться с датой, временем и фильмом, который он хочет увидеть. Стороннее приложение тоже должны эти данные со своего пользователя вытянуть – иначе смысла в такой операции не будет.
Кроме условия компактный кейс можно расширить и добавить туда ещё много деталей вторичные действующие лица, приоритет и т. д. Но всё это может иметь смысл только в больших компаниях, где разработка проходит в разных офисах и необходимо документировать каждую деталь. В остальных случаях такое может лишь снова замедлить переход непосредственно к написанию кода, а не облегчить процесс разработки.
И если вам больше нравится графическое представление информации, то после этого можно нарисовать диаграмму. Как рисовать UML-диаграммы, я тут рассказывать не буду, но они довольно просто рисуются. Рисуете человечков или квадратики, символизирующие других юзеров, и кружочки для кейсов. И ставите между ними стрелочки.
Если такие кейсы кажутся слишком детальными и «официозными», то в проектировании также можно обратиться к User stories – коротким историям, которые концентрируются на одной конкретной цели для одного юзера. Например,
Как клиент кинотеатра, я хочу проверить, есть ли доступные места на сеанс, чтобы приехать и посмотреть фильм. Как клиент кинотеатра, я хочу забронировать билет на конкретное место, чтобы не стоять в очереди перед просмотром фильма. Как клиент кинотеатра, я хочу отменить свою бронь. Как кассир кинотеатра, я хочу быстро забронировать несколько билетов, чтобы показать высокий уровень сервиса. Как администратор кинотеатра, я хочу ограничить число доступных мест на сеанс, чтобы соблюсти ограничения в связи с эпидемией. Как администратор кинотеатра, я хочу изменить расписание сеансов, чтобы у зрителей были свежие данные.
Истории короче, они описываются неформальным языком и служат для начала дискуссии с вашими коллегами или с самим собой. Кейсы всё же более подробные, они подразумевают, что вы их каким-то образом документируете и можете обратиться к ним при разработке. То есть это не приглашение к раздумыванию и обсуждению, а его результат со всеми необходимыми деталями. При этом не обязательно использовать всё это сразу – выбирайте, особенно для учебных и небольших проектов только те способы, которые помогают вам, а не нагружают бумажной работой, лишь отдаляя непосредственно разработку.
Что дальше?
А вот после этого уже можно раздумывать над тем, как всё это будет выглядеть у вас в программе. Выявите сущности (если речь идёт о БД) и классы (если парадигма ООП), определите отношения между ними и опишите обязанности каждого класса. Но это всё уже совсем другая история. Главное, что на этот момент у вас есть понимание будущей системы и описание того, что она должна делать, как должна себя вести и даже небольшие фрагменты алгоритмов.
Дополнительная литература
- Karl Wiegers – Software Requirements (Разработка требований к программному обеспечению)
- Suzanne Robertson, James Robertson – Mastering the Requirements Process: Getting Requirements Right (русский перевод не нашёл, но, возможно, он тоже существует)
- Alistair Cockburn – Writing Effective Use Cases
Также я видел подходящую информацию в лекциях, туториалах и статьях по Agile и Scrum – там тоже частенько рассказывают о user stories и прочих деталях разработки требований и обсуждения концепции приложения, в том числе с другими людьми, если вы работаете в команде.
Zimowski Journal 