ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Согласование модели/структуры данных
39 сообщений из 39, показаны все 2 страниц
  все  
Согласование модели/структуры данных
    #33616389
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
При разработке модели данных часто возникает необходимость согласования и предварительного тестирования. Кто как делает?

Например камнем преткновения бывает хранение контактной информации о контрагентах. Пользователи (заказчики) хотят видеть список фирм и у каждой контактный телефон. Ну привыкли они так. Аргументация в духе "чтоб удобно было контору искать по телефону".

Хотя если с этой контактной инф-цией идёт какая-то работа (бухгалтер интересуется оплатой, менеджеры что-то впаривают, курьер спрашивает как проехать к офису и т.п.) - структура должна быть несколько сложней. Упрощенно: табличка контрагентов, подчинённая табличка контактных лиц контрагентов, подчинённая ей табличка телефонов/мейлов контактного лица. Данные могут выглядеть примерно как

секретутка маша - телефон, факс
центральный офис - телефон, мыло
главбух - телефон

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

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

Кто чем для этого пользуется? Создаёт базульку в аксесе или может убеждает заказчика обойтись без проверки или просто картинки формочек в визио рисует.

Предлагаю обсудить
...
Рейтинг: 0 / 0
22.03.2006, 10:54
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33616702
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
1024При разработке модели данных часто возникает необходимость согласования и предварительного тестирования. Кто как делает?

т.е. речь идет о макетировании ?
лучше всего для этого использовать основное средство разработки и макет плавно переходит в боевую систему
...
Рейтинг: 0 / 0
22.03.2006, 12:02
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33616728
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
Но это же долго? Сразу делать так как будет в реальной системе где могут быть дополнительные требования (интерфейс, интеграция с другим ПО и пр.)? И с большой вероятностью что это придётся выбросить, поменять структуру и снова согласовывать?
...
Рейтинг: 0 / 0
22.03.2006, 12:08
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33616903
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
1. по повододу "Т.е. получается достаточно сложно. Предложение обезличенную контактную инф-цию типа "центр.офис", "склад" хранить вместе с контактными лицами вообще вводит в ступор хотя с точки зрения функционирования системы вроде это нормально а иногда необходимо." мы так и делаем,просто разнесли физиков, юриков и подразделения по разным частям интерфейса. Хранятся в одной таблице-пользователи думают,что в разных.
2.Я обычно стараюсь найти понимающего человека среди вернего руководства, и, как показывает опыт, они всегда присутствуют (иначе, обычно, фирма долго не живет).А далее все согласовывается на бумажках.Сложные формы-в Word рисуем,а потом вместе заполняем на бумаге.
...
Рейтинг: 0 / 0
22.03.2006, 12:37
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33617429
Dino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dino
Гость
Экранные формы совсем необязательно должны показывать реальные связи БД.
Стройте экранные формы так, чтобы они удовлетворяли текущие потребности клиента. Кто-то хочет видеть все обезличенные телефоны компании, кто-то хочет видеть список контактных лиц с телефонами, а кто-то список телефонов только одного отдела компании.
Другой вопрос действительно ли заказчик хочет видеть именно это.
Вот тут на помощь и приходят прототипы экранных форм.
Лично я предпочитаю, чтобы формы рисовались в Visio. На собственном опыте убедился, что это гораздо эффективнее чем рисовать в среде разработки.
...
Рейтинг: 0 / 0
22.03.2006, 14:38
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33617497
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
1024Но это же долго? Сразу делать так как будет в реальной системе где могут быть дополнительные требования (интерфейс, интеграция с другим ПО и пр.)? И с большой вероятностью что это придётся выбросить, поменять структуру и снова согласовывать?
на самом деле быстрее всего. макет он и есть макет - картинки поддержанные минимумом функций без которых макет не живой
а рисовать картинки в визио - только время терять. ваша среда разработки должна быть быстрее визио (или это плохая среда)
...
Рейтинг: 0 / 0
22.03.2006, 14:53
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33617523
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
Нет-нет, разговор не о рисовании. Разговор о функционирующем макете. Если
взять пример про контактную инфу (в любой системе наверна есть контактная
инфа) - какие кейсы на три роли:

