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

×


Управление требованиями(Прочитано 163731 раз)
Re: Управление требованиями Ответ #120 : 15 Ноября 2007, 11:24:42
Даже если у коллег нет RaQuest'а, тебе не зачем фиксировать все в Excel, ведь raQuest умеет делать экспорт в эксель. И импорт из csv. Заодно и проверим, хорошо ли он это умеет делать. Так что не надо мучицца ;-)
Солнышко, я и делал экспорт в Эксель и совершенно не мучился :)



Re: Управление требованиями Ответ #121 : 15 Ноября 2007, 11:30:59
Солнышко, я и делал экспорт в Эксель и совершенно не мучился :)
(Ковыряя носком туфельки паркет) - ну я так, на всякий случай, ибо мало ли чего...



Re: Управление требованиями Ответ #122 : 15 Ноября 2007, 11:50:54
Вопросы по требованиям:
 1. - 9.
RM(Gevorg) to JRM(Galogen):
у нас не более 2-х десятков требований,
по некоторым из них есть
- вопросы-ответы (т.е. внутреннее обсуждение между исполнителями),
- есть дополнительные разъяснения от Заказчика,
- есть  уточнения формулировок и Заключения от Аналитика-Консультанта(Greesha)
По-секрету от Заказчика и коллег по разработке честно признаЮсь Вам,
что я уже НЕ в состоянии это всё держать под контролем.

Что там РаКвест? Вы можете в ём как-то форумное обсуждение разместить и оттрассировать пОсты и требования?



Re: Управление требованиями Ответ #123 : 15 Ноября 2007, 12:10:24
Gevorg(во всех ролях на форуме)  To ALL участников  обсуждения и простых читателей:
заранее прошу прощения за возможные задержки с ответами в теме.

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

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





Re: Управление требованиями Ответ #124 : 15 Ноября 2007, 12:53:49
RM(Gevorg) to \
                       \JRM(Galogen):
По-секрету от Заказчика и коллег по разработке честно признаЮсь Вам,
что я уже НЕ в состоянии это всё держать под контролем.

Что там РаКвест? Вы можете в ём как-то форумное обсуждение разместить и оттрассировать пОсты и требования?
Gevorg(в роли ПМ проекта по сбору метод-материала для студенотов) to
 Galogen(в роли учредителя проекта):

вот ещё пример студентам:

ошибка в менеджменте требований:
RM(Gevorg) НЕ замечает общую КОНЦЕПТУАЛЬНУЮ проблему,
 пытается подменить её частной задачей трассировки и решить её с помощью РаКвест.

А проблема в том, что RM(Gevorg) до сих пор ещё не вооружён КОНЦЕПТУАЛЬНОЙ_МОДЕЛЬЮ и регламентом процесса по управлению требованиями.
Он не просто не в состоянии "разложить по полочкам" очень быстро накопившийся материал,
у него нет САМИХ полочек, у него даже нет ещё отчётливого понимания, какими они должны быть.

Отсюда и робкий вопрос подчинённому вместо уверенного отдавания распоряжения,
отсюда и судорожные попытки "закрыть дыру" своими средствами.

Правильные действия в этом случае - идти "наверх",
не к подчинённому, а руководству:

                      /ProcessRequirementBoss(Galogen):
RM(Gevorg) to /

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

В работе над требованиями полный произвол и неопределённость:
- кто за что отвечает,
- кто что и как делает,
- что и в каком виде подаётся в качестве исходного материала, что является результатом и как его оформлять на каждом из шагов?

Срочно нужно всё упорядочивать:
- рисовать диаграммы моделей процесса управления требованиями в нашем случае,
- писать по ним инструкции и регламент и
- ставить этот процесс на рельсы.

Иначе - утонем в, на самом деле, умных дебатах о "физической сути" каждого из требований.
« Последнее редактирование: 15 Ноября 2007, 13:06:19 от Gevorg »



Re: Управление требованиями Ответ #125 : 15 Ноября 2007, 13:47:56
Да не утонем. Надо сначала парой абзацев описать назначение разрабатываемой системы (к вопросу о целеполагании), а потом уже приводить примеры требований. Иначе студенты попытаются заполнить пробелы в понимании самостоятельно (те, кто пытается думать, конечно) и насинтезируют заказчику таких потребностей...

