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

×


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

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


Сообщения - LDV

Страницы: « 1 2 3 4 5 »
31
"Создание неограниченного числа баз данных и быстрого переключения между ними"
это должно понравиться Админам - согласен ;)
но только если снять с них ответственность за поддержание этих баз, создаваемых пользователями.
А лучше - запретить пользователям создавать "неограниченное число баз данных" - как показывает практика потом все равно Админам разбираться - а они это не любят, проверено мною:)

32
... или планируется применять в нескольких проектах.
Во внутренних ТЗ обычно отражают детали, которые не нужны заказчику проекта ...
Это, имхо, 2 разных подхода
1 - наличие нескольких заказчиков на общий продукт, который имеет единое ядро - "внутреннее" ТЗ и функциональность, заточенную под конкретного заказчика
2  - детализация - это не "внутреннее" ТЗ, это всего лишь те детали, которые не понятны и не интересны заказчику, но необходимы для создания работоспособного решения. Это детализация требования верхнего уровня (ТЗ) до уровня конкретных спцификаций и архитекурных решений
Отличия в степени детализации: внешние документы описывают бизнес-требования, внутренние архитектуру.
это скорее детализация ТЗ, а не "внутреннее" ТЗ

все имхо

33
вот же каша в голове
менеджер должен управлять: бюджетом? - да! ресурсами? - да! рисками - всенепременно! но прибыль-то тут причем???
хотя согласен вцелом, но заострю внимание, что Вы забыли уточнить - менеджер ПРОЕКТА

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

34
вероятно, можно прочесть у Липаева - что-то рядом у него точно есть, но сформулировано ли именно четко в таком виде - не уверен. зато он очень близок к ГОСТам ранних серий ;)
Если нет желания мельчить функции, то можно их сформулировать на более высоком уровне "способности". Например, не способность ПО (или ПС - по ГОСТ ИСО 12207) ввода такой-то информации, а
способность ПО ввода информации. тогда такая функция будет использоваться в нескольких ВИ - придется делать трассировки.

35
самая хорошая мотивация - отсутствия мотвов заняться чем-то другим. например, эффективность тех же "шарашек" (http://ru.wikipedia.org/wiki/%D0%A8%D0%B0%D1%80%D0%B0%D1%88%D0%BA%D0%B0)

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

37
Ну иногда между прочтением нужно и пробовать, то что прочитал ;)
то есть читать надо то, что можно попробовать, так?
ведь не все, что прочел можно/нужно попробовать :)

38
Книги нужно читать и тайм-менеджементу и другие, но использовать нужно только то, что подходит тебе и приносит реальный результат.
а как узнать, что подходит тебе и приносит реальный результат?
а то читаешь-читаешь, читаешь-читаешь, а вдруг не то? ;)

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

40
вот кстати требования за пределами ИТ - http://n-t.ru/ri/as/7003.htm
а как пример управления изменяющимися требованиями - по мере стрельбы из орудий большого калибра из-за износа ствола калибр увеличивается и соответственно заряжаются снаряды более крупного калибра.

41
насколько мне известно как раз управлением требованиями с VS TFS 2010 cmcons не занимается

42
Подскажите ПО, в котором можно построить диаграмму бизнес-вариантов использования (кроме Rational Rose, VP, EA).
Cейчас в линейке Rational можно использовать 3 продкута для ДВИ, у каждого из которых есть еще свои дополнительные преимущества:
Requirements Composer - кроме ДВИ есть возможность рисовать бизнес-процессы
Software Architect - ну здесь основные преимущества скорее уже не в области анализа, а в реализации
System Architect - (бывший Тelelogic) - нотации можно модифицировать под себя - можете сделать нотацию для ДБВИ в дополнении к ДВИ ;)
конечно все 3 продукта расчитаны на совметное использование как минимум в команде с выходом на масштаб организации.
проще, наверное, начать с Requirements Composer
все можно скачать в полнофункциональном триале на сайте IBM

43
Данных нет. Это моё субъективное ощущение.
По моим ощущением лучшая автоматизация может быть только если рассматривать кол-во используемых средств автоматизации.

Цитировать
Говоря о "требованиях в IT", я имею в виду требования к самим информационным и прочим компьютерным системам.
Понятно, сейчас уже часто делят ИТ и информационные Системы примерно как ГОСТ 12207 и ГОСТ 34. Или как Rational и Telelogic :)

44
в IT управление требованиями на сегодня лучше автоматизировано.
откуда такие данные? и что понимаете под IT?
атомные станции и самолетостроение - это ИТ?

45
А какие именно методы и техники работы с ИТ требованиями можно перенести во вне ИТ жизнь
не, ну это ж = "а есть ли жизнь вне ИТ?"
не знаю как сейчас, но раньше была (вспоминаю динозавров)

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