4771

Сообщество Аналитиков / Re: Нужны добровольцы для структурирования файлового архива

« : 08 Ноября 2007, 18:39:25 »

Сказал одному пареньку. Тот ответил, что подумает. Однако нужно:

1. структуру исходных файлов

2. предлагаемую структуру с переносом

3. предлагаемую цену и возможности работать через фтп

4772

Конференции Семинары и Тренинги / Re: [Семинар] - Альтернативные системы поддержки процесса разработки ПО (МСК)

« : 08 Ноября 2007, 18:37:37 »

Irr, fixed, thanks

Мною заметь!

4773

Примеры / Re: Разработка SRS

« : 08 Ноября 2007, 18:36:44 »

А на счет опубликования своей я с радостью как доделаю , а пока еще только на 50 % выполнено.

Типичный водопадный подход. Чего ждать? Чтобы 100% переделывать на 90%? Или понять что не так в 50%, чтобы переделать совсем не много.
Коммуникация, и еще раз коммуникация. Раз есть проблемы, то объясните в чем они. Конкретно, где в каком пункте, с чем связана, с формулировкой или не понимаем назначения и т.п.

А так могу лишь посоветовать : http://authorit.ru/?c=8&b=3

4774

Обучение / Re: Книга Введение в анализ, синтез и моделирование систем. Ваше мнение?

« : 08 Ноября 2007, 18:33:27 »

Мое мнение - так себе. Смотри аналогичный курс на Intuite и не нужно тратится. А вообще я его давно использую этот курс - с года так 2002-2003, кое что перенял.

4775

Системный Анализ и Требования / Re: Управление требованиями

« : 08 Ноября 2007, 18:29:44 »

Но в этом процессе родилось понимание как общеметодических принципов так и преимуществ Борландовской ALM-концепции и пакета приложений для её реализации.

А поделиться пониманием? Надо же формировать качественный контент на сайте. Отличная задача. Хотя понимаю - время!

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

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

4776

Примеры / Re: Разработка SRS

« : 08 Ноября 2007, 09:48:14 »

Здесь есть спецификация http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=82
Её и Вы имели в виду?

А вообще, может Вы свою спецификацию опубликуете для анализа?

4777

Системный Анализ и Требования / Re: Управление требованиями

« : 07 Ноября 2007, 20:24:21 »

Интересный опыт. Gevorg

2. Без системы управления версиями реального мнеджмента требований - нет, есть только игрушка.
Версионность требования - раньше трассировки.

насколько я понимаю - это фиксация baseline? Если да например в RaQuest есть такой инструмент как сохранения таких baselines и версионный контроль.

3. Трассировка между требованиями - задача менее приоритетная,
чем трассировка от требования - к коду и тест-кейсу, которые это требование закрывают и проверяют,
и к проектным задачам, имеющим какое-то отношение к требованию.

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

6. Те же знающие люди рассказывали легенды про решение аналогичной мощности на базе интеграции СабВершин-Джира-Телелоджик Дорз.
Но доработки по обеспечению этой интеграции обошлись компании в хорошую копеечку.

Да цена на ДООРС неслабая. Но как инструмент - действительно можная вещь. особенно в интеграции с System Architectи другой линейки от Telelogic. Но цены....

4778

Сообщество Аналитиков / Re: Проект - "Статьи по ИТ анализу от студентов"

« : 07 Ноября 2007, 18:23:41 »

Имитационное моделирование требований
free BPMS как средство анализа требований

4779

Системный Анализ и Требования / Re: Управление требованиями

« : 06 Ноября 2007, 18:52:09 »

Вот только не надо меня своей бандой пугать.

Да Лиффенгуэлл вроде не из банды. Он вроде сам по себе, хотя и о том же...

прецеденты (не люблю я это слово)

Мне тоже не совсем нравится. Просто слово компактнее варианта использования

Зато нашёл вот такую диаграмму в концептуальном документе. Просто для иллюстрации. Интересно, если использовать только UML, какая диаграмма здесь должна быть и как она выглядела бы?
[skip] тут диаграмма смотри в предыдущем посте [/skip]

Диаграмму такую сделать наверное возможно. Она как я понял отражает некий объектный поток наложенный на красивую картинку размещения. В принципе такие картинки UML-CASE позволяют сделать например с использованием activity diagram или communication diagram

4780

Нововведения / Re: Процесс обратной семантической трассировки

« : 06 Ноября 2007, 18:29:15 »

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

Да я и сам не прочь убедиться 

Единственно, что цепляет. Так вот UML, IDEF и прочие штучки, даже самое ООП, не везде вообщем-то приживается, порой просто отторгается, не принимается.

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

Пример из жизни. В начале года на предмете Web-технологии возглашаю:

"Милостливые студенты! Мы будем с вами изучать PHP. Мы будем изучать его в стиле ООП. За ООП разработку на языке РНР - бонус."

