Развитие современных индустриальных технологий упрощает для человека исполнение производственных процессов. Входные барьеры в новейшее производство понижаются и становятся доступными для всё более широкого круга игроков. Наоборот, придумывание, проектирование и быстрое прототипирование новых вещей и технических систем, других рукотворных объектов, организация и управление подобными процессами и проектами требует все более развитых компетенций. И именно сюда сегодня смещаются центры получения прибыли и инкубаторы деловых карьер мировой экономики. Сами процессы придумывания инновационных идей и создания новых продуктов тоже претерпевают развитие и становятся объектом применения системных метаконструкторов. Основы современного системного проектирования представлены в этом курсе. Курс реализует функцию навигатора для тех, кто ориентирован на деловую карьеру в умных высокотехнологичных сферах экономики, включен в программу Системы инжиниринга, менеджмента и управления 2.0 (лэндинг Программы 2.0: http://artofsystems.ru/).
Формирование требований к системе
Loading...
来自 Moscow Institute of Physics and Technology 的课程
Введение в системное проектирование
70 个评分
从本节课中
РАЗРАБОТКА ТРЕБОВАНИЙ - ОСНОВА СИСТЕМНОГО ПРОЕКТИРОВАНИЯ
"Сказка о рыбаке и рыбке" как введение в проблематику "Управление требованиями", а также: типология требований; "хорошие", корректно составленные требования; требования как обязательный компонент системного проектирования; умение составлять требования как необходимая компетенция системного инженера.
与讲师见面
Романов Алексей АлександровичДоктор технических наук, профессор.
Кафедра радиотехнических космических систем
Кондратьев Вячеслав ВладимировичДоктор технических наук, профессор
Кафедра проблем управления, R&D ФРТК МФТИ
Перейдем теперь к рассмотрению требований к системе.
И начнем с того, что поймем,
а в чем же разница требований и исходных данных.
Требования представляют собой описание то,
что продукт обязан или должен делать.
То есть, иными словами,
это документированное ожидание результата реализации проекта.
Пример.
Системное программное обеспечение миссии должно
соответствовать открытой архитектуре системы.
Другой пример.
Средняя стоимость единицы продукции не должна превышать какой-то величины.
И, как мы уже сказали,
требования документируют ожидания заказчика,
а также разработчиков программы, функций и проекта.
Таким образом, требования включают характеристики,
стоимость, сроки и риски.
Как мы уже упоминали, исходные данные — это то начальное состояние,
от которого начинается проектирование системы.
Требования в конечном итоге могут обеспечить создание лучших характеристик,
но хуже, чем исходные данные, мы ничего создать не имеем права.
Вопрос ясного понимания требований не является праздным.
На двух данных рисунках представлены два аспекта.
С левой стороны показано, как поняли разные
участники проекта то, что им предстоит создать.
И здесь видно,
что последний рисуночек в правом нижнем углу левого
рисунка означает реальное пожелание заказчика.
А вот все то, что было во всех промежуточных состояниях — это то,
как это пожелание заказчика поняли разные участники проекта,
и что они предложили создать.
Правый рисунок — он показывает видение космической
системы с точки зрения непосредственных исполнителей составных элементов.
И если мы внимательно рассмотрим каждый из элементов,
мы увидим, что баллистики в первую очередь, на первый план,
поставили вопросы того, как космический аппарат выводится на орбиту,
оптики поставили вопросы создания оптических приборов,
навигаторы — навигационных систем, и так далее.
А наша цель — обеспечить через коммуникации и взаимопонимание то,
чтобы все мероприятия формирования требований привели к оптимальному,
взвешенному варианту создания системы.
Хочу проиллюстрировать
требования на очень понятном бытовом примере,
с которым каждый из нас сталкивается практически ежедневно.
Если вам вдруг поступил запрос из дома о том,
какие продукты вам нужно купить,
то это и является для вас сборов и формулированием необходимых требований,
что вам нужно купить: хлеб, сахар, масло, молоко и другие продукты.
Если же теперь выяснится,
что хлеб вам в первую очередь необходим белый,
а масло — растительное или сливочное,
и так далее, то это уже — документирование и
детализация предъявляемых требований.
Если вдруг вы вспомните, что кто-то
из предполагаемых участников
обеда имеет ограничения по каким-либо продуктам питания,
то вы можете принять решение, что именно этот продукт вы покупать не будете,
и это будет означать учет ограничивающих факторов.
И так по каждому из направлений.
И в конечном итоге, когда вы пришли домой, выложили все то,
что вы купили, и сопоставили с тем списком, который у вас был изначально,
то вот это и есть то,
как вы реализовали требования, предъявленные изначально.
Но если вдруг вы обнаружите, что вместо сметаны
вы купили только молоко,
то это означает, что вы не учли те изменения, которые при этом вносились.
Вот очень понятное бытовое объяснение того,
как разработчик реально работает с требованиями.
Кстати говоря, если вы будете помнить этот пример при разработке любой
сложной технической системы, это вам поможет
достаточно просто перейти от простого к сложному.
Итак, важность формулировки хороших требований.
К сожалению, очень часто возникает ситуация,
когда плохо определенные требования являются главной
причиной возникновения проблем при разработке проекта.
Ведь требования задают,
что должно быть сделано, насколько хорошо и при каких ограничениях.
И если это требование по какой-либо причине будет не совсем правильным,
то тогда ваш разработанный итоговый продукт тоже получится ущербным.
Из собственного опыта знаю, что это действительно поразительная вещь,
как много проектировщиков начинают решать конкретную проблему до того,
как они ее сами отчетливо поняли и поняли, в чем эта проблема состоит.
Именно поэтому требования,
наряду с соответствующими ограничениями и допущениями,
расчленяют решаемую проблему на составные части,
что в конечном итоге определяет успех проекта в целом.
Откуда же возникают требования к создаваемой системе?
В первую очередь, на самом высоком уровне из экспериментального опыта,
который базируется на заявляемых
потребностях заказчика и конечного пользователя.
Кроме того, эти требования определены целями и задачами создаваемой системы,
допущениями и ограничениями,
в которых мы находимся, и собственно концепцией функционирования,
заложенной в создании системы.
Анализ проекта и изучение трудозатрат по проекту
позволяет нам сформулировать основные параметры значимости,
в которых этот проект может быть оценен.
И, наконец, требования возникают
и из существующей системной иерархии проекта,
определяющей функции, обеспечиваемые системой и ее подсистемами для того,
чтобы она в конечном итоге была успешной.
Таким образом, разработка хороших
требований — это самый важный шаг системной разработки.
Мы уже обсудили, откуда они возникают, формулируются на
основании анализа архитектуры системы, разрабатываемой в проекте.
Требования разграничены масштабом проблем,
решаемом на основании имеющихся знаний.
Иерархия прослеживаемых требований гарантирует нам то,
что в рамках создается именно то, что требуется,
и нет никакой самодеятельности, возникшей инициативно.
Иерархия согласуемых требований обеспечивается
сбалансированным проектированием системы.
Требования в будущем определяются
основой для валидации и верификации характеристик проекта.
Вывод: если какие-либо
недостаточно прописаны или непроверяемы требования,
то такие требования должны быть исключены и вовсе
не рассматриваться, потому что это одна из важнейших
характеристик требования: требование должно быть проверяемо.
Если мы не можем его проверить,
то такое требование не является обязательным для исполнения.
