Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Михаил Курбасов

Страницы: « 1 2 3 4 5 6 »
16
Вы в них определяете план на первые этапы проекта, т.е. границы не с точки зрения функционала Системы, а с точки зрения проектных работ.

Ну да, я же и оговорился, что это консалтинговые проекты. Какой там может быть функционал системы... Тем не менее, эти документы свою роль - согласование с заказчиком границ проекта - превосходно сыграли.

Но если кто-то готов предоставить примеры "более правильных" vision-ов, с удовольствием сам ознакомлюсь.

17
Только уточню на всякий случай - хотя топик называется "документация по результатам обследования", но в практике нашей компании Vision пишется не по результатам обследования, а до его начала.

Обследование - это уже, как правило, часть проектных работ, а vision пишется обычно на этапе, предшествующем началу активных боевых действий. Задача этого документа - удостовериться вместе с заказчиком, что мы правильно вообще поняли, куда идти надо, и застолбить границы работ (и границы обследования, в том числе).

Иногда, конечно, vision делается и по итогам обследования, но это реже, и на этом этапе роль именно vision'а как проектного артефакта существенно ниже. Собственно, на данном этапе уместнее написать отчет об обследовании или даже ТЗ. По крайней мере, те vision'ы, которые делались "по результатам обследования", было безумно трудно запихать хотя бы в 10-15 страниц, потому что аналитики уже нарыли кучу деталей, и вся эта куча страшно выпирает. Эти вижны ОЧЕНЬ похожи на краткие ТЗ. Там 5% информации по целям и границам проекта, 10% про потребности пользователей, еще 5% всякие планы и риски, и 80% - это требования, требования, требования... Имхо теперь когда читаю эти документы задним числом - не могу понять, зачем мы это оформили как vision, почему не написали сразу ТЗ.

18
По поводу конкретных примеров Vision - нашел в загашнике два примерчика, за публикацию которых, надеюсь, меня компания не привлечет по статье  :)

Правда, это примеры vision не на программные проекты, а на консалтинговые, но да разница небольшая. По сути, документ должен определить границы проекта, а для какого проекта это делать - хоть программного, хоть консалтингового, хоть землекопательного - все равно делать это надо, и специфика технологии на данном этапе не сильно влияет.

Пример 1 - это презентация, с которой выступали перед заказчиком. Пытались донести суть работ по проекту, сформировать ожидания результатов проекта. Там еще прикладывался план работ по проекту, но я его по понятным причинам секвестировал.

Пример 2 вообще коротенький, это делалось в командировке за один день, реально примерно за 1,5 часа - приехали на пресейл, выслушали заказчика, набросали vision (вот этот), согласовали с заказчиком - и пошли делать проект.

19
смодерирую  :)
Могли бы Вы назвать темы, которые Вам были интересно услышать на Конференциях?
к сожалению без каких-то примеров РЕАЛЬНЫХ проектов и удачн. решений 
ошибок на них (а не скажем какие штуки есть в UML).
вообщем бы хотелось бы в след. раз услыашть что-то практическое

Поддержу fedor'а. Я вчера смотрел презентации. Рекомендации все дельные, подписался бы. Но одно дело, когда ты сам это сто раз пережил на практике, то и все эти слова кажутся само собой разумееющимися. А для новичков, видимо, действительно не хватает ПРИМЕРОВ - была такая-то конкретная проектная ситуация, применили вот такой метод, стало лучше таким-то вот образом, при этом, однако, огребли вот такие наведенные проблемы, но все равно выгоды перевесили минусы потому-то - вот это было бы совсем зачетно.

20
Картинка в статье суперская, респект!

21
К сожалению до сих пор остается неясным вопрос о сфере практического использования UML, но этот вопрос в данной теме оффтоп..
Лично мне не кажется, что это оффтоп, вопрос как раз уместный. По-моему, в данной теме налицо не вполне удачные попытки применить инструмент, который для выбранной цели не очень подходит. Неудобно запихивать шары в квадратные отверстия, вот мы и мучаемся.

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

Лично мне более близок подход Вигерса, который указывает на то, что варианты использования имеют ограниченное применение. Они подходят как форма промежуточного описания предметной области, когда аналитик только пытается ее как-то декомпозировать - выделяет акторов, их действия по отношению к системе и т.п. Дальше, по Вигерсу, аналитик с этими зарисовками идет к этим акторам, проговаривает с ними сценарии использования (вот тут от них и есть польза), а дальше - ВИ умирают и на смену им приходят требования к ПО, которые аналитик выявил и сформулировал как результат обсуждения с пользователем. Этот подход к формулированию требований является распространенным, но неправильно было бы утверждать, что он является единственно возможным, т.е. что путь к требованиям ПО лежит только через варианты использования. Более того, Вигерс указывает, что для некоторых классов систем (например, со сложными внутренними вычислениями) ВИ мало подходят для использования.

