Перейти к содержимому

Публикации byur

7 публикаций создано byur (учитываются публикации только с 29 марта 2023)


#26496 Управление требованиями

Отправлено автор: byur 25 марта 2006 - 17:53 в Управление тестированием

А исходный вопрос все-таки о преимуществах тулов перед текстовыми процессами и электронными таблицами ... так причем тут доска с фломастерами ... ???

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


мммм.... к тому, что цель - ясный и эффективный процесс ведущий у выпуску качественного программного продукта продукта within given time and budget, а не использование конкретного тула?

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


Эта цель озвучена лично вами, а не автором вопроса, не так ли? ... Исходный вопрос был СФОРМУЛИРОВАН иначе. Повторюсь, что в БОЛЬШИНСТВЕ проектов, которые делаются на заказ, особенно госструктурами, одной доской с фломастерами не обойтись ... При создании shareware, или ПО типа "Печать платежного поручения" -- вполне может быть, что разработчики используют доску с фломастером. Кажому проекту -- своя методология (с) А. Cockburn

P.S. Попробуйте в Сбербанке или в ВТБ сделать проект без напасания ТЗ ... или приложите фотографии с доски в ТЗ ... :-).



#26491 Управление требованиями

Отправлено автор: byur 24 марта 2006 - 15:55 в Управление тестированием

Если так ставить вопрос, то управление.

Рассмотрим возможные варианты решений.
1. Специализированные средства. (Сферические, в вакууме).
2. Универсальные средства.

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

Я бы не стал выкидывать нетрадиционные средства. В ряде проектов они эффективней универсальных и специализированных средств. В разы.

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


А в большом ряде проектов по разработке систем автоматизации бизнеса у заказчика нужно подписать документацию требований к ПО. А если госконтора -- то еще и ТЗ по ГОСТ 34 выложи ... в этих случаях, к сожалению фотографии с флипчарта не приложешь к ТЗ.

А исходный вопрос все-таки о преимуществах тулов перед текстовыми процессами и электронными таблицами ... так причем тут доска с фломастерами ... ???



#26490 Управление требованиями

Отправлено автор: byur 24 марта 2006 - 15:47 в Управление тестированием

2byur. Эта ветка не предназначена для рекламы продуктов конкретной фирмы.

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


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

Или я где-то соврал?



#26393 Тул для рисков

Отправлено автор: byur 23 марта 2006 - 08:08 в Инструменты управления тестированием ПО

Сдаётся мне, подобный велосипед уже должен быть изобретен.
А именно, некоторая "база знаний", где можно хранить список рисков (включая ранее встреченные) с соответствующими properties, вести количественную статистику, допускать discussion по ним в свободной форме и прочее прочее.

Что скажет общественность?

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


Можно вести список рисков, как для конкретного проекта, так и для множества проектов (с трассировками на требования в конкретном проекте) и с включением в конкретный проект, рисков выделенных ранее и на др. проектах в инструментарии для управления требованиями. В частности, Borland CaliberRM это позволяет делать достаточно просто. Т.к. имеет возможность определения items собственного типа и добавлять к ним пользовательские атрибуты. Обладает возможностью трассировки м/у различнами типами сущностей в нутри проекта, так и кросспроектной. Плюс к этому развитые средства отчетности и экспорта (в т.ч. в БД Access наприемер) и импорта из тех же документов Word. И при необходимости анализа -- вполь до использования Business Objects.



#26191 Управление требованиями

Отправлено автор: byur 16 марта 2006 - 12:38 в Управление тестированием

про Калибер
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.

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


Q: With our version of CaliberRM it seems not to be possible to type a capital "Y" ??? ...We are using CaliberRM 2005 Release 2.

A1 (someone from borland): Yea, this is a very embarrassing defect that made it into the 2005 R2 release. Please contact support for the fix.

A2: This is not the only regression defect in R2. Anyone upgrading to this version should check it carefully to make sure their favorite features still work properly.

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


А вы до сих пор этот патч не поставили? У меня так стоит уже. Действительно можно получить его обратившись в техподдержку, при условии легальности используемой вами версии ... :-)



#26190 Управление требованиями

Отправлено автор: byur 16 марта 2006 - 12:35 в Управление тестированием

