Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - minona

Страницы: « 1 2 3 4 5 »
46
чем дальше в лес...

Спасибо создателям форма, за столь обширную просветительскую работу в сфере UML

minona,
Ну честное слово, что-то уж совсем не то на диаграммах изображено. Это примерно тоже самое, что камнем заколачивать гвозди, можно, но для этого есть другие диаграммы инструменты.

А как лучше поступить? Есть ли средства проектирования именно WEB-сайтов?

как правильно технически организовать описание проекта на VP?

На форуме вычитали про ППЦ (проблемы, потребности, цели) сейчас их расписываем

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

По этому вопросу вспомнился анекдот...
В компании сломался сервер, нарушилась переадресация и т.п. - решали своими силами неделю, вторую - ничего не помогает... Вызвали специалиста со стороны... Он сел за компьютер, через 10 минут встал - говорит: "Готово"!
Директор счастлив, радуется, спрашивает, - сколько?

Программист - 500 у.е.!
Директор: за что?? За 10 минут работы?
Программист - нет, за то что я знал как...

48
При создании нового сайта особое внимание следует уделять сбору материалов перед этапом проектирования. Как вы думаете, по какому техническому заданию работа будет вестись быстрее: по сухому описанию функционала каждого раздела, либо по такому же описанию, но наполненному конкретными примерами? Когда дизайнеру не нужно придумывать рыбный текст и искать картинки на Яндексе, а можно просто сделать копи-пэйст из ТЗ? Когда верстальщик будет иметь примерное представление об объёмах планируемых к публикации текстов потому что они у него перед глазами? Когда программист, работая над полями в базе данных, будет иметь перед глазами актуальный элемент каталога со всеми его параметрами?

— А вы что, не можете спроектировать сайт без этих материалов? Я же вам сказал, что я хочу на нём видеть, и какие задачи он должен выполнять, — это произносится с неподдельным удивлением на лице. А ещё с лёгким амбре неуверенности в компетенции исполнителя.
— Конечно, можем, — отвечает проектировщик, пожав плечами.

С этого момента время на создание сайта увеличивается в два, два с половиной раза. Причина этому проста. Проектировщик лишь предполагает, какой контент будет ставиться на сайт. Ключевое слово — предполагает.
— Приведите пять примеров товаров из вашего каталога;
— Напишите тестовую новость для вашего будущего сайта;
— Предоставьте, пожалуйста, актуальную контактную информацию вашей компании.
Я выбрал три очень простых и очевидных вещи. Сайт можно спроектировать и без этих материалов. Каждый из трёх вышеперечисленных пунктиков можно заменить кипами вопросов, раскрывающих тему сисек.
— Сколько категорий товаров будет в вашем каталоге?
— Каждый товар будет сопровождаться одним или несколькими изображениями?
— У вас есть своя студия, чтобы сфотографировать шесть тысяч наименований товаров с трёх сторон?
— У различных групп товаров есть повторяющиеся характеристики?
— Как часто вы планируете писать новости?
— Кто будет этим заниматься?
— Будут ли новости с других сайтов с указанием источников?
— Готовы ли вы искать тематические картинки, иллюстрирующие каждую новость?
— Сколько офисов в вашей компании?
— Сколько есть отделов и какие?
— У каждого отдела свой телефон?
— Добавочные номера?
— Кто будет проверять почту?
И так далее, и тому подобное. И хорошо, если заказчик действительно готов выложить круглую сумму на разработку и «всецело положиться на профессионалов». В действительности же в связи с ограниченными бюджетами он старается сэкономить на чём угодно, а «профессионалами» называет вас в таком контексте:
— Вы же профессионалы. Зачем вам нужна вся эта информация для разработки сайта?
И получается, что к моменту сдачи проекта начинаются бесконечные вереницы корректировок, внесений правок, затем исправлений ошибок в связи с внесениями правок. После этого поднимается техническое задание и становится видно, что оно не совпадает с тем, что имеется на выходе. К этому моменту уже давно истрачены все возможные человекочасы. Текст на главной странице слишком громоздкий и то, что на дизайне умещалось без полосы прокрутки, теперь разбросано на три страницы вниз. В разделе с контактной информацией оказался лишь адрес электронной почты, одинокий и несчастный, а в каталоге вместо шести тысяч наименований товаров есть лишь несколько десятков, фильтрация по которым выдаёт нам в среднем по одному результату на страницу.

— А вы что, не можете спроектировать сайт без этих материалов? Я же вам сказал, что я хочу на нём видеть, и какие задачи он должен выполнять, — это произносится с неподдельным удивлением на лице. А ещё с лёгким амбре неуверенности в компетенции исполнителя.
— Конечно, можем, — вновь отвечает проектировщик.

49
Всем известно, что в формате doc или txt можно написать задание, описать принципы работы системы, в общем-то - текстового формата должно хватить для того, чтобы более менее начать.
Но, перед нами стоит задача намного глубже - создать проект в программе Visual Paradigm...

