Всем известно, что в формате doc или txt можно написать задание, описать принципы работы системы, в общем-то - текстового формата должно хватить для того, чтобы более менее начать.
Но, перед нами стоит задача намного глубже - создать проект в программе Visual Paradigm...
При созДании проектной документации к уже работающему сайту особое внимание следует чему?
Как вы думаете, по какому техническому заданию работа будет вестись быстрее: по сухому описанию функционала каждого раздела, либо по такому же описанию, но наполненному конкретными примерами?
Когда дизайнеру не нужно придумывать рыбный текст и искать картинки на Яндексе, а можно просто сделать копи-пэйст из ТЗ? Когда верстальщик будет иметь примерное представление об объёмах планируемых к публикации текстов потому что они у него перед глазами? Когда программист, работая над полями в базе данных, будет иметь перед глазами актуальный элемент каталога со всеми его параметрами?
Ведь это так удобно...
Поскольку зачастую над проектом работает большое количество людей (архитекторы, клиенты и пр.), оперирующих различной информацией, которая в процессе уточняется, то, естественно, что для построения модели удобно использовать какой-то инструмент. С данной задачей могут, конечно, и бумага с карандашом справиться, но, пожалуй, это не является наиболее эффективным решением подобного рода проблем.
Не помешает помнить также и эти факты:
* Построение модели информационной системы (ИС) до её программной разработки столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют «понять» разрабатываемую систему во всей ее полноте.
* По предположению Страуструпа: «Цель проектирования — выявление ясной и относительно простой внутренней структуры, иногда называемой архитектурой… Проект есть окончательный продукт процесса проектирования».
* Моделирование широко распространено во всех инженерных дисциплинах, в значительной степени из-за того, что оно реализует принципы декомпозиции, абстракции и иерархии. Каждая модель описывает определенную часть рассматриваемой системы, а мы в свою очередь строим новые модели на базе старых, в которых более или менее уверены. Модели позволяют нам контролировать наши неудачи. Мы оцениваем поведение каждой модели в обычных и необычных ситуациях, а затем проводим соответствующие доработки, если нас что-то не удовлетворяет.
С чего начать проектирование?
Первое, что нужно сделать – это определить пользователей будущей системы и, ориентируясь на их пожелания, сформулировать основные требования к программному продукту. Проще говоря, нужно узнать, какие действия пользователи хотят автоматизировать (переложить на систему). Затем, постепенно ограничивая или, наоборот, расширяя, круг функциональности и пользователей мы будем уточнять границу системы. Т.е. зная внешних, по отношению к системе, исполнителей и требования к ней, мы можем получить более четкую границу проекта.
Доступная пользователям функциональность проекта описывается в документе «Описание требований». Это нужно для того, чтобы между клиентами и разработчиками было достигнуто понимание по вопросу о том, что система должна делать и чего не должна. Этим занимается аналитик.
Чтобы верно определить требования и правильно разработать систему, ключевые разработчики – в частности, архитектор и некоторые старшие аналитики – должны понимать контекст, в котором она работает. Для его описания имеется 2 подхода:
* Моделирование предметной области. Модель предметной области описывает важные понятия контекста как объекты предметной области (другими словами, это словарь терминов, который поможет каждому, кто работает над системой, лучше её «понимать»).
* Бизнес-моделирование. Бизнес-модель же определяет, какие бизнес-процессы должна поддерживать система. Кроме идентификации вовлеченных в бизнес бизнес-объектов или объектов предметной области, бизнес-моделирование также устанавливает компетентности, необходимые для процессов: работников, их обязанности и действия, которые они должны выполнять. Это знание является определяющим при идентификации вариантов использования.
Подготовив всю эту документацию, мы можем приступать к следующему этапу — проектирование диаграмм прецедентов...
Но это не так просто, как кажется...
Проект по уму на VP