Правильно-ли начинать разработку с интерфейса? - Архитектура программного обеспечения

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>Пардон, но вы пытаетесь натянуть _то, как делаем мы_ на свой стиль работы. Естественно, получившийся абсурд не взлетит.

S>Я ж не зря про здравый смысл писал.

S>Во-первых, согласитесь, что свойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями. Товары, продавцы и покупатели будут существовать вне желания владельца магазина, также как пассажиры, самолёты и полётные планы — это не глюки диспетчера-солипсиста.
Ну да, но это же не значит что в любую торговрую программу надо тащить "продавцов" и "покупателей". Все жто будет определяться тем какие функции должна выполнять программа.

S>Я ещё раз повторю: сведения о предметной области — это объективная, стабильная и верифицируемая информация. Её можно получить из множества источников — из книг, интервьюирования специалистов, анализа требований. Даже от аналитегов, если к ним достаточно долго приставать.
Сама по себе предметная область не интересует, это вообще говоря не самые полезные знания для программиста. Важна модель этой области в программе, и далеко не всегда она будет совпадать с реальными понятиями.

S>Во-вторых, разрабатывая программное обеспечение вы в любом случае используете какую-то модель (пусть даже неявную). Проблема в том, что с точки зрения вашего соседа система выглядит по другому, с точки зрения посредника — по третьему, а заказчик, вполне возможно, имел в виду вообще нечто противоположное. Кто из вас прав и что должно быть положено в основу продукта?
Заказчик прав.

G>>Обычно поток новых требований не иссякает до релиза, и в каждый момент может обнаружится противоречие.
S>Вы же не утверждаете что противоречие само собой рассосётся? Оно проскользнёт в продукт и останется там до тех пор пока не обнаружится ошибочность требования/ошибочность вашей модели (неявной).
Нет, просто не надо верить в незыблемость "предметной области". И не надо полагаться на нее, как на первоочередной источник знаний о создаваемой системе.

G>>Я за свою недолгую программистскую карьеру повстречал такие приколы "предметной области", как отрицательные суммы заказов, нецелое количество людей на проекте, отсутствие ключевых атрибутов у людей\адресов\других данных.

S>Тык значит у вас была ошибка в модели: в первом и третьем случае вы взяли слишком сильные инварианты; во втором — вы моделировали людей вместо ставок штатного расписания.
Я слава богу избежал ошибок, но все эти особенности никак не укладывались в реальную предметную область. О чем я собственно и толкую.

Здравствуйте, Sinix, Вы писали:

S>Если мы не можем описать наше требование используя только введённые ранее термины, мы неверно понимаем либо предметную область, либо требование.

Если я правильно Вас понял, то этим утверждением Вы указываете на необходимость при формулировке требований использовать ТОЛЬКО словарь предметной области, которым является Глоссарий проекта

Здравствуйте, gandjustas, Вы писали:

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

Ну да. Сначала вы согласились, что существуют объективные требования и ограничения для деятельности заказчика, и, в конечном счёте, для создаваемой программы. И тут же предлагаете вместо информации "что вообще делает заказчик" для проектирования ограничиться набором для кусочной оптимизации "что заказчик хочет от системы сейчас", забив на грядущие грабли.

G>Сама по себе предметная область не интересует, это вообще говоря не самые полезные знания для программиста. Важна модель этой области в программе, и далеко не всегда она будет совпадать с реальными понятиями.
Да ну? В более-менее долгосрочной перспективе эта модель будет асимптотически приближаться к модели реальной деятельности заказчика. Если действия программы оторваны от реальности — нафига она нужна?

S>>Во-вторых, разрабатывая программное обеспечение вы в любом случае используете какую-то модель (пусть даже неявную). Проблема в том, что с точки зрения вашего соседа система выглядит по другому, с точки зрения посредника — по третьему, а заказчик, вполне возможно, имел в виду вообще нечто противоположное. Кто из вас прав и что должно быть положено в основу продукта?
G>Заказчик прав.
Ок. Как разработчик узнаёт об этом, общаясь с представителем заказчика? Дожидается приёмки программы или момента, когда очередное неверно сформулированное требование войдёт в конфликт с имеющимися?
Дальше. Поступающие к разработчику требования — это выжимка из части "модели" в голове заказчика. Разработчик восстанавливает из этих требований свою модель, которая не совпадает с моделью заказчика (а та, вполне возможно — с реальностью). Очередное требование — разработчику приходится снова и снова перестраивать свою модель на основе неполных данных. В результате, долгосрочное качество принимаемых решений — абсолютно никакое.