1.бух хочет позвонить должнику - он должен найти тел. бухгалтера. Ни с кем
другим он говорить не будет (упрощённо)
2.курьер хочет спросить как проехать к складу - должен найти тел.склада или
ещё какой, всё равно у кого спрашивать, хоть у охраны
3.менеджер вводит конт.инфу по своим контрагентам, вводит конт.лиц,
координаты
4.менеджер ищет тел. только тех отделов которым хочет что-то впарить,
желательно начальника отдела а не секретутку

возможность выполнения этих действий и нужно продемонстрировать заказчику.
Можно нарисовать в визио и на словах объяснять, можно сделать в аксесе
базульку с формочками и забить туда какой-то объём данных (так наглядней),
можно сразу рисовать базу и формы которые поёдут в конечное приложение
(намного более трудоёмко).

После обсуждения появляются новые кейсы или меняются существующие, структура
данных корректируется и надо макет выкинуть и по новой делать


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
22.03.2006, 14:58
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33617772
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Я пользуюсь штатной базой, а к ней прикручивается макет.
Клиенту объясняю, что для проектирования БД главное предусмотреть самый сложный случай. Типа для приведенного примера:
Клиент--< Контакт--<Связь>--ТипСвязи,
Контакт>--ТипДолжности
Контакт>--Подразделение>--ТипПодразделения
еще наверно
Клиент--< Подразделение--<Связь>--ТипСвязи

Одновременно показывается, что это не ведет к тому, что бухгатер долго будет рыться в этой куче, чтобы найти/ввести общий телефон бухгалтерии или конкретно главбуха.
На макете не грех просто это в лоб зашить в запросах формы.
...
Рейтинг: 0 / 0
22.03.2006, 16:11
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33618106
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aag
Участник
согласен с mod.
Макет интересен именно в динамике - по статичным картинкам обычный пользователь плохо воспринимает единое целое. А динамику воссоздать можно только программированием.
С др. стороны, у более-менее опытного разработчика на написание кода вызова форм и пр. эту динамику как правило, времени
уходит намного меньше чем на придумывание интерфейсов.
С третий стороны, именно в таком написании сразу сам отсеиваешь неудобные или чересур трудоемкие пути.

Nobody faults but mine... (LZ)
...
Рейтинг: 0 / 0
22.03.2006, 17:42
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33618132
Dino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dino
Гость
В моём случае рисование прототипов экранных форм происходит на этапе анализа. Занимается этим человек, который ничего не знает про программирование, но знает про дизайн пользовательского интерфейса.
Тратить в данном случае время программиста не рационально.
...
Рейтинг: 0 / 0
22.03.2006, 17:49
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33618158
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
В моём случае рисование прототипов экранных форм происходит на этапе
анализа. Занимается этим человек, который ничего не -----------

само собой что дизайном занимается дизайнер. Вопрос в работающем макете (или
описании действий) - чтоб можно было ввести данные, отредактировать, найти
что-то. Для проверки


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
22.03.2006, 17:54
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33619063
Dino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dino
Гость
Вопрос в чём?
Нужен действующий прототип?
Что применять для его реализации?

Для действующего прототипа используйте то, на чём собираетесь разрабатывать.
...
Рейтинг: 0 / 0
23.03.2006, 09:36
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33620129
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
Вопрос в чём?
Нужен действующий прототип?
Что применять для его реализации?

Для действующего прототипа используйте то, на чём собираетесь разрабатывать.
-----------------




я не спрашивал советов, я предлагал обсудить плюсы/минусы подходов

1.нарисовать картинки форм и на словах (на бумаге) объяснять что где лежит и
как заполнять/искать
- менее трудоёмко но и менее наглядно

2.сделать работающий прототип в простом средстве и заполнить тестовыми
данными
- более трудоёмко

3.сделать работающий прототип таким каким он пойдёт в продакшн и заполнить
тестовыми данными
- ещё более более трудоёмко

дополнительно - использовать не тестовые а реальные данные, добавится
огромный пласт работ по конвертации




причём это всё только для макета который вероятно потом придётся просто
выкинуть

кому что ближе и почему? Есть ли какие-то ещё варианты?

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

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


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
23.03.2006, 13:29
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33624870
Фотография nibbles
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nibbles
Участник
Если под моделью понимается логика работы, то - заказчик высказал пожелания, перечислил "выходы", увидел отображение своих пожеланий на макете - дал отмашку "делай". Все довольны.

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

