Здравствуйте, gandjustas, Вы писали:
S>Таки поправлю. Всю дорогу я настаивал на использовании модели реальной предметной области. Пардон, как деятельность заказчика может быть оторвана от реальности???
gandjustas, похоже мы запутались в терминах, попытайтесь чётко сформулировать, что вы хотите сказать
:)
Re: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>На самом деле заголовок не совсем точно отражает суть моего вопроса. Ознакомившись с UP я начал как и положено со сбора требований к программе, после чего хотел перейти к разработке прецедентов и их последующему анализу. Однако во время сбора требований я столкнулся с осознанием мысли, что я сам не вполне понимаю какую функциональность должна предлагать система. Конечно в общих чертах я понимал для чего она создаётся, но детализировать функциональность не мог, и соответственно выработать требования в полной мере тоже. Поэтому ещё не дойдя до стадии разработки прецедентов я взялся моделировать интерфейс. Это было связано с тем, что никакой сложной логики система не содержала в принципе, а большинство требований вытекало именно из необходимости предоставить нужную функциональность. Вот теперь гружусь, правильно-ли не собрав все требования в кучу сразу прыгать к интерфейсу, ведь это уже стадия разработки
Я бы начал с изучения аналогов и конкурентов. А в остальном — меньше заморачиваться и просто придерживаться здравого смысла. Первоначальный прототип — это практически всегда хорошо.
Re[12]: Правильно-ли начинать разработку с интерфейса?
C>Сама деятельность нет, а вот его представление о ней легко C>Sinix, я ещё раз перечитал ветку и понял, что для начала надо определиться с терминами. Ещё раз, что Вы понимаете под реальной предметной областью Только можно без абстрактных сущностей, используйте что нибудь более конкретное раз
Определяемся с предметной областью, которую надо автоматизировать. По возможности отделить котлеты от мух^ не смешивать специфику предметной области и специфику бизнеса заказчика. Второе — это как раз бизнес--логика, которую вам предстоит реализовать.
Во-первых, согласитесь, что свойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями. Товары, продавцы и покупатели будут существовать вне желания владельца магазина, также как пассажиры, самолёты и полётные планы — это не глюки диспетчера-солипсиста.
Я ещё раз повторю: сведения о предметной области — это объективная, стабильная и верифицируемая информация. Её можно получить из множества источников — из книг, интервьюирования специалистов, анализа требований. Даже от аналитегов, если к ним достаточно долго приставать.
Если вы здесь видите двусмысленность — пните, исправлюсь.
Если совсем-совсем упрощать, предметная область — это то поле, на котором играет заказчик, со всеми его нюансами и прелестями. Разумеется, нужно соблюдать баланс, чтобы не увязнуть в мелких деталях/не взлететь слишком высоко. Но, даже упрощая модель, вы всё равно знаете о том, что вы отбросили и можете начать управлять риском неправильного выбора уровня детализации.
Re[13]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Cynic, Вы писали:
C>>Сама деятельность нет, а вот его представление о ней легко C>>Sinix, я ещё раз перечитал ветку и понял, что для начала надо определиться с терминами. Ещё раз, что Вы понимаете под реальной предметной областью Только можно без абстрактных сущностей, используйте что нибудь более конкретное S>раз
S>Определяемся с предметной областью, которую надо автоматизировать. По возможности отделить котлеты от мух^ не смешивать специфику предметной области и специфику бизнеса заказчика. Второе — это как раз бизнес--логика, которую вам предстоит реализовать.
S>Во-первых, согласитесь, что свойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями. Товары, продавцы и покупатели будут существовать вне желания владельца магазина, также как пассажиры, самолёты и полётные планы — это не глюки диспетчера-солипсиста.
S>Я ещё раз повторю: сведения о предметной области — это объективная, стабильная и верифицируемая информация. Её можно получить из множества источников — из книг, интервьюирования специалистов, анализа требований. Даже от аналитегов, если к ним достаточно долго приставать.
S> S>Если вы здесь видите двусмысленность — пните, исправлюсь. S>Если совсем-совсем упрощать, предметная область — это то поле, на котором играет заказчик, со всеми его нюансами и прелестями. Разумеется, нужно соблюдать баланс, чтобы не увязнуть в мелких деталях/не взлететь слишком высоко. Но, даже упрощая модель, вы всё равно знаете о том, что вы отбросили и можете начать управлять риском неправильного выбора уровня детализации.
Я пока не могу удариться в глубокий анализ(я на работе ), но разве gandjustas не писал то-же самое. Ведь его подход это то-же "нюансами и прелестями" и прелести заказчика
:)
Re[14]: Правильно-ли начинать разработку с интерфейса?
C>но разве gandjustas не писал то-же самое. Ведь его подход это то-же "нюансами и прелестями" и прелести заказчика
Нет. Предметная область — это то, с чем работает заказчик. Грубо говоря, это требования, предъявляемые к бизнесу заказчика. Чтобы лучше им соответствовать, заказчик внедряет систему, позволяющую упорядочить/упростить свою деятельность.
Однако заказчик трезво (я надеюсь) оценивает свои возможности и возможности разработчика, и не гонится за всеми зайцами сразу, а выбирает наиболее критичные части системы и автоматизирует в первую очередь их. В идеальном случае здесь даже попадётся слово "IT-стратегия"
В результате до разработчиков доходит только описание "мне сейчас нужно то-то и то-то". Разработчик не может делать обоснованные предположения о том как должна работать система, т.к. не не знает ничего о деятельности заказчика.
Естественно, что новые требования полностью разрушают тот образ, который разработчик построил на неполных данных, порождая паранойю ( ), взаимное недоверие и уверенность, что он (разработчик) не в силах приспособиться к хотелкам левого уха правой ноги. Отсюда и подход "мы делаем только то что нам сказали и ответственность должен нести заказчик". Пардон, но разработчикам уже заплатили за решение проблемы.
Re[15]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Cynic, Вы писали:
C>>но разве gandjustas не писал то-же самое. Ведь его подход это то-же "нюансаи и прелести" заказчика
S>Нет. Предметная область — это то, с чем работает заказчик. Грубо говоря, это требования, предъявляемые к бизнесу заказчика. Чтобы лучше им соответствовать, заказчик внедряет систему, позволяющую упорядочить/упростить свою деятельность.
S>Однако заказчик трезво (я надеюсь) оценивает свои возможности и возможности разработчика, и не гонится за всеми зайцами сразу, а выбирает наиболее критичные части системы и автоматизирует в первую очередь их. В идеальном случае здесь даже попадётся слово "IT-стратегия"
S>В результате до разработчиков доходит только описание "мне сейчас нужно то-то и то-то". Разработчик не может делать обоснованные предположения о том как должна работать система, т.к. не не знает ничего о деятельности заказчика.
S>Естественно, что новые требования полностью разрушают тот образ, который разработчик построил на неполных данных, порождая паранойю ( ), взаимное недоверие и уверенность, что он (разработчик) не в силах приспособиться к хотелкам левого уха правой ноги. Отсюда и подход "мы делаем только то что нам сказали и ответственность должен нести заказчик". Пардон, но разработчикам уже заплатили за решение проблемы. S>
У меня после этого диалога уже каша в голове
Давайте так, правильно ли я понял, вы настаиваете на том, что главным источником требований при разработке ПО является анализ предметной области.
Мне лично очень понравилось следующее утверждение:
Если мы не можем описать наше требование используя только введённые ранее термины, мы неверно понимаем либо предметную область, либо требование.
Термины проекта содержит Глоссарий проекта. А фиксация "языка" предметной области является одной из основных составляющих успешного её анализа. Из этого утверждения, а так-же того, что заказчик зачастую сам не в полной мере понимает предметную область вытекает следующее утверждение:
Cвойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями. Товары, продавцы и покупатели будут существовать вне желания владельца магазина, также как пассажиры, самолёты и полётные планы...
Трудно поспорить. Потом вы говоря о модели ПО утверждаете:
В более-менее долгосрочной перспективе эта модель будет асимптотически приближаться к модели реальной деятельности заказчика.
И честно говоря полностью согласен со всем изложенным. Формальный подход к анализу предметной области позволит выявить многие требования, которые другим способом можно и не выявить.
А gandjustas настаивает на том, что главным источником требований должны быть нужды пользователей и требования заказчика, а анализ предметной области потом. Правда анализируя просто требования заказчика и нужды пользователей, можно легко не уловить какие-то требования из предметной области.(Правда и обратное то-же верно) Например, интервьюируя работников гостиничного бизнеса, можно услышать много про бронирование, клиентов, обслуживание и т.п., но при этом возможно вообще ни где не будет явно упоминаться такая значительная сущность как Заказ. Но тем не менее выявление требований таким способом, тоже может обнаружить требования упущенные при аналезе предметной области. Например, требования касательно реализации интерфейса.
Правда он это представляет таким образом, будто бы его подход единственно правильный. Ну и вы не отсатёте
Теперь, если я всё правильно понял, мне кажется странным Ваше противоборство. Ведь понятно, что требования нужно выявлять всеми возможными способами и отдавая приоритет одному из подходов можно что-то упустить. Другой вопрос, что если на выбор приоритетов влияют другие ограничители, типа сроков исполнения стоимости, кол-ва задействованных разарботчиков и т.п, то один из потходов может оказаться в приоритете. Например, анализ предметной области может о-о-очень затянуться.
В связи с этим. Вы мне обьясните это я что-то не так понимаю, или вы ведёте священные войны
Re[16]: Правильно-ли начинать разработку с интерфейса?
А>У меня после этого диалога уже каша в голове
Дык, главная проблема со сложными проблемами в том, что они [неопределённый артикль "сцуко" вырезан цензурой] сложные
А>Давайте так, правильно ли я понял, вы настаиваете на том, что главным источником требований при разработке ПО является анализ предметной области.
Ткните носом в место, где я это говорю А говорил я следующее:
1. Информация о предметной области даёт более полное и объективное знание о деятельности заказчика в целом, чем информация, полученная из требований.
2. В долгосрочной перспективе знания о предметной области — достаточно стабильная штука, чтобы руководствоваться ей при дизайне системы и анализе требований.
Так где я призывал отказаться от требований/отрицал их важность?
А>И честно говоря полностью согласен со всем изложенным. Формальный подход к анализу предметной области позволит выявить многие требования, которые другим способом можно и не выявить.
Только это, цинизма побольше. Это никакой не универсальный решатель, а обычная практика, построенная на полученном опыте. Если использовать её как инструмент, по делу — польза будет. Если превозносить до небес, или, наоборот, отрицать само право на её существования — нет.
А>А gandjustas настаивает на том, что главным источником требований должны быть нужды пользователей и требования заказчика, а анализ предметной области потом.
Так он тоже во многом прав. Во многих ситуациях, например, если разработчик не в силах получить никакой связной информации о деятельности заказчика, или информация доходит через пятые руки, или это просто не нужно заказчику (одноразовое ПО никто не отменял), ничего не остаётся кроме как послать универсальную красивость куда подальше и делать чтобы оно просто работало. Я не говорю, что это хорошо или правильно, но так бывает.
А>Правда он это представляет таким образом, будто бы его подход единственно правильный. Ну и вы не отсатёте
Угуг.
А>Теперь, если я всё правильно понял, мне кажется странным Ваше противоборство.
Не обращайте внимания. Как мне кажется, это уже традиция
А>В связи с этим. Вы мне обьясните это я что-то не так понимаю, или вы ведёте священные войны
Ага
Re[17]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
А>>Давайте так, правильно ли я понял, вы настаиваете на том, что главным источником требований при разработке ПО является анализ предметной области. S>Ткните носом в место, где я это говорю А говорил я следующее: S>1. Информация о предметной области даёт более полное и объективное знание о деятельности заказчика в целом, чем информация, полученная из требований. S>2. В долгосрочной перспективе знания о предметной области — достаточно стабильная штука, чтобы руководствоваться ей при дизайне системы и анализе требований.
S>Так где я призывал отказаться от требований/отрицал их важность?
Ткните носом в место, где я говорю что вы призываете отказаться от требований и отрицаете их важность
Я всего-то пытался понять чего вы пытаетесь сказать! И как я уже сказал, я согласен с тем что Вы оба написали. Просто Вы развили тут такую "традицию", что я уже решил, что упустил "божественную частицу"
Все STOP
Re[16]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Аноним, Вы писали:
А>Например, интервьюируя работников гостиничного бизнеса, можно услышать много про бронирование, клиентов, обслуживание и т.п., но при этом возможно вообще ни где не будет явно упоминаться такая значительная сущность как Заказ.
А если никто из пользователей не оперирует понятием заказа? Или наоборот: часто бывает пользователи оперируют искуственными понятиями, которых нету в реальной предметной области.
Использование предметной области, как её видит себе программист\аналитик, для проектирования часто влечет избыточный и неадекватный дизайн
А>Теперь, если я всё правильно понял, мне кажется странным Ваше противоборство. Ведь понятно, что требования нужно выявлять всеми возможными способами и отдавая приоритет одному из подходов можно что-то упустить.
Еще раз повторю вопрос, вот лично ты на чем будешь основывать свои дизайнерские решения
1)На априорных знаниях о предметной области
2)На информации, полученной от будущих пользователей
?
А>Другой вопрос, что если на выбор приоритетов влияют другие ограничители, типа сроков исполнения стоимости, кол-ва задействованных разарботчиков и т.п, то один из потходов может оказаться в приоритете. Например, анализ предметной области может о-о-очень затянуться.
Кстати есть такая проблема, как "моделирование ручек на столе". При моделировании предметной области нету естественных ограничителей этого процесса, можно так и до атомов добраться.
А>В связи с этим. Вы мне обьясните это я что-то не так понимаю, или вы ведёте священные войны
Все так понимаешь, просто в реальном случае надо пользоваться одним из подходов. даже если можно заниматься как анализом предметной области и получать сведения от пользователей, то где-то информация окажется противоречивой и придется делать выбор: пожертвовать каноничностью предметной области раз решения задач или забить на желания пользователя и делать "правильно".
Re[17]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
G>А если никто из пользователей не оперирует понятием заказа? Или наоборот: часто бывает пользователи оперируют искуственными понятиями, которых нету в реальной предметной области.
Обычно программисты не в курсе предметной области
G>Кстати есть такая проблема, как "моделирование ручек на столе". При моделировании предметной области нету естественных ограничителей этого процесса, можно так и до атомов добраться.
Почему же нету, мозг девелопера — естественный ограничитель. Как только перестал понимать намоделированое, всё, капут, можно считать что дошел до предела
Re[18]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>А если никто из пользователей не оперирует понятием заказа? Или наоборот: часто бывает пользователи оперируют искуственными понятиями, которых нету в реальной предметной области. I>Обычно программисты не в курсе предметной области
Это и не обязательно.
G>>Кстати есть такая проблема, как "моделирование ручек на столе". При моделировании предметной области нету естественных ограничителей этого процесса, можно так и до атомов добраться.
I>Почему же нету, мозг девелопера — естественный ограничитель. Как только перестал понимать намоделированое, всё, капут, можно считать что дошел до предела
Отлично. Получается что моделированием надо заниматься пока получается. Так "ручки на столе" и моделируются.
Re[19]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
G>>>А если никто из пользователей не оперирует понятием заказа? Или наоборот: часто бывает пользователи оперируют искуственными понятиями, которых нету в реальной предметной области. I>>Обычно программисты не в курсе предметной области G>Это и не обязательно.
), но разве gandjustas не писал то-же самое. Ведь его подход это то-же "нюансами и прелестями" и прелести заказчика 