G>Нет, просто не надо верить в незыблемость "предметной области". И не надо полагаться на нее, как на первоочередной источник знаний о создаваемой системе.
Наколумочалоначинайсначала. Ваше:

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

S>>Тык значит у вас была ошибка в модели: в первом и третьем случае вы взяли слишком сильные инварианты; во втором — вы моделировали людей вместо ставок штатного расписания.
G>Я слава богу избежал ошибок, но все эти особенности никак не укладывались в реальную предметную область. О чем я собственно и толкую.
Блин, ну как деятельность заказчика может не укладываться в реальную предметную область???

Ув. gandjustas, предлагаю закругляться. Я в очередной раз высказал всё что мог, вы продолжаете отстаивать свою точку зрения. Шансов переубедить друг друга не просматривается.

Здравствуйте, Cynic, Вы писали:

S>>Если мы не можем описать наше требование используя только введённые ранее термины, мы неверно понимаем либо предметную область, либо требование.
C>Если я правильно Вас понял, то этим утверждением Вы указываете на необходимость при формулировке требований использовать ТОЛЬКО словарь предметной области, которым является Глоссарий проекта

Ну... наверно да

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

Разумеется, если у нас хвост виляет собакой и методика ставится во главе всего, глоссарий моментально превратится в стопку из Ожегова и оксфордского словаря. Если же интересует, как процесс выглядит на практике, советую прочитать раздел Creating the Ubiquitous Language из "Domain-Driven Design Quickly" от Эрика Эванса. В PDF-нике (скачивается либо по ссылке, либо отсюда) — страницы 24-26.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

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

S>Ну да. Сначала вы согласились, что существуют объективные требования и ограничения для деятельности заказчика, и, в конечном счёте, для создаваемой программы. И тут же предлагаете вместо информации "что вообще делает заказчик" для проектирования ограничиться набором для кусочной оптимизации "что заказчик хочет от системы сейчас", забив на грядущие грабли.

Именно, принцип YAGNI рулит.

G>>Сама по себе предметная область не интересует, это вообще говоря не самые полезные знания для программиста. Важна модель этой области в программе, и далеко не всегда она будет совпадать с реальными понятиями.
S>Да ну? В более-менее долгосрочной перспективе эта модель будет асимптотически приближаться к модели реальной деятельности заказчика.
Но при этом удаляться от канонической "предметной области".
Поэтому какие-либо рассуждения о предметной области, без понимания какие задачи надо решать, бесполезны.

S>>>Во-вторых, разрабатывая программное обеспечение вы в любом случае используете какую-то модель (пусть даже неявную). Проблема в том, что с точки зрения вашего соседа система выглядит по другому, с точки зрения посредника — по третьему, а заказчик, вполне возможно, имел в виду вообще нечто противоположное. Кто из вас прав и что должно быть положено в основу продукта?
G>>Заказчик прав.
S>Ок. Как разработчик узнаёт об этом, общаясь с представителем заказчика? Дожидается приёмки программы или момента, когда очередное неверно сформулированное требование войдёт в конфликт с имеющимися?
Проще — формализуется методика испытаний (по госту) aka acceptance tests (по agile).

S>Дальше. Поступающие к разработчику требования — это выжимка из части "модели" в голове заказчика. Разработчик восстанавливает из этих требований свою модель, которая не совпадает с моделью заказчика (а та, вполне возможно — с реальностью). Очередное требование — разработчику приходится снова и снова перестраивать свою модель на основе неполных данных. В результате, долгосрочное качество принимаемых решений — абсолютно никакое.
Более того, при попытке формализации модели в голове заказчика (если она не была формализована до этого) эта модель перестраивается. Поэтому почти всегда долгосрочное качество принимаемых решений никакое.

