Принципы работы с требованиями к ПО. Леффингуэлл (2002) (Принципы работы с требованиями к ПО. Леффингуэлл (2002).djvu), страница 18

° Каждый из этих параметров будет создавать новые зфебоапяил, которые должна выполнять система аппаратного обеспечения для построения успешного решения. ° Основная масса проблем требований переходит к программному приложению. К счастью, по крайней мере, последнее является темой данной изнги, и мы надеемся хорошо подготовить вас к решению этой конкретной проблемы. Как избежать проблемы создания системы типа "печной трубы" Итак, для того чтобы справиться со сложностью, л~ы решили использовать подход, в котором система составляется иэ подсистем. В противном случае придется иметь дело с невероятно сложными системами с непредсказуемым поведением, которые никто пе мо. жет понять, с проектом, основанным на совместно используемых функциях, плохом разбиении и последовательнол~ коде, который невозможно распутать.

Разбиение системы и использование методов системной инженерии выглядит вполне оправданно. Как это отражается на управлении требованиями) Когда будет подведен окончательный итог, обнаружится, что требований подсистем гораздо больше, чем тех (внешних) требований, которые влияют на поведение системы в среде пользователя. Мы эатратим гораздо болыпе сил па выявление требований к подсистеыаьп расстановку приоритетов и 88 Часть Е Анализ проблемы управление ими, чем на те требования, которые оказывают влияние на конечного потребителя.

Это уже нельзя считать позитивным. Что случится, если разбиение системы проведено не совсем удачно? Система станет хрупкой и будет сопротивляться изменениям, так как производные требования будут привязывать нас к конкретной реализации. Требования к подсисте. лбам будут оказывать воздействие на гибкость проекта, и изменение в Е:3 одной подсистеме вызовет цепную реакцию в других подсистемах. Такие системы по своим свойствам аналогичны печной трубе. которая мешает перестроить дом. Они иротиводейсвмуют изменениям. Проблемы интерфейсов могут быть еще серьезнее. Если интерфейсы не специфицированы надлежащим образом, система будет уязвимой. Она не будет способна к эволюции в условиях меняющихся потребностей без полной замены интерфейсов и целых подсистем, основанных на них.

Когда подсистемы являются субконтрактами Часто возникают дальнейшие осложнения. Поскольку подсистемы обычно разрабатываются различными командами (ведь, в частности, для этого мы осуществляли разбиение системы на подсистемы), требования и интерфейсгя подсистем становятся конгнракюами между командами. ("Моя подсистема предоставляет результаты расчета скорости ветра в точности в укаэанном формате...".) Иногда подсистема может разрабатываться субподрядчиком из другой компании. В этом случае задача требований перестает быть чисто системной и технической и превращается в политический "футбол". (" Требования нельзя изменить, если не пересмотреть контракт.") В результате весь проект может застопориться.

Следует заметить, что многие напитки сидания круг» номасшв~абных систем били "гюхороненм" из-за столкновения с данной проблемой, Как сделать систему работоспособной Что же делать? Первоочередной задачей является тщательное проведение проектирования системы в целом с использованием методов системной инженерии. Для систем с интенсивным использованием программного обеспечения, мы можем дать следующие рекомендации. ° Следует разработать, понятьи сопровождать требования высокого уровня и прецеденты, которые соединяют подсистемы и описьшают функции системы в целом.

Этн прецеденты покажут, как предположительно будет работать система, и позволят сосред<» точить внимание на главном. Они также помогуг убедиться, что разработанная системная архитектура поддерживает наиболее вероятные сценарии использования. ° Необходимо сделать все возможное для наилучшего разбиения и изоляции функцис» нзльиых возможностей внутри подсистем. При этом следует использовать принципы объектной технологии; инкапсуляцию и сокрытие информаомн, интерфейс по контракту, обмен сообщениюги кместо совместного использования данных.

° Если это возможно, следует разрабатывать программное обеспечение как целое, а не в виде нескольких отдельных частей, каждая из которых связана с определенной физической подсистемой. Одной из характерных особенностей систем типа печной трубы является то, что на обеих сторонах интерфейса (неважно, хорошо Глава 6. Инженерия систем, интенсивно использующих программное... 89 Поучительная астория.

Разбиение крупных систем программного обеспечения иа подсистемы в случае, когда команда разработчиков состоит из нескольких о гдельных групп Однажды на занятиях 1'асти, опытный менеджер программного обеспечения, по- дошел к нам и поставил следующую задачу. Между нами произошел приведенный ниже диалог. Мы создаем крупное приложение, которое выполняется одиночной сис. темой-хостом.

У нас есть две отдельньзе команды разработчиков по эО человек каждая; одна команда находится на восточном берегу реки в Нью-йорке, а вторая — на западном. Команды имеют различных менеджеров и разные уровни компетентности. Как можно распределить работу, чтооы создать систему, которая будет работоспособной сразу после окончания разработки? Данную задачу мозсно (загонит(завить как задачу сштемной згнлсене(зззи. Иными словами, зфедставь, кан мозкно Разумным об)завом )зозбить сштему на две подсистемы. Назови их Еазг и Изезг и (зазмести требования к нодсистемам так, как если бы они быеи отдельными фишческими сисвмиами.

Он)зедееи некий инте)зфейс, дополненный ои(зеделением обзйззк нснользуемых классов и се)тисов, что позволит двум нодсистеиам (п(ныожениям) кволо)Зи- ~> ова тьсл для осу зйеппвленил обц еси паем ныл фу нкиий А не получится ли в результате произвольная система, не подчиняющаяся никаким архитектурным правилам? Вззаене возмоэсно, в техническим смысле. Но сооб(зазкеннл но (зазбиензгю, > зи. тываюнгие логистические линии и снезсифику навыков команды зз)зоекнш, могут окова нгьсл не менее возки ыми. Расти: Мыз Расти: Мы: или плохо определенного) программа должна реконструировать состояние ключевых элементов (объектов), которые нужны для принятия решений; в отличие от аппаратного обеспечения, размещение требований на обеих сторонах не является признаком хорошего разбиения. ° При кодировании интерфейсов необходвазо использовать одинаковый код на обеих его сторонах.

В противном случае могут быть незначительные вариации, часто называемые "оптимизациями", которые сделают синхронизацию состояний очень затруднительной, И если граница между двумя физическими подсистемами позднее исчезнет (например, выяснится, что процессоры достаточно хороши, чтобы поддерживать обе подсистемы, и А, и В), то разработчикам программного обеспечения будет достаточно сложно "соединить" две части программного обеспечения, ° Следует задать такие спецификации интерфейсов, воэможности которых больше, чем это необходимо для выполнения уже известных условий. Пусть будет немного больше полоса частот, дополнительный порт ввода-вывода или некие другие интеллектуальные средства, чтобы обеспечить пространство для расширения.

Наконец, нужно постараться найти кого-нибудь из "стариков", чтобы они помо~ли вам применить лзетоды системной инженерии. Они уже делалн это раньше, и их опыт будет полезен. 90 Часть 1. Анализ проблемы Не получится ли так, что будут созданы искусственные интерфейсы и система, которая может превратиться в "печную трубу"1 В некопнфом смысел, это возмолснц номы бы посоветовали, чтобы код интффей. са для ойих спшрон разрабатывался тсиько одной командой. В пунпяивном случае обе команды пушдеяаюпг много игбыпшчной рабтлы. При этом вы дпйэгмипнльно андадите новые п~мбования для системы, в тном чиом интффейсьь котЧьые иначе были бы не нулсггы илга но арайнаг мйуе, были бы не настолько ффмаяизованы. И дейсяшипмльно, важна помнить о гфобееме гмчной пгрубы и сдвють все возможное для пшгц чтобы минимнлг ровать связь между сиииемами и пгмиппоиские аспекты, ковифые могут пфи эпшм епник путь Расти: Мы: Рабочий пример Предварительные потребности пользователя Предположим, что для НО1.1$ уже были определены некоторые хорошо понимаемые потребности пользователя.

° НО1.1б должна поддерживать "программируемые" клавиши-переключатели — индивидуально програмл~ируеь~ые переключатели, используемые для активизации функций освещения в различных коьшатах. ° Домовладельцы потребовали обеспечить возможность программировать НО1.Б из удзленного центра, чтобы они имели возможность просто сообщить туда о сво. их потребностях и не заниматься вопросами "программирования" НО1.Б вообще. ° Другие потенциальные покупатели потребовали, чтобы НО1.Б можно было программировать с их доь~ашнего персонального компьютера и чтобы им была предоставлена возможность самостоятельно выполнять все действия, связанные с установкой, программированием и обслуживанием системы.

° Еще одна категория пользователей пожелала, чтобы система предоставляла про. стой интерфейс в виде панели с кнопками, который можно было бы использовать для изменения программы НО1.Б, установки режима "жильцы в отпуске" и т.д., не прибегая к применению персонального компьютера. ° Необходимо, чтобы НО1Б предлагала некую систему контактов в случае опасности. Получилось слишком много для краткого введения в системную инженерию. Теперь попробуем применить то, что ь~ы изучили, к НО1.1$, нашей домашней системе автоматического освещения. Сейчас мы не будем тратить много времени на понимание требований к НО1.Б. Мы сделаем это в последующих главах.

В этом смысле системное проектирование будет несколько преждевременным. С другой стороны, мы, возможно, знаем достаточно, чтобы принять некоторые первоочередные решения по проекту системы, основываясь на нашем опыте и понимании вероятных требований. В любом случае на данном этапе мы не принимаем никаких окончательных решений относительно про граммного или аппаратного обеспечения и можем пересьютреть их позднее.