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

×


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

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


Сообщения - Юрий Булуй

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
586
2Эд: Заканчивай скромничать, а то ишь ты "ноофит", еще и меня умудрился "мастером" обозвать :-))).

2bas:
Эд, уверен что 2-х часов для этого хватит???? Мне кажеться, что более интересно было бы не просто сделать доклад, а сделать что-то вроде круглого стола, но только хорошо модерируемого ... т.к. тема вобщем интересна и наверное многим участникам этого мероприятия было бы интересно высказать и свои точки зрения на эту проблему ....

587
Эд ... по целям и задачам. Цель имеет не столько ограничения, сколько численные критерии -- "Улучшить, ускорить, углубить :-), ... сократить, ..." и т.п. и желательно знать НАСКОЛЬКО увеличиваем/сокращаем, и в каких попугаях измеряем. Цель по аналогии с тем же outmost use case. Т.е. если ставим *типа* цель -- "выбрать тул для <чего-то>", то еще можно задать вопрос "а почему нам нужен тул"? ... вполне возможно, что при ответе на этот вопрос мы сможем сформулировать таки действительно цель -- что-то вроде "сокращения сроков/трудоемкости/ ... при разработке проектов ПО". Другой вопрос -- когда у нас есть иерархия целей, и мы говорим о достижении какой-то промежуточной цели, ... но в этом случае имеет таки смысл приводить всю иерархию. Можно ли говорить про то, что целью является приобретение некоего свойства/возможности, которой раньше не было? Думаю да ... например вполне себе цель "стать обеспеченным человеком с доходом не менее N килобаксов в месяц", если мы, предположим, не можем дать ответ на вопрос "почему необходим именно такой доход?"  :-).

Далее, про процессы. RUP и иже с ним -- это очень общие процессы, как ты понимаешь, более того это фреймворки процессные, чем именно процессы. Более интересен ответ на вопрос не о поддерживает RUP или нет наш тул (ибо это слишком абстрактно), а сформулировать более детальный инстанс процесса (как именно и какие строим модели, как проводим управление изменениями с конкретным планом конфигуправления в этой части и с сущностями которыми мы при этом оперируем, как планируем и НА ОСНОВАНИИ ЧЕГО, что является единицей планирования, как учитываем результаты работ, какую именно технологию создания артефактов используем -- формальные документы по ГОСТ и т.п. или достаточно неформального вэб-сайта по проекту ...). Вот именно в разрезе такого детализированного инстанса процесса и интересно рассматривать использование инструментария. Отсюда же и критерии берутся. Посему ЛЕГЧЕ строить доклад в форме "МЫ РАБОТАЕМ ВОТ ТАК (описываем детали процесса и требования к артефактам) и используем вот такой набор инструментов для <того-то>. Таким-то образом автоматизирован наш процесс. При этом вот эти части процесса на ура автоматизируются, а это приходится делать наполовину вручную. Отсюда выводы ... если ваш процесс близок  к описанному -- одна ситуация, если у вас вот такая и такая вариации -- то могут быть такие и такие траблы ... ". Думаю что в таком формате легче провести доклад и он будет легче воспринимаем. Альтернатива -- четкий, формальный набор критериев и методика оценки. На мой взгляд, второй вариант требует больше усилий. Если формат доклада будет таким как я говорил, не забудьте упомянуть меня "в благодарностях за оказанную поддержку" на слайдах доклада :-)))))).

588
Примеры / Re: Разработка SRS
« : 10 Ноября 2007, 01:08:48 »
Если говорите о ТЗ, то в частности смотрите ГОСТ 34.602 или 19.201. Если посмотреть на ГОСТ 34.201, то можно увидеть список документов, как и если посмотреть на ГОСТ 19.101 ...

589
Цели семинара:
Выбрать/предложить оптимальный набор дешевых/бесплатных средств для поддержки цикла разработки ПО.
Обсудить возможные проблемы в использовании этих средств и выработать пути решения этих проблем.

Аудитория:
Аналитики и ПМ
Я думаю не плохо было бы пригласить вендоров, но для конструктивной критики. Но вряд ли они согласятся.
Доклад будет мой + возможно Стаса Фомина + возможно кого-то от ЛюксПроджекта Потом обсуждение

"Выбрать/предложить тул" -- это как-то на цель мало похоже :-). Больше на задачу :-). Но я бы не стал таким образом ее ставить ... ибо в такой постановке тебе придется давать обоснованные критерии выбора. А коль скоро один из важных критериев отсутствует -- а именно цена (тулы вроде бесплатные и "малобюджетные" рассматриваем?), то остаются только критерии оценки пригодности функциональности. А тут ньюансы ... т.к. многое зависит от ДЕТАЛЕЙ процесса. Пример -- кто-то проводит планирование на базе требований к ПО, а кто-то на основе требований (или более точно -- фич) еще формирует таски и их уже кидает в Проджект например. Тул, например, тасков не делает. Для одних тул валиден, для других нет. Другой вопрос -- если рассмотреть "пригодность" тулов под некий "условный" процесс -- тогда можно давать оценку и делать сравнение. Но этот условный процесс нужно описать.

