ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Согласование модели/структуры данных
14 сообщений из 39, страница 2 из 2
  2  все
Согласование модели/структуры данных
    #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
| Ответить | Цитировать | Написать  
14 сообщений из 39, страница 2 из 2
  2  все
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Согласование модели/структуры данных
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=33&gotonew=1&tid=1549428]:
 0ms
get settings:
 12ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 49ms
get topic data:
 12ms
get first new msg:
 9ms
get forum data:
 3ms
get page messages:
 60ms
get tp. blocked users:
 1ms
others: 237ms
total:  406ms
созд. / загр.: 406ms
x
x
Закрыть


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