Пример отображения динамической схемы
|
---|
Дата последнего изменения: 16.01.2024
Необходимый этап для любого проекта, но если в малых ещё можно что-то делать через постоянное обращение к клиенту: "делаем так?", то в случае большого или высоконагруженного проекта без проведения этого этапа в полном объёме реализовать проект невозможно.
Анализ требований действительно необходим, когда речь идет о больших сложных проектах со сроком разработки больше месяца. Необходимо вести предварительную работу, в которую входит настройка необходимых инструментов, налаживание связи с людьми заказчика, наиболее разбирающимися в сути вопроса, а также изучение самой предметной области сайта.
В случае сложной предметной области, возможно, заказчик сам не может толком собрать такие требования. Часто клиент приходит к исполнителю с "кашей" в голове. Этап сбора и анализа требований в этом случае - это упорядочивание и формальная регистрация этой "каши". И согласование полученного с клиентом.
В случае больших и сложных проектов этап сбора и анализа требований рекомендуется проводить отдельным пунктом в договоре с отдельной сметой и оплатой. Это обезопасит как клиента, так и исполнителя от недобросовестных или непрофессиональных действий.
Требования делятся на функциональные и нефункциональные, то есть описывающие поведение системы (требуемую функциональность) и различные особенности поведения или эксплуатации системы, например, требования к удобству использования, надежности, производительности и тому подобное.
Функциональные требования - это пользовательские сценарии, которые должны быть реализованы в системе. Если они работают так как нужно клиенту, то эти требования выполнены.
Нефункциональные требования оформляются отдельно и должны учитывать экстремальные особенности которые должна выдерживать система. Одним из самых оптимальных способов выполнения нефункциональных требований на данный момент является использование веб-кластера, решающего задачи отказоустойчивости (дублирует несколько узлов), масштабируемости (можно добавлять сервера приложений и базы данных), надёжности (данные распределены по нескольким машинам).
Сбор и анализ требований может быть (в случае больших и сложных проектов - должен быть) итерационным, пошаговым. В противном случае можно потерять очень много времени на данном этапе, для сложных систем (типа Softkey) - до года. В этом случае возникают свои риски: не учесть всего и встать перед необходимостью переделки.
Надо организовать с клиентом серию встреч в доверительной атмосфере. Клиент должен увидеть что вы не "отжимаете" деньги, а пытаетесь вместе с ним понять что ему нужно, решить его задачу эффективно, дёшево, быстро и максимально просто. Заказчик должен быть уверен, что он в любой момент может прийти, увидеть доступные документы по работе над его проектом. Это называется выстроить атмосферу Agile манифеста. В этом случае клиент будет максимально открыт, сообщать всё что он знает о проблеме.
Эта же мера позволит снизить риск формализации, когда стороны переводят общение в формат e-mail с целью фиксировать всё общение на случай непонимания и претензий. Такой подход сразу лишает стороны желания разбираться и понимать. Проектирование переходит в фазу юридических перестраховок, подстилания "соломки", что резко снижает вероятность удачной реализации проекта.
Без создания доверительной атмосферы возможны попытки клиента скрыть от разработчика бизнес-процесс и цели. Это когда задачи формулируются без разъяснения для чего это надо. Заказчик обрисовывает для себя проблему, но не зная принципов работы CMS и ее возможностей, придумывает решение, которое крайне сложно реализовать. А при этом эту же проблему можно решить совершенно иначе, например, проставлением галки где-то в админке. Но заказчик не объясняя для чего это надо, заявляет требование сделать именно то, что он придумал. В итоге разработчик тратит время впустую. Заказчик тратит деньги впустую.
Очень важно "качество" менеджера, занимающегося проектом со стороны исполнителя. Менеджер должен сам "прочувствовать и вжиться" в проект, должен научиться говорить с клиентом на его языке, на языке его предметной области, стать экспертом, "хранилищем знаний" для разработчиков. Менеджер должен научить предметной области ведущего разработчика или аналитика.
Существует несколько методологий сбора и анализа требований. Существуют и разные инструменты сбора и анализа требований. Задача, которая стоит перед исполнителем - выбрать именно те методы и инструменты, которые подойдут к конкретному проекту. Максимально простые и эффективные методы и инструменты.
Есть несколько инструментов:
Это статическая модель. На неё переносятся термины из словаря и устанавливаются связи и отношения между сущностями. Здесь потребуется серьёзная логическая работа со стороны Клиента. Он должен показать и обосновать почему эта связь есть, откуда она берётся. На больших проектах таких диаграмм может быть несколько (встречается до 10) и каждая охватывает какую-то часть системы.
Пример отображения динамической схемы
|
---|
В простом случае описываются просто цепочки действий, в более формальных случаях сложных предметных областей лучше использовать формат Сценария поведения.
Если требуется более глубокая проработка требований (это может потребоваться когда в проекте появляются какие-то алгоритмы вычисления, шифровки, работы банкоматов, корзины), то используются:
Возможно вам ещё понадобится "картинка" того, как вы будете размещать всё на серверах: Диаграмма развёртывания Deployment Diagram.
Пример диаграммы развёртывания
|
---|
Возможна ситуация, когда требование озвучено, но не понятно ни клиенту, ни исполнителю. Это не страшно. Его надо зафиксировать не описывая. Впоследствии к нему можно вернуться.
Работа по сбору, формализации и структурирования требований не требует каких-то сложных и дорогих программных инструментов. Всё можно выполнять в обычном Excel.
Основные риски при сборе и анализе требований:
Иногда проблема возникает при недобросовестности, либо некомпетентности менеджера клиента, ведущего проект. Решение: требовать от клиента адекватного и добросовестного сотрудника.
Сбор требований - сложный этап, который крайне сложно завершить в один заход. Как правило, Клиент не может сразу высказать все свои "хотелки". Это процесс долгий в силу того, что осознание потребностей приходит в результате постоянного контакта клиента с исполнителем, в результате итерационной реализации уже сформулированных заданий.
Переход к этапу проектирования можно выполнять после получения некоторых документов из перечисленного выше списка, достаточных для осознанного начала работ по проектированию. Риск возникновения каких-то не выявленных требований, незадекларированных сущностей при этом существенно снижается.