Я обычно подсовываю заказчику нефункциональный макет интерфейса ввода с возможностью показа каких-нить печатных форм-отчетов (болванок, ессно... с графиками, диаграммами и прочими рюшечкам) и делаю это в самом начале разработки. Максимум, что там работает - это переход между формами и "маски" на ввод данных. Ничего большего заказчик видеть не должен - у него сразу идеи появляться начинают, мысли... Нафик... А встречаться с ним в середине или под конец разработки - вообще ахтунг! Так что листики с форами и пояснениями на подпись - и вперед, за работу! А когда ТЗ, плавно перешедшее в спецификацию, уже "затвердили" - работается легко и приятно :))

Макеты клиентских модулей делаю обычно в Access MDB. Из плюсов:
1. Легко переделать в рабочее приложение и перейти на SQL Server (при необходимости)
2. Минимум усилий при максимуме результата в плане построения интерфейсов
3. Масса имеющихся наработок в области интерфейса
4. Легко таскать при необходимости демонстрации и изменять прямо на месте...

А на этапах интервьюирования - лист А4 на планшете и карандаш... никто ничего лучше пока еще не придумал :))

P.S. Не так давно рассказывал эту нехитрую схему одному весьма сертифицированному господину... Ох, как он морщился и кривился - "не по науке это все... кустарненько..."
...
Рейтинг: 0 / 0
25.03.2006, 01:39
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625031
rgrtwertewrtertertertertewrt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rgrtwertewrtertertertertewrt
Гость
расскажу совершенно рабочий вариант - программистов прошу не смеяться

в ходе презентаций и согласования ба'джета очередного этапа,

распечатал имадж формы (эскизы сделаны в среде разработки, но только дизайн + где надо - демоданные) на хорошем принтере в полный цвет на а4 в полный лист,

наклеил на а3 черный лист (специальный картон - пенополистирол с бумажным покрытием по фейсовой стороне - цвет фона черный)

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

прокатило на ура - т.е. вообще без запинки - они были готовы с момента как только взяли планшеты в руки...
...
Рейтинг: 0 / 0
25.03.2006, 12:21
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625082
dfadsfassdf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dfadsfassdf
Гость
rgrtwertewrtertertertertewrtлюди, ответственные за принятие решения...

блин... и кто за язык тянул...

если участники той встречи наткнутся на этот пост, прошу проявить чувство юмора и не обижаться...
...
Рейтинг: 0 / 0
25.03.2006, 13:20
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625090
dfasddfassdfasdfd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dfasddfassdfasdfd
Гость
nibbles
Макеты клиентских модулей делаю обычно в Access MDB. Из плюсов:


из минусов, которые перечеркнут все плюсы (если вы не МДБ-шники ваяете)

набор конролов в формах ACCESS весьма скуден, невозможно отобразить сложные элементы

а если подключать внешние ActiveX время требуемое для на разработки макета становится величиной непредсказуемой,

рисовать сложные элементы в других средах и вставлять на скриншоты аксессных форм - это для бездельников

впрочем, если Access ваша среда - задача сводится к стандартной
...
Рейтинг: 0 / 0
25.03.2006, 13:27
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625304
Фотография nibbles
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nibbles
Участник
dfasddfassdfasdfd nibbles
Макеты клиентских модулей делаю обычно в Access MDB. Из плюсов:

из минусов, которые перечеркнут все плюсы (если вы не МДБ-шники ваяете)
набор конролов в формах ACCESS весьма скуден, невозможно отобразить сложные элементы
а если подключать внешние ActiveX время требуемое для на разработки макета становится величиной непредсказуемой,
рисовать сложные элементы в других средах и вставлять на скриншоты аксессных форм - это для бездельников
впрочем, если Access ваша среда - задача сводится к стандартной
М-да... я давно не видел разводов на флеймы типа "моя линукс твоя виндовс круче".
Мы говорим о макетировании? Ну, и зачем же при макетировании нужны нестандартные ЭУ?
Лично я не собираюсь мерять эффективность среды разработки наличием или отсутствием "продвинутых" ActiveX и Вам этого не советую - это блестюче, красивенько, но бессмыслено. Из собственного опыта и из бесед с коллегами знаю, что лучше обойтись средствами одной IDE, а использования нестандартных ActiveX избегать всеми силами.
...
Рейтинг: 0 / 0
25.03.2006, 17:58
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625534
wetrweetwertewrrt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wetrweetwertewrrt
Гость
nibblesМы говорим о макетировании? Ну, и зачем же при макетировании нужны нестандартные ЭУ?

