|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
При разработке модели данных часто возникает необходимость согласования и предварительного тестирования. Кто как делает? Например камнем преткновения бывает хранение контактной информации о контрагентах. Пользователи (заказчики) хотят видеть список фирм и у каждой контактный телефон. Ну привыкли они так. Аргументация в духе "чтоб удобно было контору искать по телефону". Хотя если с этой контактной инф-цией идёт какая-то работа (бухгалтер интересуется оплатой, менеджеры что-то впаривают, курьер спрашивает как проехать к офису и т.п.) - структура должна быть несколько сложней. Упрощенно: табличка контрагентов, подчинённая табличка контактных лиц контрагентов, подчинённая ей табличка телефонов/мейлов контактного лица. Данные могут выглядеть примерно как секретутка маша - телефон, факс центральный офис - телефон, мыло главбух - телефон Т.е. получается достаточно сложно. Предложение обезличенную контактную инф-цию типа "центр.офис", "склад" хранить вместе с контактными лицами вообще вводит в ступор хотя с точки зрения функционирования системы вроде это нормально а иногда необходимо. Необходимо для согласования создать несколько формочек, ввести какое-то количество данных, сделать возможность ввода/редактирования/поиска. Кто чем для этого пользуется? Создаёт базульку в аксесе или может убеждает заказчика обойтись без проверки или просто картинки формочек в визио рисует. Предлагаю обсудить ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 10:54 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
1024При разработке модели данных часто возникает необходимость согласования и предварительного тестирования. Кто как делает? т.е. речь идет о макетировании ? лучше всего для этого использовать основное средство разработки и макет плавно переходит в боевую систему ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 12:02 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
Но это же долго? Сразу делать так как будет в реальной системе где могут быть дополнительные требования (интерфейс, интеграция с другим ПО и пр.)? И с большой вероятностью что это придётся выбросить, поменять структуру и снова согласовывать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 12:08 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
1. по повододу "Т.е. получается достаточно сложно. Предложение обезличенную контактную инф-цию типа "центр.офис", "склад" хранить вместе с контактными лицами вообще вводит в ступор хотя с точки зрения функционирования системы вроде это нормально а иногда необходимо." мы так и делаем,просто разнесли физиков, юриков и подразделения по разным частям интерфейса. Хранятся в одной таблице-пользователи думают,что в разных. 2.Я обычно стараюсь найти понимающего человека среди вернего руководства, и, как показывает опыт, они всегда присутствуют (иначе, обычно, фирма долго не живет).А далее все согласовывается на бумажках.Сложные формы-в Word рисуем,а потом вместе заполняем на бумаге. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 12:37 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
Экранные формы совсем необязательно должны показывать реальные связи БД. Стройте экранные формы так, чтобы они удовлетворяли текущие потребности клиента. Кто-то хочет видеть все обезличенные телефоны компании, кто-то хочет видеть список контактных лиц с телефонами, а кто-то список телефонов только одного отдела компании. Другой вопрос действительно ли заказчик хочет видеть именно это. Вот тут на помощь и приходят прототипы экранных форм. Лично я предпочитаю, чтобы формы рисовались в Visio. На собственном опыте убедился, что это гораздо эффективнее чем рисовать в среде разработки. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 14:38 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
1024Но это же долго? Сразу делать так как будет в реальной системе где могут быть дополнительные требования (интерфейс, интеграция с другим ПО и пр.)? И с большой вероятностью что это придётся выбросить, поменять структуру и снова согласовывать? на самом деле быстрее всего. макет он и есть макет - картинки поддержанные минимумом функций без которых макет не живой а рисовать картинки в визио - только время терять. ваша среда разработки должна быть быстрее визио (или это плохая среда) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 14:53 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
Нет-нет, разговор не о рисовании. Разговор о функционирующем макете. Если взять пример про контактную инфу (в любой системе наверна есть контактная инфа) - какие кейсы на три роли: 1.бух хочет позвонить должнику - он должен найти тел. бухгалтера. Ни с кем другим он говорить не будет (упрощённо) 2.курьер хочет спросить как проехать к складу - должен найти тел.склада или ещё какой, всё равно у кого спрашивать, хоть у охраны 3.менеджер вводит конт.инфу по своим контрагентам, вводит конт.лиц, координаты 4.менеджер ищет тел. только тех отделов которым хочет что-то впарить, желательно начальника отдела а не секретутку возможность выполнения этих действий и нужно продемонстрировать заказчику. Можно нарисовать в визио и на словах объяснять, можно сделать в аксесе базульку с формочками и забить туда какой-то объём данных (так наглядней), можно сразу рисовать базу и формы которые поёдут в конечное приложение (намного более трудоёмко). После обсуждения появляются новые кейсы или меняются существующие, структура данных корректируется и надо макет выкинуть и по новой делать Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 14:58 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
Я пользуюсь штатной базой, а к ней прикручивается макет. Клиенту объясняю, что для проектирования БД главное предусмотреть самый сложный случай. Типа для приведенного примера: Клиент--< Контакт--<Связь>--ТипСвязи, Контакт>--ТипДолжности Контакт>--Подразделение>--ТипПодразделения еще наверно Клиент--< Подразделение--<Связь>--ТипСвязи Одновременно показывается, что это не ведет к тому, что бухгатер долго будет рыться в этой куче, чтобы найти/ввести общий телефон бухгалтерии или конкретно главбуха. На макете не грех просто это в лоб зашить в запросах формы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 16:11 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
согласен с mod. Макет интересен именно в динамике - по статичным картинкам обычный пользователь плохо воспринимает единое целое. А динамику воссоздать можно только программированием. С др. стороны, у более-менее опытного разработчика на написание кода вызова форм и пр. эту динамику как правило, времени уходит намного меньше чем на придумывание интерфейсов. С третий стороны, именно в таком написании сразу сам отсеиваешь неудобные или чересур трудоемкие пути. Nobody faults but mine... (LZ) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 17:42 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
В моём случае рисование прототипов экранных форм происходит на этапе анализа. Занимается этим человек, который ничего не знает про программирование, но знает про дизайн пользовательского интерфейса. Тратить в данном случае время программиста не рационально. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 17:49 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
В моём случае рисование прототипов экранных форм происходит на этапе анализа. Занимается этим человек, который ничего не ----------- само собой что дизайном занимается дизайнер. Вопрос в работающем макете (или описании действий) - чтоб можно было ввести данные, отредактировать, найти что-то. Для проверки Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2006, 17:54 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
Вопрос в чём? Нужен действующий прототип? Что применять для его реализации? Для действующего прототипа используйте то, на чём собираетесь разрабатывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2006, 09:36 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
Вопрос в чём? Нужен действующий прототип? Что применять для его реализации? Для действующего прототипа используйте то, на чём собираетесь разрабатывать. ----------------- я не спрашивал советов, я предлагал обсудить плюсы/минусы подходов 1.нарисовать картинки форм и на словах (на бумаге) объяснять что где лежит и как заполнять/искать - менее трудоёмко но и менее наглядно 2.сделать работающий прототип в простом средстве и заполнить тестовыми данными - более трудоёмко 3.сделать работающий прототип таким каким он пойдёт в продакшн и заполнить тестовыми данными - ещё более более трудоёмко дополнительно - использовать не тестовые а реальные данные, добавится огромный пласт работ по конвертации причём это всё только для макета который вероятно потом придётся просто выкинуть кому что ближе и почему? Есть ли какие-то ещё варианты? мне кажется что вариант 3 приемлим только для небольших систем. Всё равно сразу сделать так чтоб было хорошо невозможно. Проверка на реальных а не тестовых данных тоже слишком много возни за собой тянет и при этом не исключает ситуации когда в данных представлены не все возможные варианты Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2006, 13:29 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
Если под моделью понимается логика работы, то - заказчик высказал пожелания, перечислил "выходы", увидел отображение своих пожеланий на макете - дал отмашку "делай". Все довольны. А если - КАК я буду хранить данные... Ну, в конце-концов заказчик не за то деньги платит, чтоб еще и в этом разбираться. Я обычно подсовываю заказчику нефункциональный макет интерфейса ввода с возможностью показа каких-нить печатных форм-отчетов (болванок, ессно... с графиками, диаграммами и прочими рюшечкам) и делаю это в самом начале разработки. Максимум, что там работает - это переход между формами и "маски" на ввод данных. Ничего большего заказчик видеть не должен - у него сразу идеи появляться начинают, мысли... Нафик... А встречаться с ним в середине или под конец разработки - вообще ахтунг! Так что листики с форами и пояснениями на подпись - и вперед, за работу! А когда ТЗ, плавно перешедшее в спецификацию, уже "затвердили" - работается легко и приятно :)) Макеты клиентских модулей делаю обычно в Access MDB. Из плюсов: 1. Легко переделать в рабочее приложение и перейти на SQL Server (при необходимости) 2. Минимум усилий при максимуме результата в плане построения интерфейсов 3. Масса имеющихся наработок в области интерфейса 4. Легко таскать при необходимости демонстрации и изменять прямо на месте... А на этапах интервьюирования - лист А4 на планшете и карандаш... никто ничего лучше пока еще не придумал :)) P.S. Не так давно рассказывал эту нехитрую схему одному весьма сертифицированному господину... Ох, как он морщился и кривился - "не по науке это все... кустарненько..." ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2006, 01:39 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
расскажу совершенно рабочий вариант - программистов прошу не смеяться в ходе презентаций и согласования ба'джета очередного этапа, распечатал имадж формы (эскизы сделаны в среде разработки, но только дизайн + где надо - демоданные) на хорошем принтере в полный цвет на а4 в полный лист, наклеил на а3 черный лист (специальный картон - пенополистирол с бумажным покрытием по фейсовой стороне - цвет фона черный) люди, ответственные за принятие решения (по развитию, инф.техн и нач ПЭО) передавали демообразцы друг другу, рассматривали, крутили с разных сторон... как дети, в общем... прокатило на ура - т.е. вообще без запинки - они были готовы с момента как только взяли планшеты в руки... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2006, 12:21 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
rgrtwertewrtertertertertewrtлюди, ответственные за принятие решения... блин... и кто за язык тянул... если участники той встречи наткнутся на этот пост, прошу проявить чувство юмора и не обижаться... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2006, 13:20 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
nibbles Макеты клиентских модулей делаю обычно в Access MDB. Из плюсов: из минусов, которые перечеркнут все плюсы (если вы не МДБ-шники ваяете) набор конролов в формах ACCESS весьма скуден, невозможно отобразить сложные элементы а если подключать внешние ActiveX время требуемое для на разработки макета становится величиной непредсказуемой, рисовать сложные элементы в других средах и вставлять на скриншоты аксессных форм - это для бездельников впрочем, если Access ваша среда - задача сводится к стандартной ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2006, 13:27 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
dfasddfassdfasdfd nibbles Макеты клиентских модулей делаю обычно в Access MDB. Из плюсов: из минусов, которые перечеркнут все плюсы (если вы не МДБ-шники ваяете) набор конролов в формах ACCESS весьма скуден, невозможно отобразить сложные элементы а если подключать внешние ActiveX время требуемое для на разработки макета становится величиной непредсказуемой, рисовать сложные элементы в других средах и вставлять на скриншоты аксессных форм - это для бездельников впрочем, если Access ваша среда - задача сводится к стандартной М-да... я давно не видел разводов на флеймы типа "моя линукс твоя виндовс круче". Мы говорим о макетировании? Ну, и зачем же при макетировании нужны нестандартные ЭУ? Лично я не собираюсь мерять эффективность среды разработки наличием или отсутствием "продвинутых" ActiveX и Вам этого не советую - это блестюче, красивенько, но бессмыслено. Из собственного опыта и из бесед с коллегами знаю, что лучше обойтись средствами одной IDE, а использования нестандартных ActiveX избегать всеми силами. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2006, 17:58 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
nibblesМы говорим о макетировании? Ну, и зачем же при макетировании нужны нестандартные ЭУ? нестандартные для какой среды - для Access или для Delphi - только об этом и речь... никакаких Linux vs Windows вариаций на тему... просто если Вы перечтете тред и увидите общий ход дискусии ИМХО станет очевидным что речь идет о макетировании в той среде, в которой будет вестись разработка - только и всего. Если разработка в Access, то и макет в Access исли избрана иная среда - то, соответсвенно в ней и нужно делать екземплы форм... вот и все... никакого флэйма - все по существу ИМХО не нужно обизаться за любимый инструмент, никто на него не наезжает ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2006, 00:22 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
делаем действующие прототипы. Конечно в той же среде, что и релиз. Кроме как на прототипе понять как будет работать система невозможно. А развить структуру данных это проблема разве? Да и создание прототипа вроде бы тоже не проблема. В релизе тонкости отрабатываются и интерфейсы оттачиваются. Иногда прототип с ног на голову переставляется. Это ж процесс... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2006, 00:30 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
iscrafmделаем действующие прототипы. Конечно в той же среде, что и релиз... для подготовки действующего прототипа иногда тербуется слишком много времени (и ресурсов - челчасов) проще наделать условно подобных макетов а вообще - все зависит от уровня презентации - на первых шагах достаточно скрин-шотов на планшетах, позже уже прототипы (демки) - прототипы можно погонять на компьютере пользователя (кста - баги в прототипах самым подлым образом подставляют систему и сужают поле маневра в торге о стоимости системы ) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2006, 00:57 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
wetrweetwertewrrtпросто если Вы перечтете тред и увидите общий ход дискусии ИМХО станет очевидным что речь идет о макетировании в той среде, в которой будет вестись разработка - только и всего. Ну, для начала, у меня сложилось впечатление, что автора топика интересует опыт присутствующих в способах представления (оно же - согласования) сырого проекта заказчику. Макетирование - лишь один (и не факт, что лучший) из способов. wetrweetwertewrrtне нужно обизаться за любимый инструмент, никто на него не наезжает Я не горю желанием предстать перед публикой эдаким обижено насупленным карапузом (и подобных психологических приемов стараюсь не применять в отношении окружающих.. ПЕРВЫМ). По этому, согласен, дискуссию о крутизне сред разработки давайте отложим до лучших времен. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2006, 11:15 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
dfdfasdfasdfsdfдля подготовки действующего прототипа иногда тербуется слишком много времени (и ресурсов - челчасов) проще наделать условно подобных макетов а вообще - все зависит от уровня презентации - на первых шагах достаточно скрин-шотов на планшетах, позже уже прототипы (демки) - прототипы можно погонять на компьютере пользователя Ну это зависит от того, как и на чем делается прототип. У нас, что скриншотов наделать, что показать вживую затраты одинаковые. Конечно вообще на пальцах принцип объяснить - это проще всего :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2006, 12:18 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
1024 Нет-нет, разговор не о рисовании. Разговор о функционирующем макете. Если взять пример про контактную инфу (в любой системе наверна есть контактная инфа) - какие кейсы на три роли: 1.бух хочет позвонить должнику - он должен найти тел. бухгалтера. Ни с кем другим он говорить не будет (упрощённо) 2.курьер хочет спросить как проехать к складу - должен найти тел.склада или ещё какой, всё равно у кого спрашивать, хоть у охраны 3.менеджер вводит конт.инфу по своим контрагентам, вводит конт.лиц, координаты 4.менеджер ищет тел. только тех отделов которым хочет что-то впарить, желательно начальника отдела а не секретутку Posted via ActualForum NNTP Server 1.3 Рисование макетов полезно, если вы хотите уточнить какие-либо требования либо выявить дополнительные функциональные требования, которые неибежно возникнут при углублении в суть вопроса. Есть несколько моментов -- часто, при разработке макетов GUI пользователи начинают активно обсуждать usability, вместо того, чтобы обсудить функциональность. Второе, прежде чем делать макеты, неплохо бвло бы иметь юзкейсы и/или сценарии. Юзкейсы определят цели пользователей и что пользователь должен делать, чтобы их достичь -- причем без акцента на GUI, и имеено с т.з. что делает пользователь, как на это реагирует система. Сценарии, могут совершенно спокойно описывать детали хождения по интерфейсу. Если иметь юзкейсы, дополнить их сценариями и приложить к этому прототипы GUI - возможно, это будет более эффективно, чем только прототипы GUI. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2006, 11:32 |
|
Согласование модели/структуры данных
|
|||
---|---|---|---|
#18+
Есть несколько моментов -- часто, при разработке макетов GUI пользователи начинают активно обсуждать usability, вместо того, чтобы обсудить функциональность. --------------- по-моему это не просто часто а всегда. По вполне понятным причинам. В этих кружочках со стрелочками или сущностях-связях нормальный человек не понимает ничего (программисты часто не понимают) а кнопочки/окошки вполне "осязаемы" их понажимать-подвигать можно. Гуи гуём но речь как раз о кейсах. Т.е. если в примере о контактных адресах телефон нужно не просто ввести у фирмы а завести контактное лицо и у него поставить телефон. Макет обычно и предназначен для того чтоб не объяснять на пальцах а показать последовательность действий, выявить неоднозначности, убедить что такая сложная на первый взгляд структура нужна и не повлечёт чрезмерного усложнения а напротив сделает систему более удобной. Posted via ActualForum NNTP Server 1.3 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2006, 12:34 |
|
|
start [/forum/topic.php?fid=33&msg=33618106&tid=1549428]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 273ms |
0 / 0 |