вопрос
Dmitry Kuznetsov
мне намедни задали задачей создать копию одного довольно непростого
интернет-магазина. Есть ли какие-то инструменты для анализа,
упорядочивания наблюдений, создания плана, to-do list'а? Что
используется в сложных случаях по этому поводу?
--
Regards, Dmitry Kuznetsov
Olexiy Prokhorenko
исходя из ТЗ
инструментов полно, так же как и книжек
Dmitry Kuznetsov
не придется делать. Но в том и фишка что ТЗ там нет никакого. Есть
сайт и надо сделать копию всей функциональности.
--
Regards, Dmitry Kuznetsov
Olexiy Prokhorenko
могут не дать _готовый_ ТЗ, но если Вам
известна функциональность, известны
требования то ТЗ написать Вы должны
сами. Вернее -- не "должны", а в
зависимости сколько как и почему кому
платят :-)
Dmitry Kuznetsov
довольно сложный - надо же как-то все структурировать для написания
ТЗ, чтоб все было максимально просто и ничего не упустить. Вотя и
спрашиваю, бывает ли для этого какой-то софт, облегчающий задачу.
--
Regards, Dmitry Kuznetsov
Olexiy Prokhorenko
и сделает ТЗ? :-) Вряд ли.
ТЗ всегда составляют и стараются не
упустить. Дальше дают заказчику, и
возможно макет (если нужно/можно). Он
это апрувит, и вперед с песнями. Без ТЗ
браться за сложный проект? Это надо
любить экстримальный спорт.
Dmitry Kuznetsov
Ну, фантастики в виде анализа проекта и генерации ТЗ на основе ввода
урла сайта я не жду.
Экстремальный спорт - это очень хорошо, но без четкого задания, на
которое можно опереться, очень неприятно делать проект. Поэтому я его
и избежал (вроде бы). Но фиг его знает что в голову стукнет начальству
в следующий раз... Я думал, что есть софт для упрощения анализа
оригинала. В виде удобного создания всяческих схем, которые призваны
упорядочить картину, разложить все по полочкам, что-ли. Не знаю даже
что ищу, поэтому сложно ответить что это может быть за софт.
--
Regards, Dmitry Kuznetsov
Victor Sergienko
"формализация неформализованного - процесс неформализуемый" (Перлис,
кажется). Возьмите тот же модный RUP.
Учиться, короче, надо. Умение писать код - это ещё далеко не всё, что нужно.
Dmitry Kuznetsov
--
Regards, Dmitry Kuznetsov
Nikolay Gorylenko
http://www-306.ibm.com/software/awdtools/architect/swarchitect/
Dmitry Kuznetsov
--
Regards, Dmitry Kuznetsov
Nikolay Gorylenko
Sergey
RUP это сильно круто для начала.
Как вы знаете, перед началом
проектирования обычно делают анализ, в
т.ч. и требований. Составляют т.н. Scope &
Vision Document, Software requirements specification (SRS), а уж
потом Functional requirements specification (FRS). Первые
два - для заказчика, последний больше
для разработчика.
Эти документы в основном - текстовые и
от этого никуда не деться. Они могут
быть дополнены описанием вариантов
использования, диаграммами потоков
данных, диаграммами
последовательностей и т.п., но они в
первую очередь остаются текстовыми
документами.
Есть такая штука - Rational Requisite Pro и Rational
Clear Quest, которые помогают
структурировать требования на основе
уже написанных SRS. Они ведут базу
требований, привязанных к конкретному
месту SRS документа - это пожалуй
максимум что можно сделать. За
неимением возможности использовать
эти программы можно вести базу самому,
трудность только с синхронизацией.
Хранение требований в
структурированном виде, в виде дерева
также поддерживается упомянутыми
программами и многими другими,
например Mercury QualityCenter, но объединяющий
документ должен быть в любом случае.
По своему опыту знаю, что написать
такой документ ОЧЕНЬ сложно и на это
может уйти неделя и больше, в
зависимомти от масштаба проекта.
Будьте к этому готовы. В любом случае,
это скорее всего окупится:))
Dmitry Kuznetsov
--
Regards, Dmitry Kuznetsov
Olexiy Prokhorenko
его спецификацию.
Расчитать риски; Вам и впрадву софт
никакой не нужен - Вам хорошо бы
следовать PMBOK'у в этом плане и делать по
шагово. Работа очень детальная и очень
непростая.
Это можно нести на подпись заказчику.
Хотя перед тем как за это браться я бы
заказчку описал что я буду делать, и
если он согласиться идти правильными
шагами, только тогда начал бы это
делать. В Украине маленькие компании
очень неохотно напрягаются этим -
хотят чтобы сразу "быстренько" накодил,
а описания и прочего не надо.
Дальше делаете архитектуру проекта и
макет базы (если нужна).
Потом планируете задачи (детально)
основываясь на начальном прототипе из
плана.
А потом начинается разработка.
Если же проект маленький -- это overkill,
забудьте и следуйте модной XP, или любой
другой agile методологии разработки.
Удачи.
Dmitry Kuznetsov
маленькая, всего-то 4 человека. Короче, прекрасно что за проект не
взялись, но на будущее пригодится. Спасибо.
On 3/9/06, Olexiy Prokhorenko <oprokh...@gmail.com> wrote:
--
Regards, Dmitry Kuznetsov
Alexander Ogol
следования "тяжеловесной" методологии? (тому же RUP)?
И второе: XP предполагает постоянное наличие представителя заказчика в
команде, он присутствует на ежедневной планёрке и видит ход дел проекта; тем
самым производится постоянный acceptance testing. Как это вообще согласуется
с оутсорсингом? (наверное, вопрос с подвохом... но я реально не представляю,
КАК... :-\ Если заказчик отвечает через 2-3 дня, а проект - маленький,
короткий, то как прожить без треканья всего и отсылания всех нерешаемых
внутри команды вопросов заказчику?)
Thanks,
Alexander.
Dmitry Kuznetsov
> Как по вашему: когда кончается overkill и появляется необходимость
> следования "тяжеловесной" методологии? (тому же RUP)?
>
У меня - это когда писать такое мочи нет потому что я не в состоянии
понять и полностью поместить в голове картину продукта. То есть когда
работы больше чем на 3-4 дня.
> И второе: XP предполагает постоянное наличие представителя заказчика в
> команде, он присутствует на ежедневной планёрке и видит ход дел проекта; тем
> самым производится постоянный acceptance testing. Как это вообще согласуется
> с оутсорсингом? (наверное, вопрос с подвохом... но я реально не представляю,
> КАК... :-\ Если заказчик отвечает через 2-3 дня, а проект - маленький,
> короткий, то как прожить без треканья всего и отсылания всех нерешаемых
> внутри команды вопросов заказчику?)
У нас сначала все делается что можно сделать, потом нерешенные вопросы
идут сейлеру, который общается с заказчиком. Он грамотно выпытывает,
дает указания. Ну и потом несколько стадий типа "нравится-не
нравится", порой не очень приятных.
--
Regards, Dmitry Kuznetsov
Sergey
Теоретически, RUP и любая хорошая
методология разработки
масштабируется. Это значит, что под
конкретный тип проекта, заказчика и
т.п. процесс может изменяться и
подстраиваться. Практически, вы не
сможете это хорошо сделать без
основательных зананий процесса и
некоторого опыта. Поэтому советую
начинать изучать и пробовать.
Что касается XP - есть большие сомнения,
что она может масштабироваться и
подстраиваться, по крайней мере К.Бек
утверждает, что если вы не выполняете
ВСЕ практики ХР, то это уже не ХР.
Заявление в экстремальном духе, но
совершенно точно, что заказчик в ХР
должен присутствовать на протяжении
всей разработки.
В более формальных методах SRS
составляется всегда, также и
обеспечивается процесс управления
требованиями. Это когда все новые
требования заказчика рассматриваются
и одобряются (с соответствующими
изменениями в плане) либо отклоняются.
Что касается украинских заказчиков, то
они не сильно желают участвовать в
формальном процессе, т.к. большинство
не умеют этого делать и это им не
выгодно (по крайней мере они так
думают). По моему опыту работы на
украинского заказчика руководство о
деньгах договаривалось отдельно, а мы
насчет времени, объема работ и
требований - отдельно с техническими
специалистами заказчика. Эти процессы
мало коррелировали между собой.
В общем-то поэтому большая часть
компаний до сих пор ориентируется на
зарубежного заказчика.