Re: календарный_вид

["Kostya" <k22@i.com.ua>]

> оПХБЕР!
>         Вот читаю твою "конкретизацию" каледарика :)))
> Я  хотел  бы  поделиться опытом, знаниями и дать несколько советов при
> проектировании требований такого рода систем.

Привет, Миклер!
Классное замечание! Я сам читал то, что написал, и
Интересная штука Rational Unified Process -- что-то я о нем слышал. Как ему
учатся, очно или по книжке?
Это напоминает мне о второй логике. Значит, перед тем, как приступить к
анализу, который советуешь ты, ставлю себе вопрос -- что тут важно, какие
компоненты важны?

1. Вся затея вообще и подпроцесс "календарный вид представления эзо и
обучающих событий" должны быть интересны для занимающихся ею. Т.е. должно
быть минимум рутины, и максимум творчества.

2. Нужно, чтобы подпроцесс "календарный вид представления эзо и обучающих
событий" -- или попросту "календарик", воспользуюсь твоим словом,
способствовал интересному и обучающему получению прибыли из проекта Эзонет.
Если такое пойдет, то даже возникнут новые ячейки на площадке, т.е.
несколько человек смогут активно вариться в среде!

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

4. Исполнение "календарика" дизайн и программирование должно быть не
громоздким и эффективным. Желательно сделать так, чтобы в него легко было
вносить изменения в будущем. Он должен быть хорошо согласован с тем, что уже
существует у Кати и Ани (платформы, языки, что еще?).

Ну хорошо, теперь попробую применить твой совет.

> Нужно оперделить кто с ней взаимодействует.

Админы, читатели, организаторы тусовок, заинтересованные доноры информации,
незаинтересованные доноры информации, случайные читатели

> 2.  Кадидаты  в  варианты использования. Мозговым штурмом определяется
> вся  мыслимая  функциональность  рассматриваемой  системы.  Потом  эта
> функциональность  фильтруется,  структурируется общим обсуждением. Для
> оставшейся функциональности (Вариантов Использования системы) детально
> описываются  последовательности  возможных  действий  пользователся  и
> возможных результатов.

K> 2. Механизм добавления ресурсов (дата, событие, описание, контакт)
K> пользователями (возможность предварительного одобрения админом);

Катя: Сейчас механизм такой:
1. пользователь заполняет форму, нажимает Ок -> админу отсылается письмо с
заявкой
2. админ вносит ресурс в базу

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

K> 3. Механизм добавления ресурсов администраторами - вручную и из списка с
K> разделителями (чтобы можно было подготовить список, а потом загрузить).

K> 4. Несколько View (видов, представлений) -- 1 неделя, две, месяц,
несколько
K> месяцев. Что-то подобное как на Yahoo Groups --> Calendar.

5. Отображение в календарике только событий, отобранных по критериям "Город
или города, страна, время начала события, ключевое слово"

6. поощрение доноров информации. Мы собираем имейлы людей, которые добавляют
инф. и поощряем их, даже заохочуємо їх, они же помогают нам. Кто-то из них
может, станет нашими сотрудниками.

7. классный дизайн пустого календаря будет привлекателен и сам по себе.

Народ, какая еще тут может быть и нужна нам функциональность?

Костя

----- Original Message -----
From: Mikler <Mikler_mpz@tut.by>

> Привет!
>         Вот читаю твою "конкретизацию" каледарика :)))
> Я  хотел  бы  поделиться опытом, знаниями и дать несколько советов при
> проектировании требований такого рода систем.
> 1. Выделение Актантов.
> Актанты  - это нечто внешнее для системы. Как то админ, пользователь и
> т.д.
> Нужно оперделить кто с ней взаимодействует.
>
> 2.  Кадидаты  в  варианты использования. Мозговым штурмом определяется
> вся  мыслимая  функциональность  рассматриваемой  системы.  Потом  эта
> функциональность  фильтруется,  структурируется общим обсуждением. Для
> оставшейся функциональности (Вариантов Использования системы) детально
> описываются  последовательности  возможных  действий  пользователся  и
> возможных результатов.
>
> Дальше  всё  не  так  важно.  Например  можно  дать  задание  человеку
> разработать  интерфейс  - чисто на бумажке или в графическом редакторе
> (Visio...)  и  посмотреть насколько он удобен и выполняет определённым
> требованиям.
>
> Что  касаеться  технологий,  то  это  чем-то  напоминает совмещение не
> совместимого.    Архитектура    (набор    технологий)   ограничивают
> функциональность, а функциональность определяет архитектуру.
>
> Важно разделять взгляд на систему со стороны пользователя и со стороны
> разработчика.  У  тебя  это  несколько  путается.  Когда  мы  начинаем
> разработку  с  постоения модели ВАриантов использования мы закладываем
> фундамент нужной системы, даже в таких мелочах как Календарик.
>
> Это было мизерное введение в Rational Unified Process :)))
>
> Удачи. :))
>
>
> ....
> дочитал
> посмотри какая у тебя каша :)))
> раньше тоже что-то похожее было и у меня. Кучу идей разношёрстных...
> Разделяй! :))))
>
>




-------------------------------
"Урал-2003. Летний лагерь Школы по Второй Логике" - 
http://klein.zen.ru/zen-spirit/ural-2003/