Возникает новый проект, и требования, которые касаются архитектуры, а именно - производительность, интеграция, технические ограничения необходимо согласовать с вашей платформой (если она у вас есть) - потянет ли вообще, если нет, что делать; что делать, если клиент просит postgres, а у вас всё заточено под mysql и т.д. Эту работу тоже надо делать, и она не относится ни к требованиям, ни к программированию.
не понял, вы не включаете работу с требованиями в процесс разработки, так что-ли? и они у вас фиксируются перед разработкой раз и навсегда? или они меняются, и если да, то где эти изменения требований отражаются?
а как вы собираетесь рассказывать о вашем процессе разработки ПО, не затрагивая принципы, на которых ваш подход базируется - скажем, итерационность хотя бы?
Ну RUP тут точно непричём. Может быть - OpenUP/Basic, который есть облегчённый в Agile RUP, но и то у команды не тот уровень зрелости пока, похоже, хотя он именно для такого размера и задумывался.
Роль - это соглашение, позволяющее группировать схожие наборы задач, и обладающее определёнными отношениями с другими ролями. Персонаж - это сфабрикованная личность, обладающая специфическими антропологическими характеристиками, которая может выступать в одной или нескольких ролях.
"Организатор события", "Участник события" - это роли. "Диджей Слава Сумкин", "Эмошница Марципан" - это персонажи.
Задача - это формулировка условия достижения некоторой цели. Сценарий - это последовательное описание взаимодействий (операций) агентов, необходимых для достижения этой цели (решения задачи).
Пример задачи - "Оповестить о событии".
Пример сценария - "Подготовить сообщение, Выбрать момент оповещения, Выбрать средство оповещения, Указать условия распространения сообщения, Передать сообщение системе оповещения".
Если работа с подобными терминами не является вашей профессией, то понятно, что вы слабо их различаете.
а причём тут роли? я говорю о том, что те или иные сервисы, которые возникают на сайте, должны браться не из воздуха, а как механизмы покрытия потребностей пользователя. для выявления потребностей помогают подходы с использованием персонажей.
GC позволяет приглашённым отмечать вероятность своего участия и обсуждать в комментариях место и условия. Если событие открытое, то на него может записатья любой желающий. Автор события потом может изменить параметры встречи.
"...смог все-таки выполнять возложенные на него функции."
А какие на него функции возложены?
"Т.е. сервис для поиска, создания, обсуждения и пиара самых различных событий. Начиная от концерта Мадонны в Москве, и заканчивая секретной сходкой хабраюзеров с целью устроить очередную Хабрареволюцию (sic!)"
Ну так возьмите какой-то набор типовых задач потенциального посетителя и продумайте сценарий его работы с системой для каждой задачи.
Допустим, есть такие потребности (я возьму только поиск, как наиболее массовое):
"Семинары в Москве" - хм, всего 2 семинара вообще, не то что в Москве.
Вывод 1: Нет контента.
Предложение 1: Может стоит для начала сделать аггрегатор событий из других XML-источников?
Допустим, "Питер" - это вообще то место, где я в основном собираюсь искать. Как мне его зафиксировать, чтобы каждый раз не вводить? Нужно регистрироваться? Просто для того, чтобы сделать серию обычных гео-привязанных запросов? Барьер. Зашёл в "Питер", начал искать "выставка" - попал почему-то на Московский экспоцентр.
Ок, что будет на следующей неделе? Ввожу "на следующей неделе" и только - почему-то результаты начиная с 7-го числа, т.е. с этой недели.
Хм, календарь говорите - а где же собственно календарь? С выделяющимися праздниками и выходными, когда стоит искать развлекательные события; буднями, где будут семинары и проч?
А где картинки? Развлекательные события - это прежде всего шоу - нужен визуал, чтобы запомнить, что я хочу на это событие (кстати, как добавить в избранное? чтобы составить персональную культурную программу?) пусть это будет хотя-бы логотип организатора выставки или что там.
Может вы честно признаетесь, что просто поставили Blog CMS с плагинами, а не создавали никакой "продукт"?
Я к выявлению и фиксации требований заказчика и аналитиков подрядчика привлекаю. Хватит им мороки с wiki-синтаксисом, так вы предлагаете им ещё на каждый компьютер, откуда он будет работать, SVN-клиента ставить, обучать принципам check-in/check-out и т.д?
С картинками всё просто - они служат только для иллюстрации текста (если говорить о требованиях), и обновляются гораздо реже теста. Заказчик/эксперты картинки только смотрят и согласовывают/комментируют, но не правят.
Над инструментами совместного визуального рисования, что актуально, например, для моделей бизнес-процессов и UML, пока думаем. В сети есть только рисовалки и редакторы MindMap.
С картинками пока такой цикл - скопировать из среды моделирования в буфер, вставить в GIMP, оттуда сохранить и залить в MediaWiki через соответствующую кнопку. В нужно месте текста вставить или обновить ссылку на картинку.
вопросы архитектуры входят в разработку веб-приложений и вы ими занимаетесь, но в озвученные вами тезисы она почему-то не вошла
"Организатор события", "Участник события" - это роли. "Диджей Слава Сумкин", "Эмошница Марципан" - это персонажи.
Задача - это формулировка условия достижения некоторой цели. Сценарий - это последовательное описание взаимодействий (операций) агентов, необходимых для достижения этой цели (решения задачи).
Пример задачи - "Оповестить о событии".
Пример сценария - "Подготовить сообщение, Выбрать момент оповещения, Выбрать средство оповещения, Указать условия распространения сообщения, Передать сообщение системе оповещения".
Если работа с подобными терминами не является вашей профессией, то понятно, что вы слабо их различаете.
GC позволяет приглашённым отмечать вероятность своего участия и обсуждать в комментариях место и условия. Если событие открытое, то на него может записатья любой желающий. Автор события потом может изменить параметры встречи.
Используйте Google Calendar
А какие на него функции возложены?
"Т.е. сервис для поиска, создания, обсуждения и пиара самых различных событий. Начиная от концерта Мадонны в Москве, и заканчивая секретной сходкой хабраюзеров с целью устроить очередную Хабрареволюцию (sic!)"
Ну так возьмите какой-то набор типовых задач потенциального посетителя и продумайте сценарий его работы с системой для каждой задачи.
Допустим, есть такие потребности (я возьму только поиск, как наиболее массовое):
"Семинары в Москве" - хм, всего 2 семинара вообще, не то что в Москве.
Вывод 1: Нет контента.
Предложение 1: Может стоит для начала сделать аггрегатор событий из других XML-источников?
Допустим, "Питер" - это вообще то место, где я в основном собираюсь искать. Как мне его зафиксировать, чтобы каждый раз не вводить? Нужно регистрироваться? Просто для того, чтобы сделать серию обычных гео-привязанных запросов? Барьер. Зашёл в "Питер", начал искать "выставка" - попал почему-то на Московский экспоцентр.
Ок, что будет на следующей неделе? Ввожу "на следующей неделе" и только - почему-то результаты начиная с 7-го числа, т.е. с этой недели.
Хм, календарь говорите - а где же собственно календарь? С выделяющимися праздниками и выходными, когда стоит искать развлекательные события; буднями, где будут семинары и проч?
А где картинки? Развлекательные события - это прежде всего шоу - нужен визуал, чтобы запомнить, что я хочу на это событие (кстати, как добавить в избранное? чтобы составить персональную культурную программу?) пусть это будет хотя-бы логотип организатора выставки или что там.
Может вы честно признаетесь, что просто поставили Blog CMS с плагинами, а не создавали никакой "продукт"?
Но непонятно, зачем вы спрашиваете, если с MySQL уже не работаете.
В MW есть версионность изображений, но я ей не пользовался.
С картинками всё просто - они служат только для иллюстрации текста (если говорить о требованиях), и обновляются гораздо реже теста. Заказчик/эксперты картинки только смотрят и согласовывают/комментируют, но не правят.
Над инструментами совместного визуального рисования, что актуально, например, для моделей бизнес-процессов и UML, пока думаем. В сети есть только рисовалки и редакторы MindMap.
С картинками пока такой цикл - скопировать из среды моделирования в буфер, вставить в GIMP, оттуда сохранить и залить в MediaWiki через соответствующую кнопку. В нужно месте текста вставить или обновить ссылку на картинку.