Системное мышление 2.0
- Александр Филонов
- Не в сети
- Живу я здесь
- Сообщений: 6616
- Спасибо получено: 714
Но есть successful systems![/quote]
И где?
Ссылку в словаре можете привести?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5576
- Спасибо получено: 594
Александр Филонов пишет: [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.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Филонов
- Не в сети
- Живу я здесь
- Сообщений: 6616
- Спасибо получено: 714
(2) An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:
Operations
Performancе
Test
Manufacturing
Cost & Schedule
Training & Support
Disposal
Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (INCOSE 2012)
Раздуть мимолетом сказанное successful из этого контекста - это еще надо уметь!
Если эту красочную, не имеющую определения ремарку убрать из текста, практически ничего не изменится.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Георгий Лейбович
- Не в сети
- Завсегдатай
- Сообщений: 1337
- Спасибо получено: 558
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5576
- Спасибо получено: 594
Требования не выбираются, а выявляются. Сначала выявляются сами стейкхолдеры, а потом выявляются их требования, причем процесс выявления требований идет на всем протяжении проекта. принято моделировать требования с использованием диаграммы use case языка моделирования UML. Далее идет этап согласования требований с тем, чтобы добиться общего понимания архитектуры системы.Георгий Лейбович пишет: Давно собирался спросить, да всё забывал. А как согласуются или отбираются требования стейкхолдеров в СП 2.0? Какие критерии отбора и согласования кроме абстрактного "удовлетворения" требований. Для ограниченного проекта? А для развития компании? Только не ссылайтесь на СД-картинку, там нет критериев принятия решения.
В теме требований для меня очень много непонятного - пытаюсь разобраться.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Георгий Лейбович
- Не в сети
- Завсегдатай
- Сообщений: 1337
- Спасибо получено: 558
Полагаю, ВЫ не поняли вопрос или не готовы к нему. Можно выявлять, но потом возникает проблема согласования. Что является основой для согласования, какие критерии? Мир-дружба или что-то более осмысленное, измеримое?Александр Запорожцев пишет:
Требования не выбираются, а выявляются. Сначала выявляются сами стейкхолдеры, а потом выявляются их требования, причем процесс выявления требований идет на всем протяжении проекта. принято моделировать требования с использованием диаграммы use case языка моделирования UML. Далее идет этап согласования требований с тем, чтобы добиться общего понимания архитектуры системы.Георгий Лейбович пишет: Давно собирался спросить, да всё забывал. А как согласуются или отбираются требования стейкхолдеров в СП 2.0? Какие критерии отбора и согласования кроме абстрактного "удовлетворения" требований. Для ограниченного проекта? А для развития компании? Только не ссылайтесь на СД-картинку, там нет критериев принятия решения.
В теме требований для меня очень много непонятного - пытаюсь разобраться.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5576
- Спасибо получено: 594
По большому счету к ответу на вопрос не готов. Это отдельная дисциплина "Инженерия требований" там много чего есть. Согласование требований - это частный вопрос и, на сколько я понял, не самый главный. Одна из проблем формулируется так - "есть еще стейкхолдеры, требования которых мы не учли". Другая проблема - требование было, но его потеряли и не учли.Георгий Лейбович пишет: Полагаю, ВЫ не поняли вопрос или не готовы к нему. Можно выявлять, но потом возникает проблема согласования. Что является основой для согласования, какие критерии? Мир-дружба или что-то более осмысленное, измеримое?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Георгий Лейбович
- Не в сети
- Завсегдатай
- Сообщений: 1337
- Спасибо получено: 558
Мне странно это читать. С моей точки зрения, вопрос о том, как согласовывать требования стейкхолдеров - центральный вопрос. Бессмысленно собирать, выявлять и не терять требования, если нет чёткой методологии того, как с ними поступать. И что означает "согласование" для команды проекта или руководства компании. Чьи интересы доминирующие и по какому (каким) критерию? Есть ли матобеспечение?Александр Запорожцев пишет: По большому счету к ответу на вопрос не готов. Это отдельная дисциплина "Инженерия требований" там много чего есть. Согласование требований - это частный вопрос и, на сколько я понял, не самый главный. (- выд. ГЛ) Одна из проблем формулируется так - "есть еще стейкхолдеры, требования которых мы не учли". Другая проблема - требование было, но его потеряли и не учли.
Я понял, что Вы пока не знакомы с ответами на эти вопросы, но не относитесь к ним, как к частным. Это базовый вопрос. Без ответа на них вся остальная деятельность не имеет смысла.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5576
- Спасибо получено: 594
В стандарте isi 15288 Процессы жизненного цикла в разделе Технические процессы установлено два процесса работы с требованиями :Процесс определения требований заинтересованных сторон,Георгий Лейбович пишет: С моей точки зрения, вопрос о том, как согласовывать требования стейкхолдеров - центральный вопрос. Бессмысленно собирать, выявлять и не терять требования, если нет чёткой методологии того, как с ними поступать.
Процесс анализа требований и Проектирование архитектуры
В Процессе определения требований заинтересованных сторон проект, согласуясь с соответствующей политикой и процедурами организации, должен осуществить
следующие виды деятельности.
a) Идентифицировать отдельные заинтересованные стороны или классы заинтересованных сторон, которые имеют правомерный интерес к системе в ходе всего жизненного цикла.
b) Выявить требования заинтересованных сторон.
c) Определить ограничения на системное решение, которые являются неизбежными последствиями существующих соглашений, управленческих и технических решений.
d) Определить характерный набор последовательностей видов деятельности, чтобы идентифицировать все требуемые услуги, которые соответствуют ожидаемым эксплуатационным и поддерживающим сценариям и средам.
e) Определить взаимодействие между пользователями и системой.
f) Определить требования, связанные с безвредностью для здоровья, безопасностью, защитой, средой и другие требования заинтересованных сторон, а также функции, которые касаются критичных качеств.
g) Проанализировать полный набор выявленных требований.
П р и м е ч а н и е — Анализ включает в себя выявление и расположение по
приоритетам конфликтующих, недостающих, неполных, неоднозначных, противоречивых,
неуместных или непроверяемых требований.
h) Решить проблемы, связанные с требованиями.
П р и м е ч а н и е — Это включает в себя требования, которые не могут быть реализованы, или достижение которых нецелесообразно.
i) Возвратить проанализированные требования соответствующим заинтересованным сторонам, чтобы гарантировать, что потребности и ожидания были адекватно зафиксированы и выражены.
П р и м е ч а н и е — Объясните и получите соглашение на предложения о том, как разрешить конфликтующие, непрактичные и нереализуемые требования заинтересованной стороны.
j) Совместно с заинтересованными сторонами установить, что их требования выражены правильно.
П р и м е ч а н и е — Это включает в себя подтверждение того, что требования заинтересованных сторон являются понятными для создателей, и что разрешение конфликта
в требованиях не разрушило или не поставило под угрозу намерения заинтересованных сторон.
k) Записать требования заинтересованных сторон в форме, подходящей для управления требованиями в ходе жизненного цикла и по его завершении.
Возможно, выделенные цветом пункты, соответствуют вашему вопросу о том, как рекомендуется работать с требованиями
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5576
- Спасибо получено: 594
Данная схема иллюстрирует потенциальную возможность рассматривать требования стейкхолдеров в рамках общей функциональной модели деятельности. Понимание того, как процесс одного стейкхолдера связан с процессом другого етйкхолдера, позволяет разработать имитационную модель системной динамики их совместной деятельности, понять поведение системы, рассмотреть возможные варианты повышения эффективности ее работы.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.