А то я тут ещё один вариант скретч-карт вспомнил, не подходящий под данее раньше определение. :) Есть такие карты, которые выдаются клиенту бесплатно, и содержат при этом не один, а несколько десятков скретч-кодов (например, для совершения удалённо операций с банковским счётом). Имеем ещё один вариант системы, удовлетворяющий перечисленным требованиям, но совершенно не похожий на все остальные.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Управление требованиями Ответ #126 : 15 Ноября 2007, 15:48:12
Да не утонем.
если проект такой, что не утонем
- то и управление требованиями в том моём понимании, каким я хотел поделиться, не нужно,
только лишние ресурсы у Разработчика  съест


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

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

а greesha в соответствии со своими законными обязанностями на работе - тут же на них набрасывается и "приговаривает к расстрелу"

вот и сейчас:
ситуация с отсутствием вижина - явно неправильная для проекта по разработке ПО,
а для нашего с Galogen-ом - так законный пример, который нужно далее развить:
вот начальна НЕправильная ситуация, а вот - как её исправлять и что должно получиться,
к вопросу о целеполагании
для greesha - главная цель: построить кондиционные требования,
а для меня - смоделировать проблему при работе с требованием, и показать, как она решается или вообще НЕ возникает, если правильно построить менеджмент.




Re: Управление требованиями Ответ #127 : 15 Ноября 2007, 16:01:55
кажется, я начинаю понимать сущность наших разногласий с greesha:

ситуация с отсутствием вижина - явно неправильная для проекта по разработке ПО,
а для нашего с Galogen-ом - так законный пример, который нужно далее развить:

Может, причина наших разногласий в том, что мы по-разному поняли Концепцию проекта "Практикум по управлению требованиями"? ;)

Тогда обращаемся к первоисточнику:
http://www.uml2.ru/forum/index.php?topic=487.msg5535#msg5535
и пытаемся уточнить потребности Заказчика (в роли которого в данном случае выступает Galogen).
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Управление требованиями Ответ #128 : 15 Ноября 2007, 16:11:19
А то я тут ещё один вариант скретч-карт вспомнил, не подходящий под данее раньше определение. :)
я предлагаю это зафиксировать в качестве варианта, как второе предположение(версия) Эксперта по требованим относительно термина Срэтч-Карта.
а в плане учебно-показательном ПОКА принять третий, совершенно неожиданный, но облегчающий всем жизнь вариант:

Заказчик, с его бизнесом, на деле оказался примитивным торгашом:

Скрэтч-карты для него примитивный лист пластика, имеющий свою крупно-оптовую и мелко-оптовую цену.

Которые он получает в столице от очень толстого предОставителя услуг крупным оптом и перепродаёт затем мелким оптом  приезжим торгашам из провинциальных городов.

И вот, на этих прОцентах, да на больших оборотах он и живёт.



Re: Управление требованиями Ответ #129 : 15 Ноября 2007, 16:22:09
Может, причина наших разногласий в том, что мы по-разному поняли Концепцию проекта "Практикум по управлению требованиями"? ;)

Тогда обращаемся к первоисточнику:
http://www.uml2.ru/forum/index.php?topic=487.msg5535#msg5535
и пытаемся уточнить потребности Заказчика (в роли которого в данном случае выступает Galogen).
а вот здесь у меня - никаких разногласий с greesha:
это мой прокол, как ПМ-а, который подрядился для Galogen-а проект выполнить :-)
судя из контекста переписки на форуме, мне уже удалось склонить его к работе в соответствии со своим, нигде не задокументированным вижином, а изначальные его запросы так и остались в качестве единственного документа...

Общий вывод: подход от целеполагания - рулёз!

Вывод мне как ПМ - наёмнику у Galogen-а:
Срочно бросать всё - и докумментировать-утверждать с ним актуальную версию вижина нашего проекта и продукта!



Re: Управление требованиями Ответ #130 : 15 Ноября 2007, 17:00:10
Братцы. Сорри. Я был вне дискуссии. Проходил медосмотр текущий.

Так же в скором времени должен отбыть.

Прочитал, уяснил, расстерялся.

Попытка №2. Постановка задачи.

1. Сформировать программу "Практикума управления требованиями" для студентов специальности 230201 "Информационные системы и технологии" на базе Ивановского государственного химико-технологического университета в рамках летней учебной практики студентов 3 курса. Ориентировочное количество часов: 30 по 6 часов в день. Курсы долны быть рассчитаны на 1 неделю.
Предусловие: студенты должны знать теоретические основы работы с требованиями, иметь навыки работы с инструментарием RaQuest и Enterprise Architect.
 