про Калибер
-1
Задумка неплохая (точнее, такая же как и все остальные). Но реализация...
Постоянно какие-то ошибки, какие-то проблемы.. ужас. Пользовался совсем не кракнутой версий, а скаченным с их сайт триалом.

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


Какие именно ошибки возникали, и какая версия можно узнать??? А то так вообще без конретики, как-то непонятно ... ошибки они же везде есть ... даже в создаваемом вами ПО :-).



#26058 Управление требованиями

Отправлено автор: byur 13 марта 2006 - 12:50 в Управление тестированием

И сравнить с использованием универсальных инструментов (Word, Excel, Notepad, MS Paint), допуская однако, что и в этих тулах управление требованиями можно вести грамотно, т.е. traceability, consistency и всё прочее будет присутствовать.

За счет чего, по вашему, (и сколько) можно сэкономить от использования RM tool?
Например, методом перебора (включая или отключая различные реквайрменты) оценивать суммарное время разработки - попадаем в сроки или нет
Или, автоматически генерировать драфт mpp (MS Project), с назначениями и сроками.
Или, например, избавиться от переписки со стейкхолдерами по почте.

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


Хм ... я конечно видел примеры расчетов ROI от использования инструментальных средств и в частности для разработки и управления требованиями, но -- там очень много project specific параметров и условностей. В частности, учитываются инвестеционная сторона -- сумма, потраченная на закупку лицензий и тренинги, Rework Cost Estimates и в частности средние величины стоимости переделок системы, связанные с требованиями. Размер проекта (в частности в LOC), затраты на проект и т.п. Вообще -- оценка достаточно условная получается. Более простой путь дать качественные оценки преимуществ использования инструментальных средств (могу говорить в данном случае о Borland CaliberRM), перед обычными офисными пакетами:

1. Многопользовательская работа над документом -- с файлом Word проблематично работать одновременно нескольким пользователям.
2. Контроль версий КАЖДОГО ТРЕБОВАНИЯ в отдельности (а не всего документа), с возможностью последующего проведения baselines с гибким включением именно конкретных ВЕРСИЙ (ревизий) требований. Гарантия что все участники имют самую свежую информацию.
3. Возможность отслеживать обсуждения требований прямо в инструментарии а не выискивать в многочисленных email (особенно если поставить web клиента или прсто клиентскую часть CaliberRM заказчику) -- тем самым максимально вовлекая его в разработку ПО -- что рекомендуют agile практики.
4. Возможность утверждения baslines путем электронной подписи, которую просто может поставить назначенные ответственные лица. Как минимум для неформального утверждения (review), но можно и с заказчиком -- если условия позволяют.
5. Возможность быстро управлять трассировкой и автоматически получать suspect traces ... ("чтоб тебе всю жизнь матрицы трассировки вручную в Excel поддерживать, и для больших проектов!" -- профессиональное проклятье для системного аналитика :aggressive: ) + возможность видеть ВСЕ обозначенные связи конкретного требования в виде графической диаграммы (помимо матрицы трассировки).
6. Говоря о трассировке -- возможность трассировать к другим докуметам и файлам вообще, в т.ч. находящимся под конфигуправлением. И возможность трассировки к объектам StarTeam 2005 (в т.ч. к change requests, включая defects). Более шире -- на модели и тестовые сценарии (возможны вариации) и в добавок на программный код (например, в том же используя Delphi 2006)!
7. Контроль доступа -- только санкционированый доступ и гибкая настройка кто что может видеть/создавать/изменять ... удобно ли это реализовывать при работе с фоисными пакетами?
8. Возможность оповещения по e-mail об изменнии в т.ч. только в интересных лично вам, требований.
9. Для каждого требования можно определить множество атрибутов, включая ответственных лиц, оценку сложности реализации данного требования, вероятность изменения в будущем ... и т.д.
10. В конечном итоге -- возможность легкого импорта в репозитарий CaliberRM требований из тех же документов Word ... и возможность генерации по шаблонам любых документов профкессионального качества (включая таблицы, рисунки), которые вам потребуются используя Document Factory, в т.ч. ТЗ, SRS, ... :-)

Говоря о генерации задач в терминах упрравления проектами, то они как правило базируются на требованиях -- но не всегда (зависит от процесса) требование = task. Чаще, задания на разработку нарезаются уже в средствах конфигуправления, на основе change requests соответствующего типа ... и трассируются на требования.