нестандартные для какой среды - для Access или для Delphi - только об этом и речь... никакаких Linux vs Windows вариаций на тему...

просто если Вы перечтете тред и увидите общий ход дискусии ИМХО станет очевидным что речь идет о макетировании в той среде, в которой будет вестись разработка - только и всего. Если разработка в Access, то и макет в Access исли избрана иная среда - то, соответсвенно в ней и нужно делать екземплы форм... вот и все... никакого флэйма - все по существу ИМХО

не нужно обизаться за любимый инструмент, никто на него не наезжает
...
Рейтинг: 0 / 0
26.03.2006, 00:22
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625538
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
делаем действующие прототипы. Конечно в той же среде, что и релиз. Кроме как на прототипе понять как будет работать система невозможно. А развить структуру данных это проблема разве? Да и создание прототипа вроде бы тоже не проблема. В релизе тонкости отрабатываются и интерфейсы оттачиваются. Иногда прототип с ног на голову переставляется. Это ж процесс...
...
Рейтинг: 0 / 0
26.03.2006, 00:30
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625544
dfdfasdfasdfsdf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dfdfasdfasdfsdf
Гость
iscrafmделаем действующие прототипы. Конечно в той же среде, что и релиз...

для подготовки действующего прототипа иногда тербуется слишком много времени (и ресурсов - челчасов) проще наделать условно подобных макетов

а вообще - все зависит от уровня презентации - на первых шагах достаточно скрин-шотов на планшетах, позже уже прототипы (демки) - прототипы можно погонять на компьютере пользователя (кста - баги в прототипах самым подлым образом подставляют систему и сужают поле маневра в торге о стоимости системы )
...
Рейтинг: 0 / 0
26.03.2006, 00:57
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625606
Фотография nibbles
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nibbles
Участник
wetrweetwertewrrtпросто если Вы перечтете тред и увидите общий ход дискусии ИМХО станет очевидным что речь идет о макетировании в той среде, в которой будет вестись разработка - только и всего.
Ну, для начала, у меня сложилось впечатление, что автора топика интересует опыт присутствующих в способах представления (оно же - согласования) сырого проекта заказчику. Макетирование - лишь один (и не факт, что лучший) из способов.
wetrweetwertewrrtне нужно обизаться за любимый инструмент, никто на него не наезжает
Я не горю желанием предстать перед публикой эдаким обижено насупленным карапузом (и подобных психологических приемов стараюсь не применять в отношении окружающих.. ПЕРВЫМ). По этому, согласен, дискуссию о крутизне сред разработки давайте отложим до лучших времен.
...
Рейтинг: 0 / 0
26.03.2006, 11:15
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33625638
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
dfdfasdfasdfsdfдля подготовки действующего прототипа иногда тербуется слишком много времени (и ресурсов - челчасов) проще наделать условно подобных макетов
а вообще - все зависит от уровня презентации - на первых шагах достаточно скрин-шотов на планшетах, позже уже прототипы (демки) - прототипы можно погонять на компьютере пользователя
Ну это зависит от того, как и на чем делается прототип. У нас, что скриншотов наделать, что показать вживую затраты одинаковые. Конечно вообще на пальцах принцип объяснить - это проще всего :)
...
Рейтинг: 0 / 0
26.03.2006, 12:18
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629019
Фотография byur
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
byur
Участник
1024
Нет-нет, разговор не о рисовании. Разговор о функционирующем макете. Если
взять пример про контактную инфу (в любой системе наверна есть контактная
инфа) - какие кейсы на три роли:

1.бух хочет позвонить должнику - он должен найти тел. бухгалтера. Ни с кем
другим он говорить не будет (упрощённо)
2.курьер хочет спросить как проехать к складу - должен найти тел.склада или
ещё какой, всё равно у кого спрашивать, хоть у охраны
3.менеджер вводит конт.инфу по своим контрагентам, вводит конт.лиц,
координаты
4.менеджер ищет тел. только тех отделов которым хочет что-то впарить,
желательно начальника отдела а не секретутку