590
Да, на "расстрел" брендов точно не буду вести ... бестолку это. Ибо большинство критики будет сводится к тому, что "у нас ВОТ ТАК поставлена работа с требованиям/... а ваш тул наши особенности не поддерживает". И будет сделан вывод о том, что "если бы ваши тулы стоили в 10 раз дешевле мы бы их купили" :-).
Но мне было бы интересно услышать чем не устраивает (кроме цены) конкретный инструментарий.

591
Что-то я не понял. Читаю в первом посте программу -- где заявлены тулы вендоров, читаю дальше -- все о бесплатных тулах .... таки о чем семинар я не вполне уже понимаю ...

592
2Gevorg
Если честно, не припомню вас в клиентах Борланда, которые бы к нам в офис обращались с такой проблемой в 2006 г :-). Второй важный вопрос, какие версии инструментария вы использовали ... ? Кстати, у Борланд был написанный консультантами неплохой модуль интеграции с MS Project :-) ... при соответствующих коммуникациях с нами, этот модуль можно было получить забесплатно :-). Еще один вопрос -- так это собственно КАК у вас был организован процесс разработки ПО и КАКУЮ отчетность вы собирали ... т.к. действительно можно придумать множество отчетов, которых нет ни в одном инструментарии.
Насчет доработки -- которая стала в копеечку я не скажу, таки зависит от того что вы хотели делать :-) ... но я написал через API на Delphi off-line клиента для Caliber 2005 SP2 с базовой функциональностью за неполных 3 дня :-).

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

594
Видимо я старею ... но мне кажеться что SECR сбавил обороты ...

595
Ну на кой тогда париться сканировать, когда можно выкачать в PDF или CHM форматах сразу?

596
Клиент использует для анализа своей статистики известный анализатор Web Trends. Хочет иметь кастомизированную систему для анализа продаж и посещаемости, так как трафик большой. Мы исполнители, мне, как аналитику нужно разработать функциональную спецификацию к проекту.
Хочется посмотреть на уже существующие диаграммы. Например, для разработки веб-сайтов примеров очень много.

1. Берете Web Trends и "списываете" его фичи
2. Изучаете как устроены процессы заказчика по "анализу продаж и посещаемовти"
3. Узнаете у заказчика что ему не хватает в этом инструменте и в каком виде он хотел бы видеть информацию и какую информацию (1 и 2, 3 это называется извлечением требований)
3. На основании полученных данных пишите требования к новой системе.

Возможно ему достаточно просто показать на временной шкале кол-во посещений и объемы продаж ... в виде графика :-).

597
Во-во-во! RUP - это теория, а дальше как здесь:
"Сказки, сказки. В жизни все гораааздо тяжелее" Иваси

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

598
Что не понравилось ч.1:
- usecase для г-жи Золотухиной это функция системы, это не давало мне построить логически стройную картину нотации UML и определиться с уровнями детализации usecase еще долго;

Это правда, она не воспринимает того же Коберна на дух :-)

- мы строили модель системы от бизнеса к архитектуре, и в некоторых местах были логические дыры: переход от usecase через usecase realization к паттерну MVC был скомканный (по-моему это связано с тем, что лектор в основном спец по бизнес и системному анализу), переход от usecase к ТЗ был как у фокусника: а теперь ррраз и начинаем требования в реквизите рисовать. Т.е. в паре мест я до сих пор не знаю, или у меня лыжи не катят, или у нее действительно там не трассировка, а пропущены пара действий, которые она просто в уме делает. Но в уме моделировать можно, только если у тебя моделируются типовые системы, типа набора справочников.

Да, тут неплохо бы Лармана подход использовать ... :-).

599
Я бы с удовольствием послушал дискуссию :-). А реально было бы интересно узнать что не понравилось в курсе Золотухиной.

600
Отвечая на корневой вопрос ...
1. Требования к ПО это всегда субъективная оценка в той или иной степени. Прежде чем говорить о качетсве требований, нужно как минимум определить что мы под ним подразумеваем в данном конкретном случае.
2. "Хорошие" требования, это те которые отражают все проанализированные потребности пользователя и которые ДОВЕДЕНЫ до заказчика как правило проактивным способом.
3. Именно поэтому рулят agile методы и интерационность, причем крайне желательно чтобы еще и на пару с time&materials, чтобы заказчик чуствовал ответственность за свои решения.
4. Подписанное ТЗ отнюдь не гарант неизменности ... ставить заказчика в тупик тем что подписали и все, никаких изменений - глупо. Просто изменения должны быть контролируемыми и просчитанными с т.з. оценки стоимости.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »