Система IT: особенности, требования, примеры выполнения

1.7 Предположения и зависимости

Предположение (assumption) — это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного.

Бизнес-предположения тесно связаны с бизнес-требованиями. Неверные предположения могут не позволить достичь поставленных бизнес-целей. Например, куратор из руководства компании может поставить бизнес-цель увеличить доход на 100 тыс. долларов в месяц. Определяя такую цифру, куратор сделал определенные предположения, например что новый сайт будет привлекать 200 дополнительных уникальных посетителей в день и что каждый посетитель в среднем будет тратить 17 долларов. Если новый сайт не привлечет достаточно посетителей, тратящих достаточное количество денег, проект может не достичь своей бизнес-цели. Если окажется, что те или иные предположения не оправ дались, можете изменить границы или график проекта или запустить другие проекты, чтобы достичь другие цели.

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

Задокументируйте важнейшие зависимости проекта от внешних факторов — изменения отраслевых стандартов или предписаний регулирующих органов, других проектов, сторонних поставщиков или партнеров по разработке. Предположения и зависимости бизнеса могут превратиться в риски, которые должен регулярно отслеживать менеджер проекта. Нарушение зависимостей — популярная причина задержек проекта

Опишите возможные последствия того, что предположения окажутся ошибочными или зависимости нарушены, чтобы заинтересованные лица могли понять, почему это так важно

Необходимо распланировать работы по проекту

Что касается сроков, трудоемкости, бюджетов и планирования, то вы должны понимать, что эти вопросы связаны.

Здесь ситуация такая:

Мне нравится, как сказал о планировании Эйзенхауэр – отсюда вывод какой? План – это не Библия, на которую нужно молиться или повесить его на стенку и постоянно ходить, всех тыкать о том, что план не исполняется. План нужен для того, чтобы суметь своевременно его перепланировать – только тогда он может дать полезные результаты.

Поскольку мы рассматриваем вопрос, как требования вообще влияют на проект, то — из чего складывается план работ? Очевидно, что план работ складывается:

из самих работ,
из сроков исполнения этих работ,
отсюда следует уже возможность оценки трудоемкости этих работ.

Когда мы все это вместе совокупно обдумаем, то тогда уже мы можем придти к некоему бюджету проекта. Опять же, все это взаимосвязано и источником плана работ у нас – по традиции уже – являются требования.

По каким принципам собирать информацию в эту документацию?

Остается вопрос – как эту документацию группировать? Допустим, мы знаем ответы на эти пять вопросов, а что с этими ответами делать?

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

Если, скажем, инициаторами проекта является IT-служба заказчика и проект носит какой-нибудь интеграционный сложный технический характер, то наверняка они захотят увидеть какой-нибудь детализированный технический документ, чтобы все реквизиты были прописаны, их все устраивало и пр. Но и принимать работу в этом случае тоже будут они. Здесь все понятно.

Если такой же документ принести высшему руководству, то – я уже об этом говорил – ничего им будет не понятно. Либо наоборот – сформировать требования какими-то общими словами – и отдать их программистам в разработку. Они будут что-то делать, но – опять не понятно, что из этого получится.

Какой отсюда можно сделать вывод? При разделении всей информации по документам нужно обязательно думать о том, кто их (эти документы) будет согласовывать

И здесь абсолютно не важно, как эти документы будут называться. Важен результат

Проблема «плохого» IT-решения

Компьютерные программы, так же, как и еда, одежда, обувь, техника бывают плохими – это правда

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

