Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 17
Текст из файла (страница 17)
стсс. 6.1. Система и ее еирузееиие Рис. б.З. Система, сесиюяжая из деус яедсистем Процесс декомпозиции (илн последовательного разбиения) производится до тех пор, пока специалист по системам не достигнет иумснмх результатов, что подтверждается конкретными количественными оценками, свойственными каждой области системной инженерии. Как правило. полученные после первого разбиения подсистемы подвергаются дальнейшей декомпозиции (рис. 65). Для наиболее сложных систем процесс продолжается достаточно долго, и в результате получается болыпое количество подсистем. (Говорят, что истребитель Р22, например, состоит из 152 подсистем.) Показателями того, что дело сделано и сделано "правильно", являются следующие критерии. ° Распределение и разбиение функций оптимизировано так, чтобы добиться достижения общей функциональности спстезсы с мпнимальнгемн затратами и максимальной гибкостью.
84 Часть 1. Анализ проблемы ° Каждая подсистема может быть определена, спроектирована и построена неболы шой или, в крайнем случае, средней командой. гзгс, 6.3, Подпизявна, амяаапзал яз де)я яедсисжея ° Каждая подсистема может быть изготовлена в рамках физических ограничений н технологий существующих производственных процессов. ° Каждую подсистему можно надежно протестировать, причем существует возможность подходящих установок и сопряжений, имитирующих интерфейсы с другими подсистемами. ° Соответствующее внимание уделено физической стороне (размеру, весу, размещению и распределению подсистем), которая также оптимизирована исходя из общесистемных соображений.
Размещение требований в системной инженерии Нисходящий процесс разработки требований распределяет функциональные возможности системы по подсистемам. Даже если предположить, что с помощью системной инженерии можно определить требования к системе, проблема управления требований все еще остается нерешенной. Что делать с полученными подсистемами? Какие требования должны быль предъявлены к пим) В некоторых слу ~аях процесс заключается в распределении требований системного уровня по подсистемам (" подсистема В будет выполнять алгоритм расчета скорости ветра и осуществлять непосредственное управление дисплеем лобового стекла"). Оислодяе1ий (фоиесс «азрабожки яфебоеаиий предназначен для того, чтобы гарантировать, что все системные требования выполняются некой определенной подсистемой или совокуп.
постыл взаимодействующих подсистем. Производные требования Иногда создается совершенно новый тип требований, предъявляемых к подсистемам— лрсеаюднве ефеймаииа Как правило, существует два класса производных требований. Глава 6. Инженерия систем, илпенсивно нспользулоняях программное... 86 1. Т(тебввания к надеисяммам- это требования, которые необходимо предъявить к самим подсистемам, но они не обязательно доставляют осязаемый результат конечному пользователю ("подсистема Л должна выполнять алгоритм, вычисляющий скорость ветраотноснтельно самолета"). 2. Требования к интффешам, которые могут возникнуть при взаилюдействии подсистем для достижения общего результата.
Эти подсистемы должны совместно ис. пользовать данные, мощность или некий алгоритм вычисления. В этих случаях создание подсистем приводит также к созданию инятерфйсав между ними (рис. б 4). Интерфейс изиду А а В Рис. б.4. Инимрфмм между двумя нвдеиетнемами Однако являются ли эти производные требования "настоящими"л Можно ли их трактовать как остальные требования) По всей видимости, они не соответствуют определекиям, данным в главе 2 (хотя они матус вполне соответствовать определениялт ограни. чений проектирования, которые будут даны далее). Важно понимать, что эти требования, хотя они и важны для успеха проекта, являются производными от процесса декомпозиции.
Альтернативная декомпозиция может привести к созданию других производных требований, так что эти требования не являются полноправными участниками процесса в том смысле, что не отражают требования, по. ступившие от заказчика. Но, с точки зрения поставщика подсистемы, оыи являются пол. яоправными, так как отражают требования, предъявляемые закаэчиком (в роли которого вдаыном случае выступает разработчик системы).
Магического ответа на все случаи жизни не существует. Как трактовать эти требования — зависит от роли команды разработчиков в проекте, декомпозиции системы и дру. гнх технологических факторов, Таким образом, важно знать, "как мы сюда попали", и трактовать требования соответственно обстоятельствам. Важно понилтать, что спецификация производных требований будет в конечном счете влиять на способность системы выполнять ее работу, а также на удобство эксплуатации и робастность системы. "Тихая" революция В постиндустриальном обществе "ум" прибора переместился из аппаратных компонентов в компоненты программного обеспечения.
Системная инженерия (системное проектирование) традиционно применялась преимущественно к физическим системам, таким как самолеты, энергогенераторы, потреб. ляющие энергию приборы и т.д. Однако за последние 20 лет (или около того) произошла "тихая революция" в инженерии сложных систем. Постепенно систелты и приборы в различных отраслях становились все более "умными". Все балывая часть необходимых функциональных возможностей стала размещаться в подсистемах программного обеспечения, а не в аппаратных компонентах.
Причина в том, что програлтлтное обеспечение более гибкое и многие аягоритлты измерения. учета, количественного анааиза и обнару. 86 Часть 1. Анализ проблемы жения гораздо проще (нли, по крайней мере, гораздо дешевле) реализовать в программном обеспечении, чем в аппаратных компонентах. Еще важнее то, что в этом случае их гораздо проще изменять. Таким образом, в постиндустриальном обществе внутренняя "разумность" прибора переместилась из компонентов аппаратуры, где она реализовывалась прежде наряду с электрическими, электронными, механическими системами и даже системами физической химии, в компоненты программного обеспечения, где она реализуется в программном обеспечении или программно-аппаратных средствах.
Столкновение поколений: седобородые встречаются с молодыми и самонадеянными На протяжении нескольких десятилетий специалисты по системному проектированию были одними из самых уважаемых в отрасли. Покрытые шрамамн битв и проверенные временем лшогие из них являлись специалистами в отдельных дисциплинах, таких как лзсханика илн электроника, и, кроме того, были одними из лучших учзивсрсалов команды.
Они были свидетелями величайших неудач н ~Дэ испытали множество триумфов. Теперь, став старше и мудрее, они в совершенстве знают некую прикладную область (радиотехнику, самолето. строение н т.п.), а также хорошо представляют себе различные техническис, экономические и политические стороны реализации. Но внезапно какие-то люди вторглись в их владения. Эти пришельцы — программисты илн, в лу пнем случае, специалисты по инженерии программного обеспечения, — были относительно неопытны в том, что касалось сложных систем, но они могли с помощью языка ассемблера заставить микропроцсссор звенеть. Кроме того, казалось, что они сделаны из др)того генетического материала или, по крайней мере, относятся к другому поколению, что создало дополнительные сложности в отрасли.
На нскоторос врез~я системным проектировщикам удалось закрепить за собой право на разбиение системы н размещение функций. Но во многих отраслях технологии программш>го обеспечения всс жс взяли верх, и над системным проектированием возобладала, но крайней мере частично, потребность в создании гиокого функционально полного программного обеспечения системы в целом.
Для этого перехода существовал ряд веских технических причин. Со временем стало очевидно следующее. ° Программное обеспеченно (а нс аппаратные компоненты) будет определять итоговые функциональные возможности системы. а также сс успех у конечного потребителя и на рынке. ° На программное обеспечение (а не на аппаратныс колшоненты) будет затрачена основная часть средств, выделенных на исследование и разработку системы.
° Именно программное обеспечение (а не аппаратные компоненты) будет в конеч- ном счете определять. когда система попадет на рынок. ° Программное обеспечение (а нс аппаратные компоненты) будет вбирать в себя болыную часть изменений, которые будут возникать во время разработки системы, и будет аволюционировать несколько последующих лет, чтобы удовлетворить лзсняющисся потребности систелзы. И, что самое удивительное, Глава 6. Инлсенерия систем, интенсивно нспользующюс программное... бУ ° вклад затрат на разработку и сопровождение программного обеспечения (с учетом амортизации за весь период жизни продукта) в абике гфокзводсжвенвые заш)>аяш становится сравнимым с вкладом затрат на аппаратные компоненты, а иногда да.
же превьппает его. В настоящее время во многих системах необходимо оптимизировать воз- можности их программного обеспечения, а пе аппаратных компонентов. Последнее означает, что теперь систему следует оптимизировать, исходя из затрат на разработку, сопровождение, эволюцию и усовершенствование содержащегося в системе программного обеспечения, а не иэ затрат на аппаратные компоненты илн производство. Это существенно меняет правила игрьь Теперь системное проектирование систем, использующих встроенное программное обеспечение, должно осуществляться с учетом используемых компьютеров.
Это означает, что необходилю сделать следующее. ° Максимизировать способность системы выполнять программу п>тем предоставления более чем достаточных вычислительных ресурсов даже за счет увеличения стоимости продаваемых изделий, добавляя дополнительные микропроцессоры, оператнвн>ю память, ПЗУ, массовую память, полосу частот нли любые др>тне ресурсы. которые требуются системе для выполнения ее програл~л~ьь ° Обеспечить адекватные коммуникационные интерфейсы между подсистемами н гарантировать, что выбранный коммуникационный механизм (Е~Ьегпес, Бгенаш, последовательный порт или одиночная линия связи) можно расширить с помо. щыо дополнительного программного обеспечения, а не аппаратных компонентов. В свою очередь это изменение повлияло на задачи управления требованиями в двух направлениях.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