При созДании проектной документации к уже работающему сайту особое внимание следует чему?
Как вы думаете, по какому техническому заданию работа будет вестись быстрее: по сухому описанию функционала каждого раздела, либо по такому же описанию, но наполненному конкретными примерами?
Когда дизайнеру не нужно придумывать рыбный текст и искать картинки на Яндексе, а можно просто сделать копи-пэйст из ТЗ? Когда верстальщик будет иметь примерное представление об объёмах планируемых к публикации текстов потому что они у него перед глазами? Когда программист, работая над полями в базе данных, будет иметь перед глазами актуальный элемент каталога со всеми его параметрами?
Ведь это так удобно...

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

Не помешает помнить также и эти факты:

    * Построение модели информационной системы (ИС) до её программной разработки столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют «понять» разрабатываемую систему во всей ее полноте.
    * По предположению Страуструпа: «Цель проектирования — выявление ясной и относительно простой внутренней структуры, иногда называемой архитектурой… Проект есть окончательный продукт процесса проектирования».
    * Моделирование широко распространено во всех инженерных дисциплинах, в значительной степени из-за того, что оно реализует принципы декомпозиции, абстракции и иерархии. Каждая модель описывает определенную часть рассматриваемой системы, а мы в свою очередь строим новые модели на базе старых, в которых более или менее уверены. Модели позволяют нам контролировать наши неудачи. Мы оцениваем поведение каждой модели в обычных и необычных ситуациях, а затем проводим соответствующие доработки, если нас что-то не удовлетворяет.



С чего начать проектирование?

Первое, что нужно сделать – это определить пользователей будущей системы и, ориентируясь на их пожелания, сформулировать основные требования к программному продукту. Проще говоря, нужно узнать, какие действия пользователи хотят автоматизировать (переложить на систему). Затем, постепенно ограничивая или, наоборот, расширяя, круг функциональности и пользователей мы будем уточнять границу системы. Т.е. зная внешних, по отношению к системе, исполнителей и требования к ней, мы можем получить более четкую границу проекта.

Доступная пользователям функциональность проекта описывается в документе «Описание требований». Это нужно для того, чтобы между клиентами и разработчиками было достигнуто понимание по вопросу о том, что система должна делать и чего не должна. Этим занимается аналитик.

Чтобы верно определить требования и правильно разработать систему, ключевые разработчики – в частности, архитектор и некоторые старшие аналитики – должны понимать контекст, в котором она работает. Для его описания имеется 2 подхода:

    * Моделирование предметной области. Модель предметной области описывает важные понятия контекста как объекты предметной области (другими словами, это словарь терминов, который поможет каждому, кто работает над системой, лучше её «понимать»).
    * Бизнес-моделирование. Бизнес-модель же определяет, какие бизнес-процессы должна поддерживать система. Кроме идентификации вовлеченных в бизнес бизнес-объектов или объектов предметной области, бизнес-моделирование также устанавливает компетентности, необходимые для процессов: работников, их обязанности и действия, которые они должны выполнять. Это знание является определяющим при идентификации вариантов использования.

Подготовив всю эту документацию, мы можем приступать к следующему этапу — проектирование диаграмм прецедентов...

Но это не так просто, как кажется...

50
Кстати, есть задумка, расписать систему по такому принципу, как в файле прикрепленном.
Есть смысл делать такое?

51
кстати, для yii есть диаграмма классов сделанная в VP
http://caveman.ru/yii.1.1.2r2135.png

подробности тут http://caveman.ru/page/yii-class-diagram

52
http://yiiframework.ru/ - довольно не плохой, ООП фреймворк, причем в нем, реализован почти на 100% чистый ООП

Существует очень жесткая потребность создать новый функционал, изменить имеющийся. Объемность работ большая + каждый новый напарник в этом бизнес-проекте тут же начинает все с нуля: ознакомление, исследование функций и т.д.

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

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

53
Подскажите пожалуйста

54
ВЫПОЛНЕНИЕ ЗАДАЧ
Участники: ПОСЕТИТЕЛЬ ПОЛЬЗОВАТЕЛЬ АДМИНИСТРАТОР
Основные атрибуты задачи
Подразумевается общее использование того или иного действия.
Определяемые ПОЛЬЗОВАТЕЛЬ
1.   Ожидаемый результат (самореклама, информация, контакты, события)
2.   Основное действие (создает, управлять, запросить, опубликовать,  )
3.   Цель задачи (межличностные коммуникации, самоидентификация)
4.   Срок получения результата (текущий)
Определяемые ПОСЕТИТЕЛЬ
5.   Основное действие (регистация, авторизация)
Определяемые АДМИНИСТРАТОР
Принципы
1.   ПОСЕТИТЕЛЬ имеет право просматривать данные ПОЛЬЗОВАТЕЛЬ
2.   ПОЛЬЗОВАТЕЛЬ имеет право скрыть данные от неавторизованного ПОСЕТИТЕЛЬ
3.   АДМИНИСТРАТОР может в любой момент заблокировать деятельность ПОСЕТИТЕЛЬ в системе
Основной поток
1.   ПОЛЬЗОВАТЕЛЬ формирует страницу с личной информацией ВИЗИТКА и устанавливает права доступа к этой информации для ПОСЕТИТЕЛЬ и других ПОЛЬЗОВАТЕЛЬ – для АКТОР
2.   ПОСЕТИТЕЛЬ знакомится с информацией ПОЛЬЗОВАТЕЛЬ регистрируется и налаживает СВЯЗЬ с ПОЛЬЗОВАТЕЛЬ
3.   ПОЛЬЗОВАТЕЛЬ создает публикует материал
4.   другой ПОЛЬЗОВАТЕЛЬ его комментирует
5.   