S>>>Тык значит у вас была ошибка в модели: в первом и третьем случае вы взяли слишком сильные инварианты; во втором — вы моделировали людей вместо ставок штатного расписания.
G>>Я слава богу избежал ошибок, но все эти особенности никак не укладывались в реальную предметную область. О чем я собственно и толкую.
S>Блин, ну как деятельность заказчика может не укладываться в реальную предметную область???
Да спокойно. Я уже приводил примеры: нецелое количество людей на проекте (ох как весело планирование выглядит в таком случае), отсутствие ключевых атрибутов у сущностей (ну просто пока их 10 было и на бумаге — все устраивало, а стало несколько сотен и в компе, сразу проблема как ссылаться на них) итп. Ну а отрицательные суммы заказов вообще ни в какую бухгалтерию не укладываются.

S>Ув. gandjustas, предлагаю закругляться. Я в очередной раз высказал всё что мог, вы продолжаете отстаивать свою точку зрения. Шансов переубедить друг друга не просматривается.

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

Здравствуйте, gandjustas, Вы писали:

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

Осмелюсь и я господа высказть своё мнение по обозначнным вопросам. По моему мнению каждый из Вас прав по своему:
1) Sinix всю дорогу настаивал на чётком формальном подходе к проектированию ПО, справедливо полагая, что при достаточном уровне детализации как он выразился модель "асимптотически приближаться к модели реальной деятельности заказчика".
2) А gandjustas пытался его убедить, что практика зачастую важнее теории. И как это и странно он тоже прав. У нас на работе внедрили систему чётко формализованную и стройную идейно(это мы через пол года эксплуатации выяснили), но сотрудники её ненавидят

Потому как свои функции она исполняет на 100%, вот только она уж очень оторвана от реальной жизни и подребностей этих самых сотрудников.
3) Поэтому я сделаю вывод, что каждый из этих в разных пропорциях используется при разработке ПО. А вот какова пропорция это уже зависит от целей и ограничений.

Поэтому мир товарищи

Либо я не понял о чём Вы говорили

Здравствуйте, Cynic, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:

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

C>Осмелюсь и я господа высказть своё мнение по обозначнным вопросам. По моему мнению каждый из Вас прав по своему:
C>1) Sinix всю дорогу настаивал на чётком формальном подходе к проектированию ПО, справедливо полагая, что при достаточном уровне детализации как он выразился модель "асимптотически приближаться к модели реальной деятельности заказчика".
C>2) А gandjustas пытался его убедить, что практика зачастую важнее теории. И как это и странно он тоже прав. У нас на работе внедрили систему чётко формализованную и стройную идейно(это мы через пол года эксплуатации выяснили), но сотрудники её ненавидят

Потому как свои функции она исполняет на 100%, вот только она уж очень оторвана от реальной жизни и подребностей этих самых сотрудников.
C>3) Поэтому я сделаю вывод, что каждый из этих в разных пропорциях используется при разработке ПО. А вот какова пропорция это уже зависит от целей и ограничений.

C>Поэтому мир товарищи

Либо я не понял о чём Вы говорили

Все правильно понял.
А теперь вопрос. Ты начинаешь разрабатывать систему, какой подход будешь использовать:
1)Пытаться нарисовать модель предметной области настолько насколько понимают её программисты+аналитики+заказчики, а потом на нее натянуть саму автоматизацию, которая должна упрощать работу.
2)Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение.
?

Проектирование начинается с написания user story

Здравствуйте, Сергей Савостин, Вы писали:

СС>Проектирование начинается с написания user story
Со собором требований не путаешь, а?

Здравствуйте, gandjustas, Вы писали:

G>Все правильно понял.
G>А теперь вопрос. Ты начинаешь разрабатывать систему, какой подход будешь использовать:
G>1)Пытаться нарисовать модель предметной области настолько насколько понимают её программисты+аналитики+заказчики, а потом на нее натянуть саму автоматизацию, которая должна упрощать работу.
G>2)Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение.

