Системное мышление 2.0


3 мес. 4 нед. назад #51831 от Александр Филонов
[quote="Александр Запорожцев"
Но есть successful systems![/quote]

И где? :)

Ссылку в словаре можете привести?

Пожалуйста Войти , чтобы присоединиться к беседе.


3 мес. 4 нед. назад #51832 от Александр Запорожцев
Александр Филонов пишет:

[quote="Александр Запорожцев"
Но есть successful systems!


И где? :)

Ссылку в словаре можете привести?[/quote]
The definition of systems engineering has evolved over time. The current accepted definitions are found below:

(1) Interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution and to support that solution throughout its life. (ISO/IEC/IEEE 2010)

(2) An interdisciplinary approach and means to enable the realization of successful systems.

Пожалуйста Войти , чтобы присоединиться к беседе.


3 мес. 4 нед. назад - 3 мес. 4 нед. назад #51833 от Александр Филонов
Это укороченное определение. Полное в словаре
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


Раздуть мимолетом сказанное successful из этого контекста - это еще надо уметь!:)

Если эту красочную, не имеющую определения ремарку убрать из текста, практически ничего не изменится.

Пожалуйста Войти , чтобы присоединиться к беседе.


3 нед. 3 дн. назад #52737 от Георгий Лейбович
Давно собирался спросить, да всё забывал. А как согласуются или отбираются требования стейкхолдеров в СП 2.0? Какие критерии отбора и согласования кроме абстрактного "удовлетворения" требований. Для ограниченного проекта? А для развития компании? Только не ссылайтесь на СД-картинку, там нет критериев принятия решения.

Пожалуйста Войти , чтобы присоединиться к беседе.


3 нед. 3 дн. назад #52739 от Александр Запорожцев
Георгий Лейбович пишет:

Давно собирался спросить, да всё забывал. А как согласуются или отбираются требования стейкхолдеров в СП 2.0? Какие критерии отбора и согласования кроме абстрактного "удовлетворения" требований. Для ограниченного проекта? А для развития компании? Только не ссылайтесь на СД-картинку, там нет критериев принятия решения.

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

Пожалуйста Войти , чтобы присоединиться к беседе.


3 нед. 3 дн. назад #52747 от Георгий Лейбович
Александр Запорожцев пишет:

Георгий Лейбович пишет:

Давно собирался спросить, да всё забывал. А как согласуются или отбираются требования стейкхолдеров в СП 2.0? Какие критерии отбора и согласования кроме абстрактного "удовлетворения" требований. Для ограниченного проекта? А для развития компании? Только не ссылайтесь на СД-картинку, там нет критериев принятия решения.

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

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

Пожалуйста Войти , чтобы присоединиться к беседе.


3 нед. 3 дн. назад #52748 от Александр Запорожцев
Георгий Лейбович пишет:

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

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

Пожалуйста Войти , чтобы присоединиться к беседе.


3 нед. 2 дн. назад #52750 от Георгий Лейбович
Александр Запорожцев пишет:

По большому счету к ответу на вопрос не готов. Это отдельная дисциплина "Инженерия требований" там много чего есть. Согласование требований - это частный вопрос и, на сколько я понял, не самый главный. (- выд. ГЛ) Одна из проблем формулируется так - "есть еще стейкхолдеры, требования которых мы не учли". Другая проблема - требование было, но его потеряли и не учли.

Мне странно это читать. С моей точки зрения, вопрос о том, как согласовывать требования стейкхолдеров - центральный вопрос. Бессмысленно собирать, выявлять и не терять требования, если нет чёткой методологии того, как с ними поступать. И что означает "согласование" для команды проекта или руководства компании. Чьи интересы доминирующие и по какому (каким) критерию? Есть ли матобеспечение?
Я понял, что Вы пока не знакомы с ответами на эти вопросы, но не относитесь к ним, как к частным. Это базовый вопрос. Без ответа на них вся остальная деятельность не имеет смысла.

Пожалуйста Войти , чтобы присоединиться к беседе.


3 нед. 2 дн. назад #52754 от Александр Запорожцев
Георгий Лейбович пишет:

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

В стандарте isi 15288 Процессы жизненного цикла в разделе Технические процессы установлено два процесса работы с требованиями :Процесс определения требований заинтересованных сторон,
Процесс анализа требований и Проектирование архитектуры
В Процессе определения требований заинтересованных сторон проект, согласуясь с соответствующей политикой и процедурами организации, должен осуществить
следующие виды деятельности.
a) Идентифицировать отдельные заинтересованные стороны или классы заинтересованных сторон, которые имеют правомерный интерес к системе в ходе всего жизненного цикла.
b) Выявить требования заинтересованных сторон.
c) Определить ограничения на системное решение, которые являются неизбежными последствиями существующих соглашений, управленческих и технических решений.
d) Определить характерный набор последовательностей видов деятельности, чтобы идентифицировать все требуемые услуги, которые соответствуют ожидаемым эксплуатационным и поддерживающим сценариям и средам.
e) Определить взаимодействие между пользователями и системой.
f) Определить требования, связанные с безвредностью для здоровья, безопасностью, защитой, средой и другие требования заинтересованных сторон, а также функции, которые касаются критичных качеств.
g) Проанализировать полный набор выявленных требований.
П р и м е ч а н и е — Анализ включает в себя выявление и расположение по
приоритетам конфликтующих, недостающих, неполных, неоднозначных, противоречивых,
неуместных или непроверяемых требований.
h) Решить проблемы, связанные с требованиями.
П р и м е ч а н и е — Это включает в себя требования, которые не могут быть реализованы, или достижение которых нецелесообразно.
i) Возвратить проанализированные требования соответствующим заинтересованным сторонам, чтобы гарантировать, что потребности и ожидания были адекватно зафиксированы и выражены.
П р и м е ч а н и е — Объясните и получите соглашение на предложения о том, как разрешить конфликтующие, непрактичные и нереализуемые требования заинтересованной стороны.
j) Совместно с заинтересованными сторонами установить, что их требования выражены правильно.
П р и м е ч а н и е — Это включает в себя подтверждение того, что требования заинтересованных сторон являются понятными для создателей, и что разрешение конфликта
в требованиях не разрушило или не поставило под угрозу намерения заинтересованных сторон.

k) Записать требования заинтересованных сторон в форме, подходящей для управления требованиями в ходе жизненного цикла и по его завершении.
Возможно, выделенные цветом пункты, соответствуют вашему вопросу о том, как рекомендуется работать с требованиями

Пожалуйста Войти , чтобы присоединиться к беседе.

Работает на Kunena форум