Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: minona от 14 Июня 2010, 22:08:36
-
Итак, есть проект - интернет-сайт - виртуальный мир с блогами, форумом, клубами и доской объявлений...
В этом году, ему исполняется два года. Проект живет, постепенно набирая обороты. Но...
Закралась в душу мысль, что не туда идет развитие. Нет будущего при таком положении..
Было принято решение, переводить проект на yii-фреймворк.
Но для начала - все спланировать, как положено. Для решения этой задачи, был выбран
Visual Paradigm
Собственно, описание функционала (то, что есть и что должно быть) в полном объеме занимает порядка 60 стандартных вордовских листов (это по минимуму)
НО, так как работаем с UML то не покидает мысль о том, что эти вордовские листы можно перевести на правильный язык умэля...
Программист сказал - спроектируй мне систему в VP и я на основе проекта буду программировать. Но как спроектировать - толком не объясняет, мотивируя тем, что ему не хочется заниматься всем проектом, что за мной - проектирование, за ним - программирование...
подскажите с чего начать, а?
-
дальше.
Так как не хочется строить что-то обычное и есть понимание, что проект должен быть на ООП и ООАП - то задались вопросом организации не только структуры, но и информации (кодов)
Например, выделили, что система содержит сообщения (в составе комментариев, например), посты (отдельное сообщение блога) и статьи (новости, WIKI и т.п.)
-
Во-первых, модели не заменяют текст с требованиями. Нужна их (текста и модели) наилучшая комбинация именно для вас.
Во-вторых, у Вас какая роль? Почему именно Вы должны проектировать, когда совсем не знаете как и почему именно на юмле?
Например, выделили, что система содержит сообщения (в составе комментариев, например), посты (отдельное сообщение блога) и статьи (новости, WIKI и т.п.)
Ну вот и отлично, у Вас уже вырисовывается модель предметной области, которую можно оформить в виде Д Классов.
-
немного о системе:
Основная цель проекта достичь самоидентификации пользователей, предоставлению возможности связи между пользователями и обеспечения доступа к межличностным коммуникациям (блогам, форумам, клубам и т.д.)
Основная предметная область проекта – предоставление максимума информации в тематической области.
В системе на первый план выходит взаимодействие типа Человек – Человек.
Так как проект уже работает, то основная задача данного треда, поставленных задач, оптимизировать имеющуюся систему, свести к минимуму ошибки, используя опыт предыдущих разработок.
Параллельно необходимо разрабатывать документацию пользователя – внедряя компонент Справка (как пользоваться системой)
Современный ритм жизни, диктует новые условия! Людям нужна мобильность в общении, не запирающая их в рамки «браузера» регистрации и авторизации.
Сайт создается для:
• посетитель
• пользователь
• ВИП
• администратор
Основная цель создания сайта, создание системы с максимальной возможностью расширяемости и универсальности в ее элементах
Галереи пользователей – объединяются в БАЗЫ по тому же принципу как записи в блоге объединяются в Новое в блогах и т.п.
Во вложениях еще несколько диаграмм, для затравки. Проект рисуется в VP - есть SVN на котором синхронизируем работу.
-
Я в очередной раз понял, какое вредное название у этого сайта.
-
minona,
Ну честное слово, что-то уж совсем не то на диаграммах изображено. Это примерно тоже самое, что камнем заколачивать гвозди, можно, но для этого есть другие диаграммы инструменты.
-
Итак, есть проект - интернет-сайт - виртуальный мир с блогами, форумом, клубами и доской объявлений...
В этом году, ему исполняется два года. Проект живет, постепенно набирая обороты. Но...
Закралась в душу мысль, что не туда идет развитие. Нет будущего при таком положении..
При таком - точно нет :)
Если он вам не нужен, то другим тем более.
Сколько у вас пользователей? А активных?
-
minona,
Ну честное слово, что-то уж совсем не то на диаграммах изображено. Это примерно тоже самое, что камнем заколачивать гвозди, можно, но для этого есть другие диаграммы инструменты.
Так вот и я вижу, что на диаграммах, вообще каша, ну не то там изображено, совсем не то, не так нужно делать!
При таком - точно нет :)
Если он вам не нужен, то другим тем более.
Сколько у вас пользователей? А активных?
Сейчас проект, это чуть чуть другое, не то, что изображено на диаграммах, посещает в день его примерно 500-600 человек, при 2000 просмотрах...
Но, так как посещаемость растет, и сус, которая стоит сейчас просто не справится с нагрузкой в 3-5 тыс. уник...
Поэтому решили переносить проект на YII. Естественно, параллельно, поменять логику работы в проекте. Его суть оставить, логику - поменять.
Я могу, в принципе сюда выложить ТЗ (начальное) и мы, если не сложно, вместе его проанализируем.
-
Пример сценария взаимодействия «Человек-Человек»:
http://www.scribd.com/doc/32795371/Typical-general-short-term-task-execution-via-delegation-scenario
Вот, запишу пока сюда... на будущее
-
Итак, есть проект - интернет-сайт - виртуальный мир с блогами, форумом, клубами и доской объявлений...
В этом году, ему исполняется два года. Проект живет, постепенно набирая обороты. Но...
Закралась в душу мысль, что не туда идет развитие. Нет будущего при таком положении..
Было принято решение, переводить проект на yii-фреймворк.
Но для начала - все спланировать, как положено. Для решения этой задачи, был выбран
Visual Paradigm
Собственно, описание функционала (то, что есть и что должно быть) в полном объеме занимает порядка 60 стандартных вордовских листов (это по минимуму)
НО, так как работаем с UML то не покидает мысль о том, что эти вордовские листы можно перевести на правильный язык умэля...
Программист сказал - спроектируй мне систему в VP и я на основе проекта буду программировать. Но как спроектировать - толком не объясняет, мотивируя тем, что ему не хочется заниматься всем проектом, что за мной - проектирование, за ним - программирование...
подскажите с чего начать, а?
Начните с отправки программиста "в даль светлую" с его требованием о проектировании на UML. Если это реально работающий проект, а вы оба толком не владеете ни UML как таковым, ни методологиями разработки ПО - то вы рискуете получить "аналитический паралич" в виде того, что программист запросит у вас в конечном итоги модели имплементации :-), по которым тупо будет генерить код.
На вашем месте я бы все-таки начал с более внятной формулировки а) идеологии сайта, б) целей и задач ... Например, то что вы сформулировали как цель "создание системы с максимальной возможностью расширяемости и универсальности в ее элементах ...", по сути - задача, решение которой должно служить какой-то цели. А если вы сформулируете внятно цели, то вполне может оказаться, что эти цели можно достичь различными способами, и перепроектирование не самый эффективный способ.
А по-сути ... начните с описания сценариев взаимодействия и модели предметной области ....
-
... что программист запросит у вас в конечном итоги модели имплементации :-), по которым тупо будет генерить код....
На вашем месте я бы все-таки начал с более внятной формулировки а) идеологии сайта, б) целей и задач ...
А по-сути ... начните с описания сценариев взаимодействия и модели предметной области ....
Вот так и программист мне говорит, мол сначала:
ОПРЕДЕЛЯЕМ ТРЕБОВАНИЯ К СИСТЕМЕ:
- диаграммы прецедентов
- диаграммы деятельности
АНАЛИЗ
- диаграмма компонентов
- диаграмма последовательностей
- диаграмма кооперации
ПРОЕКТИРОВАНИЕ
- диаграмма классов
- диаграмма развертывания
КОД
- диаграмма состояний
- исходные коды
Вот по этому пути программист предлагает работать.
а) идеологии сайта, б) целей и задач
это в общем-то уже расписано все много раз - и только когда стали применять UML то открылись глаза на реализацию некоторых подходов
Посему, сейчас, нужно прежде всего определить старт - точнее - взаимодействия...
-
ВЫПОЛНЕНИЕ ЗАДАЧ
Участники: ПОСЕТИТЕЛЬ ПОЛЬЗОВАТЕЛЬ АДМИНИСТРАТОР
Основные атрибуты задачи
Подразумевается общее использование того или иного действия.
Определяемые ПОЛЬЗОВАТЕЛЬ
1. Ожидаемый результат (самореклама, информация, контакты, события)
2. Основное действие (создает, управлять, запросить, опубликовать, )
3. Цель задачи (межличностные коммуникации, самоидентификация)
4. Срок получения результата (текущий)
Определяемые ПОСЕТИТЕЛЬ
5. Основное действие (регистация, авторизация)
Определяемые АДМИНИСТРАТОР
Принципы
1. ПОСЕТИТЕЛЬ имеет право просматривать данные ПОЛЬЗОВАТЕЛЬ
2. ПОЛЬЗОВАТЕЛЬ имеет право скрыть данные от неавторизованного ПОСЕТИТЕЛЬ
3. АДМИНИСТРАТОР может в любой момент заблокировать деятельность ПОСЕТИТЕЛЬ в системе
Основной поток
1. ПОЛЬЗОВАТЕЛЬ формирует страницу с личной информацией ВИЗИТКА и устанавливает права доступа к этой информации для ПОСЕТИТЕЛЬ и других ПОЛЬЗОВАТЕЛЬ – для АКТОР
2. ПОСЕТИТЕЛЬ знакомится с информацией ПОЛЬЗОВАТЕЛЬ регистрируется и налаживает СВЯЗЬ с ПОЛЬЗОВАТЕЛЬ
3. ПОЛЬЗОВАТЕЛЬ создает публикует материал
4. другой ПОЛЬЗОВАТЕЛЬ его комментирует
5.
вот, сделали набросок по верной дороге идем?
-
Подскажите пожалуйста
-
minona, а что конкретно подсказать?
а/ как правильно технически организовать описание проекта на VP?
б/ как правильно оформить все описания по проекту вообще?
Кроме того, почему существует жесткая потребность именно в UML? Вы считаете, что время которое Вы потратите на восстановление описаний проекта окупиться в любом случае? Даст ответ на мучающий Вас вопрос: куда двигаться дальше? ИМХО, я очень в этом сомневаюсь. При все сложности Вашего проекта - он довольно прозрачен, и его проблемы лежат вне компетенции самого UML.
Начните с четкого осознания проблемы.
Небольшой вопрос а что это за yii-фреймворк?
-
http://yiiframework.ru/ - довольно не плохой, ООП фреймворк, причем в нем, реализован почти на 100% чистый ООП
Существует очень жесткая потребность создать новый функционал, изменить имеющийся. Объемность работ большая + каждый новый напарник в этом бизнес-проекте тут же начинает все с нуля: ознакомление, исследование функций и т.д.
Стоит острая необходимость в инструменте, позволившим бы не только описать систему, как положено, но и дать возможность ввести справку, комментарии.
Основная зацепка, благодаря которой было принято решение разработку вести с помощью VP в том, что в дальнейшем, можно сгенерировать уже готовый код
-
кстати, для yii есть диаграмма классов сделанная в VP
http://caveman.ru/yii.1.1.2r2135.png
подробности тут http://caveman.ru/page/yii-class-diagram
-
Кстати, есть задумка, расписать систему по такому принципу, как в файле прикрепленном.
Есть смысл делать такое?
-
Всем известно, что в формате doc или txt можно написать задание, описать принципы работы системы, в общем-то - текстового формата должно хватить для того, чтобы более менее начать.
Но, перед нами стоит задача намного глубже - создать проект в программе Visual Paradigm...
При созДании проектной документации к уже работающему сайту особое внимание следует чему?
Как вы думаете, по какому техническому заданию работа будет вестись быстрее: по сухому описанию функционала каждого раздела, либо по такому же описанию, но наполненному конкретными примерами?
Когда дизайнеру не нужно придумывать рыбный текст и искать картинки на Яндексе, а можно просто сделать копи-пэйст из ТЗ? Когда верстальщик будет иметь примерное представление об объёмах планируемых к публикации текстов потому что они у него перед глазами? Когда программист, работая над полями в базе данных, будет иметь перед глазами актуальный элемент каталога со всеми его параметрами?
Ведь это так удобно...
Поскольку зачастую над проектом работает большое количество людей (архитекторы, клиенты и пр.), оперирующих различной информацией, которая в процессе уточняется, то, естественно, что для построения модели удобно использовать какой-то инструмент. С данной задачей могут, конечно, и бумага с карандашом справиться, но, пожалуй, это не является наиболее эффективным решением подобного рода проблем.
Не помешает помнить также и эти факты:
* Построение модели информационной системы (ИС) до её программной разработки столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют «понять» разрабатываемую систему во всей ее полноте.
* По предположению Страуструпа: «Цель проектирования — выявление ясной и относительно простой внутренней структуры, иногда называемой архитектурой… Проект есть окончательный продукт процесса проектирования».
* Моделирование широко распространено во всех инженерных дисциплинах, в значительной степени из-за того, что оно реализует принципы декомпозиции, абстракции и иерархии. Каждая модель описывает определенную часть рассматриваемой системы, а мы в свою очередь строим новые модели на базе старых, в которых более или менее уверены. Модели позволяют нам контролировать наши неудачи. Мы оцениваем поведение каждой модели в обычных и необычных ситуациях, а затем проводим соответствующие доработки, если нас что-то не удовлетворяет.
С чего начать проектирование?
Первое, что нужно сделать – это определить пользователей будущей системы и, ориентируясь на их пожелания, сформулировать основные требования к программному продукту. Проще говоря, нужно узнать, какие действия пользователи хотят автоматизировать (переложить на систему). Затем, постепенно ограничивая или, наоборот, расширяя, круг функциональности и пользователей мы будем уточнять границу системы. Т.е. зная внешних, по отношению к системе, исполнителей и требования к ней, мы можем получить более четкую границу проекта.
Доступная пользователям функциональность проекта описывается в документе «Описание требований». Это нужно для того, чтобы между клиентами и разработчиками было достигнуто понимание по вопросу о том, что система должна делать и чего не должна. Этим занимается аналитик.
Чтобы верно определить требования и правильно разработать систему, ключевые разработчики – в частности, архитектор и некоторые старшие аналитики – должны понимать контекст, в котором она работает. Для его описания имеется 2 подхода:
* Моделирование предметной области. Модель предметной области описывает важные понятия контекста как объекты предметной области (другими словами, это словарь терминов, который поможет каждому, кто работает над системой, лучше её «понимать»).
* Бизнес-моделирование. Бизнес-модель же определяет, какие бизнес-процессы должна поддерживать система. Кроме идентификации вовлеченных в бизнес бизнес-объектов или объектов предметной области, бизнес-моделирование также устанавливает компетентности, необходимые для процессов: работников, их обязанности и действия, которые они должны выполнять. Это знание является определяющим при идентификации вариантов использования.
Подготовив всю эту документацию, мы можем приступать к следующему этапу — проектирование диаграмм прецедентов...
Но это не так просто, как кажется...
-
чем дальше в лес...
Спасибо создателям форма, за столь обширную просветительскую работу в сфере UML
minona,
Ну честное слово, что-то уж совсем не то на диаграммах изображено. Это примерно тоже самое, что камнем заколачивать гвозди, можно, но для этого есть другие диаграммы инструменты.
А как лучше поступить? Есть ли средства проектирования именно WEB-сайтов?
как правильно технически организовать описание проекта на VP?
На форуме вычитали про ППЦ (проблемы, потребности, цели) сейчас их расписываем
-
А как лучше поступить? Есть ли средства проектирования именно WEB-сайтов?
Ну а чем принципиально проектирование веб сайта отличается от другой программы?
как правильно технически организовать описание проекта на VP?
Эх, культ инструментов .... Ну почему именно в ВП? Начните с текстовых требований (и именно с ППЦ), потом потихоньку будете добавлять и диаграммы только там где это нужнол будет.
На форуме вычитали про ППЦ (проблемы, потребности, цели) сейчас их расписываем
А вот это правильно.
-
Проблемы:
- нет нормальной системы меню для сайта (нормального управления меню)
- очень долго загружаются страницы, из-за наличия jquery.js и большого количества запросов + отсутствия нормального кэширования
- очень сложно добавить быстро объявление
- невозможность определения адреса пользователя, его города, геолокации
-
Потребности:
- пользователь не может добавлять видео, аудио на сайт
- меню пользователя в профиле пользователя
- поиск пользователей по карте, имени, расширенный поиск по компонентам системы
- выделить объявление с помощью sms или другим способом
- баннеро-ротация в зависимости от настроек пользователя
- грамотная рассылка пользователям
-
чего-то маленькая активность на форуме
-
Для активности разрешите поинтересоваться как идёт работа, и есть ли документация на которую можно взглянуть типа ДВИ?
-
RuZzz, спрашивали, отвечаем.
Проект работает уже третий год. Летом назрела необходимость спланировать его в VP (с целью дальнейшей оптимизации и работы с проектом)
В общем, на сегодняшний день, так и не подготовлен никакой материал.
Нет ничего, кроме работающего проекта посещаемостью в 1200 уников в сутки
Головой понимаю, что нужно зафиксировать все, что есть - записать в UML
за инструмент взят VP
Но с чего начать - не знаю.
-
Хочется услышать кто и какой материал использует для постановки задачи программисту?
Проанализировав кучу материала я так и не нашел готового шаблона (документа), грамотного составленного с четким и понятным изложением, описывающим как нужно запрограммировать ту или иную задачу, функцию и т.п.
В своей практике постоянно сталкивался с документами ГОСТ:
1) "Описание алгоритма" (который в данный момент и используется как постановка) и
2) "Описание постановки задачи (комплекса задач)".
В ходе общения с прогерами и аналитиками пришел к мнению, что не очень практичны, долго пишутся, не так трактуются, содержат ненужную информацию или не содержат того чего нужно.
Итог: данные документы разрабатываются на этапе ТехПроекта для "ДАЛЬНЕЙШЕЙ ИХ СДАЧИ ЗАКАЗЧИКУ" (чтобы закрыть этап). Отсюда второй итог: эти документы носят по большому счету формальный характер и в дальнейшем абсолютно не применимы.
Многие с кем общался перечисляют общие документы, разрабатываемые по разным методикам: ТЗ, Техпроект, ЮзКейзМодель, ДатаМодель, SRS, Design Specification и т.д. и т.п.
Не спорю, все они нужны и все они обязательны в какой-то мере, но разработчик говорит "Дай мне постановку на разработку, что и как нужно делать" желая видеть некий ЕДИНЫЙ документ, в котором формализована задача, требующая реализации в коде.
Вопрос коллегам: Кто и что использовал в своей практике, чтобы поставить задачу программисту? Есть ли у вас готовый шаблон, документ или что-то типа того?
Пример: Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности", кстати она очень понравилась разработчикам)...
Фух... Грустный
Понятна ли проблема? Готов услышать ваши ответы.
Спасибо.
вот тут http://www.uml2.ru/forum/index.php?topic=2472.0 Pavel_T выразил все то, для чего я хочу собственно в VP оформить весь проект.
-
Хочется услышать кто и какой материал использует для постановки задачи программисту?
Проанализировав кучу материала я так и не нашел готового шаблона (документа), грамотного составленного с четким и понятным изложением, описывающим как нужно запрограммировать ту или иную задачу, функцию и т.п.
Маловероятно, что Вы это когда-либо найдете. Нет универсального решения. Но есть общие принципы. Это возникает в ходе скрупулезной работы в команде и выработки такого документа для себя
Многие с кем общался перечисляют общие документы, разрабатываемые по разным методикам: ТЗ, Техпроект, ЮзКейзМодель, ДатаМодель, SRS, Design Specification и т.д. и т.п.
Не спорю, все они нужны и все они обязательны в какой-то мере, но разработчик говорит "Дай мне постановку на разработку, что и как нужно делать" желая видеть некий ЕДИНЫЙ документ, в котором формализована задача, требующая реализации в коде.
Трудно залесть в голову вашего прогера.
Вопрос коллегам: Кто и что использовал в своей практике, чтобы поставить задачу программисту? Есть ли у вас готовый шаблон, документ или что-то типа того?
Как показывает моя практика, чужие шаблоны могут пригодиться, но редко применяются как есть. Можно подчерпнуть идею, но не саму форму.
Пример: Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности", кстати она очень понравилась разработчикам)...
USE CASE и разные способы его реализации (UML UML и UML)
-
Minona, уточниите, пожалуйста - Вам необходимо:
1. Описать систему as is (вы писали: "...зафиксировать все, что есть - записать в UML...")?
и/или
2. "...поставить задачу программисту?" (описание системы "to be")
В зависимости от того, что требуется в первую очередь (1 или 2), выбирается и способ действия...
-
Уровень постановки задачи программисту зависит, прежде всего, от уровня программистов. А второе - от уровня сложности разрабатываемых програм и интерфейсов. У нас был опыт работы в двух разных парадигмах. (1) слабо квалифицированные программисты (типа студенты), которые делали типовые интерфейсы - там было специфицировано - что есть типовой интерфейс (таблица с фильтром для просмотра, форма-диалог для редактирования), а дальше для интерфейса писали списки конкретных полей плюс отличия от типового (дополнительные кнопки, например). (2) - постановка для квалифицированных программистов в случае сложных, нагруженных интерфейсов - тут расписываешь прецеденты (usecase), которые хочешь улоджить, либо пишешь "сделать (пока) простой интерфейс для документа XXX" (документ - это класс + схема переходов по состояниям), если ничего сложного нет или неясно. При этом понятие типового интерфейса в проекте - тоже есть (как стиль кодирования). Вообще говоря, аналогично и с постановками на НЕ интерфейсную часть, они сильно различаются для разных уровней исполнителей, но тут сложнее. Да, есть еще третий кейс - программисты квалифицированные и с самомнением, но работать хотят по спецификациям "для тупых" - таких стоит гнать. А какие программисты у Вас?
-
Minona, уточниите, пожалуйста - Вам необходимо:
1. Описать систему as is (вы писали: "...зафиксировать все, что есть - записать в UML...")?
и/или
2. "...поставить задачу программисту?" (описание системы "to be")
В зависимости от того, что требуется в первую очередь (1 или 2), выбирается и способ действия...
Именно так. Вот первая задача - это просто "Описать систему as is"
а уже вторая - поставить задачу программисту
Кстати сказать, даже не знаю с чего начать описывать систему. Вот, сайт www .beelife .org
Есть программа VP 5
-
Вот еще проблема - в прикрепленном файле
В этом 5 VP когда подносишь к элементу мышку, мигать начинает какая-то таблица появляющаяся. Как отключить это, помогите пожалуйста
-
Именно так. Вот первая задача - это просто "Описать систему as is"
а уже вторая - поставить задачу программисту
Кстати сказать, даже не знаю с чего начать описывать систему. Вот, сайт www .beelife .org
Есть программа VP 5
Для описания уже работающей системы можно идти от замысла и истории её создания. Создатели системы, которую Вы собираетесь описать, должны были действовать в соответствии с рекомендациями Вашего сообщения №17 от 16 июня.
Первое, что нужно сделать – это определить пользователей будущей системы и, ориентируясь на их пожелания, сформулировать основные требования к программному продукту. Проще говоря, нужно узнать, какие действия пользователи хотят автоматизировать (переложить на систему). Затем, постепенно ограничивая или, наоборот, расширяя, круг функциональности и пользователей мы будем уточнять границу системы. Т.е. зная внешних, по отношению к системе, исполнителей и требования к ней, мы можем получить более четкую границу проекта.
Если системы создана, значит так или иначе эта задача была решена. Пользователи, кому адресован сайт, на сайте перечислены: "менеджеры по продажам, руководители компаний, студенты, фермеры, пчеловоды..." (http://www.beelife.org/o-saite.html).
Сайт создан, значит можно исходить из того, что создатели сайта поняли, в чем состоят "пожелания пользователей" (Вы можете их назвать?) и "какие действия пользователи хотят автоматизировать" (Вы можете их назвать?).
Пожалуйста, напишите (текст не больше странички), что, как полагали создатели сайта, хотят пользователи (но именно пользователи, которым сайт адресован) и какие их действия предполагалось автоматизировать (но действия именно этих пользователей, а не, скажем, действия случайно попавших на сайт врачей или сантехников).
-
Билайф.орг это социальная сеть, ориентированная на людей любящих пчел, продукты пчеловодства,
Пользователь может:
- публиковать личное сообщение:
в личный блог
новость
в сообщество (любое, в котором состоит, всего-лишь выбрав из "доп.меню")
в галерею (видео, аудио, фото, файл, ссылку)
в объявления
голосование
задать вопрос (в вопросы/ответы)
- управлять личными настройками
рассказать о себе (Имя, статусное сообщение, пол, выбор города, дата рождения, интересы пользователя, миниконструктор форм)
установить аватар
управлять контакнтыми данными (email, icq, skype и др. миниконструктор форм)
управлять подпиской и рассылкой (рассылка всего-нового и т.п.)
настройки приватности (кому показывать профиль, настройка показа тех или иных данных из "о себе")
Управлять модулями личного профиля
удалить профиль (удаляется по нажатии кнопки и отправки уведомления админам (они удаляют)
- поиск по сайту, расширенный поиск по сайту
- приглашение друзей, поиск друзей, добавление друзей
управление категориями друзей
переписка с друзьями (по внутренней почте)
- редактировать энциклопедию информации, добавлять новые записи
- дарить и принимать подарки,
- голосовать карму (с сообщением "за что")
- награждаться медалями, грамотами, кубками
-
Гость может:
- регистрироваться в системе
- авторизоваться (с исп. разных сервисов)
- писать сообщение зарегистрированному пользователю (если позволяют настройки безопасности)
- жаловаться на "сообщение"
- поиск по сайту
- добавить объявление
-
Правильно ли я понимаю, что система реализует следующие основные ВИ?
ВИ Пользователя:
- публиковать личное сообщение
- управлять личными настройками
- искать информацию по сайту, расширенный поиск по сайту
- приглашать, искать, добавлять, управлять категориями друзей
-переписываться с друзьями (по внутренней почте)
- редактировать энциклопедию информации, добавлять новые записи
- дарить и принимать подарки,
- голосовать карму (с сообщением "за что")
- награждаться медалями, грамотами, кубками
ВИ гостя:
- регистрироваться в системе
- авторизоваться (с исп. разных сервисов)
- писать сообщение зарегистрированному пользователю (если позволяют настройки безопасности)
- жаловаться на "сообщение"
- поиск по сайту
- добавить объявление
Или Вы полагаете для этой системы другие ВИ, которые Вы представили на прикрепленных ранее к Вашим сообщениям ДВИ?
-
Или Вы полагаете для этой системы другие ВИ, которые Вы представили на прикрепленных ранее к Вашим сообщениям ДВИ?
В общих чертах - все именно так. Но, если учитывать специфику системы - то каждый ВИ будет делиться еще на "множество" определяемое "по ходу" и в дальнейшем, я должен определить, какие более важные функции, а какие менее важные.
Сейчас задача состоит в том, чтобы понять "с чего начать" проектировать, а также - как избавиться от http://www.uml2.ru/forum/index.php?action=dlattach;topic=2493.0;attach=2832;image - этой назойливой проблемы.
-
В общих чертах - все именно так. Но, если учитывать специфику системы - то каждый ВИ будет делиться еще на "множество" определяемое "по ходу" и в дальнейшем, я должен определить, какие более важные функции, а какие менее важные.
Сейчас задача состоит в том, чтобы понять "с чего начать" проектировать, а также - как избавиться от http://www.uml2.ru/forum/index.php?action=dlattach;topic=2493.0;attach=2832;image - этой назойливой проблемы.
Как-то Вы странно ответили: из вашего ответа всё-таки неясно, какой набор ВИ (что именно "всё...так"?) актуален - в Вашем ответе от 25 декабря или на диаграммах в более ранних сообщениях? Это важно, потому что дальнейшее проектирование системы предполагает декомпозицию ВИ на ВИ (не функции!) более низкого уровня. Если Вы не определитесь с изначальным набором ВИ, неясно будет, что именно декомпозировать.
-
Как-то Вы странно ответили: из вашего ответа всё-таки неясно, какой набор ВИ (что именно "всё...так"?) актуален - в Вашем ответе от 25 декабря или на диаграммах в более ранних сообщениях? Это важно, потому что дальнейшее проектирование системы предполагает декомпозицию ВИ на ВИ (не функции!) более низкого уровня. Если Вы не определитесь с изначальным набором ВИ, неясно будет, что именно декомпозировать.
Вот вот!
Я не знаю с чего начать и как лучше все описывать! Вы правы! Что можете посоветовать?
-
Вот вот!
Я не знаю с чего начать и как лучше все описывать! Вы правы! Что можете посоветовать?
Предложение "с чего начать" содержится в моем сообщении от 25 декабря, причем Вы сами совершенно верно ранее предложили этот способ действия, и Вы даже сделали шаг в предложенном направлении. Не понимаю, почему вы делаете шаг назад и снова поднимаете вопрос про то "с чего начать"?
Могу посоветовать Вам ответить все таки на вопрос, который я Вам задал 26 декабря: можем ли мы принять в качестве перечня ВИ для Вашей системы то, что вы описали в сообщении от 25 декабря. Если Вы считаете, что этот перечень актуален, можно двигаться дальше. Если Вас что-то смущает в этом перечне, то что конкретно?
-
Если Вы считаете, что этот перечень актуален, можно двигаться дальше. Если Вас что-то смущает в этом перечне, то что конкретно?
Да, В указанном перечне (Ответ #32) все актуально
-
Да, В указанном перечне (Ответ #32) все актуально
Хорошо. И мы с Вами можем считать это перечнем вариантов использования системы, реализующей информационные услуги "социальной сети, ориентированной на людей любящих пчел, продукты пчеловодства"?
-
Это минимальный перечень, так сказать отправная точка с которой все начинается.
-
Это минимальный перечень, так сказать отправная точка с которой все начинается.
Но Вы готовы рассматривать этот перечень именно как перечень вариантов использования системы?
-
Да, все так и есть - именно этот перечень сейчас существует!
-
Да, все так и есть - именно этот перечень сейчас существует!
Извините, не могу считать это ответом на свой вопрос. Вопрос был не про существование перечня, а про то что, считаете ли Вы этот перечень перечнем вариантов использования системы?
-
Извините, не могу считать это ответом на свой вопрос. Вопрос был не про существование перечня, а про то что, считаете ли Вы этот перечень перечнем вариантов использования системы?
Да, указанный перечень - это перечень ВИ системы, пользователями и гостями сайта
-
Да, указанный перечень - это перечень ВИ системы, пользователями и гостями сайта
Хорошо. Не могли бы Вы пояснить, как ВИ системы связаны с целевой тематикой сайта (пчелы, пчеловодство)?
Почему это важно:
Обычно цели системы определяют предлагаемые для достижения цели решения. И предлагаемые решения ограничиваются рамками поставленных целей: функциональность выходящая за пределы установленных целями границ - это, как правило, усложнение системы, увеличение затрат (ваших сил и времени прежде всего) на её разработку. При попытке создать излишне универсальную систему может оказаться, что система разработана под "неправильные цели" и не нужна, неудобна пользователям.
1. Пока не видно причин, почему социальная сеть с таким перечнем ВИ не сможет объединить и автолюбителей и пользователей сотовой сети "Билайн" и в принципе - кого угодно.
Создание универсального "движка" для сайта социальной сети в принципе может представлять самостоятельную ценность (если сможете конкурировать с ЖЖ, Цукербергом :)). В этом смысле может быть Ваша цель на самом деле - создание универсального движка-сайта социальной сети? Тогда заявленный Вами перечень ВИ можно рассматривать как ВИ верхнего уровня ("уровня цели").
2. Если же для Вас важно, что этот сайт именно для пчеловодов, не могли бы Вы пояснить, зачем пчеловодам нужна социальная сеть:
* Чем она лучше, например, журнала "Пчеловодство" (http://www.beekeeping.orc.ru/emag.htm), или ЖЖ?
* Насколько востребованы пчеловодами функции общения пользователей сайта, специфические для социальных сетей? Может быть сообщество пчеловодов больше заинтересовано не сколько в том, чтобы общаться между собой, формировать группы/клубы, сколько распространять информацию вне сообщества?
* Зачем на сайте размещается информация по растениеводству, разведению кур? Почему Вы указываете только пчеловодство в качестве главного ориентира, тематики сайта?
Из ответов на эти вопросы будет более ясна связь заявленных целей создания сайта с ВИ, больше ясности с тем, какие объекты нужны для описания структуры и поведения системы по крайней мере на верхнем уровне.
-
Извините, что сразу не ответил, но не мог просто так писать не обоснованно, не обдуманно
Во всем Вы правы. К сожалению, формат сайта и нашего общения не позволяет выкладывать все наработки (а за два с половиной года их набралось не мало)
Естественно, основная цель сайта - дать возможность качественного обмена информацией!
+ необходимо подготовить плацдарм для программистов и разработчиков, с целью упрощения написания нового функционала.
Как уже было сказано - основная цель - писать сообщение.
"...будет более ясна связь заявленных целей создания сайта с ВИ, больше ясности с тем, какие объекты нужны для описания структуры и поведения системы по крайней мере на верхнем уровне..."
Я думаю, самый верхний уровень - это создание сообщения, а уже от его "назначения" и идет дальнейшее строительство системы.
-
Как уже было сказано - основная цель - писать сообщение.
.....
Я думаю, самый верхний уровень - это создание сообщения, а уже от его "назначения" и идет дальнейшее строительство системы.
К сожалению, из Ваших ответов остается неясным - зачем Вы создали и развиваете сайт по теме "пчеловодство"? Ради пчеловодов или ради программы-движка сайта как таковой? Если вы заинтересованы в том, чтобы предоставить пчеловодам возможность создавать сообщения и получать на них ответы, то почему бы просто не адресовать их на форум сайта "Пчеловод.инфо" (http://www.pchelovod.info/)?
Зачем тратить время на создание/поддержку сайта, основная цель которого предоставить пчеловодам возможность, которую они и так уже имеют?
-
Хорошо.
Во-первых, пчеловод.инфо - это форум. ФОРУМ, который имеет устаревшие принципы общения. Да, они еще популярны, но не на столько, чтобы за ними было будущее. Естественно, блоги - форумы не заменят. Это параллельная ветка, дополняющая форум.
пчеловод.инфо - существует 8 лет - посещаемость - 4 тыс. (тратят около 300 у.е. на яндекс.директ и другие рекламные компании)
билайф.орг существует 2 года - посещаемость - 1300... не тратит на рекламу ничего.
Билайф.орг - информативнее - на нем собрана основная (возможная) информация о пчеловодстве, пчеловодах. Цель билайф. орг - ОБМЕН ИНФОРМАЦИЕЙ а не "ОБЩЕНИЕ" именно по-этому, СООБЩЕНИЕ является отправной точкой.
Конечно, при наличии программиста в команде - посещаемость билайф. уже сейчас, была бы примерно такой-же, как на пчеловод.инфо. НО, увы... Пока найти сложно человека, готового уделять время на перспективу... в свободное от работы время... с оплатой в 3-5 тыс. рублей (100-150 у.е.)
Сейчас не об этом. В общем задача ставиться так, чтобы уже сейчас на начальном этапе, встать на правильный путь. Определиться с системой управления... Будь-то php или python
с базой данных mysql или postgreSQL и т.п.
Даже если нанять программиста - все равно - нужно представлять себе - с чего начинать - какое первым делать приложение, переносить ли систему на другой язык, или дорабатывать то, что есть (из г. делать к.)
В общем - было решено мной, сделать общую картину системы - варианты использования - для того, чтобы точно знать, что нужно, а что нет. Что пользуется спросом, а что нет.
Ибо, блокнота уже просто не хватает! У меня записей в notepad++ уже около 6 мегабайт (это все внедрения в систему)
Вот для этого я пришел сюда
-
Билайф.орг - информативнее - на нем собрана основная (возможная) информация о пчеловодстве, пчеловодах. Цель билайф. орг - ОБМЕН ИНФОРМАЦИЕЙ а не "ОБЩЕНИЕ" именно по-этому, СООБЩЕНИЕ является отправной точкой.
Можно пока зафиксировать: поскольку сообщение является отправной точкой, а не конечной, отправка сообщения не является целью системы. В качестве цели полагается "обмен информацией". Правда, не совсем понятно, почему отправка сообщения и чтение ответов на форуме Вы не считаете обменом информацией?
Может быть Вы хотите предоставить пользователям возможность обмена информацией различными способами в рамках одного сайта? Т.е. чтобы пользователь мог выбрать наиболее подходящий ему способ структурирования/модерирования информационного обмена и выбрать,
завести ли собственный блог, завести тему в форуме или прислать администратору сайта статью для опубликования (возможно, после редактирования администратором/редактором сайта)?
У Вас уже сейчас есть разделы: статьи/новости, блоги, форум и даже чат. Т.е. цель (назначение) системы - предоставить пользователям возможность обмена информацией (четырьмя?) разными способами в рамках одного сайта?
-
Вы правы.
И способов гораздо больше.
Я надеюсь, понятно изложил суть проекта ;-)
Вот теперь, нужно понять, с чего начать - есть процесс авторизации - затем, настройки пользователя, создание сообщения и т.д. и т.п....
В какой программе это лучше сделать, в каких системах?
-
Вы правы.
И способов гораздо больше.
Я надеюсь, понятно изложил суть проекта ;-)
Вот теперь, нужно понять, с чего начать - есть процесс авторизации - затем, настройки пользователя, создание сообщения и т.д. и т.п....
В какой программе это лучше сделать, в каких системах?
Разные способы информационного обмена предполагают разные варианты использования (ВИ) системы. Предлагаю Вам уточнить перечень вариантов использования системы - вариантов информационного обмена пользователей системы. Насколько я понял, Вы хорошо представляется себе сколько всего этих способов обмена, в чем они заключаются и готовы их назвать - приведите, пожалуйста, их полный перечень. Это можете сделать только Вы, ни VP, ни Enterprise Architect, ни какое-нибудь другое средство моделирования пока ничем помочь Вам не смогут.
-
В каком формате их нужно писать? Например, есть действие:
написать в блог
написать в сообщество
написать на форум
добавить свое фото
добавить файл
добавить объявление
написать новость
разместить статью
Пригласить друга
Дальше идет: "редактировать"
установить "формат доступа" и т.п.
-
Minona, мне кажется, то, что Вы перечислили, принципиально ничем не отличается от того, что у же имеется. Можно найти вполне подходящий движок или использовать уже имеющийся. Но добьетесь ли Вы этим нужной цели? В чем нуждаются Ваши пользователи, что хотят иметь они, какой функционал, способ обмена и т.п. Не совсем ясно, какую цель в конечном итоге Вы ставите? Пчеловоды всех стран объединяйтесь? Наши пчеловоды самые прогрессивные пчеловоды в мире? Каждый пчеловод страны должен быть пользователем нашего сайта? Наш сайт самый точный источник любой информации о пчелах, пчеловодстве, меде и способах лечения им?
Кроме того на мой взгляд нужна и концепция развития сайта, его архитектуры, организационной структуры, развитие на перспективы, ориентация на разные архетипы приложений возможно, функциональная широта и полнота ...
-
В каком формате их нужно писать? Например, есть действие:
написать в блог
написать в сообщество
написать на форум
добавить свое фото
добавить файл
добавить объявление
написать новость
разместить статью
Пригласить друга
Дальше идет: "редактировать"
установить "формат доступа" и т.п.
Если Вы предполагаете в дальнейшем использовать UML, предлагаю придерживаться соответствующей терминологии. Вариант использования может реализовываться выполнением последовательности действий. Т.е. "вариант использования" - это одно, а "действие" - это совсем другое.
1. Большую часть пунктов из приведенного Вами перечня можно рассматривать в качестве вариантов использования системы.
Вариант использования должен описывать некоторое законченное взаимодействие пользователя. ВИ "добавить фото, файл и объявление" не похожи на взаимодействие, имеющее понятную причину и начало и подчиненное целям системы завершение. Возможно, они являются частью (частями) каких-то более сложных ВИ?
2. Все эти ВИ сводятся к "складированию" информации на сайт. ИМХО Вы как-то уж очень сильно акцентируете возможность отправки, а не получения информации/сообщений. В этом смысле Ваши ВИ также не похожи на законченные взаимодействия. Вряд ли возможность расстаться с информацией привлечет пользователей на сайт в большей степени, чем возможность "потребления" чужих "сообщений". Если Вы предполагаете предоставить пользователям возможность находить на сайте то, что им нужно, то в этом перечне не хватает ВИ связанных с поиском и просмотром информации (с учетом логики навигации), которые на самом деле у Вас в той или иной степени уже реализованы.
3. Вопрос, какие специфические требования к способам обмена информацией предъявляет тот факт, что этот обмен осуществляется пчеловодами, конечно остается. Я охотно присоединяюсь к вопросам, которые Вам задал Galogen, но я предполагал, что можно вернуться к ним после того, как получим относительно формализованное описание системы as is (как она видится Вам, как создателю системы), поскольку такая задача была заявлена в сообщении № 28.
Если Вы можете ответить на вопросы, которые Вам задал Galogen, ответьте, пожалуйста. В любом случае без ответа на них Вам сложно будет обосновать планируемые доработки системы (для обсуждения видения системы to be).
-
Вот опять, насущная проблема - управление проектом и безопасность.
Есть проект созданный с помощью devprom
очень хорошая программа по учету в проекте. Но, как обеспечить безопасность файлов? Программистам нужна вся система для работы,
-
Вот опять, насущная проблема - управление проектом и безопасность.
Есть проект созданный с помощью devprom
очень хорошая программа по учету в проекте. Но, как обеспечить безопасность файлов? Программистам нужна вся система для работы,
Что-то Вы прыгаете с темы на тему. К тому же мысль явно не завершена
-
Что-то Вы прыгаете с темы на тему. К тому же мысль явно не завершена
Совсем нет. Стараясь собрать требования во-едино - обнаружилось, что это сделать крайне сложно!
Как можно классифицировать требования? Скажем, есть требование исправить ошибку, а есть, добавить новый функционал к уже существующему... А есть, создать новый...
Из всего этого списка нужно как-то выдрать необходимое!
-
Совсем нет. Стараясь собрать требования во-едино - обнаружилось, что это сделать крайне сложно!
Как можно классифицировать требования? Скажем, есть требование исправить ошибку, а есть, добавить новый функционал к уже существующему... А есть, создать новый...
Из всего этого списка нужно как-то выдрать необходимое!
Что-то я Вас совсем не понимаю. Вы о чем говорите? О проблемах управления требованиями в projectcloud (devprom) или вообще о проблеме работы с требованиями?
Классификация требований может быть разнообразная. Одной единственной верной и оптимальной вряд ли существует.
Классификация по Вигерсу и т.п., мне кажется, достаточно прагматична..
Требование "исправить ошибку" - это работа, которую нужно выполнить. Это не собственно требования к функционалу или проекту, это просто ошибка, которую следует устранить в любом случае. Это задача, возможно внеплановая, т.е. непланируемая явно.
Требование на новый функционал - это тоже работа, но уже плановая, включаемая в релиз. Эта работа наверняка распадается на ряд задач: проанализировать и специфицировать, спроектировать, реализовать, протестировать, проверить и принять...
Но это управление работами проекта, а не управление требованиями. Кстати разработка требований тоже часть работ проекта
-
Чувствуется, не хватает звена какого-то...
Задача основная - правильно спланировать, описать то, что есть сейчас.
Составление требований на новый функционал, не так прост, как кажется. К уже существующим функциям, нужно приписать новые, но при этом, исправить параллельно ошибки (доработки) которые необходимы, для внедрения нового функционала.
Также, например, у все вышесказанное не возможно без ясной картины того, что уже есть и работает в системе. Именно это определяет дальнейшую работу.
Поэтому, сначала нужно фиксировать присутствующий функционал, его ошибки и затем, уже отталкиваясь от того, что есть - разрабатывать новое.
Собственно вот с этим всем и проблема!
-
Чувствуется, не хватает звена какого-то...
Задача основная - правильно спланировать, описать то, что есть сейчас.
.....
Также, например, у все вышесказанное не возможно без ясной картины того, что уже есть и работает в системе. Именно это определяет дальнейшую работу.
Поэтому, сначала нужно фиксировать присутствующий функционал, его ошибки и затем, уже отталкиваясь от того, что есть - разрабатывать новое.
Собственно вот с этим всем и проблема!
Закончите описание перечня ВИ системы- это как раз и есть один из способов "фиксации присутствующего функционала" - у Вас ведь есть работающий "живой" сайт, с постоянными пользователями. Продолжите описание того, как Вы видите, как используют сайт пользователи. Проблема в том, что разные люди могут видеть ВИ одной и той же системы по разному. Если Вы претендуете на то, чтобы быть создателем сайта, очень важно, чтобы Вы руководствовались именно Вашим видением того, что есть, и могли представить это видение в понятном другим (разработчикам, посетителям этого форума) виде. Успех Вашего проекта зависит от Вашей способности сформулировать "что есть", для того, чтобы сформулировать "что нужно". UML, среды разработки и моделирования - это только инструменты, но если суть Вашего проекта будут формулировать другие - это уже будет не Ваш проект. Дерзайте!
-
Закончите описание перечня ВИ
Как? Вот основной вопрос. Я уже приводил различные варианты описания! Но правильны ли они, как они делаются?
-
Последний вариант перечня ВИ, который Вы привели:
написать в блог
написать в сообщество
написать на форум
добавить свое фото
добавить файл
добавить объявление
написать новость
разместить статью
Пригласить друга
Какие у этого перечня недостатки (подразумевающие в каком направлении этот перечень стоит доработать) я изложил в сообщении 53 от 3 января. Посмотрите, пожалуйста. Если Вы не согласны с тем что я написал, укажите, пожалуйста пункт сообщения и с чем именно Вы не согласны. Какие конкретно затруднения есть у Вас с доработкой этого перечня ВИ?