Posted via ActualForum NNTP Server 1.3

Рисование макетов полезно, если вы хотите уточнить какие-либо требования либо выявить дополнительные функциональные требования, которые неибежно возникнут при углублении в суть вопроса. Есть несколько моментов -- часто, при разработке макетов GUI пользователи начинают активно обсуждать usability, вместо того, чтобы обсудить функциональность. Второе, прежде чем делать макеты, неплохо бвло бы иметь юзкейсы и/или сценарии. Юзкейсы определят цели пользователей и что пользователь должен делать, чтобы их достичь -- причем без акцента на GUI, и имеено с т.з. что делает пользователь, как на это реагирует система. Сценарии, могут совершенно спокойно описывать детали хождения по интерфейсу. Если иметь юзкейсы, дополнить их сценариями и приложить к этому прототипы GUI - возможно, это будет более эффективно, чем только прототипы GUI.
...
Рейтинг: 0 / 0
28.03.2006, 11:32
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629282
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
Есть несколько моментов -- часто, при разработке макетов GUI пользователи
начинают активно обсуждать usability, вместо того, чтобы обсудить
функциональность.
---------------



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

Гуи гуём но речь как раз о кейсах. Т.е. если в примере о контактных адресах
телефон нужно не просто ввести у фирмы а завести контактное лицо и у него
поставить телефон. Макет обычно и предназначен для того чтоб не объяснять на
пальцах а показать последовательность действий, выявить неоднозначности,
убедить что такая сложная на первый взгляд структура нужна и не повлечёт
чрезмерного усложнения а напротив сделает систему более удобной.


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
28.03.2006, 12:34
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629467
Dino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dino
Гость
1024
Гуи гуём но речь как раз о кейсах. Т.е. если в примере о контактных адресах
телефон нужно не просто ввести у фирмы а завести контактное лицо и у него
поставить телефон. Макет обычно и предназначен для того чтоб не объяснять на
пальцах а показать последовательность действий, выявить неоднозначности,
убедить что такая сложная на первый взгляд структура нужна и не повлечёт
чрезмерного усложнения а напротив сделает систему более удобной.
Можно конечно убедить заказчика. И в этом и в чём-то другом.
Только зачем? Для того чтобы объяснить ему насколько гибкой станет схема БД/система? А если он не хочет:
1. Делать лишних шагов/действий при решение своей задачи.
2. Не хочет платить деньги за дополнительные окна (функции системы).
Конечно, иногда бывает очень полезно обсудить с заказчиком вопрос о составе/последовательности шагов выполнения бизнес-процесса. А если он от этого отказывается, тогда что? Прощай оптимальная система/нормализованная БД и т.д. Разве это может помешать спроектировать систему таким образом, чтобы последующие изменения/добавления функционала минимально затронули систему.
...
Рейтинг: 0 / 0
28.03.2006, 13:21
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629496
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
Можно конечно убедить заказчика. И в этом и в чём-то другом.
Только зачем? Для того чтобы объяснить ему насколько гибкой станет схема
БД/система? А если он не хочет:
1. Делать лишних шагов/действий при решение своей задачи.
2. Не хочет платить деньги за дополнительные окна (функции системы).
-------------------------

не убедить а согласовать. Т.е. предложить, объяснить, выслушать встречные
предложения. Для этого как минимум необходимо говорить на одном языке
предметнику и архитектору (UML не предлагать 8) ).

Способы работы с невменяемыми заказчиками вероятно можно обсудить в другой
ветке


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
28.03.2006, 13:27
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629736
Dino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dino
Гость
1024
не убедить а согласовать. Т.е. предложить, объяснить, выслушать встречные
предложения.

С предметником должен общаться аналитик бизнес/системный, а не архитектор. Один человек может совмещать и аналитика и архитектора, но когда он выступает в роли аналитика, ему нужно помнить что сейчас он аналитик. Я не раз наблюдал картину когда аналитик-архитектор начинает общение с предметником с целью выяснить шаги бизнес-процесса, а спустя 10 минут обсуждает наличие триггеров/внешних ключей/количества слоёв.

- А каков бизнес-процесс-то, который нужно автоматизировать?
- А у нас трёх-звенка!