Есть достаточно богатый разработанный пример для ООП - целый струмент с фронтэндом, админкой. На нем построен курс практики. Сначал все скурпулезно объясняется почему так, а как иначе. Предлагается усе повторить, а затем добавить свои фичи (задания отображаются синеньким цветом).

Для проверки знаний устраиваю контрольные. Алгоритмы простенькие. Задачки беру из методички 1 курса по паскалю. Естественно прошу реализовать на РНР, и не просто реализовать а постараться показать свою профпригодность. Куда-там! сплошной линейный код с кучей условий и циклов, в лучшем случае кто-то сруппирует это по функциям и то совершенно не корректно: каждой функции свое действие. Про использование объектов - вообще молчу. Хотя мой выстраданный пример - бери и пользуйся. Сложно мыслить объектно!

Т.е. для перехода на что-то новое должна быть какая-то нетривиальная проблема, которая просто заставит потратить силы на изменение.

Конечно есть еще волшебное слово пиар. Возможно UML - это пиар? И все что с ним связано? Может нужно чтобы прошло лет 10-20, чтобы UML воспринимался так же как обычные блок-схемы?

4781

Системный Анализ и Требования / Re: Управление требованиями

« : 06 Ноября 2007, 16:27:13 »

Спасибо за развернутый ответ и подробные комментарии.

Собственная разработка - учёт требований объединён с учётом проектов, запросов (багов), тестов и текущих задач. Полной интеграции с разработкой и тестированием пока нет. Каждый раз, когда нужно использовать требования (разработать план тестирования, план работ, собрать документ для обсуждения с заказчиками и т. п.), это нужно делать "вручную". То есть открывать трекер, выбирать проект и читать все требования подряд.

Нечто подобное используется на моей второй работе. Система называется "управление поручениями". По сути очень похоже на Вашу.

Никак не обеспечивается, и необходимость в этом пока не обнаруживалась.

А  в чем нет необходимости

в ведении требований по прецедентам? (тут я понял Вы прецеденты используете мало или вообще не используете. Это может быть вполне обусловлено решаемыми задачами. По крайней мере Лифеннгуэлл пишет об этом достаточно подробно).

или и в ведении списков свойств системы? т.е. вы никак не фиксируете требования?

Даже слов таких не знаю. То есть слова знаю, но применительно к разработке программ, а не формулировке требований.

Тут имелось в виду сам способ разработки. сначал требования кровь из носу, потом проект и реализация. Либо все в перемежку по спирале?

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

Ну нормальной гибкий подход А если решение удачное, репозиторий не ведёте?

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

А например?

4782

Обучение / Re: Новая книга - UML 2 и Унифицированный процесс.

« : 06 Ноября 2007, 16:14:19 »

Никто не листал??

Я полистал доступную главу. Книга конкретная. Диаграммы деятельности описаны неплохо, елси не очень хорошо. Эта фишка про сети петри- однако... А пример параметризированного процесса производства - отличный бизнес-анализ.

4783

Нововведения / Re: Процесс обратной семантической трассировки

« : 06 Ноября 2007, 16:03:44 »

УжОс. Первый вопрос, который приходит в голову - а каковы критерии "качества дизайна"?

Язык моделирования, как мне представляется, это РАСШИРЕНИЕ естественного языка, а не альтернатива ему. Не преставляю реальных задач, которые могут быть решены таким методом.

Гриша, успокойся. Не надо так нервничать, говорят нервные клетки не восстанавливаются или очень медленно. Вдохни-выдохни (повторить 10 раз). Лучше? Ну славу Богу.

Новое всегда так волнительно и главное так пугает....

Ну, а если всерьез. Хотелось привлечь внимание к теме. Люди уже 6 лет этим занимаются и утверждают - эффект есть! Почему бы и не проанализировать, не попробывать в конце концов

4784

Нововведения / Re: Процесс обратной семантической трассировки

« : 06 Ноября 2007, 15:06:18 »

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

Саша, не нужно пытаться все решить сразу. Гибкая технология и говорит, что это если и возможно, то стоит больших денег и многого времени.

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

Если же деалть это каскадно - тут ничего имхо не поможет, вернее совершенно иные средства, ресурсы и задачи. Однако даже критические системы типа атомных лодок Трайдент - проектировались итерационно. И ничего плавают

4785

Нововведения / Re: Процесс обратной семантической трассировки

« : 06 Ноября 2007, 14:02:09 »

всё равно стОит таким заниматься, чтобы уменьшить эту злобную "наибольшую потерю".

Очень интересно. Если у Вас есть такой хороший практический опыт, может быть Вы немного подробнее опишите  с приведением примеров? Мы постараемся развить идею и практику. В частности вот уже идет конкурс UML-сказок. Правда там не все так просто получается...