Тут мне кажется выбор приоритетов зависит от самих пользователей. Например, если это физики или математики(это я грубо), т.е. люди с развитым интеллектом и для них пишется специализированный софт, то от них можно писать относительно сложный софт, т.к. от них можно ожидать большей гибкости(хотя и это с оговорками). А вот если это не квалифицированный персонал, то тут в первую очередь надо думать о интерфейсе, т.к. их будет тяжело заставить эффективно работать с тем, что им сложно понять.
Если уж говорить о специализированном софте, то для него упрощение интерфейса, может сыграть медвежью услугу. Такой софт часто пишется на все случаи жизни(например разные САПР'ы), и его возможности имеют гораздо большее значение чем юзабилити интерфейса. Для такого софта характерно то, что он пишется для широкого круга задач и попытавшись хорошо автоматизировать 20% из них, да же наиболее часто используемых, можно сделать просто не выносимым работу с оставшимися, хоть и редко используемыми, возможностями.
Поэтому тут мне кажется всё больше зависит от конкретных задач. Просто большинство софта пишется, что называется для народа, поэтому и самое распространённое требование — интерфейс. Ведь когда вы говорите "Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение", это по сути попытка построить интерфейс с тем, что у них в голове.
В связи с этим, Ваш подход конечно хорош, он практичный. Но если рассматривать формальный подход, то он более точный(и сложный заодно).

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Сергей Савостин, Вы писали:

СС>>Проектирование начинается с написания user story
G>Со собором требований не путаешь, а?

Видимо имеется ввиду "концептуальное" проектирование.

Здравствуйте, Cynic, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:

G>>Все правильно понял.
G>>А теперь вопрос. Ты начинаешь разрабатывать систему, какой подход будешь использовать:
G>>1)Пытаться нарисовать модель предметной области настолько насколько понимают её программисты+аналитики+заказчики, а потом на нее натянуть саму автоматизацию, которая должна упрощать работу.
G>>2)Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение.

C>Тут мне кажется выбор приоритетов зависит от самих пользователей. Например, если это физики или математики(это я грубо), т.е. люди с развитым интеллектом и для них пишется специализированный софт, то от них можно писать относительно сложный софт, т.к. от них можно ожидать большей гибкости(хотя и это с оговорками). А вот если это не квалифицированный персонал, то тут в первую очередь надо думать о интерфейсе, т.к. их будет тяжело заставить эффективно работать с тем, что им сложно понять.
Страшное заблуждение. Даже если пользователь очень умен, то пользоваться заумной программой ему все равно будет неприятно. Обычно только фрики используют такие программы, но их единицы в общей массе.

C>Если уж говорить о специализированном софте, то для него упрощение интерфейса, может сыграть медвежью услугу. Такой софт часто пишется на все случаи жизни(например разные САПР'ы), и его возможности имеют гораздо большее значение чем юзабилити интерфейса. Для такого софта характерно то, что он пишется для широкого круга задач и попытавшись хорошо автоматизировать 20% из них, да же наиболее часто используемых, можно сделать просто не выносимым работу с оставшимися, хоть и редко используемыми, возможностями.
Тем не менее в каком-нить visio интерфейс наверное даже проще, чем в среднестатистической системе документооборота.

C>Поэтому тут мне кажется всё больше зависит от конкретных задач. Просто большинство софта пишется, что называется для народа, поэтому и самое распространённое требование — интерфейс.
Большинство софта — это сайты. На втором месте — заказная автоматизация бизнеса.

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

Какой формальный? И почему он более точный, если он не покрывает требования пользователя?

Здравствуйте, Cynic, Вы писали:

C>1) Sinix всю дорогу настаивал на чётком формальном подходе к проектированию ПО, справедливо полагая, что при достаточном уровне детализации как он выразился модель "асимптотически приближаться к модели реальной деятельности заказчика".

Таки поправлю. Всю дорогу я настаивал на использовании модели реальной предметной области. Пардон, как деятельность заказчика может быть оторвана от реальности???
И, соответственно, как модель деятельности заказчика может выйти за рамки модели предметной области?

C>2) У нас на работе внедрили систему чётко формализованную и стройную идейно(это мы через пол года эксплуатации выяснили), но сотрудники её ненавидят

Потому как свои функции она исполняет на 100%, вот только она уж очень оторвана от реальной жизни и подребностей этих самых сотрудников.

Я ж не зря кучу раз писал про необходимость здравого подхода. И вы сейчас, и gandjustas "опровергаете" мои тезисы доводом "мы использовали оторванную от реальной жизни модель и ничего не вышло" с неявным подтекстом "любая модель — это сфероконическая бесполезная штука". Ну и как тут спорить?

C>3) Поэтому я сделаю вывод, что каждый из этих в разных пропорциях используется при разработке ПО. А вот какова пропорция это уже зависит от целей и ограничений.
Таки да, я вроде с самого начала оговорился:

Дизайн UI — это отдельная и очень больная тема.

Внутренняя архитектура и пользовательский интерфейс — понятия ортогональные. В прошлогоднем сраче тов. Gaperton приводил весьма показательный пример. Проектировать архитектуру исходя из текущих требований так же глупо, как и дизайнить UI на основе какой-то формальной модели.

C>Поэтому мир товарищи

Здравствуйте, Sinix, Вы писали:

C>>2) У нас на работе внедрили систему чётко формализованную и стройную идейно(это мы через пол года эксплуатации выяснили), но сотрудники её ненавидят

Потому как свои функции она исполняет на 100%, вот только она уж очень оторвана от реальной жизни и подребностей этих самых сотрудников.

S>Я ж не зря кучу раз писал про необходимость здравого подхода. И вы сейчас, и gandjustas "опровергаете" мои тезисы доводом "мы использовали оторванную от реальной жизни модель и ничего не вышло" с неявным подтекстом "любая модель — это сфероконическая бесполезная штука". Ну и как тут спорить?

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

Здравствуйте, Sinix, Вы писали:

S>Внутренняя архитектура и пользовательский интерфейс — понятия ортогональные. В прошлогоднем сраче тов. Gaperton приводил весьма показательный пример. Проектировать архитектуру исходя из текущих требований так же глупо, как и дизайнить UI на основе какой-то формальной модели.

Такие примеры — скорее исключение, чем правило.

Здравствуйте, gandjustas, Вы писали:

G>Страшное заблуждение. Даже если пользователь очень умен, то пользоваться заумной программой ему все равно будет неприятно. Обычно только фрики используют такие программы, но их единицы в общей массе.

Можно подумать человек плотно занимающийся высшей математикой или Теорий пля например, не фрик

G>Тем не менее в каком-нить visio интерфейс наверное даже проще, чем в среднестатистической системе документооборота.

Так система документооборота это и есть специализированный софт. Уж точно более специализированный чем Visio!

G>И почему он более точный, если он не покрывает требования пользователя?

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

Здравствуйте, Fancy, Вы писали:

F>Видимо имеется ввиду "концептуальное" проектирование.

Но если пройти по ссылке, то в первой-же строке будет написано "Пользовательские истории (англ. User Story) это способ описания требований к разрабатываемой системе"!
Так что по моему всё в норме

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Страшное заблуждение. Даже если пользователь очень умен, то пользоваться заумной программой ему все равно будет неприятно. Обычно только фрики используют такие программы, но их единицы в общей массе.

А>Можно подумать человек плотно занимающийся высшей математикой или Теорий пля например, не фрик

Может и фрик, но не компьютерный.

G>>И почему он более точный, если он не покрывает требования пользователя?

А>Потому что формальный подход основан на теории, которая рассматривает всё возможные варианты!
Какой теории? Я уже приводил примеры расхождения терии и практики. Банально в распределении человекоресурсов указывали нецелые числа. Алгоритмы планирования (довольно простые) пришлось серьезно перестраивать.
В областях типа документооборота вообще теории нет, а в бухгалтерии например есть довольно мощная формальная модель — двойная бухгалтерская запись, а все что выше творится зачастую не соответствует ни нормативных документам, ни законодательству.

А>А ваш подход является его подмножеством.
Мой подход — с другой стороны.

	От:	Cynic
	Дата:	23.09.10 10:30
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	23.09.10 10:37
Оценка:

	От:	Cynic
	Дата:	23.09.10 11:09
	Оценка:

	От:	Sinix
	Дата:	23.09.10 12:27
	Оценка:

	От:	Sinix
	Дата:	23.09.10 12:50
	Оценка:

	От:	Сергей Савостин
	Дата:	23.09.10 19:35
	Оценка:

	От:	Аноним
	Дата:	24.09.10 08:08
	Оценка:

	От:	Аноним
	Дата:	24.09.10 08:25
	Оценка: