На самом деле заголовок не совсем точно отражает суть моего вопроса. Ознакомившись с UP я начал как и положено со сбора требований к программе, после чего хотел перейти к разработке прецедентов и их последующему анализу. Однако во время сбора требований я столкнулся с осознанием мысли, что я сам не вполне понимаю какую функциональность должна предлагать система. Конечно в общих чертах я понимал для чего она создаётся, но детализировать функциональность не мог, и соответственно выработать требования в полной мере тоже. Поэтому ещё не дойдя до стадии разработки прецедентов я взялся моделировать интерфейс. Это было связано с тем, что никакой сложной логики система не содержала в принципе, а большинство требований вытекало именно из необходимости предоставить нужную функциональность. Вот теперь гружусь, правильно-ли не собрав все требования в кучу сразу прыгать к интерфейсу, ведь это уже стадия разработки
Здравствуйте, Cynic, Вы писали:
C>На самом деле заголовок не совсем точно отражает суть моего вопроса. Ознакомившись с UP я начал как и положено со сбора требований к программе, после чего хотел перейти к разработке прецедентов и их последующему анализу. Однако во время сбора требований я столкнулся с осознанием мысли, что я сам не вполне понимаю какую функциональность должна предлагать система. Конечно в общих чертах я понимал для чего она создаётся, но детализировать функциональность не мог, и соответственно выработать требования в полной мере тоже. Поэтому ещё не дойдя до стадии разработки прецедентов я взялся моделировать интерфейс. Это было связано с тем, что никакой сложной логики система не содержала в принципе, а большинство требований вытекало именно из необходимости предоставить нужную функциональность. Вот теперь гружусь, правильно-ли не собрав все требования в кучу сразу прыгать к интерфейсу, ведь это уже стадия разработки
Очень правильно. Прототипировать интерфейс — один из способов сбора требований. Зачастую не видя интерфейса ни пользователь, ни программист не может понять что должна делать программа.
Re: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>На самом деле заголовок не совсем точно отражает суть моего вопроса. Ознакомившись с UP я начал как и положено со сбора требований к программе, после чего хотел перейти к разработке прецедентов и их последующему анализу. Однако во время сбора требований я столкнулся с осознанием мысли, что я сам не вполне понимаю какую функциональность должна предлагать система. Конечно в общих чертах я понимал для чего она создаётся, но детализировать функциональность не мог, и соответственно выработать требования в полной мере тоже. Поэтому ещё не дойдя до стадии разработки прецедентов я взялся моделировать интерфейс. Это было связано с тем, что никакой сложной логики система не содержала в принципе, а большинство требований вытекало именно из необходимости предоставить нужную функциональность. Вот теперь гружусь, правильно-ли не собрав все требования в кучу сразу прыгать к интерфейсу, ведь это уже стадия разработки
Прав, но не совсем. Сначала распиши кто и что будет с твоей программой делать, отсюда вытекут и требования, и понимание, что будет делать интерфейс. Ну, например:
Возможный пользователь — Вася, программист (25-35 лет). Вася очень занят, у него нет времени разбираться в бесконечных меню. Он хочет быстро набрать 'Полиморфизм' и получить список статей RSDN, в которых упоминался полиморфизм и прикладывались примеры кода.
После этого лучше рисовать интерфейс на бумажке, потом заставить кого-нибудь покритиковать бумажку. А уж потом — делать начисто. Прогить прототип — потеря времени. Очень долго получается
Re: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>Однако во время сбора требований я столкнулся с осознанием мысли, что я сам не вполне понимаю какую функциональность должна предлагать система. Конечно в общих чертах я понимал для чего она создаётся, но детализировать функциональность не мог, и соответственно выработать требования в полной мере тоже.
Обычно реальное коммерческое приложение реализует группу связанных между собой функций. Как правило, среди этого "клубка" функций есть основные, а есть — вспомогательные, которые обеспечивают более удобное выполнение основных функций. Когда мне сложно понять, какие функции должны быть реализованы, а какие — нет, или же когда мне сложно написать прецедент с учетом вспомогательных функций, я самую главную функцию в "чистом виде" (без всяких вспомогательных "примочек") и пишу для нее юз-кейс. Как правило, такой юз-кейс содержит от 3-х до 5-ти строчек.
Затем я проектирую программу исключительно для этого юз-кейса. Как правило, это просто чертеж на бумаге. Что-то типа sequence-диаграммы или блок-схемы. Но иногда может потребоваться написать прототип. В этом случае, я его пишу.
Далее я инкрементально добавляю к основной функции вспомогательные функции. После чего — модифицирую юз-кейс (или юз-кейсы). Изменения в юз-кейсах требуют внесения изменений в архитектуру. Соответственно, чертеж на бумаге приобретает новый вид. Становится понятной логика развития архитектуры программы.
Как правило, вспомогательные функции становятся очевидными, если ставишь себя на место пользователя и начинаешь представлять, где он будет больше всего испытывать неудобств. Если это неочевидно, то можно поработать с прототипом, который и покажет проблемные места.
C>Поэтому ещё не дойдя до стадии разработки прецедентов я взялся моделировать интерфейс. Это было связано с тем, что никакой сложной логики система не содержала в принципе, а большинство требований вытекало именно из необходимости предоставить нужную функциональность.
Интерфейс, ИМХО, должен вытекать из юз-кейсов и требований к программе. С другой стороны, программа разрабатывается под определенную платформу. А платформа тоже накладывает ограничения на интерфейс. Поэтому реальный GUI — это всегда пересечение требований с ограничениями платформы.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Cynic, Вы писали:
КЛ>Обычно реальное коммерческое приложение реализует группу связанных между собой функций. Как правило, среди этого "клубка" функций есть основные, а есть — вспомогательные, которые обеспечивают более удобное выполнение основных функций. Когда мне сложно понять, какие функции должны быть реализованы, а какие — нет, или же когда мне сложно написать прецедент с учетом вспомогательных функций, я самую главную функцию в "чистом виде" (без всяких вспомогательных "примочек") и пишу для нее юз-кейс. Как правило, такой юз-кейс содержит от 3-х до 5-ти строчек.
КЛ>Затем я проектирую программу исключительно для этого юз-кейса. Как правило, это просто чертеж на бумаге. Что-то типа sequence-диаграммы или блок-схемы. Но иногда может потребоваться написать прототип. В этом случае, я его пишу.
КЛ>Далее я инкрементально добавляю к основной функции вспомогательные функции. После чего — модифицирую юз-кейс (или юз-кейсы). Изменения в юз-кейсах требуют внесения изменений в архитектуру. Соответственно, чертеж на бумаге приобретает новый вид. Становится понятной логика развития архитектуры программы.
КЛ>Как правило, вспомогательные функции становятся очевидными, если ставишь себя на место пользователя и начинаешь представлять, где он будет больше всего испытывать неудобств. Если это неочевидно, то можно поработать с прототипом, который и покажет проблемные места.
КЛ>Интерфейс, ИМХО, должен вытекать из юз-кейсов и требований к программе. С другой стороны, программа разрабатывается под определенную платформу. А платформа тоже накладывает ограничения на интерфейс. Поэтому реальный GUI — это всегда пересечение требований с ограничениями платформы.
Видимо я не совсем точно выразился. У меня уже был список требований, довольно обширный. И я не делал прототип интерфейса, я его рисовал. А в процессе рисования мне приходили свежие мысли по поводу функциональности. И я обновлял список требований.
По плану:
1) Когда я приду к выводу, что все основные требования выявлены, я перейду к моделированию прецедентов, которые видимо ещё больше расширят список требований и скорее всего придётся дополнить интерфейс.
2) После чего хочу перейти к проверке концепций которые мне не совсем понятны. Этот процесс опять-же позволит выявить новые требования и дополнит интерфейс.
3) Всю дорогу, я обновляю общее описание программы. Когда список требований, описание программы и моделирование прецедентов будет закончено, я собираюсь перейти к Анализу, с целью выявления классов Анализа и общего понимания возможной архитектуры программы.
Если есть замечания плз. высказывайте
:)
Re[2]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
G>Очень правильно. Прототипировать интерфейс — один из способов сбора требований. Зачастую не видя интерфейса ни пользователь, ни программист не может понять что должна делать программа.
Я просто думал, что может быть есть какие-то причины выполнять рабочие потоки именно в такой последовательности: Определение требований -> Анализ -> Проектирование -> Реализация -> Тестирование. Выходи что на практике эта последовательность может нарушаться
:)
Re[3]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>Я просто думал, что может быть есть какие-то причины выполнять рабочие потоки именно в такой последовательности: Определение требований -> Анализ -> Проектирование -> Реализация -> Тестирование. Выходи что на практике эта последовательность может нарушаться
Должна нарушаться. Тестирование идет с первого варианта использования и до сдачи продукта. Когда ты проводишь определение требований, ты тоже тестируешь (мысленно). И на каждом этапе логично появляется изменения в результатах предыдущих. Так всё и работает, иначе водопад, со всеми вытекающими
Re[4]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>…Поэтому ещё не дойдя до стадии разработки прецедентов я взялся моделировать интерфейс.
В некоторых случаях начинать именно с интерфейса более чем нормально. Например, если от того, сумеете ли вы предоставить подхоящий интерфейс, зависит — стоит ли вообще браться за разработку
Иногда, просто новая удачная идея представления некоторой привычной оперпции способна определить и успех того, что вы делаете, и подсказать, как именно надо спроектировать более низкоуровневые куски.
Help will always be given at Hogwarts to those who ask for it.
Re[3]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Очень правильно. Прототипировать интерфейс — один из способов сбора требований. Зачастую не видя интерфейса ни пользователь, ни программист не может понять что должна делать программа.
C>Я просто думал, что может быть есть какие-то причины выполнять рабочие потоки именно в такой последовательности: Определение требований -> Анализ -> Проектирование -> Реализация -> Тестирование. Выходи что на практике эта последовательность может нарушаться
Это ты описал тот самый waterfall, который никто не видел и который никогда не работат.
В реальности строгой последовательности не бывает, разработка идет итеративно, фазы часто перекрываются. Например прототипирование — очень важный этап как сбора требований, так и проектирования.
Re: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>Ознакомившись с UP я начал как и положено со сбора требований к программе............................................
Вот теперь гружусь, правильно-ли не собрав все требования в кучу сразу прыгать к интерфейсу, ведь это уже стадия разработки
Если ты сознательно строишь интерфейс, продумывая все детали, обращая внимания на эргономику и т.п., и самое главное затрачиваешь весьма существенную часть времени на это, то да ты занимаешься разработкой.
Если ты строишь интерфейс, используя графические редакторы (ну к примеру WinForm editor), и быстро собираешь предполагаемый интерфейс, чтобы получить представление об образе будущего продукта и узнать у заказчика, то ли это что нужно, причём затраты времени весьма малы, то это фактически сбор требований, ну или по крайней мере их уточнение.
Re: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>Однако во время сбора требований я столкнулся с осознанием мысли, что я сам не вполне понимаю какую функциональность должна предлагать система.
Ну да, итеративный процес разработки не от хорошей жизни придуман.
C> Конечно в общих чертах я понимал для чего она создаётся, но детализировать функциональность не мог, и соответственно выработать требования в полной мере тоже.
Это вы ещё не столкнулись с тем, что одно и то же предложение вы и заказчик понимаете по-разному.
Самый удобный на мой взгляд способ:
1) Определяемся с предметной областью, которую надо автоматизировать. По возможности отделить котлеты от мух^ не смешивать специфику предметной области и специфику бизнеса заказчика. Второе — это как раз бизнес--логика, которую вам предстоит реализовать.
2) Выписываем на листочек основные примитивы предметной области: сущности, связи между ними, инварианты.
3) Расписываем функциональные требования как действия над примитивами, используя только информацию с вышеупомянутого листочка.
На самом деле эта штука жутко микроитеративна, модель предметной области будет постоянно уточняться, сам процесс из пп1-3 может (и должен) идти параллельно с активным прототипированием (в том числе и интерфейса).
В идеале выходит следующее:
1. Вы и заказчик иногда даже понимаете друг-друга
2. У вас есть более-менее стабильная информация для проектирования дизайна — сама модель предметной областью и примерное описание функционала в виде последовательности действий над моделью.
3. Модель предметной области и требования проверяют друг друга: если какое-то требование нельзя описать, используя только уже выявленными сущности, либо вы промахнулись с детализацией/охватом модели, либо заказчик хочет странного.
4. Заказчик начинает понимать, как у него сейчас всё работает
Всё вышеописанное — для проектирования дизайна системы в целом. Дизайн UI — это отдельная и очень больная тема.
Re: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Самый удобный на мой взгляд способ: S>1) Определяемся с предметной областью, которую надо автоматизировать. По возможности отделить котлеты от мух^ не смешивать специфику предметной области и специфику бизнеса заказчика. Второе — это как раз бизнес--логика, которую вам предстоит реализовать. S>2) Выписываем на листочек основные примитивы предметной области: сущности, связи между ними, инварианты. S>3) Расписываем функциональные требования как действия над примитивами, используя только информацию с вышеупомянутого листочка.
Начинать проектирование с данных — пагубный путь. Сразу привязываешься к этим самым структурам, а потом внезапно появляются функции, которые в эти структуры не укладываются и вся "красивая модель предметной области" идет лесом.
Re[3]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
G>Начинать проектирование с данных — пагубный путь. Сразу привязываешься к этим самым структурам, а потом внезапно появляются функции, которые в эти структуры не укладываются и вся "красивая модель предметной области" идет лесом.
Согласен. Но где в моём посте вы увидели слово "данные"? Речь пока шла только о технике сбора/анализа требований.
Если мы не можем описать наше требование используя только введённые ранее термины, мы неверно понимаем либо предметную область, либо требование. Как следствие, мы обнаруживаем противоречие раньше, чем оно повлияет на дизайн системы.
Разумеется, риски не исчезнут совсем, они только слегка минимизируются за счёт разделения заведомо стабильной информации и пожеланий заказчика. И да, без здорового скептицизма оно работать не будет (как и любая другая методика).
Re[4]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Начинать проектирование с данных — пагубный путь. Сразу привязываешься к этим самым структурам, а потом внезапно появляются функции, которые в эти структуры не укладываются и вся "красивая модель предметной области" идет лесом.
S>Согласен. Но где в моём посте вы увидели слово "данные"? Речь пока шла только о технике сбора/анализа требований.
Выписываем на листочек основные примитивы предметной области: сущности, связи между ними, инварианты.
Сущности и есть данные.
S>Если мы не можем описать наше требование используя только введённые ранее термины, мы неверно понимаем либо предметную область, либо требование. Как следствие, мы обнаруживаем противоречие раньше, чем оно повлияет на дизайн системы.
Обычно поток новых требований не иссякает до релиза, и в каждый момент может обнаружится противоречие. Обычно оно заключается не в том что программисты понимают предметную область не так как будущие пользователи (слова "верно" и "неверно" тут неуместны).
S>Разумеется, риски не исчезнут совсем, они только слегка минимизируются за счёт разделения заведомо стабильной информации и пожеланий заказчика. И да, без здорового скептицизма оно работать не будет (как и любая другая методика).
Стабильность информации в данном случае определяет программист, так сказать "на глаз", поэтому невозможно быть абсолютно уверенным в правильности этого определения.
Я за свою недолгую программистскую карьеру повстречал такие приколы "предметной области", как отрицательные суммы заказов, нецелое количество людей на проекте, отсутствие ключевых атрибутов у людей\адресов\других данных.
Теперь я даже не не пытаюсь искать инварианты данных, я сначала анализирую операции и их пред- и пост- условия, но даже при совпадении постусловий не всегда берусь говорить об инвариантах, потому что неясно что завтра захотят заказчики.
Со связями еще интересне: почти на каждом проекте встречал различающиеся мнения разных пользователей о кардинальности связей.
Re[4]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
G>Это ты описал тот самый waterfall, который никто не видел и который никогда не работат.
G>В реальности строгой последовательности не бывает, разработка идет итеративно, фазы часто перекрываются. Например прототипирование — очень важный этап как сбора требований, так и проектирования.
А кто сказал, что waterfall не может быть итеретивным процессом?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[5]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, gandjustas, Вы писали:
G>>Это ты описал тот самый waterfall, который никто не видел и который никогда не работат.
G>>В реальности строгой последовательности не бывает, разработка идет итеративно, фазы часто перекрываются. Например прототипирование — очень важный этап как сбора требований, так и проектирования.
AJD>А кто сказал, что waterfall не может быть итеретивным процессом?
Да нету вообще такого процесса "waterfall", это пугалка для начинающих менеджеров.
Обычно о waterfall говорят когда подразумевают строго последовательный процесс.
Re: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>правильно-ли не собрав все требования в кучу сразу прыгать к интерфейсу, ведь это уже стадия разработки
Это нормально. Для заказчика интерфейс — это и есть система. Если вы на ранней стадии продумаете (и, возможно, согласуете с заказчиком) интерфейс — это будет неплохой гарантией, что система получится такая, какая и требовалась.
Re[5]: Правильно-ли начинать разработку с интерфейса?
Пардон, но вы пытаетесь натянуть _то, как делаем мы_ на свой стиль работы. Естественно, получившийся абсурд не взлетит.
Я ж не зря про здравый смысл писал.
Во-первых, согласитесь, что свойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями. Товары, продавцы и покупатели будут существовать вне желания владельца магазина, также как пассажиры, самолёты и полётные планы — это не глюки диспетчера-солипсиста.
Я ещё раз повторю: сведения о предметной области — это объективная, стабильная и верифицируемая информация. Её можно получить из множества источников — из книг, интервьюирования специалистов, анализа требований. Даже от аналитегов, если к ним достаточно долго приставать.
Собственно в этом вся фишка, если сравнивать с требованиями из разряда "голоса нашептали". Вот там действительно невозможно быть абсолютно уверенным в их правильности.
Во-вторых, разрабатывая программное обеспечение вы в любом случае используете какую-то модель (пусть даже неявную). Проблема в том, что с точки зрения вашего соседа система выглядит по другому, с точки зрения посредника — по третьему, а заказчик, вполне возможно, имел в виду вообще нечто противоположное. Кто из вас прав и что должно быть положено в основу продукта?
Собственно, пока все участники будут играть в "программисты понимают предметную область не так как будущие пользователи" ничего и не изменится.
G>Обычно поток новых требований не иссякает до релиза, и в каждый момент может обнаружится противоречие.
Вы же не утверждаете что противоречие само собой рассосётся? Оно проскользнёт в продукт и останется там до тех пор пока не обнаружится ошибочность требования/ошибочность вашей модели (неявной).
Это уже проблема управления рисками. Если уж закладываться на какую-то информацию, стоит учесть риск что информация окажется неверной и принять меры к его предотвращению, как снижая вероятность возникновения риска/ущерб от его последствий.
G>Я за свою недолгую программистскую карьеру повстречал такие приколы "предметной области", как отрицательные суммы заказов, нецелое количество людей на проекте, отсутствие ключевых атрибутов у людей\адресов\других данных.
Тык значит у вас была ошибка в модели: в первом и третьем случае вы взяли слишком сильные инварианты; во втором — вы моделировали людей вместо ставок штатного расписания.
Re[2]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Fancy, Вы писали:
F>Если ты строишь интерфейс, используя графические редакторы (ну к примеру WinForm editor), и быстро собираешь предполагаемый интерфейс, чтобы получить представление об образе будущего продукта и узнать у заказчика, то ли это что нужно, причём затраты времени весьма малы, то это фактически сбор требований, ну или по крайней мере их уточнение.
Ну да именно этим я и занимаюсь
:)
Re[6]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>Пардон, но вы пытаетесь натянуть _то, как делаем мы_ на свой стиль работы. Естественно, получившийся абсурд не взлетит.
S>Я ж не зря про здравый смысл писал.
S>Во-первых, согласитесь, что свойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями. Товары, продавцы и покупатели будут существовать вне желания владельца магазина, также как пассажиры, самолёты и полётные планы — это не глюки диспетчера-солипсиста.
Ну да, но это же не значит что в любую торговрую программу надо тащить "продавцов" и "покупателей". Все жто будет определяться тем какие функции должна выполнять программа.
S>Я ещё раз повторю: сведения о предметной области — это объективная, стабильная и верифицируемая информация. Её можно получить из множества источников — из книг, интервьюирования специалистов, анализа требований. Даже от аналитегов, если к ним достаточно долго приставать.
Сама по себе предметная область не интересует, это вообще говоря не самые полезные знания для программиста. Важна модель этой области в программе, и далеко не всегда она будет совпадать с реальными понятиями.
S>Во-вторых, разрабатывая программное обеспечение вы в любом случае используете какую-то модель (пусть даже неявную). Проблема в том, что с точки зрения вашего соседа система выглядит по другому, с точки зрения посредника — по третьему, а заказчик, вполне возможно, имел в виду вообще нечто противоположное. Кто из вас прав и что должно быть положено в основу продукта?
Заказчик прав.
G>>Обычно поток новых требований не иссякает до релиза, и в каждый момент может обнаружится противоречие. S>Вы же не утверждаете что противоречие само собой рассосётся? Оно проскользнёт в продукт и останется там до тех пор пока не обнаружится ошибочность требования/ошибочность вашей модели (неявной).
Нет, просто не надо верить в незыблемость "предметной области". И не надо полагаться на нее, как на первоочередной источник знаний о создаваемой системе.
G>>Я за свою недолгую программистскую карьеру повстречал такие приколы "предметной области", как отрицательные суммы заказов, нецелое количество людей на проекте, отсутствие ключевых атрибутов у людей\адресов\других данных.
S>Тык значит у вас была ошибка в модели: в первом и третьем случае вы взяли слишком сильные инварианты; во втором — вы моделировали людей вместо ставок штатного расписания.
Я слава богу избежал ошибок, но все эти особенности никак не укладывались в реальную предметную область. О чем я собственно и толкую.
Re[4]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Если мы не можем описать наше требование используя только введённые ранее термины, мы неверно понимаем либо предметную область, либо требование.
Если я правильно Вас понял, то этим утверждением Вы указываете на необходимость при формулировке требований использовать ТОЛЬКО словарь предметной области, которым является Глоссарий проекта
:)
Re[7]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
S>>Во-первых, согласитесь, что свойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями... G>Ну да, но это же не значит что в любую торговрую программу надо тащить "продавцов" и "покупателей". Все жто будет определяться тем какие функции должна выполнять программа.
Ну да. Сначала вы согласились, что существуют объективные требования и ограничения для деятельности заказчика, и, в конечном счёте, для создаваемой программы. И тут же предлагаете вместо информации "что вообще делает заказчик" для проектирования ограничиться набором для кусочной оптимизации "что заказчик хочет от системы сейчас", забив на грядущие грабли.
G>Сама по себе предметная область не интересует, это вообще говоря не самые полезные знания для программиста. Важна модель этой области в программе, и далеко не всегда она будет совпадать с реальными понятиями.
Да ну? В более-менее долгосрочной перспективе эта модель будет асимптотически приближаться к модели реальной деятельности заказчика. Если действия программы оторваны от реальности — нафига она нужна?
S>>Во-вторых, разрабатывая программное обеспечение вы в любом случае используете какую-то модель (пусть даже неявную). Проблема в том, что с точки зрения вашего соседа система выглядит по другому, с точки зрения посредника — по третьему, а заказчик, вполне возможно, имел в виду вообще нечто противоположное. Кто из вас прав и что должно быть положено в основу продукта? G>Заказчик прав.
Ок. Как разработчик узнаёт об этом, общаясь с представителем заказчика? Дожидается приёмки программы или момента, когда очередное неверно сформулированное требование войдёт в конфликт с имеющимися?
Дальше. Поступающие к разработчику требования — это выжимка из части "модели" в голове заказчика. Разработчик восстанавливает из этих требований свою модель, которая не совпадает с моделью заказчика (а та, вполне возможно — с реальностью). Очередное требование — разработчику приходится снова и снова перестраивать свою модель на основе неполных данных. В результате, долгосрочное качество принимаемых решений — абсолютно никакое.
G>Нет, просто не надо верить в незыблемость "предметной области". И не надо полагаться на нее, как на первоочередной источник знаний о создаваемой системе.
Наколумочалоначинайсначала. Ваше:
S>Во-первых, согласитесь, что свойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями.
Ну да...
?
S>>Тык значит у вас была ошибка в модели: в первом и третьем случае вы взяли слишком сильные инварианты; во втором — вы моделировали людей вместо ставок штатного расписания. G>Я слава богу избежал ошибок, но все эти особенности никак не укладывались в реальную предметную область. О чем я собственно и толкую.
Блин, ну как деятельность заказчика может не укладываться в реальную предметную область???
Ув. gandjustas, предлагаю закругляться. Я в очередной раз высказал всё что мог, вы продолжаете отстаивать свою точку зрения. Шансов переубедить друг друга не просматривается. ?
Re[5]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
S>>Если мы не можем описать наше требование используя только введённые ранее термины, мы неверно понимаем либо предметную область, либо требование. C>Если я правильно Вас понял, то этим утверждением Вы указываете на необходимость при формулировке требований использовать ТОЛЬКО словарь предметной области, которым является Глоссарий проекта
Ну... наверно да Если честно, я не рассматривал свой подход с этой точки зрения, для меня куда важнее, что в ходе сбора и анализа требований я правильно понимаю общую картину, а если не понимаю — узнаю об этом сразу же, а не постфактум.
Разумеется, если у нас хвост виляет собакой и методика ставится во главе всего, глоссарий моментально превратится в стопку из Ожегова и оксфордского словаря. Если же интересует, как процесс выглядит на практике, советую прочитать раздел Creating the Ubiquitous Language из "Domain-Driven Design Quickly" от Эрика Эванса. В PDF-нике (скачивается либо по ссылке, либо отсюда) — страницы 24-26.
Re[8]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Во-первых, согласитесь, что свойства области деятельности заказчика определяются отнюдь не его (заказчика) желаниями и потребностями... G>>Ну да, но это же не значит что в любую торговрую программу надо тащить "продавцов" и "покупателей". Все жто будет определяться тем какие функции должна выполнять программа.
S>Ну да. Сначала вы согласились, что существуют объективные требования и ограничения для деятельности заказчика, и, в конечном счёте, для создаваемой программы. И тут же предлагаете вместо информации "что вообще делает заказчик" для проектирования ограничиться набором для кусочной оптимизации "что заказчик хочет от системы сейчас", забив на грядущие грабли.
Именно, принцип YAGNI рулит.
G>>Сама по себе предметная область не интересует, это вообще говоря не самые полезные знания для программиста. Важна модель этой области в программе, и далеко не всегда она будет совпадать с реальными понятиями. S>Да ну? В более-менее долгосрочной перспективе эта модель будет асимптотически приближаться к модели реальной деятельности заказчика.
Но при этом удаляться от канонической "предметной области".
Поэтому какие-либо рассуждения о предметной области, без понимания какие задачи надо решать, бесполезны.
S>>>Во-вторых, разрабатывая программное обеспечение вы в любом случае используете какую-то модель (пусть даже неявную). Проблема в том, что с точки зрения вашего соседа система выглядит по другому, с точки зрения посредника — по третьему, а заказчик, вполне возможно, имел в виду вообще нечто противоположное. Кто из вас прав и что должно быть положено в основу продукта? G>>Заказчик прав. S>Ок. Как разработчик узнаёт об этом, общаясь с представителем заказчика? Дожидается приёмки программы или момента, когда очередное неверно сформулированное требование войдёт в конфликт с имеющимися?
Проще — формализуется методика испытаний (по госту) aka acceptance tests (по agile).
S>Дальше. Поступающие к разработчику требования — это выжимка из части "модели" в голове заказчика. Разработчик восстанавливает из этих требований свою модель, которая не совпадает с моделью заказчика (а та, вполне возможно — с реальностью). Очередное требование — разработчику приходится снова и снова перестраивать свою модель на основе неполных данных. В результате, долгосрочное качество принимаемых решений — абсолютно никакое.
Более того, при попытке формализации модели в голове заказчика (если она не была формализована до этого) эта модель перестраивается. Поэтому почти всегда долгосрочное качество принимаемых решений никакое.
S>>>Тык значит у вас была ошибка в модели: в первом и третьем случае вы взяли слишком сильные инварианты; во втором — вы моделировали людей вместо ставок штатного расписания. G>>Я слава богу избежал ошибок, но все эти особенности никак не укладывались в реальную предметную область. О чем я собственно и толкую. S>Блин, ну как деятельность заказчика может не укладываться в реальную предметную область???
Да спокойно. Я уже приводил примеры: нецелое количество людей на проекте (ох как весело планирование выглядит в таком случае), отсутствие ключевых атрибутов у сущностей (ну просто пока их 10 было и на бумаге — все устраивало, а стало несколько сотен и в компе, сразу проблема как ссылаться на них) итп. Ну а отрицательные суммы заказов вообще ни в какую бухгалтерию не укладываются.
S>Ув. gandjustas, предлагаю закругляться. Я в очередной раз высказал всё что мог, вы продолжаете отстаивать свою точку зрения. Шансов переубедить друг друга не просматривается. ?
Ну можем по третьему кругу пройтись с примерами реальных заказчиков и тому как априори построенная модель предметной области банально не работала.
Re[9]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
G>Ну можем по третьему кругу пройтись с примерами реальных заказчиков и тому как априори построенная модель предметной области банально не работала.
Осмелюсь и я господа высказть своё мнение по обозначнным вопросам. По моему мнению каждый из Вас прав по своему:
1) Sinix всю дорогу настаивал на чётком формальном подходе к проектированию ПО, справедливо полагая, что при достаточном уровне детализации как он выразился модель "асимптотически приближаться к модели реальной деятельности заказчика".
2) А gandjustas пытался его убедить, что практика зачастую важнее теории. И как это и странно он тоже прав. У нас на работе внедрили систему чётко формализованную и стройную идейно(это мы через пол года эксплуатации выяснили), но сотрудники её ненавидят Потому как свои функции она исполняет на 100%, вот только она уж очень оторвана от реальной жизни и подребностей этих самых сотрудников.
3) Поэтому я сделаю вывод, что каждый из этих в разных пропорциях используется при разработке ПО. А вот какова пропорция это уже зависит от целей и ограничений.
Поэтому мир товарищи Либо я не понял о чём Вы говорили
:)
Re[10]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Ну можем по третьему кругу пройтись с примерами реальных заказчиков и тому как априори построенная модель предметной области банально не работала.
C>Осмелюсь и я господа высказть своё мнение по обозначнным вопросам. По моему мнению каждый из Вас прав по своему: C>1) Sinix всю дорогу настаивал на чётком формальном подходе к проектированию ПО, справедливо полагая, что при достаточном уровне детализации как он выразился модель "асимптотически приближаться к модели реальной деятельности заказчика". C>2) А gandjustas пытался его убедить, что практика зачастую важнее теории. И как это и странно он тоже прав. У нас на работе внедрили систему чётко формализованную и стройную идейно(это мы через пол года эксплуатации выяснили), но сотрудники её ненавидят Потому как свои функции она исполняет на 100%, вот только она уж очень оторвана от реальной жизни и подребностей этих самых сотрудников. C>3) Поэтому я сделаю вывод, что каждый из этих в разных пропорциях используется при разработке ПО. А вот какова пропорция это уже зависит от целей и ограничений.
C>Поэтому мир товарищи Либо я не понял о чём Вы говорили
Все правильно понял.
А теперь вопрос. Ты начинаешь разрабатывать систему, какой подход будешь использовать:
1)Пытаться нарисовать модель предметной области настолько насколько понимают её программисты+аналитики+заказчики, а потом на нее натянуть саму автоматизацию, которая должна упрощать работу.
2)Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение.
?
Re: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
G>Все правильно понял. G>А теперь вопрос. Ты начинаешь разрабатывать систему, какой подход будешь использовать: G>1)Пытаться нарисовать модель предметной области настолько насколько понимают её программисты+аналитики+заказчики, а потом на нее натянуть саму автоматизацию, которая должна упрощать работу. G>2)Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение.
Тут мне кажется выбор приоритетов зависит от самих пользователей. Например, если это физики или математики(это я грубо), т.е. люди с развитым интеллектом и для них пишется специализированный софт, то от них можно писать относительно сложный софт, т.к. от них можно ожидать большей гибкости(хотя и это с оговорками). А вот если это не квалифицированный персонал, то тут в первую очередь надо думать о интерфейсе, т.к. их будет тяжело заставить эффективно работать с тем, что им сложно понять.
Если уж говорить о специализированном софте, то для него упрощение интерфейса, может сыграть медвежью услугу. Такой софт часто пишется на все случаи жизни(например разные САПР'ы), и его возможности имеют гораздо большее значение чем юзабилити интерфейса. Для такого софта характерно то, что он пишется для широкого круга задач и попытавшись хорошо автоматизировать 20% из них, да же наиболее часто используемых, можно сделать просто не выносимым работу с оставшимися, хоть и редко используемыми, возможностями.
Поэтому тут мне кажется всё больше зависит от конкретных задач. Просто большинство софта пишется, что называется для народа, поэтому и самое распространённое требование — интерфейс. Ведь когда вы говорите "Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение", это по сути попытка построить интерфейс с тем, что у них в голове.
В связи с этим, Ваш подход конечно хорош, он практичный. Но если рассматривать формальный подход, то он более точный(и сложный заодно).
:)
Re[3]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Сергей Савостин, Вы писали:
СС>>Проектирование начинается с написания user story G>Со собором требований не путаешь, а?
Видимо имеется ввиду "концептуальное" проектирование.
Re[12]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Все правильно понял. G>>А теперь вопрос. Ты начинаешь разрабатывать систему, какой подход будешь использовать: G>>1)Пытаться нарисовать модель предметной области настолько насколько понимают её программисты+аналитики+заказчики, а потом на нее натянуть саму автоматизацию, которая должна упрощать работу. G>>2)Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение.
C>Тут мне кажется выбор приоритетов зависит от самих пользователей. Например, если это физики или математики(это я грубо), т.е. люди с развитым интеллектом и для них пишется специализированный софт, то от них можно писать относительно сложный софт, т.к. от них можно ожидать большей гибкости(хотя и это с оговорками). А вот если это не квалифицированный персонал, то тут в первую очередь надо думать о интерфейсе, т.к. их будет тяжело заставить эффективно работать с тем, что им сложно понять.
Страшное заблуждение. Даже если пользователь очень умен, то пользоваться заумной программой ему все равно будет неприятно. Обычно только фрики используют такие программы, но их единицы в общей массе.
C>Если уж говорить о специализированном софте, то для него упрощение интерфейса, может сыграть медвежью услугу. Такой софт часто пишется на все случаи жизни(например разные САПР'ы), и его возможности имеют гораздо большее значение чем юзабилити интерфейса. Для такого софта характерно то, что он пишется для широкого круга задач и попытавшись хорошо автоматизировать 20% из них, да же наиболее часто используемых, можно сделать просто не выносимым работу с оставшимися, хоть и редко используемыми, возможностями.
Тем не менее в каком-нить visio интерфейс наверное даже проще, чем в среднестатистической системе документооборота.
C>Поэтому тут мне кажется всё больше зависит от конкретных задач. Просто большинство софта пишется, что называется для народа, поэтому и самое распространённое требование — интерфейс.
Большинство софта — это сайты. На втором месте — заказная автоматизация бизнеса.
C>Ведь когда вы говорите "Проанализировать саму работу будущих пользователей (не предметную область, а именно их действия), потом структурировать знания и на их основе создать приложение", это по сути попытка построить интерфейс с тем, что у них в голове. C>В связи с этим, Ваш подход конечно хорош, он практичный. Но если рассматривать формальный подход, то он более точный(и сложный заодно).
Какой формальный? И почему он более точный, если он не покрывает требования пользователя?
Re[10]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Cynic, Вы писали:
C>1) Sinix всю дорогу настаивал на чётком формальном подходе к проектированию ПО, справедливо полагая, что при достаточном уровне детализации как он выразился модель "асимптотически приближаться к модели реальной деятельности заказчика".
Таки поправлю. Всю дорогу я настаивал на использовании модели реальной предметной области. Пардон, как деятельность заказчика может быть оторвана от реальности???
И, соответственно, как модель деятельности заказчика может выйти за рамки модели предметной области?
C>2) У нас на работе внедрили систему чётко формализованную и стройную идейно(это мы через пол года эксплуатации выяснили), но сотрудники её ненавидят Потому как свои функции она исполняет на 100%, вот только она уж очень оторвана от реальной жизни и подребностей этих самых сотрудников.
Я ж не зря кучу раз писал про необходимость здравого подхода. И вы сейчас, и gandjustas "опровергаете" мои тезисы доводом "мы использовали оторванную от реальной жизни модель и ничего не вышло" с неявным подтекстом "любая модель — это сфероконическая бесполезная штука". Ну и как тут спорить?
C>3) Поэтому я сделаю вывод, что каждый из этих в разных пропорциях используется при разработке ПО. А вот какова пропорция это уже зависит от целей и ограничений.
Таки да, я вроде с самого начала оговорился:
Дизайн UI — это отдельная и очень больная тема.
Внутренняя архитектура и пользовательский интерфейс — понятия ортогональные. В прошлогоднем сраче тов. Gaperton приводил весьма показательный пример
Здравствуйте, Sinix, Вы писали:
C>>2) У нас на работе внедрили систему чётко формализованную и стройную идейно(это мы через пол года эксплуатации выяснили), но сотрудники её ненавидят Потому как свои функции она исполняет на 100%, вот только она уж очень оторвана от реальной жизни и подребностей этих самых сотрудников.
S>Я ж не зря кучу раз писал про необходимость здравого подхода. И вы сейчас, и gandjustas "опровергаете" мои тезисы доводом "мы использовали оторванную от реальной жизни модель и ничего не вышло" с неявным подтекстом "любая модель — это сфероконическая бесполезная штука". Ну и как тут спорить?
Любая модель построенная без анализа действий будущих пользователей будет оторванной от жизни. Особенно хорошо это видно на абсолютно неформализованных предметных областях, типа документооборота.
Re[11]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Внутренняя архитектура и пользовательский интерфейс — понятия ортогональные. В прошлогоднем сраче тов. Gaperton приводил весьма показательный пример
. Проектировать архитектуру исходя из текущих требований так же глупо, как и дизайнить UI на основе какой-то формальной модели.
Такие примеры — скорее исключение, чем правило.
Re[13]: Правильно-ли начинать разработку с интерфейса?
От:
Аноним
Дата:
24.09.10 08:08
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>Страшное заблуждение. Даже если пользователь очень умен, то пользоваться заумной программой ему все равно будет неприятно. Обычно только фрики используют такие программы, но их единицы в общей массе.
Можно подумать человек плотно занимающийся высшей математикой или Теорий пля например, не фрик
G>Тем не менее в каком-нить visio интерфейс наверное даже проще, чем в среднестатистической системе документооборота.
Так система документооборота это и есть специализированный софт. Уж точно более специализированный чем Visio!
G>И почему он более точный, если он не покрывает требования пользователя?
Потому что формальный подход основан на теории, которая рассматривает всё возможные варианты! А ваш подход является его подмножеством. Просто сложно формально подходить к оценке процессов в которых участвует человек, потому что законы его(человека) функционирования не известны и приходится пользоваться приближенными методами, основанными на эксперименте. Например психологи точно не знают почему человек делает так или иначе, и им ни чего не остаётся как надеятся на проверяемый эксперимент, т.е. практику.
Re[4]: Правильно-ли начинать разработку с интерфейса?
От:
Аноним
Дата:
24.09.10 08:25
Оценка:
Здравствуйте, Fancy, Вы писали:
F>Видимо имеется ввиду "концептуальное" проектирование.
Но если пройти по ссылке, то в первой-же строке будет написано "Пользовательские истории (англ. User Story) это способ описания требований к разрабатываемой системе"!
Так что по моему всё в норме
Re[14]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, gandjustas, Вы писали:
G>>Страшное заблуждение. Даже если пользователь очень умен, то пользоваться заумной программой ему все равно будет неприятно. Обычно только фрики используют такие программы, но их единицы в общей массе.
А>Можно подумать человек плотно занимающийся высшей математикой или Теорий пля например, не фрик
Может и фрик, но не компьютерный.
G>>И почему он более точный, если он не покрывает требования пользователя?
А>Потому что формальный подход основан на теории, которая рассматривает всё возможные варианты!
Какой теории? Я уже приводил примеры расхождения терии и практики. Банально в распределении человекоресурсов указывали нецелые числа. Алгоритмы планирования (довольно простые) пришлось серьезно перестраивать.
В областях типа документооборота вообще теории нет, а в бухгалтерии например есть довольно мощная формальная модель — двойная бухгалтерская запись, а все что выше творится зачастую не соответствует ни нормативных документам, ни законодательству.
А>А ваш подход является его подмножеством.
Мой подход — с другой стороны.
Re[11]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, Sinix, Вы писали:
S>Таки поправлю. Всю дорогу я настаивал на использовании модели реальной предметной области. Пардон, как деятельность заказчика может быть оторвана от реальности???
Сама деятельность нет, а вот его представление о ней легко
Sinix, я ещё раз перечитал ветку и понял, что для начала надо определиться с терминами. Ещё раз, что Вы понимаете под реальной предметной областью Только можно без абстрактных сущностей, используйте что нибудь более конкретное
:)
Re[15]: Правильно-ли начинать разработку с интерфейса?
Здравствуйте, 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>Это и не обязательно.