вот, сделали набросок по верной дороге идем?

55
... что программист запросит у вас в конечном итоги модели имплементации :-), по которым тупо будет генерить код....
На вашем месте я бы все-таки начал с более внятной формулировки а) идеологии сайта, б) целей и задач ...

А по-сути ... начните с описания сценариев взаимодействия и модели предметной области ....

Вот так и программист мне говорит, мол сначала:

ОПРЕДЕЛЯЕМ ТРЕБОВАНИЯ К СИСТЕМЕ:
 - диаграммы прецедентов
 - диаграммы деятельности

АНАЛИЗ
 - диаграмма компонентов
 - диаграмма последовательностей
 - диаграмма кооперации

ПРОЕКТИРОВАНИЕ
 - диаграмма классов
 - диаграмма развертывания

КОД
 - диаграмма состояний
 - исходные коды

Вот по этому пути программист предлагает работать.


а) идеологии сайта, б) целей и задач
это в общем-то уже расписано все много раз - и только когда стали применять UML то открылись глаза на реализацию некоторых подходов

Посему, сейчас, нужно прежде всего определить старт - точнее - взаимодействия...

56
Пример сценария взаимодействия «Человек-Человек»:
http://www.scribd.com/doc/32795371/Typical-general-short-term-task-execution-via-delegation-scenario

Вот, запишу пока сюда... на будущее

57
minona,
Ну честное слово, что-то уж совсем не то на диаграммах изображено. Это примерно тоже самое, что камнем заколачивать гвозди, можно, но для этого есть другие диаграммы инструменты.

Так вот и я вижу, что на диаграммах, вообще каша, ну не то там изображено, совсем не то, не так нужно делать!

При таком - точно нет :)
Если он вам не нужен, то другим тем более.
Сколько у вас пользователей? А активных?

Сейчас проект, это чуть чуть другое, не то, что изображено на диаграммах, посещает в день его примерно 500-600 человек, при 2000 просмотрах...
Но, так как посещаемость растет, и сус, которая стоит сейчас просто не справится с нагрузкой в 3-5 тыс. уник...
Поэтому решили переносить проект на YII. Естественно, параллельно, поменять логику работы в проекте. Его суть оставить, логику - поменять.

Я могу, в принципе сюда выложить ТЗ (начальное) и мы, если не сложно, вместе его проанализируем.

58
немного о системе:

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

Так как проект уже работает, то основная задача данного треда, поставленных задач, оптимизировать имеющуюся систему, свести к минимуму ошибки, используя опыт предыдущих разработок.
Параллельно необходимо разрабатывать документацию пользователя – внедряя компонент Справка (как пользоваться системой)
Современный ритм жизни, диктует новые условия! Людям нужна мобильность в общении, не запирающая их в рамки «браузера» регистрации и авторизации.
Сайт создается для:
•   посетитель
•   пользователь
•   ВИП
•   администратор
Основная цель создания сайта, создание системы с максимальной возможностью расширяемости и универсальности в ее элементах
Галереи пользователей – объединяются в БАЗЫ по тому же принципу как записи в блоге объединяются в Новое в блогах и т.п.

Во вложениях еще несколько диаграмм, для затравки. Проект рисуется в VP - есть SVN на котором синхронизируем работу.

59
Леоненков ничего не даст. Читаем по ВИ в первую очередь Коберна и наш ФАК на гл. странице.
И всегда помним, что ВИ - это ЦЕЛЬ ПОЛЬЗОВАТЕЛЯ по отношению к Системе.

Хорошо - а как быть, если система планируется не как человек-система, а как человек-человек?
В ней все взаимодействия должны быть сведены к обмену данными между пользователями. Такого, в сети я не нахожу!

60
дальше.
Так как не хочется строить что-то обычное и есть понимание, что проект должен быть на ООП и ООАП - то задались вопросом организации не только структуры, но и информации (кодов)
Например, выделили, что система содержит сообщения (в составе комментариев, например), посты (отдельное сообщение блога) и статьи (новости, WIKI и т.п.)

Страницы: « 1 2 3 4 5 »