Если у вас заказчик предъявляет требования к архитектуре, тогда да. Можно и нужно согласовывать.
...
Рейтинг: 0 / 0
28.03.2006, 14:24
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629796
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
Если у вас заказчик предъявляет требования к архитектуре, тогда да. Можно и
нужно согласовывать.
---------------

требования не к архитектуре а вообще. По разному бывает вроде бы. И разное
приходится согласовывать

вопрос именно в том кто как это делает. Высказываемся


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
28.03.2006, 14:39
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629833
Фотография byur
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
byur
Участник
1024

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

Гуи гуём но речь как раз о кейсах. Т.е. если в примере о контактных адресах
телефон нужно не просто ввести у фирмы а завести контактное лицо и у него
поставить телефон. Макет обычно и предназначен для того чтоб не объяснять на
пальцах а показать последовательность действий, выявить неоднозначности,
убедить что такая сложная на первый взгляд структура нужна и не повлечёт
чрезмерного усложнения а напротив сделает систему более удобной.

Posted via ActualForum NNTP Server 1.3

1. Юзкейсы -- в первую очередь ТЕКСТОВЫЕ описания ... и только потом, в качестве иллюстрации общего контекста -- UML диаграммы ("кружочки со стрелочками").
2. Сложность "информационной структуры" вытекает из требований к системе. Требования оперирует четкими понятиями - "система должна", "пользователь должен иметь возможность", .... Должно быть четкое понимание, причем записанное в требованиях, ПОЧЕМУ дложны существовать котнтактные лица. Их существование может объясняться какой-то необходимостью или какой-то логикой использования (да, да, выраженной в тех же юзкейсах). Просто так, "чтобы было" -- так можно сделать много в системе того, что не нужно пользователю ... и не сделать того что действительно нужно. Для этого вводят атрибут требования -- Приоритет ... что-то должно быть обязательно, а что-то желательно.
...
Рейтинг: 0 / 0
28.03.2006, 14:48
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629896
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
8)

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

Варианты как это делать:

1.нарисовать картинки формочек и рассказывать что как делается
2.сделать работающие тестовые формочки и показывать что-куда вводить и где
смотреть
3.сделать реальные формочки такие как они пойдут в продакшн и показывать там

вариант по заполнению данными для тестов
1.генерировать тестовые данные
2.вводить реальные данные



Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
28.03.2006, 15:03
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33629902
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
хотя согласен, во многих случаях обходятся без этого и делаютс сразу чё
могут и много, потом переделывают несколько раз. Для сложных систем мне
кажется это более дорогой путь.


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
28.03.2006, 15:05
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33630278
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aag
Участник
автор1.нарисовать картинки формочек и рассказывать что как делается
2.сделать работающие тестовые формочки и показывать что-куда вводить и где
смотреть
3.сделать реальные формочки такие как они пойдут в продакшн и показывать там
Простой пример. Однажды заказчик (крупный итальянский концерн) прислал нам картинки с непонятным значком внизу. Из обьяснений стало ясно, что это мусорная корзина ;). Из дальнейших распросов выяснилось что ее вполне можно заменить кнопкой "Delete" ;), причем так им даже удобнее.
Конечно, можно списать на малограмотность человека, который эти картинки рисовал - но это хорошая иллюстрация опасности картинок. С одной стороны, я вам могу таких контролов понарисовать, что бедным програмистам придется свой ГУИ изобретать. В то время как вполне можно будет заменить все стандартными. С другой стороны, картинки не отражают динамику - а это принципиально важный момент.
Наконец, с третьей стороны - например для меня набросать некое демо на Delphi будет быстрее, чем вырисовывать все картинки в Visio + схему их вызова.
Причем не нужно опасаться, что затраты на работающие формочки будут пустыми - уже на этом этапе часто можно обкатать какие-то идеи - и даже если конечный вариант внешне будет отличаться, эти идеи останутся.
3-й вариант - делать, так как они пойдут в продакшн - мне непонятен. Откуда вы можете знать - еще даже не показав заказчику - как и что пойдет в продакшн??? Зачем же самих себя настраивать так? Я уже не говорю, что не встречал случаев, когда более-менее серьезную систему принимали такой, какой она была в проекте, по ТЗ - т.е. не запрашивая по ходу разработки кучу изменений.