В Вашем кейсе я вижу следующее:
1) бизнес-процессы и алгоритмы работы системы на верхнем уровне Вами описаны;
2) взаимодействие конечных акторов (водители, клиенты) с системой Вы тоже описали, пусть и не в форме классических ВИ;
3) дальнейшее интервьюирование акторов для уточнения требований вряд ли имеет большой практический смысл - если только у Вас есть какие-то продвинутые водители и/или клиенты, с которыми Вы готовы обсудить эту идею - я бы выбрал обсуждать с ними прототип, а не ВИ;
4)  основная "тяжесть" системы состоит во взаимодействии ее компонентов - Sphinks, Katrin, Asterisk, ГИС - при желании это взаимодействие можно расписать в виде ВИ, но, опять же, это не лучший, не единственный и не обязательный способ. Еще такой нюанс - если Вы используете эти системы как готовые/полуготовые, то с практической точки зрения Вы скорее пойдете от существующих интерфейсов к сценариям, нежели наоборот.

Таким образом, Вы можете продолжать попытки применить техники ВИ для описания данной системы; в учебных целях это, наверное, неплохо. Но с практической точки зрения я бы не стал на этом проект останавливать; есть все необходимое, чтобы двигаться дальше.

22
Gordon,
у Вас, судя по тем описаниям, которые Вы представили, система со сложным внутренним алгоритмом. Для описания такой системы варианты использования мало подходят. Не заморачивайтесь на этом формате, отталкивайтесь от того описания бизнес-процесса, которое у вас есть, на его основе формируйте требования к ПО и переходите к программированию.

23
Хорошо, Денис, в следующий раз постараюсь поменьше.

24
Семинар прошел замечательно.

Был слушателем тренинга. В общем, мне понравилось - сделано довольно не плохо

Я была уже на трех треннингах - мне все нравится

Три человека специально зарегистрировались на форуме, чтобы оставить только одно сообщение - в ветке с рекламой тренинга о том, как им там понравилось.
;D ;D ;D
Потоньше надо, поделикатнее...

25
Труд достоин того, чтобы растащить его на цитаты. Респект автору!

26
Привет! Как прошло?

27
А есть среди участников форума юристы или люди, которые могут пообщаться с внятными юристами?
Хотелось бы услышать квалифицированное мнение - насколько соответствует требование регистрации персональных данных на данном интернет-ресурсе (если такое требование будет заявлено) требованиям Федерального Закона о персональных данных?

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

28
Видел разные ТЗ. В том числе со скриншотами форм и текстом примерно таким: "Поля формы такой-то должны быть как на рисунке N". Допускаю, что для каких-то ситуаций это вполне приемлемо.
Вообще, считается, что чем больше деталей технической реализации прописать в ТЗ, тем проще будет потом разработчикам. Т.е. в основном тут идет компромисс со сроками и с желанием заказчика. Если заказчик не против и сроки позволяют, то почему бы не написать ТЗ с детальным описанием всех форм, полей, правил проверки и т.п.

В более типовой ситуации дизайн форм является все-таки предметом какого-то отдельного внутреннего документа разработки, а в согласуемом с заказчиком ТЗ эти сведения даются в более общем виде.

29
О Сайте и Форуме / Re: Новости Cайта
« : 19 Февраля 2009, 22:28:03 »
На мой взгляд, интересная статья о скрытой рекламе:
http://www.nakanune.ru/articles/jelektronnaja_tolpa

Желаю вашему ресурсу не пасть жертвой манипуляций специалистов подобного жанра!

30
О Сайте и Форуме / Re: Новости Cайта
« : 19 Февраля 2009, 22:20:00 »
Я думаю, что найдутся читатели, которым такая статья будет нести пользу и будет очень интересна.
Мне, например, многие рекламные объявления очень интересны и несут большую пользу.
Только от этого они не перестают быть рекламными объявлениями.

Я думаю, что все-таки неверно так делить: если это неинтересно - то это реклама, а если интересно - то нет. Если кто-то считает, что это имеет ценность (а может он ошибается?) - то это не реклама, а если ему не понравилось - то реклама, однозначно.

Давайте опираться не на субъективизм мнений, а на четкие определения и законность. Я за то, чтобы ВСЯ реклама была помечена как "{реклама}".

Страницы: « 1 2 3 4 5 6 »