Комментарии 55
Лучше всего не спрашивать таких вопросов, а сразу же выкладывать статью(-и).
А что касается самой публикации, тема статьи мне кажется очень интересной.
А что касается самой публикации, тема статьи мне кажется очень интересной.
Хм. Это конечно интересно, но почему Вы не используете уже отработанные варианты типа RUP ?
Лично я считаю, что RUP, как и любая другая "тяжелая" методология - не самый удачный выбор для небольших комманд, разрабатывающих среднего уровня сложности веб-приложения. Мы приверженцы гибкой (agile) разработки, которая позволяет нам больше делать и меньше говорить. Хотя, если речь идет об интерпрайзе, то там бюрократия - неотъемлимая часть разработки ПО и правила игры совсем другие.
Ну RUP тут точно непричём. Может быть - OpenUP/Basic, который есть облегчённый в Agile RUP, но и то у команды не тот уровень зрелости пока, похоже, хотя он именно для такого размера и задумывался.
интересно.
«интерфейс определяет модель» — занятно, это как? Традиционной является как раз противположно направленная связь.
Конечно было бы интересно почитать про применяемый процесс разработки. Возможно, вам это будет даже полезнее, чем сообществу. Подайте лучше по частям, но одновременно.
Конечно было бы интересно почитать про применяемый процесс разработки. Возможно, вам это будет даже полезнее, чем сообществу. Подайте лучше по частям, но одновременно.
Подход от интерфейса к функционалу имеет свои преимущества.
"Интерфейс определяет модель" нужно воспринимать скорее как "каким образом интерфейс может определять модель" т.е. без фанатизма :)
Работа ведется сначала над интерфейсом, с активным участием заказчика в этом процессе. Изменения вносятся легко и непринужденно, так как править представление - это совсем не то же самое, что править модель. В итоге получаем модель, которая может отличаться от исходной (если бы она существовала) очень сильно, начиная от новых атрибутов у объектов и заканчивая появлением новых объектов и отношений. Конечно, мы не избавляемся от риска появления новых требований и необходимости изменения модели. Более того, мы знаем, что они будут и не боимся этого :) Но описанный выше подход позволяет существенно снизить их количество, особенно на ранней стадии разработки.
Работа ведется сначала над интерфейсом, с активным участием заказчика в этом процессе. Изменения вносятся легко и непринужденно, так как править представление - это совсем не то же самое, что править модель. В итоге получаем модель, которая может отличаться от исходной (если бы она существовала) очень сильно, начиная от новых атрибутов у объектов и заканчивая появлением новых объектов и отношений. Конечно, мы не избавляемся от риска появления новых требований и необходимости изменения модели. Более того, мы знаем, что они будут и не боимся этого :) Но описанный выше подход позволяет существенно снизить их количество, особенно на ранней стадии разработки.
У них "интерфейс" используется как замена письменным требованиям, как я понял. Вполне разумно, в определённых пределах.
Да, очень интересно. Выкладывайте. :)
Мне кажется, что лучше сделать цикл статей (по одной статье на тезис). Хотя, если объем не очень большой, то лучше, наверное, все целиком.
Мне кажется, что лучше сделать цикл статей (по одной статье на тезис). Хотя, если объем не очень большой, то лучше, наверное, все целиком.
Лучше все вместе, так лучше воспринимается.
Vox, респект за картинку ))
афтару: жду статью целиком ))
от себя: считаю что сначала надо делать дизайн/интрефейс целиком, абс всего, и верстать. т.е. должен получиться "макет" готового сайта.
а потом уже "оживлять" програмированием )
афтару: жду статью целиком ))
от себя: считаю что сначала надо делать дизайн/интрефейс целиком, абс всего, и верстать. т.е. должен получиться "макет" готового сайта.
а потом уже "оживлять" програмированием )
Используем для разработки интерфейсов Axure (http://www.axure.com/)
Рекомендую для ознакомления.
=============
P.S. RUP тоже имеет место быть.
Рекомендую для ознакомления.
=============
P.S. RUP тоже имеет место быть.
Он, насколько я понял, в итоге генерит обычный html. Вы используете этот html код в проекте или верстаете с нуля?
С нуля, конечно. Только он не просто HTML генерирует, а документацию к интерфейсу и рабочую презентацию (демоверсию)
А почему бы сразу же не начать делать шаблоны для проекта и не заставить их работать средствами фреймворка? Времени уйдет немного больше, зато вы получите рабочую заготовку интерфейса. Хотя, все зависит от подхода, который вы используете для разработки ПО. Поэтому то что я считаю оверхедом, глядя со своей колокольни, в вашем случае может быть оправданно.
P.S. С программой все-равно ознакомлюсь :)
P.S. С программой все-равно ознакомлюсь :)
Если это действительно методика разработки приложения, то:
Где у Вас анализ предметной области и бизнес-процессов клиента? Где изучение или составление требований к продукту проекта? Где у вас составление проектной документации? и т.д. или вы переходите сразу к построению наброска интерфейса?
Где у Вас анализ предметной области и бизнес-процессов клиента? Где изучение или составление требований к продукту проекта? Где у вас составление проектной документации? и т.д. или вы переходите сразу к построению наброска интерфейса?
Тема проектирования не была затронута сознательно, иначе получилась бы не статья, а книга :) Естественно, мы не начинаем работу над проектом с набросков интерфейса. Но и на этапе проектирования стремимся быть гибкими и свести процесс бумагомарания к минимуму.
а вы делаете только слабонагруженные проекты? вопросы архитектуры в принципе не обсуждаете, т.к. нет необходимости?
У нас были проекты средней нагрузки: 40к хостов, 200к хитов. Проектов с большой нагрузкой не разрабатывали. Что в вашем понимании есть "выбор архитектуры"?
Возникает новый проект, и требования, которые касаются архитектуры, а именно - производительность, интеграция, технические ограничения необходимо согласовать с вашей платформой (если она у вас есть) - потянет ли вообще, если нет, что делать; что делать, если клиент просит postgres, а у вас всё заточено под mysql и т.д. Эту работу тоже надо делать, и она не относится ни к требованиям, ни к программированию.
С терминами мы определились, вернемся к вопросу: "вопросы архитектуры в принципе не обсуждаете, т.к. нет необходимости?" Если кратко: обсуждаем. Но мы ограничены используемыми языками программирования, фреймворком, операционными системами (разрабатываем только по unix-подобные ОС) и так далее со всеми вытекающими последствиями. Если бы мы одинаково хорошо владели .Net, Java, PHP, Ruby, дела бы обстояли иначе. Что касается железа и сопутствующих вопросов: мы консультируемся с людьми, которые разбираются в этом лучше нас и стараемся прислушиваться к их мнению.
Не совсем понятно, правда, какое отношение это имеет к интерфейсам и озвученным тезисам :)
вы пишете - "... статью по разработке веб-приложений ..."
вопросы архитектуры входят в разработку веб-приложений и вы ими занимаетесь, но в озвученные вами тезисы она почему-то не вошла
вопросы архитектуры входят в разработку веб-приложений и вы ими занимаетесь, но в озвученные вами тезисы она почему-то не вошла
Не вошла, более того, мы занимаемся еще многими вещами, которые не вошли в тезисы :) И я не упомянул их не потому, что считаю маловажными. Просто мы взяли конкретные проблемы и хотим описать подход, применяемый для их решения. Ничего больше.
P.S. "Готовый продукт", наверное не самое удачное название для последнего пункта, может именно оно вас смутило? Имелось в виду объединение дизайна и запрограммированного интерфейса.
P.S. "Готовый продукт", наверное не самое удачное название для последнего пункта, может именно оно вас смутило? Имелось в виду объединение дизайна и запрограммированного интерфейса.
Почему бы сразу в этих статьях не затронуть тему подготовки test cases (здесь и настоящий контент пригодится к описанию), SEO оптимизации готового контента, проверка на пользователях и подобное. Вы используете эти моменты в своей работе?
Прочтите вот этот мой комментарий :)
Вообще тестирование основывается на требованиях. Если они даже не говорят про последние, то какие могут быть тесты? ) Тестировать на соответствие чему?
Вы невнимательно читаете мои комментарии :)
Кстати, а что вы скажите касательно приемочного тестирования (тестирования "черного ящика")?
очень полезная штука, наряду с остальными типами тестов, перечисленными мной вот здесь: http://beskov.livejournal.com/14493.html
Я к тому, что для приемочного тестирования не обязательно иметь доступ к требованиям.
P.S. На ваш блог уже довольно давно подписан ;)
P.S. На ваш блог уже довольно давно подписан ;)
User Story - это не требования, вы со мной согласны?
я рад, что мы поняли друг друга)
Различные современные подходы к описанию функциональных требований обсуждаются вот здесь.
С другой стороны я немного погорячился, признаю :) Без аналога требований заниматься приемочным тестированием весьма проблематично.
Возможно, вам пригодится статья: http://zeus.sai.msu.ru:7000/SE/project/selfmade/
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Разработка веб-приложений: наша методика