Nobody faults but mine... (LZ)
...
Рейтинг: 0 / 0
28.03.2006, 16:48
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33630490
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
8O

а чё я-то? Я тож ко второму варианту. Но тут прозвучали мнения и про
применение 3-го и про 1-го


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
28.03.2006, 17:46
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33630978
dgfsdsdsdgdsfdg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dgfsdsdsdgdsfdg
Гость
1024
вариант по заполнению данными для тестов
1.генерировать тестовые данные
2.вводить реальные данные

прикинул второй вариант про данные для тестов... не-не-не... нафиг-нафиг - к терапевту...
...
Рейтинг: 0 / 0
28.03.2006, 23:30
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33631941
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
а аргументы где?

безусловно создать скрипты для заполнения тестовыми данными многократно проще чем посадить девочек вводить бумажные документы.

Но могут быть варианты - например сливаются две системы в одну, у обоих вменяемая структура данных и документация. В таком случае написать набор скриптов для заливки из одной системы в другую не так муторно.
...
Рейтинг: 0 / 0
29.03.2006, 12:41
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33632575
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
proposed amendment
Участник
1024а аргументы где?<...>например сливаются две системы в одну<...>.

а у вас в качестве аргумента вообще частный случай...

ясно было написано - вводить реальные данные

причем по контексту ветки видно, что речь идет о предварительном согласовании... и пока еще нет смысла нанимать операторов...

ясен пень, что если возможно заполнить существующими данными, то лучше так и сделать...
...
Рейтинг: 0 / 0
29.03.2006, 14:44
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33632813
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
"вводить реальные данные" означает вводить реальные данные а не что-то другое. По поводу частностей - у меня щас проект в котором заказчик тестирует часть системы на реальных данных, говорит ему так удобней несмотря на затраты. Если б у меня было больше тысячи проектов я б мог это назвать частным случаем но у меня их не так много и это один из вполне допустимых вариантов. Как и у большинства присутствующих
...
Рейтинг: 0 / 0
29.03.2006, 15:36
| Ответить | Цитировать | Написать  
Согласование модели/структуры данных
    #33633137
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
proposed amendment
Участник
1024"вводить реальные данные" означает вводить реальные данные а не что-то другое. По поводу частностей - у меня щас проект в котором заказчик тестирует часть системы на реальных данных, говорит ему так удобней несмотря на затраты. Если б у меня было больше тысячи проектов я б мог это назвать частным случаем но у меня их не так много и это один из вполне допустимых вариантов. Как и у большинства присутствующих

ну ладно, ладно - я не спорю - просто дискутирую...

вот решение из практики - на базе данных... так... неудачно сформулировал - на основании данных

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

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

при этом пользователь свои данные "узнает" они все равно кажутся ему знакомыми - товарные справочники, география доставки, поставщики и проч. все похоже на то, к чему он привык.

при этом есть занятный трюк (найдено методом проб и ошибок )

метаданные нужно генерить будущими периодами, тогда, если в программе вшита аналитика, можно демонстрировать "рост объема продаж"; "расширение клиентской базы"; "уменьшение дебиторской задолженности" и проч, "сразу после внедрения системы"

на практике был занятный курьез - нагенерировали данных не аккуратно - просто не подумали а сгенерили как придется рандомайзом... и все проводки шли как в будущие периоды - на два года вперед...

показываем прототип Заказчику - смотрим аналитику на графиках - типа "вот как все будет круто и наглядно - все видно - вот продажи вот отдача"...

CFO смотрел смотрел на эти схемы и мрачно так - "мля... так зачит к концу следующего года мы банкроты?" мы немного опешили - "с чего вы взяли - все будет кул - вот смотрите - вот продажи, вот отдача..."

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

в общем - генерить данные нужно аккуратно... и прежде чем Заказчику демки показывать не лишне проверить. Зато теперь если показываем - все нищщак - и продажи растут, и оборачиваемость - все чики-чики - научились
...
Рейтинг: 0 / 0
29.03.2006, 17:04
| Ответить | Цитировать | Написать  
39 сообщений из 39, показаны все 2 страниц
  все  
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Согласование модели/структуры данных
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=33&tid=1549428]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 34ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 63ms
get tp. blocked users:
 1ms
others: 14ms
total:  159ms
созд. / загр.: 159ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]