2. Отработать принципы, регламент и порядок работы по управлению требованиями по предложенной Gevorg программе с возможным использованием RaQuest

3. Написать статью (или цикл статей) по управлению требованиями в соавторстве 3 G. Разместить публикацию на сайте www.uml2.ru, в популярных IT-журналах.

Для реализации всех выше перечисленных целей необходимо проработать пример, сформировать референтный процесс (если получится).

Задачи:
1. определится с терминологий требований и уточнить что команда 3 G и присоединившиеся понимают под БТ, ПТ.
2. определить признаки бизнес-требований и пользовательских требований для их однозначной интерпретации
3. уяснить роль и обязанности каждого из участников

anything else?

Прикладываю файл Raquest. две части архива - в силу ограничений вложения
« Последнее редактирование: 15 Ноября 2007, 17:03:58 от Galogen »



Re: Управление требованиями Ответ #131 : 15 Ноября 2007, 17:38:20
Прикладываю файл Raquest. две части архива - в силу ограничений вложения
gevorg.part1.rar (878.91 Кб - загружено 0 раз.)
это шутка такая: тыцаю загрузить файл, а вываливаюсь в тему голосования за баннеры? :-)
« Последнее редактирование: 15 Ноября 2007, 17:42:02 от Gevorg »



Re: Управление требованиями Ответ #132 : 15 Ноября 2007, 19:43:22
gevorg.part1.rar (878.91 Кб - загружено 0 раз.)
это шутка такая: тыцаю загрузить файл, а вываливаюсь в тему голосования за баннеры? :-)

Gevorg, очень советую посмотреть как вы заходите на форум.
Рекомендованнный вход.

1. явно выйти с форума или сайта, обнулить кукис.
2.  явно удалить кукис (см настройки браузера www.uml2.ru)
3. набрать в строке соединения
либо http://www.uml2.ru
авторизироваться в форме
кликнуть в верхнем меню на Форум
после перехода на форум - сохранить ссылку в закладках или если поьзуетесь оперой создать элемент быстрого доступа

либо http://www.uml2.ru/forum/
авторизироваться и сохранить закладку

Боюсь проблема получается из-за интеграции joomla и форума. Причем работа неустойчивая и ошибка не понятна, то все работет замечательно, то происходят какие-то нарушения в SSI включении.

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

У меня все работает безукоризненно
Попробуйте явные ссылки
1. http://www.uml2.ru/forum/index.php?action=dlattach;topic=487.0;attach=482
2. http://www.uml2.ru/forum/index.php?action=dlattach;topic=487.0;attach=483



Re: Управление требованиями Ответ #133 : 15 Ноября 2007, 21:29:59
Хочу все-таки довести классификацию до конца

1. Система должна обеспечивать учёт скрэтч-карт.
Системное требование. Фича системы. Возможно бизнес-требование

2. Система должна поддерживать интеграцию с Клиент-Банком.
Системное требование. Функциональное.

3. Необходимо использование БАР-кодов для номеров скретч-карт.
Больше похоже на бизнес-правило.

4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
Больше похоже на бизнес-правило.

5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
Бизнес-правило однозначно.

6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
Системное требование или даже программное требование

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

8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
Системное требование или даже программное требование с ограничением. Возможное бизнес-правило, т.е. то что должно выполняться не зависимо от реализации

9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.
Системное требование или даже программное требование с ограничением. Возможное бизнес-правило

10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
Фича, системное требование

11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
Системное требование коррелирующее с бизнес-правилом. Либо бизнес-правило

12. Необходима интеграция с внешними системами считывания бар-кодов.
Системное требования фича

13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.
Системно требование, фича, может программное требование

14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
Системное требование

15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.
Системное требование



Re: Управление требованиями Ответ #134 : 16 Ноября 2007, 11:37:03
3. Необходимо использование БАР-кодов для номеров скретч-карт.
Больше похоже на бизнес-правило.

4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
Больше похоже на бизнес-правило.

5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
Бизнес-правило однозначно.

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

Насколько мне известно, все более-менее массовые сканеры штрих-кодов поддерживают стандарт EAN.

Бизнес-правила это или технические ограничения - не могу сказать, так как в данном случае не владею терминологией.

« Последнее редактирование: 16 Ноября 2007, 11:38:52 от greesha »
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19