Многие разработчики же хотят охватить рынок по максимуму, разработав единое программное решение, которое и строительной компании и медицинской, будет, что называется, впору. Так не бывает. Во всяком случае, если речь идёт действительно о средстве автоматизации, ERP-системе, а не о текстовом редакторе, например. Решается такая проблема просто – путём внедрения специализированного отраслевого решения, а не программы «для всех типов компаний». Впрочем, внедрению какой бы то ни было программы проблема данного свойства сильно не мешает. Со временем доработать программу под нужды организации возможно, если заказчик согласен ждать месяцы и даже годы и платить за это.
Заметим, что существуют программы, которые не имеют отраслевой специфики. К примеру, это программы для ведения бюджетирования. Разработчики таких программ открыто говорят о том, что у них есть некоторый «каркас» программы, который далее можно наполнить новым функционалом. Однако в этом случае клиент должен быть готов к тому, что его индивидуальное решение будет создаваться некоторое время, нужно будет совместно с разработчиком согласовывать техническое задание на него, продумывать все детали.
Стоит сказать, что отраслевая направленность программы тоже не даёт стопроцентной гарантии удачного внедрения. Это лишь один из факторов, который должен добросовестно учитывать разработчик. Плюс ко всему, разработчик должен быть готов к быстрому, динамическому развитию программы. Например, в условиях меняющегося рынка, кризисных ситуациях, да и вообще в целом это очень важно. Та же самая строительная отрасль меняется настолько стремительно, что программа, которая три года не менялась вообще, не было выпущено никаких релизов, уже не может называться актуальным инструментом для ведения бизнеса. Сложность решения этой проблемы высока. Ведь медленное развитие программы делает её заведомо неактуальной в современной рыночной ситуации, ненужной. Скорее всего, просто методом естественного отбора такая программа из продажи исчезнет, став своего рода гужевой повозкой в мире автомобилей. Парадоксально, но внедрению данная проблема совершенно не мешает, потому что является отложенной и выявится лишь в дальнейшем. Но заказчик должен понимать, что если программу не собираются развивать, то смысл её приобретения и внедрения практически отсутствует.

Нефункциональных требований

Нефункциональные требования — Описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой.
Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.Нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надёжность, время ответа или размер системы. Кроме того, нефункциональные требования могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе.

Нефункциональные требования отображают пользовательские требования:
Нефункциональные требования основываются на бюджетных ограничениях, учитывают организационные возможности компании-разработчика, возможность взаимодействия разрабатываемой системы с другими программными и вычислительными системами, а также такие внешние факторы, как правила техники безопасности, законодательство о защите интеллектуальной собственности и т.п.

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:

легкость и простота использования;
легкость перемещения;
целостность;
эффективность и устойчивость к сбоям;
внешние взаимодействия между системой и внешним миром;
ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.

Семь шагов ADD

Шаг 1. Проверка входных данных

Убеждаемся, что все необходимые данные и требования доступны, приоретизированы, корректны и выполнимы, а цель работы понятна.

Шаг 2. Определяем список требований к подсистеме

Ранжируем требования по важности для бизнеса и степени влияния на архитектуру, группируем в соответствии с оценкой HML, выбираем 5-6 приоритетных. Устанавливаем цель каждой итерации.. Шаг 3

Выбираем часть системы для проектирования

Шаг 3. Выбираем часть системы для проектирования

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

Шаг 4. Определяем лучший вариант из возможных

Самый сложный пункт. Анализируем все варианты, находим преимущества и недостатки.

Шаг 5. Конкретизируем компоненты выбранной концепции, определяем обязанности и интерфейсы

Как правило, в начале работы концепция формулируется в общем виде. На данном этапе мы определяем все элементы подсистемы и ответственность каждого, выбираем интерфейс, через который компоненты взаимодействуют между собой.

Шаг 6. Делаем эскиз решения и краткое описание

Оформляем описание в наглядный документ, например, в виде UML-диаграммы или SFML. Нужно также зафиксировать все принятые решения, описать, на какие компромиссы мы пошли и какие альтернативы рассмотрели. Это поможет в дальнейшем оценить аргументы в пользу конкретной архитектуры и создать документацию.

Шаг 7. Проверка выполнения требований

На этом шаге методология рекомендует получить “второе мнение” других опытных коллег-архитекторов, для того чтобы подойти к процессу более объективно. Участие нескольких специалистов с их опытом и точкой зрения на архитектуру поможет оперативно выявить недочеты, если они есть.

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

3. Отслеживаем прогресс

Чтобы вовремя выполнить перечисленные выше шаги, архитектору нужно наблюдать за прогрессом работы команды и оперативно откликаться на изменения. Авторы методологии советуют отслеживать выполнение шагов с помощью архитектурного бэклога в виде канбан-доски. В ее столбцы мы помещаем архитектурно значимые требования, ограничения и системные задачи. Они могут иметь следующие статусы:

Not Yet Addressed (Еще не рассмотрено)
Partially Addressed (Рассмотрено частично)
Completely Addressed (Рассмотрено полностью)
Discarded (Отброшено)

Порядок проработки каждого ключевого требования

Но это еще не все. Дойдя до формулировки ключевых требований, мы поняли цели, критерии успешности, как заказчик собирается оценивать результат – мы все поняли, но что делать с этим дальше, как этого достичь – нам еще не известно. Так вот, при определении списка ключевых требований нам необходимо каждое из найденных ключевых требований проработать по следующей цепочке:

Берем требование, моделируем это требование в информационной системе. Берется тот программный продукт, который внедряется. Делается в нем пример. Еще лучше, если этот пример будет документироваться и сопровождаться в виде какого-то документа с описанием методики, потому что эта информация может пойти дальше – и в пользовательские инструкции, и в другую документацию.

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

Потому что если не договориться с заказчиком о том, как он это требование будет проверять, то, когда мы будем эти работы сдавать, мы будем их сдавать долго: заказчик может долго тянуть со словами « я еще не проверил».

Заканчивается все соответственно уже фиксацией требований в виде какого-то документа (Технического задания) – не важно, как вы его назовете. Александр Белов вообще говорит, что он никогда технического задания не делает – но он делает Протокол требований

Протокол требований – тоже документ

Александр Белов вообще говорит, что он никогда технического задания не делает – но он делает Протокол требований. Протокол требований – тоже документ.

Четвертая часть. Жизненный цикл требований

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

Конечно же, нужно стараться, чтобы требования были идентифицируемые. Идентификация может осуществляться по-разному. Самый простой способ – это просто сквозная нумерация (1,2,3,4…). Чтобы всегда можно было сослаться на то, что «требование № 526 не сделано». В этом случае процесс приемки-сдачи работ будет протекать гораздо более гладко и не будет таких проблем.

Как решать проблемы раздувания требований?

Важный момент по управлению требованиями:

Вот этот треугольник – это границы нашего проекта. Эта картинка предназначена для понимания проблемы раздувания требований.

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

Что с этим можно делать? Если это требование верхнего уровня, которое, в принципе, расходится с изначальными целями, то тут два варианта. Первый – сразу объяснить заказчику, что мы это выносим в новый проект. Второй – то же самое, объяснить заказчику, что мы это выносим в новый этап (с расширением, естественно, границ бюджета, сроков и т.д.)

Если уже какие-то конкретные функциональные требования выдвигаются (например, использование торгового оборудования – на этапе формулирования задачи не было, а потом – решили добавить), то самое логичное – это просто расширить требования, либо, как альтернативный вариант – делегировать эту задачу на IT-службу заказчика (тем самым, границы проекта остаются в тех же самых своих рамках).

А вот когда у нас начинается раздувание за счет потока пользовательских задач и там 200 человек и каждый из них что-то говорит, — то в этом всем можно просто «зашиться», потому что все, что они говорят, может вообще мало иметь отношение к тем самым ключевым требованиям. Тут какие есть варианты: можно использовать свои внутренние резервы, которые у нас должны были быть изначально на проект заложены, как раз для вот таких вот пользовательских доработок в части интерфейса, удобства и так далее. Но если эти пожелания явно уже вылезают за рамки проекта, либо у нас резерв не предусмотрен, то у нас есть два варианта. Либо мы объясняем, что мы реализацию этих пожеланий переносим за рамки проекта на какой-то уровень сопровождения, либо – в крайнем случае, когда больше ничего не остается – проще от них тогда отказаться. Это редко бывает, конечно. Можно, конечно, пытаться все реализовать, но этот процесс может быть бесконечным.

*************

Как собираются функциональные и нефункциональные требования?

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

Давайте посмотрим, что включает в себя каждый тип требований.

Функциональные требования можно разделить на три группы:

бизнес-требования — опишите цели и ожидания проекта, преимущества, которые может принести проект, возможные ограничения проекта и его объем;
требования пользователя — включают потребности пользователя и действия, которые пользователь сможет выполнять в системе;
системные требования — включают системные действия, спецификации программного и аппаратного обеспечения и т. д.

Нефункциональные требования подпадают под различные категории, в том числе:

удобство использования — определяет, насколько легко пользователь может взаимодействовать с интерфейсом приложения, например, цвет экрана, размер кнопок и т. д.;
доступность — гарантирует, что приложение будет стабильно работать в течение определенного периода времени, например, редкие простои в течение года 24/7;
надежность — определяет, что приложение будет работать в определенной среде или в течение определенного периода времени без сбоев;
восстанавливаемость — гарантирует, что приложение сможет восстановить все данные после сбоя системы или восстановить систему до определенных параметров;
масштабируемость — определяет, что приложение будет продолжать работать должным образом после изменения его размера или объема;
производительность — оценивает, насколько быстро работает приложение;
возможность поддержки — определяет, легко ли поддерживать и поддерживать приложение на протяжении всего его жизненного цикла, и какая поддержка ему требуется, например,
собственная команда или удаленная поддержка;
безопасность — определяет, насколько безопасным должно быть приложение, например, FinTech и банковские приложения должны соответствовать международным и региональным стандартам безопасности;
емкость — оценивает объем данных или служб, которые может обрабатывать приложение.

Особенности

При типе заземления системы IT (см. рис. 1) все части источника питания, находящиеся под напряжением, изолированы от земли или какая-то его часть, находящаяся под напряжением, заземлена через большое сопротивление. Открытые проводящие части электроустановки здания заземлены.

Рис. 1. Система IT трёхфазная трёхпроводная (на основе рисунка 2.26 из книги автора Харечко Ю.В.)

На рисунке 1 обозначено:

заземляющее устройство источника питания;
заземляющее устройство электроустановки здания;
открытые проводящие части;
защитный контакт штепсельной розетки;
сопротивление, через которое заземляют часть источника питания, находящуюся под напряжением;
ПС — трансформаторная подстанция;
КЛ — кабельная линия электропередачи;
ВЛ — воздушная линия электропередачи.

При типе заземления системы IT защитные проводники электроустановки здания не имеют такого электрического соединения с заземлённой нейтралью источника питания, как в системах TN-S, TN-C-S.

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

Система IT в отличие от систем TN-S, TN-C-S, TN-C и TT имеет чрезвычайно малые токи замыкания на землю. Поэтому в электроустановках зданий, соответствующих типу заземления системы IT, требованиями ГОСТ Р 50571.3-2009 первое замыкание на землю предписано определять посредством устройств контроля изоляции. Если до устранения первого замыкания на землю в электроустановке здания произошло второе замыкание на землю, то его следует отключать с помощью устройств защиты от сверхтока или устройств дифференциального тока. Однако УДТ могут сработать при первом замыкании на землю из-за ёмкостных токов утечки.

В тоже время, переход от систем TN к системе IT является необоснованным. Так как, например, даже если существует такой недостаток систем TN в нормальных условиях, как наличие потенциала на заземленных открытых проводящих частях электрооборудования класса I, то он может быть устранён без перехода на систему IT. Открытые проводящие части электрооборудования класса I в электроустановках зданий, соответствующих типу заземления системы TT, заземляют посредством их присоединения к заземляющим устройствам электроустановок зданий. Поэтому указанные открытые проводящие части в нормальных условиях находятся под электрическим потенциалом земли.

Таким образом, если в электроустановке зданий, соответствующих типам заземления системы TN, при каких-то условиях нельзя обеспечить надлежащий уровень электрической безопасности, следует применять систему TT. Причём переход к системе TT не требует внесения каких-либо изменений в существующие низковольтные распределительные сети.

Проблема конфликта интересов внутри фирмы-заказчика

Что касается ожиданий заказчика – первое, на что тут нужно обратить внимание – это то, что конфликт интересов может быть не только между заказчиком и исполнителем. Этот конфликт интересов начинается еще и внутри самого заказчика и связан этот конфликт интересов с тем, что автоматизируется предприятие заказчика – в большинстве своем – это большая иерархически подчиненная организационная структура

И часто бывает, что, допустим, директор (руководитель предприятия заказчика) решил, что их предприятие будет автоматизироваться, и издал приказ о том, что начинается проект – озвучил какие-то громкие цели. А после этого тихо самоустранился от проекта (наблюдает за ним со стороны), убежденный в том, что его подчиненные будут честно и добросовестно трудиться над тем, чтобы достичь этих великий целей. Как показывает практика, в 98% случаев эти подчиненные ничего делать не будут, кроме того, каждый организационный уровень этой организационной структуры будет пытаться удовлетворить свои интересы (если вообще будут что-то пытаться). Руководители подразделений будут что-то делать только ради своих подразделений, а конечные сотрудники будут думать только о том, как удобнее работать им.

Если не выявить истинных инициаторов проекта с самого начала, то процесс развертывания проекта будет пущен на самотек и это 100% приведет к проблемам – либо со сроками, либо с бюджетом, либо еще к каким-то проблемам.

Что с этим можно сделать?

Можно сделать три простых шага:

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

В первую очередь нужно выявить, кто же эти реальные инициаторы? Под инициаторами нужно в первую очередь подразумевать тех людей, кто будет принимать результаты работ. Потому что бывают ситуации, что инициатором чуть ли не весь проект называют руководителя, а принимать работу он доверяет какому-то иному лицу, которое в принципе в проекте могло вообще и не участвовать. Заканчивается это – понятно чем.
Итак, нужно выявить инициаторов, понять, какие ключевые требования от этих инициаторов поступают, и суметь эти ключевые требования декомпозировать – разложить их до конечных функциональных требований.

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

Проблема взаимодействия компании-заказчика и разработчика

Применительно к отраслевым программным решениям, независимо от того, заказные ли это разработки или тиражные программы, заказчик и разработчик должны находиться в постоянном контакте и профессиональном диалоге. Часто IT-проект обречён на неудачу, потому что заказчик не понимает, какой результат должен получиться, не может поставить задачу разработчику.
Связано это с тем, что заказчик и разработчик говорят на разных языках. Также изменение рыночной ситуации может повлиять на актуальность IT-проекта. Сложность решения данной проблемы средняя. Со стороны заказчика нужно сделать следующее: назначить ответственных за внедрение сотрудников, освободив их от части их прямых обязанностей для лучшего освоения программы. Со стороны разработчика требуется привлечение специалистов, знающих специфику отрасли. Возможно, следует привлечь экспертов извне, проконсультироваться с представителями выбранной отрасли и только затем предпринимать шаги по созданию IT-проекта. Внедрению, конечно, названная проблема мешает в значительной степени.
Расплывчатая стоимость системы тоже является камнем преткновения между компанией-разработчиком IT-проекта и компанией-заказчиком. Дело в том, что немногие компании-разработчики могут обеспечить пакетность услуг, обозначить конкретную стоимость системы и услуг по её внедрению (в процессе внедрения могут быть выявлены различные нюансы в построении бизнес-процессов компании-заказчика). На отраслевом рынке B2B – это явление, по сути, стандартное. Ответить на вопрос: «Сколько это стоит?» не могут многие разработчики. Дело в том, что иногда даже в готовое решение заказчик хочет добавить новый функционал, который будет ориентирован на специфику его компании. Соответственно, если такая возможность у исполнителя есть, то это будет расцениваться как дополнительная работа. Сложность решения этой проблемы довольно низкая. Достаточно прийти к компромиссному решению между заказчиком и исполнителем (поговорить о скидках, рассрочках платежей и так далее). Внедрению же она мешает сильно, т.к. из-за минимальных недоговорённостей процесс внедрения может быть прерван на полпути.
Вот каким образом видятся нам проблемы при реализации IT-проектов и способы их решения

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

Очень часто клиент только думает, что ему нужно «это», а ему, на самом деле, нужно «то».

Обеспечиваем команду техническими инструментами

За настройку технической инфраструктуры отвечает системный администратор. Строить боевую инфраструктуру сразу не обязательно – выполните минимальную часть, чтобы обеспечить команде место для работы.

Настройте:

репозиторий для кодовой базы проекта;
общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

Убедитесь, что у всех членов команды имеется доступ к инструментам разработки и рабочему окружению.

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

Требования к пользовательскому интерфейсу

Пользовательский интерфейс — часть программной системы. Требования к пользовательскому интерфейсу могут быть разбиты на две группы:

требования к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем;
требования по доступу к внутренней функциональности системы при помощи пользовательского интерфейса.

К первой группе можно отнести следующие типы требований:

Требования к размещению элементов управления на экранных формах
Требования к содержанию и оформлению выводимых сообщений
Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

Требования к реакции системы на ввод пользователя
Требования к времени отклика на команды пользователя

Управление требованиями

Управление требованиями — это процесс управления изменениями системных требований. Процесс управления требованиями выполняется совместно с другими процессами разработки требований. Начало этого процесса планируется на то же время, когда начинается процесс первоначального формирования требований, непосредственно процесс управления требованиями должен начаться сразу после того, как черновая версия спецификации требований будет готова.

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

Рассмотрим на примере

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

Задача

К нам обратился зарубежный заказчик — владелец крупного хранилища данных, полученных из старинных газет (более 1 млрд отсканированных страниц). Заказчику потребовалось найти и собрать в единую базу знаний все брачные объявления, а также записи о свадьбах: кто, когда и на ком женился.

Чтобы обработать информацию и выделить нужные факты, мы использовали нейросеть. Инженеры заказчика ранее уже создали все необходимые модели TensorFlow, которые должны запускаться последовательно, образуя конвейер. На вход модели поступал результат работы предыдущей модели, преобразованный по определенному алгоритму. Модели работали с разной скоростью и имели разные требования к ресурсам (потребление оперативной памяти, нагрузка на процессор, потребность в GPU).

Чтобы выполнить проект в срок, мы определили, что в среднем нужно обрабатывать до 10 миллионов страниц в день. Запросы на обработку поступали неравномерно, в некоторые часы их количество было близко к нулю, в другие — составляло порядка одного-двух миллионов. Страница полностью обрабатывалась не позднее чем через час после поступления.

Заказчик планировал развернуть систему в облаке

Поэтому было важно оптимально использовать вычислительные ресурсы, чтобы минимизировать плату за их аренду.

Варианты использования

ID	Вариант использования	Описание
UC-1	Извлечение фактов из текста	На вход системы подается отсканированный текст. На выходе получаем JSON с извлеченными фактами на интересующую нас тему.

Атрибуты качества

ID	Атрибут	Описание
QA-1	Быстродействие	До 10 миллионов страниц в день. Результат обработки страницы должен быть получен не позднее чем через 1 час
QA-2	Масштабируемость	Система должна уметь справляться с ростом нагрузки. Она неравномерная: от 0 до 2 миллионов запросов в час
QA-3	Экономичность	Необходимо оптимально использовать вычислительные ресурсы, чтобы минимизировать плату за их аренду

Ограничения

ID	Описание
CON-1	Cистема должна быть развернута в облаке AWS
CON-2	Использовать для вычислений готовые модели TensorFlow. Модели работают с разной скоростью. Требования к ресурсам сильно отличаются: некоторые потребляют много оперативной памяти, другие сильно нагружают процессор, третьим для работы необходим GPU

Шаг 1. Проверка и анализ исходных данных

Первая итерация – это референсная архитектура и общая структура системы.

Категория

Детали

Цель проектирования

Спроектировать систему с нуля

Работа должна быть выполнена в виде последовательных коротких итераций, чтобы оперативно получать обратную связь

Основные функциональные требования

UC-1

Атрибуты качества

Важность для клиента

Сложность реализации

QA-1

Высокая

QA-2

Высокая

Средняя

QA-3

Высокая

Средняя

Ограничения

CON-1

CON-2

Архитектурные задачи

Шаг 4. Выбор архитектурных концепций

Решение

Описание

Архитектурный стиль “Pipes and Filters”

Разобьем процесс обработки страницы на отдельные компоненты (фильтры). Каждый из них решает одну задачу с помощью одной модели TensorFlow.

Компоненты конвейера будут выполняться на разных компьютерах. Это позволит масштабировать их независимо друг от друга. И мы можем выбрать наиболее оптимальное оборудование для работы соответствующей модели TensorFlow

Альтернативное решение	Причина отказа
Монолит: выполнять всю обработку внутри одного неделимого модуля	Несмотря на то, что один модуль проще разрабатывать, сопровождать и развертывать, данный вариант не позволяет оптимально использовать вычислительные ресурсы из-за различий TensorFlow-моделей

Шаг 7. Анализ созданной архитектуры и прогресса

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

Пользователь — Требования пользователя

Эти требования должны определять только внешнее поведение системы, избегая по возможности определения структурных характеристик системы. Пользовательские требования должны быть написаны естественным языком с использованием простых таблиц, а также наглядных и понятных диаграмм.

Проблемы при формировании пользовательских требований

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

Проблемы несоответствия содержания документов требований техническому уровню инициаторов проекта

Основная проблема здесь заключается в том, что некоторым специалистам хочется запихать вообще всю информацию, которая имеется по проекту в один документ, либо хочется разделить эту информацию на множество других документов. Либо – сделают один какой-нибудь очень сложный, большой технический документ и, скажем, отдают его на согласование генеральному директору заказчика какого-нибудь крупного холдинга, который в этом документе вообще ничего не понимает. В таких ситуациях что происходит обычно?

Либо этот генеральный директор начинает очень долго думать, привлекая для согласования своих специалистов – месяца два они этот документ пытаются согласовать. Либо этот генеральный директор вообще не думает и сразу – не читая, этот документ согласовывает. Ни там, ни там особой пользы нет. Понятно, почему. Потому что не факт, что этот документ кто-то изучал. Даже если мы все сделаем так, как там написано, не факт, что заказчик хотел именно это, потому что он на самом деле не разобрался. Когда заказчик согласовывает документ, в котором ничего не понял – это